Discussion:
Using JCL Symbld and TYPRUN=SCAN
Add Reply
Gadi Ben-Avi
2018-06-20 05:58:35 UTC
Reply
Permalink
Raw Message
Hi,

I am trying to create a procedure that receives parameters and then uses the values as the input for some steps.
This is part of the procedure.
//DOALL PROC LVL4=LVL4,PART=PART
// EXPORT SYMLIST=(LVL4,PART)
// SET LVL4=&LVL4
// SET PART=&PART
//DEL EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//X DD SYSOUT=X
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
SET MAXCC = 0
//DOALL PEND

When I tried running this using
//G110FT24 JOB (00),'GET',CLASS=X,MSGCLASS=X,PRTY=9,
// NOTIFY=&SYSUID TYPRUN=SCAN
// JCLLIB ORDER=(SYSG.DB2.UNLOAD)
//D1 EXEC DOALL,LVL4=PKVS1073,PART=PART1

The variables in the IDCAMS DELETE statement were not substituted.
When I ran the job without TYPRUN=SCAN, the variables were substituted.

Is there a way to have the variables get substituted, without actually running the job.

This is running in z/OS v2.2

Gadi
????? ?? ????? ???? ???? ???? ?????? ??? ??? ?????? ???? ????? ??? ?????? ??????. ?? ????, ???????? ?? ??? ???? ?????, ??????? ???? ???? ????? ?? ??? ????? ?????? ?? ?????. ????? ????? ???? ?? ?????? ?????? ?????? ???? ?? ???? ??????? ??? ???, ?/?? ?????, ????? ?? ????? ????? ????? ????? ?????? ?? ????? ??????? ?/?? ?????? ?? ??????.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-06-20 07:32:14 UTC
Reply
Permalink
Raw Message
Post by Gadi Ben-Avi
The variables in the IDCAMS DELETE statement were not substituted.
When I ran the job without TYPRUN=SCAN, the variables were substituted.
Is there a way to have the variables get substituted, without actually running the job.
No. This is both WAD and BAD. In the JCL Ref this is stated, 'TYPRUN=SCAN checks the JCL only through the converter, not the interpreter.'
Post by Gadi Ben-Avi
This is running in z/OS v2.2
And older versions too. One thread about this same problem was around July 2012 where with TYPRUN=SCAN, you could not see the SYSIN contents unless you use INPUT ON and then use ST in SDSF.
Post by Gadi Ben-Avi
TYPRUN=SCAN is only JCL checking and so will not really "show" the output of the SYSIN.
TYPRUN=SCAN's "checking" is a bad joke. IIRC, it fails to report errors as fundamental as DSNAME >44 characters.
Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gadi Ben-Avi
2018-06-20 07:52:37 UTC
Reply
Permalink
Raw Message
Thanks,
Do you know of a way to check the parameter substitution in DD *?
Gadi

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Elardus Engelbrecht
Sent: Wednesday, June 20, 2018 10:32 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Post by Gadi Ben-Avi
The variables in the IDCAMS DELETE statement were not substituted.
When I ran the job without TYPRUN=SCAN, the variables were substituted.
Is there a way to have the variables get substituted, without actually running the job.
No. This is both WAD and BAD. In the JCL Ref this is stated, 'TYPRUN=SCAN checks the JCL only through the converter, not the interpreter.'
Post by Gadi Ben-Avi
This is running in z/OS v2.2
And older versions too. One thread about this same problem was around July 2012 where with TYPRUN=SCAN, you could not see the SYSIN contents unless you use INPUT ON and then use ST in SDSF.
Post by Gadi Ben-Avi
TYPRUN=SCAN is only JCL checking and so will not really "show" the output of the SYSIN.
TYPRUN=SCAN's "checking" is a bad joke. IIRC, it fails to report errors as fundamental as DSNAME >44 characters.
Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sri h Kolusu
2018-06-20 16:05:59 UTC
Reply
Permalink
Raw Message
Post by Gadi Ben-Avi
Do you know of a way to check the parameter substitution in DD *?
If you are interested to see the symbol substitution then you can use the
EZACFSM1 symbol translator utility. Once you have verified the symbols are
substituted correctly then you can route that to a dataset and use that as
input sysin to your IDCAMS step.

Here is an example.

//DOALL PROC LVL4=LVL4,PART=PART
// EXPORT SYMLIST=(LVL4,PART)
// SET LVL4=&LVL4
// SET PART=&PART
//*
//STEP0100 EXEC PGM=EZACFSM1
//SYSOUT DD SYSOUT=*
//SYSIN DD DATA,DLM=@@,SYMBOLS=JCLONLY
DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
SET MAXCC = 0
@@
//DOALL PEND
//D1 EXEC DOALL,LVL4=PKVS1073,PART=PART1

Thanks,
Kolusu


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Alan Young
2018-06-20 08:13:24 UTC
Reply
Permalink
Raw Message
I have had to do the indirection described in this document to make it work.



http://www-01.ibm.com/support/docview.wss?uid=isg1OA47958


Alan

________________________________
From: Gadi Ben-Avi <***@MALAM.COM>
Sent: Tuesday, June 19, 2018 22:59
To: IBM-***@LISTSERV.UA.EDU
Subject: Using JCL Symbld and TYPRUN=SCAN

Hi,

I am trying to create a procedure that receives parameters and then uses the values as the input for some steps.
This is part of the procedure.
//DOALL PROC LVL4=LVL4,PART=PART
// EXPORT SYMLIST=(LVL4,PART)
// SET LVL4=&LVL4
// SET PART=&PART
//DEL  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//X DD SYSOUT=X
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
SET MAXCC = 0
//DOALL PEND

When I tried running this using
//G110FT24 JOB (00),'GET',CLASS=X,MSGCLASS=X,PRTY=9,
// NOTIFY=&SYSUID TYPRUN=SCAN
// JCLLIB ORDER=(SYSG.DB2.UNLOAD)
//D1 EXEC DOALL,LVL4=PKVS1073,PART=PART1

The variables in the IDCAMS DELETE statement were not substituted.
When I ran the job without TYPRUN=SCAN, the variables were substituted.

Is there a way to have the variables get substituted, without actually running the job.

This is running in z/OS v2.2

Gadi
????? ?? ????? ???? ???? ???? ?????? ??? ??? ?????? ???? ????? ??? ?????? ??????. ?? ????, ???????? ?? ??? ???? ?????, ??????? ???? ???? ????? ?? ??? ????? ?????? ?? ?????. ????? ????? ???? ?? ?????? ?????? ?????? ???? ?? ???? ??????? ??? ???, ?/?? ?????, ????? ?? ????? ????? ????? ????? ?????? ?? ????? ??????? ?/?? ?????? ?? ??????.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-06-20 10:53:14 UTC
Reply
Permalink
Raw Message
Post by Gadi Ben-Avi
Do you know of a way to check the parameter substitution in DD *?
Easy, a quick and dirty trick I sometimes do is this little change:

//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
SET MAXCC = 0

to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in a JCL comment):

//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0

Just submit that step (with or without TYPRUN) and if you see the substition is right, then submit the whole job with the correct SYSIN contents.

That is a mild, but clean PITA... ;-D

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gadi Ben-Avi
2018-06-20 11:46:48 UTC
Reply
Permalink
Raw Message
That's a good way to bypass it
Thanks

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Elardus Engelbrecht
Sent: Wednesday, June 20, 2018 1:53 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Post by Gadi Ben-Avi
Do you know of a way to check the parameter substitution in DD *?
Easy, a quick and dirty trick I sometimes do is this little change:

//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
SET MAXCC = 0

to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in a JCL comment):

//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0

Just submit that step (with or without TYPRUN) and if you see the substition is right, then submit the whole job with the correct SYSIN contents.

That is a mild, but clean PITA... ;-D

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-06-21 00:45:15 UTC
Reply
Permalink
Raw Message
Post by Gadi Ben-Avi
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
SET MAXCC = 0
//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0
Unfortunately that may not work because the symbols in SYSIN are not
substituted the same way as in the regular JCL. I have been playing
around with them and my conclusion is that the whole feature seems to
have been badly thought out.

- Symbols in in stream data are not necessarily substituted with the
same value as the same symbol in the JCL of the same step
- Symbols "leak" from step to step and from PROCs into the main JCL, so
if you modify or add a symbol in a PROC you can break subsequent steps
in any job that calls that PROC.

If IBM had omitted some features, e.g. system symbols on the execution
system and instead substituted the symbols at the same time as the
symbols in the rest of the JCL, they would have lost maybe 10% of the
usefulness but decreased the astonishment by 90%.

The good news is that the syntax probably allows an easy fix in a new
version: a new value such as SYMBOLS=(JCLCNVT) where symbols are
substituted at the same time with the same logic as the rest of the JCL.

Please IBM?
--
Andrew Rowley
Black Hill Software
+61 413 302 386

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-06-20 11:30:24 UTC
Reply
Permalink
Raw Message
Post by Gadi Ben-Avi
Post by Gadi Ben-Avi
Do you know of a way to check the parameter substitution in DD *?
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
SET MAXCC = 0
//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0
Just submit that step (with or without TYPRUN) and if you see the substition is right, then submit the whole job with the correct SYSIN contents.
What I wrote is not always 100% correct, sorry.

I must also added, that if substition test is not working, I just submit a IEFBR14 job with the real DD (not in comments) and watch out for any 'IEFC653I SUBSTITUTION JCL' messages.

PS: I don't have a JCL scanner product or something like that which could make your TYPRUN=SCAN and SYSIN easier.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-06-20 17:26:23 UTC
Reply
Permalink
Raw Message
If you are interested to see the symbol substitution then you can use the EZACFSM1 symbol translator utility.
My oh my! That is amazing!

Where is that EZACFSM1 thing documented?

I really appreciate your most helpful reply. I am really humbled by your kind reply. I believe all in IBM-MAIN would also be grateful for your post.

Thanks again!

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bill Ashton
2018-06-20 17:27:51 UTC
Reply
Permalink
Raw Message
I learned something very useful here...thanks, Kolusu!

On Wed, Jun 20, 2018 at 1:26 PM Elardus Engelbrecht <
Post by Sri h Kolusu
Post by Sri h Kolusu
If you are interested to see the symbol substitution then you can use the
EZACFSM1 symbol translator utility.
My oh my! That is amazing!
Where is that EZACFSM1 thing documented?
I really appreciate your most helpful reply. I am really humbled by your
kind reply. I believe all in IBM-MAIN would also be grateful for your post.
Thanks again!
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Thank you and best regards,
*Billy Ashton*

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-06-20 17:42:31 UTC
Reply
Permalink
Raw Message
Yes, thank you so very much Sri!

It is apparently documented in "z/OS Communications Server: IP Configuration Guide":

z/OS 2.1:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/ip_mvs_system_symbols.htm

z/OS 2.2:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/ip_mvs_system_symbols.htm

z/OS 2.3:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm

Heck of a place to hide such a useful little utility. Why not at least a reference in the JCL reference manual or at least in the JCL User's Guide? No application programmer would ever even accidentally find it in the CS manuals, they would never think to look there.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: Wednesday, June 20, 2018 1:26 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Using JCL Symbld and TYPRUN=SCAN

EXTERNAL EMAIL
If you are interested to see the symbol substitution then you can use the EZACFSM1 symbol translator utility.
My oh my! That is amazing!

Where is that EZACFSM1 thing documented?

I really appreciate your most helpful reply. I am really humbled by your kind reply. I believe all in IBM-MAIN would also be grateful for your post.

Thanks again!

Groete / Greetings
Elardus Engelbrecht

--


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sri h Kolusu
2018-06-20 17:51:04 UTC
Reply
Permalink
Raw Message
Post by Elardus Engelbrecht
Where is that EZACFSM1 thing documented?
Elardus,

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm

I used to use the program EZACFSM1 before the EXPORT enhancements came in
as it supports both static and dynamic symbols.

sample

//STEP0100 EXEC PGM=EZACFSM1
//SYSOUT DD SYSOUT=*
//SYSIN DD DATA,DLM=@@
CURRENT DATE IS : &LYYMMDD
CURRENT JULIAN DAY OF YEAR IS : &LJDAY
CURRENT DAY OF THE WEEK IS : &LWDAY
CURRENT YEAR IS : &LYR4
CURRENT DAY IS : &LDAY
CURRENT MONTH IS : &LMON
CURRENT TIME IS : &LHHMMSS
CURRENT HOUR IS : &LHR
CURRENT MINUTE IS : &LMIN
CURRENT SECONDS IS : &LSEC
CURRENT JOBNAME IS : &JOBNAME
@@


Thanks,
Kolusu
Post by Elardus Engelbrecht
Date: 06/20/2018 10:27 AM
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Post by Sri h Kolusu
If you are interested to see the symbol substitution then you can
use the EZACFSM1 symbol translator utility.
My oh my! That is amazing!
Where is that EZACFSM1 thing documented?
I really appreciate your most helpful reply. I am really humbled by
your kind reply. I believe all in IBM-MAIN would also be grateful
for your post.
Thanks again!
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-06-20 18:48:47 UTC
Reply
Permalink
Raw Message
Well, I think "amazing" may be a bit much. Maybe EZACFMS1 predates DD
SYMBOLS=, but it's pretty easy to just use it:

// EXEC PGM=IEBGENER
//SYSUT1 DD DATA,SYMBOLS=EXECSYS
...your job here
/*
//SYSUT2 DD SYSOUT=*

sas
Post by Sri h Kolusu
Post by Elardus Engelbrecht
Where is that EZACFSM1 thing documented?
Elardus,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.
0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm
I used to use the program EZACFSM1 before the EXPORT enhancements came in
as it supports both static and dynamic symbols.
sample
//STEP0100 EXEC PGM=EZACFSM1
//SYSOUT DD SYSOUT=*
CURRENT DATE IS : &LYYMMDD
CURRENT JULIAN DAY OF YEAR IS : &LJDAY
CURRENT DAY OF THE WEEK IS : &LWDAY
CURRENT YEAR IS : &LYR4
CURRENT DAY IS : &LDAY
CURRENT MONTH IS : &LMON
CURRENT TIME IS : &LHHMMSS
CURRENT HOUR IS : &LHR
CURRENT MINUTE IS : &LMIN
CURRENT SECONDS IS : &LSEC
CURRENT JOBNAME IS : &JOBNAME
@@
Thanks,
Kolusu
Post by Elardus Engelbrecht
Date: 06/20/2018 10:27 AM
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Post by Sri h Kolusu
If you are interested to see the symbol substitution then you can
use the EZACFSM1 symbol translator utility.
My oh my! That is amazing!
Where is that EZACFSM1 thing documented?
I really appreciate your most helpful reply. I am really humbled by
your kind reply. I believe all in IBM-MAIN would also be grateful
for your post.
Thanks again!
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Windt, W.K.F. van der , Fred
2018-06-21 05:56:14 UTC
Reply
Permalink
Raw Message
Post by Steve Smith
Well, I think "amazing" may be a bit much. Maybe EZACFMS1 predates DD
// EXEC PGM=IEBGENER
//SYSUT1 DD DATA,SYMBOLS=EXECSYS
...your job here
/*
//SYSUT2 DD SYSOUT=*
Or just use the logging-DDname option of the SYMBOLS= parameter. Then you don't even need an additional step in the JCL:

//SYSIN DD *,SYMBOLS=(JCLONLY,TRACEDD)
Input with variables...
/*
//TRACEDD SYSOUT=*

-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2018-06-20 21:35:17 UTC
Reply
Permalink
Raw Message
I think the upshot here is that support for symbols in *data* is a function of the program being executed. The 'system' will resolve symbols encountered in JCL, but the 'application' has to resolve symbols read from, say, SYSIN. That's why TYPRUN=SCAN will not show resolved symbols in data: the program is not actually executed. Whether it's EZACFSM1 or IEBGENER, the program has to run in order to resolve symbols.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Wednesday, June 20, 2018 11:49 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Using JCL Symbld and TYPRUN=SCAN

Well, I think "amazing" may be a bit much. Maybe EZACFMS1 predates DD SYMBOLS=, but it's pretty easy to just use it:

// EXEC PGM=IEBGENER
//SYSUT1 DD DATA,SYMBOLS=EXECSYS
...your job here
/*
//SYSUT2 DD SYSOUT=*

sas
Post by Sri h Kolusu
Post by Elardus Engelbrecht
Where is that EZACFSM1 thing documented?
Elardus,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.
0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm
I used to use the program EZACFSM1 before the EXPORT enhancements came
in as it supports both static and dynamic symbols.
sample
//STEP0100 EXEC PGM=EZACFSM1
//SYSOUT DD SYSOUT=*
CURRENT DATE IS : &LYYMMDD
CURRENT JULIAN DAY OF YEAR IS : &LJDAY
CURRENT DAY OF THE WEEK IS : &LWDAY
CURRENT YEAR IS : &LYR4
CURRENT DAY IS : &LDAY
CURRENT MONTH IS : &LMON
CURRENT TIME IS : &LHHMMSS
CURRENT HOUR IS : &LHR
CURRENT MINUTE IS : &LMIN
CURRENT SECONDS IS : &LSEC
CURRENT JOBNAME IS : &JOBNAME
@@
Thanks,
Kolusu
Post by Elardus Engelbrecht
Date: 06/20/2018 10:27 AM
Subject: Re: Using JCL Symbld and TYPRUN=SCAN Sent by: IBM Mainframe
Post by Sri h Kolusu
If you are interested to see the symbol substitution then you can
use the EZACFSM1 symbol translator utility.
My oh my! That is amazing!
Where is that EZACFSM1 thing documented?
I really appreciate your most helpful reply. I am really humbled by
your kind reply. I believe all in IBM-MAIN would also be grateful
for your post.
Thanks again!
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-06-20 22:35:12 UTC
Reply
Permalink
Raw Message
Actually, the upshot is exactly not that. Symbols in SYSIN are always
resolved when requested by SYMBOLS=. The program that reads that SYSIN
never sees any symbols.

The 2nd parm of SYMBOLS is a DDname for a substitution report. I would
have assumed you'd get that regardless, but evidently, the SYSIN file has
to be OPENed to get the substitution report.

sas
Post by Jesse 1 Robinson
I think the upshot here is that support for symbols in *data* is a
function of the program being executed. The 'system' will resolve symbols
encountered in JCL, but the 'application' has to resolve symbols read from,
the program is not actually executed. Whether it's EZACFSM1 or IEBGENER,
the program has to run in order to resolve symbols.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-06-20 23:02:33 UTC
Reply
Permalink
Raw Message
Post by Steve Smith
Actually, the upshot is exactly not that. Symbols in SYSIN are always
resolved when requested by SYMBOLS=. The program that reads that SYSIN
never sees any symbols.
The 2nd parm of SYMBOLS is a DDname for a substitution report. I would
have assumed you'd get that regardless, but evidently, the SYSIN file has
to be OPENed to get the substitution report.
I suspect that substitution is lazy, performed at the last possible moment.
For example if the SYSIN is in a PROC called multiple times with different
values of a symbol in effect, won't different executions show those different
values substituted?

Even more, it's possible to cause a (simulated) I/O error if substitution causes
an overlong line. Will lines prior to that point be read correctly?
Post by Steve Smith
Post by Jesse 1 Robinson
I think the upshot here is that support for symbols in *data* is a
function of the program being executed. The 'system' will resolve symbols
encountered in JCL, but the 'application' has to resolve symbols read from,
We might quibble about the distinction between 'system' and 'application'.
I believe the substitution is done by the access method or JES. Is that
'system' or 'application'?
Post by Steve Smith
Post by Jesse 1 Robinson
the program is not actually executed. Whether it's EZACFSM1 or IEBGENER,
the program has to run in order to resolve symbols.
TYPRUN=SCAN is a farce; increasingly so as new features appear in JCL and
SCAN (SCAM?) fails to accommodate them. But it never reported things as basic
as overlong qualifiers in data set names.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-06-21 02:28:18 UTC
Reply
Permalink
Raw Message
Unfortunately [ ... ] the symbols in SYSIN are not
substituted the same way as in the regular JCL. I have been playing
around with them and my conclusion is that the whole feature seems to
have been badly thought out.
Yes.
- Symbols in in stream data are not necessarily substituted with the
same value as the same symbol in the JCL of the same step
o First, PROCs are expanded by the converter at the point of EXEC PRC=...

o Then, symbols in JCL statements are resolved to the last value assigned
before the point of reference.

o Symbols in SYSIN are resolved to the last value assigned before the next
EXEC PGM... statement. Those steeped in MVS internals ("Kool-Aid") say
this makes perfect sense. To normal people it's utter nonsense.
- Symbols "leak" from step to step and from PROCs into the main JCL, so
if you modify or add a symbol in a PROC you can break subsequent steps
in any job that calls that PROC.
I believe that symbols assigned values in a PROC statement or in EXEC PRC=
are local to that PROC (and its children?) Symbols assigned values in a SET
statement within a PROC are global. Ugh! It may be better to eschew SET
within a PROC; rather supply default values in the PROC header.
If IBM had omitted some features, e.g. system symbols on the execution
system and instead substituted the symbols at the same time as the
symbols in the rest of the JCL, they would have lost maybe 10% of the
usefulness but decreased the astonishment by 90%.
Be careful. If the SYSIN appears within a PROC and different symbol values
are in effect at various EXEC PRC=... statements, multiple copies of that
SYSIN might need to be supplied for the various proc steps. But the effect
could be realized by passing along with each reference to that SYSIN a list
of name-value pairs of symbols used in that SYSIN, with the values at the
point //SYSIN DD * appears in the JCL source.
The good news is that the syntax probably allows an easy fix in a new
version: a new value such as SYMBOLS=(JCLCNVT) where symbols are
substituted at the same time with the same logic as the rest of the JCL.
Please IBM?
They'd only need to do it right.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-06-21 07:30:51 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
I believe that symbols assigned values in a PROC statement or in EXEC PRC=
are local to that PROC (and its children?) Symbols assigned values in a SET
statement within a PROC are global. Ugh! It may be better to eschew SET
within a PROC; rather supply default values in the PROC header.
Symbols in a PROC header don't work consistently. SET is required for
predictable behaviour.

//PROC1     PROC VVV=
//          EXPORT SYMLIST=VVV
//PSTEP1    EXEC PGM=IEBGENER
//SYSPRINT  DD   DUMMY
//SYSIN     DD   DUMMY
//SYSUT1    DD *,SYMBOLS=JCLONLY
SYMBOL VVV=&VVV
/*
//SYSUT2    DD   SYSOUT=*
//          PEND
//JSTEP1    EXEC PROC1,VVV=VALUE1
//JSTEP2    EXEC PROC1,VVV=VALUE2

gives IEFC657I THE SYMBOL VVV WAS NOT USED for the first step, but not
subsequent steps (occurring after the first proc's EXPORT SYMLIST=VVV).
If symbol VVV is used in the JCL:

//PROC1     PROC VVV=VPWRKA
//          EXPORT SYMLIST=VVV
//PSTEP1    EXEC PGM=IEBGENER
//SYSPRINT  DD   DUMMY
//SYSIN     DD   DUMMY
//SYSUT1    DD *,SYMBOLS=JCLONLY
SYMBOL VVV=&VVV
/*
//SYSUT2    DD   SYSOUT=*
//DD1       DD   DISP=(OLD,DELETE),UNIT=SYSDA,VOL=SER=&VVV
//          PEND
//JSTEP1    EXEC PROC1,VVV=VPWRKB
//JSTEP2    EXEC PROC1,VVV=VPWRKC

gives output:
SYMBOL VVV=&VVV
SYMBOL VVV=VPWRKC

The in stream symbol is not substituted in the first step but it is
substituted correctly in subsequent steps. The JCL symbol is substituted
as expected.

If you SET VVV=&VVV the symbols are substituted as expected:

//PROC1     PROC VVV=VPWRKA
//          EXPORT SYMLIST=VVV
//          SET VVV=&VVV
//PSTEP1    EXEC PGM=IEBGENER
//SYSPRINT  DD   DUMMY
//SYSIN     DD   DUMMY
//SYSUT1    DD *,SYMBOLS=JCLONLY
SYMBOL VVV=&VVV
/*
//SYSUT2    DD   SYSOUT=*
//          PEND
//JSTEP1    EXEC PROC1,VVV=VPWRKB
//JSTEP2    EXEC PROC1,VVV=VPWRKC

SYMBOL VVV=VPWRKB
SYMBOL VVV=VPWRKC
Post by Paul Gilmartin
Be careful. If the SYSIN appears within a PROC and different symbol values
are in effect at various EXEC PRC=... statements, multiple copies of that
SYSIN might need to be supplied for the various proc steps.
If I have
//DD1       DD   DISP=(OLD,DELETE),UNIT=SYSDA,VOL=SER=&VVV
I end up with multiple copies of that JCL statement with different
values. I have no problem with multiple copies of the SYSIN, it is what
I expected.
--
Andrew Rowley
Black Hill Software
+61 413 302 386

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-06-21 13:06:00 UTC
Reply
Permalink
Raw Message
I've gotten good results with the EXPORT before the PROC, this example is
cut down from a working job:

//TSRCMHL1 JOB 1000,STEVE.SMITH,NOTIFY=&SYSUID,
// CLASS=C,MSGCLASS=X,COND=(1,LT)
// EXPORT SYMLIST=(PFX,VER,REL,FIX)
//HLDLIBS PROC PFX=RCM,VER=VV,REL=RR,FIX=TAC99999
//AMS1 EXEC PGM=IDCAMS,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSIN DD *,SYMBOLS=JCLONLY
DELETE &PFX..HLD&VER.&REL..&FIX..*
SET MAXCC=0
//COPY1 EXEC PGM=IEBCOPY,REGION=0M
//SYSPRINT DD SYSOUT=*
//ASMIN DD DSN=RCM.WRK07&REL..ASM,DISP=SHR
//LOADIN DD DSN=RCM.WRK07&REL..LOADLIB,DISP=SHR
//ASMOUT DD DSN=&PFX..HLD&VER.&REL..&FIX..ASM,DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(CYL,(5,10,1),RLSE),
// DSNTYPE=LIBRARY,RECFM=FB,LRECL=80
//LOADOUT DD DSN=&PFX..HLD&VER.&REL..&FIX..S&PFX.LOAD,
// DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(TRK,(30,20,3),RLSE),
// RECFM=U,BLKSIZE=6233
//SYSIN DD DDNAME=&PFX.ASMIN
// DD *,SYMBOLS=JCLONLY
LOADLIB COPY INDD=LOADIN,OUTDD=LOADOUT
SELECT MEMBER=&PFX.00222
//MKCASMIN DD *
ASM COPY INDD=ASMIN,OUTDD=ASMOUT
SELECT MEMBER=((RCM00222,MKC00222))
//RCMASMIN DD *
ASM COPY INDD=ASMIN,OUTDD=ASMOUT
SELECT MEMBER=RCM00222
// PEND
//JS16730 EXEC HLDLIBS,PFX=RCM,VER=07,REL=05,FIX=TAC16730
//JS2740 EXEC HLDLIBS,PFX=MKC,VER=02,REL=05,FIX=MCA2740
//JS2741 EXEC HLDLIBS,PFX=MKC,VER=02,REL=06,FIX=MCA2741
//JS2742 EXEC HLDLIBS,PFX=MKC,VER=02,REL=07,FIX=MCA2742
//JS16731 EXEC HLDLIBS,PFX=RCM,VER=07,REL=07,FIX=TAC16731
//

Ain't JCL fun!

sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-06-22 00:35:05 UTC
Reply
Permalink
Raw Message
Post by Steve Smith
I've gotten good results with the EXPORT before the PROC
Which means the EXPORT needs to be in the calling job, not the PROC. My
examples used inline PROCs for convenience, but I was trying to do it
with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the
job needs to know exactly which variables the PROC needs exported, which
negates some of the convenience of abstracting stuff into a PROC.

The best solution seems to be SET VAR=&VAR in the PROC.
--
Andrew Rowley
Black Hill Software
+61 413 302 386

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2018-06-21 06:16:16 UTC
Reply
Permalink
Raw Message
Post by Elardus Engelbrecht
//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0
Unfortunately that may not work because the symbols in SYSIN are not substituted the same way as in the regular JCL. I have been playing around with them and my conclusion is that the whole feature seems to have been badly thought out.
Thanks for this reminder. I remember that I also discovered that substition is not always correct, but I was too busy to follow it up.
If IBM had omitted some features, e.g. system symbols on the execution system and instead substituted the symbols at the same time as the symbols in the rest of the JCL, they would have lost maybe 10% of the usefulness but decreased the astonishment by 90%.
Which brings another question - I am just curious - Where are the Symbols resolved? At the submitting LPAR or at the Executing LPAR? Or is the '/*JOBPARM SYSAFF=<LPAR>' used to determine the LPAR where the Symbols are to be resolved/substituted?

I am asking, because there are Symbols unique for a LPAR, like this:

D SYMBOLS
IEA007I STATIC SYSTEM SYMBOL VALUES
&SYSALVL. = "2"
&SYSCLONE. = "C4" <--- Unique per LPAR
&SYSNAME. = "????" <--- Unique per LPAR

If that is documented, I must missed it somewhere ...

Sorry for this topic drift, but ... ;-)

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lucas Rosalen
2018-06-21 06:56:50 UTC
Reply
Permalink
Raw Message
On the side topic...

Based on our latest "experience":
- without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
which caused some problems as they were different from the executing LPAR
(and used as a dataset qualifier);
- with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR (even
with SYSAFF=*);

I also don't know about the documentation, just learned from a colleague
that had worked on our issue.


-------------------------------------------------------------------------------------------------------------------------------
*Lucas Rosalen*
***@gmail.com / ***@ibm.com
http://br.linkedin.com/in/lrosalen


2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
Post by Andrew Rowley
Post by Elardus Engelbrecht
to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place
//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0
Unfortunately that may not work because the symbols in SYSIN are not
substituted the same way as in the regular JCL. I have been playing around
with them and my conclusion is that the whole feature seems to have been
badly thought out.
Thanks for this reminder. I remember that I also discovered that
substition is not always correct, but I was too busy to follow it up.
Post by Andrew Rowley
If IBM had omitted some features, e.g. system symbols on the execution
system and instead substituted the symbols at the same time as the symbols
in the rest of the JCL, they would have lost maybe 10% of the usefulness
but decreased the astonishment by 90%.
Which brings another question - I am just curious - Where are the Symbols
resolved? At the submitting LPAR or at the Executing LPAR? Or is the
'/*JOBPARM SYSAFF=<LPAR>' used to determine the LPAR where the Symbols are
to be resolved/substituted?
D SYMBOLS
IEA007I STATIC SYSTEM SYMBOL VALUES
&SYSALVL. = "2"
&SYSCLONE. = "C4" <--- Unique per LPAR
&SYSNAME. = "????" <--- Unique per LPAR
If that is documented, I must missed it somewhere ...
Sorry for this topic drift, but ... ;-)
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2018-06-21 07:11:41 UTC
Reply
Permalink
Raw Message
Lucas,

I think this is a mis-interpretation of your observations:

With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: for convertor, interpretor and execution, so here you can be sure of the substituted values.

Without /*JOBPARM SYSAFF: the job can be handled by any system in the MAS for all 3 phases, so it can be submitted on system1, converted on system 2 and executed on system 3. You will not know in advance which system will do what.

Kees.
Post by Gadi Ben-Avi
-----Original Message-----
Behalf Of Lucas Rosalen
Sent: 21 June, 2018 8:57
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
On the side topic...
- without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
which caused some problems as they were different from the executing LPAR
(and used as a dataset qualifier);
- with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR (even
with SYSAFF=*);
I also don't know about the documentation, just learned from a colleague
that had worked on our issue.
------------------------------------------------------------------------
-------------------------------------------------------
*Lucas Rosalen*
http://br.linkedin.com/in/lrosalen
2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
Post by Andrew Rowley
Post by Andrew Rowley
Post by Elardus Engelbrecht
to this one (clear out the SYSIN - at least for IDCAMS SYSIN and
place
Post by Andrew Rowley
Post by Andrew Rowley
Post by Elardus Engelbrecht
//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0
Unfortunately that may not work because the symbols in SYSIN are not
substituted the same way as in the regular JCL. I have been playing
around
Post by Andrew Rowley
with them and my conclusion is that the whole feature seems to have
been
Post by Andrew Rowley
badly thought out.
Thanks for this reminder. I remember that I also discovered that
substition is not always correct, but I was too busy to follow it up.
Post by Andrew Rowley
If IBM had omitted some features, e.g. system symbols on the
execution
Post by Andrew Rowley
system and instead substituted the symbols at the same time as the
symbols
Post by Andrew Rowley
in the rest of the JCL, they would have lost maybe 10% of the
usefulness
Post by Andrew Rowley
but decreased the astonishment by 90%.
Which brings another question - I am just curious - Where are the
Symbols
Post by Andrew Rowley
resolved? At the submitting LPAR or at the Executing LPAR? Or is the
'/*JOBPARM SYSAFF=<LPAR>' used to determine the LPAR where the Symbols
are
Post by Andrew Rowley
to be resolved/substituted?
D SYMBOLS
IEA007I STATIC SYSTEM SYMBOL VALUES
&SYSALVL. = "2"
&SYSCLONE. = "C4" <--- Unique per LPAR
&SYSNAME. = "????" <--- Unique per LPAR
If that is documented, I must missed it somewhere ...
Sorry for this topic drift, but ... ;-)
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lucas Rosalen
2018-06-21 07:18:21 UTC
Reply
Permalink
Raw Message
Thanks Kees, that's exactly what I tried to say and failed miserably :)

-------------------------------------------------------------------------------------------------------------------------------
*Lucas Rosalen*
***@gmail.com / ***@ibm.com
http://br.linkedin.com/in/lrosalen


2018-06-21 9:09 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM <
Post by Vernooij, Kees - KLM , ITOPT1
Lucas,
With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: for
convertor, interpretor and execution, so here you can be sure of the
substituted values.
Without /*JOBPARM SYSAFF: the job can be handled by any system in the MAS
for all 3 phases, so it can be submitted on system1, converted on system 2
and executed on system 3. You will not know in advance which system will do
what.
Kees.
Post by Gadi Ben-Avi
-----Original Message-----
Behalf Of Lucas Rosalen
Sent: 21 June, 2018 8:57
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
On the side topic...
- without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
which caused some problems as they were different from the executing LPAR
(and used as a dataset qualifier);
- with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR (even
with SYSAFF=*);
I also don't know about the documentation, just learned from a colleague
that had worked on our issue.
------------------------------------------------------------------------
-------------------------------------------------------
*Lucas Rosalen*
http://br.linkedin.com/in/lrosalen
2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
Post by Andrew Rowley
Post by Andrew Rowley
Post by Elardus Engelbrecht
to this one (clear out the SYSIN - at least for IDCAMS SYSIN and
place
Post by Andrew Rowley
Post by Andrew Rowley
Post by Elardus Engelbrecht
//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0
Unfortunately that may not work because the symbols in SYSIN are not
substituted the same way as in the regular JCL. I have been playing
around
Post by Andrew Rowley
with them and my conclusion is that the whole feature seems to have
been
Post by Andrew Rowley
badly thought out.
Thanks for this reminder. I remember that I also discovered that
substition is not always correct, but I was too busy to follow it up.
Post by Andrew Rowley
If IBM had omitted some features, e.g. system symbols on the
execution
Post by Andrew Rowley
system and instead substituted the symbols at the same time as the
symbols
Post by Andrew Rowley
in the rest of the JCL, they would have lost maybe 10% of the
usefulness
Post by Andrew Rowley
but decreased the astonishment by 90%.
Which brings another question - I am just curious - Where are the
Symbols
Post by Andrew Rowley
resolved? At the submitting LPAR or at the Executing LPAR? Or is the
'/*JOBPARM SYSAFF=<LPAR>' used to determine the LPAR where the Symbols
are
Post by Andrew Rowley
to be resolved/substituted?
D SYMBOLS
IEA007I STATIC SYSTEM SYMBOL VALUES
&SYSALVL. = "2"
&SYSCLONE. = "C4" <--- Unique per LPAR
&SYSNAME. = "????" <--- Unique per LPAR
If that is documented, I must missed it somewhere ...
Sorry for this topic drift, but ... ;-)
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail or
any attachment may be disclosed, copied or distributed, and that any other
action related to this e-mail or attachment is strictly prohibited, and may
be unlawful. If you have received this e-mail by error, please notify the
sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission
of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered
number 33014286
********************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2018-06-21 07:24:56 UTC
Reply
Permalink
Raw Message
Lucas,

Ok, without SYSAFF, the submitting system has a good chance to handle the job first, but I thought you meant to say that this was a rule.
We have seen the opposite, maybe because of JESs loads, that another system than the submitting system handled most of the converts.

Kees.
Post by Gadi Ben-Avi
-----Original Message-----
Behalf Of Lucas Rosalen
Sent: 21 June, 2018 9:18
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Thanks Kees, that's exactly what I tried to say and failed miserably :)
------------------------------------------------------------------------
-------------------------------------------------------
*Lucas Rosalen*
http://br.linkedin.com/in/lrosalen
2018-06-21 9:09 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM <
Post by Vernooij, Kees - KLM , ITOPT1
Lucas,
for
Post by Vernooij, Kees - KLM , ITOPT1
convertor, interpretor and execution, so here you can be sure of the
substituted values.
Without /*JOBPARM SYSAFF: the job can be handled by any system in the
MAS
Post by Vernooij, Kees - KLM , ITOPT1
for all 3 phases, so it can be submitted on system1, converted on
system 2
Post by Vernooij, Kees - KLM , ITOPT1
and executed on system 3. You will not know in advance which system
will do
Post by Vernooij, Kees - KLM , ITOPT1
what.
Kees.
Post by Gadi Ben-Avi
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-
Behalf Of Lucas Rosalen
Sent: 21 June, 2018 8:57
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
On the side topic...
- without /*JOBPARM SYSAFF: symbols got resolved in the submitting
LPAR,
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
which caused some problems as they were different from the executing LPAR
(and used as a dataset qualifier);
- with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR (even
with SYSAFF=*);
I also don't know about the documentation, just learned from a
colleague
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
that had worked on our issue.
--------------------------------------------------------------------
----
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
-------------------------------------------------------
*Lucas Rosalen*
http://br.linkedin.com/in/lrosalen
2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
Post by Andrew Rowley
Post by Andrew Rowley
Post by Elardus Engelbrecht
to this one (clear out the SYSIN - at least for IDCAMS SYSIN
and
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
place
Post by Andrew Rowley
Post by Andrew Rowley
Post by Elardus Engelbrecht
//* DELETE KVPO.MOST.DB2DATA.&LVL4..&PART..TRS
//SYSIN DD *,SYMBOLS=(JCLONLY,X)
SET MAXCC = 0
Unfortunately that may not work because the symbols in SYSIN are
not
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
Post by Andrew Rowley
substituted the same way as in the regular JCL. I have been
playing
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
around
Post by Andrew Rowley
with them and my conclusion is that the whole feature seems to
have
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
been
Post by Andrew Rowley
badly thought out.
Thanks for this reminder. I remember that I also discovered that
substition is not always correct, but I was too busy to follow it
up.
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
Post by Andrew Rowley
Post by Andrew Rowley
If IBM had omitted some features, e.g. system symbols on the
execution
Post by Andrew Rowley
system and instead substituted the symbols at the same time as the
symbols
Post by Andrew Rowley
in the rest of the JCL, they would have lost maybe 10% of the
usefulness
Post by Andrew Rowley
but decreased the astonishment by 90%.
Which brings another question - I am just curious - Where are the
Symbols
Post by Andrew Rowley
resolved? At the submitting LPAR or at the Executing LPAR? Or is
the
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
Post by Andrew Rowley
'/*JOBPARM SYSAFF=<LPAR>' used to determine the LPAR where the
Symbols
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
are
Post by Andrew Rowley
to be resolved/substituted?
I am asking, because there are Symbols unique for a LPAR, like
D SYMBOLS
IEA007I STATIC SYSTEM SYMBOL VALUES
&SYSALVL. = "2"
&SYSCLONE. = "C4" <--- Unique per LPAR
&SYSNAME. = "????" <--- Unique per LPAR
If that is documented, I must missed it somewhere ...
Sorry for this topic drift, but ... ;-)
Groete / Greetings
Elardus Engelbrecht
------------------------------------------------------------------
----
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
Post by Andrew Rowley
For IBM-MAIN subscribe / signoff / archive access instructions,
MAIN
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
--------------------------------------------------------------------
--
Post by Vernooij, Kees - KLM , ITOPT1
Post by Gadi Ben-Avi
For IBM-MAIN subscribe / signoff / archive access instructions,
MAIN
Post by Vernooij, Kees - KLM , ITOPT1
********************************************************
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only.
If
Post by Vernooij, Kees - KLM , ITOPT1
you are not the addressee, you are notified that no part of the e-mail
or
Post by Vernooij, Kees - KLM , ITOPT1
any attachment may be disclosed, copied or distributed, and that any
other
Post by Vernooij, Kees - KLM , ITOPT1
action related to this e-mail or attachment is strictly prohibited,
and may
Post by Vernooij, Kees - KLM , ITOPT1
be unlawful. If you have received this e-mail by error, please notify
the
Post by Vernooij, Kees - KLM , ITOPT1
sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
its
Post by Vernooij, Kees - KLM , ITOPT1
employees shall not be liable for the incorrect or incomplete
transmission
Post by Vernooij, Kees - KLM , ITOPT1
of this e-mail or any attachments, nor responsible for any delay in
receipt.
Post by Vernooij, Kees - KLM , ITOPT1
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch
Post by Vernooij, Kees - KLM , ITOPT1
Airlines) is registered in Amstelveen, The Netherlands, with
registered
Post by Vernooij, Kees - KLM , ITOPT1
number 33014286
********************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-06-22 00:51:06 UTC
Reply
Permalink
Raw Message
Post by Andrew Rowley
Post by Steve Smith
I've gotten good results with the EXPORT before the PROC
Which means the EXPORT needs to be in the calling job, not the PROC. My
examples used inline PROCs for convenience, but I was trying to do it
with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the
job needs to know exactly which variables the PROC needs exported, which
negates some of the convenience of abstracting stuff into a PROC.
Does it not suffice to code EXPORT before SET, but in the PROC?
(But then are symbols exported to open code, outside the PROC?)
Post by Andrew Rowley
The best solution seems to be SET VAR=&VAR in the PROC.
Hardly practical if the vaue of VAR contains metacharacters. JCL
sorely needs HLASM's DOUBLE BIF.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-06-22 01:22:08 UTC
Reply
Permalink
Raw Message
My only point was the SET wasn't needed the way I used symbols.  It's
hardly any big deal if it's needed for  library PROCs.  The fact that
there doesn't seem to be any obvious logical reason for it, is just one
of things you take for granted with JCL.

Why don't we just skip the JCL, and write our jobs in REXX?  The two
main things JCL does, EXEC and DD, are just as easy in REXX, (call,
alloc) with a ton more flexibility.  EXPORT, SET, IF, and symbols are
lipstick for a pig.

All you must keep in JCL is the JOB card, and a standard EXEC PGM=IRXJCL
+ SYSEXEC DD.  Everything else you can code in an actual programming
language.

JCL is fun as a puzzle-solving activity (sometimes), but for busy people
trying to get their work done, it's been a black cloud since 1964.  Even
Fred P. Brooks said he didn't like it.

sas
Post by Paul Gilmartin
Post by Andrew Rowley
Post by Steve Smith
I've gotten good results with the EXPORT before the PROC
Which means the EXPORT needs to be in the calling job, not the PROC. My
examples used inline PROCs for convenience, but I was trying to do it
with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the
job needs to know exactly which variables the PROC needs exported, which
negates some of the convenience of abstracting stuff into a PROC.
Does it not suffice to code EXPORT before SET, but in the PROC?
(But then are symbols exported to open code, outside the PROC?)
Post by Andrew Rowley
The best solution seems to be SET VAR=&VAR in the PROC.
Hardly practical if the vaue of VAR contains metacharacters. JCL
sorely needs HLASM's DOUBLE BIF.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-06-22 01:48:33 UTC
Reply
Permalink
Raw Message
Post by Steve Smith
Why don't we just skip the JCL, and write our jobs in REXX?  The two
main things JCL does, EXEC and DD, are just as easy in REXX, (call,
alloc) with a ton more flexibility.  EXPORT, SET, IF, and symbols are
lipstick for a pig.
I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.

In a previous job I tried to write scripts on a unix system to try to
fix tasks that had a tendency to open one file and then wait for
another, where multiple tasks were deadlocking. This is so simple with
JCL because you don't get one allocation until you get them all.

The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is much better than one long command line) or hard code them.
--
Andrew Rowley
Black Hill Software
+61 413 302 386

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-01 17:12:12 UTC
Reply
Permalink
Raw Message
)Why don't we just skip the JCL, and write our jobs in REXX? The two

Here, here!! Actually, there is one thing that is critical to retiring
JCL. It's a host command that allows a REXX program to list and wait for
all it's datasets and their enqueues to be available. This is not trivial,
so that's why no installation has taken it on. I don't know why IBM keeps
shoe-horning new features with big astonishment factors into JCL. z/OS is
the only major platform with a separate batch-only language.

Anyone want to write sn RFE?
Why don't we just skip the JCL, and write our jobs in REXX? The two
main things JCL does, EXEC and DD, are just as easy in REXX, (call,
alloc) with a ton more flexibility. EXPORT, SET, IF, and symbols are
lipstick for a pig.
I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.

In a previous job I tried to write scripts on a unix system to try to
fix tasks that had a tendency to open one file and then wait for
another, where multiple tasks were deadlocking. This is so simple with
JCL because you don't get one allocation until you get them all.

The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is much better than one long command line) or hard code them.
--
Andrew Rowley
Black Hill Software
+61 413 302 386

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-07-02 13:56:40 UTC
Reply
Permalink
Raw Message
Post by Hobart Spitz
)Why don't we just skip the JCL, and write our jobs in REXX? The two
Here, here!! Actually, there is one thing that is critical to retiring
JCL. It's a host command that allows a REXX program to list and wait for
all it's datasets and their enqueues to be available. This is not trivial,
so that's why no installation has taken it on. I don't know why IBM keeps
shoe-horning new features with big astonishment factors into JCL. z/OS is
the only major platform with a separate batch-only language.
Anyone want to write sn RFE?
​I very much agree that JCL needs to be retired. It has a long and
not-so-lustrous ​career. However, at least for me, one major thing which
needs to be a critical consideration is restarting a "batch process" (aka
REXX program, shell script). There needs to be someway which will, like
CA-11 for instance, track what DSNs / UNIX files were created so that they
can be automatically deleted when it is necessary. The new process must
have a monitor which will keep track of which "step" equivalent has
executed and be able to do something like a CA-11 restart. This becomes
very complicated if the new processor can do looping. I can envision a REXX
like environment where you can something like:

/* REXX batch process */
ADDRESS BATCH /* activate the BATCH environment */
DSNPATTERN='SOMEHLQ.PROCESS.**.INPUT'
"FINDDSNS (DSNPATTERN) (STEM DSN."
/* Above does a catalog search for the DSNs described in DSNPATTERN */
/* DSN.0 == Number of DSNs found */
/* DSN.? (1 to DSN.0) == DSN found */
"ENQDSN (ISTEM DSN. OSTEM DDN. TIMEOUT 3600"
/* Above does a SYSDSN enqueue on all DSNs in the stem, waiting up to 3600
seconds -- 1 hour */
/* ISTEM is a REXX "array" of DSNs which are input to the ENQDSN
OSTEM is a parallel REXX "array" of DDNs which are allocated to
the corresponding ISTEM input DSN.
*/
IF RC <> 0 THEN DO; /* ENQ FAILED -- nothing allocated */
SAY "ENQ TIMED OUT -- ABORTING"
EXIT 16 /* END BATCH PROCESS WITH CC OF 16 */
END
DO DDN_NUM = 1 TO DDN.0
"REALLOC SYSIN " DDN.DDN_NUM
/* The above does a FREE on SYSIN (unless OPEN) and reallocates
DDN.DDN_NUM
to the DDN of SYSIN -- assumes DDN is harded coded in the program
*/
ADDRESS ATTACH "SOMEPGM PARM TO SOMEPGM" /* standard BATCH parameter
list */
"CKPT" /* tell the BATCH environment to "checkpoint" somewhere */
END


​The above is just some "off the cuff" thoughts and a simple example of how
something _might_ look. The BATCH environment is the replacement for JCL.
It somehow communicates either with the JES system record checkpoint
information for "restarting" the batch process if something happens. I
didn't go into this because I simply don't have any good ideas. ​
--
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-11 14:51:56 UTC
Reply
Permalink
Raw Message
Post by Andrew Rowley
I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.

Then you haven't fully considered the alternatives. That's not a
criticism, just a statement of fact. How many of us really know how our
computers, cars, phones, bodies or anything else we live with day to day,
really work, at least until they don't, then we start caring.

Here's an actual example: I was riding in the back of an Uber recently,
and I felt every single bump, as if the chassis was bottoming out. I asked
some casual questions of the driver about the car. She said she bought it
used and tires kept exploding when she hit a pothole. I'd never had
exploding tire, so I suggested that the cause might be that her shocks
weren't not doing the job they were intended for, i.e. mitigating
irregularities in the roadway. (Consider a pothole a large value of
irregularity.)

The point is, you can proceed for a long time without understanding what
your tools are doing for you, but the day may come when you (or someone
else) will need to have that knowledge.
Post by Andrew Rowley
In a previous job I tried to write scripts on a unix system to try to fix
tasks that had a tendency to open one file and then wait for another, where
multiple tasks >were deadlocking.

It may take a little more skill and experience to write in a real scripting
language than in JCL, but it should be done. I submit that this attitude
contributes to the high cost of running z/OS. The many things that happen
in batch are hidden, and IMHO, contribute to greater "large system effect"
than with leaner operating systems such as z/VM, *nix and *nix
derivatives. IBM and its stockholders love it when your company has to
spend more on hardware, especially when that hardware is so cheap to make
that they can afford to ship you 16 processors, when your company only
orders and pays for 1.
Post by Andrew Rowley
This is so simple with JCL because you don't get one allocation until you
get them all.

That's what my suggested host command/function would do. It would probably
have a behaviour that would allow it to be used only once, to prevent
deadlocks, unless all previous ENQs were freed. The second use, without
FREE, could cause a JOB cancelation, possibly unconditionally, so that
well-meaning misuse would be discouraged, or, alternatively, only if the
ENQs could not be satisfied.
Post by Andrew Rowley
The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is >much better than one long command line) or hard code them.

That's only because z/OS is so JCL oriented. Again, this works in IBM (and
shareholders) favor. It's harder to leave for another platform.
Post by Andrew Rowley
Have you a realistic alternative?
For starters, consider something that uses REXX syntax and JCL semantics:


1.
*/* REXX */ *
2.
*arg String /* From SUBMIT or start task command. */ *
3.
*"jcl myjob: job (acct),'john smith',class=t,msgclass=h,notify="userid()" *
4.
*"jcl exec pgm=myprog,parm="date("s") *
5.
*"jcl sysprint: dd sysout=*" *
6. *...*

The JCL host command could create the exact same control blocks and
structures as the existing JCL statements today. When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup. All exits would be preserved so
that third-party software would still work unchanged. The JCL EXEC host
command could generate code to set RC.stepname supporting condition code
testing, and the JCL DD host command could set stepname.ddname.DSN, etc.,
to allow for reference to all parameters. This approach would, however,
limit the benefits of batch REXX.

I'm sure there are lots of other ways to do it. Use more DB2 and PDSEs. A
combination of REXX and PIPElines means that temporary datasets, and their
2 (or more) can be replaced with just one single character.
Post by Andrew Rowley
In one case, I was able to enumerate a superset of the
DSNs I might want to allocate in a Rexx step. I added EXEC
PGM=IEFBR14,COND=(0,LE)
Post by Andrew Rowley
with DD statements for those at the end of the job just to avoid ENQ
surprises.
Post by Andrew Rowley
JCL automates the enumeration of the ENQs; DYNALLOC, a newcomer, doesn't
play by the old rules.
I use this technique when all else fails, and recommend it with one
exception. Put that those DDs in the first step of the job. You can FREE
something you won't need in the rest of the JOB, in case another
JOB/process might need it, without risking a deadly embrace.

I do advocate a combined REXX and PIPElines environment as a replacement
for JCL; z/VM works swimmingly with it. Perhaps z/OS fossilized thinking
is why the best things in z/OS (DB2, REXX, PIPElines) came from z/VM. We'd
all be just as happy if *nix could offer the same productivity and
performance benefits. Doing things character by character is just as bad
and old as JCL. That needs to change.

OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
Post by Andrew Rowley
Post by Hobart Spitz
)Why don't we just skip the JCL, and write our jobs in REXX? The two
Here, here!! Actually, there is one thing that is critical to retiring
JCL. It's a host command that allows a REXX program to list and wait for
all it's datasets and their enqueues to be available. This is not
trivial,
Post by Hobart Spitz
so that's why no installation has taken it on. I don't know why IBM
keeps
Post by Hobart Spitz
shoe-horning new features with big astonishment factors into JCL. z/OS
is
Post by Hobart Spitz
the only major platform with a separate batch-only language.
Anyone want to write sn RFE?
​I very much agree that JCL needs to be retired. It has a long and
not-so-lustrous ​career. However, at least for me, one major thing which
needs to be a critical consideration is restarting a "batch process" (aka
REXX program, shell script). There needs to be someway which will, like
CA-11 for instance, track what DSNs / UNIX files were created so that they
can be automatically deleted when it is necessary. The new process must
have a monitor which will keep track of which "step" equivalent has
executed and be able to do something like a CA-11 restart. This becomes
very complicated if the new processor can do looping. I can envision a REXX
/* REXX batch process */
ADDRESS BATCH /* activate the BATCH environment */
DSNPATTERN='SOMEHLQ.PROCESS.**.INPUT'
"FINDDSNS (DSNPATTERN) (STEM DSN."
/* Above does a catalog search for the DSNs described in DSNPATTERN */
/* DSN.0 == Number of DSNs found */
/* DSN.? (1 to DSN.0) == DSN found */
"ENQDSN (ISTEM DSN. OSTEM DDN. TIMEOUT 3600"
/* Above does a SYSDSN enqueue on all DSNs in the stem, waiting up to 3600
seconds -- 1 hour */
/* ISTEM is a REXX "array" of DSNs which are input to the ENQDSN
OSTEM is a parallel REXX "array" of DDNs which are allocated to
the corresponding ISTEM input DSN.
*/
IF RC <> 0 THEN DO; /* ENQ FAILED -- nothing allocated */
SAY "ENQ TIMED OUT -- ABORTING"
EXIT 16 /* END BATCH PROCESS WITH CC OF 16 */
END
DO DDN_NUM = 1 TO DDN.0
"REALLOC SYSIN " DDN.DDN_NUM
/* The above does a FREE on SYSIN (unless OPEN) and reallocates
DDN.DDN_NUM
to the DDN of SYSIN -- assumes DDN is harded coded in the program
*/
ADDRESS ATTACH "SOMEPGM PARM TO SOMEPGM" /* standard BATCH parameter
list */
"CKPT" /* tell the BATCH environment to "checkpoint" somewhere */
END
​The above is just some "off the cuff" thoughts and a simple example of how
something _might_ look. The BATCH environment is the replacement for JCL.
It somehow communicates either with the JES system record checkpoint
information for "restarting" the batch process if something happens. I
didn't go into this because I simply don't have any good ideas. ​
--
There is no such thing as the Cloud. It is just somebody else’s computer.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-07-11 15:40:30 UTC
Reply
Permalink
Raw Message
Not sure if this was pointed out before, but DDNAMEs are required by z/OS
access methods, not JCL. There is no reason these or dataset names need to
be arguments just because REXX is used instead of JCL.

DDNAMEs are a pretty nice feature of z/OS! So you *don't* have to pass a
bunch of (potentially very long) file names. DDNAMEs can be thought of as
a limited form of environment variables.

sas
Post by Andrew Rowley
​...
Post by Andrew Rowley
The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is >much better than one long command line) or hard code them.
That's only because z/OS is so JCL oriented. Again, this works in IBM (and
shareholders) favor. It's harder to leave for another platform.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-07-11 23:41:03 UTC
Reply
Permalink
Raw Message
Post by Hobart Spitz
It may take a little more skill and experience to write in a real scripting
language than in JCL, but it should be done.
Here is an example of something that is simple in JCL, but very
difficult to get right in a scripting language (i.e. 6 equivalent scripts):

//JOB1    JOB
//S1      EXEC PGM=PROGRAMA
//DD1     DD DSN=DATASET.A,DISP=SHR
//DD2     DD DSN=DATASET.B,DISP=SHR

//JOB2    JOB
//S1      EXEC PGM=PROGRAMB
//DD1     DD DSN=DATASET.A,DISP=OLD
//DD2     DD DSN=DATASET.B,DISP=SHR

//JOB3    JOB
//S1      EXEC PGM=PROGRAMC
//DD1     DD DSN=DATASET.A,DISP=SHR
//DD2     DD DSN=DATASET.B,DISP=OLD

//JOB4    JOB
//S1      EXEC PGM=PROGRAMD
//DD1     DD DSN=DATASET.A,DISP=OLD
//DD2     DD DSN=DATASET.B,DISP=OLD

//JOB5    JOB
//S1      EXEC PGM=PROGRAME
//DD1     DD DSN=DATASET.A,DISP=SHR

//JOB6    JOB
//S1      EXEC PGM=PROGRAMF
//DD2     DD DSN=DATASET.B,DISP=SHR

I have debugged problems on unix where (unattended) overnight backups
never completed because 2 jobs deadlocked and just sat there for hours.
Jobs that do dynamic allocation with anything other than DISP=SHR can't
be trusted, particularly if they are 3rd party programs where you don't
know exactly what will be allocated and under what circumstances.

I haven't seen large amounts of batch processing on platforms other than
z/OS. I suspect a big reason is that without JCL it is impractical. A
reasonably common message from tar on unix systems is "file changed as
we read it". I know how to fix the equivalent with z/OS datasets. How do
you prevent it on Unix? And tar is probably an unusual case,  in that it
notices and reports when it happens.

The reality seems to be that on other platforms everything is shared,
and if you are concerned about simultaneous updates (or even
guaranteeing that a file isn't changed while you read it) it is up to
everyone accessing that file to cooperate with some form of locking.
Difficult, if you didn't write all the programs.

On a unix system, you can open a file for writing and another process
can delete it while you have it open and create a new file with the same
name. The file you are writing disappears when you close it. This sort
of thing is considered bad on z/OS. Sure, that's a function of z/OS
enqueues etc., but JCL is the (relatively) easy to use interface to
allocation.

--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-06-22 01:46:45 UTC
Reply
Permalink
Raw Message
Post by Steve Smith
My only point was the SET wasn't needed the way I used symbols.  It's
hardly any big deal if it's needed for  library PROCs.  The fact that
there doesn't seem to be any obvious logical reason for it, is just one
of things you take for granted with JCL.
Not logical, but diachronic.
Post by Steve Smith
Why don't we just skip the JCL, and write our jobs in REXX?  The two
main things JCL does, EXEC and DD, are just as easy in REXX, (call,
alloc) with a ton more flexibility.  EXPORT, SET, IF, and symbols are
lipstick for a pig.
(I use LINKMVS and BPXWDYN. No need for TSO.)
What Rexx lacks is the multiple ENQ with S99WTDSN that prevents
deadlocks. I could imagine this as an enhancement to BPXWDYN.
Post by Steve Smith
All you must keep in JCL is the JOB card, and a standard EXEC PGM=IRXJCL
+ SYSEXEC DD.  Everything else you can code in an actual programming
language.
IRXJCL lacks support for //SYSEXEC DD *. You need at least an IEBUPDTE
step to create a (temporary) SYSEXEC PDS. (There's an unsupported
workaround.)
Post by Steve Smith
JCL is fun as a puzzle-solving activity (sometimes), but for busy people
trying to get their work done, it's been a black cloud since 1964.  Even
Fred P. Brooks said he didn't like it.
Ipse dixit.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-01 20:20:34 UTC
Reply
Permalink
Raw Message
Post by Hobart Spitz
)Why don't we just skip the JCL, and write our jobs in REXX? The two
Here, here!! Actually, there is one thing that is critical to retiring
JCL. It's a host command that allows a REXX program to list and wait for
all it's datasets and their enqueues to be available. This is not trivial,
so that's why no installation has taken it on. I don't know why IBM keeps
shoe-horning new features with big astonishment factors into JCL. z/OS is
the only major platform with a separate batch-only language.
Anyone want to write sn RFE?
Have you a realistic alternative? In one case, I was able to enumerate a superset of the
DSNs I might want to allocate in a Rexx step. I added EXEC PGM=IEFBR14,COND=(0,LE)
with DD statements for those at the end of the job just to avoid ENQ surprises.
JCL automates the enumeration of the ENQs; DYNALLOC, a newcomer, doesn't
play by the old rules.

I could envision an alternative to S99WTDSN, not requiring authorization, which would
cause a wait unless that created a deadlock (recognizable as a cycle in the ENQ
graph) and fail immediately if a deadlock was created. Still, lots of questions. Which
job should fail? The newcomer to the party? Why?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-11 16:04:00 UTC
Reply
Permalink
Raw Message
Post by Steve Smith
Not sure if this was pointed out before, but DDNAMEs are required by z/OS
access methods, not JCL. There is no reason these or dataset names need to
be arguments just because REXX is used instead of JCL.
Most programs that don't expose DDNAMEs externaly create them internally
using DYNALLOC. This is true for z/OS Rexx, not for CMS Rexx.
Post by Steve Smith
DDNAMEs are a pretty nice feature of z/OS! So you *don't* have to pass a
bunch of (potentially very long) file names. DDNAMEs can be thought of as
a limited form of environment variables.
It stretches the understanding, but, yes. In the UNIX environment, descriptors
perform much the same function as DDNAMES in the OS environment.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-11 22:16:51 UTC
Reply
Permalink
Raw Message
I've always considered DD's one of the major differences between MVS and
other platforms. I remember one of my first BASIC programs in college
where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
and sort. The first thing I thought of was, "So we have to update the
program every time we want to sort a different file?"
So of you search far enough, you can find something worse than JCL to
compare it to, making JCL only the *second* worst programming
language in existence. Provided BASIC is still viable; otherwise JCL
reclaims last place.

But don't you have to update the JCL every time you want to sort a different
file?" Code is code. I have a number of scripts with symbol assignments at
the top. I EDIT; SUBMIT; CANCEL. Why should it be better to edit a JCLLIB
member; SAVE; and INCLUDE it instead?
DD redirection: Genius, whoever thought of it.
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-07-11 22:47:20 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
So of you search far enough, you can find something worse than JCL to
compare it to, making JCL only the *second* worst programming
language in existence. Provided BASIC is still viable; otherwise JCL
reclaims last place.
I disagree. BASIC has iterations ('for' loops), forward and backward
branching, and subroutine call/return. These fundamental programming
language constructs are missing from JCL. This is why it's such a bad
programming language.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pew, Curtis G
2018-07-11 23:04:17 UTC
Reply
Permalink
Raw Message
I disagree. BASIC has iterations ('for' loops), forward and backward branching, and subroutine call/return. These fundamental programming language constructs are missing from JCL. This is why it's such a bad programming language.
I don’t think it’s true that JCL is the worst programming language (with all due respect to Fred Brooks) because it isn’t really a programming language. Should it have been a programming language? Almost certainly, as shown by Unix scripting languages. But it isn’t, and although JCL does have many other deficiencies, it’s biggest problem is that people come to it expecting a programming language, and that’s not what it is.

When I try to explain JCL, I describe it as a human-interface language for an obsolete input technology (punch cards) that was thrown together at the last minute rather than designed and exposes technical details you’d rather not have to know about, but other than that it’s great! An EXEC statement is like double-clicking on an app icon, DD statements are like open/save dialogs, etc. But it’s not programming.
--
Pew, Curtis G
***@austin.utexas.edu
ITS Systems/Core/Administrative Services


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-07-12 04:05:34 UTC
Reply
Permalink
Raw Message
Post by Pew, Curtis G
I don’t think it’s true that JCL is the worst programming language
(with all due respect to Fred Brooks) because it isn’t really a
programming language. Should it have been a programming language?
Almost certainly, as shown by Unix scripting languages. But it isn’t...
With all due respect to whomever deserves it, ANY instructions telling
the computer what to do constitute programming...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-07-12 04:27:17 UTC
Reply
Permalink
Raw Message
Post by Ed Jaffe
With all due respect to whomever deserves it, ANY instructions telling
the computer what to do constitute programming...
That's sort of true, but it vastly expands the competition. It makes
HTML, even GML programming languages. Is JCL a worse programming
language than GML?
--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-07-12 04:48:43 UTC
Reply
Permalink
Raw Message
Post by Andrew Rowley
Post by Ed Jaffe
With all due respect to whomever deserves it, ANY instructions
telling the computer what to do constitute programming...
That's sort of true, but it vastly expands the competition. It makes
HTML, even GML programming languages. Is JCL a worse programming
language than GML?
If you are referring to the GameMaker Language (GML) then yes, JCL is
clearly much, much worse...

https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-07-12 04:56:26 UTC
Reply
Permalink
Raw Message
Post by Ed Jaffe
If you are referring to the GameMaker Language (GML) then yes, JCL is
clearly much, much worse...
https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/
No, Generalized Markup Language i.e. SCRIPT.
--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-12 15:43:18 UTC
Reply
Permalink
Raw Message
No, the GML Starter Set is implemented in Script but is not Script and has very different syntax.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Andrew Rowley <***@BLACKHILLSOFTWARE.COM>
Sent: Thursday, July 12, 2018 12:56 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Post by Ed Jaffe
If you are referring to the GameMaker Language (GML) then yes, JCL is
clearly much, much worse...
https://secure-web.cisco.com/1cKxvSgUaXO4DyyVa9rcjD0tV4VTM2jAjYR0dnFzUyYzSoeAcJicuzQOBu3cboe_mdq21wRP2VEJ7YTriFQZa9MnNl4_KW0xbIiO-rr1ajYnc7QTKrahupyWEUQdKX2RLChgTfnWi6-ZXXPTbUdvoBAVwZUPFxouP2a4_L_992tWe3kQManlaU9wTgMQlrM_Clw2h238pXVc25kzYZ37i_r7JmOkDiukxR1qiEOUHWpfwmMHgsDqDqR9ys-IeQMzHwIwxWXCljDisuM67LPiU_2UCwANUc2X4uykiXS7L0RvdGPazif5uxNj0g7Ma0FAU17tGoGNfvEZthzRTYK9awJXxYem2ETJUt4JhE-5pUPnZsjQ7pHcphHX_ktV6doPC/https%3A%2F%2Fdocs.yoyogames.com%2Fsource%2Fdadiospice%2F002_reference%2F001_gml%2520language%2520overview%2F
No, Generalized Markup Language i.e. SCRIPT.

--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pew, Curtis G
2018-07-12 12:33:08 UTC
Reply
Permalink
Raw Message
That's sort of true, but it vastly expands the competition. It makes HTML, even GML programming languages. Is JCL a worse programming language than GML?
That’s kind of how I meant it. I think of JCL as much closer to XML or JSON than to something like BASIC. You can’t, for example, use JCL to add two numbers.
--
Pew, Curtis G
***@austin.utexas.edu
ITS Systems/Core/Administrative Services


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-07-12 13:20:25 UTC
Reply
Permalink
Raw Message
Post by Ed Jaffe
Post by Pew, Curtis G
I don’t think it’s true that JCL is the worst programming language
(with all due respect to Fred Brooks) because it isn’t really a
programming language. Should it have been a programming language?
Almost certainly, as shown by Unix scripting languages. But it isn’t...
With all due respect to whomever deserves it, ANY instructions telling
the computer what to do constitute programming...
This opens up the "competition for the race to the bottom" to machine
language, which is clearly the "winner" here! Even 1BFF07FE is harder
to read and code than its 2-instruction assembler counterpart.

(OK, so I could not resist. Back into my hole now.)
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-07-12 14:19:24 UTC
Reply
Permalink
Raw Message
And that's the point...

SR 14,14
BR 15

is easier and clearer than machine language, but

main {}

is (sorta) clearer than that.

sas

p.s. bonus points if you see what I did there ;-)
Post by John Eells
Post by Ed Jaffe
Post by Pew, Curtis G
I don’t think it’s true that JCL is the worst programming language (with
all due respect to Fred Brooks) because it isn’t really a programming
language. Should it have been a programming language? Almost certainly, as
shown by Unix scripting languages. But it isn’t...
With all due respect to whomever deserves it, ANY instructions telling
the computer what to do constitute programming...
This opens up the "competition for the race to the bottom" to machine
language, which is clearly the "winner" here! Even 1BFF07FE is harder to
read and code than its 2-instruction assembler counterpart.
(OK, so I could not resist. Back into my hole now.)
--
John Eells
IBM Poughkeepsie
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2018-07-12 14:30:01 UTC
Reply
Permalink
Raw Message
Nice program, I made it a long time ago for load tests and called it IEFBR15.

Grtn,
Kees.
Post by Gadi Ben-Avi
-----Original Message-----
Behalf Of Steve Smith
Sent: 12 July, 2018 16:19
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
And that's the point...
SR 14,14
BR 15
is easier and clearer than machine language, but
main {}
is (sorta) clearer than that.
sas
p.s. bonus points if you see what I did there ;-)
Post by John Eells
Post by Ed Jaffe
Post by Pew, Curtis G
I don’t think it’s true that JCL is the worst programming language
(with
Post by John Eells
Post by Ed Jaffe
Post by Pew, Curtis G
all due respect to Fred Brooks) because it isn’t really a
programming
Post by John Eells
Post by Ed Jaffe
Post by Pew, Curtis G
language. Should it have been a programming language? Almost
certainly, as
Post by John Eells
Post by Ed Jaffe
Post by Pew, Curtis G
shown by Unix scripting languages. But it isn’t...
With all due respect to whomever deserves it, ANY instructions
telling
Post by John Eells
Post by Ed Jaffe
the computer what to do constitute programming...
This opens up the "competition for the race to the bottom" to machine
language, which is clearly the "winner" here! Even 1BFF07FE is harder
to
Post by John Eells
read and code than its 2-instruction assembler counterpart.
(OK, so I could not resist. Back into my hole now.)
--
John Eells
IBM Poughkeepsie
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
sas
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-12 15:47:16 UTC
Reply
Permalink
Raw Message
I doubt that many programmers ,or lexicographers, would agree with that.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Ed Jaffe <***@PHOENIXSOFTWARE.COM>
Sent: Thursday, July 12, 2018 12:05 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Post by Pew, Curtis G
I don’t think it’s true that JCL is the worst programming language
(with all due respect to Fred Brooks) because it isn’t really a
programming language. Should it have been a programming language?
Almost certainly, as shown by Unix scripting languages. But it isn’t...
With all due respect to whomever deserves it, ANY instructions telling
the computer what to do constitute programming...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1zjCfruIOOKZw4mRJqIBjCcQV4BgvaKOI8jDbdP_z_xMndsVRFWmgc0S-QwOhS7djTkXSAK2UyQ41QhfXYjoPd6Kla3zdAmLSKJ9gbv5ITWHLdW-sa_O3hv6BZvb6RJI6VTAax1C5Z_2SoXhwbv9hNAVDzVnZJTQIK3XiNluAanvZjrZP3CWwzGvmB72RGNJ3mPiXRXZuIYN9A5cUaCrttoqEShN0i8Opkj2ekiQH4f7FeYaWcTuFhVCe7z3Y8-i0oOWDXp-xkbVxMFH7z1bizf40ppsqOrYpHtdzRExg0SY67wENmBazGYNpG1RQDxJT_dlyxE_PsqspAg85zxdkbuvfAm8HVksAZ-81bE8662LOQ3t2ULe9UzBFvg9s4qq4jjSaQ5KlNfWUw5mu7H81InRXlH-66ibH3GM3Rx1JPEIEu3SmP4w00Pe8__KkMM39/https%3A%2F%2Fwww.phoenixsoftware.com%2F

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-12 16:02:23 UTC
Reply
Permalink
Raw Message
This is an argument about which hammer is the worst screwdriver; there's nothing wrong with most of those hammers. You have to use the right tool for the job.

"When the only tool you have is a pipe, everything looks like a filter."


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Wednesday, July 11, 2018 6:16 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
I've always considered DD's one of the major differences between MVS and
other platforms. I remember one of my first BASIC programs in college
where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
and sort. The first thing I thought of was, "So we have to update the
program every time we want to sort a different file?"
So of you search far enough, you can find something worse than JCL to
compare it to, making JCL only the *second* worst programming
language in existence. Provided BASIC is still viable; otherwise JCL
reclaims last place.

But don't you have to update the JCL every time you want to sort a different
file?" Code is code. I have a number of scripts with symbol assignments at
the top. I EDIT; SUBMIT; CANCEL. Why should it be better to edit a JCLLIB
member; SAVE; and INCLUDE it instead?
DD redirection: Genius, whoever thought of it.
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-12 00:46:10 UTC
Reply
Permalink
Raw Message
Post by Andrew Rowley
On a unix system, you can open a file for writing and another process
can delete it while you have it open and create a new file with the same
name. The file you are writing disappears when you close it.
That's a sort of LUW isolation, a facility that has come relatively recently to
z/OS in PDSE members. For better or for worse, however you view it.
Is it any worse than if the processes operated sequentially; no overlap.
Second guy wins. Conscientious second guy will create the file with
O_EXCL. If you don't trust the second guy, lock him out with RACF profile
or file permissions.

If I want to be very nondisruptive I write to a temp name and rename at
the end. This guarantees that no other job sees the update in transit.
UNIX rename() is preemptive: it quietly replaces any older file with the
same name; and atomic: no process will perceive an instant when the file
appears not to exist. I wish I could get the same behavior from IDCAMS
RENAME.
Post by Andrew Rowley
... This sort
of thing is considered bad on z/OS. Sure, that's a function of z/OS
enqueues etc., but JCL is the (relatively) easy to use interface to
allocation.
This works OK except when it doesn't. I recently encountered a problem
where the command implicitly sourced /etc/profile. Which meant that
things broke when /etc/profile changed the value of the environment
variable.
That sounds like a "Don't do that!" Don't do that.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-07-12 01:02:02 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
Is it any worse than if the processes operated sequentially; no overlap.
Second guy wins. Conscientious second guy will create the file with
O_EXCL. If you don't trust the second guy, lock him out with RACF profile
or file permissions.
It probably is worse, e.g. a likely example is where the second guy is
processing the output from the first guy. The designers of z/OS thought
this scenario was most likely an error and so protected you from it - I
tend to agree.

I don't trust the second guy to get the serialization right, where it is
not built-in.
Post by Paul Gilmartin
If I want to be very nondisruptive I write to a temp name and rename at
the end. This guarantees that no other job sees the update in transit.
Creating temporary files has its own security exposures. I am always
wary in case I am creating a security problem I don't understand.
--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-12 01:47:30 UTC
Reply
Permalink
Raw Message
Post by Andrew Rowley
Creating temporary files has its own security exposures. I am always
wary in case I am creating a security problem I don't understand.
You'd better not use SORT.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-07-12 03:18:24 UTC
Reply
Permalink
Raw Message
Post by Paul Gilmartin
Post by Andrew Rowley
Creating temporary files has its own security exposures. I am always
wary in case I am creating a security problem I don't understand.
You'd better not use SORT.
I am comfortable that the temporary file facilities in JCL are secure,
and constructs like DISP=(NEW,DELETE) are not an issue. And temporary
files created by something like DFSORT are someone else's problem.

It is temporary files in the HFS side of things that are the issue.
Again it is something that we take for granted in JCL that becomes
difficult to do correctly without it.

A couple of articles on the subject:
http://www.linuxsecurity.com/content/view/115462/81/
https://blogs.msdn.microsoft.com/secureapps/2007/01/22/temporary-file-generation-and-usage-best-practices/

There are enough issues there that for me, the best solution is point 1:
Don't use tempfiles/Avoid temporary files altogether
--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-12 15:55:56 UTC
Reply
Permalink
Raw Message
Post by Andrew Rowley
Again it is something that we take for granted in JCL that becomes
difficult to do correctly without it.
WTF? Dynamic allocation has supported temporary data sets since Old Man Noach cornered the market in Gopher Wood. We don't need mo stinking JCL for that.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Andrew Rowley <***@BLACKHILLSOFTWARE.COM>
Sent: Wednesday, July 11, 2018 11:18 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Using JCL Symbld and TYPRUN=SCAN
Post by Andrew Rowley
Post by Andrew Rowley
Creating temporary files has its own security exposures. I am always
wary in case I am creating a security problem I don't understand.
You'd better not use SORT.
I am comfortable that the temporary file facilities in JCL are secure,
and constructs like DISP=(NEW,DELETE) are not an issue. And temporary
files created by something like DFSORT are someone else's problem.

It is temporary files in the HFS side of things that are the issue.
Again it is something that we take for granted in JCL that becomes
difficult to do correctly without it.

A couple of articles on the subject:
http://secure-web.cisco.com/19zTgw5l4mNMUIFLg54Kdy_vy9ovUURWUPgH9qMMXVmbpny7rVDAErUcD1xXOFVijoMy5AROis-PJEDTMBbfjG0LUFTJh13Dr5s_sGROocBeKc7WUVjJQkmShPbjgKyWdlRLFPlqW1TnOzgJeH5jDEUy0lcxMOu7TjQ-DWvebVmwwCwEFWUU8YLbeKu2nj71rbxyIV8Akc2BMamAsQVQ8HAIcucVuVk3M-0hWT68fYEg40lpUXrYhG486Kh5jGSlRVAn6WyinZHGfF9VmXDq0TcR9vPZZXJHoL261yMyDKz6xOXkIdwsdbSwgYaevoQZ_ZqCKwdlNSm7RGXerHeLxqrKdfh6auKz1XQow8yyEw5A-dHrNLIywohsT4feIoZ7PNjYh9MoVL2OTVrOXGqXUr9dLBVLMywBqM5SfTWv-8Cy4m9lMeVN6zn_7VNSpOJJv/http%3A%2F%2Fwww.linuxsecurity.com%2Fcontent%2Fview%2F115462%2F81%2F
https://blogs.msdn.microsoft.com/secureapps/2007/01/22/temporary-file-generation-and-usage-best-practices/

There are enough issues there that for me, the best solution is point 1:
Don't use tempfiles/Avoid temporary files altogether

--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-07-12 23:57:00 UTC
Reply
Permalink
Raw Message
Post by Seymour J Metz
Post by Andrew Rowley
Again it is something that we take for granted in JCL that becomes
difficult to do correctly without it.
WTF? Dynamic allocation has supported temporary data sets since Old Man Noach cornered the market in Gopher Wood. We don't need mo stinking JCL for that.
I assume you're correct (I was referring to temporary unix files) but I
tried to look up the details in the documentation and I couldn't find
anything specific.

How would you do the equivalent of DISP=(NEW,DELETE) or (NEW,PASS) using
dynamic allocation?

Assembler solutions fall into my definition of "difficult to do",
compared to JCL.
--
Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-12 18:14:55 UTC
Reply
Permalink
Raw Message
Post by Pew, Curtis G
That's sort of true, but it vastly expands the competition. It makes HTML, even GML programming languages. Is JCL a worse programming language than GML?
That’s kind of how I meant it. I think of JCL as much closer to XML or JSON than to something like BASIC. You can’t, for example, use JCL to add two numbers.
Which was one incentive for my using a program to generate JCL. When I
want to create a multi-file tape a script automates creating the sequence
number in the label. If I add a file I don't need to modify all later steps.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-13 00:54:13 UTC
Reply
Permalink
Raw Message
Post by Andrew Rowley
Post by Seymour J Metz
WTF? Dynamic allocation has supported temporary data sets since Old Man Noach cornered the market in Gopher Wood. We don't need mo stinking JCL for that.
I assume you're correct (I was referring to temporary unix files) but I
tried to look up the details in the documentation and I couldn't find
anything specific.
UNIX tmpfile() has some of that function. Its semantics are different and it's
difficult to pass a temporary file from program to program.
Post by Andrew Rowley
How would you do the equivalent of DISP=(NEW,DELETE) or (NEW,PASS) using
dynamic allocation?
I believe DELETE works much the same with dynamic allocation as with JCL. In
fact, one way to use BPXDYN to delete a file is to ALLOC it MOD DELETE, then FREE it.

PASS is peculiar to JCL and is unavailable from dynamic allocation.
BPXWDYN( rtddn(name) ) is an alternative, but not equivalent.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...