Conformance and Interoperatility | Presentation Encoding of FTAM PDUs and Data |
For FTAM-3 files, keep in mind that the native character sets (ASCII, EBCDIC, and so on) might be incompatible on the sending and receiving systems. For example, Compaq systems use the 7-bit ASCII character set, whereas some other vendors’ systems use 8-bit EBCDIC. If you decide to send or receive text characters as FTAM-3 binary data, some conversion of the native character set might be necessary.
Some files might contain multiple character sets. The file system provides no means of storing information on the location of character-set transitions within a file residing in it. Because the Compaq responder removes escape sequences when enforcing maximum- string-length limitations on data being written to the VFS, indications of transitions between character sets are lost.
Writing of FTAM-2 Files
FTAM-2 files that are SQL tables must be written using the flat all data units (FA) access context, since each incoming data element represents a single SQL field and node descriptors are needed to delineate rows. Attempting to write to an SQL table using the unstructured all data (UA) access context causes the responder to return a cancel request that includes a diagnostic message indicating a poorly specified FADU. The file is left in an unknown state.
FTAM-2 files that are not SQL tables may be written using either the FA or UA access context. When FTAM-2 files are written using the FA access context, the responder expects each text data element transferred to be preceded by a node-descriptor data element. If the node descriptor element is omitted, the responder returns a cancel request that includes a diagnostic message indicating an FTAM protocol error
Presentation Encoding of FTAM PDUs and Data
As described in ISO 8823, clause 8, there are several options for encoding FTAM PDUs as presentation data. Presentation data is encoded as a SEQUENCE OF PDV-list. Each PDV list contains one or more presentation data values (PDVs). PDV lists are encoded as single-ASN1-type, octet-aligned, or arbitrary. If only a single Abstract Syntax Notation-1 (ASN.1) data element (that is, a single PDV) is to be encoded, then a single PDV list encoded as single-ASN1-type may be used. However, if multiple ASN.1 data elements (that is, multiple PDVs) are to be encoded (as with grouped requests, concatenated PDUs, and most F-DATA requests), there are several options:
Place the PDVs in a single PDV list encoded as octet-aligned.
Place the PDVs in multiple PDV lists, each containing one ASN.1 data element (one PDV), encoded as single-ASN1-type.
•Place the PDVs in multiple PDV lists, some containing multiple data elements encoded as octet-aligned and others containing a single data element encoded as single-ASN1-type.
Any of these three options is valid if all data elements have the same presentation context. If different presentation contexts are needed (as would be the case, for example, with FTAM-2 data using the FA access context), a separate PDV list must be used for each different presentation context, and the third option applies.
2-6
