> Seems reasonable (-t0, anyone..?:). I'll consider including a > respective > parameter in a future version of zipl.
How about -n (do all the validation you're going to do anyway, but skip actually doing anything, a la make)? Offhand, dunno whether -n is already taken for something else, though. > 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. Certainly for new deployments, anyway. I'm mostly concerned with the problem of assessing something that may already be in place where something "weird" has been done that didn't make it into zipl.conf for some reason. Sounds like there's no nice way to do that. Would it make sense to "force" updates into zipl.conf and gradually remove the cmdline arguments? -- db ---------------------------------------------------------------------- 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
