Re: MSGIEW2678S Module contains one or more deferred classes
Hi Giliad: This is Ian of the binder development team. Thanks for your comments. We are going to update this description in the next release. Thanks and Best Regards! Ian YIN, Binder Development, z/OS Development, CSTL E-mail: yinyy...@cn.ibm.com Tel: 86-10-82454317 Tieline: 9054317 Address: 3BW351, Ring Bldg. No.28 Building, Zhong Guan Cun Software Park, No. 8 Dong Bei Wang West Road, ShangDi, Haidian District, Beijing 100193, P.R.China IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 2017/08/21 06:50:24: > From: Giliad Wilf <00d50942efa9-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 2017/08/21 06:51 > Subject: Re: MSGIEW2678S Module contains one or more deferred classes > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > A closing note: The binder has four entry > points: IEWBLINK, IEWBLOAD, IEWBLODI (the one > I had trouble with), and IEWBLDGO. > Of these four, only IEWBLINK binds into a program library. The other > three do perform in-core binding. > Yet, the "z/OS V2R2 MVS Program Management: Advanced Facilities" manual > states on page 27 that "IEWBLDGO cannot be used for programs containing > deferred load classes". > Nowhere could I find any such restriction on IEWBLOAD or on IEWBLODI. > So, seems the manual has to be corrected and list IEWBLOAD and IEWBLODI > together with IEWBLDGO as having this same restriction. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
A closing note: The binder has four entry points: IEWBLINK, IEWBLOAD, IEWBLODI (the one I had trouble with), and IEWBLDGO. Of these four, only IEWBLINK binds into a program library. The other three do perform in-core binding. Yet, the "z/OS V2R2 MVS Program Management: Advanced Facilities" manual states on page 27 that "IEWBLDGO cannot be used for programs containing deferred load classes". Nowhere could I find any such restriction on IEWBLOAD or on IEWBLODI. So, seems the manual has to be corrected and list IEWBLOAD and IEWBLODI together with IEWBLDGO as having this same restriction. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Fri, 11 Aug 2017 15:59:08 -0700, Tom Rosswrote: > >>Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find the= >>m documented in COBOL documentation library. >>Are WSOPT and NOWSOPT some nicknames of the accurate terms? >>Where are they documented? > >Everyone? No one should talk about this hidden option. We added it to V5 >for a specific customer situatation. We did not want to change V5 behavior >for everyone. COBOL V6 is now using the preferred WSOPT behavior. That >means that WORKING-STORAGE is acquired from HEAP just like all COBOL versions >did before COBOL V5. This in turn means that the STORAGE option can again be >used to set initial values of WOKRING-STORAGE to x'00' or x'FF' or anything. > >We have improved the "How to find WORKING-STORAGE at runtime" instructions >in the COBOL V6.2 Migration Guide. This has been a work in progress, starting >with trying to do things the 'C' way (WSA) and then moving back to having the >runtime allocate WORKING-STORAGE as in previous COBOL versions. > >By the way, COBOL V5 goes out of marketing in Sept, it will no longer be >available. Honestly, the only COBOL version I would think anyone would want >is COBOL V6.2, it has lots of things to make it more natural for COBOL >application programmers, as well as exploitation of z14 hardware and >performance improvements! > >Cheers, >TomR >> COBOL is the Language of the Future! << > The one thing that confused me was the word "option" which I've looked for in vain at COBOL Customization Guides for V5.1, V5.2 and V6.1. I understood "option" to refer to the selection of one of several possible values a variable can have, at the user discretion, while a "characteristic" would refer to a setting the user has no control over. So, WSOPT seems to a characteristic, not an "option". Are you hinting that Ent. COBOL V6 for z/OS will not generate deferred data classes? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
Frank Swarbrick wrote: Now imagine that the DLL gets loaded repeatedly and in each case only one of the programs it contains is actually executed. That case could have performance problems in the C world because the static data for all of the few thousand independent programs is created and initialized for each load of the DLL (and in each case you're only running one of the programs.) That isn't typically the design pattern for DLL's, "thousands of independent programs". Further, the static area is unloaded when the instance that invoked the DLL exits but the DLL itself stays loaded until the last instance using it exits. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
Sounds like someone ought to fix that! ;) From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Allan Kielstra <kiels...@ca.ibm.com> Sent: Friday, August 11, 2017 5:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes Yes a C DLL does have all static variables allocated and initialized when a DLL is loaded. This is usually fine. However suppose you had a few thousand independent programs that you linked into a DLL simply for packaging purposes. And suppose that each program had a lot of static storage associated with it. Now imagine that the DLL gets loaded repeatedly and in each case only one of the programs it contains is actually executed. That case could have performance problems in the C world because the static data for all of the few thousand independent programs is created and initialized for each load of the DLL (and in each case you're only running one of the programs.) That sort of packaging could create a performance issue for C programs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
Yes a C DLL does have all static variables allocated and initialized when a DLL is loaded. This is usually fine. However suppose you had a few thousand independent programs that you linked into a DLL simply for packaging purposes. And suppose that each program had a lot of static storage associated with it. Now imagine that the DLL gets loaded repeatedly and in each case only one of the programs it contains is actually executed. That case could have performance problems in the C world because the static data for all of the few thousand independent programs is created and initialized for each load of the DLL (and in each case you're only running one of the programs.) That sort of packaging could create a performance issue for C programs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
Well that explains why its not documented! Sorry for discussing your secret features. :) I am curious about the 'C' way being using the WSA. Does this mean a C DLL has all static variables allocated at the time the DLL is loaded? And is this a "non-issue", in contrast to COBOL, because C programs use far fewer static variables than COBOL programs using working-storage fields? From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Tom Ross <tmr...@stlvm20.vnet.ibm.com> Sent: Friday, August 11, 2017 4:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes >On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrick <frank.swarbrick@OUTLOOK= >.COM> wrote: > >>There was a post to ibm-main by Allan Kielstra of IBM compiler development= > (I think) on May 10, 2017 (How are Program Object sections with Defer attr= >ibute loaded?) that discusses how the writable static area (WSA) is used in= > COBOL V5 and COBOL V6. Briefly, this is how I understand it. If the "NOW= >SOPT" compiler option is used (the default in COBOL V5) then all COBOL work= >ing-storage is placed in the WSA. If the "WSOPT" compiler option is used t= >hen working-storage is separately allocated upon initial entry to the progr= >am and the address of the WS is placed in the WSA. >> >>Hopefully I got that all right! >> >Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find the= >m documented in COBOL documentation library. >Are WSOPT and NOWSOPT some nicknames of the accurate terms? >Where are they documented? Everyone? No one should talk about this hidden option. We added it to V5 for a specific customer situatation. We did not want to change V5 behavior for everyone. COBOL V6 is now using the preferred WSOPT behavior. That means that WORKING-STORAGE is acquired from HEAP just like all COBOL versions did before COBOL V5. This in turn means that the STORAGE option can again be used to set initial values of WOKRING-STORAGE to x'00' or x'FF' or anything. We have improved the "How to find WORKING-STORAGE at runtime" instructions in the COBOL V6.2 Migration Guide. This has been a work in progress, starting with trying to do things the 'C' way (WSA) and then moving back to having the runtime allocate WORKING-STORAGE as in previous COBOL versions. By the way, COBOL V5 goes out of marketing in Sept, it will no longer be available. Honestly, the only COBOL version I would think anyone would want is COBOL V6.2, it has lots of things to make it more natural for COBOL application programmers, as well as exploitation of z14 hardware and performance improvements! Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
>On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrick.COM> wrote: > >>There was a post to ibm-main by Allan Kielstra of IBM compiler development= > (I think) on May 10, 2017 (How are Program Object sections with Defer attr= >ibute loaded?) that discusses how the writable static area (WSA) is used in= > COBOL V5 and COBOL V6. Briefly, this is how I understand it. If the "NOW= >SOPT" compiler option is used (the default in COBOL V5) then all COBOL work= >ing-storage is placed in the WSA. If the "WSOPT" compiler option is used t= >hen working-storage is separately allocated upon initial entry to the progr= >am and the address of the WS is placed in the WSA. >> >>Hopefully I got that all right! >> >Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find the= >m documented in COBOL documentation library. >Are WSOPT and NOWSOPT some nicknames of the accurate terms? >Where are they documented? Everyone? No one should talk about this hidden option. We added it to V5 for a specific customer situatation. We did not want to change V5 behavior for everyone. COBOL V6 is now using the preferred WSOPT behavior. That means that WORKING-STORAGE is acquired from HEAP just like all COBOL versions did before COBOL V5. This in turn means that the STORAGE option can again be used to set initial values of WOKRING-STORAGE to x'00' or x'FF' or anything. We have improved the "How to find WORKING-STORAGE at runtime" instructions in the COBOL V6.2 Migration Guide. This has been a work in progress, starting with trying to do things the 'C' way (WSA) and then moving back to having the runtime allocate WORKING-STORAGE as in previous COBOL versions. By the way, COBOL V5 goes out of marketing in Sept, it will no longer be available. Honestly, the only COBOL version I would think anyone would want is COBOL V6.2, it has lots of things to make it more natural for COBOL application programmers, as well as exploitation of z14 hardware and performance improvements! Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
when I said "nowhere known to IEWBLODI for the deferred classes to be loaded from", I was thinking that IEWBLODI takes input from , and builds an executable in storage. Tony, I think of it that the binder has everything, just as it would when saving the executable to a data set. The deferred segment "template" is part of the program object. When a program object is fetched, the initial-load segments are loaded, and the deferred segment template is loaded. Later, the deferred segment can be instantiated. The output of the COBOL compiler includes information both about the initial-load segments and the deferred segment template. So I think that IEWBLODI should have access to it. It's just that there's nothing useful to be done with that template, just as there is nothing useful to be done with it if you have done a LOAD with ADDR. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrickwrote: > >There was a post to ibm-main by Allan Kielstra of IBM compiler development (I >think) on May 10, 2017 (How are Program Object sections with Defer attribute >loaded?) that discusses how the writable static area (WSA) is used in COBOL V5 >and COBOL V6. Briefly, this is how I understand it. If the "NOWSOPT" >compiler option is used (the default in COBOL V5) then all COBOL >working-storage is placed in the WSA. If the "WSOPT" compiler option is used >then working-storage is separately allocated upon initial entry to the program >and the address of the WS is placed in the WSA. > >Hopefully I got that all right! > Thank you. I went to Allan Kielstra's post on May 10, 2017, at: https://listserv.ua.edu/cgi-bin/wa?A2=ind1705=ibm-main=0=D===C4E3EF984A2A600693=giliadw%40yahoo.com=266764 ...and got the info I was looking for. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
I can't find any specific documentation. I learned about them "through the grapevine". From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Giliad Wilf <00d50942efa9-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 10, 2017 12:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrick <frank.swarbr...@outlook.com> wrote: >There was a post to ibm-main by Allan Kielstra of IBM compiler development (I >think) on May 10, 2017 (How are Program Object sections with Defer attribute >loaded?) that discusses how the writable static area (WSA) is used in COBOL V5 >and COBOL V6. Briefly, this is how I understand it. If the "NOWSOPT" >compiler option is used (the default in COBOL V5) then all COBOL >working-storage is placed in the WSA. If the "WSOPT" compiler option is used >then working-storage is separately allocated upon initial entry to the program >and the address of the WS is placed in the WSA. > >Hopefully I got that all right! > Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find them documented in COBOL documentation library. Are WSOPT and NOWSOPT some nicknames of the accurate terms? Where are they documented? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On 10 August 2017 at 08:05, Peter Relsonwrote: > > And the resulting IEW2678S makes sense in that context, because there > is nowhere known to IEWBLODI for the deferred classes to be loaded > from. So asking IBM to support deferred classes in IEWBLODI (or > IEWBLOAD, which is the same thing except without the IDENTIFY), makes > little sense. What might make sense would be an option on these two > functions to force all deferred classes to be loaded at the same time > as the non-deferred ones. > > > I'd have actually said that there is nowhere known to IEWBLODI for the > deferred classes to be > loaded *to* (rather than *from*). It is LE that needs the instantiation of > the C_WSA deferred class. > And LE might need more than one of them, depending on the application. Well, yes... I take your point, but I'm also not sure I'm wrong. When I said "nowhere known to IEWBLODI for the deferred classes to be loaded from", I was thinking that IEWBLODI takes input from , and builds an executable in storage. Other than having an option to load all classes at that time (as I suggested), all IEWBLODI could do would be to build some in-storage metadata along with the ready-to-run executable, that would indicate where to load the deferred classes *from* when the time comes. But because the that is the source of the executable code could be any combination of PDS[E], Unix file, object deck(s), GOFF files, or even data created dynamically by the invoker of IEWBLODI, there is no clear place for this putative metadata to point to. I know nothing of how the actual loading of deferred classes is triggered or implemented, but has to know where to find them. And that's the *from* I was talking about. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
And the resulting IEW2678S makes sense in that context, because there is nowhere known to IEWBLODI for the deferred classes to be loaded from. So asking IBM to support deferred classes in IEWBLODI (or IEWBLOAD, which is the same thing except without the IDENTIFY), makes little sense. What might make sense would be an option on these two functions to force all deferred classes to be loaded at the same time as the non-deferred ones. I'd have actually said that there is nowhere known to IEWBLODI for the deferred classes to be loaded *to* (rather than *from*). It is LE that needs the instantiation of the C_WSA deferred class. And LE might need more than one of them, depending on the application. IBM would almost certainly decline to support deferred classes in these services and would decline to provide an option like the one mentioned. But I share the question asked in one of the posts about a steplib. Wouldn't it make more sense to have the test versions of these modules in a different steplib, with the same module names and not do anything strange at run-time? Is it not feasible to have the JCL accommodate this? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 22:18:51 +, Frank Swarbrickwrote: >There was a post to ibm-main by Allan Kielstra of IBM compiler development (I >think) on May 10, 2017 (How are Program Object sections with Defer attribute >loaded?) that discusses how the writable static area (WSA) is used in COBOL V5 >and COBOL V6. Briefly, this is how I understand it. If the "NOWSOPT" >compiler option is used (the default in COBOL V5) then all COBOL >working-storage is placed in the WSA. If the "WSOPT" compiler option is used >then working-storage is separately allocated upon initial entry to the program >and the address of the WS is placed in the WSA. > >Hopefully I got that all right! > Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find them documented in COBOL documentation library. Are WSOPT and NOWSOPT some nicknames of the accurate terms? Where are they documented? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
There was a post to ibm-main by Allan Kielstra of IBM compiler development (I think) on May 10, 2017 (How are Program Object sections with Defer attribute loaded?) that discusses how the writable static area (WSA) is used in COBOL V5 and COBOL V6. Briefly, this is how I understand it. If the "NOWSOPT" compiler option is used (the default in COBOL V5) then all COBOL working-storage is placed in the WSA. If the "WSOPT" compiler option is used then working-storage is separately allocated upon initial entry to the program and the address of the WS is placed in the WSA. Hopefully I got that all right! From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Wednesday, August 9, 2017 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes I also see this in COBOL V5.2 binder listings for various programs of different types (sanitized): CLASS C_WSA LENGTH = 194 ATTRIBUTES = MRG, DEFER , RMODE=ANY OFFSET =0 IN SEGMENT 002 ALIGN = DBLWORD --- CLASS OFFSET NAMETYPELENGTH SECTION 0 $PRIV12 PART10 10 PROGNAME#S PART 184 PROGNAME The names and lengths are consistent among multiple programs, so the compiler must be doing something needing a WSA (Writable Static Area). Perhaps Tom Ross could explain that part to us. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, August 09, 2017 3:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes As I understand it, at least all debugging information (TEST option) is now added as deferred data classes in the program object instead of being sent to a separate dataset at compile time. The COBOL Pgmr's Guide says to totally eliminate TEST data use NOTEST(NODWARF). Not sure if that eliminates all deferred classes though. HTH Pe6ter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Giliad Wilf Sent: Wednesday, August 09, 2017 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes On Wed, 9 Aug 2017 13:37:54 -0400, Tony Harminc <t...@harminc.net> wrote: > >And the resulting IEW2678S makes sense in that context, because there >is nowhere known to IEWBLODI for the deferred classes to be loaded >from. So asking IBM to support deferred classes in IEWBLODI (or >IEWBLOAD, which is the same thing except without the IDENTIFY), makes >little sense. What might make sense would be an option on these two >functions to force all deferred classes to be loaded at the same time >as the non-deferred ones. > >And of course as John M points out, building the PO in a temporary >dataset (or one or more UNIX files...?) would be about as easy, would >perform almost as well, and sounds as though it would accomplish >what's needed. > >Tony H. > Can you suggest why, and what for, does Ent. COBOL V5.1 for z/OS generate deferred data class(es) at all? Is this being controlled by some compiler option that can be negated? Obviously, Ent. COBOL V4.2 for z/OS does not do this. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
I also see this in COBOL V5.2 binder listings for various programs of different types (sanitized): CLASS C_WSA LENGTH = 194 ATTRIBUTES = MRG, DEFER , RMODE=ANY OFFSET =0 IN SEGMENT 002 ALIGN = DBLWORD --- CLASS OFFSET NAMETYPELENGTH SECTION 0 $PRIV12 PART10 10 PROGNAME#S PART 184 PROGNAME The names and lengths are consistent among multiple programs, so the compiler must be doing something needing a WSA (Writable Static Area). Perhaps Tom Ross could explain that part to us. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Wednesday, August 09, 2017 3:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes As I understand it, at least all debugging information (TEST option) is now added as deferred data classes in the program object instead of being sent to a separate dataset at compile time. The COBOL Pgmr's Guide says to totally eliminate TEST data use NOTEST(NODWARF). Not sure if that eliminates all deferred classes though. HTH Pe6ter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Giliad Wilf Sent: Wednesday, August 09, 2017 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes On Wed, 9 Aug 2017 13:37:54 -0400, Tony Harminc <t...@harminc.net> wrote: > >And the resulting IEW2678S makes sense in that context, because there >is nowhere known to IEWBLODI for the deferred classes to be loaded >from. So asking IBM to support deferred classes in IEWBLODI (or >IEWBLOAD, which is the same thing except without the IDENTIFY), makes >little sense. What might make sense would be an option on these two >functions to force all deferred classes to be loaded at the same time >as the non-deferred ones. > >And of course as John M points out, building the PO in a temporary >dataset (or one or more UNIX files...?) would be about as easy, would >perform almost as well, and sounds as though it would accomplish >what's needed. > >Tony H. > Can you suggest why, and what for, does Ent. COBOL V5.1 for z/OS generate deferred data class(es) at all? Is this being controlled by some compiler option that can be negated? Obviously, Ent. COBOL V4.2 for z/OS does not do this. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
As I understand it, at least all debugging information (TEST option) is now added as deferred data classes in the program object instead of being sent to a separate dataset at compile time. The COBOL Pgmr's Guide says to totally eliminate TEST data use NOTEST(NODWARF). Not sure if that eliminates all deferred classes though. HTH Pe6ter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Giliad Wilf Sent: Wednesday, August 09, 2017 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MSGIEW2678S Module contains one or more deferred classes On Wed, 9 Aug 2017 13:37:54 -0400, Tony Harminc <t...@harminc.net> wrote: > >And the resulting IEW2678S makes sense in that context, because there >is nowhere known to IEWBLODI for the deferred classes to be loaded >from. So asking IBM to support deferred classes in IEWBLODI (or >IEWBLOAD, which is the same thing except without the IDENTIFY), makes >little sense. What might make sense would be an option on these two >functions to force all deferred classes to be loaded at the same time >as the non-deferred ones. > >And of course as John M points out, building the PO in a temporary >dataset (or one or more UNIX files...?) would be about as easy, would >perform almost as well, and sounds as though it would accomplish >what's needed. > >Tony H. > Can you suggest why, and what for, does Ent. COBOL V5.1 for z/OS generate deferred data class(es) at all? Is this being controlled by some compiler option that can be negated? Obviously, Ent. COBOL V4.2 for z/OS does not do this. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 13:37:54 -0400, Tony Harmincwrote: > >And the resulting IEW2678S makes sense in that context, because there >is nowhere known to IEWBLODI for the deferred classes to be loaded >from. So asking IBM to support deferred classes in IEWBLODI (or >IEWBLOAD, which is the same thing except without the IDENTIFY), makes >little sense. What might make sense would be an option on these two >functions to force all deferred classes to be loaded at the same time >as the non-deferred ones. > >And of course as John M points out, building the PO in a temporary >dataset (or one or more UNIX files...?) would be about as easy, would >perform almost as well, and sounds as though it would accomplish >what's needed. > >Tony H. > Can you suggest why, and what for, does Ent. COBOL V5.1 for z/OS generate deferred data class(es) at all? Is this being controlled by some compiler option that can be negated? Obviously, Ent. COBOL V4.2 for z/OS does not do this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On 9 August 2017 at 12:34, Binyamin Dissenwrote: > On Wed, 9 Aug 2017 08:10:53 -0500 Giliad Wilf wrote: > :>You got it right. > :>I need to further analyze the source to find out what else was IEWBLODI > supposed to do there. > > It builds the module in memory without requiring it to be hardened to disk. And the resulting IEW2678S makes sense in that context, because there is nowhere known to IEWBLODI for the deferred classes to be loaded from. So asking IBM to support deferred classes in IEWBLODI (or IEWBLOAD, which is the same thing except without the IDENTIFY), makes little sense. What might make sense would be an option on these two functions to force all deferred classes to be loaded at the same time as the non-deferred ones. And of course as John M points out, building the PO in a temporary dataset (or one or more UNIX files...?) would be about as easy, would perform almost as well, and sounds as though it would accomplish what's needed. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, Aug 9, 2017 at 11:34 AM, Binyamin Dissenwrote: > On Wed, 9 Aug 2017 08:10:53 -0500 Giliad Wilf > <00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > > :>On Wed, 9 Aug 2017 06:41:04 -0500, John McKown < > john.archie.mck...@gmail.com> wrote: > :> > :>>I'm probably not really understanding what you want to do. So I'll give > a > :>>try at an alternate explanation for what I _think_ you want. You have a > :>>"test" version of a program, call it TESTPGM, in your production PDSE. > This > :>>is a test version of PRODPGM in the same PDSE. You have another program, > :>>MAINPGM, which invokes PRODPGM. You want MAINPGM to invoke TESTPGM > instead, > :>>without any changes to MAINPGM. You are running MAINPGM inside some > sort of > :>>debugger. You debugger can "dynamically rename" TESTPGM to PRODPGM by > using > :>>the IEWBLODI. I am wondering why you can't simply do a LOAD on TESTPGM, > :>>then use and IDENTIFY to create a CDE for the name PRODPGM using the EPA > :>>for TESTPGM which you can get from the LOAD. Something akin to: > :>> > :>> LOAD EPLOC=NEWNAME > :>> ST 0,NEWEPA SAME ENTRY POINT > :>> LR 1,0 LOAD EPA TO GPR1 > :>> IDENTIFY EPLOC=OLDNAME,ENTRY=(1) > :>> > :>>Note, that I'm going mainly off of memory, so please excuse any errors > in > :>>the above. > :>> > :>>-- > :>>Veni, Vidi, VISA: I came, I saw, I did a little shopping. > :>> > :>>Maranatha! <>< > :>>John McKown > :> > :>You got it right. > :>I need to further analyze the source to find out what else was IEWBLODI > supposed to do there. > > It builds the module in memory without requiring it to be hardened to disk. > Ah. Now that makes more sense. It's doing an "internal" form of "link & go", joining multiple objects into a "program object" strictly in memory. Being a lazy SOB, I would just do an IEWL into a temporary, dynamically allocated, PDSE, then OPEN that and LOAD DCB= from it. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > -- If you look around the poker table & don't see an obvious sucker, it's you. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 08:10:53 -0500 Giliad Wilf <00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: :>On Wed, 9 Aug 2017 06:41:04 -0500, John McKownwrote: :> :>>I'm probably not really understanding what you want to do. So I'll give a :>>try at an alternate explanation for what I _think_ you want. You have a :>>"test" version of a program, call it TESTPGM, in your production PDSE. This :>>is a test version of PRODPGM in the same PDSE. You have another program, :>>MAINPGM, which invokes PRODPGM. You want MAINPGM to invoke TESTPGM instead, :>>without any changes to MAINPGM. You are running MAINPGM inside some sort of :>>debugger. You debugger can "dynamically rename" TESTPGM to PRODPGM by using :>>the IEWBLODI. I am wondering why you can't simply do a LOAD on TESTPGM, :>>then use and IDENTIFY to create a CDE for the name PRODPGM using the EPA :>>for TESTPGM which you can get from the LOAD. Something akin to: :>> :>> LOAD EPLOC=NEWNAME :>> ST 0,NEWEPA SAME ENTRY POINT :>> LR 1,0 LOAD EPA TO GPR1 :>> IDENTIFY EPLOC=OLDNAME,ENTRY=(1) :>> :>>Note, that I'm going mainly off of memory, so please excuse any errors in :>>the above. :>> :>>-- :>>Veni, Vidi, VISA: I came, I saw, I did a little shopping. :>> :>>Maranatha! <>< :>>John McKown :> :>You got it right. :>I need to further analyze the source to find out what else was IEWBLODI supposed to do there. It builds the module in memory without requiring it to be hardened to disk. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
[Default] On 9 Aug 2017 06:09:42 -0700, in bit.listserv.ibm-main 00d50942efa9-dmarc-requ...@listserv.ua.edu (Giliad Wilf) wrote: >On Wed, 9 Aug 2017 06:41:04 -0500, John McKown>wrote: > >>I'm probably not really understanding what you want to do. So I'll give a >>try at an alternate explanation for what I _think_ you want. You have a >>"test" version of a program, call it TESTPGM, in your production PDSE. This >>is a test version of PRODPGM in the same PDSE. You have another program, >>MAINPGM, which invokes PRODPGM. You want MAINPGM to invoke TESTPGM instead, >>without any changes to MAINPGM. You are running MAINPGM inside some sort of >>debugger. You debugger can "dynamically rename" TESTPGM to PRODPGM by using >>the IEWBLODI. I am wondering why you can't simply do a LOAD on TESTPGM, >>then use and IDENTIFY to create a CDE for the name PRODPGM using the EPA >>for TESTPGM which you can get from the LOAD. Something akin to: >> >> LOAD EPLOC=NEWNAME >> ST 0,NEWEPA SAME ENTRY POINT >> LR 1,0 LOAD EPA TO GPR1 >> IDENTIFY EPLOC=OLDNAME,ENTRY=(1) >> >>Note, that I'm going mainly off of memory, so please excuse any errors in >>the above. >> >>-- >>Veni, Vidi, VISA: I came, I saw, I did a little shopping. >> >>Maranatha! <>< >>John McKown > >You got it right. >I need to further analyze the source to find out what else was IEWBLODI >supposed to do there. Why wouldn't a separate STEPLIB in the STEPLIB concatenation with the appropriately named module work? Clark Morris >Thank you. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
On Wed, 9 Aug 2017 06:41:04 -0500, John McKownwrote: >I'm probably not really understanding what you want to do. So I'll give a >try at an alternate explanation for what I _think_ you want. You have a >"test" version of a program, call it TESTPGM, in your production PDSE. This >is a test version of PRODPGM in the same PDSE. You have another program, >MAINPGM, which invokes PRODPGM. You want MAINPGM to invoke TESTPGM instead, >without any changes to MAINPGM. You are running MAINPGM inside some sort of >debugger. You debugger can "dynamically rename" TESTPGM to PRODPGM by using >the IEWBLODI. I am wondering why you can't simply do a LOAD on TESTPGM, >then use and IDENTIFY to create a CDE for the name PRODPGM using the EPA >for TESTPGM which you can get from the LOAD. Something akin to: > > LOAD EPLOC=NEWNAME > ST 0,NEWEPA SAME ENTRY POINT > LR 1,0 LOAD EPA TO GPR1 > IDENTIFY EPLOC=OLDNAME,ENTRY=(1) > >Note, that I'm going mainly off of memory, so please excuse any errors in >the above. > >-- >Veni, Vidi, VISA: I came, I saw, I did a little shopping. > >Maranatha! <>< >John McKown You got it right. I need to further analyze the source to find out what else was IEWBLODI supposed to do there. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSGIEW2678S Module contains one or more deferred classes
I'm probably not really understanding what you want to do. So I'll give a try at an alternate explanation for what I _think_ you want. You have a "test" version of a program, call it TESTPGM, in your production PDSE. This is a test version of PRODPGM in the same PDSE. You have another program, MAINPGM, which invokes PRODPGM. You want MAINPGM to invoke TESTPGM instead, without any changes to MAINPGM. You are running MAINPGM inside some sort of debugger. You debugger can "dynamically rename" TESTPGM to PRODPGM by using the IEWBLODI. I am wondering why you can't simply do a LOAD on TESTPGM, then use and IDENTIFY to create a CDE for the name PRODPGM using the EPA for TESTPGM which you can get from the LOAD. Something akin to: LOAD EPLOC=NEWNAME ST 0,NEWEPA SAME ENTRY POINT LR 1,0 LOAD EPA TO GPR1 IDENTIFY EPLOC=OLDNAME,ENTRY=(1) Note, that I'm going mainly off of memory, so please excuse any errors in the above. On Wed, Aug 9, 2017 at 2:46 AM, Giliad Wilf < 00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > apologies All. Sorry for the "dense" post. Here is a re-send: > Hi All, I'm trying to do an in-core re-bind of a program object > currently residing in a PDSE, rename it, and present its new name to > Contents Supervisor, by dynamically calling IEWBLODI to do > the job. IEWBLODI fails, issuing MSGIEW2678S, stating "MODULE CONTAINS > DATA CLASSES NOT SUPPORTED BY THE LOAD FUNCTION", and further > explaining "Module contains one or more deferred classes". > This program object has been generated by Enterprise COBOL V5.1 > for z/OS. The problem does not occur when the same source gets > compiled by Enterprise COBOL V4.2 for z/OS. > Close inspection and comparison of the outputs of two compilers, > V4.2 vs. V5.1, reveals that COBOL V4.2 generates program objects > V2, while COBOL V5.1 generates program objects V3, that obviously contain > some deferred data classe(s). > I've tried to enforce 'COMPAT=PM2' on the binder at step LKED of the > procedure IGYWCL that called COBOL V5.1 to produce the > initial program object, to no avail. The binder rejects this > override and terminates with RC12. > Deferred classes are described as some performance measure > intended for postponing costly instantiation, until they are really > required. > This in-core re-bind for renaming, is part of a home-written debug > monitor, intended to allow shop users to do maintenance on production > COBOL subroutines, place them under some temporary name > in production PDSEs, and renaming them in-core into their > "production" names before invoking main programs that call them, > so that these main programs will be able to call the subroutines by their > "production" names (without having to change anything in > the calling main programs). > OS is z/OS V2R2. > Any advice will be greatly appreciated. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MSGIEW2678S Module contains one or more deferred classes
apologies All. Sorry for the "dense" post. Here is a re-send: Hi All, I'm trying to do an in-core re-bind of a program object currently residing in a PDSE, rename it, and present its new name to Contents Supervisor, by dynamically calling IEWBLODI to do the job. IEWBLODI fails, issuing MSGIEW2678S, stating "MODULE CONTAINS DATA CLASSES NOT SUPPORTED BY THE LOAD FUNCTION", and further explaining "Module contains one or more deferred classes". This program object has been generated by Enterprise COBOL V5.1 for z/OS. The problem does not occur when the same source gets compiled by Enterprise COBOL V4.2 for z/OS. Close inspection and comparison of the outputs of two compilers, V4.2 vs. V5.1, reveals that COBOL V4.2 generates program objects V2, while COBOL V5.1 generates program objects V3, that obviously contain some deferred data classe(s). I've tried to enforce 'COMPAT=PM2' on the binder at step LKED of the procedure IGYWCL that called COBOL V5.1 to produce the initial program object, to no avail. The binder rejects this override and terminates with RC12. Deferred classes are described as some performance measure intended for postponing costly instantiation, until they are really required. This in-core re-bind for renaming, is part of a home-written debug monitor, intended to allow shop users to do maintenance on production COBOL subroutines, place them under some temporary name in production PDSEs, and renaming them in-core into their "production" names before invoking main programs that call them, so that these main programs will be able to call the subroutines by their "production" names (without having to change anything in the calling main programs). OS is z/OS V2R2. Any advice will be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MSGIEW2678S Module contains one or more deferred classes
Hi All, I'm trying to do an in-core re-bind of a program object currently residing in a PDSE, rename it, and present its new name to Contents Supervisor, by dynamically calling IEWBLODI to do the job. IEWBLODI fails, issuing MSGIEW2678S, stating "MODULE CONTAINS DATA CLASSES NOT SUPPORTED BY THE LOAD FUNCTION", and further explaining "Module contains one or more deferred classes". This program object has been generated by Enterprise COBOL V5.1 for z/OS.The problem does not occur when the same source gets compiled by Enterprise COBOL V4.2 for z/OS. Close inspection and comparison of the outputs of two compilers, V4.2 vs. V5.1, reveals that COBOL V4.2 generates program objects V2, while COBOL V5.1 generates program objects V3, that obviously contain some deferred data classe(s). I've tried to enforce 'COMPAT=PM2' on the binder at step LKED of the procedure IGYWCL that called COBOL V5.1 to produce the initial program object, to no avail. The binder rejects this override and terminates with RC12. Deferred classes are described as some performance measure intended for postponing costly instantiation, until it is really required. This in-core re-bind for renaming, is part of a home-written debug monitor, intended to allow shop users to do maintenance on production COBOL subroutines, place them under some temporary name in production PDSEs, and renaming them in-core into their "production" names before invoking main programs that call them, so that these main programs will be able to call the subroutines by their "production" names (without having to change anything in the calling main programs). OS is z/OS V2R2. Any advice will be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN