Re: Aldon LMi - how to support and promote AFP source

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.