Re: SQL Triggers where Production and Test on Same iSeries

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