Damaged Objects/Upgrade Question -- MIDRANGE-L

I've got a couple questions, I'd like wiser and cooler heads to ponder and
give me any feedback you can.

Before I ask the questions, I have to setup the circumstances so you'll
understand what a mess this really is.  I mentioned some of this in an
earlier post, but for brevity only hit the high points, but here is the
whole sad, lurid tale:

We have a 3-year old model 9406-170 running V4R4.  It was out intent to
upgrade to V5R1 skipping V4R5.  We have an FSIOP card and one Ethernet
controller, model 2838.

I went through the memo to users and all the installation preparation steps
to the letter and (I thought) I'd gotten everything down right; however, I
blew it big time.  I knew that the FSIOP would not work under V5R1, and
don't need it anyway, and I understood the limitation that a dedicated
ethernet card for the FSIOP would not work.  I misinterpreted the
documentation, believing that because the 2838 is a standalone ethernet
card it would work.  I didn't realize that card slot position in the
machine was slaving it to the FSIOP and therefore would fail under
V5R1.  Just a dumb, dumb mistake on my part.

Now here's where bad luck sets in.  We had our normal backups, we got the
system prepared according to the instructions, cleaned the tape drives,
used new tapes and checked all the problem logs.  The machine had a clean
bill of health - it's never given us a moment of trouble.

I performed a SAVSTG immediately before beginning the upgrade.  The upgrade
went smoothly, until the final IPL to restart the system.  It began
reporting an urgent disk controller failure (70% probability of battery
failure, 30% hardware).  because of certain budgetary restriction, we did
not have hardware maintenance, so I couldn't just call
someone.  Diagnostics indicated that the system was working, but that
performance was degraded.

Now I run into the ethernet controller problem, I cannot activate TCP/IP,
and since everything except the console is TCP/IP I've got a real
problem.  I hunt, I search, and finally on some long-forgotten IBM UK
website I find documentation that lets me figure out that I can use my 2838
only if I remove the FSIOP board and move the 2838 to a different
designated slot.  (I later confirmed that was correct.)

But, I didn't have the time before the weekend was over, and I didn't want
to alter the hardware settings while I had a disk controller problem, since
I needed to call a time and material repair on it.

I initiated a restore storage to bring the system back to pre-upgrade
status.  After the restore storage, the system was mostly OK, except that
any program attempting to use an SQL collection or other database under
commitment control (including the problem database) would result in a
machine check.  Unable to find a solution, I concluded that it was a
damaged object during the restore, so, I wiped the machine and did another
restore storage.  Same problem.  Conclusion:  Damage occurred during
backup, not restore.

I did a reload of the OS from the distribution media, then applied our
daily backups and brought the system back on-line.

I got the controller repaired.

Now, there's still two things acting badly:

First problem: I cannot load the CUM PTF package, it fails during apply.  I
was able to apply most of the PTFs manually, but about 36 of them (mostly
in 5769999, 5769SS1 and 5769JV1) won't apply because they insist they need
a prior PTF to be loaded.  The PTF shows being loaded, but doing a display
yields no information.  I struck down the PTF indexes and rebuilt them, to
no avail.  Trying to delete the phantom PTFs yields "PTF Not
Loaded",  (They are all "permanently applied")

I'm guessing this is because when I reloaded the OS I must have missed the
"wipe the system option", but I thought I had done it.  It certainly acted
like it initialized the system.  And now, It thinks some of the previously
permanently applied PTFs are still there when they aren't.  That is, until
it tries to use the PTF to apply a later one, then it realizes its mistake.

Second problem:  I have several UDFs which were created previously to this
fiasco, they are still there and work; however, I cannot create new ones or
delete the old ones.  When I try to drop one, I get "Token FUNCTION was not
valid.  Valid tokens: PROCEDURE ROUTINE."  Which is what I'd expect of a
V4R3 machine as function was added in V4R4.

Everything on the machine checks out as V4R4, and yet this error persists.

My assumption is either I still have a corrupt object or objects in the OS
at the DB level, or one of the unappliable or missing PTFs is causing this
problem.

Other than that, though, we're working, data is not being corrupted,
hardware is all fine.  They're more of a nuisance at the moment.

It was a long message getting here, and my crashed-system headache has
returned just retelling this, but here are my questions:

(1)  Ignoring the ethernet problem for the moment, given that there are
missing PTFs and potentially corrupt system objects, would loading a newer
version of the OS (V4R5, for instance because I wouldn't yet need to deal
with the ethernet controller issue) most likely eliminate all V4R4 system
objects and make all V4R4 PTFs go away?  Or will I have to nuke it from
orbit first?

(2)  Concerning the ethernet controller.  I confirmed with CEs that the
movement of the ethernet card and removal of the FSIOP would enable that
controller to work under V5R1; however, on an old CISC box I knew the
hardware setup backwards and forwards (and had the manuals) - the RISC is
different enough to give me pause and I have been unable to find the proper
manual that describes the procedure of installing the card in enough detail
to give me confidence in making the change myself.  Has anyone here done
that change?  Or have any feedback on the process (or a link to a manual
would be great too?)


(OK, that felt good just getting it out of my system - must be why people
do psychotherapy.)