Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Phil Smith III]

Peter Relson wrote:

>I on the other hand do have sympathy. A highly significant reason that

>z/OS still exists (and the same could have been said for its

>predecessors OS/390 and MVS) is because of the enormous amount of time

>and effort we have put into maintaining as much compatibility as we

>can. We do not treat incompatibility lightly. We do try to keep down

>the number of upgrade actions needed to move to a new release.

 

+1000. Nobody does compatibility like IBM, and that's A Good Thing that s 
many other vendors should learn from. Microsoft changes UI elements and 
keyboard shortcuts silently with service! And breaks myriad other things, also 
without notice.

 

IBM has been my guiding light in this regard for my 37 (gulp) years at vendors. 
When we break something, we try to do it visibly-e.g., a configuration option 
that fails at startup, rather than doing something unexpected. And it's 
documented, of course, AND in release notes.

 

Of course this is enterprise software, where folks can be expected to read 
release notes; if they don't, my sympathy is low. Consumer stuff, expectations 
are somewhat different.

 

Anyone who's dealt with the Python 2 to Python 3 mess should understand.

 

...phsiii


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Peter Relson]

That should just be made a syntax error.  I have no sympathy for the
"compatibility" argument.


I on the other hand do have sympathy. A highly significant reason that z/OS 
still exists (and the same could have been said for its predecessors OS/390 and 
MVS) is because of the enormous amount of time and effort we have put into 
maintaining as much compatibility as we can. We do not treat incompatibility 
lightly. We do try to keep down the number of upgrade actions needed to move to 
a new release.

For your concrete suggestions about improving the documentation (such as your 
examples), please make them via the appropriate feedback mechanisms, not via a 
post on IBM-MAIN.

Peter Relson
z/OS Core Technology Design


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Wed, 11 Oct 2023 15:44:39 +, Peter Relson wrote:
>
>As it happens, the offending sentence had already been removed from the 3.1 
>book. Since the thread started before those books were generally available to 
>be looked at, it's not surprising that that was not realized.
> 
I see that.  Thanks.

I searched the 3.1 JCL Ref. for "unpredictable".  I consider some remaining
instances inexcusable, such as:
Do not code TIME=0 on a JOB statement. The results are unpredictable.

That should just be made a syntax error.  I have no sympathy for the
"compatibility" argument.

If there is some uncertainty due to discretization, that should be mentioned
concisely.

As for nested symbols, there should be an edg case example, such as:
//  SET X=FOO,Y-BAR
//  SET  A=B
The equivalent JCL would be elaborated as:
//  SET  AFOO=BBAR

If I guessed wrong, that's a fortiori reason for clarification.

And, abridged from the Ref."
//EXAMPLE   PROC SYM1='Whats up, 
Doc?',SYM2=(DEF),SYM3=&&TEMP1,
//   SYM4='&TEMP2',SYM5=&TEMP3,TEMP3=TEMPNAME,
//   SYM6=
...
//DD3   DD   DSN=,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD4   DD   DSN=,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD5   DD   DSN=,UNIT=SYSALLDA,SPACE=(TRK,(1,1))
...
The equivalent JCL produced by the substitution, when the procedure is 
expanded, is:
...
//DD4   DD   DSN=,UNIT=SYSDA,SPACE=(TRK,(1,1))
(It fails to show the equivalent JCL for DD5.)

It would be a valuable clarification to state that DD4 names a
temporary data set.  I think.

• Symbols on JCL records are treated as if they resolved simultaneously. 

I'll assume the contrapositive:  Symbols on different JCL records
(It says "record", not "statement") are resolved sequentially.
So SYM6 should receive the value "TEMPNAME".

-- 
Thanks,
gil

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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Peter Relson]

Paul G wrote

I fear "unpredictable" is too often the writers' excuse when they don't know
the answer to a request for clarification and can't find out.


I don't think you will find that that is true in z/OS books. Writers do not 
make up usage of that word. They are asked to do so because the developers have 
told them that it is the situation. It might be that "style guidelines" suggest 
using "unpredictable" rather than something like "not defined". If anything, 
blame us the design/development folks, not the writers.

It is not worth the cost to try to create an exhaustive list of what happens 
(or could happen) if you were to do something that you're told not to do. It is 
rarely worth the cost even to create examples of what could happen. It can well 
be worth the cost to try to create a list of the things that you are allowed to 
do.

As it happens, the offending sentence had already been removed from the 3.1 
book. Since the thread started before those books were generally available to 
be looked at, it's not surprising that that was not realized.

If that had not happened, we would have investigated whether there were cases 
that we could document for which it would be OK to have JCL symbols used to 
define other JCL symbols.

I expect that somewhere the books describe what you get if you use a symbol and 
that symbol is not yet defined (I do not know exactly where that is). There are 
probably subtleties about "not yet defined" for cases where you (in effect) 
"undefine" a symbol (which I think you can do). It might be that the 
no-substitution-done case is "not defined now", covering both "not yet defined" 
and also "no longer defined".

Peter Relson
z/OS Core Technology Design


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Michael Oujesky]

Processing date from control card input is endemic to the financial 
industry, not just banks.


I believe it stems from the fact that "daily" processing occurs after midnight,

Michael


At 11:08 AM 10/8/2023, Paul Gilmartin wrote:


On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:

>To be honest I consider date-related variables as pooor when
>compared to batch scheduler features, especially ControlM (it is not
>advertisement, just opinion).
>
You worked for a bank.

I had a co-worker who had worked for a bank.  He told me that
certain reports were legally required on certain dates.  Failure
to meet a production window would not avoid a penalty.

To avoid the risk, he read the report date from a control record rather
than using the system date facility.  The readers never knew.

--
gil

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


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:

>To be honest I consider date-related variables as pooor when
>compared to batch scheduler features, especially ControlM (it is not
>advertisement, just opinion).
>
You worked for a bank.

I had a co-worker who had worked for a bank.  He told me that
certain reports were legally required on certain dates.  Failure
to meet a production window would not avoid a penalty.

To avoid the risk, he read the report date from a control record rather
than using the system date facility.  The readers never knew.

-- 
gil

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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 18:42:42 +, Farley, Peter wrote:

>I’ll admit I have NOT used symbol substitution in the “name” part (left of the 
>“=”) at all, only on the right (value) side, so the true answer is “I don’t 
>know”.  Never had a reason to use substitution in the “name” part.
>
However infrequently it's done, it should be documented and behave as 
documented.
If the effect is to "Determine Equivalent JCL" then perform the operation, no 
more
explanation is needed.

I find 16 uses of "unpredictable" in the JCL Ref., with the caveat:
Chapter 4. Syntax of parameters 
Note: You must follow the syntax rules in coding job control statements to 
achieve
specific results. If you do not follow the rules, you may get error 
messages or
unpredictable results. IBM does not support the use of statements or parame

I fear "unpredictable" is too often the writers' excuseo when they don't know
the answer to a request for clarification and can't find out.

>I also have never had reason/need to use JCL continuation for the “value” part 
>of a symbol definition, all my symbols have fairly short values.
>
My  concern about continuation relates not only to SET/PROC/EXEC, but to
any JCL statement where symbol substitution might change the content of
column 73.  Since symbols can't be continued (bad design), I couldn't simply
generate a long command string and break it into 71-column chunks.

-- 
gil

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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 13:10:36 -0500, Michael Oujesky wrote:

>Dynamic symbols (date/time) can be evaluated at different points in
>time during conversion, so if used multiple time in the JCL, they can
>resolve to different values.   My ROT was to never use a dynamic
>symbol more that once in coding and where it was needed multiple
>time, set it to my own date/time variable and then use that in the
>multiple instances it was needed.
> 
But the hazard exists for any two or more symbols whose values must
be coordinated such as DATE and TIME.  This could be done with a
single symbol containing both date and time with guaranteed block-
concurrent access.  I know of none such.

POSIX rename() and PDS STOW Replace provide the effect of
block-concurrent access to the content of a file.

-- 
gil

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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Radoslaw Skorupka]

To be honest I consider date-related variables as pooor when 
compared to batch scheduler features, especially ControlM (it is not 
advertisement, just opinion).

Justification:
More possibilities of when the date should be resolved. For example it 
can be "accounting date" - job should prepare report for 21-sept, but 
due to some events it was submitted day after. Etc. etc.
Date calculations. It can be "day before". Not just 21-1 (what happens 
on 1st?), but real date for "yesterday".
Summary of days (i.e. daily datasets concatenation) for each month. 
Despite it is 30 or 31 day. Or 28. Or 29.

...and more.


--
Radoslaw Skorupka
Lodz, Poland



W dniu 07.10.2023 o 20:42, Farley, Peter pisze:

I’ll admit I have NOT used symbol substitution in the “name” part (left of the 
“=”) at all, only on the right (value) side, so the true answer is “I don’t 
know”.  Never had a reason to use substitution in the “name” part.

I personally haven’t had reason to use dynamic system symbols that could change 
at midnight in production JCL, only in test JCL I was running during normal 
daytime business hours, and usually only the “date” symbols like LYYMMDD, not 
the “time” ones.  If I had to use them in production JCL I would probably use 
Michael Oujesky’s solution of assigning that system dynamic symbol once to a 
private symbol name and then use the private symbol name everywhere else it is 
needed.

I also have never had reason/need to use JCL continuation for the “value” part 
of a symbol definition, all my symbols have fairly short values.  I use a LOT 
of symbols in my test JCL for easy flexibility of running tests varying 
critical application parameter values and dataset names, with multiple symbols 
for each different part of the standardly-named files.  I can see that a symbol 
definition using multiple other symbols for the value could exceed column 71, 
but I haven’t had that need.

When I get a chance I will try the new feedback process.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Saturday, October 7, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E 
needed for installs?]


On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:




On 9/20/2023 8:23 AM, Farley, Peter wrote:

... JCL symbols as part of the definition of other JCL symbols works flawlessly 
every time.




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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Farley, Peter]

I’ll admit I have NOT used symbol substitution in the “name” part (left of the 
“=”) at all, only on the right (value) side, so the true answer is “I don’t 
know”.  Never had a reason to use substitution in the “name” part.

I personally haven’t had reason to use dynamic system symbols that could change 
at midnight in production JCL, only in test JCL I was running during normal 
daytime business hours, and usually only the “date” symbols like LYYMMDD, not 
the “time” ones.  If I had to use them in production JCL I would probably use 
Michael Oujesky’s solution of assigning that system dynamic symbol once to a 
private symbol name and then use the private symbol name everywhere else it is 
needed.

I also have never had reason/need to use JCL continuation for the “value” part 
of a symbol definition, all my symbols have fairly short values.  I use a LOT 
of symbols in my test JCL for easy flexibility of running tests varying 
critical application parameter values and dataset names, with multiple symbols 
for each different part of the standardly-named files.  I can see that a symbol 
definition using multiple other symbols for the value could exceed column 71, 
but I haven’t had that need.

When I get a chance I will try the new feedback process.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Saturday, October 7, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E 
needed for installs?]


On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:



>On 9/20/2023 8:23 AM, Farley, Peter wrote:

>> ... JCL symbols as part of the definition of other JCL symbols works 
>> flawlessly every time.

>

Is this true alike for substitution both in the name (left of the "=")

and in the value (right of the "=")?



In 
<https://www.ibm.com/docs/en/zos/3.1.0?topic=symbols-determining-equivalent-jcl>

Substitute all symbols.

...

Symbols on JCL records are treated as if they resolved simultaneously.



Peter Relson (IIRC) answered my question hers that near midnight 

and  might be resolved at a time when their values are inconsistent.

This requires some explanation of "simultaneously".  There ought to be

a lock to prevent this.  (REXX does it right.)



And some explanation of the effect of resolving a symbol changing the

content of column 72 from blank to non-blank or vice-versa.





>Agreed 100%. We use that feature all the time for in-house JCL and also

>for distributed product JCL.

>

>This seems like a golden opportunity to test the IBM Documentation

>Feedback process.

>

>Give it a try and let us know if you actually get a response...

>

Yes.



--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Michael Oujesky]

Dynamic symbols (date/time) can be evaluated at different points in 
time during conversion, so if used multiple time in the JCL, they can 
resolve to different values.   My ROT was to never use a dynamic 
symbol more that once in coding and where it was needed multiple 
time, set it to my own date/time variable and then use that in the 
multiple instances it was needed.


Michael

At 12:45 PM 10/7/2023, Paul Gilmartin wrote:


On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:

>On 9/20/2023 8:23 AM, Farley, Peter wrote:
>> ... JCL symbols as part of the definition of other JCL symbols 
works flawlessly every time.

>
Is this true alike for substitution both in the name (left of the "=")
and in the value (right of the "=")?

In 


Substitute all symbols.
...
Symbols on JCL records are treated as if they resolved simultaneously.

Peter Relson (IIRC) answered my question hers that near midnight 
and  might be resolved at a time when their values are inconsistent.
This requires some explanation of "simultaneously".  There ought to be
a lock to prevent this.  (REXX does it right.)

And some explanation of the effect of resolving a symbol changing the
content of column 72 from blank to non-blank or vice-versa.


>Agreed 100%. We use that feature all the time for in-house JCL and also
>for distributed product JCL.
>
>This seems like a golden opportunity to test the IBM Documentation
>Feedback process.
>
>Give it a try and let us know if you actually get a response...
>
Yes.

--
gil

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


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:

>On 9/20/2023 8:23 AM, Farley, Peter wrote:
>> ... JCL symbols as part of the definition of other JCL symbols works 
>> flawlessly every time. 
>
Is this true alike for substitution both in the name (left of the "=")
and in the value (right of the "=")?

In 

Substitute all symbols.
...
Symbols on JCL records are treated as if they resolved simultaneously.

Peter Relson (IIRC) answered my question hers that near midnight 
and  might be resolved at a time when their values are inconsistent.
This requires some explanation of "simultaneously".  There ought to be
a lock to prevent this.  (REXX does it right.)

And some explanation of the effect of resolving a symbol changing the
content of column 72 from blank to non-blank or vice-versa.


>Agreed 100%. We use that feature all the time for in-house JCL and also
>for distributed product JCL.
>
>This seems like a golden opportunity to test the IBM Documentation
>Feedback process.
>
>Give it a try and let us know if you actually get a response...
>
Yes.

-- 
gil

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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Ed Jaffe]

On 9/20/2023 8:23 AM, Farley, Peter wrote:

I believe that statement in the JCL Reference is in error and needs to be deleted 
or at the very least completely rewritten.  My quite substantial experience using 
this technique over the last 10-15 years is that using JCL symbols as part of the 
definition of other JCL symbols works flawlessly every time.  There is no 
unpredictability.  If the symbol used to define one symbol isn’t already defined, 
you get the literal “” value that you coded as part of the definition.  
This works for both SET and PROC and EXEC statements, without any failures or 
unpredictability that I have ever seen.  The resulting VALUE of that symbol may 
cause errors, but there is no unpredictability to the symbol definition process.


Agreed 100%. We use that feature all the time for in-house JCL and also 
for distributed product JCL.


This seems like a golden opportunity to test the IBM Documentation 
Feedback process.


Give it a try and let us know if you actually get a response...


--
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Phil Smith III]

Farley, Peter wrote:
>I believe that statement in the JCL Reference is in error and needs to
>be deleted or at the very least completely rewritten. My quite
>substantial experience using this technique over the last 10-15 years
>is that using JCL symbols as part of the definition of other JCL
>symbols works flawlessly every time. There is no unpredictability. If
>the symbol used to define one symbol isn't already defined, you get
>the literal "" value that you coded as part of the definition.
>This works for both SET and PROC and EXEC statements, without any
>failures or unpredictability that I have ever seen. The resulting
>VALUE of that symbol may cause errors, but there is no
>unpredictability to the symbol definition process.

>I cannot imagine any circumstance in which the result of defining one
>JCL symbol using another JCL symbol would ever be unpredictable.

>If there is any possible case where the result is unpredictable, IBM
>should be required to specify the circumstances and explain why.

I'd bet large coin that what this really means is "If you do this, you're 
likely to confuse yourself". As indeed you COULD-anyone who's gotten sloppy 
with Rexx stemmed variables (where this kind of usage is more common) has been 
burned that way! Of course in the examples Peter Hannigan provided, you're 
*trying* to play those games, so I think it's as safe as anything.


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

Thanks for changing the Subject: as the topic drifted.

On Wed, 20 Sep 2023 15:23:31 +, Farley, Peter wrote:

>I believe that statement in the JCL Reference is in error and needs to be 
>deleted or at the very least completely rewritten.  My quite substantial 
>experience using this technique over the last 10-15 years is that using JCL 
>symbols as part of the definition of other JCL symbols works flawlessly every 
>time.  ...
>
The Ref. is inconsistent in its terminology:

The SET statement contains one or more parameters:
symbolic-parameter=value[,symbolic parameter=value]...

clearly in:
>On Wed, 20 Sep 2023 04:12:20 +, Peter Hannigan wrote:
>>...
>>// SET A=' '
>>
Peter H. was specifying a symbol within a "symbolic-parameter",
not within the "value"
>
>
>  - Do not specify JCL symbols within other JCL symbols. The results
>can be unpredictable, especially if the imbedded JCL symbol is
>not previously defined.
>
For clarity, that should have said "symbolic-parameter", which
I assume was within its intended meaning, not simply "JCL
symbols within"

Regardless, I agree with both Peter F. and Peter H. that either
construct works provided that all  symbols are resolved according
to "Determining equivalent JCL" which should be cited here
unless it can be assumed to apply consistently throughout the Ref.

-- 
gil

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Mon, 17 Apr 2023 14:57:22 +, Seymour J Metz wrote:

>Sorry, that should be "That's not a GUPI."
> 
SDSF?


>>On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote:
>>>
>>>No. The only way to distinguish them is to scan the JCL or the internal text.

-- 
gil

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

Sorry, that should be "That's not a GUPI."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Seymour J Metz [sme...@gmu.edu]
Sent: Saturday, April 15, 2023 11:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

But that's not a


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, April 15, 2023 11:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Sun, 16 Apr 2023 02:42:46 +, Seymour J Metz wrote:

>I'm questioning "a program could determine that PARM was not specified".
>
... which you said it could do by "scan[ning] the JCL or the internal text."

>On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote:
>>
>>No. The only way to distinguish them is to scan the JCL or the internal text.

--
gil

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

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

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

But that's not a 


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, April 15, 2023 11:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Sun, 16 Apr 2023 02:42:46 +, Seymour J Metz wrote:

>I'm questioning "a program could determine that PARM was not specified".
>
... which you said it could do by "scan[ning] the JCL or the internal text."

>On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote:
>>
>>No. The only way to distinguish them is to scan the JCL or the internal text.

--
gil

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

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Sun, 16 Apr 2023 02:42:46 +, Seymour J Metz wrote:

>I'm questioning "a program could determine that PARM was not specified".
>
... which you said it could do by "scan[ning] the JCL or the internal text."

>On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote:
>>
>>No. The only way to distinguish them is to scan the JCL or the internal text.

-- 
gil

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

I'm questioning "a program could determine that PARM was not specified".


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, April 15, 2023 10:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote:

>> Meticulously distinguishing the case of PARM is absent from PARM='',
>> possibly because a program could determine that PARM was not
>> specified and take action different from PARM=''.
>
>No. The only way to distinguish them is to scan the JCL or the internal text.
>
Aren't you agreeing with me?  "The only way" implies that one way exists.

--
gil

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

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Sun, 16 Apr 2023 02:01:10 +, Seymour J Metz wrote:

>> Meticulously distinguishing the case of PARM is absent from PARM='',
>> possibly because a program could determine that PARM was not
>> specified and take action different from PARM=''.
>
>No. The only way to distinguish them is to scan the JCL or the internal text.
>
Aren't you agreeing with me?  "The only way" implies that one way exists.

-- 
gil

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

> Meticulously distinguishing the case of PARM is absent from PARM='',
> possibly because a program could determine that PARM was not
> specified and take action different from PARM=''.

No. The only way to distinguish them is to scan the JCL or the internal text.

> A competent programmer can know COBOL, C, PL/I, ...m but no Assembler. 

It helps if the languages that he knows are radically different from each other.

As for "adequately", the acid test is to have readers that don't already know 
OS/360 ... z/OS, and see whether *they* understand that all of the forms are 
equivalent.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, April 15, 2023 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Thu, 13 Apr 2023 17:01:40 -0600, Robert Raicer wrote:
>
>The z/OS MVS JCL Reference contains the prose shown below regarding
>the PARM parameter of the JCL EXEC PGM statement.  Yes, in order to
>understand the details you need to look at the referenced
>publication (z/OS MVS Programming:  Assembler Services Guide).
>
When you,and slightly later I, entered the MVS arena it was reasonably
expected that a competent programmer would know Assembler
language (some of our co-workers called it "BAL".) and understand the
control blocks it supported.  That's no longer true.  A competent
programmer can know COBOL, C, PL/I, ...m but no Assembler.  I've
written bash, C, and Rexx for Linux on ARM, but I know not a single
ARM machine instruction (I think it's little-endian.)

The JCL Ref. should be language-neutral and say:
Many programming languages allow a program to access the value
of the "subparameter".  The details should appear in a User's Guide
for the specific language.  If the PARM parameter is omitted, that
subparameter value will be the empty string, as if PARM='' had been
coded.

>...  Thus, a length field value of zero
>indicates no PARM text is present.
>
(Pedantic quibble on whether the length of a nonexistent string is defined.)

>If the PARM parameter is effectively not present on the JCL EXEC PGM
>statement the length field is zero.  This is the "default" value.
>
>The length field is also zero when the PARM parameter is present and
>its operand is an empty string, e.g., PARM=''.
>
Meticulously distinguishing the case of PARM is absent from PARM='',
possibly because a program could determine that PARM was not
specified and take action different from PARM=''.  I'd fail that in a
design review.

>...
>The area referenced by this 31-bit pointer value resides in
>24-bit addressable storage (this is not clearly documented).
>
In days of yore it was not necessary to specify such things.  COBOL
long evaded the problem by not supporting 64-bit.  Can you imagine
an AMODE=31 Assembler program that would fail accessing PARM
where AMODE=24 would succeed?

In:
Syntax
PARM[.procstepname]=subparameter
PARM[.procstepname]=(subparameter,subparameter)
PARM[.procstepname]=('subparameter',subparameter)
PARM[.procstepname]='subparameter,subparameter'

Does it specify adequately whether the parentheses, commas, and
apostrophes are passed to the program, whether nested sublists
are permitted, and that only one parameter string is passed?

--
gil

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

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Thu, 13 Apr 2023 17:01:40 -0600, Robert Raicer wrote:
>
>The z/OS MVS JCL Reference contains the prose shown below regarding
>the PARM parameter of the JCL EXEC PGM statement.  Yes, in order to
>understand the details you need to look at the referenced
>publication (z/OS MVS Programming:  Assembler Services Guide).
>  
When you,and slightly later I, entered the MVS arena it was reasonably
expected that a competent programmer would know Assembler
language (some of our co-workers called it "BAL".) and understand the
control blocks it supported.  That's no longer true.  A competent
programmer can know COBOL, C, PL/I, ...m but no Assembler.  I've
written bash, C, and Rexx for Linux on ARM, but I know not a single
ARM machine instruction (I think it's little-endian.)

The JCL Ref. should be language-neutral and say:
Many programming languages allow a program to access the value
of the "subparameter".  The details should appear in a User's Guide
for the specific language.  If the PARM parameter is omitted, that
subparameter value will be the empty string, as if PARM='' had been
coded.

>...  Thus, a length field value of zero
>indicates no PARM text is present.
>
(Pedantic quibble on whether the length of a nonexistent string is defined.)

>If the PARM parameter is effectively not present on the JCL EXEC PGM
>statement the length field is zero.  This is the "default" value.
>
>The length field is also zero when the PARM parameter is present and
>its operand is an empty string, e.g., PARM=''.
>
Meticulously distinguishing the case of PARM is absent from PARM='',
possibly because a program could determine that PARM was not
specified and take action different from PARM=''.  I'd fail that in a
design review.

>...
>The area referenced by this 31-bit pointer value resides in
>24-bit addressable storage (this is not clearly documented).
>
In days of yore it was not necessary to specify such things.  COBOL
long evaded the problem by not supporting 64-bit.  Can you imagine
an AMODE=31 Assembler program that would fail accessing PARM
where AMODE=24 would succeed?

In:
Syntax
PARM[.procstepname]=subparameter
PARM[.procstepname]=(subparameter,subparameter)
PARM[.procstepname]=('subparameter',subparameter)
PARM[.procstepname]='subparameter,subparameter'

Does it specify adequately whether the parentheses, commas, and
apostrophes are passed to the program, whether nested sublists
are permitted, and that only one parameter string is passed?

-- 
gil

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

Re: JCL EXEC PARM= default?

[Robert Raicer]

I am rather late adding to the topic discussion, so, apologies if my
information is essentially redundant.

The z/OS MVS JCL Reference contains the prose shown below regarding
the PARM parameter of the JCL EXEC PGM statement.  Yes, in order to
understand the details you need to look at the referenced
publication (z/OS MVS Programming:  Assembler Services Guide).

When the module specified as the operand of the PGM= parameter is
entered, GPR 1 contains the address of a 32-bit (fullword) pointer
aligned on a fullword boundary.

The low order 31-bits of this pointer contain the address of a
16-bit (halfword) binary unsigned integer "length" field aligned on
a halfword boundary which is not also a fullword boundary.
Immediately following the 16-bit length field is the text of the
operand of the PARM parameter.  The length field describes the true
length of the PARM text.  Thus, a length field value of zero
indicates no PARM text is present.

If the PARM parameter is effectively not present on the JCL EXEC PGM
statement the length field is zero.  This is the "default" value.

The length field is also zero when the PARM parameter is present and
its operand is an empty string, e.g., PARM=''.

This overall PARM data organization has been unchanged since
the introduction of OS/360 (many moons ago!).

There are a few things about this PARM convention which are not
clearly documented (at least, not clear to me).

.  The content of GPR 1 at entry to the PGM= module.

   I believe that regardless of the AMODE of the PGM= module, only
   the low order 32 bits (the "low" half of the 64-bit GPR) of GPR 1
   are valid and, further, the high order 8 bits of the low half of
   GPR 1 are all zero.  In other words, the area referenced by GPR 1
   resides in 24-bit addressable storage.

.  The pointer pointed to by GPR 1 at entry to the PGM= module.

   I believe that regardless of the AMODE of the PGM= module, only
   the low order 31 bits of this pointer value are valid.  The high
   order bit of this 32-bit pointer is '1'.  An AMODE 64 PGM= module
   must be set this bit to zero prior to its usage to reference
   storage (this is clearly documented).

   The area referenced by this 31-bit pointer value resides in
   24-bit addressable storage (this is not clearly documented).



Extraction from:

z/OS Version 2 Release 3
MVS JCL Reference

SA23-1385-30
Logical page 323, physical page 371.

PARM Parameter

Parameter Type:

Keyword, optional

Purpose:

Use the PARM parameter to pass variable information to the
processing program executed by this job step.  To use the
information, the processing program must contain instructions to
retrieve the information.

References:

For details on the format of the passed information and its
retrieval, see z/OS MVS Programming:  Assembler Services Guide.

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Thu, 6 Apr 2023 16:16:24 +, Peter Relson wrote:

>Gil asked if the location linked to by Shmuel is the right place for the doc 
>about the case of no PARM.
>
>... We don't want the information in multiple places, 
>
Usually I agree rather strongly with that principle.  It makes maintenance
of the document more robust with less effort and spares the user the
chore of reading multiple very similar descriptions, looking for minute
differences.  However ...

> and the linkage conventions section is a good place for it to land.
>
There's a joke that says, "A bore is a person who, if asked 'what time
is it?' would start telling you how to build a clock!"  For programmers
who want only to know what is the effect on their programs when
PARM= is omitted, Shmuel gave the right answer, "empty string".
Such people don't care about "linkage conventions" or the construction
of clocks.

The Services Guide says, "If the PARM field was omitted in the EXEC
statement, the count is set to zero."  If it further added the phrase,
"as if PARM=''" had been coded," I'd have to agree (grudgingly) the
right information for the target audience was provided, but in the
wrong place.  It belongs in the JCL Ref.

As for the RCF on function as opposed to content, the hyperlink
(anchor) on the HTML page works for me, as I suspect it does for you.
Can you use the hyperlink in the PDF document?  For me, it gives
""HTTP/1.1 400 Bad Request".  Does it work for anyone, with any
viewer?  If so, it's an SR for my viewer(s).  If not, it's an RCF for
Tech Dcs.

-- 
Thanks for your investigation,
gil

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

Re: JCL EXEC PARM= default?

[Peter Relson]

Gil asked if the location linked to by Shmuel is the right place for the doc 
about the case of no PARM.

To be clear, that location is here:
https://www.ibm.com/docs/en/zos/2.5.0?topic=list-program-in-primary-asc-mode
within the assembler services guide linkage conventions section.

This is the right place. But only because the place you'd look (the JCL book's 
definition for PARM and PARMDD) links to it. We don't want the information in 
multiple places, and the linkage conventions section is a good place for it to 
land.
Thanks to the question, we noticed that the links from PARM and PARMDD are not 
the same (PARM's link gets you to the book itself with no information about 
where in the book - I hate that). PARMDD's link gets you to the containing 
section
https://www.ibm.com/docs/en/zos/2.5.0?topic=conventions-passing-information-through-parameter-list

That's a lot better because it's a lot closer. At a minimum, we'll update the 
two to be consistent.

If I were guiding someone to this area, in words, I'd say go to the assembler 
services guide's section for conventions for passing information through a 
parameter list, and then to the subsection for a program in primary ASC mode. 
I'd have the link be to that specific section. I don't know if the link'ing 
functionality works that way, but that's my goal anyway.

Peter Relson
z/OS Core Technology Design


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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

Yes, I have had issues using copy link, and find it more reliable and then copy 
from the URL field. Also, I edit the domain name to make it generic, e.g., 
www-40 to www.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, April 6, 2023 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Thu, 6 Apr 2023 14:01:24 +, Seymour J Metz wrote:

>I've always seen cut used as a generic term for both C-C/C-V and C-X/C-V.
>
I'll be pedantic.  "cut" deletes the selected string.

>I find the relevant material in the manual, copy the URL from the URL line, 
>and manually type the fragment.
>
Ah!  So you did *not* click on/copy from the hyperlink from the JCLRef. to the
Services Gulde.  When I do that, depending on viewer (the best I have is
Firefox), I get:
   
<https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zos_common/ieaa600_v2r5.pdf#ieaa600_v2r5>

which gives:  HTTP/1.1 400 Bad Request

--
Thanks,
gil

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

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Thu, 6 Apr 2023 14:01:24 +, Seymour J Metz wrote:

>I've always seen cut used as a generic term for both C-C/C-V and C-X/C-V.
>
I'll be pedantic.  "cut" deletes the selected string.

>I find the relevant material in the manual, copy the URL from the URL line, 
>and manually type the fragment.
>
Ah!  So you did *not* click on/copy from the hyperlink from the JCLRef. to the
Services Gulde.  When I do that, depending on viewer (the best I have is
Firefox), I get:
   


which gives:  HTTP/1.1 400 Bad Request

-- 
Thanks,
gil

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

I've always seen cut used as a generic term for both C-C/C-V and C-X/C-V.

I find the relevant material in the manual, copy the URL from the URL line, and 
manually type the fragment.





From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 5, 2023 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 17:51:22 +, Seymour J Metz  wrote:

>Yes.
>
>Cut and paste.
>
"Cut" (ITYM "Copy") from where?  (I'm trying do decide whether it's
worth an RCF to ibmd...@us.ibm.com)

>
>From: Paul Gilmartin
>Sent: Wednesday, April 5, 2023 1:04 PM
>
>On Wed, 5 Apr 2023 16:48:35 +, Seymour J Metz  wrote:
>
>>The fragment page= is the normal way to request a specific page within a PDF, 
>>but the number is the sequential page within the PDF rather than the number 
>>on the page. Your PDF viewer should show you that number.
>>
>When you click (with what viewer?) on the URL you posted, does it actually open
>a PDF document to that page?
>
>What tool generated that URL?

>>On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote:
>>
>>><https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231368/$file/ieaa600_v2r5.pdf#page=52>

--
gil

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

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

Re: RCF address [was: RE: JCL EXEC PARM= default?]

[Steve Thompson]

I have had the different RCF addresses respond over night to a 
week or so later depending on time of year and other scheduling 
(internal to IBM). But they have gotten back to me.


Steve Thompson

On 4/5/2023 4:22 PM, Bob Bridges wrote:

FWIW, I've sent comments to the ibmdocs address from time to time over the 
years, and they've always responded, always in less than a week but never 
(IIRC) the next day.  Never tried the mhvrcfs address, that I recall.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Every year, on April 15, all members of Congress would be placed in 
individual prison cells with the necessary tax forms and a copy of the Tax 
Code. They would remain locked in the cells, without food or water, until they 
had completed their tax returns and successfully undergone a full IRS audit. Of 
course this system would probably result in a severe shortage of 
congresspersons. But there might also be some drawbacks. -Dave Barry's plan to 
simplify the tax code, 2000-04-09 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Wednesday, April 5, 2023 15:18

In the latest (V2R5) "Callable Services for HLL's" manual the RCF address is still 
documented as mhvr...@us.ibm.com not the "ibmdocs" address you mentioned.

Do you know which one is correct please?  I sent one to the "mhvrcfs" address 
yesterday but have received no reply or acknowledgement yet.

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


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

Re: RCF address [was: RE: JCL EXEC PARM= default?]

[Farley, Peter]

Thanks, I see no such dual-wording in the "Callable Services" manual, there 
only the "mhvrcfs" link is provided.  My RCF concerns content (or lack thereof) 
so I guess I used the right address after all.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, April 5, 2023 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RCF address [was: RE: JCL EXEC PARM= default?]

On Wed, 5 Apr 2023 19:17:45 +, Farley, Peter  wrote:
>
>In the latest (V2R5) "Callable Services for HLL's" manual the RCF address is 
>still documented as mhvr...@us.ibm.com not the "ibmdocs" address you mentioned.
>
>Do you know which one is correct please?  I sent one to the "mhvrcfs" address 
>yesterday but have received no reply or acknowledgement yet.
>
Are you surprised?

Both.  From the JCL Ref.  How to send your comments to IBM
Feedback on IBM® Documentation function
If your comment or question is about the IBM Documentation
functionality, for example search capabilities or how to
arrange the browser view, send a detailed email to IBM
Documentation Support at ibmd...@us.ibm.com.

Feedback on the z/OS product documentation and content
If your comment is about the information that is provided in
the z/OS product documentation library, send a detailed
email to mhvr...@us.ibm.com. We welcome any feedback that
you have, including comments on the clarity, accuracy, or
completeness of the information.

I feel my concern is mor "functio" than "content": hyperlink doesn't work for 
me..

-- 

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RCF address [was: RE: JCL EXEC PARM= default?]

[Bob Bridges]

FWIW, I've sent comments to the ibmdocs address from time to time over the 
years, and they've always responded, always in less than a week but never 
(IIRC) the next day.  Never tried the mhvrcfs address, that I recall.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Every year, on April 15, all members of Congress would be placed in 
individual prison cells with the necessary tax forms and a copy of the Tax 
Code. They would remain locked in the cells, without food or water, until they 
had completed their tax returns and successfully undergone a full IRS audit. Of 
course this system would probably result in a severe shortage of 
congresspersons. But there might also be some drawbacks. -Dave Barry's plan to 
simplify the tax code, 2000-04-09 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Wednesday, April 5, 2023 15:18

In the latest (V2R5) "Callable Services for HLL's" manual the RCF address is 
still documented as mhvr...@us.ibm.com not the "ibmdocs" address you mentioned.

Do you know which one is correct please?  I sent one to the "mhvrcfs" address 
yesterday but have received no reply or acknowledgement yet.

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

Re: RCF address [was: RE: JCL EXEC PARM= default?]

[Paul Gilmartin]

On Wed, 5 Apr 2023 19:17:45 +, Farley, Peter  wrote:
>
>In the latest (V2R5) "Callable Services for HLL's" manual the RCF address is 
>still documented as mhvr...@us.ibm.com not the "ibmdocs" address you mentioned.
>
>Do you know which one is correct please?  I sent one to the "mhvrcfs" address 
>yesterday but have received no reply or acknowledgement yet.
>
Are you surprised?

Both.  From the JCL Ref.  How to send your comments to IBM
Feedback on IBM® Documentation function
If your comment or question is about the IBM Documentation
functionality, for example search capabilities or how to
arrange the browser view, send a detailed email to IBM
Documentation Support at ibmd...@us.ibm.com.

Feedback on the z/OS product documentation and content
If your comment is about the information that is provided in
the z/OS product documentation library, send a detailed
email to mhvr...@us.ibm.com. We welcome any feedback that
you have, including comments on the clarity, accuracy, or
completeness of the information.

I feel my concern is mor "functio" than "content": hyperlink doesn't work for 
me..

-- 
gil

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

RCF address [was: RE: JCL EXEC PARM= default?]

[Farley, Peter]

Gil,

In the latest (V2R5) "Callable Services for HLL's" manual the RCF address is 
still documented as mhvr...@us.ibm.com not the "ibmdocs" address you mentioned.

Do you know which one is correct please?  I sent one to the "mhvrcfs" address 
yesterday but have received no reply or acknowledgement yet.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, April 5, 2023 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 17:51:22 +, Seymour J Metz  wrote:

>Yes.
>
>Cut and paste.
>
"Cut" (ITYM "Copy") from where?  (I'm trying do decide whether it's worth an 
RCF to ibmd...@us.ibm.com)
--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Wed, 5 Apr 2023 17:51:22 +, Seymour J Metz  wrote:

>Yes.
>
>Cut and paste.
>
"Cut" (ITYM "Copy") from where?  (I'm trying do decide whether it's
worth an RCF to ibmd...@us.ibm.com)

>
>From: Paul Gilmartin
>Sent: Wednesday, April 5, 2023 1:04 PM
>
>On Wed, 5 Apr 2023 16:48:35 +, Seymour J Metz  wrote:
>
>>The fragment page= is the normal way to request a specific page within a PDF, 
>>but the number is the sequential page within the PDF rather than the number 
>>on the page. Your PDF viewer should show you that number.
>>
>When you click (with what viewer?) on the URL you posted, does it actually open
>a PDF document to that page?
>
>What tool generated that URL?

>>On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote:
>>
>>>

-- 
gil

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

Re: JCL EXEC PARM= default?

[A T & T Management]

 The default is nothing or i.e. Parm=''

Scott

On Wednesday, April 5, 2023 at 02:03:57 PM EDT, Peter Sylvester 
 wrote:  
 
 On 05/04/2023 19:41, Gibney, Dave wrote:
> I agree that it's a fullword of zeros. But, this demonstration is not JCL

In memory only the first halfword "counts". But since the area of the halfword 
is somewhere not just 
2 bytes of the end of the page, and L shows 4 bytes ..

The calling conventions of test and jcl are not different unless during the 
last 49 years I have 
missed a change (which would have created some not so small incompatibily 
problem.)

As S.M. said, everything after 2+length is irrelevant.


test 'sys1.linklib(iefbr14)' 'here we are'
TEST
l 1r
  1R  0002AF50
TEST
l 1r%
0002AF50.  8002AF54
TEST
l 1r%%
0002AF54.  000BC8C5
TEST
l 1r%% l(16)
0002AF54.  000BC8C5 D9C540E6 C540C1D9 C500
TEST
l 1r%% l(16) c
0002AF54.  ..HERE WE ARE...
TEST

Welcome in Colossal Cave. You are not yet at wit's end.

/P


>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Peter Sylvester
>> Sent: Wednesday, April 5, 2023 10:14 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: JCL EXEC PARM= default?
>>
>> [EXTERNAL EMAIL]
>>
>> test 'sys1.linklib(iefbr14)'
>> TEST
>> l 1R
>>    1R  0002AF60
>> TEST
>> l 1r%
>> 0002AF60.  8002AF64
>> TEST
>> l 1r%%
>> 0002AF64.  
>> TEST
>>
>>
>>
>>
>> On 05/04/2023 18:07, Seymour J Metz wrote:
>>>            DC    H'0'
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on
>> behalf of Gibney, Dave <03b5261cfd78-dmarc-
>> requ...@listserv.ua.edu>
>>> Sent: Wednesday, April 5, 2023 11:52 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: JCL EXEC PARM= default?
>>>
>>> So, R1 in
>>> //R EXEC PGM=IEFBR14
>>> points to ???
>>>
>>>> -Original Message-
>>>> From: IBM Mainframe Discussion List  On
>>>> Behalf Of Paul Gilmartin
>>>> Sent: Wednesday, April 5, 2023 8:47 AM
>>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>>> Subject: Re: JCL EXEC PARM= default?
>>>>
>>>> [EXTERNAL EMAIL]
>>>>
>>>> On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:
>>>>
>>>>> For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the
>>>> default is an empty string.
>>>> That was my guess.  Where did you find that documented?
>>>>
>>>>> 
>>>>> From:  Paul Gilmartin
>>>>> Sent: Wednesday, April 5, 2023 11:17 AM
>>>>>
>>>>> What's the default value for the optional PARM= on the JCL EXEC
>>>> statement?
>>>>> It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler
>>>> Services Guide.")
>>>>
>>>> --
>>>> gil
>>>>
>>>> --
>>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: JCL EXEC PARM= default?

[Peter Sylvester]

On 05/04/2023 19:41, Gibney, Dave wrote:

I agree that it's a fullword of zeros. But, this demonstration is not JCL


In memory only the first halfword "counts". But since the area of the halfword is somewhere not just 
2 bytes of the end of the page, and L shows 4 bytes ..


The calling conventions of test and jcl are not different unless during the last 49 years I have 
missed a change (which would have created some not so small incompatibily problem.)


As S.M. said, everything after 2+length is irrelevant.


test 'sys1.linklib(iefbr14)' 'here we are'
TEST
l 1r
 1R  0002AF50
TEST
l 1r%
0002AF50.  8002AF54
TEST
l 1r%%
0002AF54.  000BC8C5
TEST
l 1r%% l(16)
0002AF54.  000BC8C5 D9C540E6 C540C1D9 C500
TEST
l 1r%% l(16) c
0002AF54.  ..HERE WE ARE...
TEST

Welcome in Colossal Cave. You are not yet at wit's end.

/P





-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Peter Sylvester
Sent: Wednesday, April 5, 2023 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

[EXTERNAL EMAIL]

test 'sys1.linklib(iefbr14)'
TEST
l 1R
   1R  0002AF60
TEST
l 1r%
0002AF60.  8002AF64
TEST
l 1r%%
0002AF64.  
TEST




On 05/04/2023 18:07, Seymour J Metz wrote:

   DCH'0'


From: IBM Mainframe Discussion List  on

behalf of Gibney, Dave <03b5261cfd78-dmarc-
requ...@listserv.ua.edu>

Sent: Wednesday, April 5, 2023 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

So, R1 in
//R EXEC PGM=IEFBR14
points to ???


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Paul Gilmartin
Sent: Wednesday, April 5, 2023 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

[EXTERNAL EMAIL]

On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:


For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the

default is an empty string.
That was my guess.  Where did you find that documented?



From:  Paul Gilmartin
Sent: Wednesday, April 5, 2023 11:17 AM

What's the default value for the optional PARM= on the JCL EXEC

statement?

It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler

Services Guide.")

--
gil

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

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

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



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

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




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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

Yes.

Cut and paste.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 5, 2023 1:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 16:48:35 +, Seymour J Metz  wrote:

>The fragment page= is the normal way to request a specific page within a PDF, 
>but the number is the sequential page within the PDF rather than the number on 
>the page. Your PDF viewer should show you that number.
>
When you click (with what viewer?) on the URL you posted, does it actually open
a PDF document to that page?

What tool generated that URL?

52=22 with 30 pages of unnumbered frontmatter.


>On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote:
>
>><https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231368/$file/ieaa600_v2r5.pdf#page=52>
>
>" If the PARM field was omitted in
>the EXEC statement, the count is set to zero."

--
gil

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

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

Everything beyond the halfword of 0 is irrelevant.


From: IBM Mainframe Discussion List  on behalf of 
Peter Sylvester 
Sent: Wednesday, April 5, 2023 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?


test 'sys1.linklib(iefbr14)'
TEST
l 1R
  1R  0002AF60
TEST
l 1r%
0002AF60.  8002AF64
TEST
l 1r%%
0002AF64.  
TEST




On 05/04/2023 18:07, Seymour J Metz wrote:
>   DCH'0'
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Gibney, Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu>
> Sent: Wednesday, April 5, 2023 11:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL EXEC PARM= default?
>
> So, R1 in
> //R EXEC PGM=IEFBR14
> points to ???
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Paul Gilmartin
>> Sent: Wednesday, April 5, 2023 8:47 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: JCL EXEC PARM= default?
>>
>> [EXTERNAL EMAIL]
>>
>> On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:
>>
>>> For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the
>> default is an empty string.
>>>
>> That was my guess.  Where did you find that documented?
>>
>>> 
>>> From:  Paul Gilmartin
>>> Sent: Wednesday, April 5, 2023 11:17 AM
>>>
>>> What's the default value for the optional PARM= on the JCL EXEC
>> statement?
>>> It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler
>> Services Guide.")
>>
>> --
>> gil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: JCL EXEC PARM= default?

[Gibney, Dave]

I agree that it's a fullword of zeros. But, this demonstration is not JCL

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Peter Sylvester
> Sent: Wednesday, April 5, 2023 10:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL EXEC PARM= default?
> 
> [EXTERNAL EMAIL]
> 
> test 'sys1.linklib(iefbr14)'
> TEST
> l 1R
>   1R  0002AF60
> TEST
> l 1r%
> 0002AF60.  8002AF64
> TEST
> l 1r%%
> 0002AF64.  
> TEST
> 
> 
> 
> 
> On 05/04/2023 18:07, Seymour J Metz wrote:
> >   DCH'0'
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of Gibney, Dave <03b5261cfd78-dmarc-
> requ...@listserv.ua.edu>
> > Sent: Wednesday, April 5, 2023 11:52 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JCL EXEC PARM= default?
> >
> > So, R1 in
> > //R EXEC PGM=IEFBR14
> > points to ???
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Paul Gilmartin
> >> Sent: Wednesday, April 5, 2023 8:47 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: JCL EXEC PARM= default?
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:
> >>
> >>> For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the
> >> default is an empty string.
> >>>
> >> That was my guess.  Where did you find that documented?
> >>
> >>> 
> >>> From:  Paul Gilmartin
> >>> Sent: Wednesday, April 5, 2023 11:17 AM
> >>>
> >>> What's the default value for the optional PARM= on the JCL EXEC
> >> statement?
> >>> It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler
> >> Services Guide.")
> >>
> >> --
> >> gil
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: JCL EXEC PARM= default?

[Peter Sylvester]

test 'sys1.linklib(iefbr14)'
TEST
l 1R
 1R  0002AF60
TEST
l 1r%
0002AF60.  8002AF64
TEST
l 1r%%
0002AF64.  
TEST




On 05/04/2023 18:07, Seymour J Metz wrote:

  DCH'0'


From: IBM Mainframe Discussion List  on behalf of Gibney, 
Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 5, 2023 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

So, R1 in
//R EXEC PGM=IEFBR14
points to ???


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Paul Gilmartin
Sent: Wednesday, April 5, 2023 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

[EXTERNAL EMAIL]

On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:


For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the

default is an empty string.



That was my guess.  Where did you find that documented?



From:  Paul Gilmartin
Sent: Wednesday, April 5, 2023 11:17 AM

What's the default value for the optional PARM= on the JCL EXEC

statement?

It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler

Services Guide.")

--
gil

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

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

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




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

Re: JCL EXEC PARM= default?

[Steve Smith]

R1->A(xxx+x'8000')->H'0'

sas

On Wed, Apr 5, 2023 at 12:08 PM Seymour J Metz  wrote:

>  DCH'0'
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Gibney, Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu>
> Sent: Wednesday, April 5, 2023 11:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL EXEC PARM= default?
>
> So, R1 in
> //R EXEC PGM=IEFBR14
> points to ???
>
>

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Wed, 5 Apr 2023 16:48:35 +, Seymour J Metz  wrote:

>The fragment page= is the normal way to request a specific page within a PDF, 
>but the number is the sequential page within the PDF rather than the number on 
>the page. Your PDF viewer should show you that number.
>
When you click (with what viewer?) on the URL you posted, does it actually open
a PDF document to that page?

What tool generated that URL?

52=22 with 30 pages of unnumbered frontmatter.


>On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote:
>
>>
>
>" If the PARM field was omitted in
>the EXEC statement, the count is set to zero."

-- 
gil

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

The fragment page= is the normal way to request a specific page within a PDF, 
but the number is the sequential page within the PDF rather than the number on 
the page. Your PDF viewer should show you that number.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 5, 2023 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote:

><https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231368/$file/ieaa600_v2r5.pdf#page=52>

" If the PARM field was omitted in
the EXEC statement, the count is set to zero."

Good catch!  But is that a good place to document it?  Documentation
shouldn't be a treasure hunt, as if the writer had been traumatized
in utero by the first chapter of "Hitchhiker".

Did your viewer (which?) respect the URL fragment, "#page=52?"
I found the text on Page 22.

--
gil

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

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Wed, 5 Apr 2023 16:16:33 +, Seymour J Metz wrote:

>

" If the PARM field was omitted in
the EXEC statement, the count is set to zero."

Good catch!  But is that a good place to document it?  Documentation
shouldn't be a treasure hunt, as if the writer had been traumatized
in utero by the first chapter of "Hitchhiker".

Did your viewer (which?) respect the URL fragment, "#page=52?"
I found the text on Page 22.

-- 
gil

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

<https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5sa231368/$file/ieaa600_v2r5.pdf#page=52>

" If the PARM field was omitted in
the EXEC statement, the count is set to zero."


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 5, 2023 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:

>For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the default is 
>an empty string.
>
>
That was my guess.  Where did you find that documented?

>
>From:  Paul Gilmartin
>Sent: Wednesday, April 5, 2023 11:17 AM
>
>What's the default value for the optional PARM= on the JCL EXEC statement?
>It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler 
>Services Guide.")

--
gil

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

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

 DCH'0'


From: IBM Mainframe Discussion List  on behalf of 
Gibney, Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, April 5, 2023 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL EXEC PARM= default?

So, R1 in
//R EXEC PGM=IEFBR14
points to ???

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, April 5, 2023 8:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL EXEC PARM= default?
>
> [EXTERNAL EMAIL]
>
> On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:
>
> >For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the
> default is an empty string.
> >
> >
> That was my guess.  Where did you find that documented?
>
> >
> >From:  Paul Gilmartin
> >Sent: Wednesday, April 5, 2023 11:17 AM
> >
> >What's the default value for the optional PARM= on the JCL EXEC
> statement?
> >It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler
> Services Guide.")
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: JCL EXEC PARM= default?

[Gibney, Dave]

So, R1 in 
//R EXEC PGM=IEFBR14 
points to ???

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, April 5, 2023 8:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL EXEC PARM= default?
> 
> [EXTERNAL EMAIL]
> 
> On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:
> 
> >For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the
> default is an empty string.
> >
> >
> That was my guess.  Where did you find that documented?
> 
> >
> >From:  Paul Gilmartin
> >Sent: Wednesday, April 5, 2023 11:17 AM
> >
> >What's the default value for the optional PARM= on the JCL EXEC
> statement?
> >It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler
> Services Guide.")
> 
> --
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: JCL EXEC PARM= default?

[Paul Gilmartin]

On Wed, 5 Apr 2023 15:22:14 +, Seymour J Metz wrote:

>For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the default is 
>an empty string.
>
>
That was my guess.  Where did you find that documented?

>
>From:  Paul Gilmartin
>Sent: Wednesday, April 5, 2023 11:17 AM
>
>What's the default value for the optional PARM= on the JCL EXEC statement?
>It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler 
>Services Guide.")

-- 
gil

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

Re: JCL EXEC PARM= default?

[Seymour J Metz]

For EXEC PROC=, the default is no PARM override. For EXEC PGM=, the default is 
an empty string.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, April 5, 2023 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL EXEC PARM= default?

What's the default value for the optional PARM= on the JCL EXEC statement?
It doesn't appear in the JCL Ref.  (haven't checked the cited "Assembler 
Services Guide.")

--
gil

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

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

Re: JCL Procedure help

[Seymour J Metz]

My reading i that he wants to restrict JCL changes to the PROC.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 8, 2023 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL Procedure help

On Wed, 8 Feb 2023 14:14:47 +, Seymour J Metz  wrote:
>...
> 2. Make SYSIN in the swecond step a backwards reference to SYSIN in the first 
> step. I'm not sure whether that will work.
>
How about:
//JOBSTEP  EXEC  MYPROC
//STEP2.SYSIN  DD  *

(as in: 
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dd-name-field=05%7C01%7Csmetz3%40gmu.edu%7C7aa8d98dd80640e66d4808db0a1386ed%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638114851224515703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=F%2FmYcLD8d4Y2GvbuMfbEAoHP0yckQ2hkWQOuapuwSpU%3D=0>)

But is this a case where the requestor wants "Make it work without making
the necessary changes"?

--
gil

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

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

Re: JCL Procedure help

[Gibney, Dave]

Add a new first step. Which reads the SYSIN and passes it to the function (now 
3rd) step

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gadi Ben-Avi
> Sent: Wednesday, February 8, 2023 4:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCL Procedure help
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> I was asked to modify a procedure.
> Currently, the procedure has one step.
> This step receives input from SYSIN DD *
> 
> I was asked to add a step that would check that the JOB is running on the
> correct LPAR.
> I wrote a small REXX program that check the LPAR, and returns condition code
> 8 if it's not running on the correct LPAR.
> I then added an if statement that will run the original step if the previous
> condition code is 0, and if not will issue a message.
> 
> The problem is that now the SYSIN DD is allocated to the first step.
> I know I can code STEP.SYSIN to associate the SYSIN with correct step, but was
> wondering if there a way to code the procedure in a way so that I won't
> require changing the way the procedure is used.
> 
> We are running z/OS v2.3
> 
> Gadi
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: JCL Procedure help

[Paul Gilmartin]

On Wed, 8 Feb 2023 14:14:47 +, Seymour J Metz  wrote:
>...
> 2. Make SYSIN in the swecond step a backwards reference to SYSIN in the first 
> step. I'm not sure whether that will work.
>
How about:
//JOBSTEP  EXEC  MYPROC
//STEP2.SYSIN  DD  *

(as in: )

But is this a case where the requestor wants "Make it work without making
the necessary changes"?

-- 
gil

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

Re: JCL Procedure help

[Paul Gorlinsky]

There are static and dynamic System Symbols ... 
There is a JOBCLASS parm SysSym that ALLOWs or DISALLOWs the use of either of 
them.. if DISALLOW, none of these are available to the jobs with a class marked 
as such..

There is also a PARMLIB IEASYMxx that system programmers may add additional 
symbols...



Typical Statics:
   2   
  I1  
   LPR1
  Z1020400
   LOCAL   
 SYSRES  

Typical Dynamics
  08 
   154214 
   15 
 039
  USER001
 08 
  104214 
  10 
039
 42 
 02 
 14 
WED
 23 
 2023   
  230208 
  42 
  02 
  14 
 WED   
  23
  2023  
   230208

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

Re: JCL Procedure help

[Steve Smith]

I think that is the best idea, if changing the job JCL is an option.  But
it may be that it's more feasible to change one proc instead of who knows
how many jobs.  That's one of the reasons to have procs.

Also, I believe your "plexname" should be "systemname".

sas

On Wed, Feb 8, 2023 at 10:28 AM Sri h Kolusu  wrote:

> >> I was asked to add a step that would check that the JOB is running on
> the correct LPAR.
>
> Gadi,
>
> I agree with Mikael of using SYSAFF parm to route the JOB to that LPAR it
> needs to run. This will not only eliminate making any changes to the PROC
> and you don't need to add a rexx exec to determine the Lpar it is running
> in.
>
> So, change the Job in question to have the SYSAFF in either of these 2
> different ways
>
> //SAMPJCRD JOB (,,,),,SYSAFF=plexname,
> // MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=
> /*
>
> Or
>
> /*JOBPARM SYSAFF=plexname
>
> Thanks,
> Kolusu
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: JCL Procedure help

[Sri h Kolusu]

>> I was asked to add a step that would check that the JOB is running on the 
>> correct LPAR.

Gadi,

I agree with Mikael of using SYSAFF parm to route the JOB to that LPAR it needs 
to run. This will not only eliminate making any changes to the PROC and you 
don't need to add a rexx exec to determine the Lpar it is running in.

So, change the Job in question to have the SYSAFF in either of these 2 
different ways

//SAMPJCRD JOB (,,,),,SYSAFF=plexname,
// MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,NOTIFY=
/*

Or

/*JOBPARM SYSAFF=plexname

Thanks,
Kolusu


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

Re: JCL Procedure help

[Billy Ashton]

I agree with Steve's approach...since you want the job to be on a 
certain system, le the check be in the job. This keeps the proc 
concentrated on the work it needs and less cluttered.


Thank you and best regards,
Billy Ashton


-- Original Message --

From "Steve Smith" 

To IBM-MAIN@listserv.ua.edu
Date 2/8/2023 9:17:22 AM
Subject Re: JCL Procedure help


You can probably just invoke the original program in your REXX (ADDRESS
LINKMVS, etc.) when it's on the correct system.  Then your proc is still
one step.

sas

On Wed, Feb 8, 2023 at 8:56 AM Willy Jensen 
wrote:


 Since you are running a REXX anyway, that REXX could copy DDname SYSIN to
 a temporary dataset, which is then used for SYSIN in the 2nd step, A simple
 REPRO INFILE(SYSIN) OUTFILE(TEMP) should do it.




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


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

Re: JCL Procedure help

[Steve Smith]

You can probably just invoke the original program in your REXX (ADDRESS
LINKMVS, etc.) when it's on the correct system.  Then your proc is still
one step.

sas

On Wed, Feb 8, 2023 at 8:56 AM Willy Jensen 
wrote:

> Since you are running a REXX anyway, that REXX could copy DDname SYSIN to
> a temporary dataset, which is then used for SYSIN in the 2nd step, A simple
> REPRO INFILE(SYSIN) OUTFILE(TEMP) should do it.
>
>

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

Re: JCL Procedure help

[Seymour J Metz]

In addition to copying SYSIN, as a previous poster suggested, there are other 
options.

1. Let your REXX code call the application. As long as it doesn't need 
authorization or program control, that should work fine.

 2. Make SYSIN in the swecond step a backwards reference to SYSIN in the first 
step. I'm not sure whether that will work.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gadi Ben-Avi [gad...@malam.com]
Sent: Wednesday, February 8, 2023 7:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL Procedure help

Hi,
I was asked to modify a procedure.
Currently, the procedure has one step.
This step receives input from SYSIN DD *

I was asked to add a step that would check that the JOB is running on the 
correct LPAR.
I wrote a small REXX program that check the LPAR, and returns condition code 8 
if it's not running on the correct LPAR.
I then added an if statement that will run the original step if the previous 
condition code is 0, and if not will issue a message.

The problem is that now the SYSIN DD is allocated to the first step.
I know I can code STEP.SYSIN to associate the SYSIN with correct step, but was 
wondering if there a way to code the procedure in a way so that I won't require 
changing the way the procedure is used.

We are running z/OS v2.3

Gadi


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

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

Re: JCL Procedure help

[Willy Jensen]

Since you are running a REXX anyway, that REXX could copy DDname SYSIN to a 
temporary dataset, which is then used for SYSIN in the 2nd step, A simple REPRO 
INFILE(SYSIN) OUTFILE(TEMP) should do it.

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

Re: JCL Procedure help

[Mikael Nystrom]

Not an answer to your question, but have you looked at the JCL statements 
SYSTEM, SYSAFF or SCHENV?

//Mikael

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: den 8 februari 2023 13:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL Procedure help

Hi,
I was asked to modify a procedure.
Currently, the procedure has one step.
This step receives input from SYSIN DD *

I was asked to add a step that would check that the JOB is running on the 
correct LPAR.
I wrote a small REXX program that check the LPAR, and returns condition code 8 
if it's not running on the correct LPAR.
I then added an if statement that will run the original step if the previous 
condition code is 0, and if not will issue a message.

The problem is that now the SYSIN DD is allocated to the first step.
I know I can code STEP.SYSIN to associate the SYSIN with correct step, but was 
wondering if there a way to code the procedure in a way so that I won't require 
changing the way the procedure is used.

We are running z/OS v2.3

Gadi


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

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

Re: JCL // SET SYMBOL indirection

[Seymour J Metz]

Invent new opcodes, which is possible with SPIE, discover opcodes not in PoOps, 
or discover inadvertent opcodes? That last is what happened on the 7xx/70xx 
machines.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 2, 2023 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL // SET SYMBOL indirection

On Wed, 1 Feb 2023 13:52:56 +, Seymour J Metz  wrote:

>Or IBM knows something that you do not.
>
IBM guarantees that with their indolent documentation practice.
An example:
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dfield-relational-expression-keywords=05%7C01%7Csmetz3%40gmu.edu%7C1da89fa9fd864f3a589e08db05493a92%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109584311934619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3g1m25AvOGf%2F8FO0uBOdp%2BjKJ7hSq8XEKC8wqjNOoX8%3D=0>:
The following keywords are the only keywords supported by IBM and 
recommended
for use in relational-expressions. Any other keywords, even if accepted by 
the system,
are not intended or supported keywords.

It's been that way for too long to be "reserved for future function," as an IBM 
representative
has suggested here.

Rather, it reminds me of a colleague who lamented the announcement of the s/360 
with
its Operation Exception: "That means that I can't invent my own opcodes!"  as 
was customary
among IBM 70* hackers who delighted in black-box reverse-engineering the logic.

"Operation Exception" was a good invention.  JCL's failure to report syntax 
errors on
"not intended or supported keywords" is bad design.

--
gil

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

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

Re: JCL // SET SYMBOL indirection

[Paul Gilmartin]

On Wed, 1 Feb 2023 13:52:56 +, Seymour J Metz  wrote:

>Or IBM knows something that you do not.
>
IBM guarantees that with their indolent documentation practice.
An example:
:
The following keywords are the only keywords supported by IBM and 
recommended
for use in relational-expressions. Any other keywords, even if accepted by 
the system,
are not intended or supported keywords.

It's been that way for too long to be "reserved for future function," as an IBM 
representative
has suggested here.

Rather, it reminds me of a colleague who lamented the announcement of the s/360 
with
its Operation Exception: "That means that I can't invent my own opcodes!"  as 
was customary
among IBM 70* hackers who delighted in black-box reverse-engineering the logic.

"Operation Exception" was a good invention.  JCL's failure to report syntax 
errors on
"not intended or supported keywords" is bad design.

-- 
gil

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

Re: JCL // SET SYMBOL indirection

[Seymour J Metz]

Or IBM knows something that you do not.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, January 31, 2023 10:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL // SET SYMBOL indirection

On Wed, 1 Feb 2023 00:20:26 +, Farley, Peter wrote:

>Not necessarily what you may want, but this works:
>
>//SYM1 SET SYM1=VALUE1
>//SYM2 SET SYM2=VALUE2
>
>//TARGET   SET TARGET=
>
>//RESULT   SET RESULT=   (and end up with  being set to VALUE1 
>and not SYM1)
>
>I know Gil will complain the observed JCL symbol behavior (assigning the value 
>of (a) previously defined symbol(s) to another symbol) is not documented (and 
>it is not), but it definitely works.  I use this technique all the time in my 
>application testing JCL.
>
Yup.  I have complained in these pages that every possible construct should 
either be documented
as supported or result in a JCL error.  In reply, Peter Relson has sneered at 
me, saying that I
simply don't understand that constructs not documented but allowed should be 
regarded as for
IBM internal use, comparable to undocumented macro parameters, or reserved for 
future
extensions.  JCL feels qualitatively different to me; undocumented constructs 
should at least result
in warnings, or there should be a "PRO" option on the job statement, in the 
absence of which undocumented constructs should be reported as JCL errors.

But, like you, I experiment:
//  SET SYM3=' '  /* No substitution -- it's documented.  */
But:
//  SET Q='&'
//  SET SYM3=   /*  Substitution performed -- hardly 
documented.  */
But there may be errors reported for using  elsewhere, as in PARM=...

These behaviors should be documented, but IBM doesn't care.

--
gil

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

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

Re: JCL // SET SYMBOL indirection

[Paul Gilmartin]

On Wed, 1 Feb 2023 00:20:26 +, Farley, Peter wrote:

>Not necessarily what you may want, but this works:
>
>//SYM1 SET SYM1=VALUE1
>//SYM2 SET SYM2=VALUE2
>
>//TARGET   SET TARGET=
>
>//RESULT   SET RESULT=   (and end up with  being set to VALUE1 
>and not SYM1)
>
>I know Gil will complain the observed JCL symbol behavior (assigning the value 
>of (a) previously defined symbol(s) to another symbol) is not documented (and 
>it is not), but it definitely works.  I use this technique all the time in my 
>application testing JCL.
> 
Yup.  I have complained in these pages that every possible construct should 
either be documented
as supported or result in a JCL error.  In reply, Peter Relson has sneered at 
me, saying that I
simply don't understand that constructs not documented but allowed should be 
regarded as for
IBM internal use, comparable to undocumented macro parameters, or reserved for 
future
extensions.  JCL feels qualitatively different to me; undocumented constructs 
should at least result
in warnings, or there should be a "PRO" option on the job statement, in the 
absence of which undocumented constructs should be reported as JCL errors.

But, like you, I experiment:
//  SET SYM3=' '  /* No substitution -- it's documented.  */
But:
//  SET Q='&'
//  SET SYM3=   /*  Substitution performed -- hardly 
documented.  */
But there may be errors reported for using  elsewhere, as in PARM=...

These behaviors should be documented, but IBM doesn't care.

-- 
gil

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

Re: JCL // SET SYMBOL indirection

[Sri h Kolusu]

>>//RESULT   SET RESULT=&   (and end up with  being set to VALUE1 
>>and not SYM1)

Rob,

Try this

// EXPORT SYMLIST=*
//SYM1 SET SYM1=VALUE1
//SYM2 SET SYM2=VALUE2
//TARGET   SET TARGET=SYM1
//RESULT   SET RESULT=
/*
//STEP0100 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//LOGDD1   DD SYSOUT=*
//SYSUT1   DD *,SYMBOLS=(JCLONLY,LOGDD1)




//SYSUT2   DD SYSOUT=*
//SYSINDD DUMMY
/*


The output of this is

VALUE1
VALUE2
SYM1
SYM1


Thanks,
Kolusu


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

Re: JCL // SET SYMBOL indirection

[Bob Bridges]

I don't know about your question.  But herewith a brief side hike:

I have always been inclined to experiment with systems, hoping to find sense
in what seemed like senseless behavior and looking for shortcuts.
(Apparently I was born to be a programmer.)  When I was handed a form to
fill out, and the form appeared to be a copy of a copy of a too-many-times
copy, I wondered why people don't pay more attention to such things.  With
the advent of half-decent WYSIWYG software I took to creating my own
cleaned-up version of the same form, and using that instead, much to the
bemusement of the poor clerk who'd never seen that form.  If I tried
submitting a form with different information than was spelled out (hoping to
discover which fields were necessary and which were optional), I might be
asked "why do you want to do that?" and told "Don't waste my time playing!"

So when I discovered computer programming, I loved it that a computer never
asked me "why do you want to do that?" when I experimented with alternate
syntax on a command.  "Because I want to see what works, of course!", except
the machine didn't care.  It was wonderful.

Therefore when I gradually became a SME myself, subject to people asking how
to do something, for a long time I never asked "Why?", because I remember
how I disliked it myself.

Eventually, though, it dawned on me that in many cases - not all - if I find
out what the OP is trying to accomplish, and I point out that the better way
of doing it is thus and so, I've actually HELPED.  I still feel strongly
about letting people try things out to see what works, but if what they
really care about is finding a way that works, asking "Why do you want to do
that?" often leads to a better solution for them.

I'm not asking "Why?" in this case, because I don't care; I don't know the
answer anyway.  I'm just sayin'.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* There is not really any courage at all in attacking hoary or antiquated
things, any more than in offering to fight one's grandmother.  The really
courageous man is he who defies tyrannies young as the morning and
superstitions fresh as the first flowers.  The only true free-thinker is he
whose intellect is as much free from the future as from the past.  -from
"What's Wrong with the World" by G K Chesterton */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Robert Garrett
Sent: Tuesday, January 31, 2023 19:08

I love symbols.

I've been trying to figure out if a level of indirection is possible.
Here's an example that both doesn't work and isn't' even syntactically
correct, but hopefully will serve to illustrate what I'm trying to do:

//SYM1 SET SYM1=VALUE1
//SYM2 SET SYM2=VALUE2

//TARGET   SET TARGET=SYM1

//RESULT   SET RESULT=&   (and end up with  being set to
VALUE1 and not SYM1)

I know it'll be tempting to ask "why?" but trust me, I have a good reason.

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

Re: JCL // SET SYMBOL indirection

[Billy Ashton]

Unfortunately, you can not have "nested" symbols...just one and done.

Thank you and best regards,
Billy Ashton


-- Original Message --

From "Robert Garrett" 

To IBM-MAIN@listserv.ua.edu
Date 1/31/2023 7:07:31 PM
Subject JCL // SET SYMBOL indirection


I love symbols.

I've been trying to figure out if a level of indirection is possible.
Here's an example that both doesn't work and isn't' even syntactically correct, 
but hopefully will serve to illustrate what I'm trying to do:

//SYM1 SET SYM1=VALUE1
//SYM2 SET SYM2=VALUE2

//TARGET   SET TARGET=SYM1

//RESULT   SET RESULT=&   (and end up with  being set to VALUE1 
and not SYM1)

I know it'll be tempting to ask "why?" but trust me, I have a good reason.

Thanks,
Rob

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


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

Re: JCL // SET SYMBOL indirection

[Farley, Peter]

Not necessarily what you may want, but this works:

//SYM1 SET SYM1=VALUE1
//SYM2 SET SYM2=VALUE2

//TARGET   SET TARGET=

//RESULT   SET RESULT=   (and end up with  being set to VALUE1 
and not SYM1)

I know Gil will complain the observed JCL symbol behavior (assigning the value 
of (a) previously defined symbol(s) to another symbol) is not documented (and 
it is not), but it definitely works.  I use this technique all the time in my 
application testing JCL.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Garrett
Sent: Tuesday, January 31, 2023 7:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL // SET SYMBOL indirection

I love symbols.

I've been trying to figure out if a level of indirection is possible.
Here's an example that both doesn't work and isn't' even syntactically correct, 
but hopefully will serve to illustrate what I'm trying to do:

//SYM1 SET SYM1=VALUE1
//SYM2 SET SYM2=VALUE2

//TARGET   SET TARGET=SYM1

//RESULT   SET RESULT=&   (and end up with  being set to VALUE1 
and not SYM1)

I know it'll be tempting to ask "why?" but trust me, I have a good reason.

Thanks,
Rob
--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL Output statement question

[Paul Gilmartin]

On Tue, 6 Dec 2022 07:06:01 +, Gadi Ben-Avi wrote:
>...
>We have a series of jobs (Control-D print missions) that allocate output DD 
>statements dynamically.
>
>We coded an OUTPUT Statement with DEFAULT=YES in these jobs with INTRAY=2, but 
>this doesn't seem to work.
>
>Should it be working?
> 
Is iit from IBM?

The JCL Ref. mentions DD SYSOUT statements repeatedly, not dynamic
allocation in connection with DEFAULT.

Apparently WAD by IBM, not what's useful.

-- gil

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

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

On Fri, 7 Jan 2022 20:30:03 +, Seymour J Metz wrote:

>> Would it be a favor to programmers to make misiplacing IF, etc.
>> within a job step, or SET within IF ... ENDIF a syntax error?  The
>> effect is probably not what the programmers intend.
>
>IMHO, the current behavior is a bug, but it might take an RFE to get it fixed, 
>and IBM might add a compatibility option for installations that depend on the 
>old behavior. It should at least generate a warning.
> 
Options, compatibility or otherwise, geometrically multiply the testing
burden for software suppliers.

-- gil

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

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> Would it be a favor to programmers to make misiplacing IF, etc.
> within a job step, or SET within IF ... ENDIF a syntax error?  The
> effect is probably not what the programmers intend.

IMHO, the current behavior is a bug, but it might take an RFE to get it fixed, 
and IBM might add a compatibility option for installations that depend on the 
old behavior. It should at least generate a warning.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, January 7, 2022 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python 
instead of REXX for z/OS

On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote:
>
>... I was just
>working on some JCL and I had just assumed that I
>could set symbolics using IF THEN ELSE ENDIF:
>
>// IF (STEP1.RC = 0) THEN
>//  SYMB=GOOD
>// ELSE
>//  SYMB=BAD
>// ENDIF
>
>but I found out that BOTH SET statements are executed
>no matter what the return code is .
>
Even as in assembler it doesn't work to BC bypassing a SETC.  The JCL
Ref. is perhaps to specific in listing instructions that are not subject
to IF ... ENDIF rather than describing which control the Converter and
which control the Initiator.

>It also appears to me that I cannot put just one DD
>within an IF statement. It looks an entire step has
>to be in there... I think...
>
And it's truly confusing that if a DD statement is in a step bypassed
by IF (or COND=) allocation, deletion, or cataloging is not performed
but the ENQ SYSDSN is still issued.

Would it be a favor to programmers to make misiplacing IF, etc.
within a job step, or SET within IF ... ENDIF a syntax error?  The
effect is probably not what the programmers intend.

-- gil

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

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

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

The Initiator does the ENQ, not JES. By that time the Converter and Interpreter 
have already run. The condition code is unknown until the job actually runs, 
far too late for the Converter to examine it. The issue transcends the ENQ.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Hobart Spitz [orexx...@gmail.com]
Sent: Friday, January 7, 2022 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python 
instead of REXX for z/OS

I think it's worth mentioning that the reason that SET must be
unconditional is that JES has to issue ENQs after, AFAIK, the initial JCL
scan and before execution starts.  If a dataset has an embedded symbolic,
doing the correct ENQ when the value might change at execution time could
cause all kinds of problems, not the least of which is not ENQing on the
intended data set name.

REXX is the new JCL.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Fri, Jan 7, 2022 at 11:50 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote:
> >
> >... I was just
> >working on some JCL and I had just assumed that I
> >could set symbolics using IF THEN ELSE ENDIF:
> >
> >// IF (STEP1.RC = 0) THEN
> >//  SYMB=GOOD
> >// ELSE
> >//  SYMB=BAD
> >// ENDIF
> >
> >but I found out that BOTH SET statements are executed
> >no matter what the return code is .
> >
> Even as in assembler it doesn't work to BC bypassing a SETC.  The JCL
> Ref. is perhaps to specific in listing instructions that are not subject
> to IF ... ENDIF rather than describing which control the Converter and
> which control the Initiator.
>
> >It also appears to me that I cannot put just one DD
> >within an IF statement. It looks an entire step has
> >to be in there... I think...
> >
> And it's truly confusing that if a DD statement is in a step bypassed
> by IF (or COND=) allocation, deletion, or cataloging is not performed
> but the ENQ SYSDSN is still issued.
>
> Would it be a favor to programmers to make misiplacing IF, etc.
> within a job step, or SET within IF ... ENDIF a syntax error?  The
> effect is probably not what the programmers intend.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Hobart Spitz]

I think it's worth mentioning that the reason that SET must be
unconditional is that JES has to issue ENQs after, AFAIK, the initial JCL
scan and before execution starts.  If a dataset has an embedded symbolic,
doing the correct ENQ when the value might change at execution time could
cause all kinds of problems, not the least of which is not ENQing on the
intended data set name.

REXX is the new JCL.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Fri, Jan 7, 2022 at 11:50 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote:
> >
> >... I was just
> >working on some JCL and I had just assumed that I
> >could set symbolics using IF THEN ELSE ENDIF:
> >
> >// IF (STEP1.RC = 0) THEN
> >//  SYMB=GOOD
> >// ELSE
> >//  SYMB=BAD
> >// ENDIF
> >
> >but I found out that BOTH SET statements are executed
> >no matter what the return code is .
> >
> Even as in assembler it doesn't work to BC bypassing a SETC.  The JCL
> Ref. is perhaps to specific in listing instructions that are not subject
> to IF ... ENDIF rather than describing which control the Converter and
> which control the Initiator.
>
> >It also appears to me that I cannot put just one DD
> >within an IF statement. It looks an entire step has
> >to be in there... I think...
> >
> And it's truly confusing that if a DD statement is in a step bypassed
> by IF (or COND=) allocation, deletion, or cataloging is not performed
> but the ENQ SYSDSN is still issued.
>
> Would it be a favor to programmers to make misiplacing IF, etc.
> within a job step, or SET within IF ... ENDIF a syntax error?  The
> effect is probably not what the programmers intend.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote:
>
>... I was just 
>working on some JCL and I had just assumed that I 
>could set symbolics using IF THEN ELSE ENDIF:
>
>// IF (STEP1.RC = 0) THEN
>//  SYMB=GOOD
>// ELSE
>//  SYMB=BAD
>// ENDIF
>
>but I found out that BOTH SET statements are executed
>no matter what the return code is . 
> 
Even as in assembler it doesn't work to BC bypassing a SETC.  The JCL
Ref. is perhaps to specific in listing instructions that are not subject
to IF ... ENDIF rather than describing which control the Converter and
which control the Initiator.

>It also appears to me that I cannot put just one DD
>within an IF statement. It looks an entire step has
>to be in there... I think...
> 
And it's truly confusing that if a DD statement is in a step bypassed
by IF (or COND=) allocation, deletion, or cataloging is not performed
but the ENQ SYSDSN is still issued.

Would it be a favor to programmers to make misiplacing IF, etc. 
within a job step, or SET within IF ... ENDIF a syntax error?  The
effect is probably not what the programmers intend.

-- gil

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

Re: JCL (was: Python ... REXX)

[Pommier, Rex]

I'm sure there are several places that would copy a 6250bpi tape to a different 
medium.  I would think the bigger problem would be whether the tape is even 
readable or if too much of the iron oxide has already fallen on the floor.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Thursday, January 6, 2022 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: JCL (was: Python ... REXX)

Reading 6250BPI minireels into new formats isn’t as hard as you may think . . . 
 There are places that could do it for you at a reasonable price, and some 
people will do it gratis . . . 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, January 6, 2022 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL (was: Python ... REXX)

Peter Farley asked:

>Ahh!  But did you save a copy of the tape?  (Not that you could share 
>them
with anyone anyway, I was just curious - as an invulnerable young 
whippersnapper I would have done so and not told anyone either . . .
without ever considering the possible consequences.  Such is youth.)

 I can neither confirm nor deny (kidding). If I had saved it, it would have 
been a 6250BPI minireel. Good luck reading that 25+ years later! IBM Sterling 
Forest, here we come?
--

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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Charles Mills]

Yeah, IF is EXEC COND in a different suit of clothes. It must control an entire 
jobstep. :-(

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nash, Jonathan S.
Sent: Thursday, January 6, 2022 8:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python 
instead of REXX for z/OS


Its funny you should mention that now. I was just 
working on some JCL and I had just assumed that I 
could set symbolics using IF THEN ELSE ENDIF:

// IF (STEP1.RC = 0) THEN
//  SYMB=GOOD
// ELSE
//  SYMB=BAD
// ENDIF

but I found out that BOTH SET statements are executed
no matter what the return code is . 

It also appears to me that I cannot put just one DD
within an IF statement. It looks an entire step has
to be in there... I think...

too bad...

It would be nice the other way...

 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Andrew Rowley
Sent: Thursday, January 06, 2022 10:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: ... Re: Top 8 Reasons for using Python instead of REXX 
for z/OS

On 7/01/2022 12:23 pm, David Crayford wrote:
>
> I understand that it's declarative. But it has logic such as IF/THEN. 
> That is no reason why it couldn't have been a scripting language like 
> CL on AS/400.
>
IF/THEN was a late addition, and is probably one of the biggest problems 
with JCL because it doesn't work like IF/THEN in a programming language. 
IF/THEN is really a property of the enclosed steps (I suspect it 
generates the same thing as equivalent COND statements on the steps) 
rather than a logical block in the JCL.

e.g. from the JCL reference:

The system processes the following statements regardless of the logic of 
the IF/THEN/ELSE/ENDIF
statement construct. They can be placed in a THEN or ELSE clause, but 
they are not executed
conditionally.
• PROC and PEND statements
• JES2 and JES3 statements and commands
• JCL command statements
• Comment (//*) statements
• INCLUDE statements
• Delimiter (/*) statements
• Null statements
• SET statements

The IF/THEN/ELSE/ENDIF statement construct does not conditionally 
control the processing of JCL; rather, it conditionally controls the 
execution of job steps.


-- 
Andrew Rowley
Black Hill Software

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

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

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

Re: JCL (was: Python ... REXX)

[Farley, Peter x23353]

Reading 6250BPI minireels into new formats isn’t as hard as you may think . . . 
 There are places that could do it for you at a reasonable price, and some 
people will do it gratis . . . 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, January 6, 2022 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL (was: Python ... REXX)

Peter Farley asked:

>Ahh!  But did you save a copy of the tape?  (Not that you could share 
>them
with anyone anyway, I was just curious - as an invulnerable young 
whippersnapper I would have done so and not told anyone either . . .
without ever considering the possible consequences.  Such is youth.)

 I can neither confirm nor deny (kidding). If I had saved it, it would have 
been a 6250BPI minireel. Good luck reading that 25+ years later! IBM Sterling 
Forest, here we come?
--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL (was: Python ... REXX)

[Phil Smith III]

Peter Farley asked:

>Ahh!  But did you save a copy of the tape?  (Not that you could share them
with anyone anyway, I was just curious - as an invulnerable young
whippersnapper I would have done so and not told anyone either . . .
without ever considering the possible consequences.  Such is youth.)

 

I can neither confirm nor deny (kidding). If I had saved it, it would have
been a 6250BPI minireel. Good luck reading that 25+ years later! IBM
Sterling Forest, here we come?


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

Re: JCL (was: Python ... REXX)

[Farley, Peter x23353]

Ahh!  But did you save a copy of the tape?  (Not that you could share them with 
anyone anyway, I was just curious - as an invulnerable young whippersnapper I 
would have done so and not told anyone either . . .  without ever considering 
the possible consequences.  Such is youth.)

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, January 6, 2022 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL (was: Python ... REXX)

At one point in the 1990s, IBM PartnerWorld started charging a $5K/year fee.
We ponied up. One of the benefits was that you could now get the PL/X (or maybe 
PL/AS by then) compiler, so I requested and got it.

 A few months later they reversed the decision about the $5K and I got a call 
explaining that we were one of the few members who had taken advantage of 
getting the PL/X compiler, and that Endicott had had to pay Raleigh a license 
fee for it. That meant that I got to go to my boss with a good news/bad news 
story: that we were getting MOST of our money back. Still makes me laugh.

 I never did get around to installing the compiler!
--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL (was: Python ... REXX)

[Phil Smith III]

At one point in the 1990s, IBM PartnerWorld started charging a $5K/year fee.
We ponied up. One of the benefits was that you could now get the PL/X (or
maybe PL/AS by then) compiler, so I requested and got it.

 

A few months later they reversed the decision about the $5K and I got a call
explaining that we were one of the few members who had taken advantage of
getting the PL/X compiler, and that Endicott had had to pay Raleigh a
license fee for it. That meant that I got to go to my boss with a good
news/bad news story: that we were getting MOST of our money back. Still
makes me laugh.

 

I never did get around to installing the compiler!


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

Re: JCL (was: Python ... REXX)

[Charles Mills]

I remember the offer. We decided not to avail ourselves. Did not wish to 
"invest" in an unsupported product.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, January 6, 2022 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL (was: Python ... REXX)

On Thu, 6 Jan 2022 at 15:39, Matt Hogstrom  wrote:
>
> That’s true for all source code and not unique to the PLX language.   I 
> suspect that PLX originally was not intended to be held to the same rigor as 
> commercial languages and was specialized so IBM never er let it out of the 
> lab.

Well IBM did let it out of the lab for a short while - in the very
late 1990s ISVs could obtain the then PLX/390 for a trivial fee. I had
the order form, submitted it, and there was some sort of minor delay
that dragged on for months before they finally admitted that they had
cancelled the program. But to this day there are a few ISVs who still
have that 1999 version.

Tony H.

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

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

Re: JCL (was: Python ... REXX)

[Tony Harminc]

On Thu, 6 Jan 2022 at 15:39, Matt Hogstrom  wrote:
>
> That’s true for all source code and not unique to the PLX language.   I 
> suspect that PLX originally was not intended to be held to the same rigor as 
> commercial languages and was specialized so IBM never er let it out of the 
> lab.

Well IBM did let it out of the lab for a short while - in the very
late 1990s ISVs could obtain the then PLX/390 for a trivial fee. I had
the order form, submitted it, and there was some sort of minor delay
that dragged on for months before they finally admitted that they had
cancelled the program. But to this day there are a few ISVs who still
have that 1999 version.

Tony H.

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

Re: JCL (was: Python ... REXX)

[Matt Hogstrom]

That’s true for all source code and not unique to the PLX language.   I suspect 
that PLX originally was not intended to be held to the same rigor as commercial 
languages and was specialized so IBM never er let it out of the lab.

Matt Hogstrom

A generalist knows less and less about more and more till he knows nothing 
about everything
A specialist knows more and more about less and less till he knows everything 
about nothing

> On Jan 6, 2022, at 1:37 PM, Colin Paice  wrote:
> 
> Making PLX Internal to IBM may be to protect its Intellectual Property.  I
> remember a vendor taking some IBM source,, renaming it and shipping it.
> When it went to court, they compared the vendor code with IBM code, and
> noticed that the code was  similar, the developers had the same initials,
> and both "developers" had made the same spelling mistakes in the code.
> Wow - what an amazing coincidence!
> 
> Remember if you go to court, you have to consider the cost of winning the
> case!  Making PLX internal to IBM may be part of the cost of winning.
> Colin
> 
> On Thu, 6 Jan 2022 at 18:03, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Thu, 6 Jan 2022 12:57:34 -0400, René Jansen  wrote:
>> 
>>> JCL ... Fred Brooks (“the worst language ever, and it happened under my
>> watch”) .
>>>   ...
>>> And indeed, I think witholding PL/X from customers was a very odd move,
>> guided by who-knows-which motives; which did not do PL/I a lot of good,
>> unfortunately.
>>> 
>> I conjecture fear of competition from RCA(?)  Others(?)
>> I don't know the chronology.  I have long conjectured that if IBM
>> had opened PL/X early enough, C would have been unnecessary.
>> 
>> A colleague told me that SuperC was coded in PL/X and runs
>> alike on MVS and OS/2.  (Was an NDA breached or could that
>> have been inferred from eyecatchers in the modules?)
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: JCL (was: Python ... REXX)

[Paul Gilmartin]

On Thu, 6 Jan 2022 19:25:11 +, Seymour J Metz wrote:

>I believe that it was Hitachi that stole MVS/XA source code. I don't know the 
>terms of the settlement.
>
I know we sold a version of a software product customized for hardware
system and OS that could not legally be imported to the U.S., perhaps
nowhere outside Japan.  I believe our compiler vendor (Dignus) provided
a customized code generation RPQ.  I needed to tweak our SMP/E
installation MCS (slightly) for that system.  And there were block size
problems with Binder output.  We had to fall back to Loader.

-- gil

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

Re: JCL (was: Python ... REXX)

[René Jansen]

https://books.google.nl/books?id=ldk7z4Q-WWYC=RA14-PT5=RA14-PT5=hitachi+ibm+source+code=bl=wu-vjyCcCR=ACfU3U1kpVpCkQgJDtFT-jskySEtVGcAPw=en=X=2ahUKEwj7oJuY7p31AhUDTDABHVQ2AZ4Q6AF6BAgCEAM#v=onepage=hitachi%20ibm%20source%20code=false
 


Hitachi paid IBM a rumoured $300 million fee to license the code. It was 
settled out of court.


> On 6 Jan 2022, at 15:25, Seymour J Metz  wrote:
> 
> I believe that it was Hitachi that stole MVS/XA source code. I don't know the 
> terms of the settlement.
> 
> 


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

Re: JCL (was: Python ... REXX)

[Seymour J Metz]

PL/X started as BSL in the 1960s. At the time it supported imbedded assembler, 
which would not be portable. PL/S II still did.
Open sourcing BSL or PL/S might not have been enough to prevent C; could you 
fit a compiler on a PDP-7 or PDP-11?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, January 6, 2022 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL (was: Python ... REXX)

On Thu, 6 Jan 2022 12:57:34 -0400, René Jansen  wrote:

>JCL ... Fred Brooks (“the worst language ever, and it happened under my 
>watch”) .
>...
>And indeed, I think witholding PL/X from customers was a very odd move, guided 
>by who-knows-which motives; which did not do PL/I a lot of good, unfortunately.
>
I conjecture fear of competition from RCA(?)  Others(?)
I don't know the chronology.  I have long conjectured that if IBM
had opened PL/X early enough, C would have been unnecessary.

A colleague told me that SuperC was coded in PL/X and runs
alike on MVS and OS/2.  (Was an NDA breached or could that
have been inferred from eyecatchers in the modules?)

-- gil

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

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

Re: JCL (was: Python ... REXX)

[Seymour J Metz]

I believe that it was Hitachi that stole MVS/XA source code. I don't know the 
terms of the settlement.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Colin Paice [colinpai...@gmail.com]
Sent: Thursday, January 6, 2022 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL (was: Python ... REXX)

Making PLX Internal to IBM may be to protect its Intellectual Property.  I
remember a vendor taking some IBM source,, renaming it and shipping it.
When it went to court, they compared the vendor code with IBM code, and
noticed that the code was  similar, the developers had the same initials,
and both "developers" had made the same spelling mistakes in the code.
Wow - what an amazing coincidence!

Remember if you go to court, you have to consider the cost of winning the
case!  Making PLX internal to IBM may be part of the cost of winning.
Colin

On Thu, 6 Jan 2022 at 18:03, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 6 Jan 2022 12:57:34 -0400, René Jansen  wrote:
>
> >JCL ... Fred Brooks (“the worst language ever, and it happened under my
> watch”) .
> >...
> >And indeed, I think witholding PL/X from customers was a very odd move,
> guided by who-knows-which motives; which did not do PL/I a lot of good,
> unfortunately.
> >
> I conjecture fear of competition from RCA(?)  Others(?)
> I don't know the chronology.  I have long conjectured that if IBM
> had opened PL/X early enough, C would have been unnecessary.
>
> A colleague told me that SuperC was coded in PL/X and runs
> alike on MVS and OS/2.  (Was an NDA breached or could that
> have been inferred from eyecatchers in the modules?)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: JCL (was: Python ... REXX)

[Paul Gilmartin]

On Thu, 6 Jan 2022 18:37:01 +, Colin Paice wrote:

>Making PLX Internal to IBM may be to protect its Intellectual Property.  I
>remember a vendor taking some IBM source,, renaming it and shipping it.
>When it went to court, ...
>
We did that.  Through MVS 3.8 IBM source code was open.  We took an
Assembler listing that embedded the PL/X as comments.  We modified
the assembler source for our product.  IBM couldn't touch us.  Maintenance
wasn't easy.  And we needed to do it twice, once for MVS, once for VS/E.

-- gil

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

Re: JCL (was: Python ... REXX)

[Paul Gilmartin]

On Thu, 6 Jan 2022 16:28:42 +, Jeremy Nicoll  wrote:
>...
>Absolutely.  But what's a decent alternative to JCL?
>
o Forgo compatibility.  Whip sockets were long ago removed from
  automobile dashboards.  They are no longer mourned.
  (But provide a conversion tool.)

o Free-form input.  No special treatment of column 72.
  (Think Rexx.)

o Eliminate special cases of symbol substitution.  Simply substitute
  for any instance of "[.]".  Then report as an error any reference
  to an undefined symbol.  Forgo re scan of text substituted for
  symbols.  I find such rescan a PITA, never useful.
  (Think Rexx, not CLIST.)
 
o Support overrides and refer backs to any supported depth of nested
  PROC calls.

  But are overrides needed?  Might they all be replaced by symbol
  references?  An override can modify an item that is not explicitly
  a parameter.  Is that disciplined or chaotic language design?
  (Think CPP.)

o SYSDSN ENQ is essential.  Keep it.

o Others?

-- gil

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

Re: JCL (was: Python ... REXX)

[Colin Paice]

Making PLX Internal to IBM may be to protect its Intellectual Property.  I
remember a vendor taking some IBM source,, renaming it and shipping it.
When it went to court, they compared the vendor code with IBM code, and
noticed that the code was  similar, the developers had the same initials,
and both "developers" had made the same spelling mistakes in the code.
Wow - what an amazing coincidence!

Remember if you go to court, you have to consider the cost of winning the
case!  Making PLX internal to IBM may be part of the cost of winning.
Colin

On Thu, 6 Jan 2022 at 18:03, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 6 Jan 2022 12:57:34 -0400, René Jansen  wrote:
>
> >JCL ... Fred Brooks (“the worst language ever, and it happened under my
> watch”) .
> >...
> >And indeed, I think witholding PL/X from customers was a very odd move,
> guided by who-knows-which motives; which did not do PL/I a lot of good,
> unfortunately.
> >
> I conjecture fear of competition from RCA(?)  Others(?)
> I don't know the chronology.  I have long conjectured that if IBM
> had opened PL/X early enough, C would have been unnecessary.
>
> A colleague told me that SuperC was coded in PL/X and runs
> alike on MVS and OS/2.  (Was an NDA breached or could that
> have been inferred from eyecatchers in the modules?)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: JCL (was: Python ... REXX)

[Farley, Peter x23353]

PLX puts a value in the IDR data that can be plainly seen in the load module.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, January 6, 2022 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL (was: Python ... REXX)

EXTERNAL EMAIL

On Thu, 6 Jan 2022 12:57:34 -0400, René Jansen  wrote:

>JCL ... Fred Brooks (“the worst language ever, and it happened under my 
>watch”) .
>...
>And indeed, I think witholding PL/X from customers was a very odd move, guided 
>by who-knows-which motives; which did not do PL/I a lot of good, unfortunately.
>
I conjecture fear of competition from RCA(?)  Others(?) I don't know the 
chronology.  I have long conjectured that if IBM had opened PL/X early enough, 
C would have been unnecessary.

A colleague told me that SuperC was coded in PL/X and runs alike on MVS and 
OS/2.  (Was an NDA breached or could that have been inferred from eyecatchers 
in the modules?)

--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL SPIN not working

[Joe Monk]

Try $Tstc12345,SPIN,DDNAME=TLVLOG

Joe

On Thu, Jul 29, 2021 at 1:49 PM Roberto Halais 
wrote:

> Hello!
>
> I have a stc which has the following jcl in it:
>
> //KLS1 JOB JESLOG=(SPIN,100K),MSGLEVEL=1
> ..
> //TLVLOG   DD   SYSOUT=,SPIN=(UNALLOC,100K)
>
> The SPIN would normally function but currently is not working for this stc.
> The files are not being freed.
> I have in another lpar the same stc with the same jcl and it's working
> fine.
>
> I have tried the $Tstc12345,SPIN command to no avail.
> I know if I stop/start the stc it might begin to work.
>
> Any ideas to fix this without recycling the stc are welcomed.
> Thank you.
> Roberto
>
> --
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

[Seymour J Metz]

Yes, COND is ugly, unnatural and a booby trap for the unwary, but I never broke 
myself of the habit of using it. I would, however, want to train a newbie to 
understand it but to use IF/ELSE for new JCL.

Whether I string things together in JCL or in a REXX script depends very much 
on what I am trying to do, and the question of AND/OR logic on completion codes 
is pretty far down my list of considerations.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Smith [sasd...@gmail.com]
Sent: Monday, May 24, 2021 6:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
Technologies

The problem I have with COND= is that it's back-asswards.  First, it
specifies conditions to NOT run the step.  You have to keep in mind that
with multiple conditions, any TRUE condition means don't run the step.
Except for ONLY & EVEN, which specify conditions for which the step *will*
run.  Second, the natural way to code a test is to say "if variable
[comparison] value", not the reverse that COND requires.

It's certainly possible to train yourself to grok that, but it's about as
unintuitive as it can be.  The IF / ELSE constructs are a great improvement
in understandability.  You can continue using the old way if you like, and
I don't see any argument that the new way causes any problems.  So what's
the complaint?

For the record, I use both COND and IF as I see fit, but if an OR or AND
rears its head, I'm likely to recast the whole thing into REXX.

sas

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

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

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

[Steve Smith]

The problem I have with COND= is that it's back-asswards.  First, it
specifies conditions to NOT run the step.  You have to keep in mind that
with multiple conditions, any TRUE condition means don't run the step.
Except for ONLY & EVEN, which specify conditions for which the step *will*
run.  Second, the natural way to code a test is to say "if variable
[comparison] value", not the reverse that COND requires.

It's certainly possible to train yourself to grok that, but it's about as
unintuitive as it can be.  The IF / ELSE constructs are a great improvement
in understandability.  You can continue using the old way if you like, and
I don't see any argument that the new way causes any problems.  So what's
the complaint?

For the record, I use both COND and IF as I see fit, but if an OR or AND
rears its head, I'm likely to recast the whole thing into REXX.

sas

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

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

[CM Poncelet]

Gil, 
 
I attach a discussion about the IF/THEN vs COND= we had in 2011. 
 
That COND= BTW was for a real case of a chemical company running its
payroll 100+ step job on our mainframe, but with a COND=(4,LT) on its
job card. Each time one of its jobsteps hit a CC GT 4, the job ended and
the ops had to call the company to explain the problem. The company
finally explained that jobstep execution should continue at say "STEP20"
if whatever combination of jobstep CCs was "this", and at say "STEP30"
if the combination of jobstep CCs was "that" - else, if x then continue
at y ... etc.
 
The attachment includes also a copy of panel ISREDDE that mentions "*Use
of panel ISREDDE will result in better performance in the editor.*" If
you then issue command PANELID ON whilst in edit, I think you will see
the panel is ISREDD2/3/4/5. Go to DSN=*.[S}ISPPLIB or whatever it is now
called, compare the executable code in panel ISREDDE with that of
ISREDDE2/3/4/5 (and bear in mind that this ISREDDE2 etc. code is
executed every time any key is hit whilst in edit,) and you will
hopefully understand that ISREDDE2 etc. is wasting as many CPU cycles as
it can for the sake of displaying unnecessary drop-down menus and colors
- none of which are needed for EDIT or ISR@PRIM etc. As they say, "if it
ain't broke, don't fix it" - and neither BROWSE, nor EDIT, nor ISPF 3.4,
nor assembler, nor SMP/E, nor anything similar is "broke" and needs
"fixing", unless the objective is to waste as many CPU cycles as
possible under the pretense of thereby improving mainframe programming -
which, of course, does not need improving.
 
BTW The fix is to copy ISREDDE into a separate PDS, alias ISREDDE as
ISREDDE2/3/4/5 in that PDS, concat it ahead of ISPPLIB, logoff/logon and
then reinvoke EDIT: "PANELID ON" will still show ISREDDE2/3/4/5 but
without its drop down menus and using far fewer CPU cycles. Likewise,
ISPF option 1 should display BROWSE and not VIEW: so copy ISR@PRIM to
your ISPPLIB ahead of *.[S]ISPPLIB, change whatever option 1 is to
"1,'PGM(ISRBRO) PARM(ISRBRO01)'" and you will then get BROWSE instead of
VIEW when you hit ISPF option 1.
 
The so-called "improvements" (drop-down menus etc.) serve only to waste
CPU cycles, de-skill and stultify (i.e. reduce to an equal level of
stupidity and mediocrity) mainframe programming and in particular
systems programming. I call it the 'Pinocchio effect', whereby mainframe
sysprogs are offered beer and cigars in exchange for agreeing to be
turned into donkeys.
 
HTH
 
Cheers, Chris Poncelet (retired sysprog)
 


On 21/05/2021 21:20, CM Poncelet wrote:
> "I fear the Greeks and when bearing gifts."
>
> On 20/05/2021 04:34, Paul Gilmartin wrote:
>> On Thu, 20 May 2021 02:50:02 +0100, CM Poncelet  wrote:
>>
>>> Again and with all due respect, progress is made not by blunting the
>>> tool but by sharpening the user.
>>>  
>>> "IF/THEN" does not handle all boolean AND/OR/NAND/XOR and
>>> steps-not-executed conditions.
>>>
>> Example?  In particular, something that can be done with "COND="
>> but not "IF/THEN".
>>
>>> Let not those who cannot master playing the violin demand that the
>>> violin be made more easy, but let them try playing the banjo instead.
>>>  
>> Earl Scruggs might have taken offense at that.
>>
>> Do you regard the invention of the automatic transmission a mistake?
>> I assume you don't own one.
>>
>> Abacus vs. calculator vs. computer?
>>
>> Luddite.
>>
>> -- gil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>


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

> On Fri, 21 Jan 2011 02:01:45 +, CM Poncelet  wrote:
>
>  
>
>> Any boolean tests can be performed with 'COND=', but not so with 'IF
>> ELSE etc.' We have already discussed this in the past.
>>
>>   
>
> Sorry; I missed that.
>
>  
>
>> But please show me how 'IF ELSE ...' handles the following:
>>
>> Execute STEPF if
>> - STEPA sets CC=04, STEPB sets CC=00, STEPC did not execute, STEPD sets
>> CC=08 and STEPE did not execute
>> or if
>> - STEPA sets CC=00, STEPB did not execute, STEPC sets CC=04, STEPD did
>> not execute and STEPE sets CC=00
>> or if
>> - STEPA did not execute, STEPB sets CC=00, STEPC sets CC=04, STEPD sets
>> CC=08 and STEPE sets either CC=04 or CC=08
>> otherwise do not execute STEPF.
>>
>>   
>
> OK:
>
> //
> //IFELSEJOB  505303JOB,'Paul Gilmartin',
> // MSGLEVEL=(1,1),REGION=0M
> //*
> //USERCOUTPUT JESDS=ALL,DEFAULT=YES,
> //  

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

[CM Poncelet]

Yippee.

On 23/05/2021 04:54, Seymour J Metz wrote:
> Your "Yes, and COND is easy to understand; it's also unnatural in that it 
> requires using the brain as well as the fingers." is a fantasy that has no 
> rational connection to what I wrote. Sean Spicer would be proud of you.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> CM Poncelet [ponce...@bcs.org.uk]
> Sent: Friday, May 21, 2021 11:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
> Technologies
>
> As in "Thank you for putting words in my mouth" and "Yes, and COND is
> easy to understand; it's also unnatural in that itrequires using the
> brain as well as the fingers. OK, got it. Thanks for explaining?" - or
> what other "I'd rather speak for myself. Alternative facts?"
>
>
> On 22/05/2021 04:04, Seymour J Metz wrote:
>> Thank you for putting words in my mouth. However, I'd rather speak for 
>> myself. Alternative facts?
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> CM Poncelet [ponce...@bcs.org.uk]
>> Sent: Friday, May 21, 2021 10:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
>> Technologies
>>
>> A well-known Bank I was working at, as a systems programming consultant
>> (in '99,) asked me to install custompac. So I did that and checked it
>> out. It was so full of errors, including that the user enter the MCAT
>> password and the hlq of PARMLIB (and of whatever else,) for it to
>> function, never mind its then allocating dozens of CYLs and (if memory
>> serves) 100's of directory blocks to SAMPLIB which, after the install,
>> contained no more than a dozen or so of members - and then
>> underestimated the DASD space and directory blocks required for SMPPTFIN
>> and whatever the DLIB/TLIB loadlibs were, causing S*37 abends when it
>> was executed. I pointed this out to the Bank and suggested that I write
>> my own version of it. They gave me the go-ahead. My version then did
>> everything custompac was supposed to do, including updating all its
>> "logs" and datasets etc. and being 100% compatible with custompac - but
>> requiring only two inputs from the user, with no MCAT password or
>> PARMLIB etc. hlqs needed - and it genned all the correct SMP/E JCL to
>> install/update the Bank's products.
>>
>> Later on, IBM kept on asking me to explain to them - and for weeks - how
>> I had 'fixed' their custompac, so they could tell their developers in
>> Canada what to do.
>>
>> Yes, and COND is easy to understand; it's also unnatural in that it
>> requires using the brain as well as the fingers. OK, got it. Thanks for
>> explaining.
>>
>> Cheers, Chris Poncelet (r)
>>
>>
>>
>> On 22/05/2021 01:23, Seymour J Metz wrote:
>>> When did custompack stop having SMP steps?
>>>
>>> Yes, COND is easy to understand; it's also unnatural.
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on behalf of 
>>> CM Poncelet 
>>> Sent: Friday, May 21, 2021 7:01 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
>>> Technologies
>>>
>>> "I don't like it when IBM takes away tools" - and IBM stopped publishing
>>> system control block DSECTs with ESA, thereby preventing sysprogs from
>>> modifying its OSes (or so it thought.)
>>>
>>> Next step (perhaps in 10+ years' time) will be to withdraw support of
>>> native SMP/E (and thus of CBPDO/CBIPO installs) and enforce using
>>> custompac (or custompak, whatever it is now called) instead. That would
>>> be a "progressive and continual stultification ofmainframe systems
>>> programming" and of IBM's progressively taking over full control of how
>>> customers' systems are installed, managed and maintained - as is already
>>> done by Micro$oft.
>>>
>>> How "COND=" works is trivial and needs no 'help' from "IF/THEN&qu

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

[Seymour J Metz]

Your "Yes, and COND is easy to understand; it's also unnatural in that it 
requires using the brain as well as the fingers." is a fantasy that has no 
rational connection to what I wrote. Sean Spicer would be proud of you.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [ponce...@bcs.org.uk]
Sent: Friday, May 21, 2021 11:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
Technologies

As in "Thank you for putting words in my mouth" and "Yes, and COND is
easy to understand; it's also unnatural in that itrequires using the
brain as well as the fingers. OK, got it. Thanks for explaining?" - or
what other "I'd rather speak for myself. Alternative facts?"


On 22/05/2021 04:04, Seymour J Metz wrote:
> Thank you for putting words in my mouth. However, I'd rather speak for 
> myself. Alternative facts?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> CM Poncelet [ponce...@bcs.org.uk]
> Sent: Friday, May 21, 2021 10:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
> Technologies
>
> A well-known Bank I was working at, as a systems programming consultant
> (in '99,) asked me to install custompac. So I did that and checked it
> out. It was so full of errors, including that the user enter the MCAT
> password and the hlq of PARMLIB (and of whatever else,) for it to
> function, never mind its then allocating dozens of CYLs and (if memory
> serves) 100's of directory blocks to SAMPLIB which, after the install,
> contained no more than a dozen or so of members - and then
> underestimated the DASD space and directory blocks required for SMPPTFIN
> and whatever the DLIB/TLIB loadlibs were, causing S*37 abends when it
> was executed. I pointed this out to the Bank and suggested that I write
> my own version of it. They gave me the go-ahead. My version then did
> everything custompac was supposed to do, including updating all its
> "logs" and datasets etc. and being 100% compatible with custompac - but
> requiring only two inputs from the user, with no MCAT password or
> PARMLIB etc. hlqs needed - and it genned all the correct SMP/E JCL to
> install/update the Bank's products.
>
> Later on, IBM kept on asking me to explain to them - and for weeks - how
> I had 'fixed' their custompac, so they could tell their developers in
> Canada what to do.
>
> Yes, and COND is easy to understand; it's also unnatural in that it
> requires using the brain as well as the fingers. OK, got it. Thanks for
> explaining.
>
> Cheers, Chris Poncelet (r)
>
>
>
> On 22/05/2021 01:23, Seymour J Metz wrote:
>> When did custompack stop having SMP steps?
>>
>> Yes, COND is easy to understand; it's also unnatural.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> CM Poncelet 
>> Sent: Friday, May 21, 2021 7:01 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
>> Technologies
>>
>> "I don't like it when IBM takes away tools" - and IBM stopped publishing
>> system control block DSECTs with ESA, thereby preventing sysprogs from
>> modifying its OSes (or so it thought.)
>>
>> Next step (perhaps in 10+ years' time) will be to withdraw support of
>> native SMP/E (and thus of CBPDO/CBIPO installs) and enforce using
>> custompac (or custompak, whatever it is now called) instead. That would
>> be a "progressive and continual stultification ofmainframe systems
>> programming" and of IBM's progressively taking over full control of how
>> customers' systems are installed, managed and maintained - as is already
>> done by Micro$oft.
>>
>> How "COND=" works is trivial and needs no 'help' from "IF/THEN"
>> statements. "COND=" just means "execute the step *unless* any of the
>> COND= parms is true." Anyone who has difficulty understanding even
>> *that* should not be working with mainframes.
>>
>> Chris Poncelet (r)
>>
>>
>>
>> On 21/05/2021 23:02, Seymour J Metz wrote:
>>>> ESA's OCO?
>>> What's that in reference to?
>>>
>>>
>>> --
>>> Shmuel

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

[CM Poncelet]

As in "Thank you for putting words in my mouth" and "Yes, and COND is
easy to understand; it's also unnatural in that itrequires using the
brain as well as the fingers. OK, got it. Thanks for explaining?" - or
what other "I'd rather speak for myself. Alternative facts?"
 

On 22/05/2021 04:04, Seymour J Metz wrote:
> Thank you for putting words in my mouth. However, I'd rather speak for 
> myself. Alternative facts?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> CM Poncelet [ponce...@bcs.org.uk]
> Sent: Friday, May 21, 2021 10:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
> Technologies
>
> A well-known Bank I was working at, as a systems programming consultant
> (in '99,) asked me to install custompac. So I did that and checked it
> out. It was so full of errors, including that the user enter the MCAT
> password and the hlq of PARMLIB (and of whatever else,) for it to
> function, never mind its then allocating dozens of CYLs and (if memory
> serves) 100's of directory blocks to SAMPLIB which, after the install,
> contained no more than a dozen or so of members - and then
> underestimated the DASD space and directory blocks required for SMPPTFIN
> and whatever the DLIB/TLIB loadlibs were, causing S*37 abends when it
> was executed. I pointed this out to the Bank and suggested that I write
> my own version of it. They gave me the go-ahead. My version then did
> everything custompac was supposed to do, including updating all its
> "logs" and datasets etc. and being 100% compatible with custompac - but
> requiring only two inputs from the user, with no MCAT password or
> PARMLIB etc. hlqs needed - and it genned all the correct SMP/E JCL to
> install/update the Bank's products.
>
> Later on, IBM kept on asking me to explain to them - and for weeks - how
> I had 'fixed' their custompac, so they could tell their developers in
> Canada what to do.
>
> Yes, and COND is easy to understand; it's also unnatural in that it
> requires using the brain as well as the fingers. OK, got it. Thanks for
> explaining.
>
> Cheers, Chris Poncelet (r)
>
>
>
> On 22/05/2021 01:23, Seymour J Metz wrote:
>> When did custompack stop having SMP steps?
>>
>> Yes, COND is easy to understand; it's also unnatural.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> CM Poncelet 
>> Sent: Friday, May 21, 2021 7:01 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
>> Technologies
>>
>> "I don't like it when IBM takes away tools" - and IBM stopped publishing
>> system control block DSECTs with ESA, thereby preventing sysprogs from
>> modifying its OSes (or so it thought.)
>>
>> Next step (perhaps in 10+ years' time) will be to withdraw support of
>> native SMP/E (and thus of CBPDO/CBIPO installs) and enforce using
>> custompac (or custompak, whatever it is now called) instead. That would
>> be a "progressive and continual stultification ofmainframe systems
>> programming" and of IBM's progressively taking over full control of how
>> customers' systems are installed, managed and maintained - as is already
>> done by Micro$oft.
>>
>> How "COND=" works is trivial and needs no 'help' from "IF/THEN"
>> statements. "COND=" just means "execute the step *unless* any of the
>> COND= parms is true." Anyone who has difficulty understanding even
>> *that* should not be working with mainframes.
>>
>> Chris Poncelet (r)
>>
>>
>>
>> On 21/05/2021 23:02, Seymour J Metz wrote:
>>>> ESA's OCO?
>>> What's that in reference to?
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on behalf of 
>>> CM Poncelet 
>>> Sent: Friday, May 21, 2021 4:22 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
>>> Technologies
>>>
>>> ESA's OCO?
>>>
>>> On 20/05/2021 08:43, Seymour J Metz wrote:
>>>> Progress is also not

Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS Technologies

[Seymour J Metz]

Thank you for putting words in my mouth. However, I'd rather speak for myself. 
Alternative facts?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [ponce...@bcs.org.uk]
Sent: Friday, May 21, 2021 10:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
Technologies

A well-known Bank I was working at, as a systems programming consultant
(in '99,) asked me to install custompac. So I did that and checked it
out. It was so full of errors, including that the user enter the MCAT
password and the hlq of PARMLIB (and of whatever else,) for it to
function, never mind its then allocating dozens of CYLs and (if memory
serves) 100's of directory blocks to SAMPLIB which, after the install,
contained no more than a dozen or so of members - and then
underestimated the DASD space and directory blocks required for SMPPTFIN
and whatever the DLIB/TLIB loadlibs were, causing S*37 abends when it
was executed. I pointed this out to the Bank and suggested that I write
my own version of it. They gave me the go-ahead. My version then did
everything custompac was supposed to do, including updating all its
"logs" and datasets etc. and being 100% compatible with custompac - but
requiring only two inputs from the user, with no MCAT password or
PARMLIB etc. hlqs needed - and it genned all the correct SMP/E JCL to
install/update the Bank's products.

Later on, IBM kept on asking me to explain to them - and for weeks - how
I had 'fixed' their custompac, so they could tell their developers in
Canada what to do.

Yes, and COND is easy to understand; it's also unnatural in that it
requires using the brain as well as the fingers. OK, got it. Thanks for
explaining.

Cheers, Chris Poncelet (r)



On 22/05/2021 01:23, Seymour J Metz wrote:
> When did custompack stop having SMP steps?
>
> Yes, COND is easy to understand; it's also unnatural.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> CM Poncelet 
> Sent: Friday, May 21, 2021 7:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
> Technologies
>
> "I don't like it when IBM takes away tools" - and IBM stopped publishing
> system control block DSECTs with ESA, thereby preventing sysprogs from
> modifying its OSes (or so it thought.)
>
> Next step (perhaps in 10+ years' time) will be to withdraw support of
> native SMP/E (and thus of CBPDO/CBIPO installs) and enforce using
> custompac (or custompak, whatever it is now called) instead. That would
> be a "progressive and continual stultification ofmainframe systems
> programming" and of IBM's progressively taking over full control of how
> customers' systems are installed, managed and maintained - as is already
> done by Micro$oft.
>
> How "COND=" works is trivial and needs no 'help' from "IF/THEN"
> statements. "COND=" just means "execute the step *unless* any of the
> COND= parms is true." Anyone who has difficulty understanding even
> *that* should not be working with mainframes.
>
> Chris Poncelet (r)
>
>
>
> On 21/05/2021 23:02, Seymour J Metz wrote:
>>> ESA's OCO?
>> What's that in reference to?
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> CM Poncelet 
>> Sent: Friday, May 21, 2021 4:22 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: JCL COND vs IF/THEN - Best catch up resources for MVS / ZOS 
>> Technologies
>>
>> ESA's OCO?
>>
>> On 20/05/2021 08:43, Seymour J Metz wrote:
>>> Progress is also not made by pretending that a blunt tool is sharp just 
>>> because you're used to it. COND= is a blunt tool, and IF/THEN puts a 
>>> bandage over some, but not all, of its ugliness.
>>>
>>> What's wrong with taking advantage of skeletons and such? Yes, I have been 
>>> known to hand craft an SMP/E job when the templates didn't suit my needs, 
>>> but what's wrong with taking advantage of them when it saves me time?
>>>
>>> I don't like it when IBM takes away tools, but that's not the same as 
>>> providing new tools that I can ignore when they don't suit the task at hand.
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>> ___