On Thu, 10 Oct 2013 17:57:48 -0500, Peter X. DeFabritus wrote:
>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,
>
No! No! No! That's the worst thing they could possibly do. How would they
know what is the "proper LRECL", or that the truncated data is nonessential.
I imagine the TSO command:
DELETE FOO.BAR(MEMBER)
... truncated right here (view monospaced): ><
>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.
>
Are they committing to doing it for IBM utilities? (PARM=NOSEQ and LRECL
tolerant?)
JCL error, dammit! (but it's unfortunate that utilities tend to quietly
truncate
73-80. That's a data integrity disaster waiting to happen. Perhaps an option
on the DD DATA statement to report a JCL error if any data extend to or beyond
column NN, where the user might specify NN as 72, 73, or other ad lib.
>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 wrote:
>>
>>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 [email protected] with the message: INFO IBM-MAIN
