On 2023-06-06 12:02 PM, Paul Gilmartin wrote:
A couple of additional problems you can encounter:
- code that ASSumes that lower case alphabetic characters collate
higher than upper case alphabetic characters;
- code that ASSumes that all lower case alphabetic characters
are in a contiguous range of hex values (similar for upper case);
- code that ASSumes that digits collate lower than alphabetic
characters.
Does the Enhanced ASCII support cover all those problems?
Have you a counterexampl?
Some years ago, I was investigating porting a well-known database
package that shall remain nameless to z/OS USS, and found that the code
had a lot of the above.
Did you compile it in Enhanced ASCII mode? Were the data EBCDIC or ASCII?
The key phrase above is "I was investigating porting". I didn't actually
do the port. Had I done the port, the data that the database would have
been handling would have been EBCDIC (yeah, I don't love EBCDIC either,
but when in Rome...). I decided the dog smelled bad, so I didn't adopt it.
I don't think Enhanced ASCII would do anything for any of the problems I
listed. On the other hand, one could use functions such as isalpha(),
islower() and isdigit() to automatically do things properly.
This are the sort of thing I am referring to:
if (mychar >= 'a' && mychar <= 'z') {
do something based on mychar being lower case alphabetic;
}
This fails on EBCDIC data because there are characters that are not
alphabetic characters between 'a' and 'z'.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
