Re: Linkage editor different ways to bind
In [EMAIL PROTECTED], on 09/25/2008 at 09:39 AM, Paul Gilmartin [EMAIL PROTECTED] said: Haven't the archaic constraints on ordering of overriding DD statements been much relaxed in recent OS releases? Not relaxed, just changed in such a way as to break existing JCL. -- 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: Linkage editor different ways to bind
Hi Itschak, In respect of your Linkage Edit issue: Situation two, that in error: Output from compiler is in an object library. SYSLIB is the same. A SYSLIN INCLUDE OBJ(MYPGM)' loads the object code, but all the Cobol2 modules needed to be linked together with the object code couldn't be found although they are in the SYSLIB. Is NCAL set in the Linkage Edit Parm parameter. If it is it inhibits the automatic search of SYSLIB. Try removing it if present. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- 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: Linkage editor different ways to bind
I doubt that, as the two run on the same machine (same defaults) and with same parameters passed to the binder.farther more, the second case scanned syslib, but referenced only the second library and ignored the first one. To be more specific, here is the onle who worked for me: //syslin dd disp=shr,dsn=syslin from prev. step //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib This one didn't work for me: only modules from my.load.lib included, but sys1.cob2lib includes were ignored: //anydd dd disp=my.obj.lib,disp=shr //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib //sysin dd * include anydd(mypgm) /* I am not at my desk to check it and I'll give it a try next week. On Thu, Sep 25, 2008 at 11:28 AM, Terry Sambrooks [EMAIL PROTECTED] wrote: Hi Itschak, In respect of your Linkage Edit issue: Situation two, that in error: Output from compiler is in an object library. SYSLIB is the same. A SYSLIN INCLUDE OBJ(MYPGM)' loads the object code, but all the Cobol2 modules needed to be linked together with the object code couldn't be found although they are in the SYSLIB. Is NCAL set in the Linkage Edit Parm parameter. If it is it inhibits the automatic search of SYSLIB. Try removing it if present. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- 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: Linkage editor different ways to bind
Hi Itschak Looking at the two examples below. Should the SYSIN in the second one be SYSLIN, or is there another definition somewhere else. SYSLIN being the main input with SYSIN usually being a concatenation via // DD DDNAME=SYSIN //syslin dd disp=shr,dsn=syslin from prev. step //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib This one didn't work for me: only modules from my.load.lib included, but sys1.cob2lib includes were ignored: //anydd dd disp=my.obj.lib,disp=shr //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib //sysin dd * include anydd(mypgm) Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- 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: Linkage editor different ways to bind
Yes, It is SYSLIN. On Thu, Sep 25, 2008 at 2:47 PM, Terry Sambrooks [EMAIL PROTECTED] wrote: Hi Itschak Looking at the two examples below. Should the SYSIN in the second one be SYSLIN, or is there another definition somewhere else. SYSLIN being the main input with SYSIN usually being a concatenation via // DD DDNAME=SYSIN //syslin dd disp=shr,dsn=syslin from prev. step //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib This one didn't work for me: only modules from my.load.lib included, but sys1.cob2lib includes were ignored: //anydd dd disp=my.obj.lib,disp=shr //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib //sysin dd * include anydd(mypgm) Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- 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: Linkage editor different ways to bind
On Thu, 25 Sep 2008 08:03:39 +0300, Itschak Mugzach wrote: Any idea why Situation two doesn't work? As I said, it looks like a binder parameter that controls that, but I can't find which one. Please post the complete JCL for your situation 2. If a PROC is used, post the proc and the JCL that invokes it, including overriding DD statements. -- 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: Linkage editor different ways to bind
This could be happening because ANYDD is a new DD statement which should follow the SYSLIB DD statements if there is a SYSLIB DD statement present in the link-edit procedure being invoked. Specifying MSGLEVEL=(1,1) on the JOB card should make that clear, Bill On Thu, 25 Sep 2008 15:08:03 +0300, Itschak Mugzach [EMAIL PROTECTED] wrote: Yes, It is SYSLIN. On Thu, Sep 25, 2008 at 2:47 PM, Terry Sambrooks [EMAIL PROTECTED] wrote: Hi Itschak Looking at the two examples below. Should the SYSIN in the second one be SYSLIN, or is there another definition somewhere else. SYSLIN being the main input with SYSIN usually being a concatenation via // DD DDNAME=SYSIN //syslin dd disp=shr,dsn=amp;syslin from prev. step //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib This one didn't work for me: only modules from my.load.lib included, but sys1.cob2lib includes were ignored: //anydd dd disp=my.obj.lib,disp=shr //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib //sysin dd * include anydd(mypgm) Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- 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: Linkage editor different ways to bind
I can't supply JCL for situation two, as this is dynamicly invoked by SCLM. I plan to changed the IOTYPE from S to A and specify the object library as the input, including member name. I read the DFSMS Program management manual and have some ideas to check next week... Itschak On Thu, Sep 25, 2008 at 4:34 PM, Tom Marchant [EMAIL PROTECTED]wrote: On Thu, 25 Sep 2008 08:03:39 +0300, Itschak Mugzach wrote: Any idea why Situation two doesn't work? As I said, it looks like a binder parameter that controls that, but I can't find which one. Please post the complete JCL for your situation 2. If a PROC is used, post the proc and the JCL that invokes it, including overriding DD statements. -- 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 -- 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: Linkage editor different ways to bind
On Thu, 25 Sep 2008 09:28:27 -0500, Big Iron wrote: This could be happening because ANYDD is a new DD statement which should follow the SYSLIB DD statements if there is a SYSLIB DD statement present in the link-edit procedure being invoked. Specifying MSGLEVEL=(1,1) on the JOB card should make that clear, Haven't the archaic constraints on ordering of overriding DD statements been much relaxed in recent OS releases? On Thu, 25 Sep 2008 15:08:03 +0300, Itschak Mugzach wrote: Yes, It is SYSLIN. On Thu, Sep 25, 2008 at 2:47 PM, Terry Sambrooks wrote: This one didn't work for me: only modules from my.load.lib included, but sys1.cob2lib includes were ignored: //anydd dd disp=my.obj.lib,disp=shr //syslib dd disp=shr,dsn=sys1.cob2lib // dd disp=shr,dsn=my.load.lib //sysin dd * include anydd(mypgm) -- gil -- 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: Linkage editor different ways to bind
Have you closely compared the SYSPRINT output to check if the processing options differ in any way? Date: Thu, 25 Sep 2008 17:34:16 +0300 From: [EMAIL PROTECTED] Subject: Re: Linkage editor different ways to bind To: IBM-MAIN@BAMA.UA.EDU I can't supply JCL for situation two, as this is dynamicly invoked by SCLM. I plan to changed the IOTYPE from S to A and specify the object library as the input, including member name. I read the DFSMS Program management manual and have some ideas to check next week... Itschak _ Get more out of the Web. Learn 10 hidden secrets of Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008 -- 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: Linkage editor different ways to bind
Yes. The main difference is that SCLM uses binder INCLUDE command, while the batch program is using the object code as main input. Itschak On Thu, Sep 25, 2008 at 5:58 PM, J R [EMAIL PROTECTED] wrote: Have you closely compared the SYSPRINT output to check if the processing options differ in any way? Date: Thu, 25 Sep 2008 17:34:16 +0300 From: [EMAIL PROTECTED] Subject: Re: Linkage editor different ways to bind To: IBM-MAIN@BAMA.UA.EDU I can't supply JCL for situation two, as this is dynamicly invoked by SCLM. I plan to changed the IOTYPE from S to A and specify the object library as the input, including member name. I read the DFSMS Program management manual and have some ideas to check next week... Itschak _ Get more out of the Web. Learn 10 hidden secrets of Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008 -- 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: Linkage editor different ways to bind
First, you should be using the supported runtimes for COBOL2, and they are in LE. Otherwise, results can be unpredictable. I believe the name is hlq.SCEELKED. Second, compiler options for the older compliers can influence the binder behavior. I believe the ROT is RES DYNAM. Third, what do you mean 'couldn't be found?' AFAIK, a properly linked COBOL2 program will have only a few 'stub' CSECTS in the final program. Fourth, when an INCLUDED module contains other CSECTs, the Binder will not replace them unless explicitly directed to do so. Old COBOL runtimes as well as out of date subroutines can sneak into production via this vector and cause some real headscratcher problems. HTH -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Itschak Mugzach Sent: Thursday, September 25, 2008 12:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Linkage editor different ways to bind I have two Binder situations. One works and the other is in error I suspect that this is a binder parm that cause the error. Situation one, that works: Output from the compiler (Object) is in the syslin. Two libraries are in the syslib concatenation: SYS1.COB2LIB and MY.LOADLIB. The Binder ends successfully, referring only to MY.LOADLIB and the SYSLIN in the dataset report. Situation two, that in error: Output from compiler is in an object library. SYSLIB is the same. A SYSLIN INCLUDE OBJ(MYPGM)' loads the object code, but all the Cobol2 modules needed to be linked together with the object code couldn't be found although they are in the SYSLIB. Any idea why Situation two doesn't work? As I said, it looks like a binder parameter that controls that, but I can't find which one. Regards, Itschak NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Linkage editor different ways to bind
Hello Hal, First, this is not my system. We just do some near-system development. I do not have anyway to influence the way my customer work.On systems I managed, I climbed before y(K2) ... Second, nop. Third, the Cobol2 stub modules was 'not resolved' Although the Cob2lib was in the syslib concatenation. From other hand, the second library in the syslib concatenation was searched to resolve csects. Those csects was not required when the SYSLIN pointed directly to the object code and not indirectly via INCLUDE xx(myprog). This is realy strange situation I can't explain. Four, the old way, putting the object code in the syslib works fine ;-( Thanks for your ideas (res, etc. ). I'll check them next week. On Thu, Sep 25, 2008 at 6:31 PM, Hal Merritt [EMAIL PROTECTED] wrote: First, you should be using the supported runtimes for COBOL2, and they are in LE. Otherwise, results can be unpredictable. I believe the name is hlq.SCEELKED. Second, compiler options for the older compliers can influence the binder behavior. I believe the ROT is RES DYNAM. Third, what do you mean 'couldn't be found?' AFAIK, a properly linked COBOL2 program will have only a few 'stub' CSECTS in the final program. Fourth, when an INCLUDED module contains other CSECTs, the Binder will not replace them unless explicitly directed to do so. Old COBOL runtimes as well as out of date subroutines can sneak into production via this vector and cause some real headscratcher problems. HTH -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Itschak Mugzach Sent: Thursday, September 25, 2008 12:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Linkage editor different ways to bind I have two Binder situations. One works and the other is in error I suspect that this is a binder parm that cause the error. Situation one, that works: Output from the compiler (Object) is in the syslin. Two libraries are in the syslib concatenation: SYS1.COB2LIB and MY.LOADLIB. The Binder ends successfully, referring only to MY.LOADLIB and the SYSLIN in the dataset report. Situation two, that in error: Output from compiler is in an object library. SYSLIB is the same. A SYSLIN INCLUDE OBJ(MYPGM)' loads the object code, but all the Cobol2 modules needed to be linked together with the object code couldn't be found although they are in the SYSLIB. Any idea why Situation two doesn't work? As I said, it looks like a binder parameter that controls that, but I can't find which one. Regards, Itschak NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Linkage editor different ways to bind
I have two Binder situations. One works and the other is in error I suspect that this is a binder parm that cause the error. Situation one, that works: Output from the compiler (Object) is in the syslin. Two libraries are in the syslib concatenation: SYS1.COB2LIB and MY.LOADLIB. The Binder ends successfully, referring only to MY.LOADLIB and the SYSLIN in the dataset report. Situation two, that in error: Output from compiler is in an object library. SYSLIB is the same. A SYSLIN INCLUDE OBJ(MYPGM)' loads the object code, but all the Cobol2 modules needed to be linked together with the object code couldn't be found although they are in the SYSLIB. Any idea why Situation two doesn't work? As I said, it looks like a binder parameter that controls that, but I can't find which one. Regards, Itschak -- 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
