On 04/03/2013 07:29 AM, Paul Gilmartin wrote:
On Wed, 3 Apr 2013 06:47:01 -0500, John Gilmore wrote:
Peter's most recent response:
<begin extract>
The 100 character restriction is applied to the following case, only:
environment is APF; and jobstep program is AC(1); and the program is
not bound with LONGPARM.
</end extract>
is admirable, unambiguous, and, I think, definitive.
It leaves a couple holes. One question in the thread concerned:
o Jobstep program is AC(1), from an authorized library, so
the environment was authorized.
o Jobstep program ATTACHEs a subprogram AC(0), from an
authorized library, bound with NOLONGPARM, passing an
argument longer than 100 bytes.
o Is the 100 character restriction applied? My conjecture is, "No,":
- There's no such restriction under z/OS 1.13 and I doubt that
IBM intends to impose a new restriction in 2.1.
- The passed argument may not be structured with a halfword
count field, so ATTACH has no way of knowing its length. I
surmise the restriction is applied only by the initiator when
ATTACHing the jobstep program. Is this right?
I thought it pretty clear that in the context in Peter's response "the
program is not bound" could only be reasonably interpreted as "the
[jobstep] program is not bound". In other words, only the attributes of
the job step program are at issue. An authorized program that can be
invoked from a job step should obviously not be bound with LONGPARM if
there is any way that could cause it to pass control while authorized
to some internally invoked program with data (passed by standard
parameter linkage or any other means) that it can't handle safely. The
100 character restriction has never applied except to the job step
program directly invoked by JCL.
Or:
o JCL specifies "EXEC PGM=jobstep program,PARMDD=ddn"
o Jobstep program is AC=1, from an authorized library, no
LONGPARM attribute.
o The PARM resolved from ddn is no longer than 100 bytes.
o Is this permissible? I would actually hope not:
- there's a lower potential astonishment factor if the
restriction applies to any such use of PARMDD, not
contingent on how resolution of symbols in an instream
ddn may affect the resolved PARM length.
- The coding in the initiator is likely simpler for the more
static test.
-- gil
My original understanding was that the LONGPARM binder attribute was
required in order to access the new function (which seemed to mean, use
of PARMDD), but the references to this as a 100-character restriction
have gotten me slightly confused as well. The issue obviously is
whether the 100-character restriction is applied to the syntax used, or
to the actual parameter value supplied. Is the 100-character
restriction implemented as a restriction on use of PARMDD, because it
might be used to supply a long parameter; or can both syntactical forms
be used interchangeably in all cases as long as the 100-character limit
is not exceeded?
If the initial statement of the feature is accurate, then the capability
controlled by LONGPARM really should be described as a "PARMDD
restriction", not as in recent posts as a "100-character restriction",
because there are reasons one might want to use PARMDD syntax for
passing shorter parameters..
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
