Trouble Passing Numeric Parms

[Fooch]

I am having a problem that should NOT be an issue. I am getting extremely frustrated over something so simple but I can't get why it is happening. I am passing 5 Parms to a program but for some reason the numeric ones are showing up with boxes in them instead of the information I passed to it obviously causing data decimal errors. I am calling the program with:

"call pl0330r01 parm('Test' '00055' 'I' '1234567890' '0')"

(after previewing posts I noticed the boxes were not showing so I added them with *BOX* these are the placed were a filled in box is showing in the field)

These are the results from debug:
> EVAL @@HGISWN
@@HGISWN = 'Test
> EVAL @@HGIHG#
@@HGIHG# = 0*BOX*0*BOX*0*BOX*
> EVAL @@HGISTS
@@HGISTS = 'I'
> EVAL @@HGIPIL
@@HGIPIL = 1*BOX*2*BOX*3*BOX*4*BOX*5*BOX*
> EVAL @@authority
@@AUTHORITY = '0'

The fields are defined as:
@@HGISWN 30A
@@HGIHG# 5S 0
@@HGISTS 1A
@@HGIPIL 10S 0
@@Authority 1A

Do you have any idea why I am getting the values that I am for the numeric fields? This is driving me NUTS and the deadline is getting closer and I am stuck on such a stupid problem.

 

[RichardWilson]

HI
Calling a pgm with mixed type parameters needs an understanding of how parameters are passed as either character or packed numerics. You would normally have to convert your numeric parms to hex in the call you show.
I find that a pain so I suggest you cobble together a command.

Takes a couple of minutes, and you have a command line call to do the testing.

The boxes sound like your terminal's way of displaying a hex value outside the range of displayable characters ( hex 40 and above) this behavious differs from terminal type to terminal type.

 

[Fooch]

Thanks for the post.

I am not sure exactly what you are saying. I am not sure I have ever had a problem like this before but I can't recall back to ever sending mixed parms. I am sure I would have. I just can't understand why this is such an issue. This seems like a really simple thing. The fields on both sides and defined exactly the same. I don't get it. should I jsut pass alphas and move them or something? I can't believe this simple task would be that difficult.

 

[AlanHouston]

Fooch,

If you are going to pass numeric parms from a command line you need to tell the system that you are passing hex values for the numeric parms. The command shown below should do what you want:

call pl0330r01 ('Test' X'00055F' 'I' X'01234567890F' 'O')

Notice that the numeric parms are preceeded by an "X", contain a trailing "F" as they are positive values and all have an even number of characters in the string.

 

[Fooch]

Yeah but the command line is just to show you guys the parms i am passing...it works the same with a program with a call and parms. The parms are defined exactly the same as the called program. but as soon as the program is called the values are wrong.

 

[AlanHouston]

Fooch,

If you are talking about calling an RPG program from a CL program, remember that numeric parms are passed from a CL as 15/5. When faced with this situation I always define the numeric parms as such in both the CL and RPG programs and then convert the values passed to the RPG program into the form I want.

 

[flapeyre]

*DEC parameters in CL are PACKED, not zoned. If you change the defs in the RPG to packed, it will work.

Feles mala! Cur cista non uteris? Stramentum novum in ea posui!

 

[Fooch]

I am calling from an RPG to an RPG. I know of the CL issues.

 

[flapeyre]

Are you prototyping or are you using PLISTs?

If you are prototyping, put the CONST keyword on the numeric values (if the called program isn't supposed to change them).

Look at the compile listing for both programs and verify that each paramter in the calling program is defined EXACTLY the same as in the called program. There are instances where a field's definition can changed from zoned to packed, and vice versa. My method is to only used the paramter fields once - to move them to the actual fields I'm going to process in the *INZSR.

Feles mala! Cur cista non uteris? Stramentum novum in ea posui!

 

[Fooch]

They are defined the same, one from a display file(externally) and the other from a physical file(externally). It is not prototyped. It is a normal call with a PList.

 

[flapeyre]

I would consider prototyping the programs. If the field in the physical file packed (in the DDS definition)?

Feles mala! Cur cista non uteris? Stramentum novum in ea posui!

 

[Fooch]

Nope, they are both zoned. And I can't prototype it because we need to stay consistant with the clients stuff.

 

[flapeyre]

I'm out of ideas. All I can recommend is to move the parameters to another field before passing them. If you are getting data back, you need to move them back after the call.

Feles mala! Cur cista non uteris? Stramentum novum in ea posui!

 

[Fooch]

That was my work around lol...i don't get why this is such an issue. Kinda sucks...code will look sloppy with excessive moves.

 

[RichardWilson]

Hold on chaps,

Lets summarise,

You are calling one RPG ILE program from another, both have identical definitions for the interface, which consists of 5 fields, 2 of which are signed decimal. When you place the funs into debug, the signed decimal fields display non numeric characters, and a decimal data error is raised.

So it's evident that the values being placed into the numeric fields are incorrect.

What can the problem be? - have you looked at them in hex, using debug? view the values in the calling program as they are assigned, step into the called program and review the values before the error occurs to make sure they match. Stick with Hex when you display.

May I ask if you are familiar with the structure of signed/zoned versus packed decimal? ( I have to ask, not everyone reads hex half bytes! )


There are some issues to check out - CCSID's, your terminal emulation settings ( unless you're on a REAL 5251 on RS422) all that stuff, but that's only going to affect what you see on screen, and not the problem itself, so viewing the field content in hex is always a Good Idea.


I'm guessing here, but maybe you could try using an old fashioned, (and efficient) MOVE to set the values.


Richard Wilson

 

[Mercury2]

Fooch,

To clarify this issue, could you pls paste here :

1/ the PF description of the related fields
2/ the DSPF description of the related fields
3/ the related fields definition in the calling program
4/ the related fields definition and the *ENTRY PLIST in the called program.

Thx

 

[flapeyre]

Okay. I don't quite understand why you can't prototype. "We need to stay consistant with the clients stuff" is not a technical reason; we use prototypes to call *ENTRY PLIST programs all the time, and vice versa. It really does give you more flexibility in dealing with parameters.

The underlying issue is simply that the fields have been changed from one type (zoned or packed) to the other in one program. Did you compare them in the compile listings at the bottom of the list?

Feles mala! Cur cista non uteris? Stramentum novum in ea posui!

 

[arrow483]

You need to change the numerics to PACKED decimal. RPG-IV always passes numeric parms as packed, unless you prototype it.

What happens here is that the parm is sent as packed (which it isn't), so the input parm is attempting to read as by unpacking - which causes an error.

Change the parms both to packed, using a work field is needed.