My example is definitely not the only way to do it. It might be close to the best way, though it can simply depend on how careful you are with accessing parameter values. It can become important in later commands and their CPPs, and it might become important for your current command.

It’s definitely important to use the nbr-of-elements value(s) when processing a list as you already learned. When a list parameter is the last parameter, you’d be accessing memory that wasn’t part of the parameters at all if you went past the end. You might attempt to access memory that wasn’t even allocated for the command and hit a machine-check.

Tom

This will help me a lot. I will try it.

Thanks again. Gail

Tom

More likely it will be (a maximum of) 8 bytes long.

It will actually be a data structure, because that’s a command does to a “list” parameter. The first two bytes will be an unsigned integer (5U 0) that holds the number of list elements that were entered by the user. If three elements were entered, the value will be x’0003′ which becomes (3) as an integer. The parameter will physically be pretty much exactly like a VARYING length variable would be in memory.

You use the nbr-of-elements value to keep your program from referencing elements that weren’t entered by the user.

You might define an 8-byte variable that acts as the receiver of the parm. You never reference it directly though. Instead, define a DS that consists of a 2-byte integer followed by a single character and define the DS as based on a pointer.

When your program is called, assign the address of your 8-byte variable to the pointer. That puts your 3-byte DS definition right over whatever memory address was allocated by the command, and it gives no chance of referencing anything beyond the value because your command guarantees at least one value in your list.

Create a second DS that contains a DIM(6) array of 1-byte values, and also have it be BASED on a pointer. As soon as the first pointer be comes valid, set the second pointer to be the address of the 1-byte variable in the first DS.

At that point, your array DS points to the first element in your list. Any array element that is beyond the nbr-of-elements value needs to be considered as off-limits to your program code. If nbr-of-elements contains (3), you don’t want to be referencing element 4.

Well, I can imagine that’s a little confusing, so here’s a stab at a working example:

     H debug
     H dftactgrp( *NO )
     H     actgrp( *CALLER )
     H     bnddir( 'QC2LE' )
     H indent( '  ' )

     D ExclPgm         pr                  extpgm( 'EXCLUDE' )
     D  Exclude                       8a
     D  InvNo                        10a

     D ExclPgm         PI
     D  Exclude                       8a
     D  InvNo                        10a

     D XL_ds           ds                  based( @XL_ds )
     D  nbrElem                       5u 0
     D  Elems                         1

     D  arElem         s              1    dim( 6 ) based( @Elems )

     D  i              s              5u 0

     C                   eval      @XL_ds    = %addr( Exclude )
     C                   eval      @Elems    = %addr( Elems   )

     C                   for       i  =  1 to nbrElem

     C     arElem(i)     dsply

     C                   endfor

     C                   eval      *inLR   = *on

     C                   return

Now, it doesn’t do anything but display however many elements were entered into the command, but those are the only elements you’re interested in. Compile it and test it by calling it this way:

call exclude (x'0002F1F2F3' 'Now parm 2')

If you look closely, you’ll see that it’s technically passing three array elements in while claiming that it’s only two. Experiment by adding ‘F4F5F6′ or more onto the end of the first parm. Change the x’0002′ to x’0005′ or x’0001′.

If there are difficulties or questions, post them here. (…especially if I messed up pasting the code or something.)

Tom

This is the D specs in the RPG.

D EXCLUDE DS
D ELEAD 1 2
D EXC 1 DIM(6)
D INVFLD S 10

The EXC is the separate entries, the invfld is the 2nd parm. The invfld gets the ‘INVNO’ properly.

The ‘INVNO’ value is going to be in memory immediately following the EXCLUDE values. If RPG always accesses 6 bytes even when only 3 three were placed in memory, it will access the first bytes of INVNO.

yes, this is what is happening.
You are defining a list of 1-byte values rather than a 6-byte field. You should only access as many values as were entered by the user. You’ll need to extract the list counter from the EXCLUDE parm and use it.

So I should define the EXC as 6 bytes long and then load it into the array later?

It will almost certainly be how RPG defines and accesses the parms where the problem is.

The ‘INVNO’ value is going to be in memory immediately following the EXCLUDE values. If RPG always accesses 6 bytes even when only 3 three were placed in memory, it will access the first bytes of INVNO.

You are defining a list of 1-byte values rather than a 6-byte field. You should only access as many values as were entered by the user. You’ll need to extract the list counter from the EXCLUDE parm and use it.

Tom

PARM KWD(INVNO) TYPE(*CHAR) LEN(10) MIN(1) +
MAX(1) PASSATR(*NO) CHOICE(‘INV Field name’) +
PROMPT(‘Invoice field’)

looks like this where I can do 1 code or up to 6.
Exclude these Codes . . . . . . _ F4 for list
+ for more values _
Invoice field . . . . . . . . . . . . . __________ INV Field name

If I enter A, B, C in the Codes field and INVNO in the Invoice field, I get A B C I N V in the Exclude field.

How do I make the remaining of the 6 possible entries be blank instead?