On Tuesday, 05/14/2002 at 08:09 MST, Lionel Dyck <[EMAIL PROTECTED]> wrote: > As a migration tool it isn't even adequate as even a screwdriver can be > used for multiple things whereas SAF is too limited and if it was intended > as a migration vehicle to eventually get the site to a native z/VM it > falls miserably short as with SAF active you can't do anything but SAF and > Linux so you can't learn native z/VM. > > At a minimum the SAF doc should indicate to first install z/VM and then > install a 2nd z/VM under the first and to activate SAF there so that you > have a real z/VM to learn with as you can't guarantee that there is an > available LPAR to install z/VM in for experimentation.
Lionel, the design point of SAF was compatibility with VIF. It provides a path so that that a VIF customer can migrate to z/VM *so they can stop using the VIF command and use native VM functions instead. The whole idea of a simplified VM command-line sysadmin interface has proved to be (IMO) untenable. There are simply too many knobs, levers, bells, whistles, and portals that have developed over the last 30 years to allow a meaningful simplification of the magnitude imposed by SAF and VIF. How does one create a 2nd level system without learning enough directory management to make SAF unnecessary? Chicken and the egg. z/VM 4.3 introduced the IP Configuration Wizard and an ifconfig command to handle TCP/IP stuff. DIRMAINT does the heavy lifting for directory management. Those three things do most of what VIF/SAF did for you. Bottom line: The moment you decided that you needed to update the directory for yourself, you outgrew SAF. We're pushing you out of the nest. Fly and be free! :-) Alan Altmark Sr. Software Engineer IBM z/VM Development
