there's garbage in my *ENTRY parameter

[MW]

What's up with this:

I've got one entry parameter defined as 90 alpha. When I call the
program thusly ...

call casadr00 ('/xml4pr400/addressbook.xml')

I get garbage in the field. I put this baby in DEBUG, broke RIGHT
after the *ENTRY def, and here's what inFile looks like (copy/paste
from DEBUG):

EVAL inFile
INFILE =
....5...10...15...20...25...30...35...40...45...50...55...60
1 '/xml4pr400/addressbook.xml ALLo casadr00Ø E
'
61 ' /xml4pr400/addressbook.xml'

I've seen this when attempting to pass numeric values, but never
character. Here's the *INSZR where it's all happening:

C *Inzsr Begsr

C *Entry Plist
C Parm inFile

C Eval xmlFile = %Trim( inFile )

And the D-Specs defining both inFile and xmlFile:

* Location of XML file(s).
D inFile s 90a
D XmlFile s Like(inFile)

Any ideas??

Mike

[Thomas Hauber]

I have experienced this firsthand in a couple of my own applications. Usually when passing variable data in a fixed length alpha fields from a CL to an RPG program.
Perhaps others will suggest more elegant solutions, but the way I handled it was to embed an asterix '*' at the very end of the parm field as a placeholder. That way
my parm had the right amount of clean splaces after the needed data.

In your case make your parm 91 character with the 91st character being an '*'. Then change your eval statement to the following:
Eval xmlFile = %Trim( %subst(INFILE : 1 : 90))

[Barbara Morris]

Barbara Morris wrote:
> ...
> CMD
> PARM KWD(ADDRBOOK) TYPE(*CHAR) LEN(90) +
> CASE(*MIXED) +
> PROMPT('Path to address book')
> ...

Mike, I didn't notice that you were trimming the parameter. You can get
the command to pass you a varying parameter, and avoid having to do a
trim:

CMD
PARM KWD(ADDRBOOK) TYPE(*CHAR) LEN(90) +
CASE(*MIXED) VARY(*YES *INT2) +
PROMPT('Path to address book')

D inFile s 90a Varying
D XmlFile s Like(inFile)

C Eval xmlFile = inFile

[Barbara Morris]

MW wrote:
>
> What's up with this:
>
> I've got one entry parameter defined as 90 alpha. When I call the
> program thusly ...
>
> call casadr00 ('/xml4pr400/addressbook.xml')
>
> I get garbage in the field.

> ...

Mike, when you use the command line to call a program, the system
doesn't know your program expects 90 bytes. It assumes that character
parameters are 32 bytes long unless you actually enter more than 32
bytes. (It assumes numeric parameters are 15,5.) This doesn't apply to
program-to-program calls, though.

To get around it, you could code all 90 bytes on the command line if you
want, but it's much easier to create a command interface so you can tell
the system that the parameter is supposed to be 90 bytes long:

CMD
PARM KWD(ADDRBOOK) TYPE(*CHAR) LEN(90) +
CASE(*MIXED) +
PROMPT('Path to address book')

===> CRTCMD CASADR00 PGM(*LIBL/CASADR00) PRDLIB(YOURLIBRARY)

===> casadr00 '/xml4pr400/addressbook.xml'

[Barbara Morris]

Thomas Hauber wrote:
>
> I have experienced this firsthand in a couple of my own applications. Usually when passing variable data in a fixed length alpha fields from a CL to an RPG program.
> Perhaps others will suggest more elegant solutions, but the way I handled it was to embed an asterix '*' at the very end of the parm field as a placeholder. That way
> my parm had the right amount of clean splaces after the needed data.
>
> In your case make your parm 91 character with the 91st character being an '*'. Then change your eval statement to the following:
> Eval xmlFile = %Trim( %subst(INFILE : 1 : 90))
>

Thomas, that works well, but you don't need to substring the parameter
within your RPG program (doesn't hurt, but it's not necessary). The RPG
program won't look at more than 90 bytes of the parameter anyway.

By the way, it's only necessary when you're doing a SBMJOB within your
CL or when you're calling with literals in your CL. If you're calling
program-to-program with variables, you don't need to do anything special
to get a 90-byte variable passed as 90 bytes.

Barbara

[Dieter Bender]

Barbara Morris wrote:

> snip

> By the way, it's only necessary when you're doing a SBMJOB within your
> CL or when you're calling with literals in your CL.

for a sbmjob, I would recommend a *CMD object to control the passed
parameters.

If you're calling
> program-to-program with variables, you don't need to do anything special
> to get a 90-byte variable passed as 90 bytes.

besides correct declarations :))

Dieter

>
> Barbara