RE: Restore system

Thanks to all for your responses to my urgent plea for help regarding
the CUM PTF that I wanted to "undo".  Several have asked for details on
the problem so I'll try to share those as briefly as possible.  Also, I
would like to give a brief synopsis of what I could have done (and will
do in the future) regarding CUM PTF's.

Synopsis of CUM PTF's:
Before installing my next CUM PTF, I'm going to apply permanent all
temporary PTF's.  That way, if I have to go back after installing the
CUM, I can simply re-IPL to side "A".  Some have mentioned that that's
not perfect since the CUM does install some of it's own PTFs
permanently, but this still seems the best way to me.  The other option
I faced was to do a system restore and the ramifications and
complexities of that were overwhelming.

The Problem:
The problem was with an SQL ILERPG program (which we use heavily here).
The following is the SQL statement that failed (note that the same
statement, whether run interactively thru STRSQL or in the ILERPG
program would fail):
        DECLARE C1 CURSOR FOR SELECT 'R', A.ITNBR, A.PDATE,
DATE('0001-01-01'), A.QUANTY, A.SDATE                           
        FROM REQMTSP A JOIN ITEMASA B ON A.ITNBR = B.ITNBR
        WHERE EXISTS (SELECT * FROM PLANNERP C WHERE B.PLANN = C.PLANN)

When we changed the subquery portion to the following, it worked:
        (SELECT C.PLANN FROM PLANNERP C WHERE B.PLANN = C.PLANN GROUP BY
C.PLANN)

It's a pretty basic SQL statement.  So why did it work when I changed
it?  Well, a little about the makeup of the PLANNERP file.  It's first
key field is PLANN and it's a non-unique key file.  I suspect (although
not confirmed by IBM) that this is a major ingredient to the cause of
the problem.

I could also get the SQL statement to work correctly if I changed the
SELECT clause to do a "SELECT * FROM...", so that may blow my first
theory out of the water, but I'm not sure.

The CUM PTF I installed was C9054430.  IBM still feels it's not
defective, but if I have time this weekend, I'm going to IPL from side
"A" and try to run the original SQL statement to see if it bombs.  The
thing that bothers me about this is that this isn't a very complex SQL
statement and there's nothing unusual about the makeup of the files
(other than the non-unique key file).  I would have thought that IBM
would have the basic SQL stuff tightened down better than this.  It also
bothers me because I've had 2 other SQL problems that I've dealt with
IBM on in the last few months.  Both of them turned out to be problems
on their end.  One was turned into an APAR situation and took a couple
months to resolve.  That one also was a pretty basic SQL statement.

Thanks again to all for your comments, suggestions, etc.

Dave
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---