subject:"Re\: Question about PARMDD"

Re: Question about PARMDD

2017-02-28 Thread Paul Gilmartin

On Mon, 27 Feb 2017 14:54:49 -0500, John Eells wrote:

>Paul Gilmartin wrote:
>
>>>
>> You're suggesting that a transcript or summary of those discussions
>> is available.  Can you cite?  Thanks.
>>
>
>
>I suggested neither one, so I am a bit puzzled about how you inferred
>that.  What I wrote was, "In fact, there was a protracted discussion
>right here in IBM-MAIN about how we should implement this support, well
>in advance of its actual appearance, led by the designer. I am
>reasonably confident that you can find in that discussion why it was
>done as it was, if you care to look."
> 
My apologies.  I overlooked the reference to IBM-MAIN.

>The IBM-MAIN archives are searchable, here:
>https://listserv.ua.edu/archives/ibm-main.html
>
>If you are sufficiently interested, you can find the discussion.
>
The archives are a pretty big target, given the decades of discussion of
PARM length, here and elsewnere.  I'll rely on memory

I recall a general wish for a longer PARM, no mention of anything like
PARMDD until IBM unveiled it.

IIRC, there some feeling that for very long PARMs command files are
a better approach.  Alas, some utilities don't support command files
ahd may require PARM strings longer that 100 characters.  Command
files are more practical with (recent) JCL enhancements:
o JCLLIB
o DD DATA SYMBOLS=...
o Instream data sets are no longer limited to LRECL=80
o Instream data sets may now appear in PROCs

(Yes, those facilities also apply to PARMDD.)

There was considerable concern that long PARMs might be passed to
programs not prepared for them, resulting in unexpected and undesirable
results.  The LONGPARM program object attribute is a good solution for
this.  But why is it enforced only on APF-authorized programs?  Unauthorized
programs might be similarly unprepared for PARM>100 bytes.  Granted,
for unauthorized programs there's no threat to system integrity, only to
application integrity, but that still matters.  Simply, LONGPARM should
be recognized alike for any program invoked as a job step task, whether
authorized on not.

And I'm looking at the "BPX.EXECMVSAPF.program_name FACILITY class
profile".  Why does this even exist?  Having two dissimilar ways to
achieve similar functions tends to confuse system administrators.
The LONGPARM attribute is preferable because:
o It can be set by the program owner who may lack authority to
  define RACF profile classes.
o It distinguishes between similar program_names residing in
  different libraries.

-- gil

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

Re: Question about PARMDD

2017-02-28 Thread Charles Mills

Oh man, that brings back some memories. Check out Figure 3 on page 25 of the 
1970 manual!

Interesting -- the example of a possible PARM= value ('P1,123,MT5') has not 
changed between that manual and 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab600/iea3b6_Syntax89.htm
 Ditto for the first three examples on 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab600/iea3b6_Examples_of_the_PARM_parameter.htm
 

*Accounting* information is limited to 142 characters -- perhaps that is what 
@Clark is recalling.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 28, 2017 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about PARMDD

On Mon, 27 Feb 2017 22:20:07 -0400, Clark Morris wrote:

>When did it change to 100?

Some time between 1967 and 1970.

See page 85 of
http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf
for OS/360, dated June, 1970


PARM=value
value
consists of up to 100 characters of information or options that the system is 
to pass to the processing program.


See also page 18 of the fifth edition of the OS/360 JCL manual, dated March, 
1967, where the limit is specified as 40 characters.

http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R01-08/C28-6539-4_OS_JCL_Mar67.pdf

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

Re: Question about PARMDD

2017-02-28 Thread Elardus Engelbrecht

Tom Marchant wrote:

>Some time between 1967 and 1970.

I think the limits of 40 or 100 characters were based on a quick way (without
using tapes or extra punch cards) to give shortish parameters to a program
using puch cards. Or so it was told to me by an oldie years ago.

About "Reference of the PARM field":

Then (from bitsavers):

"The exact location and format of control information passed to a processing
program are described under the topic titled "Program Management" in section 1
of the publication IBM System/360 Operating System: Supervisor and Data
Management Services.

Today (from my bookmanager):

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

Amazing how they worded same things then and now.

>See page 85 of
>http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf

Amazing those bitsavers place which I read now and then just for amusement. I
have a look at that book.

Same familiar monospaced fonts. Same two columns per page. Same weird spacing
of words. Pages left blank intentionally. ;-)

I also looked at the 'Programmers name' and am amazed that it is still 20 chars
long!
I tried out a job with 21 chars and got a JCL error with this nice message in
upper and lower case!
'HASP110 value of programmer name is too long'

39 matches

Mail list logo