On Mon, 20 Mar 2017 17:25:09 -0500, Bill Woodger wrote: >Paul, that doesn't answer the question of whether data was written to the >dataset with LRECL=X, the question I asked. Provides a way that the data is >actually valid. > >Otherwise the data is invalid. > IIRC, without reviewing the thread or RTFM, that R.S. posted JCL attempting to read the data set and that it should have been SMF data (does that imply LRECL<=32760?)
>Are you really so sure that a program, with no knowledge of the expected >structure of the data, can determine exactly how a VBS is pickled? > Of course there's no way to be sure. >Because if it is not exactly, it is no use. > Yet there may be some use. Inspect the data. If it doesn't appear to be VBS SMF data (enough redundancy to make a good guess), first verify that the DSN in the JCL is correct ... etc. (OK. Should have checked that first.) >Someone will just fix what the message says, then find out later >undeterminable bits of the data were missing or otherwise nonsense. > Likely the BOFH. I once got a punched deck with one card punched backward. Only plausable explanation is that before it was punched the card was loaded in the hopper backward. BOFH noticed the wrong corner cut and fixed the symptom. Or they'll waste time looking at "this is what it says the error is", when the error is something else. > I've done that. Then, I blame z/OS. If I miscode a PATH in a DD statement (typo), z/OS reports a catalog error. I no longer try to diagnose a catalog problem. (The catalog was never searched; the message was inappropriately repurposed.) I believe I went to SR; WAD; who cares about UNIX paths, anyway. >If it's broke in a really weird way, a message to say "it's broke in a really >weird way, you fix it, I don't want to give you a false sense of security" is >fine with me. Mileage may vary. > Yup. I once got a data error in an early record on a tape (not IBM equipment). I *happened* to have a dump of the first several blocks from the program that created the tape. Block n was simply missing entirely. Or, blocks n, n+1, n+2, ... were corrupted so they matched the intended content of blocks n+1, n+2, n+3, ... Even more unlikely than that an entire block got dropped. I unwrapped the first couple plies of the tape and noticed a transverse crease. Can an entire block levitate over the read head with no error detected? NRZI? Not IBM equipment. Recovery involved scissors, new reflective spot; re-create data set. Sometimes human wisdom gained from experience is better than Watson (sometimes not). And an intuitive maximum likelihood selection from various failure modes is guidance to selecting the best recovery scenario. (Perhaps the value of that day's SMF data is exceed by the cost to recover it.) HLASM's ASMA435I Record n in xxxxxxx on volume: vvvvvv is precious, and rarely misleading. And it reports UNIX paths meaningfully. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
