HP3000-L Archives

November 2005, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Denys Beauchemin <[log in to unmask]>
Reply To:
Date:
Sat, 26 Nov 2005 15:39:02 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (89 lines)
You are dealing with what is usually referred to as an overloaded dataset.
What this means is that your X40 field is storing data that is not
"characters."  IMAGE does absolutely no data checking when you store things
in it, which can fool a lot of programs.  For instance, if you use Query or
some similar tool to look at the data contained in that dataset, I believe
you will see that it can't handle it.  Query relies on the schema (root
file) of the database to figure out what the data should look like.  So when
it sees a nice X40, it figures it's dealing with 40 printable characters,
when in fact that field contains gibberish.

The COBOL program understands that field.  If you look at the data division
in the COBOL source, you will probably find that the field is either
redefined from a string of 40 characters to one or (probably) more sub-items
with a PIC S9(x) COMP-3 or something similar.  So your program gets that 40
character buffer and is able to extract the required information out of it.

However, your ODBC server does not have the secret decoder ring to pass the
data properly to the client.  It may well be that the first three bytes are
indeed characters but as soon as the ODBC driver see a binary 0, which is
very possible when you look at a packed field, it thinks that's all there is
and it stops decoding the X40 right away.

What you need to do is find out if your ODBC driver can have a file that
tells it how to decode a dataset.  It would help us help you if you could
tell us which ODBC solution you are using and also maybe post the data
division from the COBOL program that addresses this field.

Denys

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Peter Osborne
Sent: Friday, November 25, 2005 4:27 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] Packed Fields

It seems the problem I am encountering is with the ODBC server i'm using. I 
only get the first 3 bytes out of the field, seems the NULL's are
terminating 
the record. I'll have to go from here.

Thanks all who replied,
Pete

On 25 November 2005 2:41 pm, Wirt Atmar wrote:
> Pete asks:
> > I'm looking at a field in a dataset. It's an X40 field but it seems that
>
> the
>
> >  data stored in it is server integers "packed" by a Cobol program. I've
>
> used
>
> >  the program to change the values that are stored in this field and the
>
> data
>
> >  is indeed changing but I cannot figure out how the data is actually
>
> stored.
>
> >  Is there a formula on how one would unpack a field that has been packed
> > by
>
> a
>
> >  Cobol program?
>
> I would expect that the data is packed in the standard manner: each nibble
> (4 bits) in the pattern is a binary encoded decimal ranging from 0
("0000")
> to 9 ("1001"), except for the last nibble, which is the sign of the
number.
> If no sign value is specified, the last nibble is the hex value"F"
> ("1111"). Otherwise, it's a "C" (credit; "1100") for a positive value, "D"
> (debit; "1101") for a negative value.
>
> Wirt Atmar
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2