I haven't actually looked at using that table for alternate sequencing, but it's definitely the right idea.
As for any applications using this scheme, there may be some logic issues involved when assigning/creating new IDs unless they're always assigned by a programmed function.
If assigned by program, I would probably use actual 32-bit unsigned (4-byte, 8 hex digits) values and simply convert the hex digits back and forth with the cvtch() and cvthc() functions. I'd do any incrementing on the 32-bit integer and then just convert the 4-bytes to hex characters.
Yes,By assuming Keyword ALTSEQ(QSYS/QASCII) in LF can only solve the sort sequence problem,How to value the KEYID,I think Tom’s say is a right way.
So others about the sequence like these:
1: The table which you use is decided by your pratical applications.
This table QASCII is tranfer the EBCDIC code to ASCII code,because the char&numeric sort sequence is reversely,so the table QASCII was choosed.
2: If some of the keylist don’t want to change the sort sequnce, the keyword NOALTSEQ(a key field-level keyword) is assumed to the specific fields.