Skip to main content

S0C4 in assembler but it is really weird

  • January 27, 2022
  • 1 reply
  • 0 views
Michael Schmitt

I'm testing Micro Focus Enterprise Developer, and am at the point where I need to execute a stand-alone Assembler program. This program is doing QSAM I/O and is AMODE(24),RMODE(24) on the mainframe.

I thought it would be easier to get it working if I started by executing it through JCL, just like on the mainframe. But the step is ending with a S0C4.

Here's what's weird:

  • The JCL output says it is running AMODE31, which is confirmed by the PSW in the assembler debugger. But, I've got RMODE(24),AMODE(24) set as both compile and link options, as well as setting AMODE370=24 in mf370ctl.cfg. Why is it running amode 31?
  • When I turn on the GTF trace, it does NOT end with a detected program check. It just ends with an instruction.
  • The instruction it ends with changes if I change the GTF trace options! For example, if I add the REG trace, then it ends in the middle of the 2-line register trace! (It prints R0-R7 but not R8-RF), and it is not the same instruction as it does without the REG trace on.
  • From reading the "Significant Changes in Behavior or Usage", I get the impression that it is supposed to intercept S0C4 and then map it into a run-time error, but I'm getting a S0C4 as the step completion code.
  • The JES Log messages are also incomplete: There's the JOB STARTED message, but no message to indicate that the step has ended.

It is like the S0C4 is in Enterprise Developer code, not in my program.

Is stand-alone assembler not supported, i.e. assembler not being called by an application COBOL program?

Would this work better if I executed the assembler from the Windows command line instead of from JCL? That's what I ultimately want to do, but have to deal with the file name mapping issues.

Any other ideas of what's going on here?


#EnterpriseDeveloper
#Assembler

1 reply

Michael Schmitt
  • Michael Schmitt
  • Author
  • Participating Frequently
  • April 1, 2022

I'm testing Micro Focus Enterprise Developer, and am at the point where I need to execute a stand-alone Assembler program. This program is doing QSAM I/O and is AMODE(24),RMODE(24) on the mainframe.

I thought it would be easier to get it working if I started by executing it through JCL, just like on the mainframe. But the step is ending with a S0C4.

Here's what's weird:

  • The JCL output says it is running AMODE31, which is confirmed by the PSW in the assembler debugger. But, I've got RMODE(24),AMODE(24) set as both compile and link options, as well as setting AMODE370=24 in mf370ctl.cfg. Why is it running amode 31?
  • When I turn on the GTF trace, it does NOT end with a detected program check. It just ends with an instruction.
  • The instruction it ends with changes if I change the GTF trace options! For example, if I add the REG trace, then it ends in the middle of the 2-line register trace! (It prints R0-R7 but not R8-RF), and it is not the same instruction as it does without the REG trace on.
  • From reading the "Significant Changes in Behavior or Usage", I get the impression that it is supposed to intercept S0C4 and then map it into a run-time error, but I'm getting a S0C4 as the step completion code.
  • The JES Log messages are also incomplete: There's the JOB STARTED message, but no message to indicate that the step has ended.

It is like the S0C4 is in Enterprise Developer code, not in my program.

Is stand-alone assembler not supported, i.e. assembler not being called by an application COBOL program?

Would this work better if I executed the assembler from the Windows command line instead of from JCL? That's what I ultimately want to do, but have to deal with the file name mapping issues.

Any other ideas of what's going on here?


#EnterpriseDeveloper
#Assembler

I don't know what's going on with the anomalies listed, but I did find the root cause of the abend. I made the assumption that since the documentation says "Assembler support includes performing all file handling by calling the COBOL file handler; this ensures 100% compatibility.", a Line Sequential file in assembler (RECFM=T) would be the same as a Line Sequential file in COBOL.

But they are completely different! In COBOL a Line Sequential file is transparent to the COBOL program; it can process an ASCII text file it as if it was a fixed record length (e.g. RECFM=FB,LRECL=80) EBCDIC file, and the file system does the conversion, including I think tab expansion. But in assembler, Line Sequential is like doing a raw file, except that it breaks the record after the CR/LF. That is, the assembler program gets in a record with the line separators, and as ASCII, not EBCDIC. Needless to say the assembler program was not happy with this.

One reason I was fooled by the Line Assembler issue is that previously I ran the same assembler program compiled with CA-Realia II Workbench, which can run the mainframe assembler program from the command line unmodified, but still reading and writing text files instead of FB 80.  That's because Realia allows the file attributes to be supplied as file "descriptors" in the file name, including in an external file name mapping environment variable.  So if I set variable INDD=MYFILE.TXT[T:RF:L80], it knows that it should read the file as a (line sequential) text file, but convert it to fixed length 80 byte records.

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement