parameter value in debug mode

[John192]

also in that link it's not explained how that packed decimal 1.23 is converted in hexadecimal as '
X'0000123F'


neither i am not sure how this numeric packed decimal becomes equivalent hexadecimal as ' x'0005367F' I mean what is the process to get it be it any number and any of the types supported in IBM i ,how do we get equivalent hexadecimal number for each of these data types which are supported in IBM i?



Thanks....

[UserName10]

https://www.ibm.com/docs/en/i/7.3?topic=type-packed-decimal-format

[john.sev99]

You're getting a bit hung up on things you need not worry about. Computers work in binary so they have to interpret that binary data.
For example, the number one can be interpreted in many ways:
As an integer, it would be 00000001.
As a packed decimal, it would be 00011111.
As a character (in EBCDIC encoding), it would be 11110001.
etc etc.

When you called your program from the command line, you were passing a character representation of the number. As per the small examples above, the binary representation of this is simply not a valid packed decimal number. This is why you need to use the hex cludge as you need to force it to send the correct hex values.

You are mentioning numeric values in files. You need not worry about this. If the field in the file is a packed decimal field, it will be stored in the correct binary format so no hex cludge is necessary. The cludge is only necessary for you in this case because it seems you were calling it from a command line and passing a string of characters instead of numbers.

[Barbara Morris]

John192, if you are really thinking of calling your program from the command line with the CALL statement, and you want to support all numeric data types, then the easiest way to determine the correct hexadecimal value is to write a little program with variables defined with those data types, and set the variables to some values. Then look at the variable in debug with :x to see what the correct hexadecimal value is to use for the CALL command.

When I say that this is the "easiest way", it is thousands of times more difficult (maybe millions of times more difficult) than simply creating a command.

It's true that there is an issue of zoned decimal parameters not being supported by a command. To me, the easiest way to solve that problem is to avoid having zoned decimal parameters ...

[John192]

John192, I strongly recommend creating a command to call the program, even if you are just calling it from the command line to test it. It's very easy to create a simple command. The article that Ted posted has an example that should be very easy to copy.

It will be much easier to test your program using the command than to test it by typing a hexadecimal value.

Hi,

any idea how can we create such a command ? I mean using this CMD type member how can we call program by passing parameters ?


Thanks...

[Scott M]

When you compile the command with CRTCMD you specify which program the command is going to run.....

[John192]

When you compile the command with CRTCMD you specify which program the command is going to run.....

Ok, do you mean to say that once inside the CMD member and coded parameters like below way then while compiling the command with CRTCMD to pass parameters in called program do I need to mention program name over there in the parameter 'Program to process command ' (when we do f4 after selecting option 14 (for Create Command (CRTCMD)) option against CMD member type) ?
and then even if I mention program name in parameter ''Program to process command ' here in this parameter then after compiling this CMD type member , will I simply need to call this command without passing any parameters in it ?

Or


Do you mean to say that inside this CMD type member only, I need to type a statement like call program name ? and then compile this CMD type member and then simply call this CMD type member by putting option 'C' against it without passing any parameters explicitly to it , because all the required parameters and program name which needs to be called are already coded inside this CMD type member ?

CMD PARM NBR1 TYPE(*DEC) LEN(7 2)
PARM SHORTCHAR TYPE(*CHAR) LEN(3)
PARM KWD(NBR2) TYPE(*DEC) LEN(3)
PARM LONGCHAR TYPE(*CHAR) LEN(60)

Thanks...

[John192]

John192, if you are really thinking of calling your program from the command line with the CALL statement, and you want to support all numeric data types, then the easiest way to determine the correct hexadecimal value is to write a little program with variables defined with those data types, and set the variables to some values. Then look at the variable in debug with :x to see what the correct hexadecimal value is to use for the CALL command.

When I say that this is the "easiest way", it is thousands of times more difficult (maybe millions of times more difficult) than simply creating a command.

It's true that there is an issue of zoned decimal parameters not being supported by a command. To me, the easiest way to solve that problem is to avoid having zoned decimal parameters ...

Is there any online calculator,tool,utility etc. available which could quickly calculate such hex values based on different such data types and by inputting their values ?


Thanks..

[UserName10]

The link in post 17 explains the data types. Take the time to read about each data type.

[Barbara Morris]

Is there any online calculator,tool,utility etc. available which could quickly calculate such hex values based on different such data types and by inputting their values ?

I don't know of any tool like that.

Why would you want one? When you know how to create a command, it only takes a few seconds to create a command that you can use for debugging a program.

Let's say it takes 2 minutes to edit some command source, such as

parm p1 type(*char) len(25)
parm p2 type(*dec) len(7 2)

and create the command.

crtcmd mylib/testpgm pgm(mylib/pgm) srcfile(mylib/mysrcfile)

Now that you have the command, it only takes a few seconds to type something like

TESTPGM 'abc' -12.5

Even if you had some handy tool to create the hex value, it would take much much longer than a few seconds to go to that tool and enter or select -12.5, DEC, 7, 2,, and then copy the hex value and paste it onto the command line.

[John192]

Now the same error appearing when trying to call a RPGLE program from a CL program whereas in CL I have defined it like :- DCL VAR(&P1) TYPE(*DEC) STG(*AUTO) LEN(6 0) VALUE (010422)
and in next statement I call my RPG program R1 like :- CALL PGM(R1) PARM(&P1)

and I tried calling this RPG program then got 'Decimal data error' in below RPG program when Value of P1 is moved into D1 field of RPG program which is again numeric still this error is occurring.

where as in RPG program R1 this p1 field is declared as following numeric type field.



C *ENTRY PLIST
C PARM P1 6
C MOVE P1 D1

D P1 1 6 0

[Barbara Morris]

It would be much more friendly in this forum if you would post valid code, using the # tool to format it correctly. For such a simple scenario, it should be possible for you to post two complete programs, so it would be easy for us to duplicate your issue.

I don't understand your RPG code. On the PARM statement you have it defined with just "6", which means character length 6. But then on the last line, it looks like you have it defined as a zoned-decimal subfield from position 1 to 6 with zero decimals. Maybe that last line is supposed to be the definition of D1, not P1. The compiler doesn't even allow a subfield to be coded on a *ENTRY PLIST, so I guess it is supposed to be D1.

But there would be a problem if P1 is defined as character or if it is defined as zoned decimal. The CL program is passing it as packed decimal.

When you use the MOVE opcode from character to numeric, RPG assumes that the data in the character value is ZONED decimal (a value like '010422'). It doesn't work if the data is actually PACKED decimal (a value like x'0010422f'). Actually, the RPG program would be receiving x'0010422f????'. The CL program is only passing a 4-byte value, but the RPG program is receiving 6 bytes. The last 2 bytes are random data.

To correct this, the RPG program should receive the parameter as a packed decimal value. The easy way to do this with fixed-form code is to define it on the PARM line as 6 0.