On 3 Apr 2013 05:29:17 -0700, in bit.listserv.ibm-main you 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?
This has been interesting. I recall when the maximum PARM length was 144. I learned to code to make sure the PARM length was in the range I was expecting (normally far less than either 144 or 100). Since the most an initiator can control is what it passes to the invoked module, it is irrelevant as to what is passed on to subsequent modules by the original invokee because it could pass anything in a call that is decided in the design so what the initiator passes it is irrelevant to subsequent calls. Clark Morris > >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 > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
