Re: CL parameters over 32 length

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

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)

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.

You give a lot of good information and good advice, as usual, but I
would challenge the notion that QCMD is "a simple program so it has
simple rules". How are the three rules you give simpler than

1. If the literal is numbers, then create a PACKED(15 5) variable.
2. If the literal is not numbers, then create a CHAR(length(literal)) variable.

The "simple 3" rules involve checking the length of the literal
anyway. There is no way around that. So then why not just stop after 2
rules? Would that not be even simpler, from QCMD's perspective?

So the story probably involves some kind of performance or memory
optimization, rather than simplicity.

Or maybe (I don't know the history; I'm just speculating) there was a
time when there WERE just two rules, and they were even simpler still:

1. If the literal is numbers, then create a PACKED(15 5) variable.
2. If the literal is not numbers, then create a CHAR(32) variable.

Anything longer than 32 characters was explicitly unsupported (if not
blatantly disallowed, then at least undefined behavior). And then
maybe they decided to add support for longer parameters, and at that
point, they had to decide whether to change the behavior of shorter
parameters. If this is indeed the history, then clearly they chose to
keep the old behavior exactly as-is for maximum compatibility and
minimum chance for breakage; while adding new support for longer
parameters.

Whether due to optimization or historical artifact, it's fine
honestly. Let's just call a spade a spade. The current behavior is not
exactly *hard* to work with, but it's definitely not as simple as it
could be, whether we're talking about implementation or use.

John Y.