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



Hey Chuck thanks for all the information provided. I wanted to let you
know that I came across this error again (actually I purposely allowed it
to happen). I did a CLRLIB QTEMP and I no longer get the error message.
So I might suggest that we change the environment command to issue CLRLIB
QTEMP.



On Wed, Apr 10, 2013 at 5:26 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

The CLRLIB QTEMP was of no assist in my testing; and would not be
compatible with my environment, perhaps not most environments. That is
rarely a circumvention that merits a UR1 [i.e. "fixed in a future
release"] closing of an APAR. I think maybe the issue might be due to
some OPM static storage instead... that requires static storage is not
reset for the end of the routing step due to RRTJOB, which I believe
accurately describes the OPM static storage.?.?; I do not remember, as
it's been too long.

I think the issue will likely have to be reported as defect, in order
to get a resolution that does not require using an undesirable
circumvention; i.e. an APAR and PTF.

I have been working on other things, and now I have yet other stuff
to do [outside] for the rest of the day, so I have not and will not get
to the scripting until tonight. That means more ideas for possible
circumventions are also further delayed.

--
Regards, Chuck

On 10 Apr 2013 14:02, Michael Schutte wrote:
that kinda leads me to something. When the CHGENV command is issued,
(that's our custom command provided by the vendor) issue CLRLIB QTEMP
?

On Wed, Apr 10, 2013 at 3:32 PM, CRPence wrote:

I think the problem is purely a run-time issue with two
[effectively] identical trigger programs being run in the same job,
and probably due to the routing step having ended but the job and
the contents of QTEMP remain. To the SQL the job may appear to be
new in most every way but whatever is [what the SQL created] in
QTEMP; i.e. the SQL is probably not fully /routing step/ aware.
Again, probably a defect issue [unless there is some doc that a new
routing step is a restriction]... but I will look further at the
recreates anyhow, primarily for what might be a circumvention, and
secondarily to provide the recreate script to be submitted with a
PMR.

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.