Compaq OSI/APLMGR D43 Manual De Usuario
Conformance and Interoperatility
2 -6
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.
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.
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.
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
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:
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.
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.
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.
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.