On Tue, 29 Jan 2019 11:06:51 -0500, Bob Bridges wrote: >... >Anyway, we attempted the RESTORE, but we got lots and lots of error messages >saying we need to include other PTFs in the RESTORE. Some of these have an >indirect connection to A and B; B superceded at least three of them, for >example, which I can see were applied some years ago. Others have no relation >to our PTFs that I can discern. I haven't yet found the place in the User's >Guide that explains these relationship and their relevance. Can someone give >a helpful explanation? > >Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran >this thing in the past never did any ACCEPT, ever, except for the original >function code. I see at least 11 PTFs that were applied (including our two), >but the distribution library shows no PTFs for any module I've yet LISTed. If >true, does that mean that to do a RESTORE of our two PTFs we'll have to >RESTORE everything back to the plain-vanilla base? > Either that, or ACCEPT everything up to exactly the level you want to fall back to. RESTORE will revert only to an ACCEPTed service level.
>Question #3) My partner the not-sysprog has in mind that maybe we need to set >aside this CSI (which is dedicated to Top Secret) and create another one >starting with the base software and build up from there. I didn't realize >this could be done, but she thinks she can do it. If it'll work, I like it; >we'll know in that case what we have, which we do not at present. Anyone have >any thoughts on this plan? > Good idea. Or, even, copy the CSI (SMP/E has commands for this) and experiment on the copy. >Question #4) This is a less-important add-on: In both the online >documentation and the User's Guide, I read if I'm doing a RESTORE and name >PTFs A and B, including the GROUP operand causes SMP/E to add whatever other >PTFs are required for various reasons. It doesn't seem to, though; it names >them and complains about them, but doesn't add them to the list. Have I >misunderstood something? I'm loathe to believe the documentation is flat >wrong. > >If you're getting ready to send rushed messages saying "DON'T DO ANYTHING >UNTIL YOU'VE CHECKED...", relax; we're planning to go slow. > Unfortunately ACCEPT CHECK does not set things up properly for a RESTORE CHECK. SMP/E sorely needs an "UNDO" command (and associated UNDO CHECK) to revert the state exactly to an earlier service level. ACCEPT-RESTORE doesn't come close. The alternative is to HSM restore from an HSM backup. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
