Re: CLP pgm with 2 paramters intermittently gettinggarbagewhencalled from AJS

On 4/11/2014 10:31 AM, Steinmetz, Paul wrote:

One last question.
Does the 32 character clear issue on a SBMJOB only apply to CLP.

No.

Is RPG, RPGLE, etc also impacted?

Yes.

Imagine writing a program in any language that has to receive an
arbitrary message and store it in memory. This is what the command
processor has to do in order to pass a pointer to a block of memory to
the callee. It looks at the message, infers the data type and length
and then allocates memory based on those inferences. Having allocated a
block of memory, it shares the pointer with the callee, which then maps
(like an RPG data structure with OVERLAY) its parameter to that memory
block.

So the only question is this: What size variable should my arbitrary
message processor set aside? We could allocate 64k, but if the average
message is only 10 bytes, that's a lot of wasted space. We could
allocate 10 bytes, but when we get a larger message we'd have to
re-allocate the memory which takes time. The way to optimise the
variable size then, is to analyse the incoming messages and choose a
size that covers enough standard deviations to provide a tradeoff
between wasting memory and wasting processor time.

IBM chose 32 bytes as that tradeoff point.

When I CALL a program - in any language - from the command line (or
SBMJOB), the command processor allocates 32 bytes for a character
variable, and re-allocates to the larger size if it finds that the
supplied argument is larger than that. Numbers are always packed and
put into a 15,5 memory block.

The problem comes when the callee defines a larger parameter, say 50
bytes and the command line supplies fewer than 50 characters. The
command processor allocates, clears and loads 32 bytes, properly leaving
any memory after that alone. The callee gets a pointer to 32 bytes of
properly initialised memory and proceeds to process 50 bytes from that
memory block.

The caller (the command processor) did not touch bytes 33 - 50 of that
block, and no one knows for sure what previous memory operations did.
So what's in there might be blanks or it might not be. It's variable
depending on the state of the memory pool your job is running in.

--buck