From: IBM Mainframe Discussion List on behalf of Tom
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, February 14, 2019 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 13:07:07 -0800, Charles Mills wrote:
SYSSYM=ALLOW in JESPARMS?
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Thursday, February 14, 2019 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
OK, I am making some progress. I got past the JCL error
On Thu, 14 Feb 2019 14:28:35 -0600, Tom Marchant wrote:
>On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote:
>
>>>// SET PARM2=&PARM2
>>
>>Doesn't this run afoul of a rule elsewhere in the Ref. that symbols
>>are not to be defined in terms of other symbols.
>
>What rule is that? Where is i
dge
Sent: Thursday, February 14, 2019 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
I'm keeping this as my set of examples - Thanks Charles
Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...
On Thu, 14 Feb 2019 13:07:07 -0800, Charles Mills wrote:
>I think I could have done
>
>//jobname JOB ...
>// EXPORT SYMLIST=*
>//procname PROC ...
Maybe. I had a similar problem a few years ago, but in my case, I had a PROC
that was used in some jobs. I don't remember if I tried using the EXPORT
gt; To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/14/2019 02:07 PM
> Subject: Re: PARMDD and Symbols in a Started PROC
> Sent by: IBM Mainframe Discussion List
>
> @Tom's got it. Thanks.
>
> EXPORT works in a PROC and so forth but must come before the
> definition of the s
ERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
>The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED
>for every single one of the symbols.
> ..
Tnat message has struck me as insane design since I first encountered it
over 40 years ago. Completely ba
ry 14, 2019 11:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote:
>> // EXPORT gets specified first before any // SET stmts
>
>How do I do that in a PROC where the SETs are implicit in the PROC
On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote:
>>// SET PARM2=&PARM2
>
>Doesn't this run afoul of a rule elsewhere in the Ref. that symbols
>are not to be defined in terms of other symbols.
What rule is that? Where is it documented?
--
Tom Marchant
On Thu, 14 Feb 2019 10:57:06 -0800, Charles Mills wrote:
> ...
>Would it kill IBM to have some meaningful examples in the JCL reference?
>
The JCL Ref. contains a section:
Using symbols in started task JCL
Example: using JCL symbols
Prepare to be disappointed. I see no meaningful exam
On Thu, 14 Feb 2019 10:02:26 -0800, Charles Mills wrote:
> ...
>I have a started PROC with the typical sort of symbols declared on the PROC
>statement.
>...
>The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME
>
>//MYDDNAME DD *,SYMBOLS=JCLONLY
>
>I have a // EXPORT SYMLIST=*. I tr
On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote:
>> // EXPORT gets specified first before any // SET stmts
>
>How do I do that in a PROC where the SETs are implicit in the PROC
>statement, which is the very first statement?
>
>//procname PROC PARM1=value,PARM2=value
Try this:
//procname
rsday, February 14, 2019 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
> // EXPORT gets specified first before any // SET stmts
How do I do that in a PROC where the SETs are implicit in the PROC statement,
which is the very first statement?
//procname PROC PAR
ame PROC PARM1=value,PARM2=value
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rich Tabor
Sent: Thursday, February 14, 2019 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
Hadn
ist [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Rich Tabor
Sent: Thursday, February 14, 2019 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
Hadn't seen SYMLIST=* learn something new every day...
// EXPORT gets specified first before any // SET stmts
-
Rich Tabor
Sent: Thursday, February 14, 2019 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
Do you really have // EXPORT SYMLIST=* or something like // EXPORT
SYMLIST=(PARM1,PARM2)
--
For IBM
AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
Do you really have // EXPORT SYMLIST=* or something like // EXPORT
SYMLIST=(PARM1,PARM2)
--
For IBM-MAIN subscribe / signoff / archive access
OK, I am making some progress. I got past the JCL error by coding a bunch of
dummy // SET FOO=&PARM1 statements.
I am not getting errors from the program. I can see that no symbol
substitution has been done.
Is there any restriction on DD *,SYMBOLS in a started PROC?
Where should the EXPORT stat
Sent: Thursday, February 14, 2019 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
Do you really have // EXPORT SYMLIST=* or something like // EXPORT
SYMLIST=(PARM1,PARM2)
--
For IBM-MAIN subs
-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
How do you have your parms set in the PARMDD input?
I was told each parm needs to be on a separate line. Not sure how accurate
that
is.
Have you tried individual lines?
Which way is your input coded?
//MYDDNAME DD
Try doing each one on one line
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Charles Mills
> Sent: Thursday, February 14, 2019 11:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PARMDD and Symbols in a Started PROC
>
> C
@LISTSERV.UA.EDU
Subject: Re: PARMDD and Symbols in a Started PROC
How do you have your parms set in the PARMDD input?
I was told each parm needs to be on a separate line. Not sure how accurate
that is.
Have you tried individual lines?
Which way is your input coded?
//MYDDNAME DD *,SYMBOLS=JCLONLY
Combo of the two, Lizette.
There are nine parms spread across three lines.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, February 14, 2019 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re
How do you have your parms set in the PARMDD input?
I was told each parm needs to be on a separate line. Not sure how accurate that
is.
Have you tried individual lines?
Which way is your input coded?
//MYDDNAME DD *,SYMBOLS=JCLONLY
PARM1,PARM2,PARM3,etc
Or
//MYDDNAME DD *,SYMBOLS=J
On 2016-12-01 12:05, Farley, Peter x23353 wrote:
> Oh, and I forgot to say: For a DD * with symbol substitution:
>
> SYMBOLS=({JCLONLY|EXECSYS|CNVTSYS} [,logging-DDname])
>
> In anything *except* the PARMDD DD statement the " logging-DDname"
> subparameter will let you point to a logging DD (us
ter x23353
Sent: Thursday, December 01, 2016 1:58 PM
To: 'IBM Mainframe Discussion List'
Subject: RE: PARMDD
In:z/OS 2.1.0
z/OS MVS
z/OS MVS Programming: Assembler Services Guide
Linkage Conventions
Conventions for passing information through a parameter list
Program
In:z/OS 2.1.0
z/OS MVS
z/OS MVS Programming: Assembler Services Guide
Linkage Conventions
Conventions for passing information through a parameter list
Program in primary ASC mode
The diagram (I can’t paste that in plain text here) shows a maximum PARM length
of 32760, whic
On Tue, 2014-12-23 at 08:53 -0500, Steve Thompson wrote:
> Could someone give me a clue as to where converter text is defined?
Here are some comments from an exit I wrote in 1990. I don't know how
much of it is still accurate, so take it with a container ship full of
NaCl.
**
In <549973cc.3040...@copper.net>, on 12/23/2014
at 08:53 AM, Steve Thompson said:
>Could someone give me a clue as to where converter text is defined?
Try 4.0 MVS Converter / Interpreter Text Processing in z/OS MVS
Installation Exits, SA22-7593
--
Shmuel (Seymour J.) Metz, SysProg a
Data Areas PDFs can be found here:
http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r1pdf/#HAS
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
And maybe everyone knows this, but for a quick look you can submit a job
on hold and use INPUT ON in SDSF with SE to see the $INTTEXT in hex.
Dale R. Smith wrote:
On Tue, 23 Dec 2014 08:53:16 -0500, Steve Thompson wrote:
It has been a long time since I've done any JES2 stuff where I
was loo
On Tue, 23 Dec 2014 08:53:16 -0500, Steve Thompson wrote:
>It has been a long time since I've done any JES2 stuff where I
>was looking in JES C/Bs.
>
>Could someone give me a clue as to where converter text is defined?
>
>Regards,
>Steve Thompson
I believe what you are looking for is not in any
23, 2014 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 C/I Data (re: PARMDD issue)
Steve Thompson wrote:
>It has been a long time since I've done any JES2 stuff where I was looking in
>JES C/Bs.
Which of C/B or C/I (in your subject) are you refering?
>It is also interesti
On 12/23/2014 09:21 AM, Nims,Alva John (Al) wrote:
There are Documentation WEB pages and within them, scroll down to the "z/OS JES2" line on
the left and locate the "z/OS JES2 Data Areas" volumes.
For z/OS 1.13:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13/en/Ho
I think what you want starts here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E4B0/4.0
and, more specifically, here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E4B0/4.3
But these are the 1.12 version, because that's what I'm running. z/OS 2.1
version seems
ion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: Tuesday, December 23, 2014 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 C/I Data (re: PARMDD issue)
It has been a long time since I've done any JES2 stuff where I was looking in
JES C/Bs.
Could someone g
On 12/23/2014 09:03 AM, Elardus Engelbrecht wrote:
Steve Thompson wrote:
It has been a long time since I've done any JES2 stuff where I was looking in
JES C/Bs.
Which of C/B or C/I (in your subject) are you refering?
I am looking for where the Converter text is defined.
The last time I
Steve Thompson wrote:
>It has been a long time since I've done any JES2 stuff where I was looking in
>JES C/Bs.
Which of C/B or C/I (in your subject) are you refering?
>It is also interesting that the manuals keep referring to a JES2 Customization
>manual, but it doesn't exist in this set of
It has been a long time since I've done any JES2 stuff where I
was looking in JES C/Bs.
Could someone give me a clue as to where converter text is defined?
I've been using PDF copies of all the JES2 manuals in the
SK5T-9234 download. And using the extended search I just can't
seem to figure o
Jol has had
* IF statements for Symbolic Variables and Return Codes,
* Symbolic Variable Replacement in Card Image Files,
* Nested Procedures,
* Data Card Image files in Procs
* Simplified JCL Syntax
* 3270 CUA Compliant Full Screen Panel instruction
and much for over 30 years.
A few years ago,
On 12/12/2014 03:02 PM, Steve Thompson wrote:
On 12/12/2014 02:35 PM, Tom Marchant wrote:
On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson
wrote:
The EXPORT has to be coded BEFORE the SET statements, as
documented
in the first paragraph describing the EXPORT statement.
"Symbols must be s
On 12/12/2014 02:35 PM, Tom Marchant wrote:
On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson
wrote:
The EXPORT has to be coded BEFORE the SET statements, as documented
in the first paragraph describing the EXPORT statement.
"Symbols must be set to a value subsequent to the EXPORT stateme
On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson
wrote:
>Ok, I'm back to working on this aspect of a problem. So, I tried something
>interesting to try to figure this one out. The following JCL does NOT expand
>the string (the JOB after this does):
>
>//SXT7279T JOB (T,,MC),'TES
Ok, I'm back to working on this aspect of a problem. So, I tried something
interesting to try to figure this one out. The following JCL does NOT expand
the string (the JOB after this does):
//SXT7279T JOB (T,,MC),'TEST PARMDD ',CLASS=I,
// TIME=(,05),
//* TYPRUN=SCAN,
// MSGCLA
>It's wrong to quietly ignore an unsupported construct. Logging-DDname
>in a SYSIN data set mentioned in PARMDD should result in a JCL syntax
>error and failure of the job before execution.
Your opinions are always welcome. They are not always agreed with.
For this case, I probably agree that a
aim.com]
Sent: December 7, 2014 12:16
Subject: Re: PARMDD -- any one use yet?
On Sun, 7 Dec 2014 11:20:40 -0500, Peter Relson wrote:
>
>I might well be thinking of something else, but for whatever reason I
>was thinking that something might show what substitution is done for
>PARMDD
On Mon, 8 Dec 2014 07:59:53 -0500, Peter Relson wrote:
>
>... At the time that PARMDD is (and
>has to be) processed (under the initiator task), various i/o operations
>are not supported (apparently including those needed to write to a the
>intended log). Changing that could be very costly, thus req
>...ignored...! WTF!? Time for a Requirement? Either
>the substitution result should be logged in logging-DDname
>or it should appear in an informative message after
>the EXEC statement.
You are always encouraged to submit requirements. Logging might well be
rejected. It is a chicken-and-eg
In <5483d485.5010...@copper.net>, on 12/06/2014
at 11:16 PM, Steve Thompson said:
>We would still need to explain why JOB A works while JOB B, based on
>JOB A, isn't working.
Obviously, because they are different. It may take some experimenting
to determine which differences are relevant.
>
In <5483d3f5.9040...@copper.net>, on 12/06/2014
at 11:13 PM, Steve Thompson said:
>I know of NOTHING using cores today.
Well, then you only know about machines designed in the last few
decades. But you can find some 1960's (1950's?) vintage machines in
museums.
>How about identifying.
RCA 3
On Sun, 7 Dec 2014 11:20:40 -0500, Peter Relson wrote:
>
>I might well be thinking of something else, but for whatever reason I was
>thinking that something might show what substitution is done for PARMDD
>
Found it in:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.i
On 12/07/2014 02:24 AM, Peter Hunkeler wrote:
We would still need to explain why JOB A works while JOB B, based on JOB A,
isn't working.
How about posting the two JCLs?
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff
On 12/07/2014 02:23 AM, Peter Hunkeler wrote:
>
SYMBOLS parameter
Parameter type
Keyword, optional
Purpose
Use the SYMBOLS parameter to request JES to perform symbol substitution within
in-stream data.
Syntax
SYMBOLS=({JCLONLY|EXECSYS|CNVTSYS} [,logging-DDname])
Valid values: Specify one of thre
>We would still need to explain why JOB A
>works while JOB B, based on JOB A, isn't
>working.
Perhaps you could consider starting this thread over again, this time
providing the complete information.
I might have missed it, but I do not think you showed what the symbol
values were, and you did
>We would still need to explain why JOB A works while JOB B, based on JOB A,
>isn't working.
How about posting the two JCLs?
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to l
>> A suggestion then: Specify a SYMBOLS logging DD, as I did in my example. It
>> *should* tell you what substitutions were actually made. >> I believe I've
>> read of such; I don't readily find it in the JCL Reference.
The JCL reference explains the SYMBOLS parameter as:
SYMBOLS parameter
Par
On 12/06/2014 06:22 PM, Shmuel Metz (Seymour J.) wrote:
In <5480d9dd.6000...@copper.net>, on 12/04/2014
at 05:02 PM, Steve Thompson said:
The one that does not work does pass to IKJEFT1B "ISPSTART
cmd(%NCMPL " and that's it. The rest of the parm string is NOT
passed.
What happedns if you
On 12/06/2014 06:20 PM, Shmuel Metz (Seymour J.) wrote:
In <5480ca98.3040...@copper.net>, on 12/04/2014
at 03:56 PM, Steve Thompson said:
On 12/04/2014 03:04 PM, Paul Gilmartin wrote:
On 2014-12-04 12:35, Steve Thompson wrote:
Like, what's the most efficient way to clear a register?
-
In <5480d9dd.6000...@copper.net>, on 12/04/2014
at 05:02 PM, Steve Thompson said:
>The one that does not work does pass to IKJEFT1B "ISPSTART
>cmd(%NCMPL " and that's it. The rest of the parm string is NOT
>passed.
What happedns if you surround the parameter with apostrophes, e.g.,
"ISPSTA
In <5480ca98.3040...@copper.net>, on 12/04/2014
at 03:56 PM, Steve Thompson said:
>On 12/04/2014 03:04 PM, Paul Gilmartin wrote:
>> On 2014-12-04 12:35, Steve Thompson wrote:
>
>> Like, what's the most efficient way to clear a register?
>>
>> -- gil
>
>Well, mine is to pull the power plug.
>
On Thu, 4 Dec 2014 17:08:30 -0500, Farley, Peter x23353 wrote:
>A suggestion then: Specify a SYMBOLS logging DD, as I did in my example. It
>*should* tell you what substitutions were actually made.
>
I believe I've read of such; I don't readily find it in the JCL Reference.
>Paul Gilmartin had
On 12/05/2014 07:23 AM, Peter Relson wrote:
Might one conclude that the substitution works just fine, but that the
application to which you are sending the data can't handle longer data?
It is the user's responsibility to provide to the application only what it
can handle. The system will not pr
Might one conclude that the substitution works just fine, but that the
application to which you are sending the data can't handle longer data?
It is the user's responsibility to provide to the application only what it
can handle. The system will not prevent it (except for authorized cases
where
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: Thursday, December 04, 2014 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD -- any one use yet?
On 12/04/2014 04:15 PM, Farley, Peter x23353 wrote:
> The following definitely works, tested on V2.1 system today
On 12/04/2014 04:15 PM, Farley, Peter x23353 wrote:
The following definitely works, tested on V2.1 system today. HTH.
Yeah I'm having a Rod Serling afternoon.
I have two JOBs now where I am using this. One works, the other
does not.
The one that does not work does pass to IKJEFT1B "ISPSTA
, December 04, 2014 4:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PARMDD -- any one use yet?
The following definitely works, tested on V2.1 system today. HTH.
//YOURJOBX JOB (0,0). . . <== Supply your own
//*
//*
The following definitely works, tested on V2.1 system today. HTH.
//YOURJOBX JOB (0,0). . . <== Supply your own
//*
//* DOC: EXPERIMENT WITH INSTREAM SYMBOL SUBSTITUTION.
//*
On 12/04/2014 03:04 PM, Paul Gilmartin wrote:
On 2014-12-04 12:35, Steve Thompson wrote:
Like, what's the most efficient way to clear a register?
-- gil
Well, mine is to pull the power plug. I don't have to write code,
I don't have to deal with MAKE, BINDER, or anything else.
Clears ALL
On 2014-12-04 12:35, Steve Thompson wrote:
>
> So, if you need to your parm line (string), think about how you do the split.
> Because the next line read is concatenated to the prior line ignoring the
> right side spaces (at least that's what I have experienced). If you need a
> space between
Date: Thu, 4 Dec 2014 12:56:53 -0600
From: Peter X. DeFabritus
You may have put the EXPORT statement at the wrong point in the JCL. Try
putting it right after the JOB statement.
Sorry, it behaved the same whether it was just after the JOB card or just
before the EXEC PGM= I've tried mov
You may have put the EXPORT statement at the wrong point in the JCL. Try
putting it right after the JOB statement.
On Thu, 4 Dec 2014 18:40:03 +, Steve Thompson
wrote:
>I've run into a situation where we have a parm that expands to more than 100
>characters (sound like a familiar problem
Shmuel wrote:
The dope vectors contained addresses; a descriptor does not. The
equivalent of a dope vector is a locator/descriptor, not a descriptor
in isolation.
and this is the classical usage. It also retains a useful
distinction between, among others, LE discriptors, which---like PL/I
ba
Sorry, you're right of course, non-exact speaking on my part ...
I first had to check the German meaning of "dope" in this context to
understand what "dope vector" stands for ...
Am 01.04.2013 16:15, schrieb Shmuel Metz (Seymour J.):
In <515866be.3010...@t-online.de>, on 03/31/2013
at 06:39
In <515866be.3010...@t-online.de>, on 03/31/2013
at 06:39 PM, Bernd Oppolzer said:
>Of course, if the called program is PL/1, things get complicated
>again, because PL/1 needs descriptors (called dope vectors in
>earlier releases),
The dope vectors contained addresses; a descriptor does not.
In
,
on 03/31/2013
at 10:54 AM, Peter Relson said:
>I thought that by mentioning CALL, ATTACH, and XCTL"interface" you
>were referring to the interface to the target routine, where the
>"traditional" parameter list format is register 1 pointing to a
>parameter list each entry of which conta
Yes, and Bernd's point can be extended. CICS also copes not just
with single-parameter but with multi-parameter main programs,
options(main) PL/I procedures, too.
Peter Relson's distinction is valid and appropriate in one, in many
environments the most common, 'standard' context, invalid in othe
This is a very philosophical point of view, but:
the traditional EXEC PGM= parameter linkage can in fact be seen
as a special case of the traditional CALL/ATTACH/XCTL interface,
where the reg1 address list contains the address of only 1 parameter,
which is a character varying. Two more things, wh
>You seem to be contradicting yourself here. Or is there a (new?)
>way for the initiator to run programs other than "the traditional
>CALL/EXEC/ATTACH/XCTL interface", but transparent to the program
>which is run?
I thought that by mentioning CALL, ATTACH, and XCTL"interface" you were
referring
On Sat, 30 Mar 2013 09:15:31 -0400, Peter Relson wrote:
>
>PARMDD does not use the traditional CALL/EXEC/ATTACH/XCTL interface. I
> ???
>thought that had been made clear. The use of PARMDD requires no change
>to programs that can handle any length in the 0-32760 range other than
>If when PARMDD appeared on the EXEC statement an old program
>simply received
>
>R1 -> fullword -> H'0'
>
>... there'd be no integrity threat in passing PARMDD to old authorized
>programs. They are all prepared nowadays to handle PARM=''.
>However, IBM saw fit to provide the LONGPARM attribut
On Tue, 26 Mar 2013 23:09:16 -0500, Ed Gould wrote:
>Paul:
>
>I think you are reading too much into John's presentation.
>After thinking about it I would guess that the exec statement and
>parm will remain essentially the same and if you want to pass a
>longer parm then you would code the exec
On Tue, 26 Mar 2013 22:15:44 -0500, Paul Gilmartin wrote:
>Since PARMDD and PARM are mutually exclusive, I should be able to
>EXEC an existing library PROC, overriding with PARMDD.stepname=MYPARM
>and expect the PARM coded in the PROC to be nullified, right?
I would expect that you would have to
On Wed, 27 Mar 2013 17:45:18 -0400, Peter Relson wrote:
>
>>Since PARMDD and PARM are mutually exclusive, I should be able to
>>EXEC an existing library PROC, overriding with PARMDD.stepname=MYPARM
>>and expect the PARM coded in the PROC to be nullified, right?
>
>I do not share the expectation. It
Ed Jaffe wrote:
On 3/26/2013 3:24 PM, Paul Gilmartin wrote:
From:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP13-0013
oSupport for passing parameter lists up to 32,760 bytes in length
to a program from JCL. A
On Wed, 27 Mar 2013 07:06:58 -0500, Tom Marchant wrote:
>
>>When long PARMS have been discussed here previously, the reactionaries
>>and IBM loyalists have objected, "Oh, no! We can't have that! Suddenly
>>programs that clearly failed on JCL errors will instead program check
>>on buffer overruns
Tom Marchant wrote
Indeed, when I started as an application programmer in 1970, that was
the standard that my code was expected to follow.
and that is what I have always recommended and, on occasion, embodied
in programming standards.
This notion is also embedded in the PL/I convention, as in
On Tue, 26 Mar 2013 16:24:49 -0600, Paul Gilmartin wrote:
>When long PARMS have been discussed here previously, the reactionaries
>and IBM loyalists have objected, "Oh, no! We can't have that! Suddenly
>programs that clearly failed on JCL errors will instead program check
>on buffer overruns and
On Tue, 26 Mar 2013 23:09:16 -0500, Ed Gould wrote:
>I think you are reading too much into John's presentation.
I don't think he is.
>After thinking about it I would guess that the exec statement and
>parm will remain essentially the same and if you want to pass a
>longer parm then you would
Paul:
I think you are reading too much into John's presentation.
After thinking about it I would guess that the exec statement and
parm will remain essentially the same and if you want to pass a
longer parm then you would code the exec pgm=a,parmdd= ..
if an old program would look i
On Tue, 26 Mar 2013 17:40:24 -0500, Ed Gould wrote:
>
>I am *GUESSING* that the new statement is a nod to compatibility.
>There are just too many programs that accept the current limit and
>would be broken if the parameter passing was changed. I am OK with it
>myself. Since any *NEW* program would
On 3/26/2013 3:24 PM, Paul Gilmartin wrote:
From:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP13-0013
oSupport for passing parameter lists up to 32,760 bytes in length
to a program from JCL. A new PARMDD D
On Tue, 26 Mar 2013 17:40:24 -0500, Ed Gould wrote:
>
>I am *GUESSING* that the new statement is a nod to compatibility.
>There are just too many programs that accept the current limit and
>would be broken if the parameter passing was changed. I am OK with it
>myself. Since any *NEW* program would
Paul:
I am *GUESSING* that the new statement is a nod to compatibility.
There are just too many programs that accept the current limit and
would be broken if the parameter passing was changed. I am OK with it
myself. Since any *NEW* program would have to be programmed to accept
the parame
93 matches
Mail list logo
