× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Richard,

        I had already solved the x2c() issue another way. .(See begining of
part 2 thread).   The problem is that while the message is intact in the CGI
program that processes it, a copy is forwarded via a socket connection to a
FreedBSD (Unix) box for additional processing and that copy is NOT intact.
To prepare that transmission I obviously have to put the message back into
ASCII before writing it to the socket.. Since the xlate table looks right,
and the socket should be transparent I am not sure where the braces are
getting lost or what the issue is yet....

        By the way it's not just the [], also saw about 5 other characters
get corrupted, like the ^ and  ! and |.......

        Thks for your time.
        JMS...



----- Original Message -----
From: "Rich Duzenbury" <rduz@westernmidrange.com>
To: <web400@midrange.com>
Sent: Saturday, November 30, 2002 12:37 AM
Subject: Re: [WEB400] Stuck in unesacpe (Part 2)


> I ran a sample conversion from codepage 37 to codepage 437, and the left
> and right brace characters come out as 0x5B and 0x5D, as you suggest they
> should.  Same for codepage 819.
>
> I made a small html file with the braces, and it shows up in the browser
> just fine.  Hmmm.
>
> OK, so I re-read the description of your problem.  Looks like there is a
> problem with the x2c routine.
>
> It relies on the fact that in ASCII, the numbers 0-9 fall before the
> letters.  In EBCDIC, the opposite is the case, the numbers fall after the
> letters.  A small change to the logic should get it working again:
>
> char x2c(char *what)
> {
>    register char
> digit;
>
>    digit = ((what[0] >= 'A' && what[0] <= 'F')
> ?
>                 ((what[0] & 0xdf) - (int) 'A') + 10 : // Calculate for
> A-F
>                 (what[0]-'0'));                       // Calculate for
> 0-9
>    digit *=
> 16;
>    digit +=((what[1] >= 'A' && what[1] <= 'F')
> ?
>                 ((what[1] & 0xdf) - (int) 'A') + 10 : // Calculate for
> A-F
>                 (what[1]-'0'));                       // Calculate for
> 0-9
>
>    return(digit);
>
> }
>
>
> OK, the braces seem to come out ok now.  I'm suspicious of the 'bitwise
> and' nonsense.  Why on earth is this routine stripping bit five?  I'd
> consider removing it:
>
> char x2c(char *what) {
>    register char digit;
>
>    digit = ((what[0] >= 'A' && what[0] <= 'F') ?
>                 (what[0] - (int) 'A') + 10 : // Calculate for A-F
>                 (what[0] - '0'));            // Calculate for 0-9
>    digit *= 16;
>    digit +=((what[1] >= 'A' && what[1] <= 'F') ?
>                 (what[1] - (int) 'A') + 10 : // Calculate for A-F
>                 (what[1] - '0'));            // Calculate for 0-9
>
>    return(digit);
> }
>
> At 10:20 PM 11/29/02, you wrote:
> >Rich,
> >
> >             Good idea but still no joy !!  With QUSRSYS/QTCPASC.......
> >
> >         JMS...
> >
> >----- Original Message -----
> >From: "Rich Duzenbury" <rduz@westernmidrange.com>
> >To: <web400@midrange.com>
> >Sent: Friday, November 29, 2002 10:22 PM
> >Subject: Re: [WEB400] Stuck in unesacpe (Part 2)
> >
> >
> > > At 08:55 PM 11/29/02, you wrote:
> > > >Well,
> > > >
> > > >         New routine works:  But I am loosing the Left [ and Right ]
when
> >I
> > > >pass them through to the server app.. Checked the ccsid and it is set
to
> >37.
> > > >for the HTTP Job... Translate is done with ...
> > > >
> > > >         QDCXLATE(fdlen, ptr, "QASCII    ", "QSYS      ");
> > > >
> > > >             The table QASCII is 0x4a to 0x58 and 0x5a to 0x5D Which
is
> >right
> > > >...
> > > I think most recent web browsers are codepage 819 so I suggest you use
> > > iconv api.  If that's not an option, I seem to remember somebody
saying
> > > that table QTCPASC was a bit better than QASCII.
> > >
> > >
> > > _______________________________________________
> > > This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> > > To post a message email: WEB400@midrange.com
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> > > or email: WEB400-request@midrange.com
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/web400.
> > >
> >
> >_______________________________________________
> >This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> >To post a message email: WEB400@midrange.com
> >To subscribe, unsubscribe, or change list options,
> >visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> >or email: WEB400-request@midrange.com
> >Before posting, please take a moment to review the archives
> >at http://archive.midrange.com/web400.
>
> Regards,
> Rich
>
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> or email: WEB400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.