Re: QWCRSSTS problem

STRDBG has an interesting side effect of forcing an initialization of the automatic storage for each new program entering the stack. Normally, such initialization does not occur. Thus programs that improperly fail to initialize any variable(s) before a reference, such a program can experience a change in function when residual non-zero storage is referenced; actually, anything not its assumed default initialization. The program with the problem could be the API, or another program involving the processing for that API; e.g. the caller of the API. An HLL that should ensure initializations would be less likely to encounter that, but any failed assumptions of how initializations occur may lead to similar problems. The OPM [Origina Program Model] OS programs use a language that may not initialize when requested, and for performance reasons an OS program will ask specifically to avoid initialization activity. If such a problem exists with the QWCRSSTS API, then another invoker would be unlikely to reproduce the problem without similarly impacting the automatic storage that will later be referenced by the API; i.e. simply having the same compiled object or source to make the same call, would not typically reproduce the problem.

Regards, Chuck

Jonathan Ball wrote:

David FOXWELL wrote:

We need the system name in a program so we've been using
QWCRSSTS. Apparently, on rare occasions, we are getting blanks
in the name, with no error. I've been told to QWCRSSTS replace
with RTVNETA. I don't see the point in using QWCRNETA so I was
just going to create a CL module that does RTVNETA.

Once this is in place we won't know what was wrong with the
QWCRSSTS API.

Any thoughts?

I just began encountering the same phenomenon. Even stranger, if
I start debug on the program containing the call to QWCRSSTS and
set a breakpoint before the call, the API returns the system
name, every time. If I don't do that, or if I set the breakpoint
after the call to check the value returned, it is always blank.