Re: MOVEL in freeform -- RPG400-L

Charles,

The C language doesn't support zoned decimal numbers. Therefore, if you read a record or a parameter that contains zoned decimal in a C program, you need a way to convert it to something that C can deal with. That is what this API is for.

Since C doesn't support zoned decimal, you have to stored the zoned value in a character buffer, and then convert that character buffer to something that C does understand -- such as integer.

RPG, however, *does* support zoned decimal. The data that the OP wants to deal with "00000000M" is already in zoned decimal format. Why would you want to waste the CPU in "converting" it from one format to another when it's ALREADY in a useful format?! The conversion process involves a relatively sophisticated routine that does calculations on each of the bytes to convert it from zoned to a completely different format. (And one that doesn't support decimal places, BTW!)

The bytes that make up the "00000000M" data are already valid zoned decimal, they just need to be viewed as zoned instead of viewed as character, and you're done. It takes no CPU to "convert" them, since no conversion is necessary. It's just a matter of telling the computer that the existing bytes are zoned instead of alpha, and you're done. No work to be done. No calculations.

If you must call a C API for some reason, why not use memcpy? Since you don't really need to change the value of the field, you just want to copy the bytes from an alphanumeric field to a zoned one. Why mess around with all of the calcs involved in converting the field? You don't particularly want it in integer format, do you? Why not just copy the bytes from one place to another, since they're already in zoned format?

I'm certainly not averse to using C APIs when they make sense -- but in this case, it doesn't make sense to me.

What's the advantage to calling QXXZTOI over using a data structure? Or writing a very simple subprocedure to convert the data? What is it gaining you, other than adding complexity and requiring more work for the computer, and making it harder for RPG programmers to understand your code?

Wilt, Charles wrote:

Scott,

I'm curious, if this function shouldn't be used the OP's purpose, then what should it be used for?

It seems to me that it's designed to convert from a zoned decimal value stored in a character buffer
to an integer. Is that not the case?

The OP had "00000000M" and needed to convert it to -4.

int QXXZTOI(unsigned char *zptr, int digits, int fraction);

Thanks!

Charles Wilt --
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Scott Klement
Sent: Monday, August 04, 2008 6:05 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: MOVEL in freeform

Hi Alan,

D cvtZonedToInt pr 10i 0 extproc('QXXZTOI')
d cvtZone * value options(*string)
d cvtDigits 10i 0 value
d cvtFraction 10i 0 value

You should remove 'options(*string)' from the first parameter. The
input isn't a string, it's a zoned decimal number.

I have no idea why you'd want to use this for your purposes, though. Is
your goal really to convert zoned decimal to integer? And if it is,
why use a C function? Why not use %int()?

AFIAK, your issue is thast you have bytes in zoned decimal format, but
they've been stored (for some weird unknown reason) in an alphanumeric
field instead of in a zoned decimal field.

The solution to that is to use overlaid fields in a data structure.
Though, you can solve the same problem by passing a mismatched parameter
(which is what you've done by calling QXXZTOI) or by pointer logic.

But, an overlaid data structure field would perform a lot better than
calling this API, and it'd also make a lot more sense to the next guy
reading your program.

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.