There used to be a lot more 97s, before Language Environment. Now LE CLOSEs open files at the end (ab or otherwise) of a run-unit.
The description of 97 from the COBOL Language Reference seems, to me, cavalier: "For VSAM only: OPEN statement execution successful: File integrity verified." Hidden beneath this "File integrity verified" is the kicker, "Data integrity - go sing". Here's what z/OS DFSMS Using Data Sets has to say about it: "You can use a VSAM VERIFY macro call with certain types of opened VSAM data sets to ensure that fields in the VSAM control blocks are accurate. The VERIFY macro does not change the data in the data set. VERIFY does not correct missing or duplicate records or repair any damage in the index structure. The verification of control-block fields enables you to perform recovery actions on the improperly closed data set, if necessary. Besides the VSAM VERIFY macro, you can use the IDCAMS VERIFY command to verify a VSAM data set. When you issue this command, IDCAMS opens the VSAM data set for output, issues a VSAM VERIFY macro call, and closes the data set. The IDCAMS VERIFY command (without the RECOVER parameter) and the verification by VSAM OPEN are the same. Neither changes the data in the verified data set." Programmers cling so dearly to that "File integrity verified". It shouldn't happen in a program. There shouldn't be a "verify step" before each program. Mostly, accurate use of a scheduler keeps things straight. Doesn't it? Let's hope so. That's a great thing to say in programming. And yes, now that there are fewer 97s there are fewer easy ways to spot this if/when it happens. VSAMOPENFS(SUCKS) is a compiler option I'm not going to use by choice. On Tuesday, 16 February 2016 21:20:54 UTC, John McKown wrote: > On Tue, Feb 16, 2016 at 3:16 PM, Bill Woodger <[email protected]> > wrote: > > > A quote from 2009: > > > > "In fact, the fact that it is rare and should not happen for 'normal' > > processing tells me that you perhaps *shouldn't* just treat '97' as > > "everything is ok" and ignore it. Seems to me that even if you elect to > > continue processing it would be nice to know that the 97 status occured." > > > > We have had the 97 happen to us too. Most of the time it is due to the > data set not being CLOSEd, usually due to an ABEND. However, in the past, > we ran two z/OS images with shared DASD. And shared data sets. But not in a > sysplex (long ago). What the 97 _could_ mean is "the VSAM file is currently > OPEN to a job on the other system". If you just "go ahead" in this case, > and are doing updates on both sides, you are just begging for a corrupted > file. Especially if one of the jobs causes a CA split. Real fun (not) > recovering from that mess. > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
