Why the OPTIONS(*TRIM) doesn't work as IBM says, what's missing here?

Question

**free
ctl-opt main(main);

dcl-pr main ExtPgm('TSTPGM');
  *n char(10) const options(*trim);
  *n char(10) const options(*trim);
end-pr;

dcl-pr ExecCmd Extpgm('QCMDEXC');
  Command Char(40);
  CmdLen  Packed(15:5);
end-pr;

dcl-s str0        Char(100) inz;
dcl-s $RRN        Packed(6);
dcl-s Command     Char(40);
dcl-s CmdLen      Packed(15:5) Inz(%Len(Command));

dcl-proc main;
  dcl-pi *n ;
    file char(10) const options(*trim);
    lib  char(10) const options(*trim);
  end-pi ;

  Command = 'DSPFFD FILE('+lib+'/'+file+') OUTPUT(*OUTFILE) OUTFILE(QTEMP/QADSPFFD)';

  Monitor;
    ExecCmd (Command: CmdLen);
  On-Error;
  EndMon;

end-proc main;

here is how the Command looks like

I'm expecting Options(*Trim) to trim the input parameters, file and lib so that I don't have to use %trim before building the Command string :|

Is this option quite unreliable to use or is there a limited setting this could be used in?

OS Details: I'm running 7.5 with TR1

Charles · Accepted Answer · 2023-03-11T23:27:17.800

As @nfgl points out options(*TRIM) can only trim a varchar field.

Fix length char fields are always whatever length they've been defined so there's always padding if not filled.

Additionally, given that this is *PGM source, I'll point out that if you intend to call the *PGM from the command line, simply changing parms to varchar won't fix the problem. The options() keyword functionality is actually implemented by the caller of the prototype procedure; not the callee.

And given that the IBM i command line processor doesn't have access to the RPG prototype it's not going to know options(*TRIM) was specified.

In other words, options() is useful only given an RPG caller since the RPG compiler generates the code required to support the functionality in the caller.

A perfect example, you've got an RPG procedure calling a ILE C procedure that expects a C standard null terminated string. When you define the RPG prototype for the C procedure, you'd use const options(*TRIM:*STRING)

And now that I've typed that last sentence, I realize it's the exception to the first one. :) When calling a C procedure const options(*TRIM:*STRING) would be used on char fields rather than varchar ones. An RPG varchar doesn't play well with C procedures as they don't expect the leading 2 or 4 byte length.

Hi @Charles Your expertise and willingness to share your knowledge have been invaluable in helping me grow as a programmer. Thank you for taking the time to assist me and for being an important part of my learning journey :) — ojay, Mar 12 '23 at 05:25
I resort to %trim to let this work, but I've a query on the varchar parm. Why the initial 2 char were being clipped as I passed them thru cmd line? IK that varchar reserves 2-4 bytes to store the actual length of a string, but why the left-bytes here? Can you help me connect the (missing) dots here? Thanks! — ojay, Mar 12 '23 at 05:35

score 2 · Answer 2 · answered Mar 11 '23 at 17:30

2

See docs

If the parameter is not a varying length parameter, the trimmed value is padded with blanks (on the left if OPTIONS(*RIGHTADJ) is specified, otherwise on the right).

answered Mar 11 '23 at 17:30

nfgl

2,812
6
16

Thank you @nfgl for bringing this to my attention. I was fixated on... > Specifying OPTIONS(*TRIM) causes the parameter to be passed exactly as though %TRIM were coded on every call to the procedure. – ojay Mar 12 '23 at 03:50

Why the OPTIONS(*TRIM) doesn't work as IBM says, what's missing here?

2 Answers2