DB2 and HIGH-VALUES

didn't see anything recently on the group.

we're still having problems with HIGH-VALUES with our combination of
390/NT/*nix versions (6,7,8) and the fact that most everything
eventually gets done by COBOL programs on 390.  these programs, in
one way or another go back to the '70s.  lots and lots of
HIGH-VALUES logic.

from what my colleagues say, who are battling with IBM on the issue,
IBM just says "don't put a non-printable character in the data".

i find this astounding, given how COBOL programs typically behave.

questions:  have others gotten the same answer from IBM, and if so
how much re-writing have you endured to stop using HIGH-VALUES
(or LOW-VALUES, for that matter)?

thanks,
robert

gnuoytr@rcn.com (robert) wrote in message news:<da3c2186.0405110533.46832e8c@posting.google
.com>...
> didn't see anything recently on the group.

oops. would help to mention the context (forgot which group i was on)
DB2

>
> we're still having problems with HIGH-VALUES with our combination of
> 390/NT/*nix versions (6,7,8) and the fact that most everything
> eventually gets done by COBOL programs on 390.  these programs, in
> one way or another go back to the '70s.  lots and lots of
> HIGH-VALUES logic.
>
> from what my colleagues say, who are battling with IBM on the issue,
> IBM just says "don't put a non-printable character in the data".
>
> i find this astounding, given how COBOL programs typically behave.
>
> questions:  have others gotten the same answer from IBM, and if so
> how much re-writing have you endured to stop using HIGH-VALUES
> (or LOW-VALUES, for that matter)?
>
> thanks,
> robert

It would also help if you gave us a clue as to what type of problems you hav
e.

Certainly using HIGH-VALUES, LOW-VALUES or any other "non-printable" charact
ers
is fully supported in COBOL (and their binary values are supported in IBM's
DB2).  HOWEVER< trying to *treat* them as "visible" would certainly lead to
"bad" results.

Again, what problem are you having?

--
Bill Klein
wmklein <at> ix.netcom.com
"robert" <gnuoytr@rcn.com> wrote in message
news:da3c2186.0405111221.eb37ce1@posting.google.com...
> gnuoytr@rcn.com (robert) wrote in message
news:<da3c2186.0405110533.46832e8c@posting.google.com>... 
>
> oops. would help to mention the context (forgot which group i was on)
> DB2
> 

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:<bpboc.16573$Hs1.1347@
newsread2.news.pas.earthlink.net>...
> It would also help if you gave us a clue as to what type of problems you have.[/co
lor]

DB2 insists on "translating" both when moving from one platform to
another.  sometimes we have to use 9F on NT to get FF on 390,
other times 3F, other times 1A.  there is no earthly reason to
translate x00 or xFF, especially knowing that oh, 95%, of 390
DB2 talks to COBOL code which depends on HIGH-VALUES and LOW-VALUES
to function.

anyone trying to pass data from NT WebSphere, for instance, to a
390 COBOL stored procedure will have hit this problem.  i can't
believe we're the only ones doing that.

it makes no sense.

>
> Certainly using HIGH-VALUES, LOW-VALUES or any other "non-printable" chara
cters
> is fully supported in COBOL (and their binary values are supported in IBM'
s
> DB2).

supported, in what way?  unless xFF && x00 moves transparently, it ain't.
only FOR BIT DATA, so far as i know; which renders the column useless
unless one wishes to translate all data.

users ought to be able set a switch for these two particularly vexing
values:  those needing COBOL access on any platform and passing data
across platforms should be able to say --
"leave these hex values ALONE!!!"

HOWEVER< trying to *treat* them as "visible" would certainly lead to
> "bad" results.
>
> Again, what problem are you having?
>
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
> "robert" <gnuoytr@rcn.com> wrote in message
> news:da3c2186.0405111221.eb37ce1@posting.google.com... 
>  news:<da3c2186.0405110533.46832e8c@posting.google.com>... 

How are you "moving" the data from one platform to another?

--
Bill Klein
wmklein <at> ix.netcom.com
"robert" <gnuoytr@rcn.com> wrote in message
news:da3c2186.0405111848.4abaa9e9@posting.google.com...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:<bpboc.16573$Hs1.1347@newsread2.news.pas.earthlink.net>... 
have.
>
> DB2 insists on "translating" both when moving from one platform to
> another.  sometimes we have to use 9F on NT to get FF on 390,
> other times 3F, other times 1A.  there is no earthly reason to
> translate x00 or xFF, especially knowing that oh, 95%, of 390
> DB2 talks to COBOL code which depends on HIGH-VALUES and LOW-VALUES
> to function.
>
> anyone trying to pass data from NT WebSphere, for instance, to a
> 390 COBOL stored procedure will have hit this problem.  i can't
> believe we're the only ones doing that.
>
> it makes no sense.
> 
characters 
>
> supported, in what way?  unless xFF && x00 moves transparently, it ain't.
> only FOR BIT DATA, so far as i know; which renders the column useless
> unless one wishes to translate all data.
>
> users ought to be able set a switch for these two particularly vexing
> values:  those needing COBOL access on any platform and passing data
> across platforms should be able to say --
> "leave these hex values ALONE!!!"
>
>  HOWEVER< trying to *treat* them as "visible" would certainly lead to