Re: This is weird: lock problems where none should exist!

You could also do an ALCOBJ. File and member not found will throw a error,
which can be monitored. Error thrown, DLYJOB for 1 second and try again.
Might want to limit retries so the job doesn't get caught in a loop. Also
need to DLCOBJ to remoe the lock no matter how the CL ends.

John McKee

On Mon, Jan 30, 2017 at 10:47 AM, James H. H. Lampert <
jamesl@xxxxxxxxxxxxxxxxx> wrote:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD