Re: COBOL / VSAM question.
The timing of it happening and being diagnosed with a recent unrelated change. On Fri, 18 Apr 2008 16:20:42 -0700, CICS Guy [EMAIL PROTECTED] wrote: IIRC (early VSAM DOS) What is it about the sysplex that prompts the 97? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Friday, April 18, 2008 2:30 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. snip Given that the problem has been around since VSAM started doing implicit verifies on OPEN when a verify situation existed (well over 20 years ago), I am surprised that the problem hadn't surfaced long before this year. -- 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
Re: COBOL / VSAM question.
'Now'? I fixed that problem in a COBOL program in Jan 2000. Eight years ago. Someone has not been keeping up to date with the state of the COBOL compilers. Do you expect the system programmer to tell the application programmer every change in how COBOL is working or that there is a new COBOL compiler and they should look at how it impacts them? I usually share the migration documentation with them so they can determine the impact on how they code. On Tue, 15 Apr 2008 12:06:34 -0400, Don Leahy [EMAIL PROTECTED] wrote: The fact that file status '97' has now become 'normal' isn't the fault of the original programmer. -- 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
Re: COBOL / VSAM question.
On Fri, Apr 18, 2008 at 2:02 AM, Kenneth E Tomiak [EMAIL PROTECTED] wrote: 'Now'? I fixed that problem in a COBOL program in Jan 2000. Eight years ago. Someone has not been keeping up to date with the state of the COBOL compilers. Do you expect the system programmer to tell the application programmer every change in how COBOL is working or that there is a new COBOL compiler and they should look at how it impacts them? I usually share the migration documentation with them so they can determine the impact on how they code. Yes, butaccording to the original poster, the problem did not surface until they converted to Sysplex, which was a recent event. That is the 'now' to which I referred. -- 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
Re: COBOL / VSAM question.
On 18 Apr 2008 05:50:57 -0700, in bit.listserv.ibm-main you wrote: On Fri, Apr 18, 2008 at 2:02 AM, Kenneth E Tomiak [EMAIL PROTECTED] wrote: 'Now'? I fixed that problem in a COBOL program in Jan 2000. Eight years ago. Someone has not been keeping up to date with the state of the COBOL compilers. Do you expect the system programmer to tell the application programmer every change in how COBOL is working or that there is a new COBOL compiler and they should look at how it impacts them? I usually share the migration documentation with them so they can determine the impact on how they code. Yes, butaccording to the original poster, the problem did not surface until they converted to Sysplex, which was a recent event. That is the 'now' to which I referred. Given that the problem has been around since VSAM started doing implicit verifies on OPEN when a verify situation existed (well over 20 years ago), I am surprised that the problem hadn't surfaced long before this year. Clark Morris -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Savor, Tom And I dislike application folks who won't test in my sandbox then complain when things blow up the first few days after a roll-up. An impasse? That was the point. I understand that you guys are very smart folks, but you guys LOVE to point all problems at application folksits tiresome. From the other side of the fence, it is equally tiresome when you folks point all problems at systems folks. anecdote A few years ago during acceptance testing of a z/OS upgrade, an application group reported that their application (an ISV product, btw) was abending in one of the two CICS regions in which it ran. After several hours of dump/trace analysis and several calls to the product vendor's support center, it was discovered that one of several interdependent product load modules was back-level in the abending region. After some pointed questions about that inconsistency, they finally admitted to having botched the backout of a test change package. When they corrected that inconsistency, the abends stopped. /anecdote -jc- -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Wednesday, April 16, 2008 8:33 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. [snip] From the other side of the fence, it is equally tiresome when you folks point all problems at systems folks. anecdote A few years ago during acceptance testing of a z/OS upgrade, an application group reported that their application (an ISV product, btw) was abending in one of the two CICS regions in which it ran. After several hours of dump/trace analysis and several calls to the product vendor's support center, it was discovered that one of several interdependent product load modules was back-level in the abending region. After some pointed questions about that inconsistency, they finally admitted to having botched the backout of a test change package. When they corrected that inconsistency, the abends stopped. /anecdote -jc- You actually had people come in to test?!? We got a single Sunday test on our LPAR split before production implementation. Because it was, you know, transparent. At that, we had one programming group bitterly complaining about having to do any work. They didn't even have to come in to the office. We have remote capability. They just didn't want to be bothered. This is the same group which refused to test a couple of years ago, then bitterly complained when one of their jobs failed. Apparently Tech Services (all 4 of us) are supposed to be able to test everything in our sandbox. This one group has better things to do, thank you very much! On the other hand, there is always enough blame to go around. Tech Services, or at least myself, does not always get it right either. However, when it blows up, my first desire is to get the problem fixed, not fix the blame. Oh, and I might also mention that our CEO doesn't give a ... whose problem it was. He just wants it fixed so that the business can go back to making some money and helping our customers. I think maybe he has the right idea. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
snipped Oh, and I might also mention that our CEO doesn't give a ... whose problem it was. He just wants it fixed so that the business can go back to making some money and helping our customers. I think maybe he has the right idea. end We allowed the users 4 weekends with 6 hour windows for testing. Kept 5 of us tied up monitoring the system with little presence. Had some issues at roll up but we got through it. Next conversion we're giving them two weekends. I guess we'll never shed the diametrically opposed ideas of testing and validation. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: COBOL / VSAM question.
In [EMAIL PROTECTED], on 04/15/2008 at 01:52 PM, Savor, Tom [EMAIL PROTECTED] said: I understand that you guys are very smart folks, but you guys LOVE to point all problems at application folks Perhaps at your shop, alhough I doubt it. its tiresome. What's tiresome is people who pretend to be mind readers and make ludicrous claims about people they know nothing about. And to your Sandbox.in our Sandboxno applications or application folks are allowed. Then application people at your shop have an excuse for not testing in your sandbox. That excuse doesn't extend to shops where they are told to test there. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, April 14, 2008 4:57 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. Or just assume '97' is a valid open (which it is) and continue. Better choice! Most shops have enough batch window problems without re-running potentially successful jobs. The reply from programming: We never needed it before! Why do we need it just because the VSAM file is OPEN on a different system? It works fine if the job is run on the same system. This breaking of the system in twain was supposed to be transparent! And, of course, any change has to be scheduled, tested, run through QA, then place into production. This will take a minimum of a month. Our scheduler fixed the problem by rescheduling the job so that it only runs when the CICS region is down. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
snipped; Our scheduler fixed the problem by rescheduling the job so that it only runs when the CICS region is down. Don't you love it when the elegant fix is the simplest one? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL Or just assume '97' is a valid open (which it is) and continue. Better choice! Most shops have enough batch window problems without re-running potentially successful jobs. The reply from programming: We never needed it before! Why do we need it just because the VSAM file is OPEN on a different system? It works fine if the job is run on the same system. This breaking of the system in twain was supposed to be transparent! Some questions don't deserve answers, because they are self-answering. -jc- -- 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
Re: COBOL / VSAM question.
The reply from programming: We never needed it before! Why do we need it just because the VSAM file is OPEN on a different system? What happens if the file is not closed 'cleanly' before the job runs? The 97 will come up then, as well. Proper practices mean that you should handle any contingency you are aware of. - Too busy driving to stop for gas! -- 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
Re: COBOL / VSAM question.
On Tue, Apr 15, 2008 at 11:54 AM, Ted MacNEIL [EMAIL PROTECTED] wrote: The reply from programming: We never needed it before! Why do we need it just because the VSAM file is OPEN on a different system? What happens if the file is not closed 'cleanly' before the job runs? The 97 will come up then, as well. Proper practices mean that you should handle any contingency you are aware of. An abend *is* a way of handling a contingency. The original programmer might have wanted to investigate why the file wasn't closed 'cleanly' before his program runs. The fact that file status '97' has now become 'normal' isn't the fault of the original programmer. -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Leahy Sent: Tuesday, April 15, 2008 11:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. On Tue, Apr 15, 2008 at 11:54 AM, Ted MacNEIL [EMAIL PROTECTED] wrote: The reply from programming: We never needed it before! Why do we need it just because the VSAM file is OPEN on a different system? What happens if the file is not closed 'cleanly' before the job runs? The 97 will come up then, as well. Proper practices mean that you should handle any contingency you are aware of. An abend *is* a way of handling a contingency. The original programmer might have wanted to investigate why the file wasn't closed 'cleanly' before his program runs. I'm the OP. If the programmer wanted it to abend under that condition, then he wouldn't have complained when it did. I don't know of any reason why a programmer would want to know that the file had not closed cleanly before this run. The very act of the OPEN resolves the problem and would not likely trigger any exception processing around here at least. The fact that file status '97' has now become 'normal' isn't the fault of the original programmer. True. It is IBM's fault. In the deep, dark past of OS/VS COBOL 2.4, the implicit verify returned a code of 00. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
The fact that file status '97' has now become 'normal' isn't the fault of the original programmer. No, it's not. But, it's somebody's fault if they don't fix it, now that they're aware of it. - Too busy driving to stop for gas! -- 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
Re: COBOL / VSAM question.
On Tue, Apr 15, 2008 at 1:34 PM, Ted MacNEIL [EMAIL PROTECTED] wrote: The fact that file status '97' has now become 'normal' isn't the fault of the original programmer. No, it's not. But, it's somebody's fault if they don't fix it, now that they're aware of it. I agree totally. I hate it when programmers incessantly whine about 'environment' changes impacting their code. Still, if the Sysplex change was described to them as 'transparent', then they should be allowed to grumble about it. For a little while anyway. :-) -- 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
Re: COBOL / VSAM question.
Don Leahy [EMAIL PROTECTED] wrote: I agree totally. I hate it when programmers incessantly whine about 'environment' changes impacting their code. Still, if the Sysplex change was described to them as 'transparent', then they should be allowed to grumble about it. For a little while anyway. :-) I hate it when systems programmers incessantly whine about transparent changes made to the system (with no prior notification) that completely blow an Application out-of-the-water.then grumble about it...for a while. Tom Savor Fidelity National Information Services 11720 Amber Park Drive Suite 500 Alpharetta, GA 30004 Phone: 678-867-8431 cell: 404-660-6898 E-Mail: [EMAIL PROTECTED] __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ -- 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
Re: COBOL / VSAM question.
And I dislike application folks who won't test in my sandbox then complain when things blow up the first few days after a roll-up. An impasse? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: COBOL / VSAM question.
And I dislike application folks who won't test in my sandbox then complain when things blow up the first few days after a roll-up. An impasse? That was the point. I understand that you guys are very smart folks, but you guys LOVE to point all problems at application folksits tiresome. And to your Sandbox.in our Sandboxno applications or application folks are allowed. It's systems folks play groundwhich is fine by me. Tom Savor Fidelity National Information Services 11720 Amber Park Drive Suite 500 Alpharetta, GA 30004 Phone: 678-867-8431 cell: 404-660-6898 E-Mail: [EMAIL PROTECTED] __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ -- 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
Re: COBOL / VSAM question.
On Tue, Apr 15, 2008 at 2:52 PM, Savor, Tom [EMAIL PROTECTED] wrote: And I dislike application folks who won't test in my sandbox then complain when things blow up the first few days after a roll-up. An impasse? That was the point. I understand that you guys are very smart folks, but you guys LOVE to point all problems at application folksits tiresome. And to your Sandbox.in our Sandboxno applications or application folks are allowed. It's systems folks play groundwhich is fine by me. Of course, without us application folks, there wouldn't be any problems at all. There would also be no point in having a computer system. :-) -- 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
Re: COBOL / VSAM question.
We never learn to get along, only point fingers. I've been on both sides of the fence... I actually encourage our users to test because if they aren't successful, neither are we. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 04/15/2008 03:23:15 PM: -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: Don Leahy [EMAIL PROTECTED] Subject: Re: COBOL / VSAM question. --- On Tue, Apr 15, 2008 at 2:52 PM, Savor, Tom [EMAIL PROTECTED] wrote: And I dislike application folks who won't test in my sandbox then complain when things blow up the first few days after a roll-up. An impasse? That was the point. I understand that you guys are very smart folks, but you guys LOVE to point all problems at application folksits tiresome. And to your Sandbox.in our Sandboxno applications or application folks are allowed. It's systems folks play groundwhich is fine by me. Of course, without us application folks, there wouldn't be any problems at all. There would also be no point in having a computer system. :-) -- 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 Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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
Re: COBOL / VSAM question.
I've been on both sides of the fence, as well. 88 GOOD-OPEN VALUE 00, 97. worked for some years. Now I'd have to throw in a few other codes if I were writing applications. And I always told people that a successful test finds a problem. If you're not finding problems, either you're not testing enough conditions or you're not thinking about the application creatively! Robert Sample IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 04/15/2008 03:27:55 PM: We never learn to get along, only point fingers. I've been on both sides of the fence... I actually encourage our users to test because if they aren't successful, neither are we. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com -- 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
Re: COBOL / VSAM question.
I'm almost sorry I brought this up. The particular programmer who complained about it always worked before consistantly uses that. If the program ever runs once to good EOJ, then the program is good and any subsequent failures are because something else changed. He even agreed that testing for 97 was a good idea, BUT still insisted that the program was OK as is because it never failed in the past. Oh, and the transparency of going to a basic sysplex from a monoplex was never said by Tech Services. The apps manager was the one who tooting that horn. I rarely say anything is transparent. Even installing a PTF can cause an outage due to (1) a bad PTF; (2) the closing of a hole; (3) the phase of the moon. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
snip- And I dislike application folks who won't test in my sandbox then complain when things blow up the first few days after a roll-up. unsnip- They're also the ones that complain the loudest when DR testing doesn't work perfectly. There's a place for people like that; it just hasn't been dug yet. -- 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
Re: COBOL / VSAM question.
--snip--- I'm almost sorry I brought this up. The particular programmer who complained about it always worked before consistantly uses that. If the program ever runs once to good EOJ, then the program is good and any subsequent failures are because something else changed. He even agreed that testing for 97 was a good idea, BUT still insisted that the program was OK as is because it never failed in the past. Oh, and the transparency of going to a basic sysplex from a monoplex was never said by Tech Services. The apps manager was the one who tooting that horn. I rarely say anything is transparent. Even installing a PTF can cause an outage due to (1) a bad PTF; (2) the closing of a hole; (3) the phase of the moon. --unsnip- At the risk of sounding unsympathetic: Those who forget their mistakes are doomed to repeat them. The quote isn't completely accurate, but the sentiment still comes through. -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, April 14, 2008 9:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL / VSAM question. I don't like what we are doing, but since when did that matter? We have a COBOL batch program which reads a VSAM file which is OPEN to cics. I am told that when we ran the program on the same z/OS image as the CICS region, that the OPEN got a FILE STATUS code of 00. We have split our single system into two images, in a basic sysplex. The program is now getting a FILE STATUS code of 97. I would have expected this even in a single system, if the file were open to another job in UPDATE mode. In any case, I am asserting that all COBOL programs should check for both 00 and 97 on OPEN and proceed in either case. It has been so very long since I have looked at this that I want to be sure that I'm not blowing smoke. The VSAM SHAREOPTIONS are 2,3. SNIP An 88 on the file status label to handle 00 97 is what we did for shops that migrated from VSE to MVS (or z/OS). That a VERIFY was done as part of OPEN is not a problem in 99.99% of the cases as far as we could ever see. So, no, I don't think you are blowing smoke. If the share options caused the OPEN to fail, that would be an entirely different animal. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- 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
Re: COBOL / VSAM question.
On 14 Apr 2008 07:56:24 -0700, in bit.listserv.ibm-main you wrote: I don't like what we are doing, but since when did that matter? We have a COBOL batch program which reads a VSAM file which is OPEN to cics. I am told that when we ran the program on the same z/OS image as the CICS region, that the OPEN got a FILE STATUS code of 00. We have split our single system into two images, in a basic sysplex. The program is now getting a FILE STATUS code of 97. I would have expected this even in a single system, if the file were open to another job in UPDATE mode. In any case, I am asserting that all COBOL programs should check for both 00 and 97 on OPEN and proceed in either case. It has been so very long since I have looked at this that I want to be sure that I'm not blowing smoke. The VSAM SHAREOPTIONS are 2,3. Very definitely, you should at least be checking for 00 and 97. Depending on the files and any recent compiler changes, other conditionally successful opens should be checked for. Clark Morris, COBOL programmer analyst who has done systems programming. -- 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
Re: COBOL / VSAM question.
On 14 Apr 2008 08:14:24 -0700, [EMAIL PROTECTED] (Clark Morris) wrote: Very definitely, you should at least be checking for 00 and 97. Depending on the files and any recent compiler changes, other conditionally successful opens should be checked for. We had a purchased system that included a called program to handle KSDS input.I have no idea why they did that, maybe because the concepts of OO were being developed and they wanted on the bandwagon. Well, it accepted parms to open, read, or close - and it passed a return of 7 if the VSAM return code wasn't 00 on the open command. This program was called by every program that read a KSDS file (which is now down to zero programs). Every once in a while, it would abort and our procedure would be to restart.That was because it didn't check for 97. In a CoBOL shop, we had standards about having everything that used that program being extensively tested by users before our fixes went into production - so it just wasn't cost effective to fix this called program. This program had all of the problems of OO, but none of the advantages. -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, April 14, 2008 10:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL / VSAM question. I don't like what we are doing, but since when did that matter? We have a COBOL batch program which reads a VSAM file which is OPEN to cics. I am told that when we ran the program on the same z/OS image as the CICS region, that the OPEN got a FILE STATUS code of 00. We have split our single system into two images, in a basic sysplex. The program is now getting a FILE STATUS code of 97. I would have expected this even in a single system, if the file were open to another job in UPDATE mode. In any case, I am asserting that all COBOL programs should check for both 00 and 97 on OPEN and proceed in either case. It has been so very long since I have looked at this that I want to be sure that I'm not blowing smoke. The VSAM SHAREOPTIONS are 2,3. No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Farley, Peter x23353 Sent: Monday, April 14, 2008 11:33 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. [snip] No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. HTH Peter I could have sworn that doing it that was was our standard. I just double checked and this particular program was last compiled on 04Aug05 in Enterprise COBOL 3.3.1. It definately should have the check for 00 and 97. Oh, well, not my problem. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
On Mon, 14 Apr 2008 12:33:16 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, April 14, 2008 11:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. On Mon, 14 Apr 2008 12:33:16 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, April 14, 2008 11:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. On Mon, 14 Apr 2008 12:33:16 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: No smoke involved. We have that here in many different programs, ALWAYS check for BOTH '00' and '97'. Or better yet (as someone else mentioned) an 88 level on the FILE-STATUS identifier with both values. And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. I don't believe sysplex has anything to do with it, but like I said, it's been many years -jc- -- 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
Re: COBOL / VSAM question.
On Mon, 14 Apr 2008 12:14:03 -0500, McKown, John [EMAIL PROTECTED] wrote: I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? Of course. Always guilty until proven innocent, especially after some kind if install or infrastructure change. Last year when I upgraded one of our small monoplex LPARs from z/OS 1.6 to z/OS 1.8 the *exact* same thing happened (old program, but never changed) and the programmer wanted to blame the z/OS 1.8 upgrade. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: COBOL / VSAM question.
On 14 Apr 2008 11:14:24 -0700, [EMAIL PROTECTED] (Chase, John) wrote: It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. Or just assume '97' is a valid open (which it is) and continue. -- 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
Re: COBOL / VSAM question.
On Mon, 14 Apr 2008 13:13:58 -0500, Chase, John [EMAIL PROTECTED] wrote: And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. I don't believe sysplex has anything to do with it, but like I said, it's been many years You're right. There would be no reason to run the manual VERIFY after the file status 97. Just re-run the program and it will magically disappear. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: COBOL / VSAM question.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, April 14, 2008 1:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL / VSAM question. On Mon, 14 Apr 2008 13:13:58 -0500, Chase, John [EMAIL PROTECTED] wrote: And sysplex has nothing to do with this really. It thought this needed to be done since DF/EF in the 80's. I guess if you've run into previous file status 97s, someone must have run a VERIFY. Mark -- I have NO idea about the VERIFY. And, of course, since the last thing that we did was convert to a sysplex, the first question out of the programmer's mouth was: It has always worked before. Is the sysplex conversion the reason that it all of a sudden failed? It's been many years, but ISTR (vaguely) that the 97 occurs at OPEN time if an _implicit_ VERIFY was done (i.e., OPEN discovered that the previous opener of the dataset did not close it cleanly, so it invoked VERIFY under the covers). The fix was (is?) to run an _explicit_ IDCAMS VERIFY against the dataset. I don't believe sysplex has anything to do with it, but like I said, it's been many years You're right. There would be no reason to run the manual VERIFY after the file status 97. Just re-run the program and it will magically disappear. Mark -- Well, given that the file actually is OPEN to CICS at the time, I don't think that just rerunning the job would fix the 97. Or would it? I have come to __HATE__ VSAM here. Especially here, where we're too elided cheap to get a database on z/OS. Better 1000s of MS-SQL squatty boxes than one enterprise class server! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
I have an interesting observation. I ran an IDCAMS jobs to print 1 record from a VSAM file which I know is OPEN to CICS. If I run it on the same LPAR as the CICS region, I get NO messages, just the output. When I run it on a different LPAR, then I get the messages: IEC161I 056-084,TSH009JX,STEP001,BPIFTX,,,MSHPV.NASE.CICSPIF, 170 IEC161I MSHPV.NASE.CICSPIF.DATA,CATALOG.ICF.VPRDH01 IEC161I 056-084,TSH009JX,STEP001,BPIFTX,,,MSHPV.NASE.CICSPIF, 171 IEC161I MSHPV.NASE.CICSPIF.INDEX,CATALOG.ICF.VPRDH01 IEC161I 062-086,TSH009JX,STEP001,BPIFTX,,,MSHPV.NASE.CICSPIF, 172 IEC161I MSHPV.NASE.CICSPIF.DATA,CATALOG.ICF.VPRDH01 as well as the IDCAMS output: IDC3300I ERROR OPENING MSHPV.NASE.CICSPIF IDC3351I ** VSAM OPEN RETURN CODE IS 118 So, on my z/OS 1.8 system, I get different actions depending on which LPAR I run on. Should I be propagating something more across the GRSPlex? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: COBOL / VSAM question.
Or just assume '97' is a valid open (which it is) and continue. Better choice! Most shops have enough batch window problems without re-running potentially successful jobs. - Too busy driving to stop for gas! -- 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
