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

3. Andy Park 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

4. Andy Park 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...

5. Andy Park 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.

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

7. Andy Park 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?

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

9. Andy Park 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.

10. Andy Park 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.

11. Andy Park 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.

12. Andy Park 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.

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

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

15. Andy Park 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...

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

17. Andy Park 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.

18. Andy Park And distribution then? Done with: –UPDATE –BACKOUT –CLEAN

19. Andy Park 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.

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

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

22. Andy Park CLEAN Delete contents of [.OLD].

23. Andy Park DIRTY Only our minds?

24. Andy Park Also needed: Product.VERSION Product.RELEASE_NOTES Product.DOCUMENTATION

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

26. Andy Park 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.

27. Andy Park 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.

28. Andy Park 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.

29. Andy Park 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….

30. Andy Park 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

31. Andy Park 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.

32. Andy Park 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.

33. Andy Park 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.

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

35. Andy Park 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.

36. Andy Park 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.

37. Andy Park 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.

38. Andy Park 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”

39. Andy Park 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.

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

41. Andy Park 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.

42. Andy Park 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.

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

44. Andy Park Thanks for listening! A.Park@truebit.nl