Discussion:
MSGIEW2678S Module contains one or more deferred classes
(too old to reply)
Giliad Wilf
2017-08-09 07:45:56 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-08-09 11:39:57 UTC
Permalink
Raw Message
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 <
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-08-09 13:09:42 UTC
Permalink
Raw Message
Post by John McKown
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
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-08-09 16:30:55 UTC
Permalink
Raw Message
[Default] On 9 Aug 2017 06:09:42 -0700, in bit.listserv.ibm-main
Post by Giliad Wilf
Post by John McKown
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
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
Post by Giliad Wilf
Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-08-09 16:33:27 UTC
Permalink
Raw Message
On Wed, 9 Aug 2017 08:10:53 -0500 Giliad Wilf
<000000d50942efa9-dmarc-***@LISTSERV.UA.EDU> wrote:

:>On Wed, 9 Aug 2017 06:41:04 -0500, John McKown <***@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.

--
Binyamin Dissen <***@dissensoftware.com>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-08-09 17:01:57 UTC
Permalink
Raw Message
Post by Binyamin Dissen
On Wed, 9 Aug 2017 08:10:53 -0500 Giliad Wilf
:>On Wed, 9 Aug 2017 06:41:04 -0500, John McKown <
:>
:>>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
:>>
:>> 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.​
Post by 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-08-09 17:36:46 UTC
Permalink
Raw Message
Post by Binyamin Dissen
:>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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-08-09 18:35:03 UTC
Permalink
Raw Message
Post by Tony Harminc
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-08-09 19:31:57 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Giliad Wilf
Sent: Wednesday, August 09, 2017 2:36 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: MSGIEW2678S Module contains one or more deferred classes
Post by Tony Harminc
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-08-09 19:46:20 UTC
Permalink
Raw Message
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 NAME TYPE LENGTH SECTION
0 $PRIV000012 PART 10
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-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Wednesday, August 09, 2017 3:33 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Giliad Wilf
Sent: Wednesday, August 09, 2017 2:36 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: MSGIEW2678S Module contains one or more deferred classes
Post by Tony Harminc
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-08-09 22:17:43 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <***@BROADRIDGE.COM>
Sent: Wednesday, August 9, 2017 1:47 PM
To: IBM-***@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 NAME TYPE LENGTH SECTION
0 $PRIV000012 PART 10
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-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Wednesday, August 09, 2017 3:33 PM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of Giliad Wilf
Sent: Wednesday, August 09, 2017 2:36 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: MSGIEW2678S Module contains one or more deferred classes
Post by Tony Harminc
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-08-10 06:28:09 UTC
Permalink
Raw Message
Post by Frank Swarbrick
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-08-10 21:12:42 UTC
Permalink
Raw Message
I can't find any specific documentation. I learned about them "through the grapevine".

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Giliad Wilf <000000d50942efa9-dmarc-***@LISTSERV.UA.EDU>
Sent: Thursday, August 10, 2017 12:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: MSGIEW2678S Module contains one or more deferred classes
Post by Frank Swarbrick
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-08-10 12:04:19 UTC
Permalink
Raw Message
<snip>
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.
</snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-08-10 19:21:39 UTC
Permalink
Raw Message
Post by Peter Relson
<snip>
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.
</snip>
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
<wherever>, 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
<wherever> 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 <someone> 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-08-10 14:59:17 UTC
Permalink
Raw Message
Post by Peter Relson
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
I've been assigned to investigate why a client's home-written debugging
monitor that was last modified in the nineties, lacking adequate
documentation, and using absolute decimal self-defining terms rather
than symbols, started failing when the shop moved to Ent. COBOL V5 for
z/OS, from Ent. COBOL V4.2.

It turned that the monitor calls IEWBLODI for an in-code re-bind of temp-
-named production subroutines and presents them to Contents supervisor
in their real names, so that main programs will not need to be changed.

I thought maybe there is some compile option that will suppress creation
of deferred data classes.

I will have to work around this call for IEWBLODI.

Thank you.

Where can I read about WSOPT/NOWSOPT?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-08-11 08:45:35 UTC
Permalink
Raw Message
Post by Frank Swarbrick
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&L=ibm-main&T=0&O=D&F=&S=&X=C4E3EF984A2A600693&Y=giliadw%40yahoo.com&P=266764
...and got the info I was looking for.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-08-11 11:21:20 UTC
Permalink
Raw Message
<snip>
when I said "nowhere known to IEWBLODI for the deferred classes to be
loaded from", I was thinking that IEWBLODI takes input from
<wherever>, and builds an executable in storage.
</snip>

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Ross
2017-08-11 23:04:22 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-08-11 23:19:42 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU> on behalf of Tom Ross <***@STLVM20.VNET.IBM.COM>
Sent: Friday, August 11, 2017 4:59 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: 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 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Allan Kielstra
2017-08-11 23:29:19 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-08-12 00:05:10 UTC
Permalink
Raw Message
Sounds like someone ought to fix that! ;)

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Allan Kielstra <***@CA.IBM.COM>
Sent: Friday, August 11, 2017 5:30 PM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jack J. Woehr
2017-08-12 00:51:03 UTC
Permalink
Raw Message
Post by Allan Kielstra
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-08-12 12:53:11 UTC
Permalink
Raw Message
Post by Tom Ross
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...