On Mon, 27 Feb 2017 14:54:49 -0500, John Eells wrote: >Paul Gilmartin wrote: ><snip> >>> >> You're suggesting that a transcript or summary of those discussions >> is available. Can you cite? Thanks. >> ><snip> > >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
