Re: C03 abend when omitting CEE.SCEERUN from JCL
I have had the same experience a couple of time. The first was an application I inherited because I worked in assembly. It was in COBOL and assembly. When I made the change to the assembly program and its COBOL caller, I introduced the fourth level of COBOL. The maintenance structure was setup to compile and link each module to an intermediate library without NCAL. The final load module was built by linking these together. The new version split a runtime module into 2 versions. One for display and one for display upon console (which also handled display). The final module contained both copies, each having its own SYSOUT DCB. Results were a consistent abend dealing with the SYSOUT DCBs. The second was a COTS product but the root cause was the same. Solution - Compile all of the COBOL using the same compiler/assembler. Link each module to a common intermediate library using NCAL. Perform a final link to put it all together. Both problems were gone. As others have pointed out, if you own the DCB you are responsible for closing it. Dennis Roach United Space Alliance 600 Gemini Avenue Mail Code USH-4A3L Houston, Texas 77058 Voice: (281) 282-2975 Page: (713) 736-8275 Fax: (281) 282-3583 E-Mail: [EMAIL PROTECTED] All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John McKown Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL Actually call flow is like below: Enterprise Cobol - Assembler V2 (566896201) - High Level Assembler (569623400) - OS/VS Cobol (5740CB103) - Enterprise Cobol (5655G5300) There are about 20 different program calls which are Assembler V2 and HLASM. Assembler programs were last compiled at 1992(as they are part of a product) and i think they are not LE-conforming. Thanks and regards. Mürsel Taþgýn I vaguely remember a similar problem in the past. As I recall, we never did get a resolution. The problem was that the OS/VS COBOL program (5740CB103) did not close its files. When it did the GOBACK, the memory for the DCB was free'd and then later reused. This caused the SC03 like you are getting. As I said, we never did resolve this. IIRC, we had to recompile the OS/VS COBOL to the current COBOL. -- John -- 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: C03 abend when omitting CEE.SCEERUN from JCL
Hi Bill, Actually call flow is like below: Enterprise Cobol - Assembler V2 (566896201) - High Level Assembler (569623400) - OS/VS Cobol (5740CB103) - Enterprise Cobol (5655G5300) There are about 20 different program calls which are Assembler V2 and HLASM. Assembler programs were last compiled at 1992(as they are part of a product) and i think they are not LE-conforming. Thanks and regards. Mürsel Taşgın BT Sistem Yönetimi Yönetici Yardımcısı Akbank Genel Müdürlüğü Sabancı Center 34330, İstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Thursday, October 23, 2008 7:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: C03 abend when omitting CEE.SCEERUN from JCL previous notes snipped With all the posts, I don't know if anyone has actually posted the references for the full discussion on this topic in existing Migration Guides. If you previously used the OS/VS COBOL run-time library, please read: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/3.2.4 If you previously used the VS COBOL II run-time library, please read http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/3.3.4 As I *think* that previous notes from the OP indicated that the application had the following flow to it: Enterprise COBOL - Assembler - OS/VS COBOL and I still haven't heard whether the Assembler is LE enabled or not and exactly HOW the Assembler calls (loads? whatever?) the OS/VS COBOL program, then you should also read http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/APPENDIX1.4.2 -- 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 Bu e-posta ve muhtemel eklerinde verilen bilgiler kişiye özel ve gizli olup, yalnızca mesajda belirlenen alıcı ile ilgilidir.Size yanlışlıkla ulaşmışsa lütfen göndericiye bilgi veriniz, mesajı siliniz ve içeriğini başka bir kişiye açıklamayınız, herhangi bir ortama kopyalamayınız. Bu mesaj aksi sözleşme ile belirtilmedikçe herhangi bir finansal işlem teklifi, alımı, satımı veya herhangi bir havalenin teyidi gibi bankacılık işlemi yapılması amacını taşımamaktadır.Verilen tüm bilgilerin doğruluğu ve bütünlüğünün garantisi verilmemekte olup, önceden bildirilmeksizin değiştirilebilecektir.Bu mesajın içeriği Bankamızın resmi görüşlerini yansıtmayabileceğinden Akbank T.A.Ş. hiçbir hukuki sorumluluğu kabul etmez. -- 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: C03 abend when omitting CEE.SCEERUN from JCL
Mürsel Ta#351;g#305;n wrote: Hi Bill, Actually call flow is like below: Enterprise Cobol - Assembler V2 (566896201) - High Level Assembler (569623400) - OS/VS Cobol (5740CB103) - Enterprise Cobol (5655G5300) There are about 20 different program calls which are Assembler V2 and HLASM. Assembler programs were last compiled at 1992(as they are part of a product) and i think they are not LE-conforming. Thanks and regards. Mürsel Taşgın BT Sistem Yönetimi Yönetici Yardımcısı Akbank Genel Müdürlüğü Sabancı Center 34330, İstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] Mürsel, Do you have the source for all the programs? Why not make everything LE-conforming? If you're not sure how to do that, I'd be happy to come to Istanbul to teach a couple of classes. Maybe Using LE Services in LE (most recently taught in Amsterdam last month); see http://www.trainersfriend.com/Language_Environment_courses/m512descr.htm Maybe Secrets of Inter-Language Communication in z/OS; see http://www.trainersfriend.com/Language_Environment_courses/m520descr.htm Maybe Enterprise COBOL Update I: Essentials; see http://www.trainersfriend.com/COBOL_Courses/d704descr.htm Maybe z/OS Assembler for Applications Programmers; see http://www.trainersfriend.com/Assembler_%20courses/C500descrpt.htm Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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: C03 abend when omitting CEE.SCEERUN from JCL
On Thu, 23 Oct 2008 16:20:11 +0300, Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote: Hi Bill, Actually call flow is like below: Enterprise Cobol - Assembler V2 (566896201) - High Level Assembler (569623400) - OS/VS Cobol (5740CB103) - Enterprise Cobol (5655G5300) There are about 20 different program calls which are Assembler V2 and HLASM. Assembler programs were last compiled at 1992(as they are part of a product) and i think they are not LE-conforming. Thanks and regards. Mürsel Taþgýn I vaguely remember a similar problem in the past. As I recall, we never did get a resolution. The problem was that the OS/VS COBOL program (5740CB103) did not close its files. When it did the GOBACK, the memory for the DCB was free'd and then later reused. This caused the SC03 like you are getting. As I said, we never did resolve this. IIRC, we had to recompile the OS/VS COBOL to the current COBOL. -- John -- 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: C03 abend when omitting CEE.SCEERUN from JCL
After talking to another co-worker, 2 more things come to mind: 1. If the OS/VS COBOL program is the one that opened the file and did not close it, the COBOL library routines will NOT automatically close the file when the application terminates. The COBOL library routines will only automatically close any open files that were opened (but not closed) in VS COBOL II and later programs. 2. If you have any of the older COBOL library data sets (e.g., OS/VS COBOL or VS COBOL II) ahead of SCEERUN in the LINKLST concatenation, this will also cause problems. You will have to remove the older COBOL library data sets from LINKLST. Check your LINKLST for duplicate modules beginning with ILBO or IGZ. For example, scan for ILBONTR and IGZEINI. If they appear in more than one data set, you will need to remove the older library data sets. In any case, you still should correct the original problem by closing the file that was left open. Rick Arellanes IBM COBOL Development -Original Message- On Tue, 21 Oct 2008 09:29:05 +0300, Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote: Hi Bill, 1 VS Cobol Program is actually OS/VS Cobol (amblist shows 5740CB103 as compiler version). Program compilation details are like: AMODE(24),RMODE(24), NOT-RENT, RES Thanks and regards. Mürsel Taþgýn BT Sistem Yönetimi Yönetici Yardýmcýsý Akbank Genel Müdürlüðü Sabancý Center 34330, Ýstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Monday, October 20, 2008 9:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: C03 abend when omitting CEE.SCEERUN from JCL When you say 1 VS COBOL program Do you mean VS COBOL II or OS/VS COBOL? If it is OS/VS COBOL, then this may WELL be part of the problem. However, for either VS COBOL II or OS/VS COBOL, was the program compiled with RES or NORES? (You can use COBANAL or Edge Portfolio to find this out). If you have ANY NORES program mixed in with an Enterprise COBOL application, you are into the wonderful world of MIXRES and things can get VERY funny. I can (relatively) easily imagine that this may well lead to problems with different locations for SCEERUN. If your VS COBOL (OS/VS COBOL or VS COBOL II) program is compiled with NORES, then I suggest recompiling with RES and seeing if this fixes the problem. Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Tasgin BT Sistem Yönetimi Yönetici Yardimcisi Akbank Genel Müdürlügü Sabanci Center 34330, Istanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -- 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: C03 abend when omitting CEE.SCEERUN from JCL
Simple answer. LE used to clean up after sloppy Cobol programs which failed to close all opened files... without making a fuss. VSCobol or very latest Cobol, no difference, any and all Cobol programs which end and leave files open. At some point, we hit it at OS390 2.10, LE stopped doing this. It started issuing C03 abends. In batch, not really a problem because the abend happens AFTER the job completes. However, your scheduling program will flag the abend, and eventually the programs must be fixed. -- 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: C03 abend when omitting CEE.SCEERUN from JCL
On Wed, 22 Oct 2008 09:53:11 -0700, John Mattson wrote: Simple answer. LE used to clean up after sloppy Cobol programs which failed to close all opened files... without making a fuss. VSCobol or very latest Cobol, no difference, any and all Cobol programs which end and leave files open. At some point, we hit it at OS390 2.10, LE stopped doing this. It started issuing C03 abends. Too simple. LE doesn't issue the C03 abend. It is issued by MVS when the task terminates. Normally, RTM will try to close any data set that is left open when a task ends. If the DCB can not be found, RTM is not able to close it. This is not because LE stopped doing this. It is because some other change caused the DCB to be released, freed or overlaid. Whatever is causing this to happen could cause other undesirable results. -- Tom Marchant -- 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: C03 abend when omitting CEE.SCEERUN from JCL
Hi Bill, 1 VS Cobol Program is actually OS/VS Cobol (amblist shows 5740CB103 as compiler version). Program compilation details are like: AMODE(24),RMODE(24), NOT-RENT, RES Thanks and regards. Mürsel Taşgın BT Sistem Yönetimi Yönetici Yardımcısı Akbank Genel Müdürlüğü Sabancı Center 34330, İstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Monday, October 20, 2008 9:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: C03 abend when omitting CEE.SCEERUN from JCL When you say 1 VS COBOL program Do you mean VS COBOL II or OS/VS COBOL? If it is OS/VS COBOL, then this may WELL be part of the problem. However, for either VS COBOL II or OS/VS COBOL, was the program compiled with RES or NORES? (You can use COBANAL or Edge Portfolio to find this out). If you have ANY NORES program mixed in with an Enterprise COBOL application, you are into the wonderful world of MIXRES and things can get VERY funny. I can (relatively) easily imagine that this may well lead to problems with different locations for SCEERUN. If your VS COBOL (OS/VS COBOL or VS COBOL II) program is compiled with NORES, then I suggest recompiling with RES and seeing if this fixes the problem. Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Tasgin BT Sistem Yönetimi Yönetici Yardimcisi Akbank Genel Müdürlügü Sabanci Center 34330, Istanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Friday, October 17, 2008 7:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL On Fri, 17 Oct 2008 11:04:51 -0500, Chase, John [EMAIL PROTECTED] wrote: When we remove CEE.SCEERUN joblib statement from the JCL, the job abends with C03: IKJ56641I SYSTEM ABEND CODE C03 REASON CODE 0004 Note the message ID: It's a TSO message. Leads me to believe more needs to be known about just how the program is invoked. Seems that it's not via normal batch JCL; i.e., it's not via //STEPNAME EXEC PGM=COBOLPGM -jc- Perhaps its a DB2 COBOL program. But that shouldn't matter. It should run without the JOBLIB all things being equal. 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 Bu e-posta ve muhtemel eklerinde verilen bilgiler kisiye özel ve gizli olup, yalnizca mesajda belirlenen alici ile ilgilidir.Size yanlislikla ulasmissa lütfen göndericiye bilgi veriniz, mesaji siliniz ve içerigini baska bir kisiye açiklamayiniz, herhangi bir ortama kopyalamayiniz. Bu mesaj aksi sözlesme ile belirtilmedikçe herhangi bir finansal islem teklifi, alimi, satimi veya herhangi bir havalenin teyidi gibi bankacilik islemi yapilmasi amacini tasimamaktadir.Verilen tüm bilgilerin dogrulugu ve bütünlügünün garantisi verilmemekte olup, önceden bildirilmeksizin degistirilebilecektir.Bu mesajin içerigi Bankamizin resmi görüslerini yansitmayabileceginden Akbank T.A.S. hiçbir hukuki sorumlulugu kabul etmez. -- 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 -- 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 Bu e-posta ve muhtemel eklerinde verilen bilgiler kişiye özel ve gizli olup, yalnızca mesajda belirlenen alıcı ile ilgilidir.Size yanlışlıkla ulaşmışsa lütfen göndericiye bilgi veriniz, mesajı siliniz ve içeriğini başka bir kişiye açıklamayınız, herhangi bir ortama kopyalamayınız. Bu mesaj aksi sözleşme ile belirtilmedikçe herhangi bir finansal işlem teklifi, alımı
Re: C03 abend when omitting CEE.SCEERUN from JCL
Hi Rick, Thanks for this valuable information. Regards. Mürsel Taşgın BT Sistem Yönetimi Yönetici Yardımcısı Akbank Genel Müdürlüğü Sabancı Center 34330, İstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Arellanes Sent: Monday, October 20, 2008 8:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL In the case of normal COBOL termination (e.g., GOBACK from main, STOP RUN, etc.) or abnormal COBOL termination (e.g., abend with TRAP(ON) in effect), COBOL will attempt to close any files that were left open and the C03 abend will be avoided. However, if an assembler program dynamically loads a COBOL program that opened a file and did not close it and then the assembler program deletes the COBOL program, this is where a C03 abend can occur. The COBOL Migration Guide says that unpredictable results may occur in certain cases if a COBOL program was SVC LOADed and then subsequently SVC DELETEd (the C03 abend is one of these unpredictable results). The COBOL library does not make any distinction as to where the library routines are loaded. However, I have seen cases before that when modules are loaded from different locations (STEPLIB, JOBLIB, LINKLSK, LPA, etc.), they may get loaded in different areas of storage. This would cause a DCB to be getmained at a different address. Then, when the COBOL program is deleted and if the DCB also gets freed (but the storage is not reused), the task termination code could still find the DCB in storage and can close the file successfully. However, if the DCB stoage got reused after the DCB was freed, task termination would no longer find the DCB in storage and would issue the C03 abend. So, seeing the C03 abend when putting the SCEERUN library in LPA or LINKLST vs. STEPLIB or JOBLIB may not actually be the cause of the problem, but rather may have just exposed the problem due to the way that storage was allocated and freed. It could be that your application was just lucky in not getting the abend until now when the storage usage was different. The correct solution is to always close your files before ending the application. It that is not possible for some reason, then do not delete the COBOL program that was SVC loaded by an assembler program until after the COBOL environment has terminated. Rick Arellanes IBM COBOL Development -Original Message- On Mon, 20 Oct 2008 10:00:50 +0300, Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote: Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Taþgýn BT Sistem Yönetimi Yönetici Yardýmcýsý Akbank Genel Müdürlüðü Sabancý Center 34330, Ýstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -- 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 Bu e-posta ve muhtemel eklerinde verilen bilgiler kişiye özel ve gizli olup, yalnızca mesajda belirlenen alıcı ile ilgilidir.Size yanlışlıkla ulaşmışsa lütfen göndericiye bilgi veriniz, mesajı siliniz ve içeriğini başka bir kişiye açıklamayınız, herhangi bir ortama kopyalamayınız. Bu mesaj aksi sözleşme ile belirtilmedikçe herhangi bir finansal işlem teklifi, alımı, satımı veya herhangi bir havalenin teyidi gibi bankacılık işlemi yapılması amacını taşımamaktadır.Verilen tüm bilgilerin doğruluğu ve bütünlüğünün garantisi verilmemekte olup, önceden bildirilmeksizin değiştirilebilecektir.Bu mesajın içeriği Bankamızın resmi görüşlerini yansıtmayabileceğinden Akbank T.A.Ş. hiçbir hukuki sorumluluğu kabul etmez. -- 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: C03 abend when omitting CEE.SCEERUN from JCL
Hi John, Previously we searched duplicate module names manually, but your suggestion is much quicker. But we again couldn't find any duplicate module names for the CEE.SCEERUN dataset and other lnklst datasets. Thanks and regards. Mürsel Taşgın BT Sistem Yönetimi Yönetici Yardımcısı Akbank Genel Müdürlüğü Sabancı Center 34330, İstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John McKown Sent: Friday, October 17, 2008 6:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL On Fri, 17 Oct 2008 10:20:44 -0500, Roach, Dennis [EMAIL PROTECTED] wrote: The cause could be ANY duplicate module in SCEERUN that is in LPA or ahead of SCEERUN in linklist that gets invoked, directly or indirectly, by the executing program. And ... MXI LPD * displays what's in the current, in VStorage, active LPA... Further to that thought, you should also check for MLPAs or dynamic LPA updates (via SETPROG). Bill I find duplicates using DDLIST in ISPF. On any command line, enter DDLIST. Then enter LINKLIST to add the current LNKLST to the display. Then enter ONLY LINKLIST to exclude all other allocations. Then enter DUPLICATES to see what is duplicated and where the duplicates exist. -- John -- 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 Bu e-posta ve muhtemel eklerinde verilen bilgiler kişiye özel ve gizli olup, yalnızca mesajda belirlenen alıcı ile ilgilidir.Size yanlışlıkla ulaşmışsa lütfen göndericiye bilgi veriniz, mesajı siliniz ve içeriğini başka bir kişiye açıklamayınız, herhangi bir ortama kopyalamayınız. Bu mesaj aksi sözleşme ile belirtilmedikçe herhangi bir finansal işlem teklifi, alımı, satımı veya herhangi bir havalenin teyidi gibi bankacılık işlemi yapılması amacını taşımamaktadır.Verilen tüm bilgilerin doğruluğu ve bütünlüğünün garantisi verilmemekte olup, önceden bildirilmeksizin değiştirilebilecektir.Bu mesajın içeriği Bankamızın resmi görüşlerini yansıtmayabileceğinden Akbank T.A.Ş. hiçbir hukuki sorumluluğu kabul etmez. -- 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: C03 abend when omitting CEE.SCEERUN from JCL
Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Taşgın BT Sistem Yönetimi Yönetici Yardımcısı Akbank Genel Müdürlüğü Sabancı Center 34330, İstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Friday, October 17, 2008 7:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL On Fri, 17 Oct 2008 11:04:51 -0500, Chase, John [EMAIL PROTECTED] wrote: When we remove CEE.SCEERUN joblib statement from the JCL, the job abends with C03: IKJ56641I SYSTEM ABEND CODE C03 REASON CODE 0004 Note the message ID: It's a TSO message. Leads me to believe more needs to be known about just how the program is invoked. Seems that it's not via normal batch JCL; i.e., it's not via //STEPNAME EXEC PGM=COBOLPGM -jc- Perhaps its a DB2 COBOL program. But that shouldn't matter. It should run without the JOBLIB all things being equal. 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 Bu e-posta ve muhtemel eklerinde verilen bilgiler kişiye özel ve gizli olup, yalnızca mesajda belirlenen alıcı ile ilgilidir.Size yanlışlıkla ulaşmışsa lütfen göndericiye bilgi veriniz, mesajı siliniz ve içeriğini başka bir kişiye açıklamayınız, herhangi bir ortama kopyalamayınız. Bu mesaj aksi sözleşme ile belirtilmedikçe herhangi bir finansal işlem teklifi, alımı, satımı veya herhangi bir havalenin teyidi gibi bankacılık işlemi yapılması amacını taşımamaktadır.Verilen tüm bilgilerin doğruluğu ve bütünlüğünün garantisi verilmemekte olup, önceden bildirilmeksizin değiştirilebilecektir.Bu mesajın içeriği Bankamızın resmi görüşlerini yansıtmayabileceğinden Akbank T.A.Ş. hiçbir hukuki sorumluluğu kabul etmez. -- 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: C03 abend when omitting CEE.SCEERUN from JCL
In the case of normal COBOL termination (e.g., GOBACK from main, STOP RUN, etc.) or abnormal COBOL termination (e.g., abend with TRAP(ON) in effect), COBOL will attempt to close any files that were left open and the C03 abend will be avoided. However, if an assembler program dynamically loads a COBOL program that opened a file and did not close it and then the assembler program deletes the COBOL program, this is where a C03 abend can occur. The COBOL Migration Guide says that unpredictable results may occur in certain cases if a COBOL program was SVC LOADed and then subsequently SVC DELETEd (the C03 abend is one of these unpredictable results). The COBOL library does not make any distinction as to where the library routines are loaded. However, I have seen cases before that when modules are loaded from different locations (STEPLIB, JOBLIB, LINKLSK, LPA, etc.), they may get loaded in different areas of storage. This would cause a DCB to be getmained at a different address. Then, when the COBOL program is deleted and if the DCB also gets freed (but the storage is not reused), the task termination code could still find the DCB in storage and can close the file successfully. However, if the DCB stoage got reused after the DCB was freed, task termination would no longer find the DCB in storage and would issue the C03 abend. So, seeing the C03 abend when putting the SCEERUN library in LPA or LINKLST vs. STEPLIB or JOBLIB may not actually be the cause of the problem, but rather may have just exposed the problem due to the way that storage was allocated and freed. It could be that your application was just lucky in not getting the abend until now when the storage usage was different. The correct solution is to always close your files before ending the application. It that is not possible for some reason, then do not delete the COBOL program that was SVC loaded by an assembler program until after the COBOL environment has terminated. Rick Arellanes IBM COBOL Development -Original Message- On Mon, 20 Oct 2008 10:00:50 +0300, Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote: Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Taþgýn BT Sistem Yönetimi Yönetici Yardýmcýsý Akbank Genel Müdürlüðü Sabancý Center 34330, Ýstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -- 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: C03 abend when omitting CEE.SCEERUN from JCL
A guess: You may have something in front of SCEERUN on your either LNKLST or LPA that overrides SCEERUN... -- 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: C03 abend when omitting CEE.SCEERUN from JCL
Further to that thought, you should also check for MLPAs or dynamic LPA updates (via SETPROG). Bill On Fri, 17 Oct 2008 10:26:31 -0400, Jakubek, Jan [EMAIL PROTECTED] wrote: A guess: You may have something in front of SCEERUN on your either LNKLST or LPA that overrides SCEERUN... -- 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: C03 abend when omitting CEE.SCEERUN from JCL
And ... MXI LPD * displays what's in the current, in VStorage, active LPA... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Big Iron Sent: October 17, 2008 10:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C03 abend when omitting CEE.SCEERUN from JCL Further to that thought, you should also check for MLPAs or dynamic LPA updates (via SETPROG). Bill On Fri, 17 Oct 2008 10:26:31 -0400, Jakubek, Jan [EMAIL PROTECTED] wrote: A guess: You may have something in front of SCEERUN on your either LNKLST or LPA that overrides SCEERUN... -- 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 -- 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: C03 abend when omitting CEE.SCEERUN from JCL
The cause could be ANY duplicate module in SCEERUN that is in LPA or ahead of SCEERUN in linklist that gets invoked, directly or indirectly, by the executing program. And ... MXI LPD * displays what's in the current, in VStorage, active LPA... Further to that thought, you should also check for MLPAs or dynamic LPA updates (via SETPROG). Bill On Fri, 17 Oct 2008 10:26:31 -0400, Jakubek, Jan [EMAIL PROTECTED] wrote: A guess: You may have something in front of SCEERUN on your either LNKLST or LPA that overrides SCEERUN... -- 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: C03 abend when omitting CEE.SCEERUN from JCL
On Fri, 17 Oct 2008 10:20:44 -0500, Roach, Dennis [EMAIL PROTECTED] wrote: The cause could be ANY duplicate module in SCEERUN that is in LPA or ahead of SCEERUN in linklist that gets invoked, directly or indirectly, by the executing program. And ... MXI LPD * displays what's in the current, in VStorage, active LPA... Further to that thought, you should also check for MLPAs or dynamic LPA updates (via SETPROG). Bill I find duplicates using DDLIST in ISPF. On any command line, enter DDLIST. Then enter LINKLIST to add the current LNKLST to the display. Then enter ONLY LINKLIST to exclude all other allocations. Then enter DUPLICATES to see what is duplicated and where the duplicates exist. -- John -- 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: C03 abend when omitting CEE.SCEERUN from JCL
On Fri, 17 Oct 2008 10:47:49 -0500, John McKown wrote: I find duplicates using DDLIST in ISPF. On any command line, enter DDLIST. Then enter LINKLIST to add the current LNKLST to the display. Then enter ONLY LINKLIST to exclude all other allocations. Then enter DUPLICATES to see what is duplicated and where the duplicates exist. Cool! Thanks John. BTW, either LINKLIST or LPa will add both LPA and the current LNKLST. -- Tom Marchant -- 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: C03 abend when omitting CEE.SCEERUN from JCL
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown On Fri, 17 Oct 2008 10:20:44 -0500, Roach, Dennis wrote: The cause could be ANY duplicate module in SCEERUN that is in LPA or ahead of SCEERUN in linklist that gets invoked, directly or indirectly, by the executing program. I find duplicates using DDLIST in ISPF. On any command line, enter DDLIST. Then enter LINKLIST to add the current LNKLST to the display. Then enter ONLY LINKLIST to exclude all other allocations. Then enter DUPLICATES to see what is duplicated and where the duplicates exist. I wonder if everybody might be barking up the wrong tree? The original complaint was this: When we remove CEE.SCEERUN joblib statement from the JCL, the job abends with C03: IKJ56641I SYSTEM ABEND CODE C03 REASON CODE 0004 Note the message ID: It's a TSO message. Leads me to believe more needs to be known about just how the program is invoked. Seems that it's not via normal batch JCL; i.e., it's not via //STEPNAME EXEC PGM=COBOLPGM -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: C03 abend when omitting CEE.SCEERUN from JCL
On Fri, 17 Oct 2008 10:47:49 -0500, John McKown [EMAIL PROTECTED] wrote: I find duplicates using DDLIST in ISPF. On any command line, enter DDLIST. Then enter LINKLIST to add the current LNKLST to the display. Then enter ONLY LINKLIST to exclude all other allocations. Then enter DUPLICATES to see what is duplicated and where the duplicates exist. I didn't spell out how to do it, but this is what I suggested earlier. The OP said they did it and found no duplicates... but perhaps they didn't use the duplicate function and did it manually. 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: C03 abend when omitting CEE.SCEERUN from JCL
On Fri, 17 Oct 2008 11:04:51 -0500, Chase, John [EMAIL PROTECTED] wrote: When we remove CEE.SCEERUN joblib statement from the JCL, the job abends with C03: IKJ56641I SYSTEM ABEND CODE C03 REASON CODE 0004 Note the message ID: It's a TSO message. Leads me to believe more needs to be known about just how the program is invoked. Seems that it's not via normal batch JCL; i.e., it's not via //STEPNAME EXEC PGM=COBOLPGM -jc- Perhaps its a DB2 COBOL program. But that shouldn't matter. It should run without the JOBLIB all things being equal. 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
