× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Chuck,

my problem is that my application must fit the existing framework.
Inside this framework decimal(15,0) is returned as char(16),
decimal(11,7) is returned as char(12).
It is absolutely obvious that generally 12 characters is not enough to
show ANY decimal(11,7) but I should not care about that hoping that
bank interest rates will not become BIG NEGATIVE (decimal (11,7) is
used for keeping interest rates).


Jevgeni.



On Wed, Mar 18, 2015 at 9:23 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:
On 17-Mar-2015 04:51 -0500, Jevgeni Astanovski wrote:

Big-big thanks to Barbara and Tim.

The result is:

void printdec(void *A, int Len, int Prec)
{
decimal(63,0) fulldec ;
int offset, bytes ;

bytes = (Len / 2) + 1;
offset = 32 - bytes;
fulldec = 0;
memcpy(((char *) &fulldec) + offset, A, bytes);
printf("%0*.*D(63,*)\n", (Len + 1), Prec, Prec, fulldec) ;
}

is exactly what I've been looking for.


The original requirements were not explicit, but if the alluded
requirement for ensuring left-pad with zeroes implies *also* that a
consistent length\layout of all valid values is required, then the
formatting chosen for the above printf() might not be appropriate. That is
because [excepting when Prec=0] both negative values and values of maximal
digits will appear laid-out in storage differently than other values; i.e.
all possible values would not align [with the decimal point in the same
location] within a fixed-width column.

Some Example values for three variations of P(l,p) to exhibit the results
with the aforementioned formatting:

P(09,2) P(03,0) P(06,6)
----------- ---- ---------
9876543.21 0321 0.660000
-9876543.21 -321 -0.660000
0876543.21 0001 0.000006
-876543.21 -001 -0.000006
0000000.21 0000 0.000000
-000000.21
0000000.00

The following formatting choices may be more appropriate, if alignment
within a [report] column is desirable:

printf("%0 #*.*D(63,*)\n", (Len + 2), Prec, Prec, fulldec) ;

printf("%0+#*.*D(63,*)\n", (Len + 2), Prec, Prec, fulldec) ;


To avoid printing the decimal point for a zero-precision packed BCD
[noting: the #flag in the above printf() examples would effect], then the
alternative formatting shown below might be more appropriate; again, to
ensure alignment within storage\report-column:

void printdec(void *A, int Len, int Prec)
{
decimal(63,0) fulldec ;
int offset, bytes , fmtLn ;

if (Prec) fmtLn=Len+2 ; // first byte is not a digit
else fmtLn=Len+1 ; // zero-precision: less one byte
bytes = (Len / 2) + 1;
offset = 32 - bytes;
fulldec = 0D;
memcpy(((char *) &fulldec) + offset, A, bytes);
printf("%0 *.*D(63,*)\n", fmtLn, Prec, Prec, fulldec) ;
//printf("%0+*.*D(63,*)\n", fmtLn, Prec, Prec, fulldec) ;
}

Some Example values for three variations of P(l,p) to exhibit the results
using the [active\non-commented] format-string in the revised version of the
printdec() included just above; if the version with the plus symbol [the
commented version with the +flag] were to used instead, the first character
as blank for positive values would be the plus-character instead of the
blank:

P(09,2) P(03,0) P(06,6)
----------- ---- ---------
9876543.21 321 0.660000
-9876543.21 -321 -0.660000
0876543.21 001 0.000006
-0876543.21 -001 -0.000006
0000000.21 000 0.000000
-0000000.21
0000000.00

--
Regards, Chuck
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.