× 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.



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



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.