AW: Re: How are Program Object sections with Defer attribute loaded?
>>Are they loaded into a specific subpool defined by MVS, or the >>loading piece of software responsible to do an appropriate >>STORAGE OBTAIN before using that internal interface? > > >Both are possible. The default system processing happens to use subpool 1 >(but the subpool number is not to be considered an interface). But the >exploiter can provide their own storage. Thank you, Sir Cheers, Peter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: How are Program Object sections with Defer attribute loaded?
>>How does one request that "deferred load" section be >>loaded now? >"One" does not. LE does, using an internal interface. LE is responsible for making sure that both the "immediate load" and "deferred load" sections are in place. I understand LE is using it, but since "deferred load" is mentioned in the Binder manual, I thought it might be a public interface. Ok, it is not. Curiosity satisfied, >As to finding it in a dump, perhaps that would be based on knowing the address of the WSA, or perhaps some LE-based diagnostics. So, although part of a load module in a PDSE, "deferred load" sections, when loaded, are not represented by any of the structures that represent load modules (CDE, etc). Are they loaded into a specific subpool defined by MVS, or the loading piece of software responsible to do an appropriate STORAGE OBTAIN before using that internal interface? Sorry, here it is again, the curiosity :-) -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: How are Program Object sections with Defer attribute loaded?
[Default] On 10 May 2017 11:09:25 -0700, in bit.listserv.ibm-main p...@gmx.ch (Peter Hunkeler) wrote: > > > >>> How does one request that "deferred load" section be loaded now? I probably >>> was looking for the wrong thing at the wrong place, since I could not find >>> it. >>> >> I believe they're loaded on demand. If you need them, they' re there; >if they're not there, you didn't need them. > > > >This is a function offered by the MVS Binder and the MVS Loader in some way. >It is being used by LE, which is the component loading Cobol, well MVS, load >modules. > > >In previous versions of Cobol, the Working Storage section was part of the >load module, and it was easier to locate Working Storage variables in dump. >Now, they are disconnected from the code section, thus it all looks different >in a dump. This is how I became aware of "deferred load" sections. > Since VS COBOL II release 1.4 with the RENT option, WORKING-STORAGE has not been in the load module. Clark Morris > >I'm a curious MVS guy, and I'm curious to understand this. I'm looking at this >from a pure MVS point of view. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: How are Program Object sections with Defer attribute loaded?
>That's actually a trickier question than you might imagine! I imagine it is! In my current job, I'm getting involved when standard application debugging techniques don't help anymore. I usually work with IPCS, so SYSMDUMPs and SVCDUMPs. We moved to Cobol V5.2 earlier this year, but I still need to find the content of Cobol variables in those dumps. The changes to how Working Storage is implemented, and the fact that this is mostly undocumented, makes it difficult. This is the real reason I'm trying to understand all this. Your comments are most welcome! > There are a number of cases: the case where your module consists of COBOL, > PL/I and assembler only and all other cases. All other cases include cases > where the COBOL run time support is implemented in a language other than the > above. These cases include OO COBOL, XML support and a few others. > > > In the second case (not pure COBOL), the C_WSA is loaded in exactly the same > way as it is for a C program. Basically, first the program is loaded and > then the C run time gets control. It determines that you want to start new > instance of this program (C_WSA is only used for RENT.) So it calls CEEPPOS > which is the actual routine that gets a WSA and initializes it. > This all happens before main is run. (Or, in the case of C++, before any > file scope statics are constructed.) Yes, this is well understood. > In the first case, your program starts and the COBOL bootstrap routine gets > control. That routine is called at the start of every PROGRAM. In most > cases, it checks a few things and returns. But for the first program in the > run unit, it does some work including ensuring that LE is up. Part of that > work is getting storage for the WSA. > All of this happens before the first user statement in the PROCEDURE DIVISION > is executed. > So, no matter how the C_WSA is loaded (by and LE routine or by the COBOL run > time) it is present before the first user written statement in the program is > executed. Yes, again well understood. > Which means that unless you're getting some sort of a trap during the COBOL > start up, you should always see the C_WSA somewhere in your storage. Yep, somewhere. But somewhere is not specific enough if you need to find the value of a variable at the time of the dump. > By the way, WORKING STORAGE is another area of complexity. In the case of > NOWSOPT (the default for V5) W-S items are directly in the C_WSA. In the > case of WSOPT (V6) W-S is separately allocated and the WSA contains a pointer > to that allocation. (Again, this is all done before the first user statement > is executed.) I really which there was a document describing all the variants in detail and how to find variables in a dump in each case. Lack of that document, I'm trying to find out step by step. You would seem to be able to be of great help for me on this quest. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: How are Program Object sections with Defer attribute loaded?
> Trust in the COBOL young Luke.. You do not need to understand the COBOL, It knows what you need. LOL ! Thanks for amusing me after a long day. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: How are Program Object sections with Defer attribute loaded?
>> How does one request that "deferred load" section be loaded now? I probably >> was looking for the wrong thing at the wrong place, since I could not find >> it. >> > I believe they're loaded on demand. If you need them, they' re there; if they're not there, you didn't need them. This is a function offered by the MVS Binder and the MVS Loader in some way. It is being used by LE, which is the component loading Cobol, well MVS, load modules. In previous versions of Cobol, the Working Storage section was part of the load module, and it was easier to locate Working Storage variables in dump. Now, they are disconnected from the code section, thus it all looks different in a dump. This is how I became aware of "deferred load" sections. I'm a curious MVS guy, and I'm curious to understand this. I'm looking at this from a pure MVS point of view. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
