× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.