Yolanda, Thank you for your reply. It sounds as if we're in the same situation. We (the people who maintain and support USS here) have been trying for almost 2 years to get our management to realize how vulnerable we are. Finally, we had 2 system outages, due to a latch contention owned by OMVS, and I reminded our management that this was the type of situation we were concerned about. We educated them on the other scary issues with USS and now they say "go forth and fix it...NOW".
I'll be talking with as many people as I can find and attending the SHARE conference in Boston next month to take the issue to IBM and any vendors who will listen. It sounds like you are on the right track towards solutions. I hope that you'll be willing to share additional information. I'll share what I learn also. Regards, Lynette -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Yolanda Vivar Sent: Monday, July 04, 2005 3:38 AM To: [email protected] Subject: Re: Best practices for administration/maintenance of USS in production Hi Lynette, I have also posted to both lists the same concern some months ago. Also we feel lost in the USS black box. Nowadays we have a lot of applications running over USS and a problem in the USS is affecting critical production applications. We miss documentation faced to define the best methods for taking care of USS and for monitoring the USS events. Neither in the last Technical Conferences I have found anything related with USS. For now we don't share HFSs (for performance reasons) and we don't have zFS (but we plan to go to zFS next year). We have the /etc, /var, /tmp, /dev in separate HFSs outside the ROOT. About your questions, I'll try to answer you: Propagate a change to multiple production systems: - If is affecting the ROOT or product code installed through SMPE we create the HFS in the SMPE environment and from there we transfer the HFS affected to the others environments. We keep the old version in case we have to back out. - For the rest: we change the file affected system by system using the BPXBATCH and executing a script that makes the change. We always keep an .OLD version of the UNIX file that we change in order to back out if needed. Backup/restore: - For ROOT, ETC, VAR, DEV TMP HFSs we make a weekly copy outside HSM. In case of problems we have a process that renames the copy to active. - For applications, we make HSM copies and TSM copies (for critical directories). How to track who changed what and when?. We are working right now on it. We have been looking different alternatives (ussACTION - ACTION SOFTWARE, CA/ENFuss - CA) and right now we are working for implementing the use of register SMF80 to obtain the information through our tools. Another big concern that we have is how to implement a proper secure environment for our USS system. In the last times, for second time, someone with superuser authority did an 'rm - R' command from the / directory by mistake... How to monitor the health of USS?: that's our big issue!!!. We don't know. We have been locking for different monitors but we were not so convinced about any of them. Some weeks ago we had to IPL the system because of a latch contention owned by OMVS. We felt quite lost about it: we had no tools for diagnostic of the situation ( except through a dump). It would be really interesting to have a SHARE presentation. I have missed in the last events conferences about USS. Regards, Yolanda Vivar. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
