Since we are now in the "guessing" phase, even though I know nothing about
QTP, I will wager a guess anyway.
Unsigned zoned decimals are not supposed to have a sign. Signed zoned
decimals are supposed to always have a sign. An unsigned "1" is not the
same as a signed "+1". If you have signed data in an unsigned field, this
is already an undefined state. The folks writing QTP needed to do
something when they encounter this, and they chose to display it in a manor
that says, hey, this is really invalid data for an unsigned field, but
rather that giving asterisks or some other error condition, they displayed
it showing that this is clearly a signed, positive value. I think that's a
quite reasonable decision.
Note that this is a "feature" of zoned decimal. If these were signed
integers for instance, an unsigned "1" and a signed "+1" are exactly the
same at the bit level.
Fire away,
Steve
On Mon, Sep 25, 2017 at 9:57 AM, Michel Adam <[log in to unmask]> wrote:
> I would hazard a guess: this may be the result of specifying "PORTABLE".
> The data is explicitly converted to "human readable format" in order to be
> passed to other platforms, typically to be read by another implementation
> of PowerHouse, which would do its own sanity check when reading in the
> data. The plus sign is probably there because the formatting routine
> handles all types, signed and unsigned, and an explicit "+" doesn't "hurt",
> so why make the ADT code more complicated than it would need to be?
>
> The specification of "UNSIGNED" is in the dictionary, and relate to the
> internal format of an item, when stored on that platform, whereas
> "PORTABLE" if for a standardized "external" representation.
>
> As I said, just a guess...
>
> Jean-Michel Adam, MSc. ISM
> Database Architect / Systems Analyst
> Informatics Shared Service Center, ENR & ITI and Lands
> Government of the NWT
> PO Box 1320 | Yellowknife NT | X1A 2L9
> (867)767-9186 x 24148| Fax: (867)765-0144
> www.iti.gov.nt.ca | www.enr.gov.nt.ca | www.lands.gov.nt.ca |
> www.geomatics.gov.nt.ca
>
>
> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
> Behalf Of James B. Byrne
> Sent: Monday, 25 September, 2017 10:54
> To: [log in to unmask]
> Subject: Re: [HP3000-L] [OT] QTP output of unsigned zoned decimal
>
> On Mon, September 25, 2017 12:39, Pickering, John wrote:
> > define d-account-number char*8 = ascii(account-number,8) Or define
> > d-account-number char*8 = char(account-number)
> >
> > Then include the defined item in your portable subfile instead of the
> > actual data element.
>
> Thanks, I am doing exactly that for other items where the values are
> signed but my question remains: Why is QTP prefacing an unsigned zoned
> decimal with a plus sign? I would expect only digits.
>
> The facile answer is: Because they programmed it that way. But why?
> Why does one have to convert ASCII encoded characters to . . . ASCII
> encoded characters to get rid of a character that is not in the source data?
>
> --
> *** e-Mail is NOT a SECURE channel ***
> Do NOT transmit sensitive data via e-Mail Do NOT open attachments
> nor follow links sent by e-Mail
>
> James B. Byrne mailto:[log in to unmask]
> Harte & Lyne Limited http://www.harte-lyne.ca
> 9 Brockley Drive vox: +1 905 561 1241
> Hamilton, Ontario fax: +1 905 561 0757
> Canada L8E 3C3
>
> * 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 *
|
