At 05:06 PM 98/07/06 -0400, you wrote:
>I know we beat this subject to death the last time it came up,
>but I'm having a slightly different problem now.  I just added
>a new field to a detail data set that is defined as Z8 in Image
>and is a linked from the detail data set to a manual master data
>set.  The "normal" value for this field will be zero.  When I
>added the data field to the detail data set using Adager, it
>added a record to the master data set with a search value of
>0 (zero, unsigned), and initialized the data field in the detail
>set to 0 (zero, unsigned).  So far, so good.
>
>Now, I try my application (COBOL) where we have defined the
>data field as S9(8) DISPLAY.  Moving zeroes to the data field
>via COBOL results in "+00000000" in the data field, and an
>error of 110 on the ensuing DBPUT, which is translated as
>"No chain head (master entry) for path 10 in set 50", which
>is the new data field.
>
>Aha!  Remembering the previous discusion concerning Image
>and ODBC and Image/SQL, I know that 0 (zero, unsigned) is a
>different value than +0 (zero, signed).  No problem, says I,
>I will simply add another default master entry using QUERY and
>entering +0 (zero, signed) as the search item value. QUERY does
>recognize this as being different from 0 (zero, unsigned), but
>it doesn't work; that is, I still get the same error on DBPUT.
>I thought that since S9(8) DISPLAY in COBOL defaults to SIGN IS
>TRAILING and OVERPUNCH, I would try a 0+ as the QUERY input, but
>QUERY rejects that as non-numeric.
>
>So, what do I try next?
>

With all due respect, what you should have done in the first place - define
this new field as an X-type field.

In fact, while donning my flame suit, please let me this startling
assertion - in my opinion, one should only define X  or I fields in an
Image database.

It makes no sense (to me anyway) to define any other type of field - and
here is why:

A packed field (P) is cumbersome and unnatural. It is only supported
natively in Cobol and RPG - as well as 4GL languages. It is cumbersome with
Image because it is not possible to define a 4-digit or 5-digit packed
field without specifying an additional slack byte in front of the field.
Most simply define the field larger to conform with the Image quantum of
2-bytes.

A real number could possibly be acceptable, but in most commercial
environments, not very practical - and cannot easily be accomodated with
COBOL.

Can someone explain the point of a U-type field - other than to bewilder
and confuse ? Unless your major data entry vehicle is QUERY, U-type fields
make no sense.

J and K (variations of I) are useless - unless of course, as above, you are
relying on QUERY to perform data validation on your behalf.

A Z-type field again serves no useful purpose except to get you in the
situation you have just described.

You should realize that it is your program that will define your data and
validate it - not Image.

As someone once said (and I forget who, although I agree) Image is a space
reservation system - not a data validation system.

Unfortunately, many treat it as the latter and pay the price - as evidenced
by Jim's dilemma, and recent lengthy discussions of the problems with Z/P
fields and ODBC client-server processes.

Anyway, that's my $0.02 worth.

---------------------------------------------------------------------------
Gilles Schipper
GSA Inc.
HP3000 & HP9000 System Administration Specialists
300 John Street, Box 87651   Thornhill, ON Canada L3T 7R4
Voice: 905.889.3000     Fax: 905.889.3001
Internet:  [log in to unmask]
---------------------------------------------------------------------------