Re: SQL Triggers where Production and Test on Same iSeries

[CRPence <CRPbottle@xxxxxxxxx>]

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