Recently I got myself into some trouble with Query and Cobol and a Z-type 
data item.  We've used the Z-type data item for quite some time to store 
unsigned numeric data with no problems.  Then along comes ODBC and SQL 
and it doesn't like unsigned integers, it insists on putting a sign 
overpunch on every value we store in the Z-type data item.  So when 
we read the data with a Cobol data item defined as PIC 9(n), the 
sign overpunch wasn't converted and we ended up with "funny" 
characters (like "{" for zero) showing up on our Vplus screens. 
No problem, said I, we'll just change the Cobol definition to 
PIC S9(n) and sure enough, that cured our display problems.  

That, however, introduced another, more interesting problem.  We added 
data using the S9(n) definition, and then some reports that read 
the data by the Z-type data item (it's a secondary key) started 
"malfunctioning" by not showing all the data (the data item is 
a Pick Number which links all products being picked this week 
for a given customer).  Because some of the data had been put 
into the data base using the unsigned (PIC 9(n)) definition, a 
DBFIND in the Cobol program using the signed (PIC S9(n)) 
definition would not find the unsigned key values.

I solved this by dumping the set, converting the data from unsigned 
to signed, and reloading the data set.

The real kicker to this whole thing is that Query was not at all 
fazed by the signed/unsigned definition.  That is, when debugging 
the Cobol program I used Query to see how many records should have 
been reported (FIND <Z-Type data item> = <integer value>) and it 
worked okay; that is, it found all the records whether or not 
they were signed or unsigned.  A "Report All" would correctly 
show the data values as signed or unsigned (for instance, 975 and 
97E), but the FIND command retrieved them all.

My question is: How come the Query FIND command worked and the  
DBFIND called from Cobol did not?  I mean, I can understand 
that a 975 unsigned is a different bit pattern than 975 signed, 
and the Cobol program works okay now that all the data is 
signed, but I would expect Query to do the same thing as the 
Cobol program did.  After all, they're both using DBFIND, aren't 
they?

Jim Phillips                            Manager of Information Systems
Voice: (330) 527-2124                   Therm-O-Link, Inc.
  Fax: (330) 527-2123                   PO Box 285; 10513 Freedom St.
Email: [log in to unmask]       Garrettsville, Ohio  44231