Re: Puzzling problem

Dean,

Moving the field simply changed where the field was in memory.

What's happening is that any data longer than the original length (1000 or whatever it was) was overwriting the computer's memory that just happened to come after the variable.

If that memory happened to be unused memory, then you wouldn't notice any problems... (though, it's something of a ticking time bomb, because any change to the program, OS, etc could change whether that memory happens to be in use.)

Moving the variable from global to a procedure just changed where it was in memory, and therefore changed whether it happened to overwrite something important.

-SK


On 5/7/2018 10:29 AM, Dean Eshleman wrote:

Scott,

Thanks for the explanation. I should have mentioned that we have multiple existing programs that seemed to be working just fine with the saved query string defined as 1000 varchar. I guess we just got lucky that they worked. I'll tell the developers to change the field size to 32767 in all of the programs.

Any thoughts on why moving the SavedQuery field from a global definition to a local definition in the sub-procedure where I call the ZhbGetInput also causes ZhbGetInput to fail every other time? This is when I have it defined as 32767 varchar.

I'll also try to contact Giovanni to get this fixed.

Dean

On 5/4/2018 5:57 PM, Scott Klement wrote:

Dean,

From your description, it sounds to me like CGIDEV2 should not have
options(*varsize) defined on the prototype. That seems like a bug in
CGIDEV2. You can work around the problem simply by always defining your
saved query string as 32767 or larger.

I'm guessing that whomever added this feature didn't understand what
options(*varsize) does, because if you look at the code inside
ZhbGetInput, it clearly does nothing to handle a *varsize field
properly... so any time the field is smaller than 32767, it will
overwrite random memory with blanks or data, potentially causing all
sorts of problems.

I'd suggest reporting the problem to Giovanni so that the procedure is
fixed, and in the mean time, simply ensure that the parameter is 32767
or larger and you'll be fine.

-SK



On 5/4/2018 4:24 PM, Dean Eshleman wrote:

I have a strange problem going on with one of my RPG programs. The
program is a REST web service and we are using CGIDEV2 and YAJL. In
one of my sub-procedures, I call a procedure that is part of CGIDEV2
called ZhbGetInput. Here is the prototype:

D ZhbGetInput pr 10i 0
D SavedQueryString...
D 32767 varying options(*varsize)
D qusec 516 options(*varsize)

I call it like this in the sub-procedure:
inputCount = ZhbGetInput(savedQuery: QUSEC);

These fields are defined as global fields as follows:
DCL-S InputCount int(10);
DCL-S SavedQuery varchar(32767);
I /include the definition for QUSEC from the CGIDEV2 source.

Here is where it gets interesting. If the SavedQuery field is defined
as less than 32767, the ZhbGetInput procedure blows up every other
time I call the web service with a low level "pointer not set for
location referenced" error in program QRNXINIT. The process aborts
and doesn't even return the error to my program. The first time I
call the program, it always works. Also, if I move the definition of
the SavedQuery field into the sub-procedure where it is used, it also
causes the same error every other time the program is called. The
field is only used on the call to ZhbGetInput. It seems like when the
program bombs, it cleans things up and then the next call is successful.

Anyone seen anything like this before? I assume something is
trampling on memory and messing things up, but I don't know where to
look. We are on V7R1, upgrading soon to V7R3.

______________________________________________________________________
Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmission errors in the future. Thank you.