On 1/30/17, 4:44 AM, Rob Berendt wrote:
Ok, I'm a bit confused. Shouldn't that be
OBJ(&LIB/&OBJname)
and not
OBJ(&LIB/&MBRname)
unless &OBJNAME = &MBRNAME
Yes. The object created has the name in &MBRNAME. Even though it's a
script being processed by RUNSQLSTM, I followed the "normal" AS/400
convention of having the member name the same as the name of the object
the member produces.
Unfortunately, it's not practical for me to simply reproduce the problem
"on demand," because it's a customer's production box, these are
production views, and I was in on a Saturday evening in order to track
down an entirely different bug that only peripherally involved the views
in question.
At any rate, not long after I posted the question, it began to ring some
bells with me, particularly since the CL program in question is one
that's being called repeatedly, with different values for &MBRNAME, and
it's only throwing the exception for some of them. I think I *have* seen
*exactly* this exception before, and I think it was on the same box. I'm
guessing that . . .
(1) The RUNSQLSTM is returning control to the calling CL program before
everything is completely settled, and
(2) the GRTOBJAUT is then getting stuck, and is somehow not noticing
that the proverbial "other two philosophers" have made the "forks" it
needs available, and
(3) the object creation defaults for this particular box are set in such
a way that the GRTOBJAUT isn't actually necessary.
Assuming this,
(1) Somebody refresh my memory: I seem to recall that there should be a
way to make the GRTOBJAUT throw the exception immediately, instead of
waiting;
(2) If I MONMSG that exception and if it comes up, then DLYJOB for a
second or two, then try the GRTOBJAUT again, would that solve the problem?
The weird part is that this glitch seems to only happen when the CL
program is being called from a terminal session. Normally, it gets
called in a batch job, as a step in an "environment rebuild" process run
from a much bigger, much more complex CL program.
--
JHHL
midrange.com
