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.