On Tue, 27 Sep 2022 13:50:14 -0500, Paul Gilmartin wrote:
>
>Breaking an existing authorized program in that fashion could be a buffer
>overrun leading to escalation of privilige; an integrity threat that I'd
>consider
>an incompatibility.
But are you talking about PARM=, which Peter has
Regarding your quarrel about "mainly": It is likely nothing will be changed.
There are many possible uses and there is no value in guessing at them in order
to try to list them.
And if one were to change to "only" then your analogous approach would be to
quibble about that because it is
On Tue, 27 Sep 2022 16:55:00 +, Peter Relson wrote:
>Gil wrote
>
>For compatibility with historic behavior, I'd expect NOLONGPARM (the default)
>not to be enforced when a program is invoked by LINK, ATTACH, etc. or from an
>unauthorized STEPLIB concatenation.
>
>
>LONGPARM is relevant only
Gil wrote
For compatibility with historic behavior, I'd expect NOLONGPARM (the default)
not to be enforced when a program is invoked by LINK, ATTACH, etc. or from an
unauthorized STEPLIB concatenation.
LONGPARM is relevant only for the building of the parameter area for the
jobstep program and
PARMDD.
But the Guide ought to mention TSO, not with the "mainly" cop out.
>-Original Message-
>From: Paul Gilmartin
>Sent: Monday, September 26, 2022 10:35 AM
>
>In Program Management: User's Guide and Reference" I read:
>"[LONGPARM] applies mainly to programs that
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Monday, September 26, 2022 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LONGPARM applies?
In Program Management: User's Guide and Reference" I read:
"[LONGPARM] applies mainly to programs tha
In Program Management: User's Guide and Reference" I read:
"[LONGPARM] applies mainly to programs that are invoked using a JCL EXEC
statement or a z/OS UNIX EXECMVS callable service."
"mainly" is tantalizing. It leads the reader to wonder what exceptions might
