Here is some related to parameters passing:
1. A CL programs call an RPG programs and passes a numeric parameter.
the RPG is expecting a zoned number but a number variable in CL is
always packed, thus garbage is received. To avoid that, you either
define the parameter as packed in the RPG or you first move the numeric
parameter in an alpha parameter ine the CL. not intuitive, thus easy
mistake to make for a newbe.
2. AN RPG programs works fine, you decide to make a variable that is
part of the parameters list part of a data structure. The variable was
defined as packed. After being added to the array, it is now zoned!!
Your programs start to bomb because it receives bad input. To avoid it,
what we did here is to avoied packed variable all together. The
performance impact, if any, is negligeible.
3. When a program is called directly from the command line or submited
to batch, all numbers are assumed to be packed 15 long with 5 decimal
numbers. Also, all caracters variable, if smaller than 32 caracters, are
assume to be 32 caracters long. The solution: use command instead of
calling programs directly. As a side note, commands only support packed
number which can interfere whit the solution I gave in 2.
Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> 2008-03-30 18:48 >>>
Folks, I'm working on an article that's tentatively titled "Classic
Traps and How to Avoid Them". The general idea is to discuss the
classic
mistakes that programmers make while programming, and (where necessary)
explain how to avoid that.
This can be simple things like "Don't use 10000.01 to flip dates,
because it's an obscure technique that many people won't understand, so
even though it's really neat, don't use it". But it can also be a much
more broad and sophisticated notion of a "trap".... "Don't get into the
habit of mixing business logic together with display logic. Although it
makes your program much easier to write, and the code is much easier to
follow, over time it results in a system that's very difficult to
maintain when the business wants to change something, it becomes very
slow and difficult to adapt the old system to the new paradigm"
Or something like that.
Anyway... I would REALLY appreciate your help. What I need to do is get
together a list of the classic traps that programmers fall into. Please
send me a list of the common traps and mistakes. You can just reply to
my e-mail address directly (I don't want to dirty up the lists too
much)
The e-mail address at the top of this message will work fine.
I just want to get together a good list of classic traps so I can use
them in my article.
Thanks
midrange.com
