Re: Trying to use long parm= in started task

[Seymour J Metz]

Google for "task oriented documentation", AKA "trash oriented documentation", 
and weep. 

Yes, reference manuals should be complete and use cases should be in the users' 
guides. And, yes, the indexing is appalling for messages with hundreds of 
special cases. It should be easy to find the explanation of a specific RC and 
reason from, e.g., TOC, search bar, without a sequential search.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Garrett [rob...@garrettfamily.us]
Sent: Tuesday, December 7, 2021 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I tend to agree about the tech writers "having lost their way".

I wish they'd quit messing with "the tool formerly known as Knowledge Center", 
because every time they revamp it, they make it WORSE, not better.

It did used to be simple.  A reference manual ought to show every possible 
option/parameter/setting with a brief description of what each one does, ALL IN 
ONE PLACE!.  Please, stop trying to "guess" at what "most" users are going to 
want to use, and tell me EVERYTHING!  Let me decide which items are relevant to 
me, and stop making me have to hunt down a gazillion different disjoint 
locations in the doc and still not be certain that I've found every possible 
setting/option/parameter - thankyouverymuch.

And messages doc?  Give me a search index on the FULL FREAKING MESSAGE 
IDENTIFIER!!  I don't know whose idea it was to set up the search index so that 
you have to in advance "know" that you have to break the message identifier 
itself down into sub-strings (of varying length of course) and drill down into 
sections of the message doc in order to find anything, but that person or 
persons ought to be horse-whipped.   And the doc itself has become pretty 
horrible.  How many times have you gone through the ordeal of finding the doc 
for a message, and when you finally do find it, all it tells you are things 
that you already knew (something went wrong) and for the solution you should 
"ask your systems programmer".   Well, I AM the systems programmer, and the 
reason I'm looking up the silly message in the first place is because I don't 
know what went wrong in enough detail to know what to do about it.

I mean come on.  Someone had to write some code to detect a condition and issue 
the message, right?  At least tell me what conditions are being checked that 
can trigger the message along with a little detail.  How difficult could that 
possibly be?

A user's guide ought to have examples of usage, picked to supplement/illuminate 
the information provided in the reference manual.

As much of pain as it was to file paper TNL's into paper manuals,  back when I 
had a whole wall's worth of them in binders in a floor to ceiling bookcase in 
my office behind my desk, I guarantee I could find anything I wanted to know in 
less than half the time it takes to use the "KC", and be at least twice as 
confident that the information I'd found was both complete and correct.

Grrr...

Yeah, I'm that olde

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Tuesday, December 7, 2021 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Trying to use long parm= in started task

>
The tech writers have lost their way.  A Reference manual should specify
syntax:
how to code a command legally; and semantics: what that command does as coded.  
A Use's Gide should be task oriented: what command described in the <

I've been on both sides of the fence writing and as an end user.

The perfect solution would be to have a link to "usage" from the command 
reference and vice versa.
This is hard in PDF.  It would tend to say "go and look in the usage book"
(See below)
With the knowledge centre conceptually there are no "books", so the cross
linking should be easy. The table of contents is book based.   I think MQ
pubs are only KC, and you cannot easily get PDF documents.

I doubt if there is the resource to put all the links in, but from the usage 
statistics per page in the KC, they should be able to find the hot pages and 
put links in there.

An example from the KC

*Note: This document provides some examples of how you can use BPXBATCH.
For more detailed information about BPXBATCH, see the description of the 
BPXBATCH utility and the detailed discussion on using BPXBATCH to run 
executable files under MVS™ environments in z/OS UNIX System Services Command 
Reference
<https://www.ibm.com/docs/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxa500/toc.htm>.*

This just gets me to *Table of Contents (exploded view) *in the command 
reference  section rather than to the BPXBATCH command itself

Re: Trying to use long parm= in started task

[Robert Garrett]

I tend to agree about the tech writers "having lost their way".

I wish they'd quit messing with "the tool formerly known as Knowledge Center", 
because every time they revamp it, they make it WORSE, not better. 

It did used to be simple.  A reference manual ought to show every possible 
option/parameter/setting with a brief description of what each one does, ALL IN 
ONE PLACE!.  Please, stop trying to "guess" at what "most" users are going to 
want to use, and tell me EVERYTHING!  Let me decide which items are relevant to 
me, and stop making me have to hunt down a gazillion different disjoint 
locations in the doc and still not be certain that I've found every possible 
setting/option/parameter - thankyouverymuch.

And messages doc?  Give me a search index on the FULL FREAKING MESSAGE 
IDENTIFIER!!  I don't know whose idea it was to set up the search index so that 
you have to in advance "know" that you have to break the message identifier 
itself down into sub-strings (of varying length of course) and drill down into 
sections of the message doc in order to find anything, but that person or 
persons ought to be horse-whipped.   And the doc itself has become pretty 
horrible.  How many times have you gone through the ordeal of finding the doc 
for a message, and when you finally do find it, all it tells you are things 
that you already knew (something went wrong) and for the solution you should 
"ask your systems programmer".   Well, I AM the systems programmer, and the 
reason I'm looking up the silly message in the first place is because I don't 
know what went wrong in enough detail to know what to do about it. 

I mean come on.  Someone had to write some code to detect a condition and issue 
the message, right?  At least tell me what conditions are being checked that 
can trigger the message along with a little detail.  How difficult could that 
possibly be?

A user's guide ought to have examples of usage, picked to supplement/illuminate 
the information provided in the reference manual.

As much of pain as it was to file paper TNL's into paper manuals,  back when I 
had a whole wall's worth of them in binders in a floor to ceiling bookcase in 
my office behind my desk, I guarantee I could find anything I wanted to know in 
less than half the time it takes to use the "KC", and be at least twice as 
confident that the information I'd found was both complete and correct. 

Grrr...

Yeah, I'm that olde

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Tuesday, December 7, 2021 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Trying to use long parm= in started task

>
The tech writers have lost their way.  A Reference manual should specify
syntax:
how to code a command legally; and semantics: what that command does as coded.  
A Use's Gide should be task oriented: what command described in the <

I've been on both sides of the fence writing and as an end user.

The perfect solution would be to have a link to "usage" from the command 
reference and vice versa.
This is hard in PDF.  It would tend to say "go and look in the usage book"
(See below)
With the knowledge centre conceptually there are no "books", so the cross
linking should be easy. The table of contents is book based.   I think MQ
pubs are only KC, and you cannot easily get PDF documents.

I doubt if there is the resource to put all the links in, but from the usage 
statistics per page in the KC, they should be able to find the hot pages and 
put links in there.

An example from the KC

*Note: This document provides some examples of how you can use BPXBATCH.
For more detailed information about BPXBATCH, see the description of the 
BPXBATCH utility and the detailed discussion on using BPXBATCH to run 
executable files under MVS™ environments in z/OS UNIX System Services Command 
Reference
<https://www.ibm.com/docs/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxa500/toc.htm>.*

This just gets me to *Table of Contents (exploded view) *in the command 
reference  section rather than to the BPXBATCH command itself which would be 
easy to do.

Both PDF and online KC have their good and bad points.  Is there another option 
I have missed?

Colin

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

Trying to use long parm= in started task

[Colin Paice]

>
The tech writers have lost their way.  A Reference manual should specify
syntax:
how to code a command legally; and semantics: what that command does as
coded.  A Use's Gide should be task oriented: what command described in the
<

I've been on both sides of the fence writing and as an end user.

The perfect solution would be to have a link to "usage" from the command
reference and vice versa.
This is hard in PDF.  It would tend to say "go and look in the usage book"
(See below)
With the knowledge centre conceptually there are no "books", so the cross
linking should be easy. The table of contents is book based.   I think MQ
pubs are only KC, and you cannot easily get PDF documents.

I doubt if there is the resource to put all the links in, but from the
usage statistics per page in the KC, they should be able to find the hot
pages and put links in there.

An example from the KC

*Note: This document provides some examples of how you can use BPXBATCH.
For more detailed information about BPXBATCH, see the description of the
BPXBATCH utility and the detailed discussion on using BPXBATCH to run
executable files under MVS™ environments in z/OS UNIX System Services
Command Reference
.*

This just gets me to *Table of Contents (exploded view) *in the command
reference  section rather than to the BPXBATCH command itself which would
be easy to do.

Both PDF and online KC have their good and bad points.  Is there another
option I have missed?

Colin

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

Re: Trying to use long parm= in started task

[Paul Gilmartin]

On Mon, 6 Dec 2021 14:40:15 -0400, Peter Relson wrote:

>Colin wrote
[In a convoluted thread such as this it's helpful to cite Date: as well as 
author.]
>
>So according to the doc you cannot pass parameters to the program.
>
>
>A reminder: it is helpful (sometimes necessary) to point out where within 
>the vast sea of documentation you found something.
>
Or where he failed to find it.  The documentation of BPXBATCH is scattered.
A reader finding one of several individually incomplete descriptions may
be misled to believe that's all there is.

>There are at least two places where the doc does not say that and does 
>describe the optional arg's. 
>
>https://www.ibm.com/docs/en/zos/2.5.0?topic=utility-passing-parameter-data-bpxbatch
>https://www.ibm.com/docs/en/zos/2.5.0?topic=utility-invoking-bpxbatch-in-batch-job#btch
>
>The inconsistency is, of course, unfortunate and should be corrected.
>
Which inconsistency?  There may be more than one.  I'll submit the RCF.
Without attribution unless you prefer otherwise.

The tech writers have lost their way.  A Reference manual should specify syntax:
how to code a command legally; and semantics: what that command does as
coded.  A Use's Gide should be task oriented: what command described in the
Ref. to use to achieve a goal, with examples as needed.  But the better 
specification of BPXBATCH appears in the Guide and is incomplete in the Ref.
 
>While JCL substitution is quirky, ...
>
An understatement.  It's a bad design.  The JCL Ref. has 18 pages of rules for
symbols and substitution with special cases targeting compatibility. Earlier in 
this thread
you considered syntactic simplification with compatibility option(s).  No!   
You can't
remedy complexity by adding complexity.  There are metaphors relating to such
contradictions, many so sarcastic as to be NSFW.

Adding options vitiates portability.  It makes it impossible for contractors, 
ISVs, and
IBM itself to create code likely to work at every customer site.

If such an option were to be added I'd prefer that it be under programmer's 
control,
on the JOB statement like DSENQSHR, not a PARMLIB option like REFRPROT .
If REFRPROT  had been a JOB option I'd have used it pervasively.

-- gil

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

Re: Trying to use long parm= in started task

[Peter Relson]

Colin wrote

I've raised a doc comment as the BPXBATCH doc says
*BPXBATCH accepts one parameter string as input, the combination of SH|PGM
and program_name.*
So according to the doc you cannot pass parameters to the program.


A reminder: it is helpful (sometimes necessary) to point out where within 
the vast sea of documentation you found something.

There are at least two places where the doc does not say that and does 
describe the optional arg's. 

https://www.ibm.com/docs/en/zos/2.5.0?topic=utility-passing-parameter-data-bpxbatch
https://www.ibm.com/docs/en/zos/2.5.0?topic=utility-invoking-bpxbatch-in-batch-job#btch

The inconsistency is, of course, unfortunate and should be corrected.

To get back to the initial problem, the parameter passed to BPXBATCH was 
this:
SH /u/mqweb3/conf/ccc.sh aa  REST
This was passed to the shell, and now shell syntax comes into play.

"&" means something special in shell syntax: run the command that precedes 
it asynchronously. The line above indicates to process two shell commands, 
with the commands separated by the "&". That is why the parameter passed 
to the first is "aa".

While JCL substitution is quirky, understanding shell syntax is important 
if you're going to use shell commands. 


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: Trying to use long parm= in started task

[Colin Paice]

Gil,
Thank you .. I'll send some more doc comments with information from your
email (once I've played with it).
The \ does pass ACTION through

I also assumed that the BPXBATCH SH was different to the Unix sh command..
(for example the case), and perhaps the documentation for SH should be
expanded.
It looks like a good area to explore and understand.

It looks like "working as designed",  which I can live with, now I know.

Colin

On Sun, 5 Dec 2021 at 17:10, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 5 Dec 2021 16:51:07 +, Colin Paice wrote:
>
> >I've raised a doc comment as the BPXBATCH doc says
> >*BPXBATCH accepts one parameter string as input, the combination of SH|PGM
> >and program_name.*
> >
> I believe a mention of "sh -c" I suggested (below) would help greatly.
>
> >So according to the doc you cannot pass parameters to the program.
> >I've also asked for clarification of what is accepted.  If you have a & it
> >seems to end the parsing of the data.
> >
> You suspect a bug.  Perhaps.  Also likely is that sh takes "&" as a connand
> separator.  Use "\&" to suppress this.
>
> Peter seems to wish for discovery of a bug in UNIX rather than JCL, perhaps
> because Peter knows that UNIX support is likely to be more responsive than
> JCL support.
>
> Also, use max MSGLEVEL. and
> PGM=BPXBATCH,PARM="SH set -x; command - string" for additional
> tracing to //STDERR  DD.
>
> >On Sun, 5 Dec 2021 at 16:31, Paul Gilmartin  wrote:
> >
> >> On Sun, 5 Dec 2021 10:05:22 -0400, Peter Relson wrote:
> >> >...
> >> >Maybe BPXBATCH and SH do not process the parameter string as you are
> >> >thinking/expecting they do.
> >> >
> >> >I have no idea what the BPXBATCH rule is for passing parameter data
> >> >supplied on a SH statement. I think you have subsequently concluded
> that
> >> >
> >> The UNIX System Services Command Ref. makes this pretty clear:
> >> BPXBATCH
> >> Parameters
> >> ...
> >> SH
> >> Instructs BPXBATCH to start the shell and to run shell commands or
> >> scripts
> >> provided from stdin or the specified program_name. BPXBATCH passes
> all
> >> of the argument data, blanks included as is, to the shell as one
> >> parameter.
> >> BPXBATCH PARM='SH command string'
> >> ...
> >> If you specify SH with no program_name information, BPXBATCH
> attempts
> >> to run anything read in from stdin.
> >>
> >> (The first paragraph is awkward, even misleading in thee use of
> "specified
> >> program_name".  Should I submit an RCF to change it to:
> >> SH
> >> Instructs BPXBATCH to start the shell, passing it the entire
> remainder
> >> of
> >> the argument data, blanks included as is, to the "sh -c" as one
> >> parameter.
> >> ?
> >> That's the behavior I've experienced.)
> >>
> >> May we assume without further explanation that's the PARM in "equivalent
> >> JCL", described in the JCL Ref.?
> >>
> >> >your problem is not with how the parameter string itself is presented
> to
> >> >the BPXBATCH program, but further downstream.  A bug in BPXBATCH
> >> >processing (and/or a doc problem), is worth reporting.
> >> >
> >> Max MSGLEVEL should clarify sufficiently.
>
> -- 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: Trying to use long parm= in started task

[Paul Gilmartin]

On Sun, 5 Dec 2021 16:51:07 +, Colin Paice wrote:

>I've raised a doc comment as the BPXBATCH doc says
>*BPXBATCH accepts one parameter string as input, the combination of SH|PGM
>and program_name.*
>
I believe a mention of "sh -c" I suggested (below) would help greatly.

>So according to the doc you cannot pass parameters to the program.
>I've also asked for clarification of what is accepted.  If you have a & it
>seems to end the parsing of the data.
>
You suspect a bug.  Perhaps.  Also likely is that sh takes "&" as a connand
separator.  Use "\&" to suppress this.

Peter seems to wish for discovery of a bug in UNIX rather than JCL, perhaps
because Peter knows that UNIX support is likely to be more responsive than
JCL support.

Also, use max MSGLEVEL. and
PGM=BPXBATCH,PARM="SH set -x; command - string" for additional
tracing to //STDERR  DD.

>On Sun, 5 Dec 2021 at 16:31, Paul Gilmartin  wrote:
>
>> On Sun, 5 Dec 2021 10:05:22 -0400, Peter Relson wrote:
>> >...
>> >Maybe BPXBATCH and SH do not process the parameter string as you are
>> >thinking/expecting they do.
>> >
>> >I have no idea what the BPXBATCH rule is for passing parameter data
>> >supplied on a SH statement. I think you have subsequently concluded that
>> >
>> The UNIX System Services Command Ref. makes this pretty clear:
>> BPXBATCH
>> Parameters
>> ...
>> SH
>> Instructs BPXBATCH to start the shell and to run shell commands or
>> scripts
>> provided from stdin or the specified program_name. BPXBATCH passes all
>> of the argument data, blanks included as is, to the shell as one
>> parameter.
>> BPXBATCH PARM='SH command string'
>> ...
>> If you specify SH with no program_name information, BPXBATCH attempts
>> to run anything read in from stdin.
>>
>> (The first paragraph is awkward, even misleading in thee use of "specified
>> program_name".  Should I submit an RCF to change it to:
>> SH
>> Instructs BPXBATCH to start the shell, passing it the entire remainder
>> of
>> the argument data, blanks included as is, to the "sh -c" as one
>> parameter.
>> ?
>> That's the behavior I've experienced.)
>>
>> May we assume without further explanation that's the PARM in "equivalent
>> JCL", described in the JCL Ref.?
>>
>> >your problem is not with how the parameter string itself is presented to
>> >the BPXBATCH program, but further downstream.  A bug in BPXBATCH
>> >processing (and/or a doc problem), is worth reporting.
>> >
>> Max MSGLEVEL should clarify sufficiently.

-- gil

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

Re: Trying to use long parm= in started task

[Colin Paice]

I've raised a doc comment as the BPXBATCH doc says
*BPXBATCH accepts one parameter string as input, the combination of SH|PGM
and program_name.*
So according to the doc you cannot pass parameters to the program.
I've also asked for clarification of what is accepted.  If you have a & it
seems to end the parsing of the data.

On Sun, 5 Dec 2021 at 16:31, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 5 Dec 2021 10:05:22 -0400, Peter Relson wrote:
> >...
> >Maybe BPXBATCH and SH do not process the parameter string as you are
> >thinking/expecting they do.
> >
> >I have no idea what the BPXBATCH rule is for passing parameter data
> >supplied on a SH statement. I think you have subsequently concluded that
> >
> The UNIX System Services Command Ref. makes this pretty clear:
> BPXBATCH
> Parameters
> ...
> SH
> Instructs BPXBATCH to start the shell and to run shell commands or
> scripts
> provided from stdin or the specified program_name. BPXBATCH passes all
> of the argument data, blanks included as is, to the shell as one
> parameter.
> BPXBATCH PARM='SH command string'
> ...
> If you specify SH with no program_name information, BPXBATCH attempts
> to run anything read in from stdin.
>
> (The first paragraph is awkward, even misleading in thee use of "specified
> program_name".  Should I submit an RCF to change it to:
> SH
> Instructs BPXBATCH to start the shell, passing it the entire remainder
> of
> the argument data, blanks included as is, to the "sh -c" as one
> parameter.
> ?
> That's the behavior I've experienced.)
>
> May we assume without further explanation that's the PARM in "equivalent
> JCL", described in the JCL Ref.?
>
> >your problem is not with how the parameter string itself is presented to
> >the BPXBATCH program, but further downstream.  A bug in BPXBATCH
> >processing (and/or a doc problem), is worth reporting.
> >
> Max MSGLEVEL should clarify sufficiently.
>
> -- 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: Trying to use long parm= in started task

[Paul Gilmartin]

On Sun, 5 Dec 2021 10:05:22 -0400, Peter Relson wrote:
>...
>Maybe BPXBATCH and SH do not process the parameter string as you are 
>thinking/expecting they do.
>
>I have no idea what the BPXBATCH rule is for passing parameter data 
>supplied on a SH statement. I think you have subsequently concluded that 
>
The UNIX System Services Command Ref. makes this pretty clear:
BPXBATCH
Parameters
...
SH
Instructs BPXBATCH to start the shell and to run shell commands or scripts
provided from stdin or the specified program_name. BPXBATCH passes all
of the argument data, blanks included as is, to the shell as one parameter.
BPXBATCH PARM='SH command string'
...
If you specify SH with no program_name information, BPXBATCH attempts
to run anything read in from stdin.

(The first paragraph is awkward, even misleading in thee use of "specified 
program_name".  Should I submit an RCF to change it to:
SH
Instructs BPXBATCH to start the shell, passing it the entire remainder of
the argument data, blanks included as is, to the "sh -c" as one parameter.
?
That's the behavior I've experienced.)

May we assume without further explanation that's the PARM in "equivalent
JCL", described in the JCL Ref.?

>your problem is not with how the parameter string itself is presented to 
>the BPXBATCH program, but further downstream.  A bug in BPXBATCH 
>processing (and/or a doc problem), is worth reporting.
>
Max MSGLEVEL should clarify sufficiently.

-- gil

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

Re: Trying to use long parm= in started task

[Peter Relson]

The buglet that needs fixing is

// set A=''
// EXEC PGM,PARM='Z  Y'
the parameter passed to the program is 'Z'  I would expect either 'Z  Y'
or  'Z  Y '


In general, that is not the behavior for started task processing. 

This proc produces a 5-character parameter of "Z U Y":
//MYPROC PROC USER=U 
// SET A= 
//MYPROC EXEC PGM=NOTVALID,PARM='Z  Y'

The same proc, changing the SET to 
// SET A=''
fails with IEFC657I as has been discussed. And yes, that is unfriendly.

The same proc, changing the SET to
// SET B=
// SET A=''
to overcome the IEFC657I situation, produces a 9-character parameter of 'Z 
 Y'
 


//IHS  EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD
//PARMDD DD  *,SYMBOLS=EXECSYS
SH /u/mqweb3/conf/ccc.sh aa  xy z
/*
//STDOUT  DD  SYSOUT=H
//STDERR  DD  SYSOUT=H

prints out the parameters
aa


Maybe BPXBATCH and SH do not process the parameter string as you are 
thinking/expecting they do.

I have no idea what the BPXBATCH rule is for passing parameter data 
supplied on a SH statement. I think you have subsequently concluded that 
your problem is not with how the parameter string itself is presented to 
the BPXBATCH program, but further downstream.  A bug in BPXBATCH 
processing (and/or a doc problem), is worth reporting.

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: Trying to use long parm= in started task

[Paul Gilmartin]

On Sat, 4 Dec 2021 15:22:29 +, Colin Paice wrote:
>
>I would be happy with some better doc ( I'll raise another RCF), explaining
>what happens.
>  
No.

>The buglet that needs fixing is
> 
Yes.

>// set A=''
>// EXEC PGM,PARM='Z  Y'
>the parameter passed to the program is 'Z'  I would expect either 'Z  Y'
>or  'Z  Y '
>
According to the doc: 
https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes>
o Symbols are not substituted on the SET statement, so A is set to "", not 
substituted.
o Symbols are substituted on EXEC PARM, so yes, "Z  Y".

Is it clear that statements are not rescanned for further substitutions?  I 
know IBM's position is,
"We don't document what we do not do."  But this is such a prevalent 
expectation that it might
deserve an exception.  I believe that ampersands introduced by substitution are 
not treated
as special characters; apostrophes and blanks introduced by substitution are 
treated as
special characters

Do *not* document it and call it a "feature".  When a customer whines, "It no 
longer works the
way it used to!"  IBM's courageous riposte should be, "we fixed a defect: it 
now works as it
has always been documented.  You shouldn't have relied on its working contrary 
to
specification."

Still, I'd prefer the specification and behavior be simplified.
 
>real example
>
>//IHS  EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD
>//PARMDD DD  *,SYMBOLS=EXECSYS
>SH /u/mqweb3/conf/ccc.sh aa  xy z
>/*
>//STDOUT   DD  SYSOUT=H
>//STDERR   DD  SYSOUT=H
>
>prints out the parameters
>aa

-- gil

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

Re: Trying to use long parm= in started task

[Tom Harper]

Peter,

You raise an interesting question about the “what should we do” thing to do. 

In my experience, whether in software or not, the best course of action is 
always to do the right thing, the “what should we do”.

Every single time I take another course of action, it turns out to be a false 
economy. What seems less expensive at first is, in reality, almost always more 
expensive in the long run. 

Tom Harper 

Phoenix Software International 

Sent from my iPhone

> On Dec 4, 2021, at 10:05 AM, Peter Relson  wrote:
> 
> I agree that it is counter-intuitive (and unfriendly) that, for proc 
> symbol yyy, you can do
> SET xxx=
> but that
> SET xxx='' or even SET xxx='' (if a trailing period were 
> necessary to clearly identify a symbol's usage) do not do what you'd 
> expect. 
> 
> Specifically, it appears that the substitution does not happen within the 
> quotes (so when you use , you get, literally, ).
> So it's more than just that IEFC657I gets issued if  is not used 
> anywhere else, it's that the SET symbol substitution value is not what is 
> desired.
> 
> Maybe this can be improved compatibly (it's important that it be felt that 
> it can be done compatibly -- while individuals hate the inconsistency of 
> the function, customers hate it even more when things that worked last 
> release don't work this release). Obviously one could consider a 
> parmlib-specifiable option to identify a changed set of rules if such a 
> change were provided by option and a customer was willing to take the risk 
> of activating it for all their users, so that each individual would not 
> have to ask to use a new set of rules.
> 
> As to justification, it's surely the obvious one: $$$.
> Why should that be a surprise? These are business decisions and tradeoffs.
> 
> Presumably, the case that needed to be handled involved special 
> characters. And presumably that case was handled.
> Would it have been nicer to have a more general solution? Sure.
> Would it have been worth the resource investment? I don't know the answer. 
> 
> 
> And, by the way, the future outlook (to me) is getting dimmer. I long for 
> the days when "MVP" stood for Most Valuable Player. The new MVP (which 
> includes the word "Minimum") can lead towards "what's the least that we 
> can get away with doing" thinking. I far prefer "what should we do" 
> balanced with "what can we afford to do" (because maybe that leads towards 
> a staged delivery plan that might start with "not as much" but could end 
> up at "what should we do" -- if the plan gets carried to fruition, 
> although I've seen too many cases of not being good at carrying a plan to 
> fruition).
> 
> 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



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: Trying to use long parm= in started task

[Colin Paice]

Peter,

I would be happy with some better doc ( I'll raise another RCF), explaining
what happens.

The buglet that needs fixing is

// set A=''
// EXEC PGM,PARM='Z  Y'
the parameter passed to the program is 'Z'  I would expect either 'Z  Y'
or  'Z  Y '

real example

//IHS  EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD
//PARMDD DD  *,SYMBOLS=EXECSYS
SH /u/mqweb3/conf/ccc.sh aa  xy z
/*
//STDOUT   DD  SYSOUT=H
//STDERR   DD  SYSOUT=H

prints out the parameters
aa

Colin

On Sat, 4 Dec 2021 at 15:05, Peter Relson  wrote:

> I agree that it is counter-intuitive (and unfriendly) that, for proc
> symbol yyy, you can do
> SET xxx=
> but that
> SET xxx='' or even SET xxx='' (if a trailing period were
> necessary to clearly identify a symbol's usage) do not do what you'd
> expect.
>
> Specifically, it appears that the substitution does not happen within the
> quotes (so when you use , you get, literally, ).
> So it's more than just that IEFC657I gets issued if  is not used
> anywhere else, it's that the SET symbol substitution value is not what is
> desired.
>
> Maybe this can be improved compatibly (it's important that it be felt that
> it can be done compatibly -- while individuals hate the inconsistency of
> the function, customers hate it even more when things that worked last
> release don't work this release). Obviously one could consider a
> parmlib-specifiable option to identify a changed set of rules if such a
> change were provided by option and a customer was willing to take the risk
> of activating it for all their users, so that each individual would not
> have to ask to use a new set of rules.
>
> As to justification, it's surely the obvious one: $$$.
> Why should that be a surprise? These are business decisions and tradeoffs.
>
> Presumably, the case that needed to be handled involved special
> characters. And presumably that case was handled.
> Would it have been nicer to have a more general solution? Sure.
> Would it have been worth the resource investment? I don't know the answer.
>
>
> And, by the way, the future outlook (to me) is getting dimmer. I long for
> the days when "MVP" stood for Most Valuable Player. The new MVP (which
> includes the word "Minimum") can lead towards "what's the least that we
> can get away with doing" thinking. I far prefer "what should we do"
> balanced with "what can we afford to do" (because maybe that leads towards
> a staged delivery plan that might start with "not as much" but could end
> up at "what should we do" -- if the plan gets carried to fruition,
> although I've seen too many cases of not being good at carrying a plan to
> fruition).
>
> 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
>

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

Re: Trying to use long parm= in started task

[Peter Relson]

I agree that it is counter-intuitive (and unfriendly) that, for proc 
symbol yyy, you can do
SET xxx=
but that
SET xxx='' or even SET xxx='' (if a trailing period were 
necessary to clearly identify a symbol's usage) do not do what you'd 
expect. 

Specifically, it appears that the substitution does not happen within the 
quotes (so when you use , you get, literally, ).
So it's more than just that IEFC657I gets issued if  is not used 
anywhere else, it's that the SET symbol substitution value is not what is 
desired.

Maybe this can be improved compatibly (it's important that it be felt that 
it can be done compatibly -- while individuals hate the inconsistency of 
the function, customers hate it even more when things that worked last 
release don't work this release). Obviously one could consider a 
parmlib-specifiable option to identify a changed set of rules if such a 
change were provided by option and a customer was willing to take the risk 
of activating it for all their users, so that each individual would not 
have to ask to use a new set of rules.

As to justification, it's surely the obvious one: $$$.
Why should that be a surprise? These are business decisions and tradeoffs.

Presumably, the case that needed to be handled involved special 
characters. And presumably that case was handled.
Would it have been nicer to have a more general solution? Sure.
Would it have been worth the resource investment? I don't know the answer. 


And, by the way, the future outlook (to me) is getting dimmer. I long for 
the days when "MVP" stood for Most Valuable Player. The new MVP (which 
includes the word "Minimum") can lead towards "what's the least that we 
can get away with doing" thinking. I far prefer "what should we do" 
balanced with "what can we afford to do" (because maybe that leads towards 
a staged delivery plan that might start with "not as much" but could end 
up at "what should we do" -- if the plan gets carried to fruition, 
although I've seen too many cases of not being good at carrying a plan to 
fruition).

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: Trying to use long parm= in started task

[Paul Gilmartin]

On Fri, 3 Dec 2021 09:23:58 +, Colin Paice wrote:

>Peter,
>As I initiated this thread, I'd like to give my perspective.
>...
>I'm happy as I can now pass long strings through to my programs.
>
But still: 

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

That list is too long.  It should simply be:
Everywhere.

Can Peter or anyone justify the needless complexity resulting in confusion?

(OK.  It's not Peter's job.  And I don't expect anyone else to speak up.)

-- gil

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

Re: Trying to use long parm= in started task

[Gibney, Dave]

When converting/interpreting, DSN= could be processed to accept what would 
otherwise be an undefined symbol. Anywhere else, including DSN=FOO. or 
SPACE= could fail if  is not defined

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Thursday, December 02, 2021 3:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
> 
> On Thu, 2 Dec 2021 23:01:27 +, Gibney, Dave wrote:
> 
> >DSN= could be treated as an exception. Any other undefined
> symbols could be identified and flagged as an error.
> >
> That profits little:
> o You need more than one.  A programmer may have several temp DSNs
> active
>   in a step.  So, , , ...,  might suffice.
> o But you're requiring the user to change JCL to use the special form.  The
> user
>   might as well change to &.
> o You're introducing reserved symbols, undesirable when needless.
> 
> I prefer mnemonics such as &SYSEXEC for a library created with
> IEBGENER
> from instream and used in a later IRXJCL step.
> 
> Don't prolong peeling the Band-Aid.  "If it were done when ’tis done, then
> ’twere well
> It were done quickly".
> 
> -- 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: Trying to use long parm= in started task

[Seymour J Metz]

Recall who said that and in what context ;-)


--
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, December 2, 2021 6:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 23:01:27 +, Gibney, Dave wrote:

>DSN= could be treated as an exception. Any other undefined symbols 
>could be identified and flagged as an error.
>
That profits little:
o You need more than one.  A programmer may have several temp DSNs active
  in a step.  So, , , ...,  might suffice.
o But you're requiring the user to change JCL to use the special form.  The user
  might as well change to &.
o You're introducing reserved symbols, undesirable when needless.

I prefer mnemonics such as &SYSEXEC for a library created with IEBGENER
from instream and used in a later IRXJCL step.

Don't prolong peeling the Band-Aid.  "If it were done when ’tis done, then 
’twere well
It were done quickly".

-- 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: Trying to use long parm= in started task

[Colin Paice]

Peter,

As I initiated this thread, I'd like to give my perspective.

You are right in that the IEFC657I THE SYMBOL xxx WAS NOT USED message
indicates a problem, and it should be looked into.
I think other people's comments are shooting the messenger.

The real problem for me was
//  SET AV= - works
//  SET AV=''  with quotes does not work, and causes the IEFC571
message.
In all my years at writing JCL, I had learned to quote strings to avoid
errors.  Now I have to stop quoting the symbols around these parameters.
However I still need quotes around
//  SET T2='T2T2 BCD'

Now I know, I find I can do
// SET B=COLIN
// SET AV=Z
These works.

What also complicated the picture was
//  SET AV=Z
//  SET A2=' '
//I2   EXEC PGM=BPXBATCH,REGION=0M,
//   PARM='SH /u/mqweb3/conf/ccc.sh aa  REST'
and 'REST' is not passed through, so it looks like 'SET A2='' breaks the
parsing at 
I would have expected the passed parameter string to be 'aa  REST'

I'm happy as I can now pass long strings through to my programs.

Colin




On Thu, 2 Dec 2021 at 19:03, Peter Relson  wrote:

> I am surprised at the vitriole regarding
> IEFC657I THE SYMBOL xxx WAS NOT USED
>
> Every time I have seen that message it was because the proc creator (me)
> screwed up (sometimes in a subtle way).
>
> -- Ignoring that situation does not seem to be in the user's best
> interest.
> -- Warning about that situation is not either because no one will notice
> the warning.
> -- Treating it as an error seems to me to be the right action. It has
> helped innumerable people over the years.
>
> This is quite different than a compiler, for example, optimizing out
> something that proves not to be used.
>
> This could not unconditionally be changed, for compatibility reasons. That
> says that an option such as "do not treat as an error" would have to be
> provided and used. Make the case that this is a good idea. None of the
> posts I read did so.
>
> Sure, one could ask for an option to "ignore" or "treat as warning" but if
> you knew enough to include that option, wouldn't you just "fix" the proc
> not to have extraneous unneeded stuff to help everyone not get confused?
>
> Asking for improvement in the detection of use of a proc symbol, such as
> within the ParmDD SYSIN might be reasonable. It was implemented as it was
> because it was practical to do so. And the limitation that exists can be
> dealt with. It is not practical to have the system search through the Parm
> DD if the Parm DD is not inline so could not be done "in general". What
> would you sacrifice our doing in order to accommodate? It is always fair
> to ask; but it is also a requirement to understand that there are limited
> resources to be parceled out among worthy causes. Maybe one could consider
> an option such as "make a JCL symbol from every proc symbol, with some
> naming convention" that could make it easier to use the symbols from the
> proc in a Parm DD without having to do extra stuff, possibly incorporating
> "EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are
> processed within Parm DD (such as the current SYMBOLS=JCLONLY).
>
> What am I missing?
>
> 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
>

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

Re: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 21:16:30 -0600, Dale R. Smith wrote:
>...
>To me. the biggest problem with not having a way to ignore a unused PROC 
>parameter is what do you do when you have a PROC parameter that is obsolete?  
>If you remove it from the PROC, then Jobs that specify that parameter will get 
>the IEFC657I  error message.  Changing JCL to remove the PROC parameter is 
>often difficult in a real Production environment.  Depending on the parameter 
>you might be able to add a dummy statement to the PROC like:
>//DUMMYDD   DD  DUMMY,DSN=SYS1.PROCLIB(),DISP=SHR 
>The parameter is now referenced in the PROC and hopefully the values specified 
>in JCL will equate to a valid member name, (the member does not have to exist, 
>it just needs to be valid).  Obviously this option will not work for all 
>parameters.
> 
I suppose you can always tolerate ENQ SHR on SYS1.PROCLIB.

For values that might not be valid member names, I'd prefer:
//STEP99  EXEC  PGM=IEFBR14,COND=(0,LE),PARM=''

o Put this last so "COND=(0,LE)" has the desired effect.

o Still, the Devil can supply a value for OBSPARM that causes syntax errors,
  such as an unbalanced apostrophe.

-- gil

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

Re: Trying to use long parm= in started task

[Dale R. Smith]

On Thu, 2 Dec 2021 14:59:30 -0400, Peter Relson  wrote:

>I am surprised at the vitriole regarding 
>IEFC657I THE SYMBOL xxx WAS NOT USED
>
>Every time I have seen that message it was because the proc creator (me) 
>screwed up (sometimes in a subtle way).
>
>-- Ignoring that situation does not seem to be in the user's best 
>interest. 
>-- Warning about that situation is not either because no one will notice 
>the warning.
>-- Treating it as an error seems to me to be the right action. It has 
>helped innumerable people over the years.
>
>This is quite different than a compiler, for example, optimizing out 
>something that proves not to be used.
>
>This could not unconditionally be changed, for compatibility reasons. That 
>says that an option such as "do not treat as an error" would have to be 
>provided and used. Make the case that this is a good idea. None of the 
>posts I read did so. 
>
>Sure, one could ask for an option to "ignore" or "treat as warning" but if 
>you knew enough to include that option, wouldn't you just "fix" the proc 
>not to have extraneous unneeded stuff to help everyone not get confused?
>
>Asking for improvement in the detection of use of a proc symbol, such as 
>within the ParmDD SYSIN might be reasonable. It was implemented as it was 
>because it was practical to do so. And the limitation that exists can be 
>dealt with. It is not practical to have the system search through the Parm 
>DD if the Parm DD is not inline so could not be done "in general". What 
>would you sacrifice our doing in order to accommodate? It is always fair 
>to ask; but it is also a requirement to understand that there are limited 
>resources to be parceled out among worthy causes. Maybe one could consider 
>an option such as "make a JCL symbol from every proc symbol, with some 
>naming convention" that could make it easier to use the symbols from the 
>proc in a Parm DD without having to do extra stuff, possibly incorporating 
>"EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are 
>processed within Parm DD (such as the current SYMBOLS=JCLONLY).
>
>What am I missing?
>
>Peter Relson
>z/OS Core Technology Design

To me. the biggest problem with not having a way to ignore a unused PROC 
parameter is what do you do when you have a PROC parameter that is obsolete?  
If you remove it from the PROC, then Jobs that specify that parameter will get 
the IEFC657I  error message.  Changing JCL to remove the PROC parameter is 
often difficult in a real Production environment.  Depending on the parameter 
you might be able to add a dummy statement to the PROC like:
//DUMMYDD   DD  DUMMY,DSN=SYS1.PROCLIB(),DISP=SHR 
The parameter is now referenced in the PROC and hopefully the values specified 
in JCL will equate to a valid member name, (the member does not have to exist, 
it just needs to be valid).  Obviously this option will not work for all 
parameters.

-- 
Dale R. Smith

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

Re: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 23:01:27 +, Gibney, Dave wrote:

>DSN= could be treated as an exception. Any other undefined symbols 
>could be identified and flagged as an error.
> 
That profits little:
o You need more than one.  A programmer may have several temp DSNs active
  in a step.  So, , , ...,  might suffice.
o But you're requiring the user to change JCL to use the special form.  The user
  might as well change to &.
o You're introducing reserved symbols, undesirable when needless.

I prefer mnemonics such as &SYSEXEC for a library created with IEBGENER
from instream and used in a later IRXJCL step.

Don't prolong peeling the Band-Aid.  "If it were done when ’tis done, then 
’twere well
It were done quickly".

-- gil

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

Re: Trying to use long parm= in started task

[Gibney, Dave]

DSN= could be treated as an exception. Any other undefined symbols 
could be identified and flagged as an error.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Thursday, December 02, 2021 2:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
> 
> FSVO show. The job will run and use the wrong dataset, with no warning.
> Because of the ambiguous ampersand, there is only one place at which IBM
> can catch the error.
> 
> If you really want to complain, look at the CLIST change on OS/VS2 R3.6, with
> its massive increase in the number of apostrophes needed for some
> parameters.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!-
> whfbjddCjXBgD0sLyusLlbrpMpxz4_GtycDP79PVdaLXBVxM2JQ8oXUsSiCmw$
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Charles Mills [charl...@mcn.org]
> Sent: Thursday, December 2, 2021 4:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
> 
> Okay, I get it, but this ship is not very ship-shape.
> 
> Seeing as DSN= means what it means, then when IBM introduced
> variable
> symbols they should have used && or % or something, not a single
> ampersand.
> Yeah, yeah, that boat has departed the dock.
> 
> The IEFC657I does not really do the job though, does it? If I have PROC
> MYPARM='SYS1.FOO' and mistakenly code DSN= then I will not get
> an
> error on it assuming I have also coded something= elsewhere in
> the
> PROC. Right?
> 
> I think I still say that two wrongs don't make a right. Flagging what (I
> say) should be a non-error is not the answer to some other coding mistake.
> If someone codes DSN= the error will show up somewhere, either
> as a
> DSN not found or as a "can't catalog a temp DSN" or something.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> Behalf Of Seymour J Metz
> Sent: Thursday, December 2, 2021 12:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
> 
> > 1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and
> then
> > mistakenly code  instead of  in the body of the PROC,
> then
> the
> > error is the undefined ,
> 
> //SYSBAR DDDSN=,DISP=(MOD,PASS)
> 
> Is valid. At the time IBM defined the syntax, there were no symbolic
> parameters. Changing that to invalid would break every job that used a
> single ampersand for a temporary dataset name.
> 
> Do I like it? No, but that ship has sailed.
> 
> --
> 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: Trying to use long parm= in started task

[Seymour J Metz]

FSVO show. The job will run and use the wrong dataset, with no warning. Because 
of the ambiguous ampersand, there is only one place at which IBM can catch the 
error.

If you really want to complain, look at the CLIST change on OS/VS2 R3.6, with 
its massive increase in the number of apostrophes needed for some parameters.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Thursday, December 2, 2021 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Okay, I get it, but this ship is not very ship-shape.

Seeing as DSN= means what it means, then when IBM introduced variable
symbols they should have used && or % or something, not a single ampersand.
Yeah, yeah, that boat has departed the dock.

The IEFC657I does not really do the job though, does it? If I have PROC
MYPARM='SYS1.FOO' and mistakenly code DSN= then I will not get an
error on it assuming I have also coded something= elsewhere in the
PROC. Right?

I think I still say that two wrongs don't make a right. Flagging what (I
say) should be a non-error is not the answer to some other coding mistake.
If someone codes DSN= the error will show up somewhere, either as a
DSN not found or as a "can't catalog a temp DSN" or something.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, December 2, 2021 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

> 1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and
then
> mistakenly code  instead of  in the body of the PROC, then
the
> error is the undefined ,

//SYSBAR DDDSN=,DISP=(MOD,PASS)

Is valid. At the time IBM defined the syntax, there were no symbolic
parameters. Changing that to invalid would break every job that used a
single ampersand for a temporary dataset name.

Do I like it? No, but that ship has sailed.

--
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: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 13:38:17 -0800, Charles Mills  wrote:

>Okay, I get it, but this ship is not very ship-shape.
>
>Seeing as DSN= means what it means, then when IBM introduced variable
>symbols they should have used & or % or something, not a single ampersand.
>Yeah, yeah, that boat has departed the dock.
>
Alas, that boat was laden to the gunwales.  In 1965(?) I could have coded any
arbitrary string, e.g. PARM='FOO' and expected that literal
string to be passed to my PGM.  Symbol substitution had breakage: today
that means  PARM='FOOgilBAR'.  Breakage could have been avoided only
by using some construct previously not syntactically permitted.  There was
none such.

>The IEFC657I does not really do the job though, does it? If I have PROC
>MYPARM='SYS1.FOO' and mistakenly code DSN= then I will not get an
>error on it assuming I have also coded something= elsewhere in the
>PROC. Right?
>
>I think I still say that two wrongs don't make a right. Flagging what (I
>say) should be a non-error is not the answer to some other coding mistake.
>If someone codes DSN= the error will show up somewhere, either as a
>DSN not found or as a "can't catalog a temp DSN" or something.

-- gil

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

Re: Trying to use long parm= in started task

[Charles Mills]

Okay, I get it, but this ship is not very ship-shape.

Seeing as DSN= means what it means, then when IBM introduced variable
symbols they should have used && or % or something, not a single ampersand.
Yeah, yeah, that boat has departed the dock.

The IEFC657I does not really do the job though, does it? If I have PROC
MYPARM='SYS1.FOO' and mistakenly code DSN= then I will not get an
error on it assuming I have also coded something= elsewhere in the
PROC. Right?

I think I still say that two wrongs don't make a right. Flagging what (I
say) should be a non-error is not the answer to some other coding mistake.
If someone codes DSN= the error will show up somewhere, either as a
DSN not found or as a "can't catalog a temp DSN" or something.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Thursday, December 2, 2021 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

> 1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and
then
> mistakenly code  instead of  in the body of the PROC, then
the
> error is the undefined ,

//SYSBAR DDDSN=,DISP=(MOD,PASS)

Is valid. At the time IBM defined the syntax, there were no symbolic
parameters. Changing that to invalid would break every job that used a
single ampersand for a temporary dataset name.

Do I like it? No, but that ship has sailed.

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

Re: Trying to use long parm= in started task

[Seymour J Metz]

It sailed; I didn't say it arrived at port.


--
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, December 2, 2021 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 20:26:49 +, Seymour J Metz  wrote:
>
>//SYSBAR DDDSN=,DISP=(MOD,PASS)
>
>Is valid. At the time IBM defined the syntax, there were no symbolic 
>parameters. Changing that to invalid would break every job that used a single 
>ampersand for a temporary dataset name.
>
>Do I like it? No, but that ship has sailed.
>
Ob 10 April 1912

-- 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: Trying to use long parm= in started task

[Seymour J Metz]

That text says nothing about rescanning after substitution.


--
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, December 2, 2021 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 20:15:29 +, Seymour J Metz wrote:

>> That doesn't work
>
>It should work with a shorter name:
>
Mutatis mutandis.

> Special characters and blanks
> : When a parameter value contains special characters or blanks, enclose
>   the value in apostrophes. The enclosing apostrophes are not considered part 
> of the value. For example:
>   //SP2  SET  PARM3='3400-6'
>
>> // SET Q=
>> // SET ACTIONVAR=
>
>I beleibe that that will give you apostrophes in the value rather than 
>delimiting ot.
>
I believe not.
On parameters that are not in the list, the system correctly resolves a 
symbol
that is enclosed in apostrophes when the symbol is immediately preceded by
a symbol that is not enclosed in apostrophes. For example, both A and B are
substituted correctly in:

   //DD1  DD  '',DISP=OLD

I believe the "immediately" doesn't belong or is misleading.

The apostrophes, double apostrophes, and double ampersands seem to bee resolved
in a later scan; the double ampersands much later -- they still appear double in
the SUBSTITUTION JCL message but passed collapsed to the PGM.

>
>From: Paul Gilmarti
>Sent: Thursday, December 2, 2021 12:37 PM
>
>That doesn't work: 
><https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes>

-- 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: Trying to use long parm= in started task

[Seymour J Metz]

SET may not be in the list, but this text is quite clear:

 Special characters and blanks
 : When a parameter value contains special characters or blanks, enclose
   the value in apostrophes. The enclosing apostrophes are not considered part 
of the value. For example:
   //SP2  SET  PARM3='3400-6'

--
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, December 2, 2021 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 20:37:01 +, Seymour J Metz  wrote:

>> I've further perused the JCL Ref. which seems to imply:
>> //  SET NULL=''
>> // SET ACTVAR=''
>
>Not this?
>
>//  SET NULL=''
>// SET ACTVAR=''
>
No:
On parameters that are not in the list, the system correctly resolves a 
symbol
that is enclosed in apostrophes [only] when the symbol is immediately [? -- 
gil]
preceded by a symbol that is *not* enclosed in apostrophes.

SET is "not in the list".

I hate JCL!

>>>...
>>That doesn't work: 
>><https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes>

-- 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: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 20:26:49 +, Seymour J Metz  wrote:
>
>//SYSBAR DDDSN=,DISP=(MOD,PASS)
>
>Is valid. At the time IBM defined the syntax, there were no symbolic 
>parameters. Changing that to invalid would break every job that used a single 
>ampersand for a temporary dataset name.
>
>Do I like it? No, but that ship has sailed.
>
Ob 10 April 1912

-- gil

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

Re: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 20:37:01 +, Seymour J Metz  wrote:

>> I've further perused the JCL Ref. which seems to imply:
>> //  SET NULL=''
>> // SET ACTVAR=''
>
>Not this?
>
>//  SET NULL=''
>// SET ACTVAR=''
>
No:
On parameters that are not in the list, the system correctly resolves a 
symbol
that is enclosed in apostrophes [only] when the symbol is immediately [? -- 
gil]
preceded by a symbol that is *not* enclosed in apostrophes.

SET is "not in the list".

I hate JCL!

>>>...
>>That doesn't work: 
>>

-- gil

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

Re: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 20:15:29 +, Seymour J Metz wrote:

>> That doesn't work
>
>It should work with a shorter name:
> 
Mutatis mutandis.

> Special characters and blanks
> : When a parameter value contains special characters or blanks, enclose
>   the value in apostrophes. The enclosing apostrophes are not considered part 
> of the value. For example:
>   //SP2  SET  PARM3='3400-6'
>
>> // SET Q=
>> // SET ACTIONVAR=
>
>I beleibe that that will give you apostrophes in the value rather than 
>delimiting ot.
>
I believe not.
On parameters that are not in the list, the system correctly resolves a 
symbol
that is enclosed in apostrophes when the symbol is immediately preceded by
a symbol that is not enclosed in apostrophes. For example, both A and B are
substituted correctly in:

   //DD1  DD  '',DISP=OLD

I believe the "immediately" doesn't belong or is misleading.

The apostrophes, double apostrophes, and double ampersands seem to bee resolved
in a later scan; the double ampersands much later -- they still appear double in
the SUBSTITUTION JCL message but passed collapsed to the PGM.

>
>From: Paul Gilmarti
>Sent: Thursday, December 2, 2021 12:37 PM
>
>That doesn't work: 
>

-- gil

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

Re: Trying to use long parm= in started task

[Seymour J Metz]

> I've further perused the JCL Ref. which seems to imply:
> //  SET NULL=''
> // SET ACTVAR=''

Not this?

//  SET NULL=''
// SET ACTVAR=''


--
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, December 2, 2021 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 11:48:11 -0800, Charles Mills wrote:

>Does
>
>// SET ACTVAR=
>
>work? Or do you indeed need to quote ? (If you do, I heartily endorse 
>@Gil's  trick. I have used that.)
>
Did I copy that from you?

It may fail ifi  contains an unbalanced apostrophe.
JCL sorely needs HLASM'S (DOUBLE bif) et al.

I've further perused the JCL Ref. which seems to imply:
//  SET NULL=''
// SET ACTVAR=''

I hate JCL!


>-Original Message-
>From: Paul Gilmartin
>Sent: Thursday, December 2, 2021 9:37 AM
>
>On Thu, 2 Dec 2021 10:29:00 +, Seymour J Metz  wrote:
>
>>I believe that the problem is a combination of an error in your JCL and an 
>>error in the Converter.  is a symbolic parameter but not a symbol. Try
>>
>>// SET ACTIONVAR=''
>>...
>That doesn't work: 
><https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes>
>
>You can code symbols in apostrophes on [only --gil] the following keywords:
>The DD statement AMP parameter
>The DD statement PATH parameter
>The DD statement SUBSYS parameter
>The EXEC statement ACCT parameter
>The EXEC statement PARM parameter.
>
>Not SET.  I believe the following works:
>
>// SET Q=
>// SET ACTIONVAR=
>
>Is this well-documented?
>
>I hate JCL!
>
>Does "ACTIONVAR" have too many characters?
>
>>//PARMDD DD  *,SYMBOLS=JCLONLY
>>SH /u/mqweb3/conf/ccc.sh aa  x   y  z

-- 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: Trying to use long parm= in started task

[Seymour J Metz]

> // SET ACTVAR=

Should work.

You don't need the apostrophes in this case, although they are valid. The  
trick is for introducing an apostrophe into thr valur and should not work for 
delimiting the values.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Thursday, December 2, 2021 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Does

// SET ACTVAR=

work? Or do you indeed need to quote ? (If you do, I heartily endorse 
@Gil's  trick. I have used that.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, December 2, 2021 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 10:29:00 +, Seymour J Metz  wrote:

>I believe that the problem is a combination of an error in your JCL and an 
>error in the Converter.  is a symbolic parameter but not a symbol. Try
>
>// SET ACTIONVAR=''
>...
That doesn't work: 
<https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes>

You can code symbols in apostrophes on [only --gil] the following keywords:
The DD statement AMP parameter
The DD statement PATH parameter
The DD statement SUBSYS parameter
The EXEC statement ACCT parameter
The EXEC statement PARM parameter.

Not SET.  I believe the following works:

// SET Q=
// SET ACTIONVAR=

Is this well-documented?

I hate JCL!

Does "ACTIONVAR" have too many characters?

>//PARMDD DD  *,SYMBOLS=JCLONLY
>SH /u/mqweb3/conf/ccc.sh aa  x   y  z
>/*

-- 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: Trying to use long parm= in started task

[Seymour J Metz]

> 1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and then
> mistakenly code  instead of  in the body of the PROC, then the
> error is the undefined ,

//SYSBAR DDDSN=,DISP=(MOD,PASS)

Is valid. At the time IBM defined the syntax, there were no symbolic 
parameters. Changing that to invalid would break every job that used a single 
ampersand for a temporary dataset name.

Do I like it? No, but that ship has sailed.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Thursday, December 2, 2021 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Peter, fools rush in. I will give it a shot.

Apologies if I was vitriolic. It's just a language detail! Peace and Joy!

I see the situation as exactly analogous to most languages I use. If I
declare a variable in C++ and do not ever use it then it is a non-event. If
I declare a method (subroutine) with a formal parameter that I do not use in
the method (analogous to the PROC situation I would say) then I get a
warning IIRC that may be dismissed in any of several ways. If I define a
variable in Rexx and never use it then it is a non-event. If I declare a
procedure in Rexx that does not use one of its arguments it is a non-event.
I have never heard anyone say "I wish Rexx would give me an error if a
procedure failed to reference one of its arguments."

1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and then
mistakenly code  instead of  in the body of the PROC, then the
error is the undefined , not the unreferenced  It would seem
to me that an error on the latter is superfluous.

2. I am missing the compatibility problem. Every change is theoretically a
compatibility problem. Suppose IBM were to define a new JCL statement
DOTHIS. Well, we have a compatibility problem, right? Every job that had an
erroneous // DOTHIS in it somewhere used to fail and now it might not. QED.
But obviously that is a ridiculously irrelevant incompatibility. Isn't this
the same? Is there really a PROC somewhere with an unreferenced parameter in
it, and whose owner is counting on it failing, and who will be surprised
and/or inconvenienced if it stops failing? I suppose there might be a hasty
sysprog somewhere who is counting on the system telling him that he has an
unreferenced parameter. Would not a warning suffice for him? I would say
that if he is trying to debug a PROC he should be and probably is in fact
paying attention to the messages.

Is this error a real problem? I can tell you that it has been a real life
problem for me. Here is the situation. I am developing a PROC. I try this. I
try that. At some point I change or comment out or remove a JCL statement,
and the PROC fails because one of its parameters is now unreferenced.
Gr!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, December 2, 2021 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I am surprised at the vitriole regarding
IEFC657I THE SYMBOL xxx WAS NOT USED

Every time I have seen that message it was because the proc creator (me)
screwed up (sometimes in a subtle way).

-- Ignoring that situation does not seem to be in the user's best
interest.
-- Warning about that situation is not either because no one will notice
the warning.
-- Treating it as an error seems to me to be the right action. It has
helped innumerable people over the years.

This is quite different than a compiler, for example, optimizing out
something that proves not to be used.

This could not unconditionally be changed, for compatibility reasons. That
says that an option such as "do not treat as an error" would have to be
provided and used. Make the case that this is a good idea. None of the
posts I read did so.

Sure, one could ask for an option to "ignore" or "treat as warning" but if
you knew enough to include that option, wouldn't you just "fix" the proc
not to have extraneous unneeded stuff to help everyone not get confused?

Asking for improvement in the detection of use of a proc symbol, such as
within the ParmDD SYSIN might be reasonable. It was implemented as it was
because it was practical to do so. And the limitation that exists can be
dealt with. It is not practical to have the system search through the Parm
DD if the Parm DD is not inline so could not be done "in general". What
would you sacrifice our doing in order to accommodate? It is always fair
to ask; but it is also a requirement to understand that there are limited
resources to be parceled out among worthy causes. Maybe one could consider
an option such as "make a JCL symbol from every proc symbol, with some
nam

Re: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 11:48:11 -0800, Charles Mills wrote:

>Does
>
>// SET ACTVAR=
>
>work? Or do you indeed need to quote ? (If you do, I heartily endorse 
>@Gil's  trick. I have used that.)
>
Did I copy that from you?

It may fail ifi  contains an unbalanced apostrophe.
JCL sorely needs HLASM'S (DOUBLE bif) et al.

I've further perused the JCL Ref. which seems to imply:
//  SET NULL=''
// SET ACTVAR=''

I hate JCL!


>-Original Message-
>From: Paul Gilmartin
>Sent: Thursday, December 2, 2021 9:37 AM
>
>On Thu, 2 Dec 2021 10:29:00 +, Seymour J Metz  wrote:
>
>>I believe that the problem is a combination of an error in your JCL and an 
>>error in the Converter.  is a symbolic parameter but not a symbol. Try
>>
>>// SET ACTIONVAR=''
>>...
>That doesn't work: 
>
>
>You can code symbols in apostrophes on [only --gil] the following keywords:
>The DD statement AMP parameter
>The DD statement PATH parameter
>The DD statement SUBSYS parameter
>The EXEC statement ACCT parameter
>The EXEC statement PARM parameter.
>
>Not SET.  I believe the following works:
>
>// SET Q=
>// SET ACTIONVAR=
>
>Is this well-documented?
>
>I hate JCL!
>
>Does "ACTIONVAR" have too many characters?
>
>>//PARMDD DD  *,SYMBOLS=JCLONLY
>>SH /u/mqweb3/conf/ccc.sh aa  x   y  z

-- gil

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

Re: Trying to use long parm= in started task

[Seymour J Metz]

> That doesn't work

It should work with a shorter name:

 Special characters and blanks
 : When a parameter value contains special characters or blanks, enclose
   the value in apostrophes. The enclosing apostrophes are not considered part 
of the value. For example:
   //SP2  SET  PARM3='3400-6'

> // SET Q=
> // SET ACTIONVAR=

I beleibe that that will give you apostrophes in the value rather than 
delimiting ot.


--
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, December 2, 2021 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 10:29:00 +, Seymour J Metz  wrote:

>I believe that the problem is a combination of an error in your JCL and an 
>error in the Converter.  is a symbolic parameter but not a symbol. Try
>
>// SET ACTIONVAR=''
>...
That doesn't work: 
<https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes>

You can code symbols in apostrophes on [only --gil] the following keywords:
The DD statement AMP parameter
The DD statement PATH parameter
The DD statement SUBSYS parameter
The EXEC statement ACCT parameter
The EXEC statement PARM parameter.

Not SET.  I believe the following works:

// SET Q=
// SET ACTIONVAR=

Is this well-documented?

I hate JCL!

Does "ACTIONVAR" have too many characters?

>//PARMDD DD  *,SYMBOLS=JCLONLY
>SH /u/mqweb3/conf/ccc.sh aa  x   y  z
>/*

-- 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: Trying to use long parm= in started task

[Charles Mills]

Peter, fools rush in. I will give it a shot.

Apologies if I was vitriolic. It's just a language detail! Peace and Joy!

I see the situation as exactly analogous to most languages I use. If I
declare a variable in C++ and do not ever use it then it is a non-event. If
I declare a method (subroutine) with a formal parameter that I do not use in
the method (analogous to the PROC situation I would say) then I get a
warning IIRC that may be dismissed in any of several ways. If I define a
variable in Rexx and never use it then it is a non-event. If I declare a
procedure in Rexx that does not use one of its arguments it is a non-event.
I have never heard anyone say "I wish Rexx would give me an error if a
procedure failed to reference one of its arguments."

1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and then
mistakenly code  instead of  in the body of the PROC, then the
error is the undefined , not the unreferenced  It would seem
to me that an error on the latter is superfluous.

2. I am missing the compatibility problem. Every change is theoretically a
compatibility problem. Suppose IBM were to define a new JCL statement
DOTHIS. Well, we have a compatibility problem, right? Every job that had an
erroneous // DOTHIS in it somewhere used to fail and now it might not. QED.
But obviously that is a ridiculously irrelevant incompatibility. Isn't this
the same? Is there really a PROC somewhere with an unreferenced parameter in
it, and whose owner is counting on it failing, and who will be surprised
and/or inconvenienced if it stops failing? I suppose there might be a hasty
sysprog somewhere who is counting on the system telling him that he has an
unreferenced parameter. Would not a warning suffice for him? I would say
that if he is trying to debug a PROC he should be and probably is in fact
paying attention to the messages.

Is this error a real problem? I can tell you that it has been a real life
problem for me. Here is the situation. I am developing a PROC. I try this. I
try that. At some point I change or comment out or remove a JCL statement,
and the PROC fails because one of its parameters is now unreferenced.
Gr!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, December 2, 2021 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I am surprised at the vitriole regarding 
IEFC657I THE SYMBOL xxx WAS NOT USED

Every time I have seen that message it was because the proc creator (me) 
screwed up (sometimes in a subtle way).

-- Ignoring that situation does not seem to be in the user's best 
interest. 
-- Warning about that situation is not either because no one will notice 
the warning.
-- Treating it as an error seems to me to be the right action. It has 
helped innumerable people over the years.

This is quite different than a compiler, for example, optimizing out 
something that proves not to be used.

This could not unconditionally be changed, for compatibility reasons. That 
says that an option such as "do not treat as an error" would have to be 
provided and used. Make the case that this is a good idea. None of the 
posts I read did so. 

Sure, one could ask for an option to "ignore" or "treat as warning" but if 
you knew enough to include that option, wouldn't you just "fix" the proc 
not to have extraneous unneeded stuff to help everyone not get confused?

Asking for improvement in the detection of use of a proc symbol, such as 
within the ParmDD SYSIN might be reasonable. It was implemented as it was 
because it was practical to do so. And the limitation that exists can be 
dealt with. It is not practical to have the system search through the Parm 
DD if the Parm DD is not inline so could not be done "in general". What 
would you sacrifice our doing in order to accommodate? It is always fair 
to ask; but it is also a requirement to understand that there are limited 
resources to be parceled out among worthy causes. Maybe one could consider 
an option such as "make a JCL symbol from every proc symbol, with some 
naming convention" that could make it easier to use the symbols from the 
proc in a Parm DD without having to do extra stuff, possibly incorporating 
"EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are 
processed within Parm DD (such as the current SYMBOLS=JCLONLY).

What am I missing?

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

Re: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 14:59:30 -0400, Peter Relson wrote:

>I am surprised at the vitriole regarding 
>IEFC657I THE SYMBOL xxx WAS NOT USED
>
>Every time I have seen that message it was because the proc creator (me) 
>screwed up (sometimes in a subtle way).
> ...
>Sure, one could ask for an option to "ignore" or "treat as warning" but if 
>you knew enough to include that option, wouldn't you just "fix" the proc 
>not to have extraneous unneeded stuff to help everyone not get confused?
>
The reference or absence of reference might be in an INCLUDE member,
one of which refers to the symbol; another doesn't

//EXPORT SYMBOLS=* should imply a reference to every SYMBOL, JCL
or parm..

>Asking for improvement in the detection of use of a proc symbol, such as 
>within the ParmDD SYSIN might be reasonable. It was implemented as it was 
>because it was practical to do so. And the limitation that exists can be 
>dealt with. It is not practical to have the system search through the Parm 
>DD if the Parm DD is not inline so could not be done "in general". What 
>
Shouldn't you be discussing not just 'ParmDD", but any instream DD with
the SYMBOLS= option such as BPXBATCH STDPARM or any SYSUT1?

Substitution is performed only on instream data sets -- your "in general"
is a red herring.

>would you sacrifice our doing in order to accommodate? It is always fair 
>to ask; but it is also a requirement to understand that there are limited 
>resources to be parceled out among worthy causes. Maybe one could consider 
>an option such as "make a JCL symbol from every proc symbol, with some 
>naming convention" that could make it easier to use the symbols from the 
>
Just do it!  The "naming convention" should be "with the same name".
Supporting proc symbols and JCL symbols with identical names but
different values is inviting chaos.

>... proc in a Parm DD without having to do extra stuff, possibly incorporating 
>"EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are 
>processed within Parm DD (such as the current SYMBOLS=JCLONLY).

-- gil

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

Re: Trying to use long parm= in started task

[Seymour J Metz]

An error message for an unused symbolic parameter may be reasonable; throwing 
away everything to the right of a bad symbol, with no warning, is not.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Peter Relson [rel...@us.ibm.com]
Sent: Thursday, December 2, 2021 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I am surprised at the vitriole regarding
IEFC657I THE SYMBOL xxx WAS NOT USED

Every time I have seen that message it was because the proc creator (me)
screwed up (sometimes in a subtle way).

-- Ignoring that situation does not seem to be in the user's best
interest.
-- Warning about that situation is not either because no one will notice
the warning.
-- Treating it as an error seems to me to be the right action. It has
helped innumerable people over the years.

This is quite different than a compiler, for example, optimizing out
something that proves not to be used.

This could not unconditionally be changed, for compatibility reasons. That
says that an option such as "do not treat as an error" would have to be
provided and used. Make the case that this is a good idea. None of the
posts I read did so.

Sure, one could ask for an option to "ignore" or "treat as warning" but if
you knew enough to include that option, wouldn't you just "fix" the proc
not to have extraneous unneeded stuff to help everyone not get confused?

Asking for improvement in the detection of use of a proc symbol, such as
within the ParmDD SYSIN might be reasonable. It was implemented as it was
because it was practical to do so. And the limitation that exists can be
dealt with. It is not practical to have the system search through the Parm
DD if the Parm DD is not inline so could not be done "in general". What
would you sacrifice our doing in order to accommodate? It is always fair
to ask; but it is also a requirement to understand that there are limited
resources to be parceled out among worthy causes. Maybe one could consider
an option such as "make a JCL symbol from every proc symbol, with some
naming convention" that could make it easier to use the symbols from the
proc in a Parm DD without having to do extra stuff, possibly incorporating
"EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are
processed within Parm DD (such as the current SYMBOLS=JCLONLY).

What am I missing?

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

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

Re: Trying to use long parm= in started task

[Charles Mills]

Does

// SET ACTVAR=

work? Or do you indeed need to quote ? (If you do, I heartily endorse 
@Gil's  trick. I have used that.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, December 2, 2021 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Thu, 2 Dec 2021 10:29:00 +, Seymour J Metz  wrote:

>I believe that the problem is a combination of an error in your JCL and an 
>error in the Converter.  is a symbolic parameter but not a symbol. Try
>
>// SET ACTIONVAR=''
>...
That doesn't work: 
<https://www.ibm.com/docs/en/zos/2.5.0?topic=jcl-coding-symbols-in-apostrophes>

You can code symbols in apostrophes on [only --gil] the following keywords:
The DD statement AMP parameter
The DD statement PATH parameter
The DD statement SUBSYS parameter
The EXEC statement ACCT parameter
The EXEC statement PARM parameter.

Not SET.  I believe the following works:

// SET Q=
// SET ACTIONVAR=

Is this well-documented?

I hate JCL!

Does "ACTIONVAR" have too many characters?

>//PARMDD DD  *,SYMBOLS=JCLONLY
>SH /u/mqweb3/conf/ccc.sh aa  x   y  z
>/*

-- 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: Trying to use long parm= in started task

[Peter Relson]

I am surprised at the vitriole regarding 
IEFC657I THE SYMBOL xxx WAS NOT USED

Every time I have seen that message it was because the proc creator (me) 
screwed up (sometimes in a subtle way).

-- Ignoring that situation does not seem to be in the user's best 
interest. 
-- Warning about that situation is not either because no one will notice 
the warning.
-- Treating it as an error seems to me to be the right action. It has 
helped innumerable people over the years.

This is quite different than a compiler, for example, optimizing out 
something that proves not to be used.

This could not unconditionally be changed, for compatibility reasons. That 
says that an option such as "do not treat as an error" would have to be 
provided and used. Make the case that this is a good idea. None of the 
posts I read did so. 

Sure, one could ask for an option to "ignore" or "treat as warning" but if 
you knew enough to include that option, wouldn't you just "fix" the proc 
not to have extraneous unneeded stuff to help everyone not get confused?

Asking for improvement in the detection of use of a proc symbol, such as 
within the ParmDD SYSIN might be reasonable. It was implemented as it was 
because it was practical to do so. And the limitation that exists can be 
dealt with. It is not practical to have the system search through the Parm 
DD if the Parm DD is not inline so could not be done "in general". What 
would you sacrifice our doing in order to accommodate? It is always fair 
to ask; but it is also a requirement to understand that there are limited 
resources to be parceled out among worthy causes. Maybe one could consider 
an option such as "make a JCL symbol from every proc symbol, with some 
naming convention" that could make it easier to use the symbols from the 
proc in a Parm DD without having to do extra stuff, possibly incorporating 
"EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are 
processed within Parm DD (such as the current SYMBOLS=JCLONLY).

What am I missing?

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: Trying to use long parm= in started task

[Paul Gilmartin]

On Thu, 2 Dec 2021 10:29:00 +, Seymour J Metz  wrote:

>I believe that the problem is a combination of an error in your JCL and an 
>error in the Converter.  is a symbolic parameter but not a symbol. Try
>
>// SET ACTIONVAR=''
>...
That doesn't work: 


You can code symbols in apostrophes on [only --gil] the following keywords:
The DD statement AMP parameter
The DD statement PATH parameter
The DD statement SUBSYS parameter
The EXEC statement ACCT parameter
The EXEC statement PARM parameter.

Not SET.  I believe the following works:

// SET Q=
// SET ACTIONVAR=

Is this well-documented?

I hate JCL!

Does "ACTIONVAR" have too many characters?

>//PARMDD DD  *,SYMBOLS=JCLONLY
>SH /u/mqweb3/conf/ccc.sh aa  x   y  z
>/*

-- gil

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

Re: Trying to use long parm= in started task

[Colin Paice]

Hi Seymour,

Thanks for your reply -  I originally used symbols (wrongly). ..

Your solution does not require the dummy step because you suggested

//  SET AV=  without the quotes...

When I used
//  SET AV=''
it didnt work

Old dogs,  new tricks...

thank you

Colin




On Thu, 2 Dec 2021 at 10:29, Seymour J Metz  wrote:

> I believe that the problem is a combination of an error in your JCL and an
> error in the Converter.  is a symbolic parameter but not a symbol.
> Try
>
> // SET ACTIONVAR=''
> ...
> //PARMDD DD  *,SYMBOLS=JCLONLY
> SH /u/mqweb3/conf/ccc.sh aa  x   y  z
> /*
>
> Note that you don't need the terminating period since the symbol is
> followed by a space.
>
> --
> 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, December 2, 2021 5:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> I have set up a script with
>  echo "$1 $2 $3 $4 $5 $6 $7"
>  echo "all $*"
> and
> //COLWEB   PROC ACTION='start'
> //  EXPORT SYMLIST=*
> //  SET T2='T2T2'
> //IHS  EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD
> //PARMDD DD  *,SYMBOLS=JCLONLY
> SH /u/mqweb3/conf/ccc.sh aa  x   y  z
> /*
> //STDOUT   DD  SYSOUT=H
> //STDERR   DD  SYSOUT=H
> //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>
> this gives
> aa T2T2 x
> all aa T2T2 x
>
> so ,>.<  and any text after the  are ignored.
> Also the y and Z are not displayed...  so  is not just being
> replaced with blanks .. but is saying "end of parsing"
> it is a good little problem... hidden depths.
> Colin
>
>
> On Wed, 1 Dec 2021 at 20:18, Seymour J Metz  wrote:
>
> > In the JCL before he tried PARMDD I saw "" followed by a letter;
> > did he doe the same thiong with PARMDD or did he have a period in
> between?
> >
> >
> > --
> > 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: Wednesday, December 1, 2021 2:19 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Trying to use long parm= in started task
> >
> > On Wed, 1 Dec 2021 18:51:57 +, Seymour J Metz wrote:
> >
> > >It's not easy to demo the OP's JCL without knowing what it is. At this
> > point I don't know whether "" appeared after PARMDD and I don't
> know
> > whether it was followed with a period.
> > >
> > The period should be unnecessary if  is sufficiently delimited
> > lexically.
> >
> > I believe the OP stated (and you quoted) that neither SET nor EXPORT
> > SYMLIST=*
> > satisfied the need for a reference to an argument.  This is stupidity or
> > indolence of
> > the developers.  The arguments of SET, EXPORT, and the instream text are
> > available
> > to the reader/converter to verify that the arguments are referenced.
> >
> > (I suspect that any APAR will be closed PRS.  Perhaps USER.)
> >
> >
> > >> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice   wrote:
> > >> > >...
> > >> > > One attempt is below.
> > >> > >
> > >> > > //COLWEB   PROC ACTION='start',
> > >> > > //  DIR='/usr/lpp/ihsa_zos',
> > >> > > //  CONF='/u/mqweb3/conf/httpd.conf',
> > >> > > //  T='-t -DDUMP_CONFIG'
> > >> > > //*-
> > >> > >
> > >> > >
> > >> > >
> > >> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> > >> > > T2='' *
> > >> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > >> > > //STDINDD *,*SYMBOLS=EXECSYS *
> > >> > >
> > >> > >
> > >> > > */bin/apachectl -k  -f &ACTIONCONF -DNO_DETACH
>   *
> > >> > > *blah blah blah*
> > >> > > /*
> > >> > > //STDOUT   DD  SYSOUT=H
> > >> > > //STDERR   DD  SYSOUT=H
> > >> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> > >> > >
> > >> > >
> > >> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM=' 
> > 

Re: Trying to use long parm= in started task

[Seymour J Metz]

I believe that the problem is a combination of an error in your JCL and an 
error in the Converter.  is a symbolic parameter but not a symbol. Try

// SET ACTIONVAR=''
...
//PARMDD DD  *,SYMBOLS=JCLONLY
SH /u/mqweb3/conf/ccc.sh aa  x   y  z
/*

Note that you don't need the terminating period since the symbol is followed by 
a space.

--
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, December 2, 2021 5:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I have set up a script with
 echo "$1 $2 $3 $4 $5 $6 $7"
 echo "all $*"
and
//COLWEB   PROC ACTION='start'
//  EXPORT SYMLIST=*
//  SET T2='T2T2'
//IHS  EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD
//PARMDD DD  *,SYMBOLS=JCLONLY
SH /u/mqweb3/conf/ccc.sh aa  x   y  z
/*
//STDOUT   DD  SYSOUT=H
//STDERR   DD  SYSOUT=H
//STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)

this gives
aa T2T2 x
all aa T2T2 x

so ,>.<  and any text after the  are ignored.
Also the y and Z are not displayed...  so  is not just being
replaced with blanks .. but is saying "end of parsing"
it is a good little problem... hidden depths.
Colin


On Wed, 1 Dec 2021 at 20:18, Seymour J Metz  wrote:

> In the JCL before he tried PARMDD I saw "" followed by a letter;
> did he doe the same thiong with PARMDD or did he have a period in between?
>
>
> --
> 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: Wednesday, December 1, 2021 2:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> On Wed, 1 Dec 2021 18:51:57 +, Seymour J Metz wrote:
>
> >It's not easy to demo the OP's JCL without knowing what it is. At this
> point I don't know whether "" appeared after PARMDD and I don't know
> whether it was followed with a period.
> >
> The period should be unnecessary if  is sufficiently delimited
> lexically.
>
> I believe the OP stated (and you quoted) that neither SET nor EXPORT
> SYMLIST=*
> satisfied the need for a reference to an argument.  This is stupidity or
> indolence of
> the developers.  The arguments of SET, EXPORT, and the instream text are
> available
> to the reader/converter to verify that the arguments are referenced.
>
> (I suspect that any APAR will be closed PRS.  Perhaps USER.)
>
>
> >> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice   wrote:
> >> > >...
> >> > > One attempt is below.
> >> > >
> >> > > //COLWEB   PROC ACTION='start',
> >> > > //  DIR='/usr/lpp/ihsa_zos',
> >> > > //  CONF='/u/mqweb3/conf/httpd.conf',
> >> > > //  T='-t -DDUMP_CONFIG'
> >> > > //*-
> >> > >
> >> > >
> >> > >
> >> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> >> > > T2='' *
> >> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> >> > > //STDINDD *,*SYMBOLS=EXECSYS *
> >> > >
> >> > >
> >> > > */bin/apachectl -k  -f &ACTIONCONF -DNO_DETACH   *
> >> > > *blah blah blah*
> >> > > /*
> >> > > //STDOUT   DD  SYSOUT=H
> >> > > //STDERR   DD  SYSOUT=H
> >> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> >> > >
> >> > >
> >> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM=' 
> '
> >*
> >> > >
> >> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> >> > > //  PEND
>
> --
> 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: Trying to use long parm= in started task

[Colin Paice]

I have set up a script with
 echo "$1 $2 $3 $4 $5 $6 $7"
 echo "all $*"
and
//COLWEB   PROC ACTION='start'
//  EXPORT SYMLIST=*
//  SET T2='T2T2'
//IHS  EXEC PGM=BPXBATCH,REGION=0M,PARMDD=PARMDD
//PARMDD DD  *,SYMBOLS=JCLONLY
SH /u/mqweb3/conf/ccc.sh aa  x   y  z
/*
//STDOUT   DD  SYSOUT=H
//STDERR   DD  SYSOUT=H
//STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)

this gives
aa T2T2 x
all aa T2T2 x

so ,>.<  and any text after the  are ignored.
Also the y and Z are not displayed...  so  is not just being
replaced with blanks .. but is saying "end of parsing"
it is a good little problem... hidden depths.
Colin


On Wed, 1 Dec 2021 at 20:18, Seymour J Metz  wrote:

> In the JCL before he tried PARMDD I saw "" followed by a letter;
> did he doe the same thiong with PARMDD or did he have a period in between?
>
>
> --
> 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: Wednesday, December 1, 2021 2:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> On Wed, 1 Dec 2021 18:51:57 +, Seymour J Metz wrote:
>
> >It's not easy to demo the OP's JCL without knowing what it is. At this
> point I don't know whether "" appeared after PARMDD and I don't know
> whether it was followed with a period.
> >
> The period should be unnecessary if  is sufficiently delimited
> lexically.
>
> I believe the OP stated (and you quoted) that neither SET nor EXPORT
> SYMLIST=*
> satisfied the need for a reference to an argument.  This is stupidity or
> indolence of
> the developers.  The arguments of SET, EXPORT, and the instream text are
> available
> to the reader/converter to verify that the arguments are referenced.
>
> (I suspect that any APAR will be closed PRS.  Perhaps USER.)
>
>
> >> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice   wrote:
> >> > >...
> >> > > One attempt is below.
> >> > >
> >> > > //COLWEB   PROC ACTION='start',
> >> > > //  DIR='/usr/lpp/ihsa_zos',
> >> > > //  CONF='/u/mqweb3/conf/httpd.conf',
> >> > > //  T='-t -DDUMP_CONFIG'
> >> > > //*-
> >> > >
> >> > >
> >> > >
> >> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> >> > > T2='' *
> >> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> >> > > //STDINDD *,*SYMBOLS=EXECSYS *
> >> > >
> >> > >
> >> > > */bin/apachectl -k  -f &ACTIONCONF -DNO_DETACH   *
> >> > > *blah blah blah*
> >> > > /*
> >> > > //STDOUT   DD  SYSOUT=H
> >> > > //STDERR   DD  SYSOUT=H
> >> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> >> > >
> >> > >
> >> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM=' 
> '
> >*
> >> > >
> >> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> >> > > //  PEND
>
> --
> 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: Trying to use long parm= in started task

[Seymour J Metz]

In the JCL before he tried PARMDD I saw "" followed by a letter; did he 
doe the same thiong with PARMDD or did he have a period in between?


--
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: Wednesday, December 1, 2021 2:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Wed, 1 Dec 2021 18:51:57 +, Seymour J Metz wrote:

>It's not easy to demo the OP's JCL without knowing what it is. At this point I 
>don't know whether "" appeared after PARMDD and I don't know whether it 
>was followed with a period.
>
The period should be unnecessary if  is sufficiently delimited lexically.

I believe the OP stated (and you quoted) that neither SET nor EXPORT SYMLIST=*
satisfied the need for a reference to an argument.  This is stupidity or 
indolence of
the developers.  The arguments of SET, EXPORT, and the instream text are 
available
to the reader/converter to verify that the arguments are referenced.

(I suspect that any APAR will be closed PRS.  Perhaps USER.)


>> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice   wrote:
>> > >...
>> > > One attempt is below.
>> > >
>> > > //COLWEB   PROC ACTION='start',
>> > > //  DIR='/usr/lpp/ihsa_zos',
>> > > //  CONF='/u/mqweb3/conf/httpd.conf',
>> > > //  T='-t -DDUMP_CONFIG'
>> > > //*-
>> > >
>> > >
>> > >
>> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
>> > > T2='' *
>> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
>> > > //STDINDD *,*SYMBOLS=EXECSYS *
>> > >
>> > >
>> > > */bin/apachectl -k  -f &ACTIONCONF -DNO_DETACH   *
>> > > *blah blah blah*
>> > > /*
>> > > //STDOUT   DD  SYSOUT=H
>> > > //STDERR   DD  SYSOUT=H
>> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>> > >
>> > >
>> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  '
>*
>> > >
>> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
>> > > //  PEND

--
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: Trying to use long parm= in started task

[Paul Gilmartin]

On Wed, 1 Dec 2021 18:51:57 +, Seymour J Metz wrote:

>It's not easy to demo the OP's JCL without knowing what it is. At this point I 
>don't know whether "" appeared after PARMDD and I don't know whether it 
>was followed with a period.
>
The period should be unnecessary if  is sufficiently delimited lexically.

I believe the OP stated (and you quoted) that neither SET nor EXPORT SYMLIST=*
satisfied the need for a reference to an argument.  This is stupidity or 
indolence of
the developers.  The arguments of SET, EXPORT, and the instream text are 
available
to the reader/converter to verify that the arguments are referenced.

(I suspect that any APAR will be closed PRS.  Perhaps USER.)


>> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice   wrote:
>> > >...
>> > > One attempt is below.
>> > >
>> > > //COLWEB   PROC ACTION='start',
>> > > //  DIR='/usr/lpp/ihsa_zos',
>> > > //  CONF='/u/mqweb3/conf/httpd.conf',
>> > > //  T='-t -DDUMP_CONFIG'
>> > > //*-
>> > >
>> > >
>> > >
>> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
>> > > T2='' *
>> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
>> > > //STDINDD *,*SYMBOLS=EXECSYS *
>> > >
>> > >
>> > > */bin/apachectl -k  -f &ACTIONCONF -DNO_DETACH   *
>> > > *blah blah blah*
>> > > /*
>> > > //STDOUT   DD  SYSOUT=H
>> > > //STDERR   DD  SYSOUT=H
>> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>> > >
>> > >
>> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  '
>*
>> > >
>> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
>> > > //  PEND

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

Re: Trying to use long parm= in started task

[Seymour J Metz]

It's not easy to demo the OP's JCL without knowing what it is. At this point I 
don't know whether "" appeared after PARMDD and I don't know whether it 
was followed with a period.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Wednesday, December 1, 2021 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Easy to demo. Define a proc with =BAR. Don't reference  anywhere in
the body of the PROC. QED.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, December 1, 2021 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Please post the failing JCL.

//... PROC ...,ACTION=FOO,,
...
PARMDD DD *,SYMBOLS-JCL
...

...
/*
...
Should work.


--
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: Wednesday, December 1, 2021 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I tried that ...
I get
IEFC657I THE SYMBOL ACTION WAS NOT USED...
Where action is one of the procedure parameters.

and the procedure parm was not passed through into the parmsdd, symbols I
create are...  procedure parms are not

hence my convoluted solution using intermediate symbols and some dummy
iefbr14 steps to use the procedure parms.

On Wed, 1 Dec 2021 at 15:08, Charles Mills  wrote:

> The mailing list program is making me add some random text here so that it
> won't think this is a Listserve command.
>
> Here is an example of what you need to do:
>
> //EXPORT SYMLIST=*
> ...
> //PARMS  DD  *,SYMBOLS=JCLONLY
> ,,
> 
> /*
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Styles, Andy (ITS zPlatform Services)
> Sent: Wednesday, December 1, 2021 2:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> Classification: Public
>
> Providing it's running under JES2 or JES3 and not SUB=MSTR, instream data
> in procedures is fine:
>
> //PGM EXEC PGM=FRED,PARMDD=PARMS
> //PARMS DD *
> blah blah blah
>
> Andy Styles
> z/Series System Programmer
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Colin Paice
> Sent: 01 December 2021 09:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> *** This email is from an external source - be careful of attachments and
> links. Please report suspicious emails ***
>
> PARMDD was the easy bit.  But how do you get the started task parameters
> into PARMDD?
>
> On Wed, 1 Dec 2021 at 08:44, Mike Schwab  wrote:
>
> > PARMDD.
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Dparameter-examples-parmdd&
> > amp;data=04%7C01%7CAndy.Styles%40LloydsBanking.com%7Cb569694c823e46cb1
> > 59f08d9b4aac859%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C637739467
> > 878831910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qNneGDjjrQT88PlsI1Y35p
> > eTnmPLF6zMqCNK6ol%2Fe0A%3Dreserved=0
> >
> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice 
> wrote:
> > >
> > > I want to use a started task to start my web browser, but the size
> > > of the parameters exceeds the 100 char limit for parm=
> > >
> > > Is there a nice way of passing the data?
> > >
> > > Ive tried using symbols, and passing them in to an instream dataset,
> > > with SYMBOLS=
> > > I then need dummy steps to actually use the parameters, otherwise
> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
> > >
> > > One attempt is below.
> > >
> > > //COLWEB   PROC ACTION='start',
> > > //  DIR='/usr/lpp/ihsa_zos',
> > > //  CONF='/u/mqweb3/conf/httpd.conf',
> > > //  T='-t -DDUMP_CONFIG'
> > > //*-
> > >
> > >
> > >
> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> > > T2='' *
> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > > //STDINDD *,*SYMBOLS=EXECSYS *
> > >
> > >
> > > */bin/apachectl -k  -f & -DNO_DETACH   *
> >

Re: Trying to use long parm= in started task

[Charles Mills]

Easy to demo. Define a proc with =BAR. Don't reference  anywhere in
the body of the PROC. QED.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, December 1, 2021 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Please post the failing JCL.

//... PROC ...,ACTION=FOO,,
...
PARMDD DD *,SYMBOLS-JCL
...

...
/*
...
Should work.


--
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: Wednesday, December 1, 2021 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I tried that ...
I get
IEFC657I THE SYMBOL ACTION WAS NOT USED...
Where action is one of the procedure parameters.

and the procedure parm was not passed through into the parmsdd, symbols I
create are...  procedure parms are not

hence my convoluted solution using intermediate symbols and some dummy
iefbr14 steps to use the procedure parms.

On Wed, 1 Dec 2021 at 15:08, Charles Mills  wrote:

> The mailing list program is making me add some random text here so that it
> won't think this is a Listserve command.
>
> Here is an example of what you need to do:
>
> //EXPORT SYMLIST=*
> ...
> //PARMS  DD  *,SYMBOLS=JCLONLY
> ,,
> 
> /*
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Styles, Andy (ITS zPlatform Services)
> Sent: Wednesday, December 1, 2021 2:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> Classification: Public
>
> Providing it's running under JES2 or JES3 and not SUB=MSTR, instream data
> in procedures is fine:
>
> //PGM EXEC PGM=FRED,PARMDD=PARMS
> //PARMS DD *
> blah blah blah
>
> Andy Styles
> z/Series System Programmer
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Colin Paice
> Sent: 01 December 2021 09:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> *** This email is from an external source - be careful of attachments and
> links. Please report suspicious emails ***
>
> PARMDD was the easy bit.  But how do you get the started task parameters
> into PARMDD?
>
> On Wed, 1 Dec 2021 at 08:44, Mike Schwab  wrote:
>
> > PARMDD.
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Dparameter-examples-parmdd&
> > amp;data=04%7C01%7CAndy.Styles%40LloydsBanking.com%7Cb569694c823e46cb1
> > 59f08d9b4aac859%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C637739467
> > 878831910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qNneGDjjrQT88PlsI1Y35p
> > eTnmPLF6zMqCNK6ol%2Fe0A%3Dreserved=0
> >
> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice 
> wrote:
> > >
> > > I want to use a started task to start my web browser, but the size
> > > of the parameters exceeds the 100 char limit for parm=
> > >
> > > Is there a nice way of passing the data?
> > >
> > > Ive tried using symbols, and passing them in to an instream dataset,
> > > with SYMBOLS=
> > > I then need dummy steps to actually use the parameters, otherwise
> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
> > >
> > > One attempt is below.
> > >
> > > //COLWEB   PROC ACTION='start',
> > > //  DIR='/usr/lpp/ihsa_zos',
> > > //  CONF='/u/mqweb3/conf/httpd.conf',
> > > //  T='-t -DDUMP_CONFIG'
> > > //*-
> > >
> > >
> > >
> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> > > T2='' *
> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > > //STDINDD *,*SYMBOLS=EXECSYS *
> > >
> > >
> > > */bin/apachectl -k  -f  -DNO_DETACH   *
> > > *blah blah blah*
> > > /*
> > > //STDOUT   DD  SYSOUT=H
> > > //STDERR   DD  SYSOUT=H
> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> > >
> > >
> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  '
*
> > >
> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> > > //  PEND
> > >
> > > 
> > > -- For IBM-MAIN 

Re: Trying to use long parm= in started task

[Charles Mills]

What is being suggested is the opposite: removing the current error for a
symbol that is defined but never referenced. (Or is it just for a symbolic
parm that is never referenced?) Hard for me to see how changing that would
break anything. ("Oh, I was counting on my PROC being invalid and not
executing!")

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, December 1, 2021 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Making an undefined synbol invalid would cause massive breakage. Now if IBM
had anticipated symbolic parameters way back when and had chosen a different
syntax for temporary DSNs, then I believe flagging undefined symbols would
have been desirable.

There are a lot of design choices that I didn't like early on, but this is
one that I hadn't noticed until long after the fact. :-(


--
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: Wednesday, December 1, 2021 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Wed, 1 Dec 2021 15:35:27 +, Colin Paice wrote:

>I tried that ...
>I get
>IEFC657I THE SYMBOL ACTION WAS NOT USED...
>Where action is one of the procedure parameters.
>
o // SET should suffice to establish use.  If not, it should be APARable.

o // SET should suffice to establish use.  If not, it should be APARable.

IEFC657I is bogus.  It should be an error to use a symbol without defining
it,
not to define a symbol without using it.

IBM needs to get its act together and understand customers' needs.

>and the procedure parm was not passed through into the parmsdd, symbols I
>create are...  procedure parms are not
>
>hence my convoluted solution using intermediate symbols and some dummy
>iefbr14 steps to use the procedure parms.


>> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice wrote:
>> > >
>> > > I want to use a started task to start my web browser, but the size
>> > > of the parameters exceeds the 100 char limit for parm=
>> > >
>> > > Is there a nice way of passing the data?
>> > >
>> > > Ive tried using symbols, and passing them in to an instream dataset,
>> > > with SYMBOLS=
>> > > I then need dummy steps to actually use the parameters, otherwise
>> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
>> > >
>> > > One attempt is below.
>> > >
>> > > //COLWEB   PROC ACTION='start',
>> > > //  DIR='/usr/lpp/ihsa_zos',
>> > > //  CONF='/u/mqweb3/conf/httpd.conf',
>> > > //  T='-t -DDUMP_CONFIG'
>> > > //*-
>> > >
>> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
>> > > T2='' *
>> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
>> > > //STDINDD *,*SYMBOLS=EXECSYS *
>> > >
>> > > */bin/apachectl -k  -f  -DNO_DETACH   *
>> > > *blah blah blah*
>> > > /*
>> > > //STDOUT   DD  SYSOUT=H
>> > > //STDERR   DD  SYSOUT=H
>> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>> > >
>> > >
>> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  '
*
>> > >
>> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
>> > > //  PEND

-- 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: Trying to use long parm= in started task

[Seymour J Metz]

Please post the failing JCL.

//... PROC ...,ACTION=FOO,,
...
PARMDD DD *,SYMBOLS-JCL
...

...
/*
...
Should work.


--
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: Wednesday, December 1, 2021 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

I tried that ...
I get
IEFC657I THE SYMBOL ACTION WAS NOT USED...
Where action is one of the procedure parameters.

and the procedure parm was not passed through into the parmsdd, symbols I
create are...  procedure parms are not

hence my convoluted solution using intermediate symbols and some dummy
iefbr14 steps to use the procedure parms.

On Wed, 1 Dec 2021 at 15:08, Charles Mills  wrote:

> The mailing list program is making me add some random text here so that it
> won't think this is a Listserve command.
>
> Here is an example of what you need to do:
>
> //EXPORT SYMLIST=*
> ...
> //PARMS  DD  *,SYMBOLS=JCLONLY
> ,,
> 
> /*
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Styles, Andy (ITS zPlatform Services)
> Sent: Wednesday, December 1, 2021 2:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> Classification: Public
>
> Providing it's running under JES2 or JES3 and not SUB=MSTR, instream data
> in procedures is fine:
>
> //PGM EXEC PGM=FRED,PARMDD=PARMS
> //PARMS DD *
> blah blah blah
>
> Andy Styles
> z/Series System Programmer
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Colin Paice
> Sent: 01 December 2021 09:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> *** This email is from an external source - be careful of attachments and
> links. Please report suspicious emails ***
>
> PARMDD was the easy bit.  But how do you get the started task parameters
> into PARMDD?
>
> On Wed, 1 Dec 2021 at 08:44, Mike Schwab  wrote:
>
> > PARMDD.
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Dparameter-examples-parmdd&
> > amp;data=04%7C01%7CAndy.Styles%40LloydsBanking.com%7Cb569694c823e46cb1
> > 59f08d9b4aac859%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C637739467
> > 878831910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qNneGDjjrQT88PlsI1Y35p
> > eTnmPLF6zMqCNK6ol%2Fe0A%3Dreserved=0
> >
> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice 
> wrote:
> > >
> > > I want to use a started task to start my web browser, but the size
> > > of the parameters exceeds the 100 char limit for parm=
> > >
> > > Is there a nice way of passing the data?
> > >
> > > Ive tried using symbols, and passing them in to an instream dataset,
> > > with SYMBOLS=
> > > I then need dummy steps to actually use the parameters, otherwise
> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
> > >
> > > One attempt is below.
> > >
> > > //COLWEB   PROC ACTION='start',
> > > //  DIR='/usr/lpp/ihsa_zos',
> > > //  CONF='/u/mqweb3/conf/httpd.conf',
> > > //  T='-t -DDUMP_CONFIG'
> > > //*-
> > >
> > >
> > >
> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> > > T2='' *
> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > > //STDINDD *,*SYMBOLS=EXECSYS *
> > >
> > >
> > > */bin/apachectl -k  -f  -DNO_DETACH   *
> > > *blah blah blah*
> > > /*
> > > //STDOUT   DD  SYSOUT=H
> > > //STDERR   DD  SYSOUT=H
> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> > >
> > >
> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
> > >
> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> > > //  PEND
> > >
> > > 
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> >
> >
> >
> > --
> > Mike A Schwab, Springfield IL USA
> > Where do Forest Rangers go to get away from it all?
> >
> > -

Re: Trying to use long parm= in started task

[Seymour J Metz]

Making an undefined synbol invalid would cause massive breakage. Now if IBM had 
anticipated symbolic parameters way back when and had chosen a different syntax 
for temporary DSNs, then I believe flagging undefined symbols would have been 
desirable.

There are a lot of design choices that I didn't like early on, but this is one 
that I hadn't noticed until long after the fact. :-(


--
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: Wednesday, December 1, 2021 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Wed, 1 Dec 2021 15:35:27 +, Colin Paice wrote:

>I tried that ...
>I get
>IEFC657I THE SYMBOL ACTION WAS NOT USED...
>Where action is one of the procedure parameters.
>
o // SET should suffice to establish use.  If not, it should be APARable.

o // SET should suffice to establish use.  If not, it should be APARable.

IEFC657I is bogus.  It should be an error to use a symbol without defining it,
not to define a symbol without using it.

IBM needs to get its act together and understand customers' needs.

>and the procedure parm was not passed through into the parmsdd, symbols I
>create are...  procedure parms are not
>
>hence my convoluted solution using intermediate symbols and some dummy
>iefbr14 steps to use the procedure parms.


>> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice wrote:
>> > >
>> > > I want to use a started task to start my web browser, but the size
>> > > of the parameters exceeds the 100 char limit for parm=
>> > >
>> > > Is there a nice way of passing the data?
>> > >
>> > > Ive tried using symbols, and passing them in to an instream dataset,
>> > > with SYMBOLS=
>> > > I then need dummy steps to actually use the parameters, otherwise
>> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
>> > >
>> > > One attempt is below.
>> > >
>> > > //COLWEB   PROC ACTION='start',
>> > > //  DIR='/usr/lpp/ihsa_zos',
>> > > //  CONF='/u/mqweb3/conf/httpd.conf',
>> > > //  T='-t -DDUMP_CONFIG'
>> > > //*-
>> > >
>> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
>> > > T2='' *
>> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
>> > > //STDINDD *,*SYMBOLS=EXECSYS *
>> > >
>> > > */bin/apachectl -k  -f  -DNO_DETACH   *
>> > > *blah blah blah*
>> > > /*
>> > > //STDOUT   DD  SYSOUT=H
>> > > //STDERR   DD  SYSOUT=H
>> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>> > >
>> > >
>> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
>> > >
>> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
>> > > //  PEND

-- 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: Trying to use long parm= in started task

[Charles Mills]

+1

Every other programming and similar language that I know treats unreferenced 
symbols as either a non-event or a warning.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 1, 2021 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

On Wed, 1 Dec 2021 15:35:27 +, Colin Paice wrote:

>I tried that ...
>I get
>IEFC657I THE SYMBOL ACTION WAS NOT USED...
>Where action is one of the procedure parameters.
>
o // SET should suffice to establish use.  If not, it should be APARable.

o // SET should suffice to establish use.  If not, it should be APARable.

IEFC657I is bogus.  It should be an error to use a symbol without defining it,
not to define a symbol without using it.

IBM needs to get its act together and understand customers' needs.

>and the procedure parm was not passed through into the parmsdd, symbols I
>create are...  procedure parms are not
>
>hence my convoluted solution using intermediate symbols and some dummy
>iefbr14 steps to use the procedure parms.


>> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice wrote:
>> > >
>> > > I want to use a started task to start my web browser, but the size
>> > > of the parameters exceeds the 100 char limit for parm=
>> > >
>> > > Is there a nice way of passing the data?
>> > >
>> > > Ive tried using symbols, and passing them in to an instream dataset,
>> > > with SYMBOLS=
>> > > I then need dummy steps to actually use the parameters, otherwise
>> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
>> > >
>> > > One attempt is below.
>> > >
>> > > //COLWEB   PROC ACTION='start',
>> > > //  DIR='/usr/lpp/ihsa_zos',
>> > > //  CONF='/u/mqweb3/conf/httpd.conf',
>> > > //  T='-t -DDUMP_CONFIG'
>> > > //*-
>> > >
>> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
>> > > T2='' *
>> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
>> > > //STDINDD *,*SYMBOLS=EXECSYS *
>> > >
>> > > */bin/apachectl -k  -f  -DNO_DETACH   *
>> > > *blah blah blah*
>> > > /*
>> > > //STDOUT   DD  SYSOUT=H
>> > > //STDERR   DD  SYSOUT=H
>> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>> > >
>> > >
>> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
>> > >
>> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
>> > > //  PEND

-- 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: Trying to use long parm= in started task

[Seymour J Metz]

Does the browser support long parms?


--
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: Wednesday, December 1, 2021 3:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Trying to use long parm= in started task

I want to use a started task to start my web browser, but the size of the
parameters exceeds the 100 char limit for parm=

Is there a nice way of passing the data?

Ive tried using symbols, and passing them in to an instream dataset, with
SYMBOLS=
I then need dummy steps to actually use the parameters, otherwise you get
IEFC657I THE SYMBOL ACTION WAS NOT USED

One attempt is below.

//COLWEB   PROC ACTION='start',
//  DIR='/usr/lpp/ihsa_zos',
//  CONF='/u/mqweb3/conf/httpd.conf',
//  T='-t -DDUMP_CONFIG'
//*-



*//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
T2='' *
//IHS  EXEC PGM=BPXBATCH,REGION=0M
//STDINDD *,*SYMBOLS=EXECSYS *


*/bin/apachectl -k  -f  -DNO_DETACH   *
*blah blah blah*
/*
//STDOUT   DD  SYSOUT=H
//STDERR   DD  SYSOUT=H
//STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)


*//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *

*//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
//  PEND

--
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: Trying to use long parm= in started task

[Paul Gilmartin]

On Wed, 1 Dec 2021 15:35:27 +, Colin Paice wrote:

>I tried that ...
>I get
>IEFC657I THE SYMBOL ACTION WAS NOT USED...
>Where action is one of the procedure parameters.
>
o // SET should suffice to establish use.  If not, it should be APARable.

o // SET should suffice to establish use.  If not, it should be APARable.

IEFC657I is bogus.  It should be an error to use a symbol without defining it,
not to define a symbol without using it.

IBM needs to get its act together and understand customers' needs.

>and the procedure parm was not passed through into the parmsdd, symbols I
>create are...  procedure parms are not
>
>hence my convoluted solution using intermediate symbols and some dummy
>iefbr14 steps to use the procedure parms.


>> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice wrote:
>> > >
>> > > I want to use a started task to start my web browser, but the size
>> > > of the parameters exceeds the 100 char limit for parm=
>> > >
>> > > Is there a nice way of passing the data?
>> > >
>> > > Ive tried using symbols, and passing them in to an instream dataset,
>> > > with SYMBOLS=
>> > > I then need dummy steps to actually use the parameters, otherwise
>> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
>> > >
>> > > One attempt is below.
>> > >
>> > > //COLWEB   PROC ACTION='start',
>> > > //  DIR='/usr/lpp/ihsa_zos',
>> > > //  CONF='/u/mqweb3/conf/httpd.conf',
>> > > //  T='-t -DDUMP_CONFIG'
>> > > //*-
>> > >
>> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
>> > > T2='' *
>> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
>> > > //STDINDD *,*SYMBOLS=EXECSYS *
>> > >
>> > > */bin/apachectl -k  -f  -DNO_DETACH   *
>> > > *blah blah blah*
>> > > /*
>> > > //STDOUT   DD  SYSOUT=H
>> > > //STDERR   DD  SYSOUT=H
>> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>> > >
>> > >
>> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
>> > >
>> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
>> > > //  PEND

-- gil

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

Re: Trying to use long parm= in started task

[Colin Paice]

I tried that ...
I get
IEFC657I THE SYMBOL ACTION WAS NOT USED...
Where action is one of the procedure parameters.

and the procedure parm was not passed through into the parmsdd, symbols I
create are...  procedure parms are not

hence my convoluted solution using intermediate symbols and some dummy
iefbr14 steps to use the procedure parms.

On Wed, 1 Dec 2021 at 15:08, Charles Mills  wrote:

> The mailing list program is making me add some random text here so that it
> won't think this is a Listserve command.
>
> Here is an example of what you need to do:
>
> //EXPORT SYMLIST=*
> ...
> //PARMS  DD  *,SYMBOLS=JCLONLY
> ,,
> 
> /*
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Styles, Andy (ITS zPlatform Services)
> Sent: Wednesday, December 1, 2021 2:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> Classification: Public
>
> Providing it's running under JES2 or JES3 and not SUB=MSTR, instream data
> in procedures is fine:
>
> //PGM EXEC PGM=FRED,PARMDD=PARMS
> //PARMS DD *
> blah blah blah
>
> Andy Styles
> z/Series System Programmer
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Colin Paice
> Sent: 01 December 2021 09:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Trying to use long parm= in started task
>
> *** This email is from an external source - be careful of attachments and
> links. Please report suspicious emails ***
>
> PARMDD was the easy bit.  But how do you get the started task parameters
> into PARMDD?
>
> On Wed, 1 Dec 2021 at 08:44, Mike Schwab  wrote:
>
> > PARMDD.
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Dparameter-examples-parmdd&
> > amp;data=04%7C01%7CAndy.Styles%40LloydsBanking.com%7Cb569694c823e46cb1
> > 59f08d9b4aac859%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C637739467
> > 878831910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qNneGDjjrQT88PlsI1Y35p
> > eTnmPLF6zMqCNK6ol%2Fe0A%3Dreserved=0
> >
> > On Wed, Dec 1, 2021 at 8:27 AM Colin Paice 
> wrote:
> > >
> > > I want to use a started task to start my web browser, but the size
> > > of the parameters exceeds the 100 char limit for parm=
> > >
> > > Is there a nice way of passing the data?
> > >
> > > Ive tried using symbols, and passing them in to an instream dataset,
> > > with SYMBOLS=
> > > I then need dummy steps to actually use the parameters, otherwise
> > > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
> > >
> > > One attempt is below.
> > >
> > > //COLWEB   PROC ACTION='start',
> > > //  DIR='/usr/lpp/ihsa_zos',
> > > //  CONF='/u/mqweb3/conf/httpd.conf',
> > > //  T='-t -DDUMP_CONFIG'
> > > //*-
> > >
> > >
> > >
> > > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> > > T2='' *
> > > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > > //STDINDD *,*SYMBOLS=EXECSYS *
> > >
> > >
> > > */bin/apachectl -k  -f  -DNO_DETACH   *
> > > *blah blah blah*
> > > /*
> > > //STDOUT   DD  SYSOUT=H
> > > //STDERR   DD  SYSOUT=H
> > > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> > >
> > >
> > > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
> > >
> > > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> > > //  PEND
> > >
> > > 
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> >
> >
> >
> > --
> > Mike A Schwab, Springfield IL USA
> > Where do Forest Rangers go to get away from it all?
> >
> > --
> > 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
> Lloyds Banking G

Re: Trying to use long parm= in started task

[Charles Mills]

The mailing list program is making me add some random text here so that it 
won't think this is a Listserve command.

Here is an example of what you need to do:

//EXPORT SYMLIST=*
...   
//PARMS  DD  *,SYMBOLS=JCLONLY  
,,

/*

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Styles, Andy (ITS zPlatform Services)
Sent: Wednesday, December 1, 2021 2:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

Classification: Public

Providing it's running under JES2 or JES3 and not SUB=MSTR, instream data in 
procedures is fine:

//PGM EXEC PGM=FRED,PARMDD=PARMS
//PARMS DD *
blah blah blah

Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: 01 December 2021 09:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

*** This email is from an external source - be careful of attachments and 
links. Please report suspicious emails ***

PARMDD was the easy bit.  But how do you get the started task parameters into 
PARMDD?

On Wed, 1 Dec 2021 at 08:44, Mike Schwab  wrote:

> PARMDD.
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Dparameter-examples-parmdd&
> amp;data=04%7C01%7CAndy.Styles%40LloydsBanking.com%7Cb569694c823e46cb1
> 59f08d9b4aac859%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C637739467
> 878831910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qNneGDjjrQT88PlsI1Y35p
> eTnmPLF6zMqCNK6ol%2Fe0A%3Dreserved=0
>
> On Wed, Dec 1, 2021 at 8:27 AM Colin Paice  wrote:
> >
> > I want to use a started task to start my web browser, but the size 
> > of the parameters exceeds the 100 char limit for parm=
> >
> > Is there a nice way of passing the data?
> >
> > Ive tried using symbols, and passing them in to an instream dataset, 
> > with SYMBOLS=
> > I then need dummy steps to actually use the parameters, otherwise 
> > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
> >
> > One attempt is below.
> >
> > //COLWEB   PROC ACTION='start',
> > //  DIR='/usr/lpp/ihsa_zos',
> > //  CONF='/u/mqweb3/conf/httpd.conf',
> > //  T='-t -DDUMP_CONFIG'
> > //*-
> >
> >
> >
> > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET 
> > T2='' *
> > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > //STDINDD *,*SYMBOLS=EXECSYS *
> >
> >
> > */bin/apachectl -k  -f  -DNO_DETACH   *
> > *blah blah blah*
> > /*
> > //STDOUT   DD  SYSOUT=H
> > //STDERR   DD  SYSOUT=H
> > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> >
> >
> > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
> >
> > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> > //  PEND
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.

Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham 
Street, London EC2V 7HN. Registered in England and Wales no. 11722983.

Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority

Re: Trying to use long parm= in started task

[Styles, Andy (ITS zPlatform Services)]

Classification: Public

Providing it's running under JES2 or JES3 and not SUB=MSTR, instream data in 
procedures is fine:

//PGM EXEC PGM=FRED,PARMDD=PARMS
//PARMS DD *
blah blah blah

Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: 01 December 2021 09:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task

*** This email is from an external source - be careful of attachments and 
links. Please report suspicious emails ***

PARMDD was the easy bit.  But how do you get the started task parameters into 
PARMDD?

On Wed, 1 Dec 2021 at 08:44, Mike Schwab  wrote:

> PARMDD.
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Dparameter-examples-parmdd&
> amp;data=04%7C01%7CAndy.Styles%40LloydsBanking.com%7Cb569694c823e46cb1
> 59f08d9b4aac859%7C3ded2960214a46ff8cf4611f125e2398%7C0%7C0%7C637739467
> 878831910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=qNneGDjjrQT88PlsI1Y35p
> eTnmPLF6zMqCNK6ol%2Fe0A%3Dreserved=0
>
> On Wed, Dec 1, 2021 at 8:27 AM Colin Paice  wrote:
> >
> > I want to use a started task to start my web browser, but the size 
> > of the parameters exceeds the 100 char limit for parm=
> >
> > Is there a nice way of passing the data?
> >
> > Ive tried using symbols, and passing them in to an instream dataset, 
> > with SYMBOLS=
> > I then need dummy steps to actually use the parameters, otherwise 
> > you get IEFC657I THE SYMBOL ACTION WAS NOT USED
> >
> > One attempt is below.
> >
> > //COLWEB   PROC ACTION='start',
> > //  DIR='/usr/lpp/ihsa_zos',
> > //  CONF='/u/mqweb3/conf/httpd.conf',
> > //  T='-t -DDUMP_CONFIG'
> > //*-
> >
> >
> >
> > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET 
> > T2='' *
> > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > //STDINDD *,*SYMBOLS=EXECSYS *
> >
> >
> > */bin/apachectl -k  -f  -DNO_DETACH   *
> > *blah blah blah*
> > /*
> > //STDOUT   DD  SYSOUT=H
> > //STDERR   DD  SYSOUT=H
> > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> >
> >
> > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
> >
> > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> > //  PEND
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.

Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham 
Street, London EC2V 7HN. Registered in England and Wales no. 11722983.

Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and Prudential Regulation Authority.

Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by 
the Financial Conduct Authority.

Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned 
subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 
6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht 
Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für 
Finanzdienstleistungsau

Re: Trying to use long parm= in started task

[Colin Paice]

PARMDD was the easy bit.  But how do you get the started task parameters
into PARMDD?

On Wed, 1 Dec 2021 at 08:44, Mike Schwab  wrote:

> PARMDD.
> https://www.ibm.com/docs/en/zos/2.1.0?topic=parameter-examples-parmdd
>
> On Wed, Dec 1, 2021 at 8:27 AM Colin Paice  wrote:
> >
> > I want to use a started task to start my web browser, but the size of the
> > parameters exceeds the 100 char limit for parm=
> >
> > Is there a nice way of passing the data?
> >
> > Ive tried using symbols, and passing them in to an instream dataset, with
> > SYMBOLS=
> > I then need dummy steps to actually use the parameters, otherwise you get
> > IEFC657I THE SYMBOL ACTION WAS NOT USED
> >
> > One attempt is below.
> >
> > //COLWEB   PROC ACTION='start',
> > //  DIR='/usr/lpp/ihsa_zos',
> > //  CONF='/u/mqweb3/conf/httpd.conf',
> > //  T='-t -DDUMP_CONFIG'
> > //*-
> >
> >
> >
> > *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> > T2='' *
> > //IHS  EXEC PGM=BPXBATCH,REGION=0M
> > //STDINDD *,*SYMBOLS=EXECSYS *
> >
> >
> > */bin/apachectl -k  -f  -DNO_DETACH   *
> > *blah blah blah*
> > /*
> > //STDOUT   DD  SYSOUT=H
> > //STDERR   DD  SYSOUT=H
> > //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
> >
> >
> > *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
> >
> > *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> > //  PEND
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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: Trying to use long parm= in started task

[Mike Schwab]

PARMDD.
https://www.ibm.com/docs/en/zos/2.1.0?topic=parameter-examples-parmdd

On Wed, Dec 1, 2021 at 8:27 AM Colin Paice  wrote:
>
> I want to use a started task to start my web browser, but the size of the
> parameters exceeds the 100 char limit for parm=
>
> Is there a nice way of passing the data?
>
> Ive tried using symbols, and passing them in to an instream dataset, with
> SYMBOLS=
> I then need dummy steps to actually use the parameters, otherwise you get
> IEFC657I THE SYMBOL ACTION WAS NOT USED
>
> One attempt is below.
>
> //COLWEB   PROC ACTION='start',
> //  DIR='/usr/lpp/ihsa_zos',
> //  CONF='/u/mqweb3/conf/httpd.conf',
> //  T='-t -DDUMP_CONFIG'
> //*-
>
>
>
> *//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
> T2='' *
> //IHS  EXEC PGM=BPXBATCH,REGION=0M
> //STDINDD *,*SYMBOLS=EXECSYS *
>
>
> */bin/apachectl -k  -f  -DNO_DETACH   *
> *blah blah blah*
> /*
> //STDOUT   DD  SYSOUT=H
> //STDERR   DD  SYSOUT=H
> //STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)
>
>
> *//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *
>
> *//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
> //  PEND
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Trying to use long parm= in started task

[Colin Paice]

I want to use a started task to start my web browser, but the size of the
parameters exceeds the 100 char limit for parm=

Is there a nice way of passing the data?

Ive tried using symbols, and passing them in to an instream dataset, with
SYMBOLS=
I then need dummy steps to actually use the parameters, otherwise you get
IEFC657I THE SYMBOL ACTION WAS NOT USED

One attempt is below.

//COLWEB   PROC ACTION='start',
//  DIR='/usr/lpp/ihsa_zos',
//  CONF='/u/mqweb3/conf/httpd.conf',
//  T='-t -DDUMP_CONFIG'
//*-



*//  EXPORT SYMLIST=* //  SET A1='' //  SET D1='' //  SET
T2='' *
//IHS  EXEC PGM=BPXBATCH,REGION=0M
//STDINDD *,*SYMBOLS=EXECSYS *


*/bin/apachectl -k  -f  -DNO_DETACH   *
*blah blah blah*
/*
//STDOUT   DD  SYSOUT=H
//STDERR   DD  SYSOUT=H
//STDENV   DD  DISP=SHR,DSN=USER.Z24C.PROCLIB(HTTPENV)


*//DUMMYEXEC PGM=IEFBR14,REGION=0M, //  PARM='  ' *

*//DUMMY2EXEC PGM=IEFBR14,REGION=0M, //  PARM='' *
//  PEND

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