SV: Basic question on passing JCL set symbol to proc

[Thomas Berg]

There seems to be a sort of "on-off" switch 
regarding the substitution of &-variables.  As soon 
as a "substituionable" variable is found any variable 
thereafter is substituted on that "card" (Sic!). 



Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 



 

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
> Skickat: den 9 januari 2010 01:10
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: Basic question on passing JCL set symbol to proc
> 
> On Fri, 8 Jan 2010 15:15:11 -0800, Charles Mills wrote:
> 
> >Thanks. That works too:
> >
> >// SET NIL=
> >// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
> >//*  ...
> >//COMPMAIN EXEC CBCC,CPARM=&NIL'&OPTS'
> >
> Really!?  Because the value of the operand is not 
> _surrounded_ by apostrophes?
> 
> >Weird design.
> >
> Indeed.
> 
> >-Original Message-
> >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
> >Behalf Of Thomas Berg
> >Sent: Thursday, January 07, 2010 5:40 AM
> >
> >I have as a standard a X= parm in most of my procedures 
> (that never has 
> >a value other than "null"):
> >
> >//ANYPROC  PROC  X=,PARM1=,WHATEVER=
> > . . .
> >//STEPNEXEC  PGM=ANYPGM,PARM=&X'&PARM1&WHATEVER'
> > . . .
> >
> But (I say from the doc, without testing) in this case the &X 
> is superfluous, because one of the cases where symbols are 
> substituted within apostrophes is the PARM of the EXEC statement.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 

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

Re: Basic question on passing JCL set symbol to proc

[Charles Mills]

> Really!?  Because the value of the operand is not _surrounded_ by
apostrophes?

Really. 

But it's "started with" that seems to matter, not "surrounded by."

// SET NIL=  
// SET OPTS='NOTEMPL,OE,OBJ,NOARG'   
//* ...  
//PROCLIB JCLLIB ORDER=CBC.SCCNPRC   
//COMPMAIN EXEC CBCC,CPARM='&OPTS'&NIL

fails.  

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

succeeds.   

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Friday, January 08, 2010 4:10 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Basic question on passing JCL set symbol to proc

On Fri, 8 Jan 2010 15:15:11 -0800, Charles Mills wrote:

>Thanks. That works too:
>
>// SET NIL=
>// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
>//*  ...
>//COMPMAIN EXEC CBCC,CPARM=&NIL'&OPTS'
>
Really!?  Because the value of the operand
is not _surrounded_ by apostrophes?
tml

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

Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

On Fri, 8 Jan 2010 15:15:11 -0800, Charles Mills wrote:

>Thanks. That works too:
>
>// SET NIL=
>// SET OPTS='NOTEMPL,OE,OBJ,NOARG'
>//*  ...
>//COMPMAIN EXEC CBCC,CPARM=&NIL'&OPTS'
>
Really!?  Because the value of the operand
is not _surrounded_ by apostrophes?

>Weird design.
>
Indeed.

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
>Of Thomas Berg
>Sent: Thursday, January 07, 2010 5:40 AM
>
>I have as a standard a X= parm in most of my procedures
>(that never has a value other than "null"):
>
>//ANYPROC  PROC  X=,PARM1=,WHATEVER=
> . . .
>//STEPNEXEC  PGM=ANYPGM,PARM=&X'&PARM1&WHATEVER'
> . . .
>
But (I say from the doc, without testing) in this case
the &X is superfluous, because one of the cases where
symbols are substituted within apostrophes is the
PARM of the EXEC statement.

-- gil

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

Re: Basic question on passing JCL set symbol to proc

[Charles Mills]

Thanks. That works too:

// SET NIL=
// SET OPTS='NOTEMPL,OE,OBJ,NOARG' 
//*  ...
//COMPMAIN EXEC CBCC,CPARM=&NIL'&OPTS' 

Weird design.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Thomas Berg
Sent: Thursday, January 07, 2010 5:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: SV: Basic question on passing JCL set symbol to proc

I have as a standard a X= parm in most of my procedures 
(that never has a value other than "null"):

//ANYPROC  PROC  X=,PARM1=,WHATEVER=
 . . .
//STEPNEXEC  PGM=ANYPGM,PARM=&X'&PARM1&WHATEVER'
 . . .
  


Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 

 

 

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Charles Mills
> Skickat: den 4 januari 2010 01:05
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: Basic question on passing JCL set symbol to proc
> 
> 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-m...@bama.ua.edu] On Behalf Of Charles Mills
> Sent: Sunday, January 03, 2010 2:33 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Basic question on passing JCL set symbol to proc
> 
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 

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

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

SV: Basic question on passing JCL set symbol to proc

[Thomas Berg]

I have as a standard a X= parm in most of my procedures 
(that never has a value other than "null"):

//ANYPROC  PROC  X=,PARM1=,WHATEVER=
 . . .
//STEPNEXEC  PGM=ANYPGM,PARM=&X'&PARM1&WHATEVER'
 . . .
  


Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 

 

 

> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] För Charles Mills
> Skickat: den 4 januari 2010 01:05
> Till: IBM-MAIN@bama.ua.edu
> Ämne: Re: Basic question on passing JCL set symbol to proc
> 
> 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-m...@bama.ua.edu] On Behalf Of Charles Mills
> Sent: Sunday, January 03, 2010 2:33 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Basic question on passing JCL set symbol to proc
> 
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to lists...@bama.ua.edu with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Shmuel Metz (Seymour J.)]

In , on 01/04/2010
   at 05:43 PM, Paul Gilmartin  said:

>Does that mean before there were PROCs?  

No.

>PROCs are little use without symbols. 

They were quite useful.

>Or was everything done with overrides?

Yes. As I recall, symbolic parameters came in with OS/360 Release 14.

>For most of what I cited, JCL/initiator exploits it. 

The Initiator runs in Supervisor; Rexx does not.

>That suggests that something is in initiator that would more 
>properly be in allocation.

There's more to Allocation then SVC 99. What's missing is an unprivileged
interface to the Allocation features that are either global or that are
local but have no TU assigned.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[P S]

On Tue, Jan 5, 2010 at 12:25 PM,  wrote:

> According to , Mussolini
> did *not* make the trains run on time.  Interesting how those catch
> phrases become part of common knowledge, true or not.
>

Tsk. You misunderstand the nature of a dictatorship. E.g.:

Stalin, Khruschev and Brezhnev were traveling on a train that had stopped.

Khruschev got up and went to the front of the train.
When he came back he smiled and said, "Will be leaving soon. I have had
engine-driver rehabilitated".

"I will see to it!" said Stalin leaving the compartment.
On his return, he declared, "we go now, I have had engine-driver shot".

Still the train didn't move. Finally Brezhnev stood up and pulled down the
blinds.
"There", he said, "now, train is moving".

:-)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Jack . Hamilton]

According to <http://www.snopes.com/history/govern/trains.asp>, Mussolini 
did *not* make the trains run on time.  Interesting how those catch 
phrases become part of common knowledge, true or not.


--
Jack Hamilton
Management Information & Analysis 
Kaiser Foundation Health Plan, Inc.
1950 Franklin Street, Oakland, California 94612
+1 510 987-1556 (KP tieline 8-427-1556)

NOTE:  This email document and attachments are covered by CA Evidence Code 
§1157 and CA Health and Safety Code §1370.

NOTICE TO RECIPIENT:  If you are not the intended recipient of this 
e-mail, you are prohibited from sharing, copying, or otherwise using or 
disclosing its contents.  If you have received this e-mail in error, 
please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or 
saving them.  Thank you.




P S  
Sent by: IBM Mainframe Discussion List 
01/04/2010 06:48 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Re: [IBM-MAIN] Why is JCL so bad was Re: Basic question on passing JCL set 
symbol to proc





On Mon, Jan 4, 2010 at 9:10 PM, Clark Morris 
wrote:

> The trains were available.
>

...and Mussolini made them run on time!

(OK, I'm guessing that isn't the first time that joke has been made...)

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


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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[P S]

On Mon, Jan 4, 2010 at 9:10 PM, Clark Morris wrote:

> The trains were available.
>

...and Mussolini made them run on time!

(OK, I'm guessing that isn't the first time that joke has been made...)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Clark Morris]

On 4 Jan 2010 15:22:46 -0800, in bit.listserv.ibm-main you wrote:

>In , on 01/03/2010
>   at 11:28 AM, Clark Morris  said:
>
>>JCL was designed for OS360 on a 256K real machine (the original design
>>point for PCP was 64K). 
>
>256 KiB? We ran OS/360 PCP on a 128 KiB machine[1]. With 256 KiB we were
>able to run MFT II for production.
>
>> 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
>
>Why? The TN train was available[2] for the 1403-N1. Did you have only 1443
>printers or 1403 printers older than the Nancy One?

The trains were available.  The management desire for the fastest
print speed dictated the 48 character chain.  I think that it was the
1980's before we got the QNC chain which had 60 characters where 45 of
them were in all of the sets (5 I think) and 15 were scattered 3 to a
set.  The name and exact details are subject to hazy recollection.  In
any case the problems with obtaining the chains were management
objectives and values, not technical ones.
>
>>Lower case was out of the question.
>
>Why?

Low print speed, no programs to take advantage of it and no perceived
business value.
>
>[1] Well, we did IPL on a 64 KiB machine, but not for production.
>
>[2] Yes, it was slower than AN, HN or PN.
> 

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

On Mon, 4 Jan 2010 11:46:20 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>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.
>
Does that mean before there were PROCs?  PROCs are little use
without symbols.  Or was everything done with overrides?

>>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.
>
For most of what I cited, JCL/initiator exploits it.  That
suggests that something is in initiator that would more properly
be in allocation.

-- gil

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Shmuel Metz (Seymour J.)]

In , on 01/03/2010
   at 11:28 AM, Clark Morris  said:

>JCL was designed for OS360 on a 256K real machine (the original design
>point for PCP was 64K). 

256 KiB? We ran OS/360 PCP on a 128 KiB machine[1]. With 256 KiB we were
able to run MFT II for production.

> 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

Why? The TN train was available[2] for the 1403-N1. Did you have only 1443
printers or 1403 printers older than the Nancy One?

>Lower case was out of the question.

Why?

[1] Well, we did IPL on a 64 KiB machine, but not for production.

[2] Yes, it was slower than AN, HN or PN.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Shmuel Metz (Seymour J.)]

In <0377b9a583fd0e4aacd676ee33ee994b2aa61...@sdkmail13.emea.sas.com>, on
01/03/2010
   at 07:01 PM, Lindy Mayfield  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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Shmuel Metz (Seymour J.)]

In , on 01/03/2010
   at 11:08 AM, Paul Gilmartin  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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Shmuel Metz (Seymour J.)]

In , on 01/03/2010
   at 05:56 PM, Paul Gilmartin  said:

>Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing
>QSAM I/O to SYSTSPRT and SYSTSIN?

Because they provide functionality not present in QSAM.

>And JCL and Rexx both leave an undefined symbol as it appeared in 
>the source, with no warning. 

The first is necessary because symbols were an afterthought and IBM
overloaded the & when they added symbols. Both behaviors are actually
useful. 

I take it that you adhere to the philosophy of always enabling NOVALUE in
Rexx?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Frank Swarbrick]

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$ecd299...@org>,
Charles Mills  wrote:
>> >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-m...@bama.ua.edu] On Behalf
> Of Paul Gilmartin
> Sent: Sunday, January 03, 2010 1:51 PM
> To: IBM-MAIN@bama.ua.edu 
> Subject: Re: Why is JCL so bad was Re: Basic question on passing JCL set
> symbol to proc
> 
> On Sun, 3 Jan 2010 19:01:00 +0100, Lindy Mayfield wrote:
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

>>> 

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.

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

Re: Basic question on passing JCL set symbol to proc

[Shmuel Metz (Seymour J.)]

In , on 01/03/2010
   at 12:48 AM, Paul Gilmartin  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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[McKown, John]

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.mck...@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-m...@bama.ua.edu] On Behalf Of Clark Morris
> Sent: Sunday, January 03, 2010 9:28 AM
> To: IBM-MAIN@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:

> 
> 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. 
> >
> >-- gil
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


paulgboul...@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'2' ... and cms kernel "shared code"
moved to start at segment boundary at x'1' (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

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Gerhard Postpischil]

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 




Gerhard Postpischil
Bradford, VT

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Rick Fochtman]

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.

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

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

Re: Basic question on passing JCL set symbol to proc

[Charles Mills]

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-m...@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Sunday, January 03, 2010 2:33 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Basic question on passing JCL set symbol to proc

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

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

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Charles Mills]

>>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-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Sunday, January 03, 2010 1:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why is JCL so bad was Re: Basic question on passing JCL set
symbol to proc

On Sun, 3 Jan 2010 19:01:00 +0100, Lindy Mayfield wrote:

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

Re: Basic question on passing JCL set symbol to proc

[Charles Mills]

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

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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.

-- gil

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Lindy Mayfield]

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Paul Gilmartin
Sent: 3. tammikuuta 2010 23:51
To: IBM-MAIN@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.

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Lindy Mayfield]

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.

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Steve Comstock]

Paul Gilmartin wrote:

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.


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   <==

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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

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

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[P S]

On Sun, Jan 3, 2010 at 10:28 AM, Clark Morris wrote:


> 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?

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

Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Clark Morris]

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

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

Re: Basic question on passing JCL set symbol to proc

[Steve Comstock]

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   <==

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

Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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

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

Re: Basic question on passing JCL set symbol to proc

[Mike La Martina]

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

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

Re: Basic question on passing JCL set symbol to proc

[Shane]

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

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

Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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!

-- gil

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

Re: Basic question on passing JCL set symbol to proc

[Paul Gilmartin]

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

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

Re: Basic question on passing JCL set symbol to proc

[Charles Mills]

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
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Steve Comstock
Sent: Saturday, January 02, 2010 5:38 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Basic question on passing JCL set symbol to proc

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.

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

Re: Basic question on passing JCL set symbol to proc

[Steve Comstock]

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   <==

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

Basic question on passing JCL set symbol to proc

[Charles Mills]

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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html