Re: CLOSING of files OPEN at program exit. Re: Help on SC03 abend
In [EMAIL PROTECTED], on 06/23/2005 at 11:04 AM, Rolf Ernst [EMAIL PROTECTED] said: the question is to which lengths COBOL goes to determine which files were opened. No, the question is to what lengths a program should go in an attempt to work around a broken subroutine; the issue would be the same if the caller were written in another language. Since you indicated the files were opened (and not closed) by a BAL subroutine, No he didn't. the COBOL code may not even be aware of it. Nor should it be. It does take a bit of poking around to find the DECBs anyhow. He doesn't need the (nonexistent for QSAm and VSAM) DECB's; he needs the ACB's and DCB's, which are presumably already gone. However, since you indicate that you are dealing with VSAM files - are the ACBs that the subroutine used around at all? I doubt that he would have gotten the C03 if they were. -- 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: CLOSING of files OPEN at program exit. Re: Help on SC03 abend
... Since you indicated the files were opened (and not closed) by a BAL subroutine, the COBOL code may not even be aware of it. ... My Mother used to say: You use it; you clean it. Put it back where you got it from. Always wear clean underwear, in case you get hit by a bus. The point is: A programme, sub-routine, etc. that opens a file should (must) close it. You can't leave artifacts around for callers to trip over. (At least, that's what I was taught at the UoW in the 1970's) -teD (The secret to success is sincerity. If you can fake that, you've got it made!) -- 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: CLOSING of files OPEN at program exit. Re: Help on SC03 abend
The origional statement was that a different program calling the subroutine didn't have the abend. If the different program was also ASM and didn't clean up modules loaded or was linked as a static call, then the storage would still be available for the system to close the ACB. sort of an example of how 2 wrongs can run correctly. Mike On 6/22/05, Ted MacNEIL [EMAIL PROTECTED] wrote: ... Since you indicated the files were opened (and not closed) by a BAL subroutine, the COBOL code may not even be aware of it. ... My Mother used to say: You use it; you clean it. Put it back where you got it from. Always wear clean underwear, in case you get hit by a bus. The point is: A programme, sub-routine, etc. that opens a file should (must) close it. You can't leave artifacts around for callers to trip over. (At least, that's what I was taught at the UoW in the 1970's) -teD (The secret to success is sincerity. If you can fake that, you've got it made!) -- 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 -- Mike -- 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: CLOSING of files OPEN at program exit. Re: Help on SC03 abend
On 23 Jun 2005 09:04:13 -0700, in bit.listserv.ibm-main you wrote: Clark, the question is to which lengths COBOL goes to determine which files were opened. Since you indicated the files were opened (and not closed) by a BAL subroutine, the COBOL code may not even be aware of it. It does take a bit of poking around to find the DECBs anyhow. However, since you indicate that you are dealing with VSAM files - are the ACBs that the subroutine used around at all? Has this storage not been freed? As long as you have no activity you would not find out until it's closing time, whether COBOL intends to clean up or someone else. Obviously, I have been less than clear. I was referring to the requirements for COBOL to CLOSE any files OPENed by a COBOL program. This would not apply to the files in the original posting by someone else since the problem was occurring with an Assembler subroutine. It becomes very murky when we are dealing with a DB2 COBOL program since it is running under the batch TMP and probably a DB2 service. The 85 COBOL standard recognizes only STOP RUN and EXIT PROGRAM so the issue of GOBACK confuses the issue further. The 2002 standard recognizes GOBACK so I would assume that the requirement for termination of the RUN unit to close the files would still apply. I also suspect but haven't researched the whether a COBOL calling program issuing a CANCEL for a CALLed program must implicitly cause the CLOSING of any files OPENed by the CALLed program. CANCEL in COBOL terms mean to DELETE the program from the calling stack and free the memory and does not imply ABEND. Clark Morris wrote: On 22 Jun 2005 15:56:11 -0700, in bit.listserv.ibm-main you wrote: If my old addled brain is thinking correctly, I believe over 10 years ago IBM decided to no longer be nice to programs and require that all programs close any files they open. And if they did not close them, the system would then issue a SC03 abend. Probably true for Assembler. The 85 COBOL standard requires COBOL to clean up after itself and close all OPEN files on a STOP RUN. By implication GOBACK from a main program probably also does the same thing but I don't have a compiler and system to test it. Still it is bad practice not to close all files. Of course I am wondering what the need for an assembler routine is in the case that prompted the original posting. snip -- 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
