https://www.ibm.com/docs/en/cobol-zos/6.2?topic=entries-block-contains-clause
Is BLOCK0 specified as a compiler option? For a way to apply BLOCK CONTAINS 0 to QSAM files that do not already have a BLOCK CONTAINS clause, see the description of the compiler option, BLOCK0 in the Enterprise COBOL Programming Guide On Wed, Jun 15, 2022 at 8:34 AM Seymour J Metz <[email protected]> wrote: > > No, RECFM=F is unblocked, whether you use BSAM, QSAM or something else, > regardless of whether it is on DASD or tape and regardless of whether it is > SMS managed.. It means that the access method makes no attempt to block or > unblock logical records. Think of it as RECFM=FB with LRECL and BLKSIZE the > same. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] on behalf of > Rob Schramm [[email protected]] > Sent: Tuesday, June 14, 2022 11:43 PM > To: [email protected] > Subject: Re: SMS confusion on when system determined blocksize is used > > Pretty sure the Using Data Sets should describe what is happening. > > I do not understand is the Non-sms data set that you say is unblocked. > What does that even mean? If it is on disk and QSAM .. it is blocked. > SDB should work regardless of SMS or non-sms as long as blksize=0 and the > other caveats in the SDB section are met. > > Also.. you say that the Tape data set is unblocked.. I question that as > well. But I don't see that you included the data set information for the > non-sms and the tape data sets. > > Rob. > > > On Tue, Jun 14, 2022 at 6:07 PM Pommier, Rex <[email protected]> > wrote: > > > Hi list, > > > > I had a strange one thrown to me from a developer and I'm hoping somebody > > can point me to something to explain why this is happening. Environment is > > z/OS 2.4 and Cobol 6.3,pretty vanilla. I've read through SDB explanations > > in several manuals but haven't found the explanation as to why this is > > happening. > > > > We have a Cobol program with record length 200, and the developer > > inadvertently omitted the BLOCK CONTAINS 0 RECORDS clause which according > > to the Cobol manual says the file is supposed to be unblocked. Developer > > runs the program in batch using a DD card like this for the unblocked > > dataset. > > > > //VSF DD DSN=TEST.DATASET.NAME, > > // DISP=(NEW,CATLG,DELETE), > > //* UNIT=VTS, > > // UNIT=SYSDA, > > // SPACE=(CYL,(5,20),RLSE), > > // DCB=MDCB.TEST.DATASET.NAME > > > > The only DCB information provided is in the MDCB statement which looks > > like this: > > > > % XT Device Dsorg Recfm Lrecl Blksz > > ---------------------------------------------- > > MDCB.TEST.DATASET.NAME > > 0 ? 0 3390 FB 200 0 > > > > Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB. > > > > If he runs his job with the DD card as above, going to an SMS managed > > dataset, he gets half track blocking. If he runs it changing it to > > UNIT=VTS, he gets an unblocked dataset, and if he runs it against DASD with > > an unmanaged dataset name, he also gets it unblocked. Definitely makes it > > look like something in the SMS configuration, however, our SMS dataclas > > that this dataset falls under does not specify to use SDB that I could > > find. So my questions are how to explain what's happening here? Why does > > the MDCB specification of SDB seem to override the Cobol program in the > > case of the SMS managed dataset but the Cobol program overrides the MDCB > > for the non-SMS datasets? > > > > TIA, > > > > Rex > > > > ---------------------------------------------------------------------- > > The information contained in this message is confidential, protected from > > disclosure and may be legally privileged. If the reader of this message is > > not the intended recipient or an employee or agent responsible for > > delivering this message to the intended recipient, you are hereby notified > > that any disclosure, distribution, copying, or any action taken or action > > omitted in reliance on it, is strictly prohibited and may be unlawful. If > > you have received this communication in error, please notify us immediately > > by replying to this message and destroy the material in its entirety, > > whether in electronic or hard copy format. Thank you. > > > > > > ---------------------------------------------------------------------- > > 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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
