On 1/24/2014 1:33 PM, Stone, Joel wrote:
that the proper specifications were ignored?
I am NOT suggesting that the specs were ignored. I think that they are working as IBM intended.
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.
I would expect, as you probably did, that if you specify a qualified
object reference, that it should be used, no matter what - there are no
overrides for page segments, right?
For me, this doesn't seem similar to COMPILE vs RUN - for example, we
can specify in an F-spec the exact file that should be used at run-time
(EXTFILE) - maybe an override can change this, but it will use exactly
what is specified, if you qualify it - you can say *LIBL, which is the
default. EXTDESC is used for compile-time, and EXTFILE can be set to
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.
I will try your suggestion of commands to verify the resource name and let you know what I find.
It will be interesting to see what kind of reference is inserted into
the spooled file.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, January 24, 2014 1:06 PM
Subject: Re: similar *PAGSEG objects in two libs with same name - how to print both next to each other
On 24-Jan-2014 10:34 -0800, Stone, Joel wrote:
Vernon Hamberg on Friday, January 24, 2014 12:17 AM wrote:
Was it verified whether the resources were properly defined within
I agree that the lib-name can be specified in DDS. However, the
As it says in the DDS documentation:
"You can specify the library-name, page-segment-name,
position-down, position-across, width, height and rotation
parameters as constants, program-to-system fields, or a combination
of both, <<SNIP>>
output writer SEEMS to ignore this lib-name and instead seems to
select it at print-time from a liblist.
the spool file before concluding that the effect was instead, that the
proper specifications were ignored? In a prior reply, I offered an ad
hoc script of commands to issue to verify the resource names associated
with the spool file. Surely if the effect is incorrect output,
irrespective of wherein the issue lies, being either the named resources
getting associated with the spool file or the writing of the spool file
improperly choosing from the correctly named resources, then either
would be considered a defect that could be reported to IBM?