MI400 digest, Vol 1 #119 - 5 msgs

Send MI400 mailing list submissions to
        mi400@midrange.com

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.midrange.com/cgi-bin/listinfo/mi400
or, via email, send a message with subject or body 'help' to
        mi400-request@midrange.com

You can reach the person managing the list at
        mi400-admin@midrange.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MI400 digest..."


Today's Topics:

   1. Re: base64 encoder/decoder for EBCDIC systems (Simon Coulter)
   2. RE: base64 encoder/decoder for EBCDIC systems (Jim Langston)
   3. Re: base64 encoder/decoder for EBCDIC systems (Mark Waterbury)
   4. RE: base64 encoder/decoder for EBCDIC systems (Jim Langston)
   5. Re: base64 encoder/decoder for EBCDIC systems (Leif Svalgaard)

--__--__--

Message: 1
Date: Thu, 28 Mar 02 09:12:22 +1100
From: "Simon Coulter" <shc@flybynight.com.au>
To: mi400@midrange.com
Subject: Re: [MI400] base64 encoder/decoder for EBCDIC systems
Reply-To: mi400@midrange.com


Hello Jim,

You wrote:
>return(((cc >= 33) && (cc <= 60)) || ((cc >= 62) && (cc <= 126))) AND ...
>Basically, that is looking for any "standard" type character.  ASCII

I think that was the original appenders point.  That this code is full of
ASCII specific assumptions.  So it won't work on an EBCDIC machine where
the character representation is different.  It is typical Unix-weenie,
ASCII-specific, C code written by people with no idea that anything else
exists (or being gracious, it may have been optimized for an ASCII
environment by someone who did consider the ramifications but somehow I
doubt it).

The above code returns TRUE if the character is a 'displayable character'
(i.e., printable) in ASCII.  It ain't going to work on an EBCDIC machine
where the 'displayable characters' are scattered throughout a 256
character range and where most of the useful characters are above 127.
Nor does it account for the gaps that appear between groups of alphabetic
characters in EBCDIC -- which are there for a reason.  Nor does it
consider different codepages and character sets where characters like #
and $ may have different representations.

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------


--__--__--

Message: 2
From: Jim Langston <jlangston@celsinc.com>
To: "'mi400@midrange.com'" <mi400@midrange.com>
Subject: RE: [MI400] base64 encoder/decoder for EBCDIC systems
Date: Wed, 27 Mar 2002 15:42:23 -0800
Reply-To: mi400@midrange.com

True, and although I don't know Base64 encoding, what I am assuming is
happening is that any character that is NOT displayable by an ASCII
character is encoded by it's byte value.

I would be interested to know two things to get this to work on EBCDIC.

1. What would happen if you encoded EVERY byte value, Text displayable or
not?  Would it still decode properly?
2. How difficult would it be to determine the range of EBCDIC values that
are Text displayable?  I know they are scattered, and the IF statement could
get quite complex, but it should be very doable.

The assumption being, however that what you are encoding in EBCDIC Base64
will be decoded into EBCDIC.  Trying to decode into ASCII would give you
garbage.  The whole purpose of Base64 encoding, if I remember my history
correctly, was for ANY type of data that any machine could make to be
represented by ASCII characters and hence moved from various different
platforms without loosing data.

The Base64 encoding we are taking samples from here is the ASCII
implementation of it.  Encode ASCII/Decode ASCII.  It will obviously have to
be changed for the EBCDIC character set.

Then consider what will happen when this code was written and someone looks
at it and tries to implement it on some other character set like ASCII.

"It is typical AS/400-weenie, EBCDIC-specific, RPG code written by people
with no idea that anything else
exists (or being gracious, it may have been optimized for an EBCDIC
environment by someone who did consider the ramifications but somehow I
doubt it)."

Regards,

Jim Langston

-----Original Message-----
From: Simon Coulter [mailto:shc@flybynight.com.au]

Hello Jim,

You wrote:
>return(((cc >= 33) && (cc <= 60)) || ((cc >= 62) && (cc <= 126))) AND ...
>Basically, that is looking for any "standard" type character.  ASCII

I think that was the original appenders point.  That this code is full of
ASCII specific assumptions.  So it won't work on an EBCDIC machine where
the character representation is different.  It is typical Unix-weenie,
ASCII-specific, C code written by people with no idea that anything else
exists (or being gracious, it may have been optimized for an ASCII
environment by someone who did consider the ramifications but somehow I
doubt it).

The above code returns TRUE if the character is a 'displayable character'
(i.e., printable) in ASCII.  It ain't going to work on an EBCDIC machine
where the 'displayable characters' are scattered throughout a 256
character range and where most of the useful characters are above 127.
Nor does it account for the gaps that appear between groups of alphabetic
characters in EBCDIC -- which are there for a reason.  Nor does it
consider different codepages and character sets where characters like #
and $ may have different representations.

Regards,
Simon Coulter.

--__--__--

Message: 3
From: "Mark Waterbury" <mark.s.waterbury@worldnet.att.net>
To: <mi400@midrange.com>
Subject: Re: [MI400] base64 encoder/decoder for EBCDIC systems
Date: Wed, 27 Mar 2002 16:56:32 -0700
Reply-To: mi400@midrange.com

Hi, Jim (et al):

Maybe I am "missing something" here, but, it seems to me that
you could simply write a "wrapper" to call QDCXLATE to
translate from EBCDIC to ASCII, then invoke the Base64 code,
then at the other end, convert from Base64 back to ASCII, then,
(if necessary), invoke QDCXLATE to translate it back to EBCDIC
again (if you are running on an AS/400 or iSeries or IBM mainframe
at the other end, that needs EBCDIC).

So, what's the "big deal"? Why do you want to "mess about"
trying to create a special EBCDIC-only version of Base64,
which will be a non-standard version of base64 anyway?

Perhaps someone can "step back" to look at the "big picture"
and tell me what it is you are trying to do, and why you think
you need to use base64 in the first place.

Regards,

Mark S. Waterbury

----- Original Message -----
From: "Jim Langston" <jlangston@celsinc.com>
To: <mi400@midrange.com>
Sent: Tuesday, March 26, 2002 9:56 AM
Subject: RE: [MI400] base64 encoder/decoder for EBCDIC systems


> Yes, there is a lot of C specific code in that equation.  I can tell you
> what that specific code is doing if you want.
>
> return(((cc >= 33) && (cc <= 60)) || ((cc >= 62) && (cc <= 126))) AND ...
> Basically, that is looking for any "standard" type character.  ASCII
>
> Basically, that is taking any character between ASCII 33 through 126 with
> the exception of 61 which is equals.  Equals is a special character in
> Base64.  Anything 32 and lower are control characters and not part of the
> standard displayable alphabet.
>
> if ((dd == '\n') || (dd == '\r') || (dd == '\0')) {;)
>
> \n is newline, carriage return.  \r is return.  \0 is NULL.  Looking for
end
> of line, terminated either by Carriage Return, Line Feed, or as a NULL
> terminated string.
>
> That code should be convertible to EBCDIC as long as you have an EBCDIC
> table to look at.
>
> Any more C specific questions you have I will answer if I know (or make up
> an answer if I don't <g> j/k ).
>
> You can e-mail me either through this list or directly to me at
> jlangston@celsinc.com
>
> Regards,
>
> Jim Langston
>
> -----Original Message-----
> From: shahar mor [mailto:shahar_mor@yahoo.com]
>
>  Hi,
> Thanks for the reply, i knew you that base 64 had no problem with EBDIC
(at
> least this :)), only the c source contanis many questions that are ascii
> dependent (something like  return(((cc >= 33) && (cc <= 60)) || ((cc >=
62)
> && (cc <= 126))) AND  something like this if ((dd == '\n') || (dd == '\r')
> || (dd == '\0')) {;) so we need to prot it carefully this is doable
however
> i tried to make it shorter.
> Thanks again for your reply
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
> or email: MI400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
>


--__--__--

Message: 4
From: Jim Langston <jlangston@celsinc.com>
To: "'mi400@midrange.com'" <mi400@midrange.com>
Subject: RE: [MI400] base64 encoder/decoder for EBCDIC systems
Date: Wed, 27 Mar 2002 16:10:07 -0800
Reply-To: mi400@midrange.com

Mark,

The only problem with that would be getting an ASCII Base64 converter to
work on the AS/400.  Some of the ASCII characters it would be converting to
would not be text in EBCDIC, and not sure how they would turn out.

It was not my original question, but my assumption is that someone is
writing and e-mail attachment program for the AS/400, which uses Base64
Encoding.

Regards,

Jim Langston

-----Original Message-----
From: Mark Waterbury [mailto:mark.s.waterbury@worldnet.att.net]

Hi, Jim (et al):

Maybe I am "missing something" here, but, it seems to me that
you could simply write a "wrapper" to call QDCXLATE to
translate from EBCDIC to ASCII, then invoke the Base64 code,
then at the other end, convert from Base64 back to ASCII, then,
(if necessary), invoke QDCXLATE to translate it back to EBCDIC
again (if you are running on an AS/400 or iSeries or IBM mainframe
at the other end, that needs EBCDIC).

So, what's the "big deal"? Why do you want to "mess about"
trying to create a special EBCDIC-only version of Base64,
which will be a non-standard version of base64 anyway?

Perhaps someone can "step back" to look at the "big picture"
and tell me what it is you are trying to do, and why you think
you need to use base64 in the first place.

Regards,

Mark S. Waterbury

--__--__--

Message: 5
From: "Leif Svalgaard" <leif@leif.org>
To: <mi400@midrange.com>
Subject: Re: [MI400] base64 encoder/decoder for EBCDIC systems
Date: Wed, 27 Mar 2002 18:11:54 -0600
Reply-To: mi400@midrange.com

couple of things wrong with this. First the translation
from E to A and back does not give the same result (depending
a bit on code pages), seconds, base64 was designed to
encode arbitrary binary data for which even the concept
of translating E to A doesn't make sense.

----- Original Message -----
From: Mark Waterbury <mark.s.waterbury@worldnet.att.net>
To: <mi400@midrange.com>
Sent: Wednesday, March 27, 2002 5:56 PM
Subject: Re: [MI400] base64 encoder/decoder for EBCDIC systems


> Hi, Jim (et al):
>
> Maybe I am "missing something" here, but, it seems to me that
> you could simply write a "wrapper" to call QDCXLATE to
> translate from EBCDIC to ASCII, then invoke the Base64 code,
> then at the other end, convert from Base64 back to ASCII, then,
> (if necessary), invoke QDCXLATE to translate it back to EBCDIC
> again (if you are running on an AS/400 or iSeries or IBM mainframe
> at the other end, that needs EBCDIC).




--__--__--

_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) digest list
To post a message email: MI400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
or email: MI400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.



End of MI400 Digest