On 7/5/2018 3:58 AM, Erwin Donker wrote:
So basically what I want to know is, why does using CL parameters over 32 characters sometimes work, and sometimes not?
tl;dr It always works.
Parameter passing is done by address - by a pointer.
The caller sets aside a variable in memory and passes a pointer to the
start of that memory to the callee.
In a programming language, we use some kind of declaration to explicitly
state the name, type and length of the variable like so:
DCL &CUSTNAME *CHAR 50
dcl-s cust_name char(50);
In this case, the caller is the command line - QCMD and friends.
There is no DCL.
There is no variable.
There is only a literal.
In order to pass a pointer to the address of the variable, QCMD needs
first to create a variable. Remember: QCMD is running, not the called
program. QCMD has no idea what the called program uses for parameter
definitions. No calling program on this system knows what the called
program's parameter definitions are like.
So QCMD needs to create a variable, but what type and size? It's a
simple program so it has simple rules:
1) IF the literal is numbers:
THEN create a variable PACKED(15 5)
2) IF the literal is not numbers
AND there are more than 32 characters in the literal
THEN create a variable CHAR(length(literal))
3) IF the literal is not numbers
AND there are 32 characters or less in the literal
THEN create a variable CHAR(32)
These simple rules have been in place from very, very early releases of
S/38 CPF. If our calling program insists on reading the first 512
characters of a 32 character variable, we get what we deserve.
Sometimes we catch a break and discover our error on the very first test
run. Sometimes, characters 32+1 through 512 contain blanks, and we
don't realise we wrote bad code for a long, long time.
Another question out of curiosity, this "problem" has been around at
least since 1998 and probably much longer (1998 was the oldest
information I found online). I see many people having issues with this,
so why has IBM never changed this?
This is how the system was designed.
These rules are what govern tens of millions of program calls.
It's not a problem, any more than gravity is a problem.
Follow the rules and it's completely reliable.
That said, in order to change this behaviour, here are several ideas you
might ask for in an RFE.
1) Alter the rules by which QCMD creates variables. Maybe always create
a 64k character variable. The resultant performance problems might be
fun to watch.
2) Alter the way programs are created. Have each program store the
parameter definitions. Expose those definitions via API. Alter QCMD et
al to inquire into what the caller expects, ignoring the actual literals
supplied, and create variables that always match between the command
line and every possible called program.
3) Alter the CALL command to allow for parameter definitions. So
instead of
CALL SOMEPGM ('parm1' 'parm2')
we might have
CALL SOMEPGM ('parm1' 'parm2') ARGDEF((*CHAR 50) (*CHAR 512))
While I myself haven't had an issue remembering the three rules, it is
2018. Maybe it's time to have IBM i deal handle parameters in a more
programmer-friendly way. Put in an RFE and see how the wind blows.
https://www.ibm.com/developerworks/rfe/?BRAND_ID=352
midrange.com
