Special Characters in MFS Attributes

Issue

If you have used character literals to specify the values of MFS attributes, the resulting values will be different when you compile using ASCII from those that you obtain when compiling using EBCDIC. For example, the two code fragments below give the same results when compiling with the EBCDIC character set. When using ASCII, however, the first example will give different behavior: '{A' now translates as hexadecimal 7B41 rather than C0C1.

05 ATTRIBUTE-VARIABLES.
   10 CURSOR-ATTR          PIC X(2) VALUE '{A'. 
   10 ERROR-ATTR           PIC X(2) VALUE '{I'.
   10 OK-ATTR              PIC X(2) VALUE ' A'.
   10 PROT-ATTR            PIC X(2) VALUE ' 1'.

05 ATTRIBUTE-VARIABLES.
   10 CURSOR-ATTR          PIC X(2) VALUE X'C0C1'.
   10 ERROR-ATTR           PIC X(2) VALUE X'C0C9'.
   10 OK-ATTR              PIC X(2) VALUE X'00C1'.
   10 PROT-ATTR            PIC X(2) VALUE X'00F1'.

Resolution

To facilitate the migration of programs, you can specify at the level of the transaction or the system whether MFS attribute values have been coded using character or binary notation. (The value specified for the transaction definition overrides that for the system.)

Where you specify that the attribute values have been coded as character literals, Enterprise Server will automatically translate the values of MFS attributes to those that would be used if the program were compiled as EBCDIC. For example: the hexadecimal 7B41 value produced by assigning '{A' to an attribute and compiling with ASCII, will be converted to the correct C0C1 value. Where you specify that attribute values have been coded as binary data, Enterprise Server will take no action.

As an alternative solution, edit your programs to use x'nn' notation (as used in the second example above) instead of characters.