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.
midrange.com
