On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve <steve_thomp...@stercomm.com> wrote:
>-----Original Message----- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >Behalf Of Frank Swarbrick >Sent: Thursday, May 14, 2009 7:03 PM >To: IBM-MAIN@bama.ua.edu >Subject: BLOCK CONTAINS > >I have been a bit of experimenting with z/OS QSAM files from a Cobol >program >and I find that the manuals don't exactly agree with my results. The >manuals seem to imply that if you use the BLOCK CONTAINS clause (whether >0 or something else) then the file has a RECFM of either VB or FB. And >if you don't include it then it's either V or B. > ><SNIPPAGE> > >Welcome to the MVS world. In the MVS world, we are not device dependant, >nor are we data definition locked/blocked. We generally don't have to >recompile our programs, change the DTF contents (DCB in MVS), etc. just >because the file attributes change (xSAM to VSAM is the exception). > >We do not have to link PIOCS or LIOCS routines to our programs to handle >I/O. The access method itself handles these things (particularly at the >QSAM level). > >If you are using a vendor to help you migrate, you should spend a bit of >time with them discussing all the changes to the environment and >different concepts between VSE and MVS. We are not using a vendor. We have systems and applications programmers that come from the MVS world, so we're going with that expertise. Though I suppose the fact that I am asking these questions here might indicate that said expertise is perhaps not sufficient? Hmmm... >As you have seen with your experiments, the information on the DD >statement will override what you have in your program. And the label >from the file in MVS actually contains the LRECL, BLKSIZE and RECFM, >which as I recall, is not the case with VSE (for disk or tape). > >However, what happens if the DD statement only contains the UNIT, SPACE, >DISP, and DSN? Does what you specify in the COBOL program then behave >the way the manual says? It depends on if the file is "pre-defined". If it is not, and I don't include DCB stuff on the DD, then it does what Cobol tells it to do (because there is no other place to get that information!). However if the file *is* predefined then *that* information appears (for blocking only, not for RECFM (V vs B) or LRECL) to override what Cobol states. Examples... If I predefine a file as RECFM=VB, BLKSIZE=10000, LRECL=4004 then 1) If Cobol says "BLOCK CONTAINS 10000" it works (of course). 2) If Cobol says "BLOCK CONTAINS 0" it works. 3) If Cobol says "BLOCK CONTAINS 12345" it works (!!!) 4) If Cobol does not have a BLOCK CONTAINS clause it works (!!!) This is the case no matter if I am reading from the file or writing to it. I am glad it works "no matter what". But the documentation seems to me to indicate that conditions 3 and 4 should not work, even though they do. That is where I am getting confused. >Your ESDS files being taken to SAM: Just make sure that you don't >actually depend on VSAM functions. Any hints as to what VSAM functions I might be depending on? The only case we've come upon so far is if the file is defined to CICS we have to leave it as an ESDS. We have about two dozen of those, but plan on converting all others to SAM. >And as far as your ASSIGN clause on the SELECT: you can probably leave >them as they are -- but I haven't used the latest COBOL for a migration. >In fact it has been a few years since I've done a migration. So unless >it is going to enforce something, as I recall, only what is after the >last "-" is paid attention to. And if you end with -SYS112 (or some >such), then the DD being looked for is SYS112. Both VSE and z/OS require the AS- prefix in order for Cobol to distinguish between between a VSAM ESDS and a regular SAM file. Other than that, yes, only the last "node" has any meaning. Nonetheless our conversion program is going to remove all of the superfluous stuff. I have been trying to get my fellow programmers to cut out this information for years, but with little success. Hopefully this way people will have fewer bad examples to follow! Thanks! Frank ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
