Mainframe

Getting closer to a JCL one liner equivalent to Unix head -1.

June 14, 2019 Mainframe , , , , , , , ,

I was somewhat bemused by how much JCL it took to do the equivalent of a couple ‘head -1’ commands.  It was pointed out to me that INDATASET, OUTDATASET can be used to eliminate all the DD lines, and that all but the SYSPRINT DDs for IDCAMS were not actually required.  This allows the JCL for these pair of ‘head -1’ commands to be shortened to:

The REPRO lines still have to be split up because of the annoying punch-card derived 72 column restrictions of JCL. Note that to use OUTDATASET in this way, I had to sacrifice the JCL shell variable expansion that I had been using. To retain my shell variables (SET TID=UT; SET CID=UT128) I still need DDNAME statements to do the shell expansion in JCL proper, since that doesn’t occur in the SYSIN specification.  Translated to Unix, we must think of this sort of SYSIN “file” as being single and not double quoted (unlike a Unix <<EOF…EOF inline file where shell script are expanded).  The JCL is left reduced to:

Note that since I opted to retain the DDNAME statements, the REPRO lines are now short enough to each fit on a single line.

It turns out that there’s also a way to do variable expansion within the SYSIN, essentially treating something like a Unix double quoted script variable.  You need to explicitly export the symbols in the JCL prologue using EXPORT SYMLIST, and then import them in the SYSIN specification using SYMBOLS=CNVTSYS

I’ve switched to IDS and ODS to make the lines shorter, which makes it possible for one of the REPRO lines to be a one liner (with 6 lines of helper code).  The final JCL line count weighs in at 8:2 vs. Unix, but is not as bad as the original JCL I constructed (22 lines.)

JCL equivalent of head -1.

June 12, 2019 Mainframe , , , ,

Suppose you wanted to do the equivalent of the following Unix shell code on the mainframe in JCL:

head -1 < UT128.SYSOUT.EXPECTED > $TID.$CID.SYSOUT.ACT
head -1 < UT128.COBPRINT.EXPECTED > $TID.$CID.COBPRINT.ACT

Here’s the JCL equivalent of this pair of one-liners:

There are probably shorter ways to do this, but the naive way weighs in at 22:2 lines for JCL:Unix — damn!

I can’t help but to add a punny comment that knowing JCL must have once been really good JOB security.

A library discard: ANSI COBOL WITH STRUCTURED PROGRAMMING

February 14, 2019 Mainframe ,

Look what I found for $2 at the public library in the no-longer-circulating discard bin

Can you believe that a book like this wasn’t flying off the shelves and ended up in the for sale box?!

So far I quite like it, as it has a number of examples of bad COBOL style, and what you should do instead.  Example:

Ways to make COBOL source code burn your eyes less are much appreciated.  The first sample above definitely mandates a trip to the eye wash station.

Mainframe development: a story, chapter 1.

April 19, 2018 Mainframe , , , , , , , , , , , , ,

Once upon a time, in a land far from any modern developers, were languages named COBOL and PL/I, which generated programs that were consumed by a beast known as Mainframe. Developers for those languages compiled and linked their applications huddled around strange luminous green screens and piles of hole filled papers while chanting vaguely latin sounding incantations like “Om-padre-JCL-beget-loadmodule-pee-dee-ess.”

In these ancient times, version control tools like git were not available. There was no notion of makefiles, so compilation and link was a batch process, with no dependency tracking, and no parallelism. Developers used printf-style debugging, logging trace information to files.  In order to keep the uninitiated from talking to the Mainframe, files were called datasets.  In order to use graphical editors, developers had to repeatedly feed their source to the Mainframe using a slave named ftp, while praying that the evil demon EBCDIC-conversion didn’t mangle their work. The next day, they could go back and see if Mainframe accepted their offering.

[TO BE CONTINUED.]

Incidentally, as of a couple days ago, I’ve now been working for LzLabs for 2 years.  My work is not yet released, nor announced, so I can’t discuss it here yet, but it can be summarized as really awesome.  I’m still having lots of fun with my development work, even if I have to talk in languages that the beast understands.

My first COBOL program.

November 9, 2017 Mainframe , , , , ,

I recently bought Murach’s COBOL reference:

and coded the chapter 1 compound interest calculation myself before looking at the solution.  I was surprised to see that (n)vim has built in syntax highlighting for COBOL.  It even helps position the comments and line starts in the right places, which was handy.

Having been horrified any time in the past that I saw COBOL code, it feels weird to be coding my own hello-world in the language, but it works, and with ALL CAPS output, it looks sufficiently dinosaur’ish to be COBOL:

./interest 
-----------------------------------------------
TO END PROGRAM, ENTER 0.
ENTER THE INVESTMENT AMOUNT.
1000
ENTER THE NUMBER OF YEARS.
1
ENTER THE INTEREST-RATE.
1
FUTURE-VALUE = 0001010.00
-----------------------------------------------
TO END PROGRAM, ENTER 0.
ENTER THE INVESTMENT AMOUNT.
1000
ENTER THE NUMBER OF YEARS.
2
ENTER THE INTEREST-RATE.
1
FUTURE-VALUE = 0001020.10
-----------------------------------------------
TO END PROGRAM, ENTER 0.
ENTER THE INVESTMENT AMOUNT.
0
END OF SESSION.

Notes and questions:

  • I wasn’t sure about when I had to use statement terminators (.’s) in the ELSE body, so I moved the whole basic block to a helper function.
  • I got messed up initially with the syntax for the PIC values at first, as I’d used .’s instead of V’s to specify that my variables were numeric.  This caused cobc (gnu-cobol front end) to complain that INTEREST-AMOUNT was not numeric, and I eventually found the answer in the PIC table of the book.
  • The point of this exercise was probably to use a loop, which I avoided by calculating the value in one shot.  I’ll have to go back and see how to do that.
  • There doesn’t seem to be any notion of function prototype, and the function bodies can be either before or after their calls.
  • Functions are annoyingly, but appropriately (given the requirement to be over the top verbose for many things), called PARAGRAPHs in COBOL.  I wonder what the mainframe does with name mangling, given that symbol names have to be 8 characters, and COBOL function names are up to 30.  Perhaps only the external entry points (the program-id?), have that restriction?
  • cobc’s implementation of -g sucks, and a debug session shows the lines of the generated .c files instead of the COBOL sources.  There ought to at least be #line markers in the generated C sources instead of comments.