On Thu, 4 Dec 2014 17:08:30 -0500, Farley, Peter x23353 wrote: >A suggestion then: Specify a SYMBOLS logging DD, as I did in my example. It >*should* tell you what substitutions were actually made. > I believe I've read of such; I don't readily find it in the JCL Reference.
>Paul Gilmartin had a thread about this a while back (not sure if here or >TSO-REXX or where), from which my example was taken and subsequently modified. > The problem that can happen is "I/O errors" when the LRECL is exceeded after >symbol substitution (due, we think, to LRECL limitations, maybe in JES for DD >* datasets? Don't remember ATM). > Symbol substitution is performed only for DD * (or DD DATA) data sets. o There appears to be no practical global limitation on LRECL for instream data sets (perhaps thousands). o It seems that the "I/O error" is reported when substitution causes the length of a line to exceed not any universal limit, but LRECL for the individual instream data set, whether it be 80 or 1000 or ... o The JCL reference doesn't explain how LRECL is determined for an instream data set. I submitted an RCF on this. Accepted as clarification. I requested a preview, pending publication. Pubs said they'd consult the developer and get back to me with the information. They haven't. Empirically, the rules seem different between JES2 and JES3. o The LRECL= parameter is now permitted on instream data set DD statements. Empirically, specifying it has no effect (on JES2, at least). >In any case, the log may help. On Fri, 5 Dec 2014 10:19:10 -0500, Steve Thompson wrote: >On 12/05/2014 07:23 AM, Peter Relson wrote: >> Might one conclude that the substitution works just fine, but that theåç >> application to which you are sending the data can't handle longer data? >> >> It is the user's responsibility to provide to the application only what it >> can handle. The system will not prevent it (except for authorized cases >> where providing too much data can be a system integrity exposure for >> incorrectly written programs). >> Good point. I believe the capability for an authorized program to accept PARM>100 is specified as an attribute on the load module. I don't know what it's called; I don't know whether AMBLIST or Binder SYSPRINT reports it. Thanks. >Peter, I will use your post to give an update on this strangeness. > >The two JOBs in question are using IKJEFT1B. > I suspect IKJEFT1B is APF-authorized. I don't know whether it's linked as long PARM tolerant. I would not recommend simply re-linking it to change the attribute. >Once I got this working for the one JOB, I did a copy and paste >to the second JOB. For these two JOBs the step in question is >using IKJEFT1B, and ISPSTART is used to run a REXX. > >The second JOB fails. And the Logging DD doesn't get written to. > If the encountered I/O error precludes logging, it's a bad design. But the I/O ABEND should be reported in the job log. >I'm dropping this problem (PARMDD) for now, to focus on the REXX >logic issue (submitting compiles with wrong compile options) that >was the catalyst for this. > This is too damn complicated. IBM should have simply relaxed the syntactic limit on the length of the PARM= operand on the EXEC statement. Symbol substitution in instream data sets is a separate feature, having it's own value. Irritating. The TSO CALL command still enforces the now-obsolete 100-character PARM limit. Will anyone bet me that there will be an enhancement in the next release? The integrity concerns have been removed by the availability of the PARM length enforcement for APF authorized programs (provided that's enforced globally by ATTACH/LINK, not only by the initiator, bypassing enforcement for TSO CALL. That would be a wrong design, but too charactistic of IBM.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
