On 27-Nov-2013 13:12 -0800, Stone, Joel wrote:
I asked this a few months ago and didn't get much response <<SNIP>>
Seemed like the issue was well on the way to resolution.?:
http://archive.midrange.com/midrange-l/201304/msg01260.html
And FWiW I verified the "Copy Source Overlay" is just a simple CPYF
invocation, preceded some validity checking for existence and verifying
that the record format of the target file is RCDLEN(80) PF-DTA [or
possibly something similar]; per:
http://archive.midrange.com/midrange-l/201304/msg01283.html
We use STRAFPU to create lines and boxes on an INVoice page; AFP
source is named OVL_INV. This builds a new member in a physical file
AFPSRC with a member named OVL_INV.
After creating the source with the editor, a *OVL object is created
named OVL_INV_OBJ.
Aldon supports promotion of the *OVL object just fine (OVL_INV_OBJ)
But they don't seem to have a method to promote the source
(OVL_INV).
Aldon claims it is NOT source because the PF type is not *SRC (like
it would be for CL or RPG). Of course it is source, but that is just
semantics.
Instead the FILETYPE is *DATA.
The so-called /source/ contains non-printable\non-displayable data,
so definitely the data is not literally *source* data in the classical
sense of *text* data. Merely being the *location* whence data is
retrieved, as the /source/ of the data used to create the object, does
not imply an equivalence in meaning for the same term used in each
context. A non-binary copy taken of the data, a /text/ copy, would
invariably lead to the corruption of the non-text data across encoding
schemes [e.g. EBCDIC to ASCII] or even across EBCDIC CCSIDs. Hardly
seems to be "just semantics."
<<SNIP>>
Has anyone found a method of promoting AFP source thru Aldon?
Multiple mentions of a "Data Option" feature. Any progress on that
front?
Easy enough to copy the data to a source member if necessary, into a
source member or elsewhere. As Dan had suggested\alluded in April, the
CPYF FMTOPT(*CVTSRC) is a binary copy [although be sure to use CRTSRCPF
CCSID(*HEX) to properly encode the target of the copy; other references
need to avoid seeing the data as /text/ as well]. Another option
alluded in that message was using stream files:
http://archive.midrange.com/midrange-l/201304/msg01244.html
The CPYTOSTMF and CPY command can also copy the binary data to a
source member. The CPYTOSTMF and CPY commands can also copy to a User
Space (*USRSPC) or to a stream file (STMF); beneficial, if like PF-SRC
members, the feature might enable easily /promoting/ one of those other
types. The "Data conversion options (CVTDTA)" parameter would need to
specify *NONE for the CPYTOSTMF command, and the "Data Format (DTAFMT)"
parameter would need to specify *BINARY for the CPY command, to ensure
no character translation. But if nothing had eventually changed to
[IMO] /properly/ assign the *HEX CCSID to a created STMF by either
command [when using binary copy from a member tagged with CCSID(*HEX)],
then the STMF needs to be pre-created or changed, to be tagged with
CCSID(65535) so any references do not accidentally corrupt the non-text
data. The User Space object does not support a CCSID attribute; like a
program-described file, the reader and writer must know how to treat the
data. Note: The CPYTOSTMF and it inverse action of CPYFRMSTMF, must be
careful to avoid any line-end (EOR) or /tab/ related processing... which
should be implied by CVTDTA(*NONE), but for which the ENDLINFMT(*FIXED)
may be required [something I specify, just to be sure].? Of course
writing your own binary copy feature is an option too; i.e. need not be
beholden to the system utilities that are provided.
midrange.com
