Your messages clarified my issue and actually assured me that the solution I'd
suggested is correct, so I would like to brief you.
It is apparent that IBM chose to mark the end of line with NL and not with any
of LF or CRLF. That on itself is probably a correct decision and probably what
the standard should have been to begin with. The problem is that in the C
language convention, the escape sequence \n has subtle double meaning. It
means LF but it also contains within it the semantics of NL.
When we do
printf ("some text \n");
it will work correctly on all platforms and nobody would ever notice any
problem. it will produce on EBCDIC
some text NL
and on ASCII platforms
some text LF
or
some text CRLF
But when we issue a pattern matching (I'll use Perl syntax for brevity)
if ($text =~ /some text \n/)
the \n is translated by convention to LF and the EBCDIC based pattern matching
will fail to match!
So the solution should be to somehow (optionally) dictate to the package that
\n is NL and not LF. I've requested that such option would be implemented so I
can use it.
ZA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
