On Thu, Jan 15, 2015 at 12:31 AM, Timothy Sipples <[email protected]>
wrote:
>
> John McKown writes:
> >This might help people to convert to z/OS. Of
> >course, there is still that nasty EBCDIC
> >issue for any conversion.
>
> That's just not correct.
>
> z/OS imposes absolutely no requirement to use or to convert to EBCDIC.
> Zero, zip, nada. Store and manage everything in Unicode if you like. (Many
> do and do like.) Or Plutocode, or McKowncode. Choose whatever character
> encoding you like.
>
> Interoperating with EBCDIC-encoded data requires, well, interoperating with
> EBCDIC-encoded data, whether z/OS or another operating system manages and
> stores such data. z/OS provides excellent interoperation capabilities
> should you wish to use them. But such interoperation requirements exist, if
> they exist, no matter where you run.
>
I think I understand where you're coming from. But this is, in and of
itself, a "nasty EBCDIC" problem because code on z/OS generally _assumes_
that character data is encoded in CP-037 (historic batch?), or maybe
IBM-1047 (UNIX). And code from other systems such as Windows, UNIX, Linux,
Mac assume that character data is ASCII (and no, not exactly the same code
page, but "close enough" for the common Latin characters in English). One
way in which EBCDIC is "nasty", that I personally encountered, is that the
"control" versions of A..Z (ctrl-A through ctrl-Z) in ASCII are a simple
bit manipulation to get from the letter encoding to the corresponding
control encoding. To do the same in EBCDIC took a table look-up and a lot
of #define lines in C. The "ugliness" of this is that the C code I was
using looked like:
#define control_character_bit 0x40 /* 0x000000, must be off. */
#define CTRL(c) ((c) & control_character_mask)
select (c)
{
case CTRL('A'):
...
break;
case CTRL('C'):
...
break;
// and so on
}
With ASCII, the CTRL('C') is a calculated value of the literal 'C', which
is acceptable to the C compiler as the "case" operand. On z/OS, I had to
replace all the CTRL('...') with something like CTRL_??? and then #define
each CTRL_A through CTRL_Z with the specific EBCDIC values (which are all
over the place, not neatly organized). Was this really all that difficult?
No. But is was an "ugliness" and an impediment to the port. And I must now
maintain even more differences in the z/OS version and the "normal" UNIX
version of this code. No, I cannot change the upstream UNIX version - it is
GNU software. Can I request that they change their standards? <giggle>
<giggle> <chortle>. They likely wouldn't do it because an older version of
this same software actually used my method (individual #define statements)
and they converted away from it to the one which doesn't work on z/OS with
EBCDIC. Possibly because it is fewer lines of code to maintain (2 vs. 26).
That is why I called EBCDIC "ugly". And, to my shame?, I will admit that I
_like_ Java and the fact that it uses UNICODE internally with the external
representation be specifiable by the programmer or by the user. But
historic z/OS code doesn't do this. Nor historic UNIX code. Both _assume_
things about the bit encodings (such as A<B<C...<Z). Again, this is not
directly an EBCDIC vs. ASCII problem, it is a short sighted(?) programmer
problem. Or, more likely, a programmer under a deadline which doesn't allow
for time to consider "strange stuff" like character encodings. The concern
for this problem is become more apparent with increasing multilingual,
multinational needs.
Ah, I'm almost glad that I'm 62 and likely to be forcibly retired due to
the company I work for going to a "cloud sourced" ?aaS outside vendor,
eliminating the z/OS system here and eventually most of the
Windows/AIX/Linux servers (a perfect company: 99% managers, 1% other
employees, all else various vendors). At 62, the likelihood of being hired
somewhere else is very low.
--
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity. In other words, eschew obfuscation.
111,111,111 x 111,111,111 = 12,345,678,987,654,321
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
