Yves, As far as I can see all the "alternatives" which have been suggested to you may be available only if you anticipated a disaster such as you describe. If you had anticipated such a disaster it is unlikely you would have posted your "help request". There's a "Catch 22" in there somewhere!
So probably this suggestion from Barry is your best bet - assuming these changes haven't equally prevented you from starting your "TCPIP" procedure ... I don't actually have a novel solution for you. I do have a suggestion for when you do get back on your feet with the first item on your "to do" list to ensure such a disaster cannot happen again. For the education/test systems I used to run under VM I could usually rely upon a "production" MVS to fix up any of my disks, typically one shared and one per MVS. For some reason - maybe I was inconvenienced once by the "production" system being down - I decided that I should have a VTAM procedure and a TSO logon procedure which was the absolute bare minimum for getting access to my libraries, in other words, exactly what you needed when you posted. This VTAM procedure and TSO logon procedure would have no dependencies on any customization. I don't have it for reference now but I believe I took care of RACF dependencies as well somehow. Something very much like this is probably worth setting up for the "next time". There's some talk in one of your reply posts of using products with a "terminal interface". Surely such a product is also relying on VTAM. The suggestion simply - on a temporary basis - to APF-authorise the errant library is, of course, also a possibility. The possibility to use SMCS consoles has been introduced since I used to have my systems. I expect, if you are using these SMCS consoles in general, it is prudent always to have at least one console which does not depend on VTAM. Chris Mason ----- Original Message ----- From: "Schwarz, Barry A" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 23 June, 2006 4:13 PM Subject: Re: Help: User.parmlib inadvertently renamed > The last time I did something similar, I was able to FTP into the system > (since only VTAM was broken), GET the parmlib member, update it on a > PC/Sun (don't remember which), PUT it back into parmlib, and then IPL > successfully. > > -----Original Message----- > From: Yves Lederrey [mailto:[EMAIL PROTECTED] > Sent: Friday, June 23, 2006 6:55 AM > To: [email protected] > Subject: Help: User.parmlib inadvertently renamed > > Sorry to disturb you! > > I've inadvertently moved the User.datasets to another disk (where they > are know as User1.Datasets. > > But I've forgotten to change the Parmlib assignment in the sys1.parmlib > dataset > > Consequence: I can no longer IPL: I receive a message saying that > User.parmlib was not found on Z7SYS1, and the VTAM abends saying that > one module is in a non authorized library. > > No TSO session can be open to fix the problem. > > I tried to IPL with Cold start (DC) and warm start (DB): same result. > > Any idea how I could fix this ? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
