Rob van der Heij <[EMAIL PROTECTED]> wrote: > <[EMAIL PROTECTED]> wrote: > > I think the most reasonable solution for scenarios where configuration > > management tools are used would be to impose a policy, only to use > > configurations supplied in the zipl.conf file. > > That's theory only. Even when you know that a bunch of files must be > copied to implement a change, we find it helpful to run an additional > check to verify that is has been done completely (and when possible > have someone else do the check). I am sure many others also have a > program to compare two CP load maps and eyeball the differences before > an IPL (or after one that failed ;-)
Trust zipl :) If it exits with a return code of 0, it should be safe to assume that the IPL record was written according to the provided configuration. If you're not sure about a new configuration, use the multiboot feature to be able to switch back to a working one. > I suppose it should not be that hard to include the relevant > information in the bootmap - say after the first word of 0 (or > whatever signals the loader the end of the list). And zipl -q could > retrieve that by reading the bootmap from the IPL records? I agree that putting the information into the bootmap file wouldn't be too hard, but I don't like the implications: zipl would need to be able to read bootmap files, put a version tag on the current format, make sure to identify files written by previous versions with no or different information. Once external tools access this file, there's no way to change the file format without causing chaos with users of that tool. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
