Advanced use of ALTSEQ in DFSORT includes building full 256-byte translation tables for complete code page conversion (such as EBCDIC to ASCII), using the same ALTSEQ definition for both sort collation and character translation in INREC or OUTREC, translating only selected fields while leaving the rest of the record unchanged, and reusing a long ALTSEQ table across jobs by storing it in a shared member or procedure. This page builds on the basic ALTSEQ page: it covers full translation tables, common pitfalls, combining collation and translation, and how to maintain and include large ALTSEQ definitions.
For code page or character set conversion (e.g. EBCDIC to ASCII), every possible byte value (0–255) can appear in the data. If your ALTSEQ CODE= table omits some values, those bytes may be left untranslated or may be handled in a product-specific way. To get predictable results, define a mapping for all 256 bytes. The table is a list of (input_hex, output_hex) pairs: for each input byte value, the output byte value is given. You can generate the list from an authoritative EBCDIC-to-ASCII (or other) mapping table published by IBM or your platform vendor. Keep the definition in a separate dataset member so you can include it in multiple jobs and update it in one place.
A common advanced use is converting EBCDIC data to ASCII for transfer to non-mainframe systems. You define ALTSEQ CODE= with 256 pairs mapping each EBCDIC byte to its ASCII equivalent. Then in INREC or OUTREC you specify TRAN=ALTSEQ for the field(s) or the whole record that should be converted. Control characters, spaces, digits, letters, and national characters all need correct mappings; missing or wrong pairs can cause downstream systems to misinterpret the data. Use a standard mapping (e.g. IBM code page documentation) and test with sample data that includes spaces, punctuation, and any special characters your application uses.
The same ALTSEQ definition can serve two roles in one job: as the alternate collating sequence for the sort (so key comparison uses your mapping) and as the table for TRAN=ALTSEQ when building records. For example, you might want output in ASCII but also want the sort order to follow ASCII character order. Define the ALTSEQ table once; reference it for the sort (per your product’s syntax) and use TRAN=ALTSEQ on the appropriate OUTREC (or INREC) fields. That way you do not maintain two separate tables and the behavior is consistent.
In INREC or OUTREC you specify the record layout as a series of segments (position, length, and optional modifiers). Attach TRAN=ALTSEQ only to the segment(s) that represent the field(s) you want to translate. Other segments are copied as-is. For example, you might translate only bytes 41–80 (a name field) and leave bytes 1–40 (binary or already-ASCII data) unchanged. The exact syntax for attaching TRAN=ALTSEQ to a segment (e.g. whether it applies to the previous segment or a following one) depends on your DFSORT version; see the INREC/OUTREC section of the manual.
A full 256-byte table makes the ALTSEQ statement long. To avoid repeating it in every job, put the ALTSEQ statement (and optionally other control statements) in a separate dataset member. In the JCL, point SYSIN to a concatenation that includes that member, or use a procedure that contains the member. When the mapping changes (e.g. a new code page), you update the member once and all jobs that include it get the new table. Document the member name and the fact that it defines ALTSEQ so that maintainers know where to look.
If the ALTSEQ table does not define a byte value, that byte may pass through unchanged or may be treated in an undefined way. In EBCDIC-to-ASCII conversion, control characters (e.g. X'00'–X'3F') and high bytes (e.g. X'80'–X'FF') often need explicit mappings; otherwise binary data or national characters can be wrong. Another pitfall is reversing the pairs (output_hex, input_hex instead of input_hex, output_hex), which produces incorrect translation. Verify a few known characters (e.g. space, letter A, digit 0) in the output and spot-check the full range if the data is critical.
Applying TRAN=ALTSEQ to large fields or entire records adds work per record. For very large files, the cost is usually acceptable, but if you only need to convert a few columns, specify TRAN=ALTSEQ only on those segments to reduce the amount of data translated. Using ALTSEQ as the collating sequence can also affect sort performance slightly compared to the default sequence; for most jobs the difference is small.
Imagine a big secret decoder sheet: for every possible squiggle (all 256 of them), you write down what it should become in the new alphabet. When the sorter builds a new card, it uses your sheet to change only the parts you mark. If you forget to write down what one squiggle means, that squiggle might not change and could look wrong. So for a full new alphabet, you need to write down every squiggle. And you can use the same sheet so the sorter both sorts by the new alphabet and writes the new alphabet on the card.
1. Why would you define all 256 byte values in an ALTSEQ CODE= table?
2. Can you use ALTSEQ for both sort order and translation in the same job?
3. What is a common pitfall when building an EBCDIC-to-ASCII ALTSEQ table?
4. How can you avoid duplicating a long ALTSEQ table in multiple jobs?
5. When translating only part of a record with TRAN=ALTSEQ, what must you specify correctly?