On Mon, 14 Jan 2008 21:34:06 +0000, Ted MacNEIL wrote: >>If you use IEBGENER in straight copy mode, it does check and enforce that the >>LRECLs match. > >I think that violates the principle of least astonishment. > Historically, many programs have had RECFM, LRECL, and sometimes BLKSIZE hard coded in DCB macros. The effect astonished me some decades ago when I first encountered it. Many of us have become so accustomed to it that we are astonished when behavior is otherwise.
About that era, I was supporting a tool that kept a melange of listings (Linkage Editor, Assembler, Pascal) in a single PDS with RECFM=VBA, LRECL=255 (the largest ISPF tolerated at the time), copying the output from each with a utility that converted the format. From time to time, some troublemaker would directly allocate a member of that PDS to SYSPRINT and run IEV90. (Usually the troublemaker would remember to specify a member name.) I'd fix it, sacrificing the offending member. Ever since, I've firmly believed that the access method should NEVER change the attributes of an existing non-empty data set. Instead, ABEND Sx13. Lately I encountered (and probably whined here) about an IBM utility whose rules for output data sets are: o If the existing data set LRECL is less than the program requires, ABEND. o If the existing data set LRECL is greater than 150, OPEN and CLOSE with 150 in the DCB, thereby updating the DSCB. Even if it's a PDS. Go figure. >If I have a VB (or even an FB) with a larger LRECL, it shouldn't take >handstands to copy! > It's the OS/360 way. REPRO is relatively friendly. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
