× 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.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.