System Z

Virtualization and Linux on System z Workshop
System z
Virtualization and Linux
Workshop
Part 1
Virtualization and z/VM
Presented by
IBM
1
User Agreement
This agreement ("Agreement") governs your use of the remotely accessed IBM system and the course
materials. By using the system or accessing the system (“Materials”) you agree to the terms of this
Agreement.
Under this Agreement, you may use the Materials only for the class attended and other use authorized
by IBM. Any other use (including distribution, reproduction, resale, publication or transmission) is not
permitted.
The Materials are provided on an "AS IS" basis. In addition, IBM makes no warranties or conditions,
either express or implied, including without limitation, warranties of title, non-infringement and the
implied warranties of merchantability and fitness for a particular purpose, concerning the Materials, or
any information accessed using the Materials.
The z/OS operating system and associated middleware Program(s) that were packaged with, or
preloaded onto, the IBM computer system are the property of the IBM Corporation. You receive no
express or implied patent or other license from IBM. IBM will not be liable for any damages resulting
from use of the Materials, including without limitation, lost profits, lost savings, or any incidental,
special or indirect damages or other economic consequential damages, even if IBM has been advised of
the possibility of such damages. Some jurisdictions do not allow the exclusion or limitation of
incidental or consequential damages, so the above limitation or exclusion may not apply to you.
This agreement does not grant you a license, either expressed or implied, to any IBM intellectual
property, including patents copyrights or trademarks. Unless IBM specifies otherwise, you may not
copy, modify, adapt, reproduce, translate, distribute, reverse engineer, decompile or disassemble any
aspect of the Materials. Neither IBM nor its Suppliers are responsible for: 1) the accuracy,
completeness, timeliness, reliability, content or availability of the Materials or any information
retrieved; 2) loss or damage to your records or data; or 3) your use of or results achieved from the
Materials or any information retrieved.
This Agreement is the complete and exclusive agreement regarding the Materials. IBM may, at any
time, 1) revoke your access to the Materials, or 2) modify, change or withdraw the Materials, in whole
or in part.
This Agreement is governed by the laws of the State of New York.
Notices
This information was developed for products and Materials offered in the U.S.A.
IBM may not offer the products, Materials, or features discussed in this document in other countries. Consult your local
IBM representative for information on the products and Materials currently available in your area. Any reference to an IBM
product, program, or Materials is not intended to state or imply that only that IBM product, program, or Materials may be
used. Any functionally equivalent product, program, or Materials that does not infringe any IBM intellectual property right
may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product,
program, or Materials.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of
this document does not give you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
2
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent
with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express
or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the
information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve
as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product
and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any
obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM
products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely
as possible, the examples include the names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming techniques on
various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application
programming interface for the operating platform for which the sample programs are written. These examples have not been
thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, Materials ability, or function of
these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the
purposes of developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
3
Table of Contents
Our Workshop Environment...................................................................................................................... 7
Hardware............................................................................................................................................... 7
Workshop partition................................................................................................................................7
Team virtual machine............................................................................................................................8
Manuals................................................................................................................................................. 8
Unit 1: System z Virtualization.................................................................................................................9
1.1 IPL z/VM.........................................................................................................................................9
Unit 2: The Control Program (CP) ..........................................................................................................13
2.1 Introduction................................................................................................................................... 13
2.2 Logon to MAINT ........................................................................................................................ 15
2.3 HELP............................................................................................................................................. 16
2.4 QUERY......................................................................................................................................... 16
2.5 VARY ...........................................................................................................................................19
2.6 ATTACH ......................................................................................................................................20
2.7 INDICATE ................................................................................................................................... 20
2.8 CPFMTXA ................................................................................................................................... 21
Unit 3: The Conversational Monitor System (CMS)............................................................................... 25
3.1 Introduction................................................................................................................................... 25
3.2 HELP............................................................................................................................................. 26
3.3 QUERY ........................................................................................................................................ 27
3.4 ACCESS .......................................................................................................................................27
3.5 COPYFILE....................................................................................................................................28
3.6 CP.................................................................................................................................................. 28
3.7 FILELIST...................................................................................................................................... 29
3.8 XEDIT........................................................................................................................................... 31
Unit 4: System Configuration ................................................................................................................. 33
4.1 Overview of the SYSTEM CONFIG file...................................................................................... 33
4.2 System parameter disks................................................................................................................. 33
4.3 Update the SYSTEM CONFIG file...............................................................................................33
4.4 CPSYNTAX .................................................................................................................................36
4.5 Restart z/VM and verify changes ................................................................................................ 37
Unit 5: Create Virtual Server................................................................................................................... 39
5.1 Overview of the User Directory.................................................................................................... 39
4
5.2 Create a profile ............................................................................................................................ 41

5.3 Create the LINUX1 virtual machine ........................................................................................... 42
5.4 DISKMAP..................................................................................................................................... 43
5.5 Protecting the volume id................................................................................................................43
5.6 DIRCTXA .................................................................................................................................... 44
5.7 Test LINUX1.................................................................................................................................44
Unit 6: Basic TCP/IP Configuration ....................................................................................................... 46
6.1 Overview....................................................................................................................................... 46
6.2 IPWIZARD................................................................................................................................... 48
6.3 Viewing TCP/IP configuration files..............................................................................................52
6.4 Verify the TCPIP setup................................................................................................................. 56
6.5 Setting up a virtual switch (VSWITCH) with failover..................................................................56
Unit 7: Performance Monitoring Tools....................................................................................................60
7.1 The z/VM Performance Toolkit.................................................................................................... 60
Unit 8: Install Linux .............................................................................................................................. 67
8.1 Prepare the Linux virtual machine................................................................................................ 67
8.2 Cloning a RHEL5 Linux server.....................................................................................................68
8.3 Add VDISK swap spaces.............................................................................................................. 71
8.4 Add a z/VM Guest LAN............................................................................................................... 72
Unit 9: Cloning Linux virtual servers...................................................................................................... 79
9.1 Add the LINUX2 virtual machine to z/VM.................................................................................. 79
9.2 Clone LINUX2.............................................................................................................................. 80
9.3 Configure the cloned server.......................................................................................................... 80
9.4 Reboot server with new network ..................................................................................................81
9.5 Test networking on both Linux systems........................................................................................81
Unit 10: Test the Virtual Switch failover capabilities .............................................................................83
10.1 Verify the VSWITCH setup ....................................................................................................... 83
10.2 Simulate an OSA failure..............................................................................................................83
10.3 Simulate a VSWITCH controller failure.....................................................................................84
Unit 11: Basic system automation........................................................................................................... 86
11.1 Startup and Shutdown Policy...................................................................................................... 86
11.2 Autolog Linux systems to boot at z/VM IPL.............................................................................. 86
11.3 Setting Linux systems to halt at z/VM shutdown .......................................................................87
11.4 Set up z/VM shutdown signals ...................................................................................................88
11.5 Shutdown a single Linux system.................................................................................................88
11.6 Start up a single Linux system.................................................................................................... 89
11.7 Shutdown z/VM......................................................................................................................... 89
5
11.8 IPL z/VM.....................................................................................................................................89

Unit 12: System z Device Drivers & Commands.................................................................................... 91
12.1 Display kernel modules .............................................................................................................. 91
12.2 z/VM CP interface device driver (vmcp).................................................................................... 91
12.3 z/VM Monitor stream - APPLDATA Support ........................................................................... 91
12.4 Cryptographic device driver........................................................................................................94
Unit 13: DCSS....................................................................................................................................... 102
13.1 z/VM DCSS and Execute-in-Place Technology ...................................................................... 102
Unit 14: References................................................................................................................................111
14.1 XEDIT Cheat Sheet...................................................................................................................111
14.2 Vi Cheat Sheet...........................................................................................................................114
14.3 Books.........................................................................................................................................115
14.4 Web Sites...................................................................................................................................115
6
Our Workshop Environment

Hardware
Processor type and model: System z9

LPAR 1
Number of configured partitions (LPAR): 29
Number of physical processors: 54
VM52 Workshop partition: VM52
LPAR n
Workshop partition
L T
M T T T
I E
A C E E
N A
I P A A
N M
N I M M
F 1
T P 1 2
S 5
PBCVM52 - z/VM 5.2

129.40.45.25
I/O and Network
Main: 12 GB Memory Expanded: 6 GB
Processors: 6 (shared)
LPAR VM52
7
Team virtual machine
200 201 202 203
520RES 520W01 520W02 52PGSP
300 301
20xx
SCSI
190
IPL 190 = boot CMS
CMS
(Logon default)
OSA devices: 800-802 900-902 A00-A02
Memory: 768 MB
Processors: 2 virtual CPUs
Team1
Manuals
The z/VM manuals are available online. You may access them through your browser on your laptop.
Access them through the following URL(s) and select the zVM BookShelf:
http://129.40.35.3/vmmanuals
If you need the manuals when you return home, they are available for download in PDF format from
the following URL: http://www.vm.ibm.com/library.
8
Unit 1: System z Virtualization

1.1 IPL z/VM
It’s time to boot your own z/VM environment to be used for the rest of the z/VM module.
1. Obtain a team number from the instructor:
Team number:________________________________________________________
z/VM IP address:_____________________________________________________
2. Connect to the first level z/VM system, known as PBCVM52.
Start the TN3270 client
Connect to IP address 129.40.45.25, port 23
3. Log on to the team ID assigned to you.
USERID ===> team<n> where is the team number assigned to you
PASSWORD ===> adrian
4. Logon messages appear in your VM console. You should see a console status at the bottom
right corner of VM READ which indicates the console is waiting for a command.
Press the Enter key
You should see the console status change to RUNNING. Your team ID is defined to IPL the
conversational monitoring system (CMS). IPL stands for “initial program load”. IPL’ing is the same as
booting. When you hit the enter key just now, the system executes a profile and completes the IPL
process. You will learn more about profiles later on.
9
5. Clear the messages from your console.

Press the Clear key (Pause key on most keyboards)
6. Enter the QUERY TERMINAL command to display your terminal settings.
===> query terminal
00: LINEND # , LINEDEL OFF, CHARDEL OFF, ESCAPE " , TABCHAR OFF
00: LINESIZE 080, ATTN OFF, APL OFF, TEXT OFF, MODE VM, HILIGHT OFF
00: CONMODE 3215, BREAKIN IMMED , BRKKEY PA1 , SCRNSAVE OFF
00: AUTOCR ON , MORE 050 010, HOLD ON , TIMESTAMP OFF, SYS3270 OFF
7. Notice the terminal’s console mode (conmode) is set to 3215. This is CMS’s default terminal console
mode. In order to boot z/VM, you need to change the conmode value to 3270.
===> terminal conmode 3270

This sets your virtual machine’s terminal to conmode 3270, and also drops you into a disabled
wait state as CMS cannot handle the 3270 conmode. This is OK because a z/VM system will
be booted.
8. Next display information about the console.
===> query console
00: CONS 0009 ON LDEV L0010 TERM STOP HOST TCPIP FROM 9.56.60.184
00: 0009 CL T NOCONT NOHOLD COPY 001 READY FORM STANDARD
00: 0009 TO TEAM11 PRT DIST TEAM11 FLASHC 000 DEST OFF
00: 0009 FLASH CHAR MDFY 0 FCB LPP OFF
00: 0009 3270 NOEOF CLOSED NOKEEP NOMSG NONAME
00: 0009 SUBCHANNEL = 000B
The output shows that the console address is 0009. We now have enough information to boot our z/VM:
the volume address to boot (IPL) is 200 and the console address (specified via the LOADPARM option)
10
to direct output is 0009.

9. Boot (IPL or Initial Program Load) your z/VM system.
===> ipl 200 clear loadparm 0009
10. If your screen shows “HOLDING” in the lower right corner
===> press the Pause key to clear the screen
Note that the system ID in the lower right hand is PBCVM52.
11. You should next see the Stand Alone Program Loader screen.
“Tab” to advance the cursor to the “IPL PARAMETERS” section
Enter “cons=0009”
Press the F10 key to load the z/VM system
12. Enter the rest of the IPL parameters as follows.

Press the “Pause” key whenever the lower right hand corner of your console shows
“MORE” or “HOLDING”.
When prompted to provide “start” parameters:
Enter “cold drain noautolog”
When prompted to “Change TOD clock”:
Press enter to accept the default “no”
When prompted to continue with “COLD start”:
11
Enter “go”
13. You have successfully IPL'ed z/VM when you receive the following messages:
These messages provide some basic information about your system:

● The system identifier is ZVMV5R30. It is also displayed at the lower right hand corner
of the console.
● The z/VM version 5.3.
● The OPERATOR user is currently logged on.
● The system has 512 MB of storage (memory).
14. Now disconnect from the 'OPERATOR' .
===> disconnect
Press the Pause key when the console status indicates “MORE...”
Press the Enter key to proceed
You should see the logon window for your second level z/VM system. This is the only session
available to log on users. Later on, you will enable TCP/IP which will allow multiple
connections to your system.
It is important to disconnect, not log off your system. Logging off from the system is equivalent
to turning off the computer, thus crashing your z/VM system.
12
Unit 2: The Control Program (CP)

2.1 Introduction
z/VM has two main components:
● The Control Program (CP) controls the Real machine.
● The Conversational Monitor System (CMS) controls Virtual Machines
The CP is sometimes called the hypervisor. It is the layer between the hardware and virtual machines. Each
virtual machine appears to have its own CPU, storage (memory), and devices. In reality, these items can be:
● Real. For example, you can dedicate a real network interface to a virtual machine for its exclusive use.
● Shared. For example, the CPU is shared through time sharing and real storage is shared as virtual
storage. What appears as real storage to a guest is actually virtual storage to CP.
● Simulated. For example, a virtual switch is a simulated LAN networking switch. CP transparently maps
virtual devices and resources to their real counterparts.
The following topics explain how CP manages computer resources for virtual machines.
2.1.1 Central processing units (CPUs)

A virtual machine can have up to 64 virtual CPUs. If capable of running in multiprocessor mode, your virtual
machine operating system dispatches work on its virtual CPUs as if it were running on real hardware. CP
handles the dispatching of work on your virtual CPUs to real CPUs.
Guideline: Never give a virtual machine more virtual CPUs than there are real CPUs.
Usually virtual machines share all CPUs, but a real CPU can be dedicated to a virtual machine, which means that
the CPU is reserved for that virtual machine’s exclusive use. This obviously has an impact on the performance of
other virtual machines in the system.
2.1.2 Storage
Mainframe storage is analogous to memory in a personal computer. CP commands refer to memory as storage,
so do not confuse the term “storage” with disk or tape storage.
Each virtual machine has its own virtual storage. CP manages the residency of virtual machine’s pages in real
storage through paging. Pages that have not been referenced can be moved out of real storage into either
expanded storage or onto a paging device. When a virtual machine requires a page no longer in real storage, a
page fault occurs and CP brings the missing page back into real storage.
CP has facilities that allow portions of real storage to be shared by many virtual machines. Such portions are
called shared segments. This sharing economizes on real storage and requires less paging, thereby improving
performance. For example, the CMS nucleus is shared in real storage by all virtual machines that loaded CMS
by name; that is, every CMS virtual machine maps a 1 MB segment of virtual storage to the same 1 MB of real
storage.
13
2.1.3 DASD and minidisks

DASD, the mainframe term for disk drives, stands for “direct access storage device” and is analogous to a hard
disk drive on a personal computer. A single real DASD is called a volume or real volume. Each volume has a
label or volume serial number (volser) that identifies the volume to z/VM.
Of special importance is the way z/VM shares DASD. CP can logically partition real DASD volumes into
minidisks, which is analogous to dividing a personal computer hard disk into multiple partitions. A minidisk has
its own label, which is distinct from the real DASD label. Each virtual machine can have one or more minidisks
and those minidisks are under control of the guest operating system.
2.1.4 Temporary minidisks

You can create a temporary minidisk from a special pool of real disks. The disk lasts as long as the virtual
machine is logged on. At logoff, the temporary minidisk is deleted and the space returned to the available
temporary disk pool.
2.1.5 Virtual disks in storage

Virtual disks in storage are similar to temporary minidisks, except the disks are mapped to storage rather than the
cylinders of real disks. Using virtual disks in storage avoids the need for disk I/O. CP manages the virtual disk
pages as part of its real memory management.
2.1.6 Virtual readers, punches, and printers

These devices are not associated with real devices, but are implemented through the spool file system.
In the early days of computing, input to the computer came from punched cards loaded into a card reader. You
used a key punch to record your program on punched cards, then loaded the cards into a card reader, which
interpreted your cards and loaded your program into the computer. Output from the program was written to a
printer. z/VM preserves this bit of computing history through virtual reader, punch, and printer devices, also
called unit record devices. Unit record devices provide a handy way to send files from one virtual device to
another, to other virtual machines, or to real devices (such as real printers). For instance, you can think of a file
being sent from one virtual machine to another as the virtual equivalent of taking a card stack from one computer
and loading the stack onto another computer’s card reader.
Behind the manipulation of these files is a CP file system called the spool file system. CP manages spool files on
one or more DASD volumes that act as temporary storage areas. A spool file is a collection of data along with
device control instructions for processing on a unit record device. Spooling is the processing of files created by
or intended for virtual readers, punches, and printers. Through CP and CMS commands, you can send spool files
from one virtual device to another, from your virtual machine to another, and to real devices.
By convention, each virtual machine has a virtual reader at virtual device number 00C, a virtual punch at virtual
device number 00D, and a virtual printer at virtual device number 00E. Your virtual reader is like the in-box of
an e-mail system, except more than just e-mail can be placed there. Through your virtual punch, you can place a
copy of an entire operating system into the system spool, then use the CP IPL command to load and run that
operating system in your virtual machine
14
2.1.7 The virtual machine console

The virtual machine console or virtual console is the primary interface to the virtual machine. When you log on
to a virtual machine from a local terminal or a remote workstation, the virtual console is associated with the
terminal session. From the console, you can enter CP commands, such as loading (IPL) an operating system. The
virtual console is the device an operating system views as its system or hardware console.
As you do work on your console, the lower right corner of the screen displays various status notices. The notices
tell you what is happening in the system at the present time. If you forget what these notices mean, you can come
back to this section for reference.
CP READ This notice means that the Control Program (CP) is waiting for you to enter a command.
VM READ This notice means that a virtual machine operating system, such as CMS, is waiting for
you to enter a command.
RUNNING This notice means the virtual machine is working on something. For CMS, this means
CMS is ready for you to enter a command.
MORE ... This notice means that there is more information than can fit on the current screen. After
a pause (which depends on the terminal settings for your virtual machine), the next
screen of information is displayed. To view the next screen right away, press the Clear
key. To hold this information on the screen, press the Enter key, which changes
MORE... to HOLDING.
HOLDING This notice means the system is waiting for you to clear the screen before showing you
more information. The notice appears when the screen displays MORE... and you press
the Enter key. The notice can also appear when another user sends you a message. To
cancel the hold, press the Clear key.
NOT ACCEPTED This notice means that the system is working on something and is too busy to accept
another command. Wait several seconds and issue your command again.
2.1.8 The User Directory

The user directory The z/VM user directory (or user registry) describes the configuration and operating
characteristics of each virtual machine that can be created by CP. A z/VM user directory exists in two
forms: a source form that consists of one or more CMS files, and an object form, compiled from the
source, on a CP-formatted disk.
Each virtual machine has a directory entry.
2.2 Logon to MAINT

MAINT is us
Log on to the MAINT virtual machine. The default password is the same as the name of the virtual
machine. (or alternatively, clear the logon screen, from CP mode, enter ===> logon maint maint)
15
USERID ===> maint

PASSWORD ===> maint
Press the ENTER key to change from “VM READ” to “RUNNING” status
The “PROFILE EXEC” will run to set up your environment. You are now in CMS. It is similar to
TSO in z/OS or a shell in UNIX. You will learn more about CMS in the next unit. Now, let's do some
CP commands to get familiarized with the system.
2.3 HELP
You use CP commands to communicate with the control program. CP commands control the devices attached to
a virtual machine and their characteristics.
1. To see a list of the CP commands:
===> help
Place cursor on “CP”
Press the ENTER key
What you see here is a subset of the CP commands available in z/VM.
2. To display help text for the DISCONNECT command:
Place cursor on “DISConn”
Press the ENTER key
The bottom of the screen lists the PF Keys for additional options that are available for the
selected command.
3. When you are done browsing, exit the help utility.
Press the F3 key (Quit) repeatedly until you return to “RUNNING” state
You may have to do this repeatedly depending on how deep you have gone into the HELP
function.
4. Another way to go directly to the menu of CP commands is with the following help command:
===> help cp menu
5. Exit the help menu and return to the READY prompt:
Press the F3 key repeatedly until you return to “RUNNING” state
2.4 QUERY
Let’s learn a little about your virtual machine environment with the QUERY command.
1. To display a list of commands your virtual machine (MAINT, in this case) is authorized to
issue:
16
===> query commands

This list is long because the MAINT virtual machine has the highest level of privilege class (A,
B, C, D, E, F, G) which enables it to issue all the commands. Usually a general virtual machine
should have only general class (G) privilege which only allows it to issue commands to control
its own resources.
2. Display a list of all real processors, and indicate the way in which each processor is being used.
===> query processors
The output indicates that your z/VM has 2 real processors. Processor address 00 is the master
processor and processor address 01 is non-dedicated.
3. Display the size of real storage.
===> query storage
The output indicates that your z/VM system has 512 MB of real storage.
4. Display the size of storage accessible to your virtual machine (MAINT)
===> query virtual storage (q v stor)
17
The MAINT virtual machine has access to 128 MB of virtual storage.

5. Display the status of real direct access storage devices (DASDs).
===> q dasd all
A list of devices known to this virtual machine is displayed. Check the table below for
descriptions of each device and what are are used for.
200 Boot volume or “res” pack, sometimes called the SYSRES, or system’s residence volume.
The volume that you just “IPL” (IPL 200 CLEAR).
201, 202, and 203 Other CP owned volumes. For now consider CP owned volumes as system volumes,
containing things like page space (swap for those of you who prefer distributed
terminology), spool space, temporary file space, etc... You will learn more about this later.
190, 19E CMS disks used to support your team ID on the first level z/VM, PBCVM51.
702, 703 Utility disks shared by all team Ids.
300, 301 Use to build linux virtual machines.
6. Display all the free Open System Adapter (OSA) devices.

===> q osa free
The output returns all free OSA devices. A free OSA device is one that is not currently in use
by a user or the system.
7. Display the number of cylinders or pages that are allocated, in use, and available for DASD
volumes attached to the system which are owned by 'CP' . These are typically system related
DASDs.
===> q alloc
18
In a later exercise, you will learn how to format a DASD volume. Basically, a volume must be
allocated and used in the following ways:
TDISK tdisk is short for temporary disk. z/VM gives you the ability to define temporary work or utility
disks.
PAGE Page space on the mainframe is similar to swapping in the distributed environment. Windows has
swap files. Linux has swap devices or swap files. z/VM has page space.
SPOOL Spool space is where print, reader, and punch files are held.
DRCT Directory space is the space that holds information about your users such as their passwords and
virtual machine definitions.
PERM Permanent user's space.
2.5 VARY
With a mainframe you have the ability to turn devices on and make them available for use, or you can turn them
off, and remove them from the available pool of resources. This is called varying devices online and varying
devices off-line.
In a previous exercise, you used the 'Q DASD ALL' command to display the status of real DASDs. Since
devices 190 and 19E are not needed by your second level virtual machine, let's vary them offline.
===> vary off 190 19E
Display the status of these devices to verify that they are offline
19
===> q 190 19E
2.6 ATTACH
In a previous exercise, you used the 'Q OSA FREE' command to display all the available Open Systems Adapter
addresses. You can 'attach' a free device to a virtual machine and make it available for use. One way to attach a
real device is to use the 'ATTACH' command.
You will be using OSA devices 800-802 in this workshop later to provide networking for the Linux guest you
will build. Let's attach these devices to the MAINT virtual machine now.
===> attach 800-802 maint
Display the status of these devices:
===> q 800-802
Notice that they are no longer free! They show as attached to MAINT. The command to return these devices to
the free resource pool for other virtual machines to use is 'DETACH'.
2.7 INDICATE
CP also has commands to help you monitor what’s happening with your system; IND or INDICATE,
is one such command. Let's try a few:
===> ind load
This simple command tells you many things. You might notice right away your system is sleeping!!!
● Average utilization is 000%
● No I/O activities
● No paging
● Etc.
Another useful command is 'IND USER' . You can use this command to find out how a specific virtual machine
is doing. If the I/O count fields are progressing you know the machine is working on something. Hopefully its
something productive. You might want to try some IND USER commands when your Linux guest is running
later on. (See output above)
===> ind user maint
20
Try others....
===> ind paging
===> ind i/o
2.8 CPFMTXA
When you add a new disk to a PC you may format, partition, and build filesystems. When you add disk
to a z/VM system, you must format it and tell z/VM how you would like the disk to be used, ie. Page,
spool, perm etc.
CPFMTXA is a utility for formatting and allocating page, spool, temporary disk, and directory space on DASD
volumes. These special volumes are listed in the 'CP_OWNED_VOLUMES' list of the 'SYSTEM CONFIG'
file. Z/VM uses volumes in this list whenever it needs to allocate page, spool, temporary and directory space.
In addition, CPFMTXA can be used to format, label , and allocate DASD volumes for user minidisk space. This
kind of allocation is called PERM space.
Now let's practice using the CPFMTXA utility.
2.8.1 Use CPFMTXA to format Device 300

1. First, display a list of available DASDs:
===> q dasd free
The QUERY command should report that disk 300 is free.
Attach 300 to MAINT so we may use the MAINT ID to format the disk for our z/VM system’s use:
===> attach 300 *
The asterisk means attach the device to me, the user ID issuing the attach command
===> q 300
Device 300 should show as attached to MAINT.
2. Format device 300 with the CPFMTXA utility. Enter:
===> cpfmtxa
The CPFMTXA interactive utility will ask you want to format, allocate or label. CPFMTXA is
a multifunction utility. In this case you want to begin by formatting. Enter:
===> format
CPFMTXA next asks us which device you would like formatted. You are going to format
device 300, the device you just attached to MAINT. Enter:
===> 300
CPFMTXA next asks what range of cylinders you would like formatted. This is a nice feature.
Sometimes you don’t want to format the whole volume, just selected cylinder ranges on a
volume. In this case you want to format the whole volume so enter:
21
===> 0 end
Next you are asked for a new volume label. Enter:
===> zvmpg1
We are next warned that CPFMTXA is about to erase all data on the volume; are you sure you
want to continue? Enter:
===> yes
CPFMTXA now invokes ICKDSF to begin formatting the volume. This would be a good time
to get a cup of coffee! When the formatting is done, CPFMTXA presents the following:
CPFMTXA is reporting the current allocation map of the new volume ZVMPG1. Note that by
default CPFMTXA allocated all cylinders as PERM space. PERM space is where virtual
machine minidisks are allocated. For now, let's accept the default and exit the utility. Enter:
===> end
2.8.2 Use CPFMTXA to allocate cylinders

You can alter the default allocation map by giving CPFMTXA the allocations that we want ZVMPG1
to have. Now allocate the following
● 2501 cylinders of page (PAGE)
● 200 cylinders of spool (SPOL)
● The remainder as temporary disk (TDSK)
Start the CPFMTXA utility. Enter:
22
===> cpfmtxa
In this case you want to allocate cylinders. Enter:
===> allocate
Enter the virtual device number of ZVMPG1 to be processed:
===> 300
Next enter the volume label. This is a check to make sure you are working on the volume you are
supposed to. This verification is meant to protect against accidental overwriting. Enter:
===> ______________
Enter allocation data. Start by making cylinders 0-2500 PAGE space. Enter:
===> page 0 2500
This specifies starting with cylinder 0 and ending with cylinder 2500 we want PAGE space. This
allocates 2501 cylinders as page space. Note: You do not get acknowledgment back until you type
“end” later.
Make the next 200 cylinders spool space. Enter:
===> spol 2501 2700
Make the rest (637 cylinders) temporary disk. Enter:
===> tdsk 2701 3337
We now tell CPFMTXA you are done altering the allocation map by entering:
===> end
23
A new allocation map is presented. Verify that the allocations are correct.
You are now done with device 300. Detach it from the system. Enter:
===> detach 300
2.8.3 Use CPFMTXA to format Device 301

Using what you have learned in the previous lab, format device 301, label it ZVMPK1, and allocate the
entire device with permanent (PERM) space.
Hints:
Attach the device: ______________________________________________
Format it: _____________________________________________________
Detach the device: ______________________________________________
24
Unit 3: The Conversational Monitor System (CMS)
3.1 Introduction
Just as you can interact with Linux or UNIX® through a bash or Korn shell, you can interact with
z/VM through CMS. Like a shell, you can use CMS to edit files, run EXECs (script-like executable
files) or programs, modify the virtual machine environment, or modify z/VM itself. CMS is to z/VM as
a shell is to Linux or UNIX.
3.1.1 The Help System

z/VM provides online help through the CMS Help system. The HELP command is like the man
command in Linux. You can find full descriptions of z/VM commands by using the HELP command.
3.1.2 Minidisks and the CMS access mode

CMS, like other operating systems running in a virtual machine, can access minidisks to store and
retrieve files. For CMS, each minidisk has an access mode represented by an alphabetic letter that
determines how CMS searches for files. In Linux, path variables defining directories determine the
search order for files. CMS searches for files among minidisks based on the alphabetical order of the
access mode. First, CMS looks on the A minidisk, then the B minidisk, and so forth. The 191 minidisk
holds a special place in CMS. A 191 minidisk to a CMS user is like the home file directory for a Linux
user. CMS always tries to access a user’s 191 minidisk as access mode A. The CMS 191 minidisk is
often called the “A-disk.”
3.1.3 CMS Files

CMS files have a file name, file type, and file mode. File names and file types can be up to 8 characters
long. The file mode corresponds to the access mode of the minidisk. Examples:
PROFILE EXEC A1
MYDOC LISTING A1
DNFPFS LISTPS B1
By convention, some file types have special meanings. For example, EXEC is the file type for a file
that contains executable statements, LISTING is the file type for text files, and LISTPS is the file type
for PostScript files. To view and manipulate files, use the FILELIST command. FILELIST is similar to
the dir command in Linux.
25
3.1.4 The PROFILE EXEC

The PROFILE EXEC is a special executable file analogous to the .profile (or .bash_profile) in Linux
and UNIX. Every time a CMS user logs on, CMS runs the PROFILE EXEC residing on the 191
minidisk, file mode A. You can use the PROFILE EXEC to set up your virtual machine environment;
for instance, access disks, set up special PF keys, or even load another operating system in your virtual
machine.
There can be times when you do not want the PROFILE EXEC to execute when you log on. For
example, assume your PROFILE EXEC automatically loads Linux. If you have just shut down Linux
and want to start CMS, but prevent Linux from being loaded again, you can prevent CMS from
executing the PROFILE EXEC by issuing access (noprof. When you IPL (load) CMS, you see an
identifier line displayed and CMS pauses with VM READ in the lower right corner of the display.
3.1.5 The CMS file editor XEDIT

CMS provides a file editor called XEDIT, which is a not only a full-screen editor, but a powerful
programming tool. XEDIT has functions similar to vi in Linux.
3.2 HELP
1. To see a list of the CMS commands:
===> help
Place cursor on “CMS” and press the ENTER key
What you see here is a subset of the CMS commands available in z/VM.
2. Display help text for the QUERY command. You may have to scroll down (F8) to find it.
Place cursor on “Query” and press the ENTER key
The bottom of the screen lists the PF Keys for additional options that are available for the
selected command. To see related information for this command:
Press the F11 key
3. When you are done browsing, exit the help utility.
4. Another way to go directly to the menu of CMS commands is with the following help
command:
===> help cms menu
5. Exit the help facility and return to the READY prompt:
26
3.3 QUERY
The CMS QUERY command is used to display information about your virtual machine. You can get
information about
● The operation of your virtual machine.
● The status of your files and file pool directories.
● Information about how your virtual machine is set up.
1. Use the QUERY ACCESSED command to display the status of your accessed disks. Note that
the 191 disk is accessed as “A”.
===> q accessed
Mode Stat Files Vdev Label/Directory
A R/W 35 191 MNT191
B R/W 132 5E5 MNT5E5
C R/W 55 2CC MNT2CC
D R/W 247 51D MNT51D
S R/O 687 190 MNT190
Y/S R/O 1010 19E MNT19E
2. Use the QUERY IMPCP command to find out the implied CP function setting for your virtual
machine.
===> q impcp
For the MAINT virtual machine, the IMPCP function is set to
________________________________
You will learn more about this function in a moment.
3.4 ACCESS
The ACCESS command is used to:
● Identify a minidisk to CMS.
● Make a list of the files on the specified minidisk or directory available to your virtual machine.
● Establish a file mode letter for the files on a minidisk or in a directory.
1. Use the ACCESS command to access the 191 minidisk as “Z”.
===> access 191 z
What happened to the A-disk? _________________________________________________
What implications does this change have? _______________________________________
2. Re-access the 191 minidisk as “A”. What is the command?
===> _________________________________________________________
27
3.5 COPYFILE
The COPYFILE command is used to copy and modify files on CMS minidisks. You can:
● Combine two or more files into a single file.
● Copy multiple input files into multiple output files.
● Change file characteristics (such as file mode number and record format) and/or modify file
contents.
1. Copy the file PROFILE EXEC A to a new file called PROFILE EXECSAVE A.
===> copy profile exec a = execsave =
What do the “=” signs mean? ________________________________________________

2. Copy the file USER DIRECT C to a file called USER DIRSAVE C. Replace the file if it already exists.
===> copy user direct c = dirsave = (replace
3. Look at the help for the COPYFILE command to see what are functions are available.
===> ________________________________________________________
3.6 CP
There are several ways to issue CP commands in CMS depending on the setting of the implied CP
(IMPCP) option:
● If IMPCP is set to ON, CMS will try to interpret an “unknown” command as a CP command.
● If IMPCP is set to off, you must precede any CP commands with “CP”
Or you can precede any CP command with “#CP” to directly send the command to the control
program.
1. Find your current IMPCP option setting:
===> q impcp
It should say 'ON'. This is the default. It means if CMS does not recognize a command, it will
send to CP for processing.
2. Try a CP command (while you are in CMS):
===> q dasd
Sure enough, the command works and you see a list of DASDs currently attached to your
virtual machine.
3. Next set the IMPCP option to off:
===> set impcp off
4. Try the same CP command:
===> q dasd
28
This time, the command failed. With the IMPCP function turned off, CMS did not redirect the
unknown command to CP for processing.
5. You are currently running in the CMS environment. To enter CP mode, type:
===> CP
The console status in the lower right hand corner of the screen now indicates “CP READ” .
6. Try the same CP command:
===> q dasd
7. To return to CMS, type:
===> begin (or 'b' for short)
The status in the lower right hand corner of the console returns to “RUNNING” .
8. Another way to issue CP command is to prefix it with '#CP'. Try this:
===> #cp q dasd
9. Reset the IMPCP option back to ON:
===> set impcp on
3.7 FILELIST
The FILELIST command is used to display a list of information about CMS files residing on accessed disks. In
the FILELIST environment, information is displayed under the control of XEDIT. You can use XEDIT
subcommands to manipulate the list itself. You can also issue CMS commands against the files directly from the
displayed list.
1. Display a list of files on your A-disk.
===> filel * * a
The files are sorted by date and time, newest to oldest.

2. Delete the file $VMFP2P $MSGLOG.
Press the TAB key to advance the cursor to the CMD column of the $VMFP2P
$MSGLOG file
Type “ERASE” and press the ENTER key
29
Update the FILELIST display. The $VMFP2P $MSGLOG file should be gone.
Press the F2 key
3. Rename the PROFILE EXECSAVE file to PROFILE EXEBKUP.
Press the TAB key to advance the cursor to the CMD column of the PROFILE
EXECSAVE file
Type “COPY / = EXECBKUP =” and press the ENTER key
30
The command can be read as ”rename the current file (/) to a file with the same file name of
PROFILE (=), a file type of EXECBKUP and the same file mode of A (=)”.
Update the FILELIST display and you should see the new copy of the profile.
Press the F2 key
4. Exit FILELIST.
Press the F3 key
3.8 XEDIT
Let's create a simple REXX EXEC file with an edit session by using the XEDIT command.
1. Start an XEDIT session and create a new file HELLO EXEC A.
===> xedit hello exec
2. Enter Input mode:
===> i
3. Input the following text. Refer to the XEDIT quick reference guide if you need help.
/* A sample REXX exec */
say 'Welcome to the zSeries Linux Workshop'
4. Return to Edit mode:

Press the Enter key
5. File your changes and exit the file.

===> file
31
6. An REXX EXEC is similar to a Unix/Linux script. Let's run the exec and see what happens:
===> hello
7. Now update the HELLO EXEC file:
===> x hello exec
8. Insert a new line:

Type an 'i' on the line
Enter the text 'q time'
9. Execute the file again. You have successfully created a executable file to execute commands
and output messages!
===> hello
Next, modify the PROFILE EXEC file so that you will gain access to a shared utility disk
which contains useful scripts for the workshop.
1. Edit the “PROFILE EXEC” file.
===> x profile exec
2. Add the following statements (in upper case) to the end of the file
'CP ATTACH 702 *'
'ACCESS 702 E'
10. File your changes and exit the file.

===> file
11. Execute the profile to pick up the changes. You should see a message tell you that the device
702 is attached.
===> profile
32
Unit 4: System Configuration

4.1 Overview of the SYSTEM CONFIG file
The SYSTEM CONFIG file contains the primary system definitions used when CP is booted (IPLed).
All of the information needed to configure CP statically comes from this file. As a system programmer,
you should become familiar with this file. The SYSTEM CONFIG file resides in the same location as
the bootable CP kernel. Both objects, along with other files and modules, reside on a special CMS-
formatted minidisk. Minidisks containing such objects are called parm disks because when allocated
those disks are given a special record category type called “PARM”. There can be more than one parm
disk allocated in a z/VM system for backup and recovery. However, for any specific IPL, only one
parm disk is used to load code and configuration files.
4.2 System parameter disks

The SYSTEM CONFIG file is located on a system’s parameter disk. MAINT’s CF1, CF2, and CF3
minidisks are traditionally used as the system’s parameter disks. Use the QUERY CPDISK command
to query what system parameter disks are in use with your system:
===> q cpdisk
4.3 Update the SYSTEM CONFIG file
4.3.1 Edit the SYSTEM CONFIG file

Release the primary parm disk. Before you begin updating the SYSTEM CONFIG file, you must
access the primary parm disk which contains this file with WRITE permission. Execute a script
“GETCF1” which will access the parm disk as the “F” disk. (See below for the actual commands in the
script.
===> getcf1
'CP CPRELEASE A'
'LINK * CF1 CF1 MR'
'ACCESS CF1 F'
Edit the SYSTEM CONFIG file:
33
===> x system config f
4.3.2 Update the CP-owned volume list

The CP-owned volume list is the place where you specify the labels of paging and spooling volumes that CP
should automatically attach to the system during IPL. These volumes contain the system data for your z/VM
system. All other volumes on the system are considered user volumes.
Find the section titled “CP_Owned Volume Statements.” At the XEDIT command line, type the following and
press the Enter key:
===> /cp_owned
Move the cursor to the first CP-owned slot that is marked “Reserved”.
Move cursor to “Slot 6”
Type over the word “Reserved” with the volume label of the paging volume that you allocated earlier.
CP_Owned Slot 6 ZVMPG1
4.3.3 Update the default system identifier

The default system identifier appears on printed output separator pages and the status area of 3270 display
screens. z/VM assigns the identifier ZVMV5R20 to all z/VM version 5 release 2 systems. If you have many
z/VM systems, it is difficult to determine which z/VM system you are logged onto unless you make the system
identifier unique for each system.
Find the line “System_Identifier_Default.” At the XEDIT command line, type the following and press the Enter
key:
===> /system_identifier
Replace the default system identifier with your own: ZVM<n> where <n> is your team number.
System_Identifier_Default ZVM<n>
4.3.4 Update the user volume list

Just as there is a list of DASD volumes that CP should automatically attach to the system during IPL for access
to CP system areas, there is a list of DASD volumes that CP should automatically attach to the system for user
minidisk definitions. Because all minidisks are managed by CP, all volumes that house minidisks must be
attached to the z/VM system.
The USER_VOLUME_LIST statement directs CP to attach specific user DASD volumes at z/VM load (IPL)
time. The USER_VOLUME_INCLUDE statement allows you to create a general volume identifier and to
include all volumes that match the general identifier. For example, if all your Linux user volumes have a volume
identifier starting with V2LX, you can add the following statement: User_Volume_Include V2LX*.
Find the section titled “User_Volume_List.” At the XEDIT command line, type the following and press the
Enter key:
34
===> /user_volume
Add a User_Volume_List statement for volume ZVMPK1. (Be sure not to use /* */ because it will be treated
as a comment)
User_Volume_List ZVMPK1
4.3.5 Set up other features

The FEATURES statement in SYSTEM CONFIG allows you to modify attributes associated with the running
system at IPL time. In this procedure, you will modify some of the features:
Find the line containing the text “Features Statement.”
===> /features
Modify the following features:
Features ,
Disable , /* Disable the following features */
Set_Privclass , /* Disallow SET PRIVCLASS command */
Auto_Warm_IPL , /* Prompt at IPL always */
Clear_TDisk , /* Don't clear TDisks at IPL time */
Retrieve , /* Retrieve options */
Default 99 , /* Default.... default is 20 */
Maximum 255 , /* Maximum.... default is 255 */
MaxUsers noLimit , /* No limit on number of users */
Passwords_on_Cmds , /* What commands allow passwords? */
Autolog yes , /* ... AUTOLOG does */
Link yes , /* ... LINK does */
Logon yes , /* ... and LOGON does, too */
Disconnect_Timeout off , /* don't logoff idle guests */
Vdisk Userlim infinite , /* Maximum vdisk allowed per user */
Syslim infinite /* Maximum vdisk in system */
4.3.6 Set up control access to devices at startup

Sometimes your z/VM system may have access to devices that you do not want to be varied online
during IPL. For instance, the devices may contain duplicate labels of devices used by your production
system, or may be in use by other LPARs or systems. You can specify ranges of devices that z/VM
should not vary online during IPL.
Find the section titled “Status of Devices.”
===> /status
Find the line containing the text “Online_at_IPL.”
===> /online
Add an Offline_at_IPL statement for devices 190 and 19E following the “Online_at_IPL” statement.
35
Offline_at_IPL 190 19E,
4.3.7 Set addresses for consoles

During the first IPL of your z/VM system, you needed to specify a load parameter so you could communicate
with the Stand-Alone Program Loader (SAPL). The reason is the new z/VM system did not know which device
address to use to display messages and prompts. The installation system includes default device addresses for
use as the system operator console and emergency messages console, but these addresses rarely correspond to
your production hardware configuration. So you will not need to use the SAPL each time you IPL z/VM, you
need to supply the address of your IPL console and your emergency messages console on the Operator_Consoles
statement. During IPL, CP tries each device on the Operator_Consoles statement (from left to right) until it finds
an active device. If no devices on the list are active, CP loads a disabled wait state and terminates. The
emergency message console is used as an additional console during failures. Define the emergency console with
the Emergency_Message_Console statement.
Find the section titled “Console Definitions” .
===> /console
Set 0009 as the first device on the Operator_Consoles and the Emergency_Message_Consoles statement. This
will tell z/VM to open operator communications with device 0009 which is the device address of the virtual
console. This will alleviate the need for passing load parameters at the next boot.
Operator_Consoles 0009 0021 0022 0023 0E20 0E21 1020 ,
System_3270 System_Console
Emergency_Message_Consoles 0009 0021 0022 0023 0E20 0E21 1020 ,
System_Console
Save all the changes you have made so far and exit the SYSTEM CONFIG file.
===> file
4.4 CPSYNTAX
Since the SYSTEM CONFIG file contains very important data, extreme care must be taken to ensure its contents
are correct. The system may not start correctly if this files contains errors. Fixing the errors can be cumbersome.
z/VM provides a utility, CPSYNTAX, in MAINT's 193 minidisk to check the syntax of the SYSTEM CONFIG
file.
1. Access MAINT's 193 minidisk as the X-disk.
===> access 193 x
2. Run the CPSYNTAX command.
===> cpsyntax system config
3. If you receive error messages, modify the SYSTEM CONFIG file and rerun CPSYNTAX.
4. Restore CP’s access to the primary parm disk
Execute the script “FREECF1” to relinquish write access and restore CP's read access to the parm disk.
36
(See below for the actual commands in the script).

===> freecf1
'RELEASE F'
'CP DETACH CF1'
'CP CPACCESS MAINT CF1 A'
4.5 Restart z/VM and verify changes

In this exercise, you will learn to use some new CP/CMS commands to verify the changes you have made to the
system.
1. Restart your z/VM
===> shutdown reipl
When the system shuts down and re-IPLs, you will see a number of IPL messages. z/VM restores the
system to the same state as it was prior to shutdown (for instance, with OPERATOR disconnected).
Press the Pause key if the console status is “MORE...”
To get a z/VM logo, press the Enter key.
Log on as MAINT.
Press the Enter Key to go from “VM READ” to “RUNNING” State.
2. Check paging and spooling space
Use the QUERY ALLOC to display the number of cylinders or pages that are allocated, in use, and
available for DASD volumes attached to the system.
Display the allocation information for paging space.
===> query alloc page
The output should show that the system is now using cylinders 0-2500 on volume ZVMPG1 for paging
EXTENT EXTENT TOTAL PAGES HIGH %
VOLID RDEV START END PAGES IN USE PAGE USED
------ ---- ---------- ---------- ------ ------ ------ ----
52PGSP 0203 1001 3337 420660 0 0 0%
ZVMPG1 0300 0 2500 450180 13 17 1%
------ ------ ----
SUMMARY 870840 13 1%
USABLE 870840 13 1%
Display the allocation information for spooling space.
===> query alloc spool

The output should show that the system is now using cylinders 2501-2700 on volume ZVMPG1 for
spooling space.
EXTENT EXTENT TOTAL PAGES HIGH %
VOLID RDEV START END PAGES IN USE PAGE USED
------ ---- ---------- ---------- ------ ------ ------ ----
37
52PGSP 0203 1 1000 180000 8027 23760 4%

ZVMPG1 0300 2501 2700 36000 11925 11925 33%
------ ------ ----
SUMMARY 216000 19952 9%
USABLE 216000 19952 9%
3. Check the system identifier

Use the IDENTIFY command to display information about your user ID and node
===> id
MAINT AT ZVM15 VIA * 04/02/06 23:44:43 EDT SUNDAY
Your system identifier should be ZVM<n> where n is your team id. The system identifier is
also displayed at the lower right hand corner of your console.
4. Check the user volume list
Use the QUERY DASD command to display a list of the DASDs that are attached to the
system.
===> query dasd
DASD 0200 CP OWNED 520RES 74
DASD 0201 CP OWNED 520W01 89
DASD 0202 CP OWNED 520W02 1
DASD 0203 CP OWNED 52PGSP 1
DASD 0300 CP OWNED ZVMPG1 0
DASD 0301 CP SYSTEM ZVMPK1 0
You should see the ZVMPK1 user volume attached to the system.
5. Check features
Use the QUERY RETRIEVE command to display the setting of the retrieve key buffer limits.
===> q ret
99 buffers available. Maximum of 255 buffers may be selected.
A maximum of 99 commands can now be stored and retrieved from the retrieve key buffer.
The retrieve keys (PF11 and PF12) are defined in the PROFILE EXEC file.
6. Check offline devices
Once again, use the QUERY DASD command to display any offline devices.
===> query dasd offline
An offline DASD was not found.
38
Unit 5: Create Virtual Server

5.1 Overview of the User Directory
The z/VM user directory (or user registry) describes the configuration and operating characteristics of
each virtual machine that can be created by CP. A z/VM user directory exists in two forms: a source
form that consists of one or more CMS files, and an object form, compiled from the source, on a CP-
formatted disk. Each virtual machine has a directory entry. Here is a sample directory entry.
Directory definitions are processed in the following order:
1. DIRECTORY Definition - which defines the output object directories
2. GLOBAL Definition - which defines global settings to be used across all users
3. PROFILE Definitions - which consolidates other directory control statements that are
commonly used across multiple users
4. USER Definitions - which defines an individual virtual machine
5.1.1 DIRECTORY definition

The DIRECTORY Definition consists of one or more DIRECTORY directory control statements that define the
output of object directories. The DIRECTORY statement defines to CP the device on which you have allocated
space for the directory. (This devices must also be a CP_owned volume.)
The user directory itself resides on MAINT’s 2CC disk. If you execute a QUERY DISK command you’ll see
that 2CC is accessed as file mode “C”, or your “C” disk.
The following DIRECTORY definition simply says DASD volume 530RES has directory space allocated on it
for the object directory. It is a 3390 device type, and 123 is the virtual device number which contains the
directory.
DIRECTORY 123 3390 530RES
5.1.2 GLOBAL definition

The Global Definition section begins with the GLOBALDEFS directory control statement. It also
includes directory control statements which define global settings to be used across all user definitions.
This is an optional statement. If specified it must directly precede all PROFILE and USER definitions.
There can be only one GLOBALDEFS directory control statement specified. The user directory that
came with the installed system contains the following Globaldefs:
GLOBALDEFS
POSIXGROUP system 0
POSIXGROUP staff 1
POSIXGROUP bin 2
POSIXGROUP sys 3
POSIXGROUP adm 4
39
POSIXGROUP mail 6
POSIXGROUP security 7
POSIXGROUP nobody 4294967294
5.1.3 PROFILE definitions

Each PROFILE definition begins with a PROFILE directory control statement and consolidates other
directory control statements that are commonly used across multiple users. When PROFILE is
specified it must follow the last DIRECTORY statement, the global definition section (if any), and
precede the USER statements.
This is a profile used by the team Ids:
PROFILE ZVMDFLT
IPL CMS
MACH esa 4
iucv any
iucv allow
cpu 00 base
cpu 01
option applmon
CRYPTO APVIRT
SPOOL 000C 2540 READER *
SPOOL 000D 2540 PUNCH A
SPOOL 000E 1403 A
CONSOLE 009 3215 T
special 800 qdio 3 system qlan1
special 900 qdio 3 system qlan1
LINK MAINT 0190 0190 RR
LINK MAINT 019E 019E RR
LINK PBCMAINT 0702 0702 RR
5.1.4 USER definitions

User definitions (virtual machine definitions, or guests) begin with a USER directory control statement
and define an individual virtual machine.
The USER statement starts each virtual machine’s directory entry. It also defines a user ID and
password, a logon and maximum virtual storage size, and command privileges.
Here are the team ID user definitions:
USER team1 adrian 768M 2048M G
INCLUDE ZVMDFLT
MDISK 191 3390 0285 0020 VM51U9 MR RAPACHE WAPACHE
MDISK 200 3390 0001 3338 bcws11 MR RAPACHE WAPACHE
MDISK 201 3390 0001 3338 bcws12 MR RAPACHE WAPACHE
The above directory control statement defines a virtual machine called TEAM1, whose password is 'adrian'.
When TEAM1 logs on it is allocated 768 Megabytes of virtual storage. It is allowed a maximum of 2048
40
Megabytes of virtual storage, and it is a class G, or general user.

The following table contains a description of different command classes:
Class User and Function
A System Operator: The class A user controls the z/VM system. The system operator is responsible for the
availability of the z/VM system and its resources. In addition, the system operator controls system accounting,
broadcast messages, virtual machine performance options, and other options that affect the overall performance
of z/VM.
Note: The class A user who is automatically logged on during CP initialization is designated as the primary
system operator.
B System Resource Operator: The class B user controls all the real resources of the z/VM system, except those
controlled by the system operator and the spooling operator.
C System Programmer: The class C user updates or changes system-wide parameters of the z/VM system.
D Spooling Operator: The class D user controls spool files and the system's real reader, printer, and punch
equipment allocated to spooling use.
E System Analyst: The class E user examines and saves system operation data in specified z/VM storage areas.
F Service Representative: The class F user obtains, and examines in detail, data about input and output devices
connected to the z/VM system. This privilege class is reserved for IBM use only.
G General User: The class G user controls functions ssociated with a particular virtual machine.
Any Commands belonging to class "Any" are available to any user, regardless of their privilege class. These
commands are primarily those used to gain access to, or relinquish access from, the z/VM system.
H Reserved for IBM use.
I-Z Classes I through Z are reserved for redefinition through user class restructure (UCR) by each installation for its
own use.
5.2 Create a profile

Create a profile to be included by Linux virtual machines.
1. Log on as MAINT.
2. Edit the user directory source file.
===> x user direct
3. Find the profile section.
===> /profile
===> up 1 (position the current line, where the profile is inserted)
4. Insert a file called “lindflt prof” into the PROFILE section. This file has been prepared for you
in the workshop shared disk. Check the following table for it's contents and the meanings.
===> get lindflt prof
Press the Enter key to insert
Press the F7 Key to page up to see the inserted profile
41
Line Explanation
PROFILE LINDFLT Define the profile named LINDFLT
IPL CMS When the user ID is logged on, IPL CMS
MACH ESA 4 The machine architecture is ESA with a maximum of 4 CPUs.
CPU 00 BASE CPU 00 is the base
CPU 01 The user has access to 2 CPUs ( 00 and 01)
SPOOL 000C 2540 READER * Definition of a virtual reader
SPOOL 000D 2540 PUNCH A Definition of a virtual punch
SPOOL 000E 1403 A Definition of a virtual printer
CONSOLE 009 3215 T Definition of a console
LINK MAINT 0190 0190 RR Link to MAINT's 190 minidisk with read access
LINK MAINT 019D 019D RR Link to MAINT's 19D minidisk with read access
LINK MAINT 019E 019E RR Link to MAINT's 19E minidisk with read access
LINK TCPMAINT 592 592 RR Link to TCPMAINT's 592 minidisk with read access. This is where the ftp
utility is located.
5.3 Create the LINUX1 virtual machine

1. Add the virtual machine definition for LINUX1.
Go to the end of the file. Tyep:
===> type “bot”
Insert 4 lines (use 'i4' or 'a4')
Enter the following lines:
user linux1 linux1 256M 1G g
include lindflt
mdisk 100 3390 0001 1650 zvmpk1 mr rapache wapache mapache
mdisk 191 3390 1651 0030 zvmpk1 mr rapache wapache mapache
Line Explanation
user linux1 linux1 256M 1024M g linux1 is a general (G) class user with a password of 'linux1'. It's initial
memory allocation is 256 MB and the user can increase it up to 1GB.
include lindflt Includes additional definition statements from the 'lindflt' profile.
mdisk 100 3390 0001 1650 zvmpk1 mr A 1650-cylinder minidisk 100 on the DASD labeled 'zvmpk1' to be use
rapache wapache mapache for the root file system.
2. Save the changes and exit the file.
42
===> file
5.4 DISKMAP
When defining minidisks to virtual machines by editing the user directory as you are doing here, there is another
step you should perform to ensure you are not defining overlapping minidisks. The DISKMAP utility
summarizes the MDISK statements in the user directory and produces a report called DISKMAP USER
A Gaps between minidisks and overlapping minidisks are flagged in this report.
1. Run the DISKMAP utility .
===> diskmap user
2. Edit the output file and look at the DISKMAP report. Turn the prefix area off so you can see 80
columns:
===> x user diskmap
===> pre off
3. Check the report to make sure that for the ZVMPK1 volume:
○ There are no gaps
○ There are no overlaps
○ Minidisks 100-103 are allocated correctly to LINUX1
4. Exit the report.
===> qq (or press the PF3 key)
5.5 Protecting the volume id

You may have noticed that cylinder 0 is defined as PERM space, however you started your minidisk
allocations on cylinder 1. Cylinder 0 on z/VM volumes is special. The volume id (volid) is written in
cylinder 0. The volumes allocation map is also written to cylinder 0. This means you never want to
allocate cylinder 0 as a minidisk to any virtual machines. If you were to mistakenly allocate cylinder 0
as a minidisk, and the user formatted their minidisk with the CMS FORMAT command, as you will do
shortly, the volume label would be changed, in this case from ZVMPK1, to whatever volume label was
chosen when performing the CMS FORMAT.
Note that the mapping for ZVMPK1 shows a gap starting at cylinder 0 for 1 cylinder. It is good
practice to protect cylinder 0 so that it does not get allocated accidentally. One way to do this is by
defining it to a dummy USER named $ALLOC$.
Edit the USER DIRECT file.
===> x USER DIRECT
Search for $ALLOC$. Go to the command line and enter:
43
===> /$alloc$
Add an entry so cylinder 0 of the ZVMPK1 volume does not show up as a gap (the virtual address A04
is also a dummy value – it will never be used).
MDISK A04 3390 000 001 ZVMPK1 R
Save the changes and exit the file:
===> file
Run the DISKMAP utility again to verify that cyclinder 0 does not show up as a gap any more.
===> diskmap user
===> x user diskmap
===> qq
------------------------------------------------------------------------
VOLUME USERID CUU DEVTYPE START END SIZE

ZVMPK1 $ALLOC$ A04 3390 00000 00000 00001
LINUX1 100 3390 00001 01650 01650
LINUX1 191 3390 01651 01680 00030
------------------------------------------------------------------------
5.6 DIRCTXA
What you have been editing, USER DIRECT, is the source file. The DIRECTXA utility is used to build the
actual directory and installed it to the directory space on 520RES (123).
1. Run the DIRECTXA utility to build the user directory and put it on-line.
===> directxa user
2. Correct any errors and rerun the DIRECTXA utility if necessary.
3. Log off the MAINT user.
===> logoff
5.7 Test LINUX1

Let's log on to LINUX1 and verify that the environment has been created correctly.
1. Log on as LINUX1.
You will see a device error for the 191 disk. This is because the disk has not been formated yet.
2. Format the 191 disk, label it LIN191 and access it as the A-disk.
===> format 191 a
===> 1 (YES to format)
44
===> lin191 (disk label)
3. Display the available storage (memory). It should show 256 MB.

===> q stor
4. Display a list of available DASDs. You should see minidisk 100 created in the user directory.
===> q dasd
5. Your LINUX1 virtual machine is ready to be used. We will return to this machine to install
Linux later. For now, please log off.
===> logoff
45
Unit 6: Basic TCP/IP Configuration

6.1 Overview
6.1.1 TCPIP Service Machines

This section describes the virtual machines that are necessary to provide basic and optional TCP/IP
services. The virtual machines listed here comprise a set of “default” TCP/IP virtual machines that are
defined as part of the z/VM system when it is installed.
While various TCP/IP virtual machines have specific definition requirements, all TCP/IP servers must
maintain links to the following minidisks, to allow for correct operation:
Minidisk Description
TCPMAINT 592 Client-code disk
TCPMAINT 591 Server-code disk
TCPMAINT 198 Configuration file, or customization disk
1.1.1 Required Virtual Machines

The following virtual machines are required to provide basic TCP/IP services:
Machine Function
5VMTCP20 Maintains the TCP/IP system. Installation and service resources are owned by this user ID.
TCPIP Provides TCP/IP communication services. The Telnet server is implemented as an ″internal
client″ within the TCPIP virtual machine.
TCPMAINT Owns TCP/IP production resources — the 198, 591, and 592 disks.
1.1.2 Optional Virtual Machines

There are many optional virtual machines that you can setup to perform TCP/IP server functions.
Some of these servers include FTSERVE, IMAP,PORTMAP,NAMESRV,SSLSERV, etc.
6.1.2 Configuration files

This section lists the various TCP/IP configuration files which are necessary to provide basic TCP/IP
services for most environments.
The first file, IBM DTCPARMS, contains server configuration definitions. The next three files,
PROFILE TCPIP, HOSTS LOCAL, and ETC HOSTS, are configuration files for the TCPIP server
virtual machine. The next two files, TCPIP DATA and ETC SERVICES, need to be accessible to all
46
TCP/IP servers, applications, and users; these files contain information that is (or may be) referenced
by all users. ETC GATEWAYS contains routing information for distant networks and hosts.
1.2.1 The DTCPARMS files

Configuration of each server is controlled by a set of files with a file type of DTCPARMS. These files
may contain two types of information:
1.Server class names that define the application protocols available for all server virtual machines.
2.Individual server user IDs and their associated server class, as well as the operational characteristics
of the server (security, devices, parameters, etc.).
The TCP/IP server initialization program searches for server definitions in a hierarchical fashion. The
following table lists the DTCPARMS files in the order that they are searched, along with a description
of each file.
File Purpose
userid DTCPARMS May be used for servers that do not require configuration by the TCP/IP administrator, such
as a test server. This file will most likely be found on a server’s file mode A.
nodeid DTCPARMS This is useful for shared-DASD configurations. The node ID used is the node ID returned by
the CMS IDENTIFY command. This file should be kept on the TCPMAINT 198 disk.
SYSTEM DTCPARMS Most server configurations should be kept in this file on the TCPMAINT 198 disk.
IBM DTCPARMS Server classes provided by IBM, as well as the default server configurations, are in this file.
This file is on TCPMAINT 591 and should never be modified because it will be replaced
when service is applied or when a new release is installed. Any modifications you make
should be placed in SYSTEM DTCPARMS.
1.2.2 The TCPIP DATA File

The TCPIP DATA file defines system parameters used by TCP/IP client applications. It is used to
specify configuration information for single or multiple host systems. It also allows you to specify:
● Host name of the VM host
● User ID of the TCPIP virtual machine
● Domain origin of the host
● Output trace
● Name server specifications
A sample TCP/IP DATA file is shipped as TCPIP SDATA on the TCPMAINT 592 disk.
1.2.3 The ETC HOSTS Files

The local host files contain information needed for local host name resolution. Any domain name or IP
address specified in this file is accessible for use on your network. Local host files are used to create
the site table, which enables name resolution and reverse name resolution without using a domain name
server.
TCP/IP for z/VM offers two local host files for domain name resolution and reverse name resolution.
The old HOSTS LOCAL file (which supports IPv4 only), and the preferred ETC HOSTS file (which
47
supports both IPv4 and IPv6).

The ETC HOSTS file does not require additional processing to create the site tables used for name
resolution. The site tables are created dynamically by the resolver when the ETC HOSTS file is used.
Use of the HOSTS LOCAL file requires that you run the MAKESITE command to create the site
tables. Whenever changes are made to the HOSTS LOCAL file, you must run the MAKESITE
command to recreate the site tables.
A sample file, ETCHOSTS SAMPLE, is supplied with the TCP/IP distribution tapes on the.
1.2.4 The TCPIP server profile file

When the TCPIP virtual machine is started, TCP/IP operation and configuration parameters are read
from an initial configuration file. TCP/IP searches for an initial configuration file in the following order
and uses the first file present in that order:
1. userid TCPIP, where userid is the user ID of the of the TCP/IP server
2. node_name TCPIP, where node_name is the system node name returned by the CMS
IDENTIFY command
3. PROFILE TCPIP
This file is used to customize your system, specify system operation, Telnet, and network parameters.
If no file is found, TCP/IP uses server default values.
A sample initial configuration file is provided as PROFILE STCPIP on the TCPMAINT 591 disk.
6.2 IPWIZARD
You can initially configure TCP/IP via the IPWIZARD command which is generally used just once.
After IPWIZARD creates the initial configuration files, they are typically maintained manually.
1. Log on as MAINT.
Log on to MAINT
2. The IPWIZARD command is on the MAINT 193 disk. Issue the ACCESS command so you
will pick up IPWIZARD from that minidisk.
==> acc 193 g
3. Invoke the IPWIZARD.
==> ipwizard
4. At the '*** z/VM TCP/IP Configuration Wizard ***' panel. Fill in the following data:
Host Name: zvm<n>
Doamin Name: pbm.ihost.com
Gateway IP: 129.40.35.3
DNS Address: 129.40.35.3
48
5. Continue with next step.

Press the F8 key
6. At the '*** General Interface Configuration Panel ***' panel. Fill in the following data:
Interface Name: eth0
Device Number: 800
IP address: 129.40.35.<n>0
Subnet Mask: 255.255.255.0
Interface Type: QDIO
49
7. Continue with next step.

Press the PF8 key
8. At the '*** QDIO Interface Configuration Panel ***' panel. Fill in the following data:
Network Type: Ethernet
Router Type: None
MTU Size: 1500
50
9. Start the network configuration.

Press the PF5 key to Process
10. The TCP/IP stack (TCPIP) must be restarted as part of this procedure. Would you like to restart
TCPIP and continue?
Enter '1' for Yes
11. The TCP/IP configuration is complete when you see these messages:
51
12. At this point, your z/VM system should be on the network. Go to a DOS prompt (or Linux
session) and try to ping your z/VM system.
# ping 129.40.35.<n>0
6.3 Viewing TCP/IP configuration files

Let's learn what the IPWIZARD did for you.
1. Logon to the TCPMAINT virtual machine
Logoff of MAINT
Logon to TCPMAINT
2. Before editing files, let's copy MAINT's PROFILE XEDIT file so the editor behaves the same
on all user IDs. Use the VMLINK command to link and access MAINT's 191 disk. The
VMLINK command links a disk read-only as an arbitrary virtual device address and accesses it
as the highest file mode.
===> vmlink maint 191
00: ENTER READ PASSWORD: READ
DMSVML2060I MAINT 191 linked as 0120 file mode Z
3. Now, copy the file PROFILE XEDIT from that disk to your A disk.
===> copy profile xedit z = = a
52
4. This will result in TCPMAINT's XEDIT sessions having the same look and feel as MAINT's.
5. List the CMS disks that are accessed via the QUERY DISK command. Note that the
TCPMAINT 198 disk is accessed as your D disk:
===> q disk
LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL
TCM191 191 A R/W 7 3390 4096 1 8-01 1252 1260
TCM198 198 D R/W 9 3390 4096 2 9-01 1611 1620
TCM591 591 E R/W 61 3390 4096 219 7988-73 2992 10980
TCM592 592 F R/W 70 3390 4096 917 9381-74 3219 12600
MNT190 190 S R/O 100 3390 4096 689 14622-81 3378 18000
MNT19E 19E Y/S R/O 250 3390 4096 1011 26739-59 18261 45000
6. This is an important disk for TCP/IP configuration files. List all the files on this disk. What is
the command?
===> _______________________________________________
TCPMAINT FILELIST A0 V 169 Trunc=169 Size=2 Line=1 Col=1 Alt=0
Cmd Filename Filetype Fm Format Lrecl Records Blocks Date Time
x PROFILE TCPIP D1 V 73 65 1 4/11/07 13:57:16
SYSTEM DTCPARMS D1 V 71 7 1 4/11/07 13:57:16
6.3.1 PROFILE TCPIP

1. Look at the file PROFILE TCPIP.
You can type an X, which is a synonym for XEDIT right in the FILELIST command
next to the file you want to edit.
2. Search for the string DEVICE. You should see many of the values that you typed into the
IPWIZARD. Following is an example file for TEAM11:
===> /device
...
DEVICE DEV@0800 OSD 0800 NONROUTER
LINK ETH0 QDIOETHERNET DEV@0800 MTU 1500
; (End DEVICE and LINK statements)
; ----------------------------------------------------------------------
; ----------------------------------------------------------------------
HOME
129.40.35.110 255.255.255.0 ETH0
; (End HOME Address information)
; ----------------------------------------------------------------------
GATEWAY
; Network Subnet First Link MTU
; Address Mask Hop Name Size
; ------------- --------------- --------------- ---------------- -----
DEFAULTNET 129.40.35.3 ETH0 1500
53
; (End GATEWAY Static Routing information)

; ----------------------------------------------------------------------
START DEV@0800
; (End START statements)
; ----------------------------------------------------------------------
3. Exit this file, enter:

===> qq
6.3.2 SYSTEM DTCPARMS

1. Now look at the file SYSTEM DTCPARMS.
You can type an X, which is a synonym for XEDIT right in the FILELIST command
next to the file you want to edit.
2. You should see the following:
.**********************************************************************
.* SYSTEM DTCPARMS created by DTCIPWIZ EXEC on 11 Apr 2007
.* Configuration program run by MAINT at 13:57:16
.**********************************************************************
:nick.TCPIP :type.server
:class.stack
:attach.0800-0802
This file is how the OSA devices 800, 801 and 802 are attached to the TCPIP service machine.
3. Exit this file:

Press the F3 key (or type qq)
4. If you are still in FILELIST mode, exit and return to RUNNING mode.
Press the F3 key
6.3.3 Renaming the PROFILE TCPIP file

One change that is recommended is to rename your main configuration file, PROFILE TCPIP. It is
possible that applying service to z/VM can overwrite the PROFILE TCPIP file.
1. Use the RENAME command to change the file:
===> rename profile tcpip d zvm<n> = d
2. Now you should test this change. You can do this by forcing the TCPIP user ID off the system
(logging it off) and then logging on interactively and watching it come back up. This is
analogous to a Linux “service network restart” command. Be careful when you do this. If you
are using the network to get to your system, you will immediately lose the connection.
54
===> force tcpip

3. Now logon to TCPIP and start the TCP/IP stack.
===> logoff TCPMAINT
===> logon TCPIP
Press Enter to run the PROFILE EXEC
Press Enter again to start the TCP/IP stack. Note that your renamed profile is
used:
z/VM Version 5 Release 3.0, Service Level 0701 (64-bit),
built on IBM Virtualization Technology
There is no logmsg data
FILES: NO RDR, NO PRT, NO PUN
LOGON AT 14:57:03 EDT WEDNESDAY 04/11/07
z/VM V5.3.0 2007-03-14 09:57
Press Enter
DMSWSP100W Shared S-STAT not available
DMSACP723I D (198) R/O
DMSACP723I E (591) R/O
DMSACP723I F (592) R/O
Ready; T=0.01/0.01 14:57:04
DTCRUN1022I Console log will be sent to default owner ID: TCPMAINT
DTCRUN1021R To cancel TCP/IP Stack startup, type any non-blank character and
press ENTER. To continue startup, just press ENTER.
Press Enter
DTCRUN1011I Server started at 14:57:06 on 11 Apr 2007 (Wednesday)
DTCRUN1011I Running "TCPIP"
DTCTCP001I z/VM TCP/IP Level 530
***** 04/11/07 *****
14:57:06 DTCIPI008I Initializing... TCPIP MODULE E2 dated 03/14/07 at 09:51
14:57:06 DTCIPI052I TCP/IP Module Load Address: 00C17000
14:57:06 DTCIPI009I Devices will use diagnose 98 real channel program support
14:57:06 DTCIPI012I TCP/IP running under z/VM system
14:57:06 DTCIPI005I Trying to open TCPIP TCPIP *
14:57:06 DTCIPI005I Trying to open ZVM11 TCPIP *
14:57:06 DTCIPI006I Using profile file ZVM11 TCPIP D1 dated 04/11/07 at 13:57
4. Now should you LOGOFF of TCPIP or DISCONNECT?

===> ___________________________________________
The former will kill the stack while the latter will allow it to run. A VM service machine is
analogous to a Linux daemon. Use the #CP DISC command. The #CP punches through to the
CP level.
55
6.4 Verify the TCPIP setup

If all went well, your z/VM should now be on the network. Let's try a few things to verify the
configuration is correct.
1. Start a TN3270 session and connect directly to you z/VM system. You now have the ability to
log on to more than one virtual machine at a time.
2. Log on as TCPMAINT.
3. Use the NETSTAT command to display information about your network.
Display the device information. You should see information about the QDIO1 device.
===> netstat dev
Display the gateway information. You should see information about the gateway.
===> netstat gate
4. Ping the gateway (first hop).
===> ping 129.40.35.3
5. Tracing routes through a network is sometimes necessary to help debug connectivity issues. Try the
TRACERTE command and trace the route to 129.40.45.254:
===> tracerte 129.40.45.254
The TRACERTE command reports that the path through the network to 129.40.45.254 passes through
129.40.35.3, the DEFAULT route (the qdio connection).
6. Log off the TCPMAINT virtual machine.
===> logoff
6.5 Setting up a virtual switch (VSWITCH) with

failover
n this exercise, we will setup the Virtual Switch to use two controllers and two separate sets of OSA
devices. If the primary controller fails, the backup controller will take over. Likewise, if the primary
OSA fails, traffic will be switched to use the backup OSA devices.
The high level steps in the process are in the sections that follow:
1. Define a VSWITCH
2. Add a NIC definition statement to the Linux user ID directory entries
3. Grant Linux Access to the VSWITCH
4. Shutdown and re-IPL z/VM
56
6.5.1 Define a VSWITCH

Define the Virtual Switch in the SYSTEM CONFIG file to ensure the Virtual Switch is defined on IPL. Use the
MODIFY VSWITCH statement to authorize a z/VM user to attach to the Virtual Switch.
1. Log on as MAINT.
2. Display a list of available OSA devices. You should see devices 900-902 and A00-A02 free.
===> q osa free
3. Execute the script to get write access to the primary parm disk.
===> getcf1
4. Edit the SYSTEM CONFIG file.
5. Add the following statements to the end of the file to:
/* define vswitch named vsw1 and set MAC address prefix to 02-00-01 */
define vswitch vsw1 rdev 900 A00
vmlan macprefix 020001
6. Save the changes end exit the file.
===> file
7. Check the syntax by using the CPSYNTAX command.
===> access 193 x
===> cpsyntax system config
8. Execute the script to release write access to the primary parm disk.
===> freecf1
6.5.2 Add a NIC definition to Linux virtual servers

Each Linux virtual server will need a virtual NIC so that a virtual ethernet cable can be attached into it.
A virtual NIC can be added via the NICDEF statement in the USER DIRECT file.
By adding the NICDEF statement in the LINDFLT profile section of the user directory, virtual server
entries including this profile will automatically get the NIC definition. When the server starts, the NIC
will be coupled to the virtual switch.
1. Edit the user directory source file.
===> x user direct
2. Add a NICDEF statement.
Find the LINDFLT profile and add the following line immediately following the CONSOLE statement.
57
nicdef 700 type qdio lan system vsw1
3. Save the changes and exit the file.

===> file
4. Run the DIRECTXA utility to build the user directory and put it on-line.
===> directxa user
6.5.3 Grant Linux Access to the VSWITCH

The AUTOLOG1 virtual machine is used to start services and customize z/VM each time it is IPLed.
(For those of you with z/OS experience this is like using the COMMANDxx members in sys1.parmlib.
For UNIX/Linux experienced people, this is like adding scripts to be executed each time you boot in
the rc.d directory infrastructure). Up to this point, we have been responding “NOAUTOLOG” at the
operator prompt, telling z/VM not to process the commands found in AUTOLOG1’s PROFILE EXEC.
You’ll now edit the PROFILE EXEC for user AUTOLOG1 to:
● Start the TCPIP Virtual Machine
● Start the VSWITCH controllers
● Grant LINUX1 and LINUX2 access to the VSWITCH VSW1
1. Link to AUTOLOG1's 191 minidisk. Use mode MW to access the disk in “shared” WRITE mode.
===> link autolog1 191 291 mw
2. Access the 291 minidisk as Z.
===> access 291 z
3. Edit AUTOLOG1’s PROFILE EXEC:
===> x profile exec z
4. Replace the contents of the PROFILE EXEC file with the following lines:
/***************************/
/* Autolog1 Profile Exec */
/***************************/
'CP AUTOLOG TCPIP TCPIP'
'CP XAUTOLOG DTCVSW1'
'CP SET VSWITCH VSW1 GRANT LINUX1'
'CP LOGOFF'
The original AUTOLOG1's PROFILE EXEC contained AUTOLOG commands for VMSERVS,
58
VMSERVU, and VMSERVR. These ID's provide z/VM's shared filed services. You are not using the
shared file system so they can be removed.
Statement Description
'CP AUTOLOG TCPIP TCPIP' Starts z/VM's TCPIP stack. In most instances, you want to start TCPIP
at every IPL (for security reasons, some shops do not put z/VM on the
network).
'CP XAUTOLOG DTCVSWn' Start the two VSWITCH controllers.
'CP SET VSWITCH VSW1 GRANT LINUXn' Grants LINUX1 and LINUX2 access to VSWITCH VSW1 (yes,
LINUX2 does not exist yet, but it will later).
'CP LOGOFF' The virtual machine is logged off so it doesn't continue to use memory.
6.5.4 Test the VSWITCH configuration

Restart the z/VM system and verify the changes you have made in the networking section.
1. Shutdown and re-ipl your z/VM system.
===> shutdown reipl
2. Log on as MAINT.
3. Display the VSWITCH:
===> q vswitch
Is the VSWITCH VSW1 defined ? _______________
4. To see the status of the VSWITCH controllers, issue the command:
===> q controller
Which controller is your primary? _________________
5. To see which virtual servers have access to the VSWITCH, issue the command:
===> q vswitch access
Are LINUX1 and LINUX2 allowed to use VSWITCH VSW1? ____________
If any of the above commands indicated you have problems in your setup, review your work and try
again. You will test the failover capability of the VSWITCH in a later exercise.
59
Unit 7: Performance Monitoring Tools

7.1 The z/VM Performance Toolkit
The Performance Toolkit for z/VM is a global performance product that provides real-time monitoring
functions and historical performance analysis for multiple z/VM systems (local or remote). In this
section you will learn how to enable the the Performance Toolkit. You will go over later in the class
how to use the Performance Toolkit for understanding basic system performance. It provides the
following functions:
7.1.1 Enabling the Performance Toolkit

You should still be logged onto MAINT.
1. Edit the SYSTEM CONFIG file and turn the prefix area off so you can better read the file.
===> getcf1
===> pre off
2. Go to the last two lines before where you defined the VSWITCH. You should see that the
Performance Toolkit for VM is DISABLED. Change it to ENABLED:
PRODUCT PRODID 5VMPTK30 STATE ENABLED DESCRIPTION
'00/00/00.00:00:00.$BASEDDR ERFORMANCE TOOLKIT FOR VM'
3. Verify the syntax with the CPSYNTAX command. When the system is re-IPL'ed next time, the
product will be enabled.
==> cpsyntax system config
4. You can also enable the product dynamically using the SET PRODUCT command:
===> set product prodid 5vmptk30 state enabled
7.1.2 Configuring the Web interface

Once the product is enabled, the TCPIP profile must be configured to add browser capabilities for the
Performance Toolkit.
1. Logon to TCPMAINT.
2. Edit the ZVM<n> TCPIP file and search for “port”. This is where z/VM TCP/IP ports are
reserved:
===> x zvm<n> tcpip d
60
===> /port
3. Add a line for PORT 81. Setting the Performance Toolkit to use port 81 will cause a browser
pointed to your z/VM system to show the Toolkit output.
PORT
; 20 TCP FTPSERVE NOAUTOLOG ; FTP Server
; 21 TCP FTPSERVE ; FTP Server
23 TCP INTCLIEN ; TELNET Server
; 25 TCP SMTP ; SMTP Server
; 53 TCP NAMESRV ; Domain Name Server
; 53 UDP NAMESRV ; Domain Name Server
; 67 UDP DHCPD ; DHCP Server
; 69 UDP TFTPD ; TFTPD (Trivial FTP) Server
81 TCP PERFSVM ; z/VM Performance Toolkit
; 111 TCP PORTMAP ; Portmap Serverr
4. Save your changes.

===> file
5. TCPIP needs to be recycled in order for our changes to take effect. One way to do this is to
force off and automatically log on the TCPIP user ID. This assumes that you are accessing your
Linux system through the first level TEAM<n> user ID. If you are accessing your system via its
IP address, forcing TCPIP will kill your 3270 session:
===> force tcpip
===> xautolog tcpip
6. Check if everything was successful by issuing the NETSTAT CLIENTS command. You want
to see that the service PERFSVM is a client (listening). It should be the last entry in the list:
===> netstat clients
...
Client: PERFSVM Authorization: {none}
Notes Handled: none
Last Touched: 0:07:17
Vmcf error count: 0
...
This shows that you have enabled the Performance Toolkit.
7.1.3 Configure the Performance Toolkit
1.3.1 The PERFSVM service machine

PERFSVM is the Performance Toolkit service machine. This is where the configuration files are
located and the where the toolkit is started.
1. Logon to PERFSVM.
61
Logoff of TCPMAINT
Logon to PERFSVM
2. After you have logged on and pressed Enter, the guest will execute an EXEC that puts you in
the Performance Toolkit environment. Exit from this environment to return to RUNNING
state.
Enter the PF3 key twice
3. Before you start, it is recommended to copy the PROFILE XEDIT from MAINT's 191 disk so
that XEDIT environment will have a common feel.
===> vmlink maint 191
ENTER READ PASSWORD: READ
===> copy profile xedit z = = a
1.3.2 The configuration files

Copy the default configuration files, which are on PERFSVM's D disk, to your A disk:
===> copy * * d = = a
FCONX $PROFILE
1. The main configuration file is FCONX $PROFILE. Edit that file and search for the string VMCF.
===> x fconx $profile a
===> /vmcf
2. This should take you to the “activates VMCF data retrieval interface” section. This sets the Performance
Toolkit to collect Linux performance data.
Modify as shown below:
* Following command activates VMCF data retrieval interface
FC MONCOLL VMCF ON
* Following command activates Internet interface
FC MONCOLL WEBSERV ON TCPIP TCPIP 81 IDTEST CP
* Following command activates Internet interface with SSL
*C MONCOLL WEBSERV ON SSL TCPIP TCPIP 81 IDTEST RACF
* Following command activates TCP/IP interface for data retrieval
* from LINUX RMF DDS interface
FC MONCOLL LINUXUSR ON TCPIP TCPIP
...

===> file
62
FCONRMT AUTHORIZ
The remote data retrieval authorization file. It specifies the systems to be monitored.
1. Create the FCONRMT AUTHORIZ file:
===> x fconrmt authoriz
2. Add the following 2 lines - replace ZVM<n> with your system name:
ZVM<n> PERFSVM S&FSERV
ZVM<n> MAINT DATA CMD EXCPMSG

===> file
FCONRMT SYSTEMS
1. Create the FCONRMT SYSTEMS file:
===> x fconrmt systems
2. Add the following line - replace ZVM<n> with your system name:
ZVM<n> PERFSVM ESA N FCXRES00

===> file
FCONX LINUXUSR
The Linux System Definition File. It defines the Linux systems to be monitored:
1. Create the fCONX LINUXUSR file:
===> x fconx linuxusr
2. Add the following 2 lines: TCP/IP addresses of your two Linux systems:
LINUX1 129.40.35.<xxx>:8803
LINUX2 129.40.35.<yyy>:8803

===> file
PROFILE EXEC
This file contains the types of data to be collected.
1. Edit the PROFILE EXEC file:
===> x profile exec
2. Search for the string enabled:
63
===> /enabled
3. Uncomment the five MONITOR SAMPLE and the two MONITOR EVENT statements by
removing the /* */ around each line :
/*** Once you have PERFKIT enabled and running uncomment the ***/
/*** following comments ***/
'CP MONITOR SAMPLE ENABLE PROCESSOR'
'CP MONITOR SAMPLE ENABLE STORAGE'
'CP MONITOR SAMPLE ENABLE USER ALL'
'CP MONITOR SAMPLE ENABLE I/O ALL'
'CP MONITOR SAMPLE ENABLE APPLDATA ALL'
'CP MONITOR EVENT ENABLE STORAGE'
'CP MONITOR EVENT ENABLE I/O ALL'
'PERFKIT' /* Invoke the PERFKIT module @FC012BD*/
Exit
===> file
7.1.4 Start the Performance Toolkit

Your z/VM Performance Toolkit should now be configured to monitor z/VM and Linux
performance.You are ready to start the performance toolkit.
1. At the CMS command line enter the perfkit command. You should note that a Web server is
started on port 81:
===> perfkit
FCXBAS500I Performance Toolkit for VM FL530 31Oct06
FCXAPP530I Connected to *IDENT for resource FCXRES00
FCXAPF530I Connected to *IDENT for resource FCXSYSTM
FCXTCP571I Connected to TCP/IP server TCPIP on path 0003
FCXAPP527I User PERFSVM connected on path 0006
FCXAPC535I Connected to resource FCXRES00 on path 0005, for S&F-Coll
FCXTCP575I WebServer host IP address is 129.40.35.140:00081
FCXTCP590I WebServer interface activated
Monitor event started -- recording is activated
Monitor sample started -- recording is activated
2. Disconnect from PERFSVM now. The Performance Toolkit is running as a service virtual
machine.
===> #cp disc
64
7.1.5 Using the Performance Toolkit

1. Bring up a browser and point it to your z/VM system:
http://129.40.35.<n>0:81
2. Logon as MAINT.
VM UserID: maint
Password: maint
Click Submit
You should see the Central Monitory System Load Overview screen.
3. Select the system to monitor. Under the Node-ID column:
Click on your system name
You should see the Initial Performance Data Selection Menu screen similar to the following:
4. Note the screen number 29, Linux systems is a hot link. If you drill down into it, the CPU,
memory and network links will be dead. Later you will enable Linux virtual servers to provide
this performance data.
Linux screens selection
65
S Display Description
. LINUX RMF PM system selection menu
. LXCPU Summary CPU activity display
. LXMEM Summary memory util. & activity display
. LXNETWRK Summary network activity display
Congratulations, you have configured a Web interface to the z/VM Performance Toolkit.
66
Unit 8: Install Linux

Important: Because Anaconda is not very efficient in terms of I/O and because Linux will be
installed third level (Linux under VM under VM), the process of cross referencing and copying
RPMs is very lengthy. A manual install will take an hour or more. Cloning a RHEL5 server should
take only 15-20 minutes. For this part of the workshop, you will clone the linux server. You will
perform a full installation later on in the second half of the workshop.
8.1 Prepare the Linux virtual machine

First, let's log on to the LINUX1 virtual machine from a TN3270 session.
Logon as LINUX1
There are several files we need to transfer from the workshop server to the “A” disk. You will use FTP
to connect to the workshop server and copy the following files under the /mnt/rhel5root/ directory.
● PROFILE EXEC for Linux user Ids
● SWAPGEN EXEC for VDISKs swap spaces
Connect to the workshop NFS server:
===> ftp 129.40.35.3
ftp> user1/user1
ftp> cd /mnt/rhel5root
ftp> mget *.EXEC
ftp> quit
The PROFILE EXEC that you just copied is a REXX EXEC that is analogous to a .bash_profile startup
script. It first creates two VDISK swap spaces in memory of sizes 256MB and 512MB. If the user ID is
logged on in a disconnected mode (usually via XAUTOLOG), Linux will be IPLed from minidisk 100.
Otherwise the user is prompted.
===> type profile exec
Following are the contents:
/* PROFILE EXEC for Linux virtual servers - If user is disconnected
IPL Linux at 100, otherwise prompt user to IPL from 100 */
'CP SET RUN ON'
'CP SET PF11 RETRIEVE FORWARD'
'CP SET PF12 RETRIEVE'
'SWAPGEN 101 524288' /* create a 256M VDISK disk swap space */
'SWAPGEN 102 1048576' /* create a 512M VDISK disk swap space */
'PIPE CP QUERY' userid() '| var user'
parse value user with id . dsc .
if (dsc = 'DSC') then /* user is disconnected */
'CP IPL 100'
else /* user is interactive -> prompt */
67
do
say 'Do you want to IPL Linux from DASD 100? y/n'
parse upper pull answer .
if (answer = 'Y') then /* IPL Linux at 100 */
'CP IPL 100'
else /* CMS is wanted */
'ACC 592 C'
end
You will be running this EXEC soon.
8.2 Cloning a RHEL5 Linux server

A minimal RHEL5 server with networking turned off can be found on the workshop shared 705 disk.
You will be cloning using this master copy.
8.2.1 Copy from the master clone

1. Logon to MAINT.
2. Look at your free DASD with the QUERY DASD FREE command to make sure the 705 disk is
available to your virtual machine.
===> q da free
3. To work with the disk, you must attach it to yourself (*):
===> att 705 *
4. Link the LINUX1 100 disk read/write (MR):
===> link linux1 100 100 mr
5. Use the DDR utility to copy the master disk to the LINUX1's 100 disk. The DDR command is
similar to the Linux dd command, however the session is more interactive. You specify the
Input device of type 3390, the OUTput device also of type 3390, then give the COPY ALL
subcommand. This should take 8-10 minutes:
===> ddr
z/VM DASD DUMP/RESTORE PROGRAM
ENTER:
in 705 3390
ENTER:
out 100 3390
ENTER:
copy all
HCPDDR711D VOLID READ IS 0X0100
DO YOU WISH TO CONTINUE? RESPOND YES, NO OR REREAD:
yes
HCPDDR711D VOLID READ IS 0X0100
DO YOU WISH TO CONTINUE? RESPOND YES, NO OR REREAD:
68
yes
COPYING 0X0100
END OF COPY
6. When you see the “END OF COPY” message, exit the DDR utility:
Press the Enter key
8.2.2 IPLing the cloned Linux

1. Boot (IPL) LINUX1 using the copied disk (100).
===> Logon to LINUX1
2. Now the PROFILE EXEC will run. You should see the two VDISK swap spaces get created at
addresses 101 and 102. Because you are logging on interactively, not disconnected, you can IPL
the new Linux by answering y to the question.
===> y
3. Linux should IPL. You can wait 15 seconds at the interactive boot menu, or type
===> #cp vi vmsg 0
4. 00: zIPL v1.5.3 interactive boot menu
5. 00:
6. 00: 0. default (linux)
7. 00:
8. 00: 1. linux
9. 00:
10.00: Note: VM users please use '#cp vi vmsg <input>'
11.00:
12.00: Please choose (default will boot in 15 seconds):
13. At the login prompt,

Login as root/redhat
8.2.3 Configure the network

There is no network because it was turned off via chkconfig. This is necessary so each Linux does not
come up with the same IP address:
# chkconfig --list network
network 0:off 1:off 2:off 3:off 4:off 5:off 6:off
There are three files where the IP address and host name have to be modified.
● /etc/sysconfig/network-scripts/ifcfg-eth0 - IP address
● /etc/sysconfig/network - Host name
69
● /etc/hosts - Host name

You will have to work with a 3270 session until you get networking going. The vi editor does not
work in a 3270 session, so the sed or ed commands are often used when files have to be modified.
/etc/sysconfig/network-scrips/ifcfg-eth0
1. Note the current IP address in the file /etc/sysconfig/network-scrips/ifcfg-eth0
# cd /etc/sysconfig/network-scripts
# cat ifcfg-eth0
# IBM QETH
DEVICE=eth0
BOOTPROTO=static
IPADDR=129.40.35.141
MTU=1500
NETMASK=255.255.255.0
NETTYPE=qeth
ONBOOT=yes
PORTNAME=DONTCARE
SUBCHANNELS=0.0.0700,0.0.0701,0.0.0702
MTU=1500
2. Use sed -i to change the IP address from from <n>1 to <n>2 corresponding to your team
number:
# sed -i ifcfg-eth0 -e 's/141/<n>1/g'
3. Verify the file has been modified correctly:
# cat ifcfg-eth0
/etc/sysconfig/network
1. Modify the /etc/sysconfig/network file:
# cd /etc/sysconfig
# cat network
Note that the host name in /etc/sysconfig/network is for Team 14.
2. Change the host name to correspond to your team number.
# sed -i network -e 's/zvm14/zvm<n>/g'
# cat network
/etc/hosts
1. Modify the /etc/hosts file. Change the host name to correspond to your team number.
70
# cat /etc/hosts
# sed -i /etc/hosts -e 's/zvm14/zvm<n>/g'
# cat /etc/hosts
8.2.4 Start the network

Set the network to come up. Then reboot your system to test your changes:
# chkconfig network on
# reboot
When the system comes back up, you should now have a running RHEL 5 system.
8.3 Add VDISK swap spaces

Whether you cloned a RHEL5 system or installed manually, you should now be able to SSH into it via
PuTTY or another SSH client.
1. SSH into your server cloned server and log in as root/redhat.
2. Look at your file systems with the df -h command. It should be about ¾ full:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/dasda1 1.1G 807M 260M 76% /
tmpfs 250M 0 250M 0% /dev/shm
3. Use the lsdasd command to list the disk devices that you have. Compare this with the file
system table:
# lsdasd
0.0.0100(ECKD)at(94:0) is dasda:active at blocksize 4096, 297000 blocks, 1160 MB
0.0.0101(FBA )at(94:4) is dasdb:active at blocksize 512, 524288 blocks, 256 MB
0.0.0102(FBA )at(94:8) is dasdc:active at blocksize 512, 1048576 blocks, 512 MB
# cat /etc/fstab
LABEL=/ / ext3 defaults 1 1
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
You should notice that /dev/dasdb (101) and /dev/dasdc (102) are not being used. Remember
these devices are virtual disks in memory that were created by the SWAPGEN EXEC which
was called by the PROFILE EXEC when you logged onto your system. One important attribute
71
of these disks is that the memory is not used until it is referenced. So if the system never swaps,
almost no memory is used (perhaps only 8KB per VDISK).
4. Note that there are no swap spaces:
# swapon -s
5. Make a backup copy of the /etc/fstab file then add two swap spaces to it.
# cd /etc
# cp fstab fstab.orig
# vi fstab
LABEL=/ / ext3 defaults 1 1
/dev/dasdb1 swap swap defaults 0 0
/dev/dasdc1 swap swap defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
6. Use the swapon -a command to turn on all swap spaces. The file /etc/fstab will be read. This
has the side effect of testing the changes you made to the file. Verify that you now have two
swap spaces:
# swapon -a
# swapon -s
Filename Type Size Used
Priority
/dev/dasdb1 partition 259956 0 -1
/dev/dasdc1 partition 519924 0 -2
7. Shutdown the system because you will be defining more networking resources to z/VM.
# shutdown -h now
8.4 Add a z/VM Guest LAN

You have created a z/VM virtual switch and installed Linux using that switch as the network
connection. However, there are times when an isolated LAN is a better option. This is when a z/VM
Guest LAN is used.
The steps involved in creating and implementing a Guest LAN are as follows
● Define the Guest LAN
● Define a NIC for each Linux user ID
● Attach Linux systems to the Guest LAN
72
8.4.1 Define the Guest LAN

1. Logon to MAINT.
2. Edit the SYSTEM CONFIG file
===> getcf1
===> x system config
3. Add the following two lines to the bottom of the SYSTEM CONFIG file. This will define a
Hipersocket-style Guest LAN.
/* Define a guest LAN named glan1 of type QDIO */
define lan glan1 type hiper maxconn 100 ownerid system
4. Verify the syntax of your changes. The CPSYNTAX command is on the MAINT 193 disk.
Access it as your G disk.
===> _______________________________________________________
===> _______________________________________________________
5. You could set the CP A disk back online with the following commands:
===> freecf1
6. Re-IPL z/VM to test the creation of the Guest LAN at system startup. Before you re-IPL, see
that there is no LAN named GLAN1 via the QUERY LAN command:
===> q lan glan1
===> shutdown reipl
You should see the system go down and come back up. Note that when you include the REIPL
parameter, the OPERATOR ID is automatically disconnected from.
7. When the system comes back, logon as MAINT. Verify that the new guest LAN has been
created:
Log on to MAINT
===> q lan glan1
LAN SYSTEM GLAN1 Type: HIPERS Connected: 0 Maxconn: 100
PERSISTENT UNRESTRICTED IP MFS: 16384 Accounting: OFF
IPTimeout: 5
This shows that you have created a Hipersocket-style Guest LAN at z/VM IPL time.
8.4.2 Define a NIC for each Linux user ID

Now that the Guest LAN is defined, it is very easy to give each Linux user ID a NIC to it.
1. Edit the USER DIRECT file and add a SPECIAL statement, defining a NIC starting at virtual
73
device 800. The same way all Linux user ID's get a virtual NIC to the VSWITCH starting at
virtual address 700, they will get a virtual NIC to the Guest LAN starting at virtual address 800:
===> x user direct
PROFILE lindflt
IPL CMS
MACH esa 4
cpu 00 base
cpu 01
SPOOL 000D 2540 PUNCH A
SPOOL 000E 1403 A
CONSOLE 009 3215 T
nicdef 700 type qdio lan system vsw1
special 800 hiper 3 system glan1
LINK MAINT 0190 0190 RR
LINK MAINT 019D 019D RR
LINK MAINT 019E 019E RR
LINK tcpmaint 592 592 rr
2. Bring your changes online. What is the command?
===>__________________________________________________
8.4.3 Attach Linux systems to the Guest LAN

1. Now IPL linux from LINUX1.
Logon to LINUX1
IPL Linux
You should immediately note that a second NIC is created as you log on. This is because the
new directory defintion of LINUX1 includes a NIC definition (SPECIAL) that connects the
virtual machine to the guest LAN named GLAN1:
LOGON LINUX1
00: NIC 0700 is created; devices 0700-0702 defined
00: NIC 0800 is created; devices 0800-0802 defined
00: z/VM Version 5 Release 3.0, Service Level 0701 (64-bit),
...
2. Verify that both NICs have been activated. Note the type of the second NIC and that the MAC
address is automatically incremented:
===> #cp q nic
00: Adapter 0700 Type: QDIO Name: DONTCARE Devices: 3
00: MAC: 02-00-01-00-00-02 VSWITCH: SYSTEM VSW1
00: Adapter 0800 Type: HIPERS Name: UNASSIGNED Devices: 3
00: MAC: 02-00-01-00-00-03 LAN: SYSTEM GLAN1 MFS: 16384
3. Log in as root
Start an SSH session
74
Log in as root
4. Change directory to /sys/bus/ccwgroup/drivers/qeth. You should see the one device that is
being driven by the qeth/qdio driver.
# cd /sys/bus/ccwgroup/drivers/qeth
# ls
0.0.0700 group notifier_register
5. What is device 0.0.0700?______________________________________________________
6. Our new device is a triplet starting at 800. To notify the qdio/qeth driver of this device, you
must echo the virtual device addresses to the special file named group. You should see a new
directory 0.0.0800 get created for this triplet:
# echo 0.0.0800,0.0.0801,0.0.0802 > group
# ls
0.0.0700 0.0.0800 group notifier_register
7. Change into this directory. There are many files relating to the data structures of the driver. Two
important ones are named portname, online and if_name. In the past, a port name identifier
was also necessary to connect a NIC to an OSA device. This requirement has been relaxed.
Confirm that no portname is required:
# cd 0.0.0800
# cat portname
no portname required
8. Another important file is named online. By default the new device is not online. Bring it online
by echoing a 1 to the file:
# cat online
0
# echo 1 > online

9. Verify that the change was accepted by viewing the file again. If the file does not contain a “1”,
you must determing what went wrong (there may be some output on the 3270 session).
# cat online
1
10. Finally the file if_name contains the name of the new interface. Verify the new device is named
hsi0:
# cat if_name
hsi0
If you had defined the Guest LAN as type QDIO, the interface name would have been eth1. But
because it was defined as type hipersockets, the prefix hsi is used.
11. You should now be able to bring the device online via the following ifconfig command.
75
# ifconfig hsi0 10.0.0.1 netmask 255.255.255.0 mtu 1500 up

12. Verify it came online:
# ifconfig hsi0
hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:352 (352.0 b)
Your Linux system now has an interface to a 10.0.0/24 private network. At this time, there is no other
system on that network, so there is no way to test with a ping. That will be done later.
8.4.4 Configure the device to come online at IPL time

You have brought the new interface up manually, however, it would not be defined after a reboot. You
need to make this interface permanent in the directory /etc/sysconfig/network/.
There is a one-to-one relationship between the files in these two directories. In the
/etc/sysconfig/hardware/ directory, the configuration files have a naming convention of hwcfg-<device
type>-bus-<bus type>-<bus location>.
The scripts to manipulate network interfaces are in the directory /etc/sysconfig/network-scripts/, and
the file names begin with the prefix “ifcfg-”.
1. Let's look at the current interfaces:
# cd /etc/sysconfig/network-scripts/
# ls ifcfg-*
ifcfg-eth0 ifcfg-lo
The ifcfg-eth file brings up the ethernet interface while the ifcfg-lo file brings up the local
loopback interface.
2. Copy the configuration script for the ethernet device (eth0) to a file for the hipersocket device
(hsi0). Note that interface name is specified in the file name:
# cp ifcfg-eth0 ifcfg-hsi0
3. Edit the new file and set:
DEVICE=hsi0
IPADDR=10.0.0.1
SUBCHANNELS=0.0.0800,0.0.0801,0.0.0802
# vi ifcfg-hsi0
# IBM QETH
DEVICE=hsi0
76
BOOTPROTO=static
IPADDR=10.0.0.1
MTU=1500
NETMASK=255.255.255.0
NETTYPE=qeth
ONBOOT=yes
PORTNAME=DONTCARE
SUBCHANNELS=0.0.0800,0.0.0801,0.0.0802
MTU=1500
Save the file.

4. You have now created a hardware configuration file and a network script for the new hsi0
interface. Test this script by rebooting your Linux
# reboot
5. You will lose your SSH session. You can go back to your 3270 session, logon to LINUX1 and
see your Linux system come back up. Or you can wait a minute or two and get a new SSH
session to LINUX1. Invoke the ifconfig command to see your interfaces. You should see the
new hsi0 interface:
Log in to root
# ifconfig
eth0 Link encap:Ethernet HWaddr 02:00:01:00:00:03
inet:129.40.35.<n>1 Bcast:129.40.35.255 Mask:255.255.255.0
inet6 addr: fe80::200:100:200:3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX bytes:4798 (4.6 Kb) TX bytes:7849 (7.6 Kb)
hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00

inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX bytes:0 (0.0 b) TX bytes:440 (440.0 b)
...
Congratulations, you have defined a Guest LAN to z/VM and tested that it is created at IPL-
time. You created a NIC for LINUX1 and all other user IDs using the PROFILE LINDFLT.
You have dynamically defined a new interface on Linux and configured your system to create
the device at boot-time.
6. Next it is time to learn how to clone this system. It is always recommended to clone a quiesced or shut
down system, so shut your system down now then log off of it.
# shutdown -h now
77
Log off LINUX1 from z/VM
78
Unit 9: Cloning Linux virtual servers

Now it’s time to take advantage of z/VM's ability to rapidly create cloned Linux systems. You have
your first Linux and various networking options defined and tested. Adding new Linux systems can be
done quickly Let’s see how easy it is to add a new Linux system to our z/VM.
For this cloning exercise we will z/VM's minidisk capability by sharing the ZVMPK1 pack between
two LINUX systems. You will complete the definition of the LINUX2 user ID and use z/VM’s DDR
(DASD Dump Restore) utility to copy the minidisks.
9.1 Add the LINUX2 virtual machine to z/VM

1. Logon as MAINT.
2. Edit the user directory.
===> x user direct
3. Add the following statements at the bottom of the file to create the LINUX2 virtual machine.
Allocate the same size 100 disk as LINUX1. Share LINUX1's 191 disk instead of creating it's
own .
user linux2 linux2 256M 1G g
include lindflt
mdisk 100 3390 <start-cylinder> <end-cylinder> zvmpk1 mr rapache wapache
mapache
link linux1 191 191 rr
The last link statement allows LINUX2 to share a 191 disk with LINUX1.
What should be the start-cylinder? _____________________________
What should be the end-cylinder? _____________________________
4. Create a mapping of the disk allocations.
===> diskmap user
5. Verify that there are no overlaps.
===> x user diskmap
6. Exit the file.
===> qq
7. Put the directory online.
===> directxa user
79
9.2 Clone LINUX2

Use the DASD Dump Restore (DDR) utility to 'clone' (copy) LINUX2 from LINUX1. You should still
be logged on as MAINT.
1. Link to LINUX1’s 100 disk as B00 in read-only mode. This is the source disk.
===> link linux1 100 B00 rr
It is always a good practice to link the source disk read-only just in case you copy the data in
the wrong direction. The minidisk read password set in the USER DIRECT file is RAPACHE,
however, it is not needed by MAINT because the OPTION LNKNOPAS in MAINT's user ID
definition means that minidisk passwords are not needed.
2. Link to LINUX2’s 100 disk as A00 in multi-read (write) mode. This is the target disk.
===> link linux2 100 A00 mr
3. Invoke the DDR utility to copy the 100 minidisk as described below. You do not have to get
out of the DDR to copy the next minidisk, just start with the IN statement.
===> DDR
===> IN B00 3390
===> OUT A00 3390
===> COPY ALL
===> reply 'yes' to continue
===> reply 'yes' to continue
===> Press Enter to quit
4. Log off MAINT. This will release all the accessed minidisks.
9.3 Configure the cloned server

At this point, you have two identical virtual servers with exactly the same network configuration. The
next step is to IPL LINUX2 to change it's network.
1. IPL the LINUX2 virtual server from z/VM
Logon as LINUX2
IPL the system
2. Start an SSH session, connect to LINUX2 and log in as root.
SSH into LINUX2 as root.
3. Change the network configuration as follows:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
Set the primary IP address to 129.40.35.<n>2
80
# vi /etc/sysconfig/network-scripts/ifcfg-hsi0
Set the IP address to 10.0.0.2
# vi /etc/sysconfig/network
Set the host name to zvm<n>lin2
# vi /etc/hosts
Set the host name to zvm<n>lin2
9.4 Reboot server with new network

Now reboot your system to test the changes.
1. Reboot your Linux virtual server.
# reboot
# exit
Your system should come back in a minute or two. Start a new SSH session to the new IP
address. If there is a problem, you will have to go to your 3270 session and investigate
(remember you can't use vi from a 3270 session).
2. Log in as root.
SSH into LINUX2 as root.
3. Verify that all your changes have been modified correctly.
# hostname
# ifconfig eth0
# ifconfig hsi0
9.5 Test networking on both Linux systems

To test networking between LINUX1 and LINUX2, they both need to be running. Right now you
should have LINUX2 running, but LINUX1 still logged off. You could logon LINUX1 and answer yes
to the question of IPLing Linux. But there is another way to boot LINUX1. The XAUTOLOG
command automatically logs on another user.
1. Logon as MAINT and IPL LINUX1

===> xautolog linux1
The Linux system on LINUX1 should come up in about a minute.
2. When your system comes up, start an SSH session to it.
81
SSH to LINUX1 as root

3. Test a ping using both eth0 (VSWITH) and hsi0 (Guest LAN) interfaces. You should be able to
ping over two interfaces from each of the two Linux systems.
From LINUX1:
# ping -c1 129.40.35.<n>2
# ping -c1 10.0.0.<2>
[root@zvmxlin1 ~]# ping -c1 129.40.35.122
PING 129.40.35.122 (129.40.35.122) 56(84) bytes of data.
64 bytes from 129.40.35.122: icmp_seq=1 ttl=64 time=1.64 ms
--- 129.40.35.122 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.644/1.644/1.644/0.000 ms
--- 10.0.0.2 ping statistics ---

From LINUX2:
# ping -c1 129.40.35.<n>1
# ping -c1 10.0.0.<1>
--- 129.40.35.121 ping statistics ---

--- 10.0.0.1 ping statistics ---

If any of the tests fail, go back and try to fix the problem.
Congratulations, you have created a Linux image with two different types of networking interfaces,
cloned that system, modified the clone and have the two systems communicating.
82
Unit 10: Test the Virtual Switch failover

capabilities
10.1 Verify the VSWITCH setup
1. You should be still logged on as MAINT, if not
Logon as MAINT
2. Display the status of the VSWITCH.
===> q vswitch
You should see output similar to the following:
● The primary controller is DTCVSW1 with OSA devices 900-902.
● The primary controller is DTCVSW1 with OSA devices A00-A02.
q vswitch
VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED NONROUTER Accounting: OFF
VLAN Unaware
MAC address: 02-00-01-00-00-01
State: Ready
IPTimeout: 5 QueueStorage: 8
RDEV: 0900 VDEV: 0900 Controller: DTCVSW1
RDEV: 0A00 VDEV: 0A00 Controller: DTCVSW2 BACKUP
Ready; T=0.01/0.01 13:53:36
Which is your primary controller ______________ and what are the OSA devices
_____________
Which is your backup controller ______________ and what are the OSA devices
_____________
3. Open an SSH session to LINUX1 and log on as root.
Log in to LINUX1 as root
4. Start a ping to LINUX2's primary TCP/IP address and let it run.
===> ping 129.40.35.<n>2
10.2 Simulate an OSA failure

The loss of an OSA device is simulated via the DETACH command.
1. While the ping is running on Linux, go back to MAINT and simulate an OSA failure by
detaching the OSA devices used by the primary controller. For example:
83
===> det <xxx-xxx> <primary-controller> (e.g., det 900-902 dtcvsw1)
Go back to the LINUX1 SSH session. You should see the ping output continue without
hesitation. The backup has now taken over as the primarily to service network requests. In the
mean time, z/VM is in the process of recovering the failed controller. You can leave the ping
going for the next test.
2. Display the status of the virtual switch again. You should see that z/VM failed over to the
secondary OSA device and that what was the primary is now the backup.
Note: The backup controller will take a few minutes to come online. In the meantime you may
see query command returns a state of error for the failed controller. Repeat the command in 1
minutes until the backup controller is in backup state.
===> q vswitch
VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED NONROUTER Accounting: OFF
VLAN Unaware
State: Ready
IPTimeout: 5 QueueStorage: 8
RDEV: 0900 Controller: DTCVSW2 VDEV: 0900 BACKUP
RDEV: 0A00 Controller: DTCVSW1 VDEV: 0A00
10.3 Simulate a VSWITCH controller failure

Now simulate a VSWITCH controller failure (which almost never happens).
1. Determine which controller is the primary:
===> q controller
The primary controller is __________________________________________________
2. From MAINT, use the FORCE command to log the primary controller off.
===> force <primary controller>
3. Again query the controllers.

===> q controller
You should see that the remaining controller is now acting as the primary and backup
controller, since the other one is logged off.
4. Back on LINUX1, the ping should still be running. Stop it now by entering:
# ctrl-c
You have demonstrated the highly available (HA) features of a z/VM virtual switch. Implementing
these at the z/VM layer pushes the HA qualities down to all Linux guests.
84
85
Unit 11: Basic system automation

11.1 Startup and Shutdown Policy
It is useful to configure z/VM so that all production Linux systems, or all Linux systems desired to be
started, come up when z/VM is IPLed. Contrarily, when z/VM is shut down, it is useful for all Linux
systems running to first come down cleanly. z/VM has a facility that allows a privileged user to set a
time parameter that defines the amount of time reserved for guests to come down after the z/VM
SHUTDOWN command is issued, but before z/VM itself comes down. This value is used as the default
timeout interval for SIGNAL, FORCE, and SHUTDOWN commands when no explicit interval is
specified. If SET SIGNAL SHUTDOWN is not specified in the system configuration file, the default
is 0, which suppresses guest shutdown signals.
11.2 Autolog Linux systems to boot at z/VM IPL

The PROFILE EXEC on the AUTOLOG1 191 is designed to customize the z/VM IPL process. If the
parameter NOAUTOLOG is not given at z/VM IPL time, then AUTOLOG1 is autologged and the
EXEC is run. To review, this is what the file should contain:
/***************************/
/***************************/
'CP LOGOFF'
1. Logon to AUTOLOG1
Logon as AUTOLOG1, but don't press Enter at the VM READ prompt:
What will happen if you press Enter? ____________________________________________
The PROFILE will run which has a final command of LOGOFF. AUTOLOG1 will be logged
off.
2. There is a special command to avoid this situation. Type:
===> acc (noprof
This means to continue processing without running the profile. You should now in Running
state.
3. Edit the PROFILE EXEC and add statements to
● automatically log on LINUX1 and IPL Linux
● automatically log on LINUX2 and IPL Linux
86
● automatically log on PERFSVM and starts the performance toolkit

● sets the signal shutdown interval to 45 seconds
===> x profile exec
/***************************/
/***************************/
'CP XAUTOLOG LINUX1'
'CP XAUTOLOG LINUX2'
'CP XAUTOLOG PERFSVM'
'CP SET SIGNAL SHUTDOWN 45'
'CP LOGOFF'
After the Linux user IDs are logged on, Linux will start because of the logic in their PROFILE
EXEC's that IPLs minidisk 100 when starting in a disconnected mode.
4. Save the changes and logoff of AUTOLOG1.
===> file
Log off AUTOLOG1
11.3 Setting Linux systems to halt at z/VM shutdown

z/VM has a facility to signal user IDs before it shuts down. The Linux kernel traps such a signals and
translates it into a CTRL-ALT-DEL key sequence. The file /etc/inittab is where the action to perform is
set when this signal is caught.
1. From either of your two Linux systems, use grep to see what happens when a virtual CTRL-
ALT-DEL sequence is trapped:
# cd /etc
# grep ctrl inittab
What is the action to be performed? _________________________________________
2. On LINUX1, modify the CTRL-ALT-DEL sequence to process shutdown instead of restart.
# vi /etc/inittab
Change the command for CTRL-ALT-DEL to _____________________________
3. Tell the system to pickup the new setting in the /etc/inittab file:
# init q
4. On LINUX2, modify the CTRL-ALT-DEL sequence to process shutdown instead of restart.
87
# vi /etc/inittab
Change the command for CTRL-ALT-DEL to _____________________________
5. Tell the system to pickup the new setting in the /etc/inittab file:
# init q
11.4 Set up z/VM shutdown signals

1. After you are finished with the changes
Return or Logon to MAINT
2. Query the SIGNAL SHUTDOWN value.
===> q signal shutdown
The default value of 0 means that no signal is sent to user Ids (sometimes called guests). Modify
it to allow 45 seconds for the guests to come down, then query again:
===> set signal shutdown 45
===> q signal shutdown
3. Query the signals value to display the signal status of all users who are enabled to receive
signals or are processing signals.
===> q signals
Signalled Timeout
Userid Signal Signal Status By Remaining
LINUX1 SHUTDOWN Enabled - -
LINUX2 SHUTDOWN Enabled - -
11.5 Shutdown a single Linux system

1. From MAINT, shutdown Linux1 with the SIGNAL SHUTDOWN command.
===> signal shutdown linux1
2. Then issue the QUERY SIGNALS command again and you should see that the LINUX1
shutdown is being processed
===> q signals
3. Go back to MAINT.. A short time later you should see the following messages indicating
LINUX virtual server has successfully shut down and the LINUX virtual machine has logged
off:
HCPSIG2113I User LINUX1 has reported successful termination
USER DSC LOGOFF AS LINUX1 USERS = 9 AFTER SIGNAL
88
This is an effective tool for shutting down individual Linux user IDs easily and cleanly.
11.6 Start up a single Linux system

To start Linux systems up, you can use the XAUTOLOG command from users such as MAINT that
have class A or B privileges.
A minute or so later, you should be able to SSH into LINUX1.
11.7 Shutdown z/VM

Now shutdown the system and observe what happens. Be sure to invoke the SHUTDOWN command
from a 3270 session to the first level z/VM, not one directly to your z/VM TCP/IP stack. You will be
able to restart z/VM from the former session, but you will lose communication with the latter,
naturally, as the TCPIP service machine is also shut down.
Before you shutdown z/VM, you may want to bring up an SSH session for LINUX2 to see that it is
shutdown cleanly before z/VM is shutdown.
===> SHUTDOWN
SYSTEM SHUTDOWN STARTED
HCPSHU960I System shutdown may be delayed for up to 75 seconds
You may or may not see the following messages for LINUX1 and LINUX2.
HCPSIG2113I User LINUX2 has reported successful termination
When the Linux images are completely down the system will start to shutdown even if the time hasn't
expired. When z/VM is shut down all the way, you should see the following line. Note the name of the
system in the lower right corner.
00: HCPGIR450W CP entered; disabled wait PSW 00020000 00000000 00000000
00000FFF
11.8 IPL z/VM

At this point your z/VM is completely shutdown. Return to the first level team virtual machine and re-
IPL manually.
1. Connect to first level z/VM (129.40.45.25)
Logon as TEAM<n>
2. IPL your z/VM system
89
===> ipl 200 cl

3. At the START prompt, reply:
===> cold drain
14:01:09 Start ((Warm|Force|COLD|CLEAN) (DRain) (DIsable) (NODIRect)
14:01:09 (NOAUTOlog)) or (SHUTDOWN)
4. You want to take the default of AUTOLOG in the third parameter so the AUTOLOG1's
PROFILE EXEC will run.
5. Accept the default of the TOD Clock setting.

Press Enter
6. To continue COLD start, enter:

===> 'go'
7. You should see some output from that PROFILE running at the end of the IPL messages:...
13:27:30 AUTO LOGON *** DTCVSW1 USERS = 7 BY AUTOLOG1
13:27:30 AUTO LOGON *** DTCVSW2 USERS = 8 BY AUTOLOG1
13:27:30 AUTO LOGON *** LINUX1 USERS = 9 BY AUTOLOG1
13:27:30 AUTO LOGON *** LINUX2 USERS = 10 BY AUTOLOG1
13:27:30 USER DSC LOGOFF AS AUTOLOG1 USERS = 9
13:27:30 0800-0802 ATTACHED TO TCPIP BY TCPIP
13:27:31 HCPSWU2830I VSWITCH SYSTEM VSW1 status is ready.
13:27:31 HCPSWU2830I DTCVSW2 is VSWITCH controller for device 0900.
8. When the system initialization completes, log off OPERATOR and log on to MAINT.
===> disconnect
Press Enter
Logon as MAINT
9. Check to see if your LINUX1 and LINUX2 are started

===> q names
SSH into LINUX1 as root
SSH into LINUX2 as root
Congratulations, you have configured z/VM to cleanly shutdown and IPL your Linux systems.
90
Unit 12: System z Device Drivers & Commands

12.1 Display kernel modules
1. Using LINUX1
Logon as root
2. Print a list of all kernel modules. This command returns a list of all available kernel modules.
# modprobe -l
3. Print a list of all kernel modules with names starting with "appl". You should see a list of
appldata modules which suppor the Linux monitor stream function.
# modprobe -l appl*
4. Print a list of all loaded kernel modules.
# lsmod
12.2 z/VM CP interface device driver (vmcp)

Using the z/VM CP interface device driver (vmcp), you can send control program (CP) commands to
the VM hypervisor and display VM’s response. The vmcp module is not loaded by default.
1. Load the vmcp module:
# modprobe vmcp
2. Display its status to make sure that the module is loaded correctly.
# lsmod | grep vmcp
3. The vmcp module is now loaded. Test it by using some z/VM CP commands:
# vmcp query dasd
# vmcp indicate user
12.3 z/VM Monitor stream - APPLDATA Support

There are no kernel or module parameters for the monitor stream support. This exercise describes how
to load those components of the support that have been compiled as separate modules and how to set up
your VM guest for the APPLDATA record support.
z/VM setup
1. To enable your Linux guest for data gathering ensure that the Linux guest directory includes the
91
option APPLMON.
2. If you are not logged on to MAINT already
Logon as MAINT
3. Edit the USER DIRECT file and add the APPLMON option to the LINDFLT profile as shown
below:
===> x user direct
PROFILE LINDFLT
IPL CMS
MACH ESA 4
CPU 00 BASE
CPU 01
option applmon
...
4. Put the updated directory online:
===> directxa user
5. Shutdown the Linux systems, LOGOFF and then LOGON again. This will enable the change
to the directory entry. Let's do this all from MAINT.
Shut down the linux systems:

When they report successful termination, reboot the systems.
Setup LINUX1
1. When the system comes up,
Login to LINUX1 as root
2. Load the data gathering modules:

# modprobe appldata_mem
# modprobe appldata_os
# modprobe appldata_net_sum
3. APPLDATA monitor records are produced if both a particular data gathering module and the
monitoring support in general are switched on. To switch on monitoring, use the echo command
92
to send a non-zero value into the monitoring variables in the /proc/ virtual file system:
# echo 1 > /proc/sys/appldata/timer
# echo 1 > /proc/sys/appldata/mem
# echo 1 > /proc/sys/appldata/os
# echo 1 > /proc/sys/appldata/net_sum
4. You can set the time that lapses between consecutive data samples. The time you set is
measured by the virtual CPU timer. Because the virtual timer slows down as the guest idles, the
time sampling interval in real time can be considerably longer than the value you set. The value
in /proc/sys/appldata/interval is the sample interval in milliseconds. The default sample interval
is 10000 ms.
To read the current value, issue:
# cat /proc/sys/appldata/interval
Setup LINUX2
If you wish, setup LINUX2 using the same procedures for LINUX1 above.
Test with the z/VM Performance Toolkit

Once the data collection is enabled in LINUX1, the data is available for the Performance Toolkit to
display via the Linux Systems (menu item #29) . Start the Performance toolkit web interface to verify
that your setup is correct:
http://129.40.35.<n>0:81
93
12.4 Cryptographic device driver

4.1.1 Enabling PCICA in z/VM and Linux
Give access to the z/VM Linux guest
To access the crypto coprocessors, Linux user IDs must be specifically permitted to use them via the
CRYPTO APVIRT directory control statement.
1. If you are not logged on to MAINT already
Logon as MAINT
2. Edit the USER DIRECT file and add the CRYPTO APVIRT option to the LINDFLT profile as
shown below:
===> x user direct
PROFILE LINDFLT
IPL CMS
MACH ESA 4
CPU 00 BASE
CPU 01
option applmon
crypto apvirt
...
3. Put the updated directory online:

===> directxa user
4. Shutdown the Linux system, LOGOFF and then LOGON again. This will enable the change
to the directory entry. Let's do this all from MAINT.
94
Shut down the linux systems:

When they report successful termination, reboot the systems.
Enable the z90crypt module

1. Return to the Linux virtual server.
Login to LINUX1 as root
2. Verify that you have access to the crypto card.
# modprobe vmcp
# vmcp q crypto
00: No CAM or DAC Crypto Facilities defined
00: AP 53 CEX2C Queue 04 shared
The second line indicates that a CEX2C card is available.

3. Insert the z90crypt module.
# modprobe z90crypt
View the information written to /proc.
# cat /proc/driver/z90crypt
z90crypt version: 1.3.3
Cryptographic domain: 4
Total device count: 1
PCICA count: 0
PCICC count: 0
PCIXCC MCL2 count: 0
PCIXCC MCL3 count: 0
CEX2C count: 1
CEX2A count: 0
You should have one CEX2C device with no open handles. This indicates that the device is
attached to your system but there is no activity on it yet.
4.1.2 Install the Crypto support RPMs

To test the performance of the crypto card, the openssl-ibmca RPM is needed. It can be installed with
the rpm -ivh command:
# mkdir /mnt/rhel5
# mount 129.40.35.3:/mnt/rhel5root /mnt/rhel5
# cd /mnt/rhel5/Server
# rpm -ivh libica-1.3.7-5.el5.s390x.rpm openCryptoki-2.2.4-15.el5.s390x.rpm
95
openssl-ibmca-1.0.0.rc2-1.el5.3.s390x.rpm
12.4.2 Test performance of the crypto card

OpenSSL is a cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport
Layer Security (TLS v1) network protocols and related cryptography standards required by them. The
openssl program is a command line tool for using the various cryptography functions of OpenSSL's
crypto library from the shell.
1. Start from root's home directory to use speed command to test the performance of cryptographic
algorithms using the native library.
# cd
# openssl speed rsa1024 > software.out 2>&1
2. Next, use speed command again to test the performance of the same cryptographic algorithm
using the PCICA device.
# openssl speed rsa1024 -engine ibmca > hardware.out 2>&1
3. Compare speeds using software and hardware encryption
# tail -2 software.out
# tail -2 hardware.out
Your should see a drastic increase in performance. This is hardware crypto acceleration at
work.
4. Check the PCICA device status.
# cat /proc/driver/z90crypt
You should see that the completed request count is incremented, indicated that it was used by
our previous test.
12.4.3 PCICA exploitation with Apache and SSL

The availability of standard crypto libraries provides the plug points necessary to enable applications,
such as Apache, Java, IHS and Tivoli’s Access Manager to take advantage of the powerful
cryptographic acceleration provided on System z.
96
This exercise steps you through the steps necessary to enable Apache to use openSSL and the PCICA
device.
4.3.1 Turn off SELinux control of Apache

SELinux policy is customizable based on least access required. So by default SElinux prevents certain
apache scripts from working. Apache policy is extremely flexible and has several booleans that allow
you to manipulate the policy. The boolean that controls the protection of the apache server is
“httpd_disable_trans”. Issue the getsebool command to see the current value:
# getsebool httpd_disable_trans
This boolean is set to “off” (protection is active). Let's disable SELinux's protection of Apache by
setting this boolean to “on”.
# setsebool -P httpd_disable_trans 1
# getsebool httpd_disable_trans
The next step is to add the RPMs needed for Apache, but before hat can be done, yum must be
configured.
4.3.2 Configure yum

To configure yum, the following steps are recommended:
● Mount the RHEL 5 install tree
● Create a yum configuration file
● Import the RPM GPG key
1. To mount the install tree, create a mount point then mount the NFS-exported RHEL 5 install
97
tree that your system was installed from: (This has been done in the previous section.)
# mount 129.40.35.3:/mnt/rhel5root /mnt/rhel5
# cd /mnt/rhel5/Server
2. Create a yum configuration file pointing to the new mount directory:
# cd /etc/yum.repos.d/
# vi rhel5.repo
[RHEL5]
name=Red Hat Enterprise Linux 5
baseurl=file:///mnt/rhel5/Server
gpgcheck=0
3. To import the RPM GPG key, use the rpm –import command:
# rpm --import /mnt/rhel5/RPM-GPG-KEY-redhat-release
Segmentation fault
:((
TODO: figure the error here or open a bugzilla – workaround is to add
“gpgcheck=0” to rhel5.repo
4.3.3 Install the software components

To run the Apache Web server with the crypto card, it is recommended that the following RPMs are
added:
● Apache - httpd
● Apache documentation - httpd-manual
● openCryptoki - openCryptoki (installed earlier)
● Secure server support - mod_ssl
Additional RPMs will be needed for dependencies, so yum is used with the -y install flags:
# yum -y install httpd httpd-manual openCryptoki mod_ssl
Make sure your apache web server is operational before proceeding to the next step:
# service httpd start
Start a web browser and access the Web server for the http protocol:
http://129.40.35.<n>1
You should see the Red Hat Enterprise Linux Test Page.
4.3.4 Create a digital certificate

Next, create a test digital certificate for the web server. This is a two-step process which includes the
creation of a private key and a self-signed certificate.
Create a private key with the triple DES encryption standard. You will be prompted to enter and re-
98
enter a pass phrase. Using this encryption standard, you will be prompted for the pass phrase every
time you start the Apache server with SSL.
# cd /etc/httpd/conf/
# openssl genrsa -des3 -out test.key 1024
Generating RSA private key, 1024 bit long modulus
...............++++++
.....................................++++++
e is 65537 (0x10001)
Enter pass phrase for test.key: redhat
Verifying - Enter pass phrase for test.key: redhat
Create a self-signed certificate. You need to provide the private key generated from the previous step
and enter the pass phrase when prompted. You will also be asked to enter information about the server.
When prompted to enter the 'Common Name', enter your Linux server's IP address. All the other fields
are optional.
# openssl req -new -key test.key -x509 -out test.crt
Enter pass phrase for test.key: redhat
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: US
State or Province Name (full name) [Some-State]: NY
Locality Name (eg, city) : POK
Organization Name (eg, company) [Internet Widgits Pty Ltd]: IBM
Organizational Unit Name (eg, section) : Linux
Common Name (eg, YOUR name) : 129.40.35.<n>1
Email Address : root@zvm<n>lin1.pbm.ihost.com
You should now be able to get to the

https://129.40.35.<n>1
4.3.5 Configure and restart the Apache server

In Redhat, Apache is configured with SSL enabled. SSL specific configuration data can be found in
/etc/httpd/conf.d/ssl.conf. Update this file to with the following:
# cd /etc/httpd/conf.d
# cp ssl.conf ssl.conf.orig
# vi ssl.conf
99
1. Around line 67, modify the SSLCryptoDevice directive to enable the crypto card.
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names. NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice ibmca
2. Around line 107, modify these directives to point to the file names of the key and certificate you just
created in the previous step.
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/httpd/conf/test.crt
...
...
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/httpd/conf/test.key
3. Save your changes and restart the Web server. Enter the pass phrase for the private key when
prompted.
# service httpd restart
4.3.6 Give it a try

Start a web browser and enter the following URL:
https://129.40.35.<n>1
Since you are using a self signed certificate, a security alert window will pop up telling you that the
certificate did not come from a known (trusted) authority.
View the certificate and verify it is the one you created.
Click on 'Examine certificate'
Accept the certificate and proceed with the https request. You should see the home page for the
Apache server. Now how can you verify that the Crypto device is being used?
# ________________________________________________________
Stop the Apache server before moving on to the next exercise
100
# service httpd stop
101
Unit 13: DCSS

13.1 z/VM DCSS and Execute-in-Place Technology
13.1.1 Creating a DCSS

1. Determine the maximum size of the DCSS.
● Determine the beginning memory address of the DCSS address range. The address range
must not overlap with the virtual storage of the guest operating system. Therefore the
beginning memory address of the DCSS is equal to the highest amount of virtual storage
that has been allocated to any of your images.
● Determine the upper boundary of the DCSS address range. The upper boundary is 1960
MB for 31-bit Linux kernels and 2 GB for 64-bit Linux kernels.
● Subtract the lower beginning memory address from the upper boundary to obtain the
maximum possible DCSS size.
● Note: For our class, all our Linux guests have been defined with 512 MB of memory.
We are running 64-bit code so the upper boundary is 2 GB. The maximum possible size
of our DCSS is:
2 GB - 512 MB = 1536 MB
2. Identify the directories to be shared.
Remember previously we said that good candidates are those which are read-only
files/directories that are at the same level (version) in all Linux instances and that are
applications and libraries that are frequently used by most of the images.
For our class we will share the following directories:
/bin
3. Calculate the space requirements for sharing the directories above.

You can issue the following command to find the space requirements for the directories chosen:
# du -smc /bin <====== size in megabytes for directory
9 /bin
9 total
# find /bin | wc -l <====== number of files in directory

101
The space used by the directories adds up to 9 MB. You should add 4kb per shared file as
filesystem overhead and about 10% on top of that for updates and contingencies which results
in
102
9216k + (101 x 4k) = 9620 KB + 962k = 10582 KB or 10.5 MB. I like rounding up to the magic
numbers (4,8,16,32,64...), so this would be 16 MB. This number is well below the maximum
size of 1536 MB which means we are within our boundaries.
Now let’s establish the start and end address for the DCSS. This addresses must be on a page
boundary (4 KB on the mainframe) and in hexadecimal notation. (note: do not enter the
spaces between the hex numbers, they are there only for readability.)
Start address: 512 MB => 0x20 00 00 00
End address: 512 MB + 16 MB - 1 B => 0x20 ff ff ff
We must calculate the page frame number for the start and end address. You can do this by
dividing the above numbers by 4096 (4K pages). In hexadecimal notation 4096 = 1000, so
dividing the above numbers by 1000 can be accomplished by dropping the last three digits.
Start address: 0x20000000 = page frame number 0x20000
End address: 0x20ffffff = page frame number 0x20fff
103
13.1.2 Change Linux addressable memory range to use the

DCSS
Before your Linux kernel can use the DCSS, it must be aware of the extended address space that covers
the DCSS.
Perform the following steps to set the mem kernel parameter accordingly:
1. Start up your Linux system.
Login as root
2. Add a mem=<value> parameter to your kernel parameter line (parmfile). The value must cover
the entire DCSS, that is, must be equal to or above the DCSS end address. The value can be in
either of these forms: in byte, in the form <x>k, in the form <y>M. For our exercise we will use
1024M:
# vi /etc/zipl.conf
[defaultboot]
default=linux
target=/boot/
[linux]
image=/boot/vmlinuz-2.6.18-8.el5
ramdisk=/boot/initrd-2.6.18-8.el5.img
parameters="root=LABEL=/ mem=1024M"
3. Run zipl with the new parameter file.

# zipl
4. Resboot Linux.
# reboot
5. Issue the following command to verify that Linux is using the new parameter:
# cat /proc/cmdline
root=LABEL=/ mem=1024M BOOT_IMAGE=0
104
1.2.1 Creating a file system image for the DCSS

A DCSS holds shared Linux code in form of a Linux file system. We will now create the place holder
under z/VM.
1. Logon to maint userid on you z/VM and increase the memory to 1000M
===> define store 1000M
2. Enter the following command to define and save the DCSS
===> defseg linux1 20000-20fff sr
===> saveseg linux1
3. Logon to Linux1, activate the DCSS LINUX1 and make a file system to hold your files.
# modprobe dcssblk segments="LINUX1" <=== activate the LINUX1 DCSS
# echo 0 > /sys/devices/dcssblk/LINUX1/shared <=== don't share it (local)
# mke2fs -b 4096 /dev/dcssblk0 <=== make an ext2 filesystem
4. Create a mount point for the filesystem and mount the file system
# mkdir /xipimage
# mount /dev/dcssblk0 /xipimage -o xip
5. Copy all directories to be shared to the DCSS and save it.
# cp -a /bin /xipimage/bin
# echo 1 > /sys/devices/dcssblk/LINUX1/save
6. Unmount the file system.

# umount /xipimage/
1.2.2 Testing the DCSS

Perform the following steps to test the DCSS:
1. Mount the xip file system.
# mount -o ro,xip /dev/dcssblk0 /xipimage
2. Make sure that all files are accessible
# cd /xipimage
# ls -l
drwxr-xr-x 7 root root 4096 Dec 13 15:58 ./
drwxr-xr-x 21 root root 4096 Dec 14 11:33 ../
drwxr-xr-x 2 root root 4096 Dec 13 14:45 bin/
105
13.1.3 Activating the execute-in-place file system at boot time

Before you can activate the execute-in-place file system you have to over-mount the shared directories
on startup.
We have provided a sample script that can be used to over-mount directories with the content of a
DCSS before Linux accesses them. The script is a copy of the one shown in the document LNUX-
H6DS-00, and it can be found in /mnt/labstuff/misc . The script has been tailored for our environment
but it contains instructions to tailor to your environment. This script only supports over-mounting
directories on the root file system ( / ). We recommend that you get a copy of the original document
(LNUX-H6DS-00) and read it in its entirety.
In this context, over-mounting a directory means replacing it with the contents of the DCSS at system
startup. Shared directories must be over-mounted before any data on them is accessed. If a directory is
accessed before being over-mounted, accessed libraries and binaries might remain in memory, and so
waste memory, after the corresponding directory is over-mounted.
Directories that are on the root file system need to be over-mounted before running the first program on
system startup: /sbin/init.
On system startup, xipinit runs instead of /sbin/init. First xipinit over-mounts the shared directories and
then it runs /sbin/init.
1. Copy the xipinit script into the /sbin directory.
# cp /mnt/labstuff/misc/xipinit /sbin/xipinit
2. Test the xipinit script by executing it and verifying that the directories are over-mounted
correctly. After
# xipinit
mount: /dev/dcssblk0 already mounted or /xipimage busy
mount: according to mtab, /dev/dcssblk0 is already mounted on /xipimage
binding directory /bin
Usage: init 0123456SsQqAaBbCcUu
# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
/dev /dev tmpfs rw 0 0
/proc /proc proc rw 0 0
/sys /sys sysfs rw 0 0
none /selinux selinuxfs rw 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
/etc/auto.misc /misc autofsrw,fd=6,pgrp=1335,timeout=300,minproto=5 ......
/dev/dcssblk0 /xipimage ext2 ro,xip 0 0
/dev/dcssblk0 /bin ext2 ro,xip 0 0
# testxip <==== should find it because the dcss is mounted over /bin
106
Hello from LINUX1 DCSS
3. Now that you know that the directories were mounted correctly, we need to change Linux so
that it happens at boot time.
Edit the init table file.

# vi /etc/inittab
Add the line dc::sysinit:/sbin/xipinit to the table as shown below.
id:3:initdefault:
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
dc::sysinit:/sbin/xipinit
l0:0:wait:/etc/rc.d/rc 0
...
4. Reboot Linux.
# reboot
5. Once the system is up, we want to check that everything was successful. Verify that the shared
directories are over-mounted.
# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
/dev /dev tmpfs rw 0 0
/proc /proc proc rw 0 0
/sys /sys sysfs rw 0 0
none /selinux selinuxfs rw 0 0
devpts /dev/pts devpts rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
/dev/dcssblk0 /xipimage ext2 ro,xip 0 0
/dev/dcssblk0 /bin ext2 ro,xip 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
/etc/auto.misc /misc autofs
rw,fd=6,pgrp=1329,timeout=300,minproto=5,maxproto=5 ...
6. Verify that z/VM is using the DCSS by issuing the “q nss map” z/VM command. The command
called “vmcp” allows you to enter CP commands and view the output. Check the #USERS
column; it should be equal to the number of linux guest that your team successfully connected
to your own DCSS.
# modprobe vmcp
# vmcp q nss map
107
FILE FILENAME FILETYPE MINSIZE BEGPAG ENDPAG TYPE CL #USERS PARMREGS

VMGROUP
0026 SCEEX DCSS N/A 02100 027FF SR A 00000 N/A N/A
0034 CMS NSS 0000256K 00000 0000D EW A 00008 00-15 NO
00020 00023 EW
00F00 013FF SR
0025 SCEE DCSS N/A 00900 009FF SR A 00000 N/A N/A
0023 GCS NSS 0000256K 00000 0000C EW R 00000 OMITTED YES
00400 0044E SR
0044F 0044F SW
00450 005FF SN
01000 0101A SR
0101B 011FF SN
0021 NLSGER DCSS N/A 02000 020FF SR A 00000 N/A N/A
0020 NLSKANJI DCSS N/A 02000 020FF SR A 00000 N/A N/A
0019 NLSUCENG DCSS N/A 02000 020FF SR A 00000 N/A N/A
0018 NLSAMENG DCSS N/A 02000 020FF SR A 00004 N/A N/A
...
...
0034 LINUX1 DCSS N/A 20000 20FFF SR A 00001 N/A N/A
13.1.4 Create a DCSS for swapping

A new addition to the dcssblk device driver was the support for mixed EW/EN segments. Why use a
DCSS for swapping? It provides a fast write into z/VMs storage and swap caching when guest is memory
constrained but z/VM is not. It allows to shrink guest virtual memory size while maintaining acceptable performance for
peak workloads (move overcommitment to guest level). It can be much faster than vdisk and no hypervisor calls are
required.
To use a DCSS for swapping you must be at least on SLES9 SP2 or RHEL5. You will also need a lot of paging space
assigned to z/VM. Here is a step by step implementation for defining a DCSS segment of 115M for swapping. Must of the
explanations to this steps are found in the previous excercise. For your information, look up in z/vm for help on the defseg
command and find out what does type EW and EN means.
EW = _________________________________ EN=________________________________
1. Login to MAINT and define the segment starting at 512M + 16M (the size of the previous
DCSS).
===> defseg swapping 21000-21000 ew 21001-283ff en
2. Save the segment.
===> saveseg swapping
3. Logon to your linux guest and enter the following commands
Dynamically adds the segment:
# echo "SWAPPING" > /sys/devices/dcssblk/add
Make a swap file:
108
# mkswap /dev/dcssblk1
Setting up swapspace version 1, size = 121630 kB
Save the signature of the swap file

# echo 1 > /sys/devices/dcssblk/SWAPPING/save
Turn on swapping:
# swapon /dev/dcssblk1
Make sure the swap file is now being used:
# cat /proc/swaps
Filename Type Size Used
Priority/dev/dcssblk1 partition 118776 0 -1
Check the memory usage in megabytes:

# free -m
total used free shared buffers cached
Mem: 491 218 273 0 8 141
-/+ buffers/cache: 68 422
Swap: 115 0 115
13.1.5 Activating DCSS for swapping at boot time

Now that we have everything working lets make it work at boot time. The strategy will be the same as
the previous excercise. Here we have 2 choices we can either add a new entry in /etc/inittab or we
can change /sbin/xipinit to take care of the swap environment. For simplicity, we will change
/sbin/xipinit. The xipinit script that you previously copy, already has the changes needed for activating
the swap environment but they are commented out. You will need to uncomment a couple of lines
and delete one line. Here are the changes needed:
#!/bin/sh
# /sbin/xipinit: use read only files from another file system
##########################################################################
######### Change RODIRS to add the directories you are sharing. ########
######### Make sure you end RODIRS in a comma. ########
######### Change ROMOUNT to the mount point of your choice. ########
######### Change DCSSNAME for the name of your DCSS. ########
##########################################################################
RODIRS=/bin,
ROMOUNT=/xipimage
# DCSSNAME="LINUX1,SWAPPING(local)" <=== UNCOMMENT by removing “#”
DCSSNAME="LINUX1" <=== DELETE THIS LINE
########
modprobe dcssblk segments="$DCSSNAME"
mount -o xip /dev/dcssblk0 $ROMOUNT
# bind mount all ro dirs into rw filesystem
109
while [ -n "$RODIRS" ] ; do
dir="${RODIRS%%,*}"
RODIRS="${RODIRS#*,}"
test -d "$dir" || continue
echo "binding directory" $dir
mount --bind "$ROMOUNT/$dir" "$dir"
done
# turn swap on <=== UNCOMMENT by removing “#”
# swapon /dev/dcssblk1 <=== UNCOMMENT by removing “#”
110
Unit 14: References

14.1 XEDIT Cheat Sheet
THE BASIC XEDIT COMMANDS
Anytime you wish to edit an existing file, you can:
• enter XEDIT filename filetype, or
• enter the command FILELIST (which will display a list of files stored on your A disk), position the
cursor over the file you wish to edit, and press F11.
TO ADD, DELETE, COPY, OR MOVE LINES OF TEXT

The lines to the left of the text are the prefix lines. You can turn these on and off. If you don't see a
string of numbers or equal marks on the left side of the screen, type
SET PREFIX ON <enter>
then
SET NUM ON <enter>
When you are using the XEDIT editor, to add a line, type A on the line '00000' and <enter>:
0A000 * * * Top of File * * *
00001 * * * End of File * * *
This will add one line:
00000 * * * Top of File * * *
00001
00002 * * * End of File * * *
To add multiple lines, type the number of lines you want to add. For example, type A5 <enter> to add 5
lines. Type the command right on the '00000' -- type right over the numbers.
00000 * * * Top of File * * *
0a501
00002 * * * End of File * * *
This will add 5 lines after line 00001:
00000 * * * Top of File * * *
00001
00002
00003
00004
00005
00006
00007 * * * End of File * * *
111
To delete a line, position the cursor in the prefix area (over the numbers) of the line you want to delete
and type a 'd' and <enter>. To delete multiple lines, you type 'dd' on the first and last lines inclusive,
and <enter>.
00000 * * * Top of File * * *
00001
0dd02
00003
00004
00005
00dd6
00007 * * * End of File * * *
The pairs of 'd's show which lines will be deleted; in this case, lines 2-6 will be deleted:
00000 * * * Top of File * * *
00001
00002 * * * End of File * * *
The XEDIT program will renumber the remaining lines.
A useful command to remember when editing is RECOVER . When entered at the command line it
allows you to recover the last set of deleted lines.
Just as with any electronic medium, it is a good idea to SAVE your text on a regular basis. From the
command line, simply type SAVE <enter>. The file will be saved with the same name unless you
specify a different fileid (that is, filename and/or filetype) by entering
SAVE filename filetype
where you specify an alternate filename and/or filetype from the original. You can also copy a line or
lines by typing 'c' (for a single line) or 'cc' (for blocks of text on adjacent lines) and then put an 'f'
preceding where you would like the lines copied, and "enter"ing.
00000 * * * Top of File * * *
00001 Hear the sledges with the bells--
00002 Silver bells!
00003 What a world of merriment their melody foretells!
00004 How they tinkle, tinkle, tinkle,
00005 In the icy air of night!
00006 While the stars that oversprinkle
00007 All the heavens seem to twinkle
00008 With a crystalline delight;
00007 * * * End of File * * *
After you put the pairs of 'cc's on the lines you want to copy, and you have put an 'f' at the line after
which you would like the text inserted, the move operation will be performed when you press the
<enter> key:
00000 * * * Top of File * * *
00002 Silver bells!
112
00004 How they tinkle, tinkle, tinkle

00005 In the icy air of night!
00006 While the stars that oversprinkle
00007 All the heavens seem to twinkle
00008 With a crystalline delight;
00010 Silver bells!
00012 * * * End of File * * *
The same goes for moving lines; use 'm' or 'mm' (for blocks of text on adjacent lines) and the lines will
be moved to the point after the 'f'. If you want to move or copy lines prior to a current line (rather than
following the current line), use 'p' to move/copy line(s) preceding this line.
FORMATTING YOUR SCREEN FOR YOUR XEDIT SESSION

NOTE: You can create a file called 'PROFILE XEDIT' that will automatically implement some of the
commands below. See Section 6.
SET SCALE OFF turns off the column 'ruler'
SET CASE MIXED allows you to enter text in mixed case
SET PREFIX OFF turns off prefix display
SET PREFIX ON turns on display of the prefix area: ======
SET NUM ON prefixes are set to numbered lines as 00001 rather than =====
SET NUM OFF prefixes are now =====
RESET Removes all prefix commands when screen is in "PENDING" status
INPUT allows input of data
SET SCR 2 allows xediting of 2 files simultaneously
SET SCR 1 resets to a single screen
TABS tells you the tab settings that the F4 key is set to
SET TABS num num allows you to set the tabs as you wish, insert numbers for the 'num'
Q PF to see what your PF keys are set to
SET PF 'n' command allows you to set a PF key to execute a command
113
SAVING AND QUITTING

SAVE saves the file you are editing
FILE saves the file you are editing, then exits to CMS
QUIT allows you to quit out of the XEDIT editor
QQUIT allows you to quit without saving any changes to the text
14.2 Vi Cheat Sheet

vi has 2 modes: command mode and insert mode. In command mode, everything you type is a
command. In insert mode what you type is written to the screen (file buffer). vi starts in command
mode.
To enter insert mode you can press:
i to start inserting at the current cursor position
I to start inserting at the beggining of the line
a to start append after the current cursor position
A to start appending at the end of line
o append a new line and start editing
O insert a new line and start editing
Press Esc to exit command mode.

To move around in command mode you can use the arrow keys.
Other useful movement commands
0 start of line
$ end of line
:nn goto line nn
G end of file
Editing commands: They can be preceded by a number of times to repeat the command, i.e. 4dd will
cut 4 lines.
dd cut line (delete)
yy copy line (yank)
114
dd cut line (delete)

p paste after cursor
P paste before cursor
File commands:
:w save file
:w filename save as 'filename'
:q quit
:q! quit without saving
:e file open a file
:r file insert (read) a file
14.3 Books
• Linux in a Nutshell
• Linux for S/390 - Redbook
• zSeries HiperSockets - Redbook
• zSeries Linux Application Development - Redpiece
• ZSeries Linux Systems Management - Redpiece
• Linux for S/390: Device Drivers and Installation Commands
• Linux on IBM eServer zSeries and S/390: VSWITCH and VLAN Features of z/VM 4.4
www.redbooks.ibm.com/redpapers/pdfs/redp3719.pdf
• Getting Started with zSeries Fibre Channel Protocol - Redpaper
• Linux on IBM zSeries and S/390: High Availability for z/VM and Linux - Redpaper
• Linux on IBM zSeries and S/390: Securing Linux for zSeries with a Central z/OS LDAP Server (RACF)
-Redpaper
• Porting UNIX Applications to Linux - Hints and Tips (
ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130115.pdf)
• Linux for S/390 and zSeries porting hints and tips (
ibm.com/servers/esdd/articles/linux_s390/index.html)
14.4 Web Sites

• www.ibm.com/vm
• www.vm.ibm.com/linux
115
• linux.com
• linux.s390.org
• oss.software.ibm.com/developerworks/opensource/linux390
116

System Z

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Z

Uploaded by

Copyright:

Available Formats

Virtualization and Linux on System z Workshop

Virtualization and Linux

Virtualization and z/VM

5.2 Create a profile ............................................................................................................................ 41

11.8 IPL z/VM.....................................................................................................................................89

Our Workshop Environment

Processor type and model: System z9

PBCVM52 - z/VM 5.2

I/O and Network

Main: 12 GB Memory Expanded: 6 GB

Team virtual machine

200 201 202 203

520RES 520W01 520W02 52PGSP

OSA devices: 800-802 900-902 A00-A02

Processors: 2 virtual CPUs

Unit 1: System z Virtualization

5. Clear the messages from your console.

===> terminal conmode 3270

to direct output is 0009.

12. Enter the rest of the IPL parameters as follows.

These messages provide some basic information about your system:

Unit 2: The Control Program (CP)

2.1.1 Central processing units (CPUs)

2.1.3 DASD and minidisks

2.1.4 Temporary minidisks

2.1.5 Virtual disks in storage

2.1.6 Virtual readers, punches, and printers

2.1.7 The virtual machine console

2.1.8 The User Directory

2.2 Logon to MAINT

USERID ===> maint

===> query commands

The MAINT virtual machine has access to 128 MB of virtual storage.

702, 703 Utility disks shared by all team Ids.

300, 301 Use to build linux virtual machines.

6. Display all the free Open System Adapter (OSA) devices.

PERM Permanent user's space.

===> q 190 19E

2.8.1 Use CPFMTXA to format Device 300

2.8.2 Use CPFMTXA to allocate cylinders

Start the CPFMTXA utility. Enter:

2.8.3 Use CPFMTXA to format Device 301

Unit 3: The Conversational Monitor System (CMS)

3.1.1 The Help System

3.1.2 Minidisks and the CMS access mode

3.1.3 CMS Files

3.1.4 The PROFILE EXEC

3.1.5 The CMS file editor XEDIT

===> copy profile exec a = execsave =

What do the “=” signs mean? ________________________________________________

The files are sorted by date and time, newest to oldest.

4. Return to Edit mode:

5. File your changes and exit the file.

8. Insert a new line:

Enter the text 'q time'

10. File your changes and exit the file.

Unit 4: System Configuration

4.2 System parameter disks

4.3 Update the SYSTEM CONFIG file

4.3.1 Edit the SYSTEM CONFIG file

Edit the SYSTEM CONFIG file:

===> x system config f

4.3.2 Update the CP-owned volume list