Basic question on passing JCL set symbol to proc

1286 views
Skip to first unread message

Charles Mills

unread,
Jan 2, 2010, 8:22:16 PM1/2/10
to
I apologize for a very basic question. I'm a developer; not a PROC guy.

I've got a PROC that says

//CBCC PROC INFILE=,

// CRUN=,

// CPARM=,

.

and

//COMPILE EXEC PGM=CCNDRVR,REGION=&CREGSIZ,

// PARM=('&CRUN/CXX &CPARM')

I had the bright idea of coding a SET symbol

// SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG'

And then invoking the proc with

//COMPMAIN EXEC CBCC,CPARM='&OPTS'

Unfortunately, all the program sees is effectively PARM='/CXX &OPTS" - a
literal "&OPTS" rather than my set symbol. I've tried a couple of variations
but to no avail.

How do I pass a set symbol as a parm to a proc?

Thanks and apologies in advance.

Charles Mills


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Steve Comstock

unread,
Jan 2, 2010, 8:39:14 PM1/2/10
to
Charles Mills wrote:
> I apologize for a very basic question. I'm a developer; not a PROC guy.
>
>
>
> I've got a PROC that says
> //CBCC PROC INFILE=,
> // CRUN=,
> // CPARM=,
>
> ..

>
> and
>
> //COMPILE EXEC PGM=CCNDRVR,REGION=&CREGSIZ,
> // PARM=('&CRUN/CXX &CPARM')
>
> I had the bright idea of coding a SET symbol
>
> // SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG'
>
> And then invoking the proc with
>
> //COMPMAIN EXEC CBCC,CPARM='&OPTS'
>
> Unfortunately, all the program sees is effectively PARM='/CXX &OPTS" - a
> literal "&OPTS" rather than my set symbol. I've tried a couple of variations
> but to no avail.
>
>
>
> How do I pass a set symbol as a parm to a proc?
>

//COMPMAIN EXEC CBCC,CPARM=&OPTS

should do it, I would think.

>
>
> Thanks and apologies in advance.
>
>
>
> Charles Mills

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

Charles Mills

unread,
Jan 2, 2010, 9:09:11 PM1/2/10
to
Thanks! That was one of the variations I tried. Fails on a JCL error:

STMT NO. MESSAGE
4 IEFC620I UNIDENTIFIABLE CHARACTER u ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER t ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER c ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER c ON THE EXEC STATEMENT
4 IEFC620I UNIDENTIFIABLE CHARACTER v ON THE EXEC STATEMENT

Charles

//COMPMAIN EXEC CBCC,CPARM=&OPTS

----------------------------------------------------------------------

Paul Gilmartin

unread,
Jan 3, 2010, 1:48:49 AM1/3/10
to
On Sat, 2 Jan 2010 18:08:21 -0800, Charles Mills wrote:

>Thanks! That was one of the variations I tried. Fails on a JCL error:
>

Tough!:

5.4.4.3 "z/OS V1R10.0 MVS JCL Reference"
5.4.4.3 Coding Symbols in Apostrophes

You can code symbols in apostrophes
on the following keywords:
* The DD statement AMP parameter
* The DD statement PATH parameter
* The DD statement SUBSYS parameter
* The EXEC statement ACCT parameter
* The EXEC statement PARM parameter.

(and no other. -- gil)

Your problem in this instance is that JCL makes the colossal
design blunder of interpreting metacharacters _after_
symbol substitution. Rexx, for example, knows better.

I hate JCL!

Whenever I want to do anything serious, I keep my JCL as a
here-document in a POSIX shell script. The designers of shell
gave some consideration to what programmers need to do. The
designers of JCL apparently wanted only to collect their
paychecks and go home on Friday evening.

-- gil

Paul Gilmartin

unread,
Jan 3, 2010, 2:00:52 AM1/3/10
to
On Sat, 2 Jan 2010 17:21:27 -0800, Charles Mills wrote:
>
>//COMPILE EXEC PGM=CCNDRVR,REGION=&CREGSIZ,
>// PARM=('&CRUN/CXX &CPARM')
>
>I had the bright idea of coding a SET symbol
>
>// SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG'
>
>And then invoking the proc with
>
>//COMPMAIN EXEC CBCC,CPARM='&OPTS'
>
>Unfortunately, all the program sees is effectively PARM='/CXX &OPTS" - a
>literal "&OPTS" rather than my set symbol. I've tried a couple of variations
>but to no avail.
>
I might try (although I'm much more likely to suggest you try):

// SET OPTS='LSE(/u/tcc001/v300),NOTEMPL,OE,OBJ,NOARG',
Q=''''

And then invoking the proc with

//COMPMAIN EXEC CBCC,CPARM=&Q&OPTS&Q

This is still guaranteed to fail if the value assigned to &OPTS
contains an apostrophe. You might have to double it again.

I hate JCL!

Shane

unread,
Jan 3, 2010, 2:02:12 AM1/3/10
to
On Sun, 2010-01-03 at 00:48 -0600, Paul Gilmartin wrote:

> Your problem in this instance is that JCL makes the colossal
> design blunder of interpreting metacharacters _after_
> symbol substitution. Rexx, for example, knows better.
>
> I hate JCL!
>
> Whenever I want to do anything serious, I keep my JCL as a
> here-document in a POSIX shell script. The designers of shell
> gave some consideration to what programmers need to do.

Mmmm - I often need to pass (environment/shell) variables through to
called programs via the shell; along with globbing to be resolved by the
called.
Certainly not always intuitive to this little black duck ...

Shane ...

Mike La Martina

unread,
Jan 3, 2010, 8:38:23 AM1/3/10
to
Hi Danny:

Did you know that Windows Media player can slow down music without
changing its pitch?

Google for the instructions.

I don't buy anything from the Andreas site, but I do like her approach
to teaching.

And yes, I was referring to Bill Alexander. I could not recall his name.

Thanks for the complement, but after all we did work together, and did
owe each other professional respect.

I have been on vacation since December 23 and this is my last day. I
have to gear back up for the grind tomorrow.

Lucky you, but luck has little to do with it.

Mike

Paul Gilmartin

unread,
Jan 3, 2010, 9:49:27 AM1/3/10
to
On Sun, 3 Jan 2010 17:01:28 +1000, Shane wrote:
>
>Mmmm - I often need to pass (environment/shell) variables through to
>called programs via the shell; along with globbing to be resolved by the called.
>Certainly not always intuitive to this little black duck ...
>
Example? C-shell or POSIX shell? ", \, or ' always prevent globbing
resolution by the shell. Otherwise shell always resolves globbing
and passes a list of resolved names to the called program.

I don't believe I see you on MVS-OE, although it appears you have a
question that might well be asked there.

Otherwise, this thread has just drifted in another ply far worse
than you or I could ever manage.

-- gil

Steve Comstock

unread,
Jan 3, 2010, 9:53:02 AM1/3/10
to
Paul Gilmartin wrote:
> On Sat, 2 Jan 2010 18:08:21 -0800, Charles Mills wrote:
>
>> Thanks! That was one of the variations I tried. Fails on a JCL error:
>>
> Tough!:
>
> 5.4.4.3 "z/OS V1R10.0 MVS JCL Reference"
> 5.4.4.3 Coding Symbols in Apostrophes
>
> You can code symbols in apostrophes
> on the following keywords:
> * The DD statement AMP parameter
> * The DD statement PATH parameter
> * The DD statement SUBSYS parameter
> * The EXEC statement ACCT parameter
> * The EXEC statement PARM parameter.
>
> (and no other. -- gil)
>
> Your problem in this instance is that JCL makes the colossal
> design blunder of interpreting metacharacters _after_
> symbol substitution. Rexx, for example, knows better.
>
> I hate JCL!
>
> Whenever I want to do anything serious, I keep my JCL as a
> here-document in a POSIX shell script. The designers of shell
> gave some consideration to what programmers need to do. The
> designers of JCL apparently wanted only to collect their
> paychecks and go home on Friday evening.
>
> -- gil

Ah, that's it. The places where I tend to use symbolics
and lower case are in PATH parameters.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------

Clark Morris

unread,
Jan 3, 2010, 10:28:54 AM1/3/10
to
On 3 Jan 2010 06:49:27 -0800, in bit.listserv.ibm-main you wrote:

>On Sun, 3 Jan 2010 17:01:28 +1000, Shane wrote:
>>
>>Mmmm - I often need to pass (environment/shell) variables through to
>>called programs via the shell; along with globbing to be resolved by the called.
>>Certainly not always intuitive to this little black duck ...
>>
>Example? C-shell or POSIX shell? ", \, or ' always prevent globbing
>resolution by the shell. Otherwise shell always resolves globbing
>and passes a list of resolved names to the called program.
>
>I don't believe I see you on MVS-OE, although it appears you have a
>question that might well be asked there.
>
>Otherwise, this thread has just drifted in another ply far worse
>than you or I could ever manage.

JCL was designed for OS360 on a 256K real machine (the original design
point for PCP was 64K). In addition, I suspect that the design was
done by engineers or mathematicians for whom "not and" and "not or"
were familiar concepts. Virtually all of the printers were upper case
only and at least in my shop it was a struggle to get a printer that
printed the special characters correctly (the 48 character train was
adequate FSVO adequate). Lower case was out of the question. Memory
and instruction cycles were at a premium. Even on a 1 megabyte mod 65
we were stingy about region sizes.

While I share your (Paul's) distaste for JCL, the crime is that IBM
hasn't provided a clear migration path for at least new things to
either REXX or one of the shells. It also hasn't provided a migration
path so that we could have longer member names, longer data set names
and a generation data set facility for ESDS data sets. We are stuck
on software architecture that was designed for the limitations of the
original 360's using work arounds and kludges. It is for this reason
that I am not optimistic about the long term viability of the z series
and z/OS.

P S

unread,
Jan 3, 2010, 11:58:57 AM1/3/10
to
On Sun, Jan 3, 2010 at 10:28 AM, Clark Morris <cfmp...@ns.sympatico.ca>wrote:
<snip>

> It is for this reason
> that I am not optimistic about the long term viability of the z series
> and z/OS.
>

Well, zSeries is dead, so it has no long-term viability.

Yes, I'm being pedantic about the terminology -- but if WE don't get it
right, then we don't get to complain when the press farbles something about
mainframes, eh?

Paul Gilmartin

unread,
Jan 3, 2010, 12:09:26 PM1/3/10
to
On Sun, 3 Jan 2010 11:28:18 -0400, Clark Morris wrote:
>
>JCL was designed for OS360 on a 256K real machine (the original design
>point for PCP was 64K). In addition, I suspect that the design was
>done by engineers or mathematicians for whom "not and" and "not or"
>were familiar concepts. Virtually all of the printers were upper case
>only and at least in my shop it was a struggle to get a printer that
>printed the special characters correctly (the 48 character train was
>adequate FSVO adequate). Lower case was out of the question. Memory
>and instruction cycles were at a premium. Even on a 1 megabyte mod 65
>we were stingy about region sizes.
>
The inhomogeneity of JCL syntax is symptomatic of lack of reusable
subroutines. A reusable lexical analysis subroutine would have
alleviated the memory constraint while supporting resolution of
symbols wherever they appear (but perhaps not in SYSIN, which is
a different matter).

Does anyone know a plausible design rationale for the current
restrictions on symbol substitution?

Rather, I ascribe it to Conway's law at its perniciousest. Design
and coding of parsers for the various JCL operands was parceled out
to different programmers. Each could decide independently whether
to support symbol substitution. Since there was (apparently) no
reusable lexical analysis subroutine, support for symbol substitution
would have required considerable extra code in each context, and
was provided only where the need was most urgent.

>While I share your (Paul's) distaste for JCL, the crime is that IBM
>hasn't provided a clear migration path for at least new things to
>either REXX or one of the shells. It also hasn't provided a migration

Rexx, I'd say. Once again, the deficiencies I perceive in Rexx are:

o Lack of a bulk ENQ with WAIT facility to prevent deadlocks, one
thing JCL does well.

o Lack of support for APF authorized subcommands, though this can
mostly be achieved when Rexx runs under the TSO TMP.

o (For me particularly) Lack of support for multi-file tapes by
keyword/constructs such as RETAIN, PASS, and VOL=REF.

>path so that we could have longer member names, longer data set names

The longer names are available in the Unix filesystems. A plausible
migration path would be providing for migration of enterprise data
into Unix filesystems.

>and a generation data set facility for ESDS data sets. We are stuck
>on software architecture that was designed for the limitations of the

>original 360's using work arounds and kludges. It is for this reason

Most of that last is more fundamental than JCL.

>that I am not optimistic about the long term viability of the z series
>and z/OS.
>

I wonder if IBM is listening? I wonder if IBM doesn't see it a
sounder business position to cannibalize rather than nurture z/OS?

-- gil

Steve Comstock

unread,
Jan 3, 2010, 12:40:29 PM1/3/10
to

Cool! I'm working on an utility to do that! In a month or two I
could use some beta testers.


>
>> and a generation data set facility for ESDS data sets. We are stuck
>> on software architecture that was designed for the limitations of the
>> original 360's using work arounds and kludges. It is for this reason
>
> Most of that last is more fundamental than JCL.
>
>> that I am not optimistic about the long term viability of the z series
>> and z/OS.
>>
> I wonder if IBM is listening? I wonder if IBM doesn't see it a
> sounder business position to cannibalize rather than nurture z/OS?
>
> -- gil


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------

Lindy Mayfield

unread,
Jan 3, 2010, 1:01:37 PM1/3/10
to
I transcribed this from a talk given by Fred Brooks, Jr. on the 40th year anniversary of the System 360. This is a wonderful talk given by the people who were involved in the original design, recorded at the Computer History Museum. This is what Fred Brooks said about JCL:

I tell my students, OS/360 Job Control Language is the worst programming language ever designed anywhere by anybody for any purpose and it was done under my management. Why is it? Well, I think there is an important take home lesson for us all in it. One is, it is one job control language for all six of these programming languages. Whereas what you really want is a schedule time operation in whatever language you're working in. Just like you have compile time operations in whatever language you're working in. Then at the very time we were moving the whole world to high level languages, such that at our computing center at Chapel Hill the year after the 360s were operating, only 1 percent of the jobs that ran were assembler, 99 percent were in high level languages, but the JCL was modeled on assembler rather than any of the high level languages. But it wasn't exactly like the assembler. And it was card column dependent. Column 73 was magic. And for years afterwards you sit do!
wn to a terminal and you wonder why column 73. Well it had to do with the fact that the cards on a 701 read in two sets of 36 bits and that used 72 columns. And JCL still preserves this column dependence. JCL was designed to have only six verbs. Well it turns out a schedule time language needs more than six verbs. But it was an article of faith that we were only going to have six verbs and so we put all the verby things into declarations. The DD cards do all the verby things, and parameters. The language has awkward, possible but awkward branching. It has no clean iteration, no for statement. No clean subroutine call. It is not really a good programming language. In fact it is the worst programming language. Now, how did a smart bunch of people get into this mess? This is where the lesson is: We did not see it as a programming language. From the beginning it was seen as a few control cards that would go in front of your deck. Anybody seen a JCL deck recently? They are norma!
lly known as a "dusty" deck. Why is it a dusty deck? Because you get s
omeone else's and you darst not change it. Why is it a deck? Because there are a lot of control cards by the time you get all these DD's and declarations and verby things in. But we didn't see it as a programming language. We saw it as a few control cards. And the other thing is, that it wasn't designed -- we had very good programming language designers, and they designed some very good programming languages, Fortran 6, Fortran H, PL/1, an improved RPG, various other improved programming languages -- but this was not tackled that way. Instead it just grew a parameter here, and a parameter there. So many things were done so right, and every now and then something was really royally messed up with superb competence.

Paul Gilmartin

unread,
Jan 3, 2010, 4:51:59 PM1/3/10
to
On Sun, 3 Jan 2010 19:01:00 +0100, Lindy Mayfield wrote:

>I transcribed this from a talk given by Fred Brooks, Jr. on the 40th
>year anniversary of the System 360. This is a wonderful talk given
>by the people who were involved in the original design, recorded >
at the Computer History Museum. This is what Fred Brooks said about JCL:
>
>I tell my students, OS/360 Job Control Language is the worst
>programming language ever designed anywhere by anybody for any
>purpose and it was done under my management.
>

Don't brag; it's always possible to do worse.

>Whereas what you really want is a schedule time operation in whatever
>language you're working in.
>

Here, I strongly disagree. This is the C-shell blunder. You want
a langage suited to the problem. C-shell attempts to do scripting
with a C-like flavor. JCL attempts to do scheduling with an
assembler-like flavor. Both are misguided in the choice of objective.

>but the JCL was modeled on assembler rather than any of the high
>level languages. But it wasn't exactly like the assembler. And it
>was card column dependent. Column 73 was magic. And for years

>afterwards you sit down to a terminal and you wonder why column

>73. Well it had to do with the fact that the cards on a 701 read
>in two sets of 36 bits and that used 72 columns. And JCL still
>preserves this column dependence.

> ...


>The language has awkward, possible but awkward branching. It has
>no clean iteration, no for statement. No clean subroutine call.
>It is not really a good programming language.
>

Some of this is deliberate. The enterprise run scheduling model
requires things to be static in a scheduler that can be dynamic
in programming languages for other purposes. Its objectives make
JCL more like a macro processor than a programming language, but
it failed to incorporate much of the current assembler's macro
processing capability. And neither JCL nor HLASM conditional
assembly has graceful branching nor clean iteration.

>So many things were done so right, and every now and then something
>was really royally messed up with superb competence.
>

The tragedy is that in 40 years no one undertook to fix it.

-- gil

Lindy Mayfield

unread,
Jan 3, 2010, 5:06:09 PM1/3/10
to
what does he mean by "... a schedule time operation..."? what does that mean?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
Sent: 3. tammikuuta 2010 23:51
To: IBM-...@bama.ua.edu
Subject: Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc


>Whereas what you really want is a schedule time operation in whatever
>language you're working in.
>
Here, I strongly disagree. This is the C-shell blunder. You want
a langage suited to the problem. C-shell attempts to do scripting
with a C-like flavor. JCL attempts to do scheduling with an
assembler-like flavor. Both are misguided in the choice of objective.

----------------------------------------------------------------------

Paul Gilmartin

unread,
Jan 3, 2010, 5:07:29 PM1/3/10
to
On Sun, 3 Jan 2010 10:39:46 -0700, Steve Comstock wrote:
>>
>>> path so that we could have longer member names, longer data set names
>>
>> The longer names are available in the Unix filesystems. A plausible
>> migration path would be providing for migration of enterprise data
>> into Unix filesystems.
>
>Cool! I'm working on an utility to do that! In a month or two I
>could use some beta testers.
>
I fear we're using different semantics for "migration". I was
thinking that Classic data management should have enhanced
capabilities for using Unix files. This is the sense of the PATH=
operand in JCL and the more recent BPAM (read only; no DESERV)
support for z/OS Unix directories. The next big step might be
to have a Unix directory tree replacing the VTOC and catalog, with
Classic CKD data sets as the leaves. This would open the larger
Unix namespace, but provide compatibility and performance of
Classic access methods and EXCP once the data sets were opened.

I suspect you, OTOH, are working on a utility to copy Classic data
sets to Unix files.

Yah, I know either scheme leaves gaps to be filled concerning
security, integrity, and serialization.

-- gil

Paul Gilmartin

unread,
Jan 3, 2010, 5:16:32 PM1/3/10
to
On Sun, 3 Jan 2010 23:05:18 +0100, Lindy Mayfield wrote:

>what does he mean by "... a schedule time operation..."? what does that mean?
>

In the Bad Old Days, the production administrators would provide to
operations a handwritten Run Sheet for each job, specifying resources
such as expected execution time, storage requirements, number of
tape drives, and volumes to be mounted on each. The operators would
arrange these so that at no point were the available resources
overcommitted, the pass them on to the tape ape who would run up and
down the aisles pulling tapes and stacking them on a cart in the order
that jobs would need them.

JCL automated some of this. TMS, JES3 Setup, and automated tape libraries
did more.

Charles Mills

unread,
Jan 3, 2010, 5:34:05 PM1/3/10
to
Sheesh! Thanks all for your input. And to think I thought it was just that I
didn't know what I was doing. I thought one of you would say "you dummy --
you need to double the apostrophes and put it all in parentheses" or
something like that.

I "solved" the problem by splitting it in two. I was able to get the lower
case letters out of there by moving the information to a //SYSLIB DD PATH=
statement. Now the solution to the rest of the problem is just

// SET OPTS=(NOTEMPL,OE,OBJ,NOARG)
. . .
//COMPMAIN EXEC CBCC,CPARM=&OPTS

(In case anyone was wondering why I wanted to take a perfectly good PARM=
parameter and make it into a problematic SET symbol: there are multiple
compile jobsteps in the job and I got tired of changing the compile PARM= in
more than one place. Also, this way I can readily alternatively comment out
or use various sets of compile options. I might also use set symbols for
multiple sets of compile options that I could concatenate together as
appropriate -- but you have to save some fun for another day.)

Charles

Charles Mills

unread,
Jan 3, 2010, 6:25:57 PM1/3/10
to
>>I tell my students, OS/360 Job Control Language is the worst
>>programming language ever designed anywhere by anybody for any
>>purpose and it was done under my management.

>Don't brag; it's always possible to do worse.

I recall that DOS/360 had a series of file-to-file utilities (no device
independence so you needed a disk to tape utility, a card to tape utility, a
tape to disk utility, ...) whose control card syntax was way worse than
OS/360 JCL. DOS/VSE JCL is arguably worse than OS/MVS JCL: the DLBL
statement with its umpteen positional parameters makes the DD statement look
downright user-friendly. And VSE is much more dependent on POWER control
cards than MVS is on JES control cards, and the syntax is totally different
from JCL -- JES statements are at least closer to JCL in syntax.

And anyone else ever write IV-Phase assembler? 5-character symbols, of which
only three (24 bit word machine) were significant, so NOTAG was the same
symbol as NOTUP. And it did not flag duplicates, it just silently redefined
the symbol. Nor did it flag undefined symbols -- just passed them to the
linker as externs. The JCL was pretty bad too ...

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Sunday, January 03, 2010 1:51 PM
To: IBM-...@bama.ua.edu
Subject: Re: Why is JCL so bad was Re: Basic question on passing JCL set
symbol to proc

Paul Gilmartin

unread,
Jan 3, 2010, 6:57:36 PM1/3/10
to
On Sun, 3 Jan 2010 15:25:02 -0800, Charles Mills wrote:
>
>I recall that DOS/360 had a series of file-to-file utilities (no device
>independence so you needed a disk to tape utility, a card to tape utility, a
>tape to disk utility, ...)
>
So that's where CMS got that idea. But z/OS device independence is eroding.
Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing
QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the number of z/OS
utilities that balk at "DD PATH=...", not because their QSAM calls couldn't
perfectly well handle it, but merely because they're afraid to try.

>And anyone else ever write IV-Phase assembler? 5-character symbols, of which
>only three (24 bit word machine) were significant, so NOTAG was the same
>

Someone should have introduced them to RADIX50. But I always disapprove
of quiet truncation.

>symbol as NOTUP. And it did not flag duplicates, it just silently redefined
>the symbol. Nor did it flag undefined symbols -- just passed them to the
>linker as externs.
>

They could have got that idea from C (or perhaps vice-versa). But I
once wrote a very simple minded assembler that flagged duplicate
definitions only if the values differed. And JCL and Rexx both
leave an undefined symbol as it appeared in the source, with no
warning. And POSIX shell expands the containing string as if the
symbol weren't there at all. All irresponsible, IMO.

-- gil

Charles Mills

unread,
Jan 3, 2010, 7:05:36 PM1/3/10
to
CORRECTION. I got seduced by a good return code. The below does not work. I
had to go to Gil's

// SET Q=''''
// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
//COMPMAIN EXEC CBCC,CPARM=&Q&OPTS&Q

Ugly? Whew!

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Sunday, January 03, 2010 2:33 PM
To: IBM-...@bama.ua.edu

Rick Fochtman

unread,
Jan 3, 2010, 7:15:35 PM1/3/10
to
-------------------------------<snip>-------------------------------------------------

So that's where CMS got that idea. But z/OS device independence is
eroding. Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than
just doing QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the
number of z/OS utilities that balk at "DD PATH=...", not because their
QSAM calls couldn't perfectly well handle it, but merely because they're
afraid to try.
------------------------------<unsnip>-------------------------------------------
I've used QSAM, BSAM, TPUT/TGET and PUTLINE/GETLINE quite successfully
for terminal I/O under TSO for a wide variety of applications. Each has
advantages and disadvantages; none is "perfect".

Making generalizations is always a risky process; let's not make them
too widespread. Device independance is alive and well; it just requires
a certain amount for forethought in how the application might be used.
I'm sure that many, if not all, of us have used the so-called "batch
utilities" in the foreground, and some of us have wanted to use
foreground processors in the background. How easy or hard these might be
is very much dependant on the forethought of the designer/coder.

Rick
---
Unless you're the lead dog, the view never changes.

Gerhard Postpischil

unread,
Jan 3, 2010, 7:44:42 PM1/3/10
to
Paul Gilmartin wrote:
>> the symbol. Nor did it flag undefined symbols -- just passed them to the
>> linker as externs.
>>
> They could have got that idea from C (or perhaps vice-versa). But I
> once wrote a very simple minded assembler that flagged duplicate
> definitions only if the values differed. And JCL and Rexx both
> leave an undefined symbol as it appeared in the source, with no
> warning. And POSIX shell expands the containing string as if the
> symbol weren't there at all. All irresponsible, IMO.

I doubt it. Treating undefined as externals was alive and well
on the 709/7090/7094 assemblers.

And it was a feature - none of those wimpy EXTRN/WXTRNs to worry
about <g>

Gerhard Postpischil
Bradford, VT

des...@verizon.net

unread,
Jan 3, 2010, 8:04:01 PM1/3/10
to
PaulGB...@AIM.COM (Paul Gilmartin) writes:

> And neither JCL nor HLASM conditional
> assembly has graceful branching nor clean iteration.

JCL has forward branching thru condition codes and nested procs are a
little like a subroutine call.

HLASM is in another league entirely with forward and backward branching,
loop counts, nesting, arrays, global variables, etc.

What's ungraceful or unclean about HLASM?

Anne & Lynn Wheeler

unread,
Jan 3, 2010, 9:13:25 PM1/3/10
to

PaulGB...@AIM.COM (Paul Gilmartin) writes:
> So that's where CMS got that idea. But z/OS device independence is eroding.
> Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing
> QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the number of z/OS
> utilities that balk at "DD PATH=...", not because their QSAM calls couldn't
> perfectly well handle it, but merely because they're afraid to try.

a lot of CMS design reflects CTSS heritage. CMS then adopted a lot of
os/360 applications ... and therefor had to do a layer of OS/360
simulation (especially for assembler and compilers).

more information ... cp67/cms version 3 (oct70) users guide:
http://www.bitsavers.org/pdf/ibm/360/cp67/GH20-0859-0_CP67_Version_3_Users_Guide_Oct70.pdf

os macros .... pg 294

Later after the moph to vm370/cms (and cambridge monitor system renamed
conversational monitor system) ... there was some amount of DOS
simulation also added. There was also some joke about CMS 32kbyte
os/360 simulation code ... did almost as good as the 8mbyte mvs os/360
simulation code.

The biggest change from cp67/cms to vm370/cms ... was reorging the
kernel with application program loading at x'12000' to take advantage of
(original) 370 (64k) r/o shared segment support. Application programs
then were moved to starting at x'20000' ... and cms kernel "shared code"
moved to start at segment boundary at x'10000' (segment 0 was then data
and non-shared code ... since virtual page zero couldn't be shared, and
therefor virtual segment 0 couldn't be shared).

however, all the effort came to *NOT* ... before the full 370 virtual
memory architecture could be announced and shipped ... retrofitting the
full 370 virtual memory architecture to 370/165 ran into all sorts of
problems. 165 petitioned for dropping several features to gain back a
lot of the schedule; and one of the things dropped was 370 r/o shared
segment support. that forced m370 to quickly come up with a quick&dirty
hack using storage protection keys ... to simulate the original 370
virtual memory r/o segment protect.

with the addition of dos simulation ... for running dos programs in cms
... there then had to be option to specify whether non-cms service
requests went thru os simulation or dos simulation ... aka "set dos on"
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/topic/com.ibm.zvm.v54.dmsa5/hcsd2b00514.htm

in the wake of demise of FS and the head of POK convincing corporate to
kill vm370, shutdown the burlington development group and moving all the
people to POK (justification was that otherwise wouldn't be able to make
mvs/xa ship schedule) .... there was joke that head of POK was major
contributor to vax/vms (i.e. the people that didn't move to pok ... but
went to DEC to work on vax/vms); endicott eventually was able to obtain
the vm370 product mission ... but had to reconstitute the organization
from scratch.

the issue here was that one of the people in burlington (that didn't
move to pok) had done a pretty complete os disk i/o routines for os disk
r/w, vtocs, handle most kinds of files, understood and could process
PDS, etc (aka wasn't os/360 file simulation in cms filesystem, but
supported full os/360 operation on os/360 disks). All of that
evaporated/disappeared with the shutdown of burlington development
group.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

McKown, John

unread,
Jan 4, 2010, 8:22:38 AM1/4/10
to
One thing that, IMO, is keeping JCL in business is shear inertia. Too many times I've had people, especially programmers, resist doing any "unnecessary" clean up of JCL. IMO, all COND processing should be done with the new IF/ELSE/ENDIF construct. But I can't even get them to write new JCL using this, much less convert old JCL ("It works and it's too much trouble to change, test, and run through change control.") They keep cutting and pasting old JCL into new JCL. The same with the newer constructs in COBOL. They like to cut and paste (supposedly) working code.

Relative to this is the internal control blocks created via JCL need to stay the same, or very similar. Why? We couldn't use the new if CA-11 doesn't support it. That is why we don't use UNIX and REXX stuff. CA-11 doesn't support restarting complex shell scripts or REXX programs. I guess doing that would require something akin to checkpoint restart for compiled programs. And who uses that???

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Clark Morris
> Sent: Sunday, January 03, 2010 9:28 AM
> To: IBM-...@bama.ua.edu
> Subject: Why is JCL so bad was Re: Basic question on passing
> JCL set symbol to proc
>

> On 3 Jan 2010 06:49:27 -0800, in bit.listserv.ibm-main you wrote:

<snip>

Shmuel Metz , Seymour J.

unread,
Jan 4, 2010, 9:46:36 AM1/4/10
to
In <LISTSERV%20100103004...@BAMA.UA.EDU>, on 01/03/2010

at 12:48 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:

>Your problem in this instance is that JCL makes the colossal design
>blunder of interpreting metacharacters _after_
>symbol substitution. Rexx, for example, knows better.

There are two ways to design syntax for symbol substitution; expressions
and interpolation. Rexx uses the former, and has no need to recognize
metacharacters inside quoted strings, other than recognizing doubled
framing characters. JCL, like BASH, CLIST, Perl and Script, uses
interpolation. Each approach has advantages and disadvantages.

The blunders in JCL, IMHO, are not in the design but in implementation
details, e.g., the default for SPACE=.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

hanc...@bbs.cpcn.com

unread,
Jan 4, 2010, 10:27:09 AM1/4/10
to
On Jan 3, 9:13 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:

> the issue here was that one of the people in burlington (that didn't
> move to pok) had done a pretty complete os disk i/o routines for os disk
> r/w, vtocs, handle most kinds of files, understood and could process
> PDS, etc (aka wasn't os/360 file simulation in cms filesystem, but
> supported full os/360 operation on os/360 disks). All of that
> evaporated/disappeared with the shutdown of burlington development
> group.

Per the question of the subject line, I believe the original developer
of JCL, Mr. Brooks, himself said it was a lousy language but it was
the best they could do under the circumstances of rushed development
of a complex new idea. ("The birth of a baby will take nine months no
matter how many women are assigned", and "Adding more people to a late
project will only make it later.")

Considering the incredibly many options and internal communications
shortcuts, it is pretty powerful. However, I'd rather spell things
out than depend on backward references, especially in procs, for ease
in understanding. Some of the substitution options in procs can get
confusing.

JCL includes a way to check the 'condition code' of a prior step.
Most of the time it's to see merely that a prior step didn't abend.
But all sorts of convoluted logic can be done on the COND= clause
which are very hard to understand.

Anne & Lynn Wheeler

unread,
Jan 4, 2010, 11:04:11 AM1/4/10
to
hanc...@bbs.cpcn.com writes:
> Per the question of the subject line, I believe the original developer
> of JCL, Mr. Brooks, himself said it was a lousy language but it was
> the best they could do under the circumstances of rushed development
> of a complex new idea. ("The birth of a baby will take nine months no
> matter how many women are assigned", and "Adding more people to a late
> project will only make it later.")

re:
http://www.garlic.com/~lynn/2010.html#22 Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

the thread originated in ibm-main ... and I added in a.f.c. earlier in
the (ibm-main) part of the thread there. can be viewed in google groups:
http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/8fb4c75d62fc6353/b31fc2570a47f078?q=why+is+jcl+so+bad+group:bit.listserv.ibm-main#b31fc2570a47f078

one of the earlier posts (by somebody else) starts out with:

I transcribed this from a talk given by Fred Brooks, Jr. on the 40th
year anniversary of the System 360. This is a wonderful talk given by
the people who were involved in the original design, recorded at the
Computer History Museum. This is what Fred Brooks said about JCL:

... snip ...

and then goes on for a couple paragraphs

Frank Swarbrick

unread,
Jan 4, 2010, 12:51:13 PM1/4/10
to
VSE has better symbolic substitution and much better conditional logic.
--

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403


On 1/3/2010 at 4:25 PM, in message <00fb01ca8ccb$f99b8890$ecd299b0$@org>,

>>>

The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.

Shmuel Metz , Seymour J.

unread,
Jan 4, 2010, 6:21:58 PM1/4/10
to
In <0377B9A583FD0E4AACD6...@sdkmail13.emea.sas.com>, on
01/03/2010

at 07:01 PM, Lindy Mayfield <lindy.m...@SSF.SAS.COM> said:

>This is what Fred Brooks said about JCL:

As in his book, there are statements there that suggest he was not in
touch with his own projects.

>Whereas what you really want is a schedule time operation in whatever
>language you're working in.

That, of course, assumes that the job only uses programs written in a
single language.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------

Shmuel Metz , Seymour J.

unread,
Jan 4, 2010, 6:22:17 PM1/4/10
to
In <LISTSERV%20100103110...@BAMA.UA.EDU>, on 01/03/2010

at 11:08 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:

>Does anyone know a plausible design rationale for the current
>restrictions on symbol substitution?

The fact that things were added after the original design, including
symbols.

>Rather, I ascribe it to Conway's law at its perniciousest. Design and
>coding of parsers for the various JCL operands was parceled out to
>different programmers. Each could decide independently whether to
>support symbol substitution.

Most of the coding was done before there were symbols.

>Once again, the deficiencies I perceive in Rexx are:

OS issues rather than REXX issues. If z/OS had the suuport it would be
easy for Rexx to exploit it.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------