I had this exact problem during the Early Support Program for z/OS 2.1. I ran
an IDCAMS step, where, after substitution, the IDCAMS control statement went
past column 72. Here's the error I got:
IDC3302I ACTION ERROR ON TECH008.TECH008Z.JOB01701.
D0000101.?
IDC3313I ** ,TECH008Z,DEFCL ,JES ,I,SYSIN ,
GET ,WRONG LEN RECRD,**************,
I suggested either truncating the record to the proper LRECL, so at least the
user would realize what's going on, or perhaps breaking it up into 2 records.
But IBM was suggesting that each individual utility be changed, which didn't
make much sense to me. I believe the current situation will lead to confusion
and the wasting of a lot of folks' time. I put in a Marketing Requirement in
the hopes of changing this behavior, but I'm not sure if a solution will ever
appear. In the meantime, this unfortunate situation will continue.
On Thu, 10 Oct 2013 15:22:16 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:
>(We don't yet have 2.1, so I can't experiment.)
>
>There was plenty discussion here of the new-fangled facility to
>support symbol resolution in instream data sets, but I don't
>recall whether this specifically was discussed:
>
>What will happen (JES2, specifically) if substituting a symbol in
>an instream data set causes a record to exceed the otherwise
>LRECL (over which the programmer now has little control)?:
>
>o LRECL is adjusted to accommodate (almost best)?
>
>o JCL error (ugh!)?
>
>o The record is quietly truncated? Worst; even if a warning is
> issued the job should not be allowed to execute. (I hate quiet
> truncation!)
>
>Best of all would be to restore control to the programmer:
>allow RECFM and/or LRECL to coexist with * or DATA on the
>DD statement (presently they're mutex). Those values, if
>coded, should be merged with the DCB at OPEN. An oversize
>record, either read directly from INTRDR or created by substitution
>should cause a JCL error (I believe this can be detected before
>job initiation), and the programmer could change either the data
>or the attributes and resubmit.
>
>-- 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
