Fortran SPICE for IBM mainframe

[ozcar]

You saw that same problem before, and I told you how to fix it, but I cannot see any sign that you did that.

This is my take on how you got to this point:

Your first assembly generated a huge number of error messages because the macro for the register equates was missing, so you made some changes to the source, but in the process accidentally (presumably!) deleted that LTORG, but you still had a single error there, and somehow discovered that if you changed the instruction to "  S     R10, 128 ", then the error message went away. You hinted that 128 was the largest value that "worked", but that is not true - you will find, if you want to expand your assembler knowledge, that "    S     R10,4092 " will also make the error message go away.  "   S     R10,4093 " ( or 4094 or 4095) will make the error message go away, but will probably generate another, less severe "warning" message (as will some values below 4092). Finally, with a value greater than 4095, you would be back to the same addressabilty error you get when using a value specified as =F'nnn'. There is a big difference between making the assembler error message go away, and having code that will do the right thing when executed though, and your change could have resulted in all sort of error at run-time, ranging from SPICE complaining that there was not enough storage, various system routines doing the same via S80A abends, or perhaps even S0C4 (I've forgotten when the "fetch protection override" feature first appeared in MVS, but that would cause weird things at the 2048 boundary).

So, having fixed, or so you thought, the assembly problem, you compiled the Fortran code, but when you linked it, it generated a bunch of errors messages about "unresolved" symbols, for various "IHCxxxxx" names. Somehow, you found that you needed to add "SYS1.FORTLIB" to the JCL for the link step, because some Fortran library routines have to be included into your SPICE module, and these library routines are in SYS1.FORTLIB. Unfortunately, when you re-ran the link step, it did not replace the SPICE module, so when you tried to run it, it got the S0C1 due to the unresolved references in the previous link. When you eventually sorted that out, you got a new error when you tried to run the SPICE program:

IEA703I 806- 4 MSZR01UX GO MODULE ACCESSED IHCSTAE

Your latest run got the same problem, because you have done nothing to fix that - or at least, nothing that I can see.

That message says that the system is trying find a module named IHCSTAE, which from the name is a Fortran module. That means your code has made it into the Fortran code statically linked into SPICE, but that the Fortran code needs additional library code which is only loaded when the program is running (this is what I said was similar to a DLL). Now there are two ways you can fix this. The one involves updating a SYS1.PARMLIB member, and re-ipling MVS, and the other requires a change to the JCL you use to run the SPICE program. I suggested that you do the second of those.

Whichever way you want to do it, the first thing to do is to find out where the load module "IHCSTAE" is. My starting point would be to see if it is in SYS1.FORTLIB, together with the various IHCxxx members that were picked by the linkage editor. If it is there, then good, if not you will have to look for it in whatever other Fortran libraries exist on the TK4 system. When you know where IHCSTAE is, add that to your STEPLIB where you run the SPICE module (concatenate with your MSZR01U.SPICE.LOAD).

[ozcar]

In addition to the above:

You have made progress, because the one thing that you did do is correct the problem with the SYSUDUMP statement, so your latest run produced a dump, which shows something interesting:

You managed to get not one, but actually two abends. The one that is visible at the top of the job output (the S806 problem trying to find IHCSTAE) is the second abend. There is actually a clue in the IHCSTAE name - "STAE" is the name of an MVS service related to intercepting and trying to handle errors (abends). It appears the reason Fortran is trying to call that particular module, is because of a prior error.

You should still find where IHCSTAE is, and add that to your STEPLIB, but that will probably just produce some additional Fortran messages about the first error that caused it to be looking for IHCSTAE.

So, the first abend is a S0C2 which is "privileged operation exception", which means that the program tried to execute an instruction code which is "valid", but which is restricted to programs which are running in "supervisor state", - in other word instructions intended to be used by the operating system (or by close friends - long story).

Now you may remember I said I saw a DIAGNOSE instruction in the source code? Well, that is where is has failed. I'm not really familiar with CMS, but I guess VM/CMS allows peasant programs (ones not running in supervisor state) to issue this instruction, or perhaps historically did allow that. Specifically SPICE is trying to use CMS "DIAGNOSE Code X'0C' – Pseudo Timer". That returns information about the CPU time used, but also provides a date and time value.

I saw one point where it seemed to just use the CPU time used to produce a message telling you how much it is costing you to run the program. I think you know exactly how much it is costing you on your Rpi, so I don't think that it is too important to you, so that would be easy to fix. But it seems it uses the same instruction in another place to do something with the date and time - might also just be cosmetic, but I'll have to dig a bit into it to see...

[wilfred]

There is a message
15.44.20 JOB 1462 IEC141I 013-14,IGG0191B,MSZR01UA,LKED1B,SYSLMOD,290,PUB003,
15.44.20 JOB 1462 IEC141I MSZR01U.SPICE.LIB

Which is the job alerting you to another issue. You appear to be creating
14 //SYSLMOD DD DSN=MSZR01U.SPICE.LIB,
// UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,CATLG),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)

as a "sequential" dataset what you really should do is create it once and just reference it in the JCL as DISP=MOD which means just use the one that exists in the catalog.

However OBJ and LOAD libraries are just that, libraries or collections of related modules. These are stored in "PARTITIONED" datasets which are created with an internal directory. They do tend to creep toward the limit of SPACE allocated and occasionally need to be compressed. ie free space is accumulated at the end. Analogous to defraging a disk drive. But that's just life on an MVS system.

I would create the OBJ and LOAD libraries just once and not each time the job runs but there is no need to do that if this is the only thing you want in them. You do it if you just want to come back later to execute them and not recompile them each time.

If you want to continue recreating them each time them consider adding DSORG=PO and SPACE=(CYL,(1,1,20),RLSE)

This allocates a 1 cylinder dataset that can grow in 1 cylinder increments (limit 15) and has 20 directory blocks which is more than needed for a single load module. RLSE will release allocated but unused space at job temination to the nearest cylinder in this case.

however if you really don't want to keep the OBJ and LOAD modules then consider using a temporary dataset name which is prefixed with && like &&LOAD or &&OBJLIB.

[wilfred]

The S0C2 might mean ICHSTAE needs to come from an authorised library in the LINKLIST.

[ozcar]

The S0C2 might mean ICHSTAE needs to come from an authorised library in the LINKLIST.

You're probably thinking of one of the variants of S306 for an authorised program trying to access a module from a non-auth library. That is not the situation here, and the dump does point to one of the DIAGNOSE instructions.

[wilfred]

   Pretty sure I was thinking it must be getting on to 20 years since I last looked at an RTM2WA in anger. 

I've probably forgotten more than I ever knew.

Nonetheless  I am intrigued by someone trying to get SPICE (and FORTRAN) going on MVS and did I see it was on an Rpi.
It is gems like this thread that keep the forum interesting to me.

I've got a spare Rpi or three laying around.

[ozcar]

About the S0C2:

I had a bit of a look at the code, and it looks like it would not be difficult to get around the current issue. This suggestion here is the totally lazy way, by just providing static "dummy" information for what it expects to get from CMS. For the date and time, those don't appear to be manipulated at all, only written to a file (report?) -  at least, as far as I could see. It does some calculations with the CPU time, (and checks that it does not exceed a limit), but I think it will be none the wiser if we just always return zeros.

Someone more keen that me could consider provide more than just dummy information.

The two assembler routines are DATIME (date and time obviously), and SECOND (because it provides CPU time in seconds). The troublesome instructions were specified in hex in the code - X'83...', because there was no defined assembler mnemonic for DIAGNOSE. I've just commented those out and pre-filled the storage used with dummy info.

Code: [Select]

SECOND   CSECT
         BC 15,12(15)
         DC X'7'
         DC CL7'SECOND '
         STM  14,12,12(13)
         BALR 12,0
         USING *,12
         L   2,0(,1)
         LA    3,AREA
***      DC    X'8330000C'  DIAGNOSE INSTR FOR TIME - COMMENT FOR MVS
         L     4,16(3)
         N     4,=X'00FFFFFF'
         O     4,=X'4E000000'
         ST    4,16(3)
         LD    0,16(3)
         DD    0,=D'1000000.0'
         STD   0,0(2)
         LM  14,12,12(13)
         MVI 12(13),X'FF'
         BCR 15,14
AREA     DS    0D                  NOTE, CHANGED FROM 4D TO 0D 
         DC    CL8'12/31/99'         MM/DD/YY   - DUMMY FOR MVS
         DC    CL8'23:59:59'         HH:MM:SS   - DUMMY FOR MVS
         DC    XL8'0000000000000000' VIRTCPU    - MICROSECONDS 
         DC    XL8'0000000000000000' TOTALPROC  - MICROSECONDS
         LTORG
         DROP


Code: [Select]

DATIME  CSECT
        BC 15,12(15)
        DC X'7'
        DC CL7'DATIME '
        STM 14,12,12(13)
        BALR 12,0
        USING *,12
        LA 6,SOURCE
        L  7,0(1)
        L  8,4(1)
***     DC X'83',XL3'60000C'     COMMENTED OUT FOR EXECUTION ON MVS
        MVC 0(8,7),SOURCE
        MVC 0(8,8),SOURCE+8
        LM  14,12,12(13)
        MVI 12(13),X'FF'
        BCR 15,14
SOURCE  DS  0D                    NOTE, CHANGED FROM 4D TO 0D
        DC  CL8'12/31/99'         MM/DD/YY   - DUMMY FOR MVS
        DC  CL8'23:59:59'         HH:MM:SS   - DUMMY FOR MVS
        DC  XL8'0000000000000000' VIRTCPU    - MICROSECONDS 
        DC  XL8'0000000000000000' TOTALPROC  - MICROSECONDS
        LTORG
        DROP

Hopefully there is no other CMS dependency.

And, no, I did not try to assemble those to check for typos. Edit, there was an error on one line, now corrected.

[MiroS]

I am starting to do random changes, which is clearly is not the way.
I am thinking that it  require more skills than I have at this moment.

[ozcar]

I am starting to do random changes, which is clearly is not the way.

MiroS,

It's a good job that I was not suggesting that you make random changes then.

I'll admit I had to run it three times, twice because I mangled the JCL, and the third time because, yes, there was an error in my suggested change to the assembly code (I told you I had not tried to assemble it). So where I had this in the "SECOND" routine:

Code: [Select]

***      DC    X'8330000C'  DIAGNOSE INSTR FOR TIME INFO - COMMENT FOR MVS

I had to change it to:

Code: [Select]

***      DC    X'8330000C'  DIAGNOSE INSTR FOR TIME  - COMMENT FOR MVS

I'll leave it as an exercise for you to work out what was wrong with my original suggestion.

I know absolutely nothing about how to use the resulting program, but I am up to copying the "benchmark.in" file that was provided with the source, and this is what I get:

Code: [Select]

*******12/31/99 ********  SPICE 2G.6    3/15/83 ********23:59:59*****


MOSAMP2 - MOS AMPLIFIER - TRANSIENT


****     INPUT LISTING                    TEMPERATURE =   27.000 DEG C


***********************************************************************



.OPTIONS ACCT ABSTOL=10N  VNTOL=10N
.TRAN 0.1US 10US
M1  15 15  1 32 M W=88.9U  L=25.4U
M2   1  1  2 32 M W=12.7U  L=266.7U
...

You can see when I ran the job on the first line there. No, I lied, what you can see there is the 'dummy' date and time that I put in the code - my tribute to y2k about to happen.

There is all sorts of other good stuff in the report with an example of 1980s (or earlier) attempts to produce graphs on a printer that was not really up to the job.

I'll attach the output here.

Edit:
I just noticed that I did not pick up the entire report above and in what I attached, only the last section of it. The whole thing is quite big, but here is where it starts:

Code: [Select]

*******12/31/99 ********  SPICE 2G.6    3/15/83 ********23:59:59*****


DIFPAIR CKT - SIMPLE DIFFERENTIAL PAIR


****     INPUT LISTING                    TEMPERATURE =   27.000 DEG C


***********************************************************************



.WIDTH IN=72
.OPT ACCT LIST NODE LVLCOD=2
.TF V(5) VIN
...


[MiroS]

I adjusted assember code , replaced example and some other staff, no effect.
I am not giving up , but it looks like out of my skill for the moment

Interesting is that now LIB format is different na dwhen I try to view it there is error
IKJACCNT,241,DA,SYS00115,READ  ,WRNG.LEN.RECORD,00000013000000,BSAM

but OBJECT file looks OK to me, so that is appointed for linker

 ****** ***************************** Top of Data *****************************
 000001  ESD                            ADDGEN          TRPNUM                 
 000002  ESD            REGVAL     {    NXTCOD          SECOND         Ç       
 000003  ESD            CODEXC     µ   ĐSCRTCH          NXTCOD                 
 000004  ESD            DATIME     &   ĚMINS3A     H    ADDGEN                 
 000005  ESD            LOC        }    MINS0      Y   öSCRTCH                 
 000006  ESD            TRPNUM          REGVAL          MINS1      ˝   8       
 000007  ESD            MINS2      ¬   0MINS4      µ   ©MINS3      ě           
 000008  ESD            GTMAIN     Ě                                           
 000009  TXT            ĺ00  ADDGEN °Ö} i   č 1     č 1 «   ĺŘ0Ąě-1 ě 1 ě 1 ß 
 000010  TXT            ĺŘ0ćßŔ  ĺ}0<ěŔ   Č c! 1 ă 0    ĺ&   ě 1 ě°1 ěz   Ý!µ1 &
 000011  TXT   ř          ěµ0˝iŘ   y s ż  hµ   ż  ěµ0Ż y ż  hµ   ż  i     ěř1  
 000012  TXT   y          &ř1 &Č  q }  Ú    i                                 
 000013  TXT   \                                                               

[wilfred]

Try this on the LKED1B step. That DCB is not a load module format. Also change the SPACE parm. I can't test it but it should be a quick test.

//SYSLMOD DD DSN=MSZR01U.SPICE.LIB,
//                      UNIT=SYSDA,SPACE=(CYL,(1,1,1)),DISP=(NEW,CATLG) <-- remove comma continuation.
//*                    DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)                 < -- comment with * in col 3

[ozcar]

Miros,

I looked at the assembler output, and you did not get the changes I suggested quite right. With what you have done, it won't get the S0C2 problem, but it will be a bit messed up. This is what you need to do to fix it:

In the SECOND routine, you have lost the line with the date, ( DC CL8'12/31/99'  ...) which should have been immediately after the line with label AREA.

In the DATIME routine, you have not changed "SOURCE  DS  4D" to "SOURCE  DS 0D", and that is despite me adding a comment on it to highlight that this needed to be done.

I'm not sure if Wilfred has sorted your other problem out, but this might help, (or might just confuse things more, sorry).

Object code consists of records 80 bytes long (hangover from days of punched cards). Can be stored in "partitioned" datasets (DSORG=PO in the DCB info) which need additional parameter for "directory blocks" when they are created, or sequential data set (DSORG=PS). Either of those would normally be blocked (RECFM=FB), so with LRECL=80 and BLKSIZE=<some multiple of 80 appropriate for track size>.

Object code can be linked to form a (perhaps incomplete) load module (that is what you were doing originally with the assembler object code, I did not check if it is still like that - nothing wrong with doing it that way).

A library with executable programs (complete, ready to run load modules) is in a different format. It is always a partitioned dataset (so DSORG=PO), so-called "undefined" record format (RECFM=U), and typically block size chosen to be the maximum which will fit on a track (BLKSIZE=13030 for 3330 disks, and BLKSIZE=19069 for 3350 disks). (I'm sort-of amazed that I still remember those strange numbers).

And, if you have not noticed it yet, partitioned datasets need to be "compressed" occasionally to reclaim space that becomes unused when members are deleted or replaced.

BTW, if you write to an existing dataset using the wrong setting for things like RECFM or BLKSIZE, it may change the original settings for the dataset and mess it up. Probably best to just delete it and start over if that has happened to you.

Apologies in advance for any typos in that very brief explanation.

For the record, here is the JCL I used. The HERC01.TEST.LOADLIB is as it came with the TK4- system. I allocated the HERC01.TEST.OBJ (partitioned dataset for storing both the assembler and Fortran object code) before I ran the job. I more-or-less copied your JCL but the whole lot is in one job, and no, I did not try to sort out the condition code checking to stop it from trying to proceed when there have been errors.

Code: [Select]

... JOB card here ...
//*
//ASMF     EXEC PGM=IFOX00,REGION=2048K                                 
//SYSLIB    DD  DSN=SYS1.MACLIB,DISP=SHR                               
//         DD DSN=SYS1.AMODGEN,DISP=SHR                                 
//         DD DSN=SYS2.MACLIB,DISP=SHR                                 
//SYSUT1    DD DISP=(NEW,DELETE),SPACE=(1700,(900,100)),UNIT=SYSDA     
//SYSUT2    DD DISP=(NEW,DELETE),SPACE=(1700,(600,100)),UNIT=SYSDA     
//SYSUT3    DD DISP=(NEW,DELETE),SPACE=(1700,(600,100)),UNIT=SYSDA     
//SYSPRINT  DD SYSOUT=*                                                 
//SYSPUNCH  DD DSN=HERC01.TEST.OBJ(SPICEA),DISP=SHR
//SYSIN     DD *
ADDGEN   CSECT
*        CREATE THE SECOND HALFWORD OF AN RX TYPE INSTRUCTION.
 ..... all the rest of the assembly code
//*
//FORT     EXEC PGM=IEYFORT
//SYSPRINT DD  SYSOUT=*                                   
//SYSPUNCH DD  SYSOUT=B                                   
//SYSLIB   DD  DSNAME=SYS1.FORTLIB,DISP=SHR               
//SYSLIN  DD  DSNAME=HERC01.TEST.OBJ(SPICEF),DISP=SHR           
//SYSIN    DD *
C SPICE VERSION 2G.6  SCCSID=root.ma 3/15/83
C     PROGRAM SPICE
 ..... all the rest of the Fortran code
//*
//LKED EXEC PGM=IEWL,REGION=8000K,                           
//   PARM=(XREF,LET,LIST),COND=(4,LT,FORT)                   
//SYSLIB   DD  DSNAME=SYS1.FORTLIB,DISP=SHR                   
//SYSLMOD  DD  DSNAME=HERC01.TEST.LOADLIB,DISP=SHR         
//SYSPRINT DD  SYSOUT=*                                       
//SYSUT1   DD  UNIT=SYSDA,SPACE=(1024,(900,90),RLSE),         
//             DCB=BLKSIZE=1024,DSNAME=&SYSUT1,SEP=SYSLMOD   
//OBJECT   DD  DSNAME=HERC01.TEST.OBJ,DISP=SHR       
//SYSLIN   DD  *
 INCLUDE OBJECT(SPICEF)
 INCLUDE OBJECT(SPICEA)
 ENTRY MAIN
 NAME SPICE(R)                                   
//GO EXEC PGM=SPICE                             
//STEPLIB DD DSN=HERC01.TEST.LOADLIB,DISP=SHR
//        DD DSN=SYS1.FORTLIB,DISP=SHR 
//SYSUDUMP  DD  SYSOUT=*     
//FT06F001 DD  SYSOUT=*                       
//FT07F001 DD  SYSOUT=B                       
//FT05F001 DD  *
DIFPAIR CKT - SIMPLE DIFFERENTIAL PAIR
.WIDTH IN=72
 ... all the rest of the input for the spice program

Edit: I mentioned wrong label in SECOND routine, corrected it to be "AREA" not "SOURCE".

[MiroS]

Thanks, that was very helpful. Now play time BIG thanks to ozkar and wifred 

It may be useful for someone like me:

1. OBJ dataset created with below attibutes
                                   
   DATA SET NAME:  HERC01.TEST.OBJ 
                                   
   VOLUME SERIAL:  PUB010  (3350)   
    ORGANIZATION:  PO               
   RECORD FORMAT:  FB               
   RECORD LENGTH:  80               
    BLOCK LENGTH:  400             
      INDICATORS:  RACF MODIFIED   
                                   
UMBER OF EXTENTS:  2               
     USED TRACKS:  341             
ALLOCATED TRACKS:  600             
 ALLOCATION TYPE:  TRACK           
CONDARY QUANTITY:  300             
                                   
UMBER OF MEMBERS:  2               
 USED DIR BLOCKS:  1               
TOTAL DIR BLOCKS:  10               


2. LOADLIB is comming with TH4-

   DATA SET NAME:  HERC01.TEST.LOADLIB 
                                       
   VOLUME SERIAL:  PUB010  (3350)       
    ORGANIZATION:  PO                   
   RECORD FORMAT:  U                   
   RECORD LENGTH:  0                   
    BLOCK LENGTH:  19069               
      INDICATORS:  RACF MODIFIED       
                                       
UMBER OF EXTENTS:  8                   
     USED TRACKS:  211                 
ALLOCATED TRACKS:  240                 
 ALLOCATION TYPE:  CYLINDER             
CONDARY QUANTITY:  1                   
                                       
UMBER OF MEMBERS:  1                   
 USED DIR BLOCKS:  1                   
TOTAL DIR BLOCKS:  20                   

I am attaching  full job card deck in spice.txt file and job output in spice2.pdf

BTW , I am quite sure that MVS will last next decades and many 'modern' systems will gone, so vintage , but who would call  for example a hammer a vitage tool

[ozcar]

MiroS,

Great that you got it to work finally. It is quite surprising how little really had to be changed - it is quite complicated code, huge lot of Fortran, and some of the assembler code acts like a sort-of compiler that builds sequences of instructions to execute (I did not try to understand exactly what it does).

A couple of comments:

You will notice in your SPICE output it created headings like this:

Code: [Select]

**************** ºÖ º• ************************  SPICE 2G.6     3/15/83 ************************ ºú s**************

In the middle there it has the Spice version number and date which are just constants in the Fortran code. However, those weird characters in the middle of the asterisks on each side are supposed to be the date (that you ran the Spice program) on the left, and the time on the right. The reason that you are getting that is that it seems you misunderstood what I told you last time, because you did not fix one of the things I told you to fix, and you "unfixed" something else (maybe partly my fault because initially I mentioned a wrong label in the code).

The problem you have now is that in both of the routines, SECOND and DATIME, one of the statements was supposed to have been changed from having "DS  4D" to "DS  0D". Yesterday you had changed one of those, but not the other, now you have put both of them back to what they were before my change, so now both are wrong. The code as I posted it a few days ago was 100% correct, EXCEPT for that one statement that I later mentioned (there was nothing wrong there in regard to the DS 0D). I have gone back and modified my original post to correct the other statement (which you had already fixed - please do not unfix it!).

Perhaps putting a silly made up date on the report is no better than what you have now, but I will leave it to somebody else to provide the correct information. I hate the thought of messing with dates where you have to worry about silly things like leap years. Actually, on a modern mainframe system, it would be much easier to provide the correct information, because there are now system services to get the date without having to worry about leap years, and there is also a service to get the CPU time used.

Now, just for info:

Because you stored the both the assembler and Fortran object code in HERC01.TEST.OBJ, to fix the assembler code, you don't have to re-run the Fortran compile, so you can leave that out (still need the assembly step, of course, and the link). Back in the really old days we tended to avoid unnecessary steps. I can remember one particular assembly (IFOX00) step that we had to run regularly, and it took around 45 minutes, then perhaps the link step would fail when there was nothing wrong with the assembly step, so we quickly learned to keep the object code. No issue now with how long it takes, but if you re-run the whole thing every time, you will sooner discover about the need to compress partitioned data sets.

The blocksize you chose for the object library, 400, is quite small, and you lose quite a lot of space due to gaps between the blocks. Back in the olden daze we used to have tables that you could look up to see what the optimum size was. I  think I used 3200, which might be better than 400, but TBH I did not even check what the device type was (3330 vs 3350 which can make a difference in selecting the very best value). Bigger blocksizes could also allow programs to run faster, but also not somethig to get too concerned about here.

Hope you can get some more out of it. I wouldn't  know how to run anything more than that supplied benchmark.

[ozcar]

MiroS,

After a quick talk to my uncle Google, I can point you to this, which will probably tell you a lot more about IBM 3350 disks than you wanted to know:

http://vtda.org/docs/computing/IBM/Mainframe/Hardware/DataStor/GA26-1638-2_ReferenceManual3350DAS_Apr77.pdf .

On page 11 there is one of those tables like I mentioned. On the top line you can see that strange number I could remember - 19069 which was the maximum track capacity.

From that table:

For block size 400, you get 32 blocks per track, and with 5 records of 80 bytes each in a block, you get 5*32 = 160 records per track.

For block size 3200, you get 5 blocks per track, and with 40 records in a block, you get 40*5 = 200 records per track, so yes, 3200 is a better block size.

You will probably notice that block size 3600 would be even better, because you still get 5 blocks per track, giving 225 records per track.

Having gone that far, how about block size 19040 (just the sort of number you would have thought to use) - only one block per track, but 238 records per track.

Just FYI, I don't expect you to be too worried about all this.

[MiroS]

Hi Ozcar,

Yes, you are right I did not calulate space, just ensure that there will be not small value. I learned that dataset compression is probably not a solution for bigger files. I had to copy PDS a few times after editing, so now I am putting a bigger value by creation.
I removed from card deck all direct placement of UNIT, so I think MVS will select most suitable DASD. I think I will add 2-3  3390 anyway.

[wilfred]

Does the device type make a difference on Hercules emulated DASD? Yes it might be possible to optimise the overhead of emulated I/O channel programs if you have larger blocksizes. But then rather than going for half track as you might on a 3380 or 3390  wouldn't just going 32K suffice?  3330 and 3350 was before my time so I'd go with 3390 just because.

And BTW just to test my memory was 23476 a half track on a 3380 ISTR the track size was around 47 K  and the interblock gap was a bit under 500 bytes, and maybe 57K for a 3390 but that's getting shaky.For a 3390 I have a number a whisker under 29100.

[ozcar]

Does the device type make a difference on Hercules emulated DASD? Yes it might be possible to optimise the overhead of emulated I/O channel programs if you have larger blocksizes. But then rather than going for half track as you might on a 3380 or 3390  wouldn't just going 32K suffice?  3330 and 3350 was before my time so I'd go with 3390 just because.

And BTW just to test my memory was 23476 a half track on a 3380 ISTR the track size was around 47 K  and the interblock gap was a bit under 500 bytes, and maybe 57K for a 3390 but that's getting shaky.For a 3390 I have a number a whisker under 29100.

Wilfred,

You are almost as bad as me, because yes, 23,476 was the maximum size record for 2 on a track on 3380. Strangely, I don't remember that actual number, but I found I have a 3380 Reference Summary here in my collection together with Green Cards of various colours (even a white one which I think was quite rare, but it is not so white anymore). I hate to say even 2311s and 2314s were not before my time, but for those all I remember is the ballpark pack capacities of around 7 and 28 MB.

I first encountered Hercules about twenty years ago! I tinkered a bit with it back then, but I'm not up to date with where they got to, or how far they got with persuading the various old operating systems to handle more modern devices. I just took a look at the TK4- config file, and they have a very strange collection of disk types there - no actual MVS system would have had to contend with mixture covering such a range. It includes everything from 2314 to 3390 (no 2311 though).  I don't know how Hercules stores the data, but from the host system file sizes they must be compressed, or at least they are not storing unused space, so some of the finer points relating to block sizes probably do not matter, other than maybe to avoid small block sizes.

[ozcar]

Perhaps putting a silly made up date on the report is no better than what you have now, but I will leave it to somebody else to provide the correct information.

So, I lied again - I just couldn't leave it like that, so I updated the two assembler routines to return "real" data. Now the report has the date and time it was run on it:

Code: [Select]

****************06/06/20 ************************  SPICE 2G.6    3/15/83 ************************09:23:47****************

Now that it is also printing some actual statistic relating to the run, it is sorta interesting to compare it to their benchmark output from when they ran it in 1983. The "job" which seems to have the taken the longest time was "MOSAMP2 - MOS AMPLIFIER - TRANSIENT" and their run looked like this: 

Code: [Select]

         READIN                    1.83
         SETUP                      .85
         TRCURV                     .00               .
         DCAN                      4.98             17.
         DCDCMP                   4.683              2.
         DCSOL                    3.100
         ACAN                       .00               .
         TRANAN                  159.12            424.
         OUTPUT                    2.12
         LOAD                   141.467
         CODGEN                    .000               .
         CODEXC                    .000
         MACINS                    .000
         OVERHEAD                   .17
         TOTAL JOB TIME          169.07

Most of the numbers there appear to be the CPU times used to perform various phases of the processing but about the only one that I really understand is the "TOTAL JOB TIME".
 
Having changed the "SECOND"  routine to provide actual numbers instead of just zeros, this is what I get for that same "job":

Code: [Select]

         READIN                    0.01
         SETUP                     0.01
         TRCURV                    0.0               0.
         DCAN                      0.03             17.
         DCDCMP                   0.007              2.
         DCSOL                    0.000
         ACAN                      0.0               0.
         TRANAN                    0.99            424.
         OUTPUT                    0.01
         LOAD                     0.848
         CODGEN                   0.002              2.
         CODEXC                   0.025
         MACINS                1600.000
         OVERHEAD                  0.00
         TOTAL JOB TIME            1.05

So, what took them 169 seconds of CPU time on whatever mainframe they had in 1983, took around 1 second on my not-so-recent PC. Some of the figures there are so low, that I thought of changing the "SECOND" routine to return the time is say one-hundredths of a second rather than in seconds, but I did not try that.

This is the assembler code now. I also put the register equates into the source code so that it is not dependent on some macro for that.

[MiroS]

Your changes are working excellent 

On my Raspbian not so  fast , but still quite well  - 15 sec

READIN 0.13
SETUP 0.09
TRCURV 0.0 0.
DCAN 0.36 17.
DCDCMP 0.073 2.
DCSOL 0.003
ACAN 0.0 0.
TRANAN 14.30 424.
OUTPUT 0.14
LOAD 12.282
CODGEN 0.021 2.
CODEXC 0.320
MACINS 1600.000
OVERHEAD 0.01
TOTAL JOB TIME 15.03

Do you know if there is a way to avoid print program listing in printout ?

[ozcar]

Do you know if there is a way to avoid print program listing in printout ?

If you mean the assembly or Fortran program listings, then the obvious way is to just not run those steps. So, submit a job starting with the GO step. Or, like now where you picked up the new assembler code, you would have to run the IFOX00 step, the IEWL link step, and the GO SPICE step. So, no need for the IEYFORT Fortran step, since that code did not change (but with no FORT step, remove COND=(4,LT,FORT) from the link step). Then if you want to run the Spice program again, without changing the assembly or Fortran code, then just run the GO step.   

If you mean you want to get rid of part of the Spice program output, then I'm not sure what you can do. There may be something you can specify in the input to the program itself that determines what it prints, but I don't understand what any of that input means. I do notice that in the JCL for GO step, you have defined two output files for the SPICE program - FT06F001 and FT07F001, which might be because it writes different output to each of those, so you could throw one of those away if you did not want it (in MVS you can code "DUMMY" on a DD to do that). However, I had a quick look at the Fortran code, and it appears to write everything to FT06F001 - I can't see anywhere where it writes to FT07F001, but maybe I just missed it. It would be easy enough to check for sure if it is using both those DD statements - just try taking them out one at a time and see what happens. I don't know where you got the JCL to run the program from, maybe there is something there that I did not see that explains how those two files are used.

Code: [Select]

         READIN                    0.01
         SETUP                     0.01
         TRCURV                    0.0               0.
         DCAN                      0.03             17.
         DCDCMP                   0.007              2.
         DCSOL                    0.000
         ACAN                      0.0               0.
         TRANAN                    0.99            424.
         OUTPUT                    0.01
         LOAD                     0.848
         CODGEN                   0.002              2.
         CODEXC                   0.025
         MACINS                1600.000
         OVERHEAD                  0.00
         TOTAL JOB TIME            1.05

I have no idea what the numbers are that appear on the right side on only some of those lines there. They are obviously not CPU time, because even when our SECOND routine was just returning zero, the reports we were getting had non-zero values for some of them.

We were also getting a non-zero value for "MACINS", which did not change when SECOND was updated to return the actual CPU time. I notice you get the same values for MACINS as I do, like 1600.0 for that last mosfet job, while their benchmark shows 0 ( " .000 "). I looked at the Fortran code to try to see what it really is, and it seems to be somehow related to storage use, but I'm not sure why we would see relatively large numbers, and they have zero.

[MiroS]

I just found that Microcap has 'translate' feature which let export netlist in format of SPICE 2 and  include models for components.

After very minimal changes, like removing LEVEL=1 from all models  and inserting  LIMPTS=10000 into options,   simulation rus smooth and is giving the same results in both.

All in all  that means actually that this old SPICE can be used with modern parts at no problem.

[naturtle]

Just for fun I decided to get this working on my Hercules system. I have always wanted a meaty Fortran program which actually did something useful. Thanks to those who provided updates regarding the Diagnose command in DATTIM and SECOND - I was also getting the S0C2 abends ("privileged operation exception").

I also ran into trouble with the assembler routine "LOC". I then ensured that my module was AMODE 24 and RMODE 24 and now I don't have those problems. PARM.LKED='LIST,CALL,MAP,AMODE=24,RMODE=24'

People raised a question about the "X" and "Y" in column 1. I believe that these are to indicate X and Y co-ordinates.  I modified the following format statements to change the 1HX or 1HY. These are NOT valid carriage control characters and should not be in column 1.
SUBROUTINE   New format
OVTPVT      111 FORMAT(2H Y)
SETPRN      101 FORMAT(2H X/1H )
PLOT      501 FORMAT(2H Y)

I have run the program and compared the output. Apart from some formatting differences like 1.00e+02 becoming 1.00E+02, and  -.0077 becoming -0.0077 I started to run into differences in the TUNNEL DIODE OSCILLATOR area where I am getting different values. I am not concerned, I have proven what I wanted to from getting it working.

I do have access to some assembler DATE and TIME code,  which I may post if I get the time.