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



Okay, switching between production and test without clrlib qtemp. I would
get the message the first record I try to update after switching. Then it
seemed to work just fine. But other times, I would get the message after
each of the first 5 updates to the record. Finally after the 6th try I
stopped getting the message. but once the message stopped showing up, it
never came back up.




On Fri, Apr 12, 2013 at 4:31 PM, Michael Schutte <mschutte369@xxxxxxxxx>wrote:

Well crap. I always assumed that I was completely screwed after the first
blow up and always just signed off and signed back on. Never bothered with
trying again to see what happens. After the first blow up, I issued the
CLRLIB QTEMP I'll give it ago and see what happens again.


On Fri, Apr 12, 2013 at 4:18 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

Is that to suggest that a CLRLIB after the error allowed a repeated
invocation of the previously failed INSERT to operate without the
failure? If so, that is not any indication of success. Reason being,
the second request to perform the same insert always functioned without
error [for me anyway].

Or is that to suggest that placing a CLRLIB as part of the CHGENV was
verified to be preventive to the error? My claim that CLRLIB QTEMP was
of no assist, was when the CLRLIB was part of the of the reset from test
to prod [or reverse]; though I think I only ever tried the CLRLIB after
the RRTJOB, not before RRTJOB.

I have been stalled in further review because I have been up against
my storage limit on the system I am using. I am trying to pore over
what I have on the system, deciding what I can outright purge or instead
what of source and or objects I can move elsewhere. Slow and tedious,
because I have only ever created /small/ stuff specifically to avoid
hitting the limit, so there are no big objects to delete to get back
easily lots of storage. I even cleared out all of my interactive SQL
sessions and reset my only journal... and I am still ~97%.

Regards, Chuck

On 12 Apr 2013 12:44, Michael Schutte wrote:
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 wrote:

The CLRLIB QTEMP was of no assist in my testing; and would not be
compatible with my environment, perhaps not most environments.
<<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.