How to prevent parameter 2 from getting into parm 1 in iSeries

300 pts.
Tags:
AS/400 Parameters
COMMANDS
IBM iSeries
RPGLE
I have a command that calls a RPGLE program. One of the parms has a max of 6 but if using less than the 6, I get info from the next parm in that field. How do I prevent that?

Here are the 2 parms as defined in the Command:

PARM       KWD(EXCLUDE) TYPE(*CHAR) LEN(1) RSTD(*YES) + 

Software/Hardware used:
iSeries, Command

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • VGP
    It lost the rest of my info...here it is This is the command parms: PARM KWD(EXCLUDE) TYPE(*CHAR) LEN(1) RSTD(*YES) + VALUES(A B C D E F G H I) + MIN(1) MAX(6) PASSATR(*NO) CHOICE('F4 + for list') PROMPT('Exclude these Codes') 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?
    300 pointsBadges:
    report
  • TomLiotta
    We need to see how RPG is defining its parms. (Why does this process feel familiar?) 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
    125,585 pointsBadges:
    report
  • VGP
    Thanks Tom, yes this is familiar. The same process that had the QM issue with the setvar 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?
    300 pointsBadges:
    report
  • TomLiotta
    So I should define the EXC as 6 bytes long... 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
    125,585 pointsBadges:
    report
  • TomLiotta
    Sometimes you can get programs to do more work by setting variable definitions than you can by coding more op-codes. Tom
    125,585 pointsBadges:
    report
  • VGP
    Tom, Thank you very much for the info and the detail. As you probably guessed I am not to savy with commands. This will help me a lot. I will try it. Thanks again. Gail
    300 pointsBadges:
    report
  • TomLiotta
    If you need more documentation, see Defining lists for parameters in the Info Center. 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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following