MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2014

Re: similar *PAGSEG objects in two libs with same name - how to print both next to each other



fixed

On 23-Jan-2014 19:14 -0800, John Yeung wrote:
Two thoughts. I should warn you I have no idea what a *PAGSEG
object even is, but the way you're talking about them makes them
sound like some kind of image, which you can sort of embed or link in
a printer file.

Yes. They are a resource to be associated with a spooled file. The Page Segment usually provides an image for printing somewhere on a page.

My reply is effectively to the OP, but in reply to this message, because it provides a good lead-in.

To help clarify some later comments:

The Page Segment (*PAGSEG) object is a space object [type x'19' which is a Space Object, with subtype x'27'; i.e. x'1927']. They can be created with the Create Page Segment (CRTPAGSEG) command from data exported, usually from another system; i.e. effectively, this "create" feature is an import from some data that was previously stored in a program described database file. From that command's help text:
"... creates a page segment space object by copying a user-supplied AS/400 database file to an internal space object. The user must load the page segment resource into the database from a remote system (such as a System/370) ..."

First <<SNIP>>

Second crazy, more technical idea: Is there absolutely no way to
compare the objects byte-for-byte?

The *PAGSEG [like a *QRYDFN and most other non *USRxxx] object types are in the System Domain, so only a program running in the System State can access the object's space where the data resides [without receiving an error MCH6801 aka x4401]. Without addressability to the data [in the space], no direct comparison is possible.

If not directly, then perhaps after some kind of conversion,

There is such a feature available, the Convert Page Segment to PFM (CVTPAGSPFM) command; followup at the end of my reply. Presumably the /conversion/ of identical Page Segments would produce identical output.

like saving to a save file

Similar has been done for the dataspace of a database file member [for an undelete feature], as well as *QRYDFN objects [for a retrieve query definition]; the Query Definition objects also are a Space Object, but with type\subtype of x'1911'.

or dumping to an IFS stream file?

Although the *PAGSEG is just a simple space object, there are no direct methods provided to access the data in that space; though not directly a side effect of the inability to address the space with a Space Pointer as limited by the domain of the object.

If not on the i5/OS side (apologies if I'm getting the terminology
wrong) then perhaps in Qshell or PASE?

Still for lack of a method to directly access the space. Although the space of a *USRSPC object is directly accessible [e.g. DSPF, CPY], no such capability for other space objects [like *PAGSEG].

Just as the integrity of the object is protected by domain\state rules, the object is also limited for access, via only the supported _methods_. There are effectively no methods made available to access the data in the space; except what is available to the system domain, which is basically any action for a space object, achieved simply with the Set Space Pointer operation to obtain a pointer address to the space from the System Pointer to the object.

Of course what is the data [aside from pointer data] in the space can be obtained as a copy, and anything can be done to that copy; e.g. the DMPOBJ and the SAVOBJ both make a[n effective] copy of the data in the space, and that data could be used to effect a comparison.

The Dump Object (DMPOBJ) command provides a hexadecimal view of the contents of the "SPACE" portion of the object. The save of the object [e.g. into a save file; read as save records] also provides access to a copy of the contents. The former even provides references that expose the values of any pointer data included in the space.

More conveniently however, there is the Convert Page Segment to PFM (CVTPAGSPFM) command which appears to be an effective export from an existing *PAGSEG object, into a database file member. The effect of that command [as seen in some tests] was all data in the space object starting past some initial header, is copied into the physical file member. If so, there are many ways to compare that data; even SQL. But of course the data is binary, so is unsuitable to be displayed as character [irrespective the name of the data type of the database pseudo-field for the program-described file].

FWiW: Some limited types of data [one Image Data Stream (IMDS) or one Image Object Content Architecture (IOCA) function-set-10 image data stream] can be processed using the effective inverse function of the Convert PFM to Page Segment (CVTPFMPAGS) in order to create a Page Segment, instead of the CRTPAGSEG. See: GO CMDPAGSEG Note however: In a test I performed whereby one request had used CVTPFMPAGS and another had used CRTPAGSEG to created a Page Segment, both from the same source created from CVTPAGSPFM, the dumped objects mis-compared. However, the *PAGSEG created from that source did compare identically to the original object specified on the CVTPAGSPFM. For that testing, I used the *PAGSEG object QAFP/QFCPAGS2 because it was described in its TEXT() as having the IOCA FUNCTION-SET-10 format, so I figured the CVTPFMPAGS and CRTPAGSEG would be the same.?






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact