vhamberg@xxxxxxxxxxx wrote:
If I remember what Paul Tuohy said at COMMON recently, the called
program assigns storage for its parameters, with the sizes it knows.
There is likely some kind of memory copy to put the parameters into
that storage, for as long as each parameter needs.
The called program never assigns storage (unless you write code in your
program that explicitly does that, of course). It references the
storage passed in the parameter list -- that's why it's called "passing
by reference".
In other words, the caller (the command-line in this case) is passing a
pointer to the program. The program simply views the memory that the
pointer points to.
There is no copy going on. That's why programs can return information
in their parameters! They're simply referring to the same spot in
memory that the caller is referring to. When you change it, you change
the caller's memory. (If there was a copy, you wouldn't change the
callers memory, and therefore, you would not be able to return info in
the parms.)
When you use literals from the command line or in the CMD parm of
SBMJOB, you can see what you get. If you use commands to front your
call, the memory is properly cleared for the size of the parameter in
the command.
It has nothing to do with clearing memory. It simply has to do with the
amount of memory allocated. When you use a literal from the command
line, you haven't explicitly told the operating system how big the
parameter is. Consider this command:
CALL PGM(ALBATROSS) PARM('EVERY ONE KNOWS HOW PARAMETERS WORK')
How much memory should the operating system reserve for the parameter
I'm passing? Did I declare that parameter as 10 bytes long? 20 bytes?
50 bytes? 1000 bytes? No! I didn't declare a length AT ALL. I haven't
told the operating system how much memory it should be.
Since there's absolutely nothing declaring the length of the parameter,
it uses a set of rules to decide on the length. If the parameter is
less than or equal to 32 characters, it asks for 32 characters of
memory, puts the data in the start of the field, and fills the rest with
blanks. Always. Even if the program is only expecting 10 characters,
it still reserves 32 characters. It doesn't know what the program expects.
If the parameter is longer than 32 charaters, it reserves whatever
length you typed. If you typed 35 characters (as in my example above)
it reserves 35 characters. Since the length is exactly the same as what
you typed, there's no padding.
When your program receives the parameter, it views the area of memory
that the command line reserved. It doesn't copy it. It just views (and
potentially, changes) it.
If the length of the variable in the program is shorter than what the
command-line has reserved, it's no big deal. It simply doesn't try to
read as far into memory. If I declared 10 bytes, and the command-line
reserved 32, it only reads the first 10 of the 32, and ignores the
remaining 22... no harm done.
If the length of the variable in the program is longer than what the
command-line has reserved, it views memory beyond what was allocated,
and you see whatever (by chance) happens to come after it in memory.
This is also why the trick of putting a character after the "last"
position works - that marker is never copied because it is not within
the length that is defined in the called routine.
No. The reason this works is because you're changing the length that
the command-line allocates. If your program wants a 50 char parameter,
and you type an X in position 51, the command-line allocates 51
characters, but you only view the first 50, and ignore the X in position
51. There's no copying involved (unless it's code that you wrote in
your program.)
midrange.com
