Dynamic Hardware Configuration Changes

Dynamic Hardware Configuration Changes

Back in MPE/iX ‘Release 5.5, Hewlett-Packard created tools to manage hardware configurations dynamically. Online configuration management was a welcome enhancement that will save countless hours of downtime that typically is spent rebooting systems for such simple changes as adding a printer or changing a baud rate or device class. This article is intended to give you the requisite information to guide you through the jungle of configuration changes and to point out the hidden traps along the way.

System hardware configuration changes are made using either SYSGEN or NMMGR, depending upon the type of device that is configured. Serial (RS232 and RS422) devices such as dumb terminals, modems, and serial printers are configured in NMMGR. Devices such as disk drives, tape drives and network printers are configured in SYSGEN. Separate tools have been developed for both types of configuration changes.

NMMGR Changes.

Dynamic NMMGR changes are implemented when you validate the DTS subsystem inside of NMMGR. After cross validating with SYSGEN you will see a prompt like this:

Copying validated configuration file to backup file, please wait ***

Do you want DTS changes to become active now (Y/N)?

When you answer “Y” to the prompt, NMMGR runs the command file DTCCNTRL.PUB.SYS. Further examination of DTCCNTRL reveals it offers a menu mode with extremely useful and powerful options:

0 exit

1 dynamically implement DTS changes made in NMMGR

2 view status of last DTS dynamic configuration

3 automatically add a new DTC

4 shut down DTS subsystem

5 restart DTS subsystem

6 manage/dynamically configure host-based X.25

7 help

Of particular interest is number 4 and number 5. These give you the ability to shut down and restart the DTS subsystem without rebooting the entire system. This will save you time making changes that cannot be implemented dynamically such as reconfiguring the remote console port. Understand that a successful shutdown of the DTS subsystem requires that no DTC devices can be owned by any user or spooler. You must log off all users, stop all spoolers, and log off any job that holds a DTC port open before attempting a DTS shutdown. Sessions coming in over virtual terminals can remain active.

You can also use option 5 to enable the DTS subsystem after a reboot if you receive an error message indicating the DTS subsystem is unavailable because the NMCONFIG file was not validated. You can validate the NMCONFIG file and then restart the DTS subsystem without requiring an extra reboot. We have a command file on available on our website that handles this situation as well as many others called PRESHUT which we recommend you run prior to a system shutdown. One of the many tasks it handles is to validate the NMCONFIG file.

One problem we have occasionally seen is that the system has been reconfigured, nevertheless the modification has not made it all the way through to the DTC port. Even a TERMDSM reset of the DTC won’t necessarily fully implement the new configuration. For these stubborn changes you must cycle power on the DTC to force a hard reset and a new download.

SYSGEN Changes.

Configuration changes in SYSGEN can also be implemented dynamically. The types of changes you can make are adding adapter cards, adding printers (extremely handy for creating new network printers on the fly), adding tape drives, adding disk drives, and modifying device classes. You can even use it to delete some devices from the configuration.

Changes are made through IOCONFIG.PUB.SYS that has a similar interface to SYSGEN with one major difference. When you make changes in IOCONFIG they take effect immediately as soon as you press the return key, there are no second chances. As you can see extra care should be taken to be certain the commands are entered accurately.

Modifications made via IOCONFIG are automatically saved to the last group you booted from upon exiting the program. If the last system reboot was a START NORECOVERY then the changes will be saved to CONFIG.SYS. However, if the last system restart was a START RECOVERY then IOCONFIG will attempt to save the changes to BOOTUP.SYS, which will fail because the operating system keeps the files in the BOOTUP group open at all times. If this happens then you will need to manually replicate your changes into SYSGEN.

An alternate method is to make the changes in SYSGEN first. After making your SYSGEN changes you can run the command file :DOIONOW (Do I/O Now) which essentially is a command file that runs the IOCONFIG program feeding it a script of commands generated by SYSGEN. There are several potential traps to this method. First, any logical device number that you add cannot be currently in use by a virtual terminal session or the DOIONOW will fail. Second, the log file that DOIONOW uses is not necessarily empty when you begin. It is imperative that you review this log file prior to executing the command to verify its contents. The file to review is LOG4ONLN.PUB.SYS.

Regardless of the method you choose you need to keep in mind that the changes are not permanent until you perform a START NORECOVERY. If you reboot your system with a START RECOVERY then the system reads the configuration from the BOOTUP.SYS group, while your changes were made to CONFIG.SYS. Consequently all dynamic changes you made will not be considered part of the current configuration. The only remedy to this situation is to re-enter your changes into IOCONFIG or to shut down and reboot with a START NORECOVERY.

Conclusion

Finding time to reboot today’s systems with the myriad of continually running background jobs is a difficult task. Moreover systems with larger memory configurations take much longer to reboot. By exercising caution and proper planning you can use the online configuration tools available to make new devices available sooner, and save hours of downtime in the process.