Extended Host Code Support (XHCS)

LMSCONV supports the use of special (national) character sets. This coded character set name (CCSN) assigned to the member is - as far as possible - forwarded to the interfaces and taken into account during output.

If XHCS is not offered at the relevant interface, the default “no code” is always used.

LMSCONV itself does not require a particular character set, and does not even interpret the default setting in the user ID; internal sorting procedures, e.g. for the member names, are carried out independently of the CCS.

1. Implicit setting of the CCSN for a member
   Each member of a library can be assigned a character set. LMSCONV then always transfers the CCSN of the source to the target member.
   This can happen by adding a file with the ADD-ELEMENT statement by adopting the catalog attribute CCS. However, the CCSN is not stored extra in the attribute record (record type 164), so as to avoid inconsistencies.

   If data is added from the logical system file SYSDTA, the particular character set applicable is determined and the name is assigned to the member as an attribute.

   When adding modules from the EAM file, the modules are assigned the attribute “no code”.

   When copying members, the CCSN of the source member is always assigned to the target member.

2. CCSN logging
   The SHOW-ELEMENT-ATTRIBUTES statement and the operand INFORMATION= *MAXIMUM provide information on the assignment of coded character sets to members. Members that have the CCSN “no code” are not shown in the display.

3. Interpreting and forwarding the CCSN of a member
   When members are output to files, the corresponding CCSN of the member is assigned to the file.

   The following applies to the output information created by LMSCONV:
   When outputting member records to SYSOUT (also formatted) with the SHOW-ELEMENT statement, the CCS of the corresponding member is used. If SYSOUT is assigned to a file, the user must explicitly assign the desired character set to this file with /MODIFY-FILE-ATTRIBUTES.

   When outputting member records to SYSLST, no CSSN is interpreted. If SYSLST is assigned to a file, the user can explicitly assign the desired character set to this file with /MODIFY-FILE-ATTRIBUTES .

   Extracting an element into a SAM node file on Net-Storage can fail because the CCSN of the element cannot be converted into the NETCCSN of the node file. This can have several cause:

   1. An inappropriate CCSN is assigned to the element. In this case a suitable CCSN can be assigned with // MODIFY-ELEMENT-ATTRIBUTES.
   2. An unsuitable NETCCSN is stored in the file attributes for the element (can be seen in the output of // SHOW-ELEMENT TEXT-INFORMATION = * FILE-ATTRIBUTES). In this case, the node file into which the element is to be extracted must be assigned the appropriate NETCCSN with / MODIFY-FILE-ATTRIBUTES. The element can then be extracted by specifying FILE-ATTRIBUTES = * BY-CATALOG.
   3. No NETCCSN is saved for the element (e.g. because it was not originally a node file or because the SOURCE-ATTRIBUTES = * KEEP operand was not specified when the node file was added to the library), and the user's preset NETCCSN does not match CCSN. In general, the user attribute NET-CODED-CHARACTER-SET should be changed accordingly in this case. In individual cases, however, the same procedure can be used as in case b.

   If the output stream is reassigned to a library member by MODIFY-LOGGING-PARAMETERS, this member receives the CCSN “no code”.

   When outputting directories or other member information created by LMSCONV, the CCSN “no code” is always assumed.

4. Extending members and files with WRITE-MODE=*EXTEND
   If WRITE-MODE=*EXTEND is used, LMSCONV checks the CCS names of the source and target. If they do not match, processing is terminated with an error.