**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
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.