On 3 Sep 2009 18:40:03 -0700, in bit.listserv.ibm-main you wrote: >let's take some possibilities. >1. the verify succeeds - there are no hanging end of file or paritial >splits or fatal errors. wha happened to the blocks that had not been >written to dasd yet - well, they are gone into the bit bucket in the >sky. >2. the verify succeeds - and operations is rerunning the exact same >job - some of the updates are going double update - some inserts will >fail as duplicate, totals have wrong values. > >status 97 means that a job abended and nothing has been done to >recover the file. That is usually not a good thing.
Given that the general action for a successful verify is to continue as if nothing happened, it would be interesting to see if someone took the approach of trying to get a PMR against this 20 - 30 year old problem. Since 97 is implementer defined unless the standard specifically states that a 9x status code is unsuccessful, I doubt this would work (I will try to remember to look this up). I also recall having to this for COBOL 74 so it goes back to at least ICF VSAM. It also shows that as a community we are sheep for having put up with this monstrosity for this length of time. If I were still active in SHARE, I would give a requirement to return status 00 for successful implicit verify a 5 (imperative) and be willing to accept that this could be governed by a LE option or compiler option. ---------------------------------------------------------------------- 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
