OpenVMS System Management

1. OpenVMS System Management A different perspective by Andy Park TrueBit b.v.

2. Daily life of a system manager? • Installing some hardware • Installing some software • Adding a user • Doing a backup • Starting an application • Booting a system • Checking the network Andy Park

3. There is more to it than that! • Sorting out incidents, and problems. • Making changes. • Repetitive daily tasks. • Writing scripts to aid with repetitive tasks. • Department meetings. • Etc... Andy Park

4. But most of the time! • A large proportion of the time of system managers goes into: • either doing repetitive daily tasks, • or maintaining scripts to do repetitive daily tasks. • Usually each system has its own scripts. Andy Park

5. But how many systems? • Just one? • Two perhaps? • Ten? • Hundreds??? Andy Park

6. Are you organized? • Are the scripts the same on all systems? • You mean you have 10’s of procedures doing the same thing! • What do you do when you get another system? • What do you do when an application moves from one system to another? Andy Park

7. Get organized! • Manage all systems as a whole, not each system individually. • Scripts should be able to run on any system without any modification. Andy Park

8. Create flexible scripts • No embedded data. • Maintain the environment, on exit: • Reset privileges, • Reset messages, • Reset defaults. • Keep on top of errors. • Allow for different modes of operation. Andy Park

9. Isolate the scripts • Don’t keep scripts in user directories. • Users come and go. • Put them on a separate (logical) disk. • MANAGEMENT_DISK: • And those that must be in SYS$MANGER? • I’ll come back on that. Andy Park

10. Standardize scripts • Create a number of templates to use for making scripts, which include for example: • An introduction. (date, description, changes, etc.) • Code to save current environment. • Some space for the real work. • Code for error handling. • Code to restore saved environment. Andy Park

11. Management layers • Are you aware of the ICT management layers? • User Management • Application Management • Data Management • System Management • Network Management • If not, that’s a different presentation. Andy Park

12. Make top level directories to match • [USER] • [APPLICATION] • [DATA] • [SYSTEM] • [NETWORK] Andy Park

13. Subdivide layers • Each management layer involves many tasks for example: • User account management • Mail management • Backup • System startup • Check network counters Andy Park

14. Create products • Group together the scripts for each function. • Create products (or packages) • For example • [USER.ACCOUNT_MANAGEMENT] • May contain: • add_user, remove_user, modify_user ... Andy Park

15. You modify scripts on?? • Production system • Your kidding me! • Test System • Surely not! • Development system • Getting better but... Andy Park

16. Master Node • Chose one system as “master node”. • Keep your templates there. • Make all changes to scripts there. • It could be your development system. • But its better if its a separate system. Andy Park

17. And distribution then? • Done with: • UPDATE • BACKOUT • CLEAN Andy Park

18. UPDATE • Creates [.OLD] sub-directory. • Moves current version of product to [.OLD]. • Copies product from master node to this node. • Executes product install procedure to: • Put files is special places like sys$manager, • (Re-) start batch jobs, • Do what needs to be done. Andy Park

19. Note: • All of the current product is moved to [.OLD] • Therefor: • Keep “permanent” files in subdirectories: • [.LOG] • [.DAT] • [.HISTORY] • [.XYZ] Andy Park

20. BACKOUT • Deletes current product. • Moves [.OLD] back to current. • Executes product install procedure. Andy Park

21. CLEAN • Delete contents of [.OLD]. Andy Park

22. DIRTY • Only our minds? Andy Park

23. Also needed: • Product.VERSION • Product.RELEASE_NOTES • Product.DOCUMENTATION Andy Park

24. Clusters • In a cluster only one management_disk:. • UPDATE gets new version. • UPDATE runs product install on all nodes. Andy Park

25. On all nodes? • But I only need it to run on one node in the cluster! • For that matter, just specific systems out of all the systems we have! • Now we come back to how to control the scripts. Andy Park

26. Data for the scripts • Scripts must remain identical on all nodes. • Use data to determine what they should do. • An easy source of data is logical names. Andy Park

27. Logical names • You can put a lot of information in logical names. • You have fast access (they are in memory). • Easily accessed by scripts and programs. • But you will need a lot of them. Andy Park

28. Separate table • Create a separate logical name table: • Ensures you can not interfere with others. • No one else can interfere with you. • I call it the “FINGER PRINT” for a node. • Identifies exactly what the system is supposed to do, when, how…. Andy Park

29. An example $ ASSIGN/TABLE=FPT 1,”00:30:00”,- ”VOLUME_REBUILD,SHOW_USED” -NODE_HAS_DISK_CHECK 1 = Disk check runs on this node “00:30:00” = early in the morning and of all the functions it can do just do the volume rebuild and show used disk space Andy Park

30. Not only your product info • For each product you create there will be an entry in the table. • Also for each manageable object there can be an entry: • Could be software from others. • Could be hardware. • Could be people. Andy Park

31. Software • You need to know which software packages are on each system. • Someone will have to start them when the system boots. • The products you make will interact with layered products and applications from other sources. Andy Park

32. Hardware • Which disks do I have? • they need mounting, backup-ing, checking, defragmenting, • Which tapes do I have? • Are they used by backup? • Any special I/O devices? • Even something as trivial as the system serial number can be in the finger print. Andy Park

33. People • Mail account of system manager • “When you got a problem, who do you call?” Andy Park

34. How do you fill the table? • Several possibilities: • Node specific command procedure. • Procedure that processes node specific data file. • I make it using: • Site wide command procedure (sets defaults). • Then call cluster wide procedure. • Then call node specific procedure. Andy Park

35. When do you make it? • As soon as possible. • There are several call-outs in the startup of OpenVMS to site specific procedures. • SYCONFIG is currently the first. • Use it to set up your finger print i.e. your configuration. Andy Park

36. Which means: • One of your first products will be • [SYSTEM.STARTUP] • Containing: • the procedures to make the fingerprints • the site specific startup procedures which: • use the finger print to start the system. Andy Park

37. Still with me? • Standard directory structure. • Standard style scripts. (Templates) • Standard “products” created on master node. • Distributed using product “UPDATE” • Each node has a finger print specifying its role in the world. • Distributed in product “STARTUP” Andy Park

38. One job less for the system manager • Did you notice that log files were in [.LOG]? • It is now easy to make a product that scans management_disk:[*.*.log]*.log for all of those “-F-” ’s and “-E-” ’s, and mail the results back to the system manager. Andy Park

39. Still with me? • You now have standard error checking. Andy Park

40. Scheduling • Did you notice that there were time specifications in the finger print? • Your next project is to make a simple scheduler product to run the jobs of all the other products. Andy Park

41. I’m out of breath • You have a standard environment on all of your systems. • A set of software “products” • Each system has a finger print which tells the products what they should, or should not, do. Andy Park

42. Any Questions? • The simple ones I’ll answer now. • The complex ones you can take up with TrueBit. Andy Park

43. Thanks for listening! • A.Park@truebit.nl Andy Park