Paul Gilmartin wrote: >Long ago I dealt with this problem in Assembler. I left LRECL=0 in the DCB. >It would be merged in from either the DSCB or JCL, JCL dominating. I took the >DCB OPEN exit. If the value was still 0, unavailable from either of those >sources, I supplied a default LRECL; likewise for BLKSIZE and RECFM. >Nowadays, SDB gets control last and supplies its default.
Good approach, but I prefer to a$$ume that LRECL is fixed and known and then let the system abend the job if an incorrect LRECL is used. But then it is just me. >I don't know how much of this is supported by COBOL except that coding BLOCK >CONTAINS 0 RECORDS allows SDB to operate. Omitting the BLOCK CONTAINS clause >is equivalent to coding BLOCK CONTAINS 1 RECORD(S). A supremely stupid default >except, perhaps, in that it supports unit record devices. True. I don't like that, but have accepted do it the 'COBOL way'..... Grrrr. So, I always include that BLOCK CONTAINS clause. (from Shmuel) >>3. If it's a concatenation, test whether LRECL and RECFM are the same in >>every dataset. See ARL, probably in the RDJFCB documentation. Hmmm, I really need to RTFM on that. Interesting. Thanks Shmuel! >If RECFM=V* you may reasonably override to a larger value of LRECL; Including VBS (spanned records) too? >if RECFM=F* it's inadvisable to try to change LRECL. Yup. You get some nice abends for that change. Easy to fix all values to an expected LRECL value, but it depends on what you as programmer expects. Note: DFSORT has some clever magic tricks to figure out the LRECL, RECFM, DSORG of input data.... I wish I can see how that is done... Paul, thanks for your notes. It is very interesting! ;-) Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
