Re: CL parameters over 32 length

Item 1 in your list won't really help Buck - it has been a long time since we were limited to 64K and I think a 16Mb temp would for sure cause issues!

Item 2 (full descriptor support) has long been requested but not implemented. In most cases you can at least now use the PCML support to embed the definitions in the program - and of course there's an API to retrieve those. Problem is that the PCML support is also incomplete.

Item 3 is an interesting idea - but I don't see it helping much in practice. Problem as I see it is that it presumes that the person making the call knows exactly what the callee expects - and in most cases had the programmer realized that he wouldn't create the problem in the first place!


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jul 5, 2018, at 10:20 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

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

--
--buck

http://wiki.midrange.com
Your updates make it better!

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD