× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.