On 24-Jan-2014 11:33 -0800, Stone, Joel wrote:

I am NOT suggesting that the specs were ignored. I think that they
are working as IBM intended.

Just seems an odd interpretation IMO. If the DDS offers the ability to specify the library name, but the run-time does not use those library specifications to locate the resource, then I would consider those library-name specifications to have been ignored. The obvious implication seems to me, the DDS having given the ability to specify a library-name on the PAGSEG(), that the library-name specification should be honored.

I think it would be comparable to a file spec in RPG source. For CUST
file, the lib name at COMPILE time need not be the same as the lib
name at RUN time.

An analogous situation would require that the file spec, having been made by a constant or a variable-name, would include the library name. The F-Spec [without any keywords] is just a file name; no library name allowed. Thus, that name resolution at run-time is via a library list is the natural effect [noting: the open-member-search algorithm is different than the object-search algorithm when using a library-list].

I am suggesting that it is unfortunate it works that way, but it
appears to do just that.

The difference is that I cannot control what the output writer
resolves to - once the spool file is created, it is no longer under
my app's control.

But your DDS specifications, in combination with having set the System-To-Program Field values would have explicitly defined, library-qualified even, where the system should find\resolve the named PAGSEG() resource. If a library name had not been specified, then I would agree that what the system decides to use is more variable, but library-qualified named object and object type is as explicit as it gets; i.e. what is in effect as a user or device AFPRSCLIBL, is moot.

I suspect however, that during the creation of the spooled file [as I just experienced in a test], there is a diagnostic being logged to warn that indeed, unfortunately, that *it just works that way* [apparently at least, for any one page]; i.e. contradicting what is IMO, an intuitive expectation, such that merely a diagnostic logged at run-time with no warning in the docs nor warning in the compiled DDS listing, would be a rather frustrating outcome:

Message ID . . . . . . . . . : CPD4091
Message . . . . : Same object name (&6) used on a page with different libraries specified.
Cause . . . . . : A page segment or overlay with the same name cannot be used with different libraries on the same page. Page segment or overlay &6 will be library qualified to library &7, not library &8.
Recovery . . . : Rename the overlay or page segment and try the job again.

I will try your suggestion of commands to verify the resource name
and let you know what I find.

If the msg CPD4091 F/QWPPERRS is getting logged, then the resource included in the list produced by the QGSLRSC should reflect the *PAGSEG from the library name seen as the replacement value &7 in the that message; i.e. there will not be two with the same name, but with different library names.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].