Fortran SPICE for IBM mainframe

[MiroS]

Hello Big Iron fans:)

I have found Fortran version of SPICE2 for IBM mainframe:
https://ptolemy.berkeley.edu/projects/embedded/pubs/downloads/spice/
I refer to  FORTRAN version for  IBM mainframe.
I have problem to make it running on MVS 3.8J ? Maybe someone already successed with this?

[iMo]

Off Topic: FYI - I got the Spice 2G5 (as I can remember) on an 3.5in floppy (aprox 350kB binary) for my Atari 520STM/1MB in 1987 or 88. Worked as expected.

[intabits]

What exactly is the problem?
Do you have a working FORTRAN compiler on this system?
Does the SPICE program compile successfully?
If so, what happens when you run the compiled result?

Are you using using a real IBM mainframe or is this on Hercules?
I don't know my MVS version numbers, but is this an old version of MVS (that can be run on Hercules)?

If you are using Hercules and the problem comes from other than just using the SPICE program, maybe you would get the answers you need if you ask for help in a Hercules forum (and precisely describe the problem)?

[MiroS]

What exactly is the problem?
Do you have a working FORTRAN compiler on this system?
Does the SPICE program compile successfully?
If so, what happens when you run the compiled result?

Are you using using a real IBM mainframe or is this on Hercules?
I don't know my MVS version numbers, but is this an old version of MVS (that can be run on Hercules)?

If you are using Hercules and the problem comes from other than just using the SPICE program, maybe you would get the answers you need if you ask for help in a Hercules forum (and precisely describe the problem)?

FORTRAN compliter work normally, but this should be linked to assembler code.  all in all I wrote JCL script , but end result is bad MVS is crashing with it, not beceuse something bad in with FORTRAN, but doue to my low JCL skills. I had to change single line in assember code 
  S     R10,128         OFF A CHUNK FOR THE O/S =F'32768'
orginaly it was
  S     R10,=F'32768'         OFF A CHUNK FOR THE O/S
but it is rather not the root case, but my JCL, therefore started to look for help

[intabits]

I just Goggled "mvs jcl fortran" and got plenty of hits, including:-

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieac100/xfort.htm

Which compiles a Fortran program, Assembles an assembler routine, and links them together, along with JCL to do that,  and then run the result.

I would think that should get you on the right path.
And just "MVS JCL" will bring up IBM reference manuals that should help answer any questions that might come from the example.

[MiroS]

This is z/OS , I am using MVS 3.8 , older linker and older compiler, which is not bad they match to FRORTAN and assembler,
I tried to 'copy' this an others JCLs, no luck.

[ozcar]

...
 I had to change single line in assember code 
  S     R10,128         OFF A CHUNK FOR THE O/S =F'32768'

How did you get F'32768' down there?

Code: [Select]

l 70. x l(64)                                                                   
000070.  00080000 0000D3B8 040C0000 00042B92               
         00000000 00001004 0002003C 00060011
00090.   000F1000 00000000 00000000 00000000   
         00000000 00000000 20000000 00FE80B8 

[ozcar]

... I am using MVS 3.8

Where did you get it from?

Do you have a SYS2.PROCLIB dataset? If so, have a look for FORT... members in there.

Edit:

Actually, I don't really know what you are looking for at this point. You mention Fortran, but then show some assembly code. If you want to assemble that, have a look in SYS1.PROCLIB for ASMF... procedures (executing program IFOX00).

But to make it clear, you probably don't want to modify that instruction in the way you proposed.

That instruction as you modified it subtracts the content of a fullword at location decimal 128 (hex 80) from R10. That location is within what used to be called FLC (Fixed Low Core), later known as PSA (Prefixed Save Area). There are various locations there as determined by the hardware, and other locations that the operating system may use for whatever purposes it chooses.

If you wanted to subtract decimal 128 from R10 (why?), then:

Code: [Select]

         S     R10,=F'128'   similar to the original instruction
   or
         SH   R10,=H'128'
   or
         LA    R0,128
         SR    R10,R0


[wilfred]

@ozcar is correct with his suggestions regarding the code change. I'd like to know what led you to think such a change is needed. that might help. But can you show the job output with the error messages. 

Not enough to really go on just yet.

[MiroS]

Sure it isnot the way, but other than that all above 128 is causing error in compliation. 
That is JCL for making OBJECT DS whichnext  used in Fortan for  linking

MSZR01U.SPICE.OBJ - File with object, it is actualiy the same as MSZR01U.SPICE.LIB
Program is supposed to be member called SPICE - MSZR01U.SPICE.LOAD(SPICE)
I am first compiling assembler , in next task FORTRAN


//MSZR01U   JOB (AS),'SPICE2 ASM',                                     
//    CLASS=H,MSGCLASS=H,RESTART=ASMF                                   
//*--------------------------------------------------------------------
//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=MSZR01U.SPICE.OBJ,                                   
//             UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,CATLG),               
//          DCB=(RECFM=FB,LRECL=80,BLKSIZE=400)                         
 //SYSIN     DD *                                               
 ADDGEN   CSECT                                                 
 *        CREATE THE SECOND HALFWORD OF AN RX TYPE INSTRUCTION.
...
          END                                                 
 /*                                                           
 //LKED1B  EXEC PGM=IEWL,                                     
 //             PARM='XREF,LIST,LET,TEST,AC=0',               
 //             REGION=1024K                                 
 //SYSLMOD  DD  DSN=MSZR01U.SPICE.LIB,                       
 //             UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,CATLG),   
 //          DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)             
 //SYSUT1   DD  UNIT=WORK,SPACE=(CYL,(8,1))                   
 //SYSPRINT DD  SYSOUT=*                                     
//



This is JCL for FORTAN
//MSZR01U JOB (FORTRAN),'SPICE',REGION=7000K,TIME=1440, 
//    CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),NOTIFY=MSZR01U   
//FORT     EXEC PGM=IEYFORT   
//SYSPRINT DD  SYSOUT=*                                   
//SYSPUNCH DD  SYSOUT=B                                   
//SYSLIB   DD  DSNAME=SYS1.FORTLIB,DISP=SHR               
//SYSLIN   DD  DSNAME=&LOADSET,DISP=(NEW,PASS),UNIT=SYSSQ,
//             SPACE=(80,(900,900),RLSE),DCB=BLKSIZE=80   
//SYSLIN DD  DSNAME=MSZR01U.SPICE.OBJ,DISP=SHR,           
//   UNIT=3350,VOLUME=SER=PUB010                           
//FORT.SYSIN    DD *                           
C SPICE VERSION 2G.6  SCCSID=root.ma 3/15/83   
...
/*                                                           
//LKED EXEC PGM=IEWL,REGION=8000K,                           
//   PARM=(XREF,LET,LIST),COND=(4,LT,FORT)                   
//SYSLIB   DD  DSNAME=SYS1.FORTLIB,DISP=SHR                   
//LKED.SYSLMOD  DD  DSNAME=MSZR01U.SPICE.LOAD(SPICE),         
//             DISP=(MOD,PASS),                               
//             SPACE=(1024,(900,900,1),RLSE),DCB=BLKSIZE=1024,
//             UNIT=3380,VOLUME=SER=PUB012                   
//SYSPRINT DD  SYSOUT=*                                       
//SYSUT1   DD  UNIT=SYSDA,SPACE=(1024,(900,90),RLSE),         
//             DCB=BLKSIZE=1024,DSNAME=&SYSUT1,SEP=SYSLMOD   
//SYSLIN   DD  DSNAME=&LOADSET,DISP=(OLD,PASS)               
//         DD  DSNAME=MSZR01U.SPICE.OBJ,DISP=(OLD,KEEP)       
//         DD  DDNAME=SYSIN                                   
 //GO EXEC PGM=SPICE                             
 //STEPLIB DD DSN=MSZR01U.SPICE.LOAD,DISP=SHR     
 //GO.FT06F001 DD  SYSOUT=*                       
 //GO.FT07F001 DD  SYSOUT=B                       
 //GO.FT05F001 DD  DDNAME=SYSIN                   
 //GO.SYSIN DD *   
 /*
...
 //

Assembler code

...
        FREEMAIN V,A=WHERE1       
        S     R10,128        That was orinaly  =F'32768'   , everything above 128 is reported as error
        BNP   NOSPACE       
        ST    R10,SIZE+4     P
...

I think I should declare something , like relative address or something to avoid error , or long rgister (?)

I think originaly Berkeley distroibuted installation notes and tape, but now only this  file with code  only  left.

I attached spool file with that JCL codes.

[ozcar]

From a very quick look at the assembler source code, the instruction you were messing with is in a CSECT called GTMAIN. The logic there appears to be "obtain the largest chunk of storage possible that will allow 32k bytes to still available for the operating system to use". It does that by initially requesting any length between 8 bytes and (16 Mbytes - 8 bytes). Whatever size it obtains, it immediately releases the storage, and then loads the actual length it got into R10 (so, that was just to determine the maximum size of contiguous storage available). It then subtracts 32K (the F'32768') from the length in R10, and then asks for storage of that size. However if there is not enough storage available (R10 goes negative or zero) then it sets a return code to indicate that there is not enough storage available.

I have no idea how that condition will surface - perhaps it results in a message being issued about storage? It must have done something to draw your attention to that GTMAIN routine? Anyway, the solution is not to decrease the amount of storage it will leave in reserve for the operating system (the 32768), but instead to tell the system that you need more storage (JCL REGION parameter). By the sound of it, you messed around incorrectly subtracting random values located in the PSA until you happened to stumble on a fullword containing zero.

Presumably, the job that you have provided the output for is after you made that (incorrect) modification to stop it complaining about lack of storage? Certainly there is nothing there to draw my attention to lack of storage, instead it tells me that the GO step terminated with code "S0C1" which says that the code somehow tried to execute an invalid instruction (undefined operation code). You need to find out more about that - I suggest you add this:

Code: [Select]

//GO.SYSUDUMP DD SYSOUT=A
I do note that the comments in the GTMAIN routine make reference to "CMS" and there is another routine in there that uses a DIAGNOSE instruction, so perhaps it expects to be running under VM/CMS rather than MVS. You can probably work around that if that is where it is coming unstuck.

Edit:
I happened to notice that the link step complained that the member name already existed in the output dataset, and so it did not replace it. So it looks like you might not be running the version that you just compiled, but a previous one instead. If the previous one had some problems with unresolved references in the link step, that could explain the S0C1.

If you want the link step to replace an existing member, I would omit the member name on the SYSLMOD DD statement, and provide a name via the LKED step SYSLIN:

Code: [Select]

NAME SPICE(R)
The R indicates replace it if is already there.

Or else just delete the member first, or give it another name. TBH it's been so long since I did any of this..........

[wilfred]

@ozcar, Where is the assembler source code?

However I do concur with your analysis. Getting a dump of the error is worthwhile.

I would leave the original code those changes were not the right way to proceed. Best to work the resulting problem.

I've never worked on a VM/CMS system.

I did note message IEW0421 down the bottom of the listing which seems to indicate the module which the JCL expects to be saved in

11 //LKED.SYSLMOD DD DSNAME=MSZR01U.SPICE.LOAD(SPICE)  which is then passed to the GO step which proceeds to EXEC PGM=SPICE

***GO EXEC PGM=*.LKED.SYSLMOD,COND=((4,LT,FORT),(4,LT,LKED))
//GO EXEC PGM=SPICE

can't be saved as SPICE and is instead saved as TEMPNAME

I've sort of forgotten the JCL COND CODE logic now but the LKED step gets CONDCODE=4 which would be better if it was 0.

There is also message
IEF686I DDNAME REFERRED TO ON DDNAME KEYWORD IN PRIOR STEP WAS NOT RESOLVED which probably is the result of the CC=4 on the LKED step.

Essentially you already have a program module called SPICE in the dataset on the LKED.SYSLMOD card.

unless you delete it before trying to create a new one you will need to delete or rename the old SPICE load module (program) first. Or keep changing it to SPICE2,3,4, etc and EXEC PGM=SPICE2,3,4 and so on at least until the program library runs out of space.

Long story short you need to follow @ozcar's advice and collect even more diagnostic information and also ensure you are running the newly created program in the GO step. As it is I think you might be executing the one (SPICE) that already exists in MSZR01U.SPICE.LOAD.

[ozcar]

Wilfred,

I located the source from the link MiroS gave in the first post.

My somewhat hazy recollection is that if you specified a member name on the link SYSLMOD DD statement, then that member could replace an existing member, but maybe I'm mistaken, or maybe that doesn't happen if you specify, as he did, DISP of MOD rather than OLD. My memory of how it worked is likely also tainted by differences between the linkage editor and the "binder" program which replaced it many years later.

For whatever reason, the link step did complain about the member already existing with that IEW0421 warning, which I think is the reason for the return code of 4 for the link step.

I've sort of forgotten the JCL COND CODE logic now but the LKED step gets CONDCODE=4 which would be better if it was 0.

That is for sure something better forgotten!

[MiroS]

Yes if I will forget do delete data set than linker use TEMPNAME, but the code anyway is the same, I experimented with REGION for FORTRAN and for Assembler jobs , but is not doing better, also with (R) the same results.

Maybe that is worth of sharing that MVS is publicly avaible and there is redy to run version called TK4- from http://wotho.ethz.ch/tk4-/. Actualy there are more of distributions, but this TK4- is simply excellent one.  It runs instantly on almost anything -any Linux/Windows/Unix, my 'mainframe' runs on Raspberry better than that real one I have in my memory. download&ready to run. IPL is scrited so  one command ./mvs and all is up after 2-3 minutes. There is also VM/CMS avaible, but I am experimenting with MVS  at this moment only.

[ozcar]

Yes if I will forget do delete data set than linker use TEMPNAME, but the code anyway is the same, I experimented with REGION for FORTRAN and for Assembler jobs , but is not doing better, also with (R) the same results.

So add the SYSUDUMP DD for the GO step and show us where it fails.

Besides the warning about the SPICE member not being replaced there are clues pointing to you maybe not executing the program as you compiled and linked it. The linkage editor output in the job you posted shows this near the end:

Code: [Select]

TOTAL LENGTH 69560
That is the total size of the program in hexadecimal - that comes out as around 421k bytes. However, when you tried to execute it, the step only used 400k:

Code: [Select]

IEF374I STEP /GO / STOP 20152.2100 CPU 0MIN 00.06SEC SRB 0MIN 00.23SEC VIRT 400K SYS 184K
That indicates that you are not executing the program that corresponds to what was linked there, but something smaller. To me that suggests maybe a program from an earlier link attempt, perhaps before you added the SYS1.FORTLIB to the link SYSLIB DD, which would result in the various IHCxxxxx Fortran library routine not being found. The resulting program would be smaller, maybe under 400k, and would get S0C1 when executed (unresolved module address will be zero, resulting in a branch to location zero when something tries to call them, because there is no valid code there to execute). Yes, it could be something else, but my money is on that being the cause.

I still don't see what got you looking at the GTMAIN routine.

[MiroS]

File with SYSUDUMP in  attachement

[ozcar]

I notice that the link shows the program is 8 bytes longer now, so you must have changed something else?

In any event the error you have now is totally different. It has failed trying to load a Fortran library routine (something like a DLL), by name of IHCSTAE. Have a look in SYS1.FORTLIB for this member (or look in any other Fortran libraries that you can find). Wherever you find it, this library must be added to the STEPLIB for the GO step (assume you know how to concatenate libraries - omit the DDNAME on all but the first DD).

I also note that the SYSUDUMP did not work (fortunately we don't need it this time). That is because you coded "DD *" on it (a spool file to be read), rather than the "DD SYSOUT=A" (a spool file to write to) as I had suggested.

I think you are making progress.

[MiroS]

>I notice that the link shows the program is 8 bytes longer now, so you must have changed something else?
Yes, I reverted 128 to 32768 , I simply ignored error , object file is generated, so maybe ignoring  is not  bad idea.

In old days I did plenty of circuit simulations with SPICE on IBM clone (Polish clone), but I simply used cards template taht was given to me. I think that was a common practice with JCL.  I am almost JCL ignorer, I think '*'  is meaning  that queue of JOB is used, as JOB queue is 'A' than I think '*' is replaced with A ?

[ozcar]

>I notice that the link shows the program is 8 bytes longer now, so you must have changed something else?
Yes, I reverted 128 to 32768 , I simply ignored error , object file is generated, so maybe ignoring  is not  bad idea.

That may not really be such a good idea.

Originally, you said this:

FORTRAN compliter work normally, but this should be linked to assembler code.  all in all I wrote JCL script , but end result is bad MVS is crashing with it, not beceuse something bad in with FORTRAN, but doue to my low JCL skills. I had to change single line in assember code 
  S     R10,128         OFF A CHUNK FOR THE O/S =F'32768'
orginaly it was
  S     R10,=F'32768'         OFF A CHUNK FOR THE O/S
but it is rather not the root case, but my JCL, therefore started to look for help

To me, "MVS crashing" means breaking the operating system itself, which is fairly unlikely, so I took that to mean that when you executed your SPICE program, it crashed, or in MVS-talk it ABENDED.

But from what you say now I think that you mean that the assembler (IFOX00) generated an error message for that instruction trying to subtract 32768 from R10. Unfortunately, the job output you have posted does not contain the IFOX00 step, so if that is what you are getting now that you changed the instruction back to what it was, please show us the output showing the error.

This is important, because if the assembler "flags" a statement as an error (not just a warning), it substitutes zeros for the code that it creates for that instruction (you would be able to see that in the hexadecimal version of the code it prints on the left side). Now guess what happens if you ignore that and use the object code is has created? When (if) the program gets to that point it fails because x'00' is not a valid instruction code, and that causes S0C1.

So it  may be that you have had two completely different errors resulting S0C1, unresolved modules in the link step, OR error(s) detected by the assembler. In absence of the SYSUDUMP output, it is impossible to say for sure.

So, show us the assembly listing if there is an error message there, or if no error there, show us the SYSUDUMP output.

Actually, show us the assembly listing even if there is no error there.

[MiroS]

Files contain complete code and JCL -  FORTRAN and assembler.



/17/2007 Spice is covered now covered by the BSD Copyright:

Copyright (c) 1985-1991 The Regents of the University of California.
All rights reserved.

Permission is hereby granted, without written agreement and without license
or royalty fees, to use, copy, modify, and distribute this software and its
documentation for any purpose, provided that the above copyright notice and
the following two paragraphs appear in all copies of this software.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT
OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN
"AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO PROVIDE
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

[wilfred]

What is needed is the actual output listing of the assembly step. The code alone is insufficient.

[MiroS]

Please find job output in attched pdf file, error  is appointed by *** ERROR ***'

[ozcar]

This is the very end of the assembler code as it came from https://ptolemy.berkeley.edu/projects/embedded/pubs/downloads/spice/ :

Code: [Select]

         LM    R14,R12,12(R13)     ERROR RETURN SEQUENCE
         LA    R15,4095
         BR    R14
MAREA    DS    18F
SIZE     DC    F'8'
         DC    X'00FFFFF8'
WHERE1   DS    2F
         LTORG
         DROP
         END

And this is the end of what you submitted:

Code: [Select]

         LM    R14,R12,12(R13)     ERROR RETURN SEQUENCE
         LA    R15,4095
         BR    R14
MAREA    DS    18F
SIZE     DC    F'8'
         DC    X'00FFFFF8'
WHERE1   DS    2F
         DROP
F0       EQU   0
F2       EQU   2
F4       EQU   4
F6       EQU   6
RSTAR4   EQU   2
RSTAR8   EQU   3
CSTAR8   EQU   3
CSTAR16  EQU   4
         END
/*
//LKED1B  EXEC PGM=IEWL,
//             PARM='XREF,LIST,LET,TEST,AC=0',
//             REGION=1024K
//SYSLMOD  DD  DSN=MSZR01U.SPICE.LIB,
//             UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,CATLG),
//          DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)
//SYSUT1   DD  UNIT=WORK,SPACE=(CYL,(8,1))
//SYSPRINT DD  SYSOUT=*
//

So you have added JCL to link it there (you could have just stored the object code, but turning it into a load module like you did is also OK).

However, you have also changed the assembler code. For a start, you have put equates for some registers there. Maybe fair enough to do this if you could not find the macro used in the original source (maybe that was the "REGEQU" near the top).

Not so good is that you have deleted the "LTORG" that was in the original source. LTORG = "Literal Origin" - it tells the assembler where to put the "literal pool", and the literal pool is where the assembler puts constants declared using the "=" sign - so constants like the =F'36768' that you became acquainted with. If you don't tell the assembler where to put them, it makes up it's own mind (yes, there are some rules), and where it has put it is after the "DROP" statement, so you have lost addressability to the =F'32768". It causes an error like this:

Code: [Select]

      IFO209      ADDRESSABILITY ERROR- BASE AND DISPLACEMENT CANNOT BE RESOLVED AND ARE SET TO 0
And yes, the code generated for that will be four bytes of zeros which will cause S0C1.

Put the LTORG back, and you should make progress.

[wilfred]

@ozcar. Nice work.

[MiroS]

Put the LTORG back, and you should make progress.

Thanks, it really helped with assembler!
Spice is still dumping. I attached files for  both jobs.

[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.