As I basically mentioned, they're not committed to doing anything. On Thu, 10 Oct 2013 18:44:12 -0500, Paul Gilmartin <[email protected]> wrote:
>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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
