Pretty good list, Tom, I would add:
1) Reporting for the auditors (racf violations, etc)
2) Get EREP running and be able to produce reports in case the CE's need
them
This includes the collection of erep data, of course.
3) Hopefully you already have a scheduler or vmserve to run nightly tasks.
4) If you have RACF, backup the db and practice restoring it.
5) Hopefully you've set up prop or something similar to catch important
messages and act on them. Either clear up the problem or send an email to
yourself about it. (Mailit is a useful tool for this) I had dozens of little
rexx execs for stuff like this. Purge diskacnt's 191 files older than 90
days, etc.
6) If you have perfkit, make sure you are capturing console messages and
doing something with them. Perfkit will check the health of the system based
on your specs. But you've gotta be seeing the msgs.
Mary Anne
On Tue, Jun 2, 2009 at 12:51 PM, Tom Duerbusch
<duerbus...@stlouiscity.com>wrote:
> A lot of it also depends on local practices.
>
> 1. Backups....scheduled..and monitored.
> 2. Disaster recovery.
> 3. Someone, other than yourself, trained, on fixing common problems.
> 4. Usually, the working size is bigger as you have more users. Change the
> virtual size and monitor the vdisk swap disks.
> 5. SET SHARE a little higher, but only if you really need to.
> 6. Perhaps QUICKDSP OFF. Only if q drops have become a problem.
> 7. Some method for Operations (or others) to make sure the machine is
> operating properly.
> 8. Automated startup and shutdown.
> 9. Be comfortable with restores.
> 10. Be comfortable with applying maintenance, and backing it out.
> 11. Documentation (what? did I say that...naaaa)
> 12. Make a decision if it should be in its own LPAR, without VM. I doubt
> most of us have that case.
> 13. Should it be part of a VSWITCH, or have dedicated OSA addresses,
> perhaps with the port (ethernet) dedicated if it needs the bandwidth.
> 14. Some sort of IP fail over.
> 15. Service contracts on your hardware/software.
> 16. A good performance monitor. (I don't have one, "money", but it makes
> things a lot easier and faster to respond and debug.)
>
>
>
> Does all of this really, really get done up front? Noop. Eventually, it
> will, when enough people scream!
>
> Tom Duerbusch
> THD Consulting
>
> >>> Dave Jones <d...@vsoft-software.com> 6/1/2009 6:37 PM >>>
> Hi, Sunny.
>
> Can you explain what you mean by 'more special'? Give it more access to
> real resources? Insure that it gets dispatched before the test guests?
>
> Have a good one.
>
> sunny...@wcb.ab.ca wrote:
> > We put the test, develop and production zlinux environment in the same
> > z/VM partition.
> > So what we must do to make the production zLinux more 'special' than
> > others?
> > I understand it is the shared environment.
> >
> >
> >
> > Sunny Hu
> > sunny...@wcb.ab.ca
> >
> > This message is intended only for the addressee. It may contain
> privileged or confidential information. Any unauthorized disclosure is
> strictly prohibited. If you have received this message in error, please
> notify us immediately so that we may correct our internal records. Please
> then delete the original email. Thank you. (Sent by Webgate2)
> >
>
> --
> Dave Jones
> V/Soft
> www.vsoft-software.com
> Houston, TX
> 281.578.7544
>
