On Fri, 15 May 2009 15:28:37 +0200, Gilbert Saint-Flour <[email protected]> wrote:
>On Friday 15 May 2009 02:05, Frank Swarbrick wrote: > >> We are migrating from VSE to z/OS, and at the same time we are going >> to convert most of our existing ESDS files to regular sequential files. >> I see no reason to add "BLOCK CONTAINS 0" to all of our FD's if it has >> no affect (our VSAM FD's do not (generally!) specify the BLOCK CONTAINS >> clause, because it has no meaning to VSAM). > >IIRC, BLOCK CONTAINS 0 is only needed for OUTPUT files in COBOL, but I think >it's better to put it everywhere, so programmers later don't have to remember >where it's needed. What I'm getting at is that it appears to not even be required for OUTPUT files *as long as that information can be determined by other means*. >In 1991, I started to convert VSE applications to MVS/ESA and stopped to >generate DCB attributes on DD statements, except for output files in IDCAMS >REPRO and QUIKJOB programs, and a few others ones. A few years later, >I started to convert IDCAMS REPRO to something else, for several advantages, >among them not having to specify DCB info in the JCL. I'm convinced that >coding DCB attributes on DD statements is something almost always useless and >archaic. This is something all my customers agreed with, except an >outsourcing company that absolutely had to have DCB information on all output >DD statements, like this: DCB=(RECFM=xx,LRECL=yy,BLKSIZE=zzz). >This was in 2007 ! In z/OS ! I agree that DCB et al is generally not needed. The exceptions being 1) if "IEFBR14" is being used to create the file. 2) if a Cobol program is being used to create the file and one wants a blocked file but did not specify a BLOCK CONTAINS statement. It's this latter one that is my only cause for concern. We'd have to use RECFM and BLKSIZE statements if we wanted to override Cobol's default of non-blocked. Probably in the end we'll probably decide to include BLOCK CONTAINS 0 for all non-VSAM sequential files. It just bugs me that I have to do that when 95% of the time it's meaningless, because it's overriden by information retrieved elsewhere. >See examples here: http://gsf-soft.com/Prism-CS/Samples.shtml and you won't >see many DD statements that contain DCB info. This is very similar to what >I generated since 1991. > >As for the conversion of ESDS files to non-VSAM in COBOL programs, >changing AS-filename to S-ddname is not always the only thing you need >to do. Trust me ! Now you have me curious. What other gotchas do you think we might run in to? We already use FILE STATUS for file I/O error checking, so that should not be a problem. We have SELECT OPTIONAL for the cases where we want to be able to open for input an empty VSAM file. This does not (thank god!) appear to be an issue for SAM files, but leaving OPTIONAL does not appear to hurt either. I have not decided yet if we'll keep or remove the OPTIONAL clause. Probably remove it, since it has no meaning for SAM, but... To be honest, I was personally against "migrating" our ESDS files to SAM. I thought why take the chance? The one thing that has convinced me is the fact that we have quite a few cases in VSE where we sort several ESDS files together in to a single ESDS output file. DFSORT on z/OS does not allow this! Thus we have to use sequential files at least as intermediate files, so we figured we'd just convert almost all of them (we'll leave the ones defined to CICS as ESDS). Additionally we will want to use GDGs and I've been told (though I have not researched it) that you can't have GDG ESDS files. There may be other reasons, but I can't recall what they are at the moment... Frank ---------------------------------------------------------------------- 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
