On 10 August 2017 at 08:05, Peter Relson <rel...@us.ibm.com> wrote: > <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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
