Cameron, > Does anyone have a clearer description of how to use the CPFORMAT exec for > formatting DASD? As Scott points out, there is a help screen and a section in the Virtualization Cookbooks. Basically it's: ==> CPFORMAT <rdev range> AS <PAGE|PERM|SPOL|TDSK>
CPFORMAT is not standard with z/VM - it is a wrapper around CPFMTXA (which is itself a wrapper around ICKDSF, as mentioned) and has been in all tar files associated with each Virtualization Cookbook. It performs two main tasks beyond what CPFMTXA does: (1) It allows multiple DASD to be formatted following the "CP QUERY rdev" format (2) It automatically labels DASD using a convention of "<char 1><char 2><rdev>" If I have more than a couple of DASD to format, I use it (to avoid work :)). Let's say you have 100 3390-3s to format - CPMFTXA becomes monotonous, and monotony leads to errors. There's been a lot of discussion on (2). Many z/VM sysadmins don't like having the 4 character rdev in a 6 character label. If you don't, then CPFORMAT is not for you. For us in our shop, this convention has worked fine for a number of years. There's a variable in the EXEC that sets the first character in the label (i.e.: firstChar = 'U' /* change this for an LPAR ID other than 'U' */), so you can choose a different character for each z/VM LPAR (if you have more than 26 z/VM LPARs, they you should probably be consolidating :)) Jeff G then comments: > Personally I find it much easier to understand what's happening when > I'm using the utilities directly - as per their respective manuals - > than I do when having my elbow joggled by, 'helpful' wrappers. They > perhaps have their place when starting out but I find that - because > of their necessarily limited nature - they can quickly become > unhelpful and inhibitors to true progress and understanding > > Regards > Jeff (Currently struggling to understand exactly what SERVICE ALL > really does under the covers) Gribbin >> (A. a lot :)) <soapbox> Let me opine for a bit on this one. I was born at a very early age (sorry, just kidding :)). In 2004, a group of IBMers were asked to solve a problem that came out of the zBLC. My understanding is that a number of z/OS sysadmins were asked "What do you want in Linux on the mainframe?" The answer was "We want z/VM and Linux to be as easy to use as an appliance". So that was the goal. A zBLC working group was formed, led by Tim Kane and Donna Von Dehsen. It proposed three possibilities, trying to address the issue within about six months: (1) Levanta, (2) IBM Director, and (3) "roll your own". For (1), I believe Levanta was starting to have financial issues. For (2), I believe that the Director z code would not be ready given the short runway. So (3) was the last option standing. Myself, Jin Xiong and Curtis Gearhart wrote a Redbook with the title "z/VM and Linux on zSeries: From LPAR to Virtual Servers in Two Days" (Mark, you were right, that was a poor title :)). It was published early in 2005. We perhaps overdid the number of 'helpful wrappers' in this first book. There were quite a number of scripts, especially on the Linux side. We also got some good feedback, a number of people also wanted to help write follow-on books, and customers asked for more. So we kept them up to date, changing the titles to "Virtualization Cookbook"s. We also got some not-so-good feedback - that there were too many "magic scripts" as Jeff alludes to. Most of those scripts have fallen out. However, three have remained, two on the z/VM side and one on the Linux side: (1) CPFORMAT EXEC - as discussed above (2) CHPWvrm EXEC (where vrm is z/VM version, release, mod) - an EXEC to change all passwords in the default USER DIRECT file (3) clone.sh - a bash script to clone a Linux For (2), I believe it is also monotonous and error-prone to change all default passwords in a new z/VM system, but is necessary for good security. So this EXEC persists. When I get a new z/VM system going, one of the first things I do is FTP (1) and (2) EXECs over. For (3), we have added sections in the books on how to first clone manually. We still get feedback that the clone scripts are useful. Brad Hinson now maintains the script for the RHEL distros, and Marian Gasparovic of IBM and Mark Post of SLES/Novell/Attachmate have helped me maintain the script for SLES distros. So Jeff, I agree with you that sysadmins should know how to use the utilities directly, and know where to find help and the manuals. However, when a wrapper can make you more productive, and allow fewer chances for typos or just dumb mistakes, then by all means, use the wrappers. </soapbox> Getting back to the thread, Cameron also writes: > I'm using the SLES10 Cookbook Redbook and was doing fine > up to this point. SLES 10, really? There is a new book this year for SLES 11 SP1 - see http://www.redbooks.ibm.com/abstracts/sg247932.html I hope this helps. "Mike MacIsaac" <[email protected]> (845) 433-7061 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
