z/VM Module 2: Conversational Monitor System (CMS)

Objectives List z/VM’s base components and describe how they work together Describe CMS and the tasks it can accomplish State why CMS Pipelines are an important feature of z/VM Describe CMS Application Multitasking Describe the XEDIT environment and its purpose

Objectives continued Describe the three important application environments that CMS supports: Callable Service Library (CSL) OpenExtensions Reusable Server Kernel Show how to find and use the Help Facility Explain Shared File System (SFS) setup and configuration Explain how syntax diagrams are used List and describe the most important and useful CMS commands

Introducing z/VM’s Base Components Conversational Monitor System (CMS) An end-user interface for running user programs A single user interactive environment Control Program (CP) A component that manages the resources of a single system to make it appear that multiple computing systems exist REXX/VM A programming language that allows you to write customized application programs and command procedures Group Control System (GCS) A virtual machine supervisor that provides multitasking services When we speak of z/VM’s base components, we are referring to the different types of environments that z/VM supports. This slide and the next are here to give you a feel of the types of environments z/VM is capable of using and will help you understand topics and terms that are presented in the next few modules. The Conversational Monitor System provides a high-capacity environment that supports large numbers of interactive users. The Conversional Monitor System (CMS) is a component of z/VM. “Interactive” means supporting two-way communication between a user and the CMS environment. Although CMS could be called an operating system in itself, CMS performs two roles within z/VM. First, as an end-user interface, it is part of z/VM that is most often seen by users. Second, it is the part of the operating system that supports the running of your programs, thus, it is your interface to application programming languages and facilities. The Control Program (CP) is primarily a real-machine resource manager. The CP provides each user with an individual working environment known as a virtual machine. Each virtual machine is a functional equivalent of a real system, sharing the real processor function, storage, console, and input/output (I/O) device resources. CP is the component that manages the resources of a single computer so that multiple computing systems appear to exist. REXX/VM includes the REXX/VM Interpreter, which processes the English-like Restructured EXtended eXecutor (REXX) programming language. Using REXX, you can write customized application programs and command procedures. This procedural language allows programs and algorithms to be written in a clear and structured way. REXX programming has the capability of issuing both commands and conventional inter-language calls to its host environment. The Group Control System is a virtual machine supervisor, providing multitasking services that allow numerous tasks to remain active in the virtual machine at one time. A virtual machine supervisor bands many virtual machines together in a group and supervises their operations. GCS runs in a real XA machine and is installed with z/VM. This allows all virtual machines in a GCS group to run in XA or XC mode. GCS can not be built or run in a 370-mode virtual machine. XA mode means running with the full capabilities of the Extended System Architecture (ESA). Either 24-bit or 31- bit addressing can be used, as well as the more efficient XA I/O using the Channel Subsystem. ESA/XC virtual machine architecture is available only when VM/ESA is running on an ESA/390 processor. ESA/XC architecture lets virtual machines share multiple data spaces or address spaces, where an XC virtual machine can access one or more data spaces of another virtual machine if authorized to do so. 370 mode is a simulation of the 370 architecture under the Extended System Architecture machine. For migration purposes GCS supports mixed mode groups that include XC and XA mode (but not 370 mode).

What is CMS? Conversational Monitor System is an operating system environment itself Over time CMS became a part of VM CMS is a single user operating system, which makes it possible to: Create and maintain files Write and execute application programs CMS communicates with users through the console Unlike Windows 2000, where you can set up multiple users for a single operating system, such as Admin, User1 and Home, CMS is a single user operating system. This makes it possible for users to create and update files and to write and execute application programs. An important aspect of the CMS is that it is the operator or communicator of your z/VM environment. It executes commands given by users and displays information from the z/VM environment to the user console. The console can be considered two separate entities. When you run an operating system in a virtual machine, you are the virtual machine operator. You operate the virtual machine and the operating system in your virtual machine. Your virtual machine operator’s console is the display device at which you log on to z/VM. (Your virtual machine operator’s console can also be referred to as a virtual console, an operator’s console, or just a console. All of these terms refer to the display device at which you log on to z/VM.) By entering commands from your virtual machine operator’s console, you can communicate with CP and with the operating system executing in your virtual machine. To communicate with CP, enter CP commands. To communicate with the operating system running in your virtual machine, enter the commands of that operating system (for z/VM, that would be CMS commands). As a side note, many installations have two consoles for the virtual machine operator: a virtual machine console to communicate with CP, and a system console to communicate with the operating system running in the virtual machine (CMS). Your virtual machine operator’s console refers to the console you use to communicate with CP.

CMS Tasks With CMS, you can: Write, test, and debug application programs for use on CMS or guest systems Run application programs developed on CMS or guest systems Create and edit data files Process jobs in batch mode Share data between CMS and guest systems Communicate with other system users These are the important operations and tasks that CMS is able to execute. CMS writes, tests, and debugs application programs for use on CMS or a guest system. CMS runs application programs developed on CMS or guest systems, creates and edits data files, processes jobs in batch mode, shares data between CMS and guest systems, and communicates with other systems users. In batch mode, all data must be supplied beforehand and cannot be interacted with while the program is executing. Running applications in batch mode is very reliable and efficient. All data is saved in a file, so data cannot accidentally be deleted or lost. Batch mode is efficient because it waits to accumulate a sufficient amount of data to utilize the system processors, I/O devices, and other networking devices. Therefore, batch mode is an important way of running and completing CMS tasks.

Structure of CMS CMS consists of three areas: the terminal system, the CMS system services, and the file system. Each area has a number of commands and programming interfaces that invoke CMS functions. The CMS terminal system provides communication between users and the system. It reads commands entered at the keyboard and displays system responses to those commands. The CMS file system provide three methods for storing files. You can store files on virtual disks (called minidisks), Shared File System (SFS) directories, or in Byte File System (BFS) directories. SFS and BFS directories reside in CMS file pools. Each file system provides basic input and output functions, such as read and write operations. These I/O functions are used by the CMS system services and by applications running in a CMS virtual machine. The CMS system provides the basic user interface. These services consists of library services (such as the CSE), CMS pipelines, multitasking facilities, OpenExtensions Services, Reusable Server Kernel, XEDIT, the batch facility, utility commands, REXX, EXEC2, CMS EXEC, and REXX Sockets. Library Services include the Callable Services Library. All these facilities will be described more fully in later sections.

Callable Services Library (CSL) This diagram depicts the moment when the callable services library would be invoked. When there is a function call to the CSL, the program halts until that service call is complete. CMS gives control to the CSL routine at runtime. The CSL has routines to conduct tasks involving files and directories, virtual machine settings, calls to REXX execs, VM data spaces, data compression, and event management. The CSL routines can be invoked as REXX functions through a REXX subcommand environment. Any programming language that directly or indirectly communicates with the operating system through an operating system CALL interface is supported by the CSL, including COBOL, FORTRAN, Pascal, PL/I, C, and Assembler. In the case of C, the CSL routines are called by the C runtime routines to provide the functions, but are also available to other applications.

CMS Pipelines Provide a rich and efficient set of functions that can be used to solve large problems by breaking them up into smaller programs Smaller programs are called stages Stages: Read data Filter and refine data Combine multiple data items “Unix/Linux like” CMS Pipelines provides a rich and efficient set of functions that are used to solve large problems by breaking them up into smaller, less complex programs. These smaller programs are called stages. Many stages are included with CMS Pipelines. Some stages read data from system sources, such as disk files, tape files, or the result of VM commands. Other stages filter and refine that data in some way. Users can combine many stages within a single pipeline to create the results they need. If a function is not available through CMS Pipelines, users can write their own stage to get it. Here is an example of a simple PIPE command. It counts the number of words in your ALL NOTEBOOK file and writes the result to your terminal. A word is anything surrounded by blanks:  pipe < all notebook | count words | console Three stages are combined to do the work. The < (read file) stage reads the file, the count stage counts the words, and the console stage displays the count at your terminal. Anyone familiar with CMS commands can use CMS Pipelines. You do not need to be a programmer. If you can describe what you want to do, chances are that you can use CMS Pipelines to do it.

CMS Pipelines The significant difference between CMS Pipelines and other z/VM facilities is that CMS pipelines lets you combine programs so that the output of one program serves as the input to the next. CMS Pipelines also includes many programs, referred to as built-in stages, that are ready for you to combine in pipelines. CMS pipelines are like the pipelines used in plumbing. Instead of water flowing through pipes, however, data flows through programs. Data enters the pipe from a device (such as a terminal or a disk), flows through the pipeline, and exits to another device. (See Figure 1) Programs, like pieces of pipe, can be fitted together to solve complex problems. Each program, or stage, in the pipeline changes the data that flows through it. As data flows through the stages it is transformed, step-by-step, into the results you need. The data flows from left to right. (See Figure 2 in the slide.) In a pipeline, the output of one stage is the input to the next. The data itself is in the form of discrete records; that is, it is records that flow through the pipeline, not a continuous stream of bytes. A record is simply a string of characters—perhaps a line of a CMS file or a line entered at the terminal. Imagine a stage as a small factory through which a conveyor moves records. Records enter the stage on the left, and leave on the right. Figure 3 shows input records before processing on the left. The stage reads the records and processes them. The resulting output records, written by the stage, are shown on the right. Figure 4 shows a chop stage. chop truncates records at a specified length. In the example, each record is truncated to a length of 5 characters. Like many stages, chop writes one output record for every input record.

pipe < profile exec | count lines | console Pipeline Example pipe < profile exec | count lines | console This command executes the number of lines contained within your PROFILE EXEC file. In a pipeline, stages are separated by a character called a stage separator:  pipe stage_1 | stage_2 | ... | stage_n Do not place stage separators after the last stage. There is no limit (other than available space on the command line) to the number of stages you can specify. For your first pipeline, try this PIPE command:  pipe < profile exec | count lines | console If you do not have a PROFILE EXEC, substitute the name of any existing file. Be careful to leave a space after <. The number of lines in your PROFILE EXEC is displayed. If you make a mistake typing the command, an error message is displayed. Just type the command again, correcting the mistake. Figure 9 shows a map of the above pipeline. The example contains three stages. Each stage consists of a stage plus operands: < profile exec – The < (read file) stage reads a file and writes all of the file records to its output stream. As used here, the < stage reads your PROFILE EXEC and writes each record to its output stream. count lines – The count stage counts items on the records it reads from its input stream. count has operands that let you tell it what to count (such as bytes, words, or the records themselves). As used here, the LINES operand causes count to tally the count of the input records. The records that count reads are the records written by the < stage. (That is, the output of < becomes the input to count.) So, count tallies the count of records in your PROFILE EXEC. Then count writes a single record containing the tally to its output stream. count writes only one record—it does not write the records from the PROFILE EXEC to its output stream. Console – The console stage either reads from your console or writes to it, depending on its position in the pipeline. As used here, the COUNT stage reads records from its input stream and displays them on the console. Only one record is in its input stream. That record, written by count, contains the count of the lines in your PROFILE EXEC. Notice that both < and console work with devices. In the example, < reads a disk file and console writes to the console. Stages that convey data between the pipeline and the outside world are called device drivers. One advantage of CMS Pipelines is that you can use a different device by changing only one stage. To change the above example to write the count to a file instead of the console, just substitute a > stage for console. Here's how:  pipe < profile exec | count lines | > yourfile data a The > (write file) stage writes all records in its input stream to a file. Specify the file name as an operand. Remember to leave a space after the > symbol. The > stage creates a new file or replaces an existing file named YOURFILE DATA A. A file mode must be specified, as shown in this example.

CMS Application Multitasking An application can be divided into multiple units of execution, called threads. Threads have the ability to run on multiple CPUs at the same time Multitasking facilities allow applications to harness the power of the underlying multiprocessor complex to achieve high performance. CMS application multitasking services provide an execution environment for high-performance applications and servers. With CMS multitasking, an application can be divided into multiple units of execution and allow these multiple units, called threads, to run on multiple CPUs simultaneously. The multitasking facilities are available only at the application programming level. These multitasking facilities allow applications to harness the power of the underlying multiprocessor complex and to overlap operations to better-utilize processors and I/O devices and achieve high performance.

OpenExtensions OpenExtensions provides open systems support in two ways: OpenExtensions Services OpenExtensions Shell and Utilities OpenExtensions Services include: POSIX.1—System Interfaces POSIX.1a—Extensions to POSIX.1 POSIX.1c—Threads POSIX programs should “port” to CMS. The term OpenExtensions refers to VM services that provide industry-standard open system interfaces for applications and users, such as the Institute of Electrical and Electronics Engineers (IEEE) Portable Operating System Interface for Computer Environments (POSIX). OpenExtensions provide two open system (defined below) components: OpenExtensions Services and OpenExtensions Shell and Utilities, which is included within CMS. OpenExtensions Services includes the VM implementation of three POSIX standards. The first is POSIX.1, System Interfaces. The second is the POSIX.1a, Extensions to POSIX.1. The third is POSIX.1c, Threads. The POSIX.1, POSIX.1a, and POSIX.1c interfaces are provided as C library routines in the C runtime library included with Language Environment. For programs written in other languages, a language-neutral version of the POSIX functions is provided as a set of CMS callable services library (CSL) routines. OpenExtensions Shell and Utilities provides application development tools and an interactive environment in support of the POSIX application environment. This open system support facility also provides a large set of utilities that aid in program development and in porting applications from other open systems. It also provides a UNIX-like interactive user environment. Users of the shell environment have access to both the shell command set (built-in commands and utilities) and the full CP and CMS command set, as well as both OpenExtensions and non-OpenExtensions applications. A shell is the part of an operating system that communicates with the user and allows communication between commands. Therefore you are able to invoke the OpenExtensions through the shell. Open systems: Computer systems that provide either interoperability, portability, or freedom from proprietary standards, depending on your perspective. For years the term was applied loosely to the many flavors of UNIX. Since the emergence of The Open Group’s Single Unix Specification, any operating system that supports the UNIX APIs (z/OS, for example) can reasonably be classified as an open system.

OpenExtensions – Invocation Invocation from REXX Procedures example OPENVM is a z/VM subcommand environment OPENVM makes invocation of callable services look like other requests for host functions The OPENVM language binding file defines REXX variables used by the OpenExtensions services. You include the file using the APILOAD function. Invocation from REXX Procedures: Callers from REXX must use the REXX mechanism for calling routines from a Callable Services Library (CSL). A subcommand environment called OPENVM is provided to make invocation of these callable services look like other requests for host functions. After addressing the OPENVM subcommand environment, the services are invoked by specifying the routine name followed by the parameters. In addition, the OPENVM language binding file that defines REXX variables used by the OpenExtensions services should be included by using the APILOAD function. The APILOAD loads the directory needed to open and use the REXX/VM OPENVM function. An example of a REXX invocation of one of the callable services follows: call apiload 'VMREXOVM' /*Change the working directory */ pathname = '/home/myfiles' plength = length(pathname) address OPENVM 'BPX1CHD plength pathname return_value, return_code reason_code'

Reusable Server Kernel...........”reentrant” Enables vendors and application programmers to write multithreaded server programs The server kernel is the starting point for a server program To construct a server program you need: A text library of routines A macro library of function prototypes Constant definitions These entities are supplied by the Reusable Server Kernel The Reusable Server Kernel (RSK) enables vendors and application programmers to write multithreaded server programs that exploit VM technologies. The reusable server kernel is an empty server program that server writers can use as a starting point for developing and executing server programs on CMS. This “empty” server, called the reusable server kernel, consists of a text library of routines and a macro library of function prototypes and constant definitions. An “empty” server program is a useful starting point for server construction. To construct an actual server program, the server author attaches application- specific code to a set of interfaces in the reusable server kernel. The result of such attachment is a server program that exploits the z/VM system's best technologies. The reusable server kernel provides help in more than just multithreading. Additional help is provided in the areas listed on the next slide.

Additional RSK Help Areas …..RSK = Reusable server kernel Connectivity DASD I/O Authorization Memory management Runtime environment Worker machines Configuration and operation These are additional Reusable Server Kernel help areas: Connectivity – A big part of server design and development is the selection and deployment of connectivity strategies for the server program. The reusable server kernel includes line drivers for both bulk data and operator-oriented protocols and unifies all of these line drivers under a single interface. Server writers develop no communication code when they use the reusable server kernel. DASD I/O – The RSK organizes the server’s DASD volumes into one or more storage groups. This set of storage groups can be brought online, brought offline, and changed in size. I/O to these storage groups is thread-synchronous, thread-blocking, and does not serialize on the base virtual processor. Authorization – The RSK provides callable entry points for managing the authorization of users to objects. These entry points implement a class-oriented paradigm in which the object, classes, and access types for each class are completely defined by the server writer. Memory management – The RSK provides callable storage allocation and release primitives designed for multithreaded servers and suitable for most situations. Runtime environment – The RSK provides an automatic storage management convention that improves the performance of the server by minimizing the number of storage management calls needed to manage automatic storage. Worker machines – The RSK provides a facility that lets the server author run server work in a pool of virtual machines. The server kernel takes care of auto-logging these worker machines and moving data between the central server and the workers. This is useful for offloading complex functions or for isolating risky or time-consuming operations. Configuration and operation - The RSK operation is configurable and controllable through a set of commands. These commands let the operator start and stop services, manipulate storage groups, and perform other tasks related to server management.

XEDIT.......skip this...its a WYSIWYG editor + macros XEDIT is a full-screen editing facility that runs under CMS. XEDIT creates and modifies CMS files and BFS (Byte File System) files. System macros and user-written procedures can be performed from the XEDIT environment. 1: File Identification Line The first line on the screen identifies the file you are editing. The following information is displayed: file name, file type, file mode or BFS path name. If you do not specify a file mode, the editor assigns a file mode of A1. The file mode identifies an accessed minidisk or SFS (Shared File System) directory where the file resides. Record format and record length: The record format and record length in this example, (V 132) mean that the length of a line can vary and the file can hold lines up to 132 characters long. Therefore, a file line can be longer than a screen line. Truncation column (Trunc=): Notice that the truncation column is the same as the record length (132). Because a file line can be only 132 characters long, any data you enter beyond 132 characters (in total) can be truncated. Current number of lines in the file (Size=): (Because data has not yet been entered in the file, the number of lines is zero.) File line number of the current line (Line=): (See number 5, following.) Position of the column pointer (Col=): (See number 6, following.) Alteration count (Alt=): The alteration count is the number of alterations that have been made to the file since the last AUTOSAVE (which is explained later in this chapter). 2: Message Line The editor communicates with you by displaying messages on the second and third lines of the screen. These messages tell you if you have made an error, or they provide information. In Figure 1 on page 4, the message line shows that you are creating a new file.

XEDIT continued 3: File Area This part of the screen is available to display the file. You can make changes to the file by moving the cursor under any line and typing over the characters, or by using special keys to insert or delete characters. You can make as many changes as you want on the displayed lines before pressing Enter. When you press Enter, the changes are made to the copy of the file that is kept in virtual storage. At the end of the editing session, a FILE subcommand permanently records those changes on the copy of the file that resides on disk or directory. Because a file can be too long to fit on one screen, various subcommands scroll the screen so you can move forward and backward in a file. Scrolling the screen is like turning the pages of a book. 4: Prefix Area The prefix area is the five left-most columns on the screen, and it displays five equal signs (=====). Each line in the file has a prefix area. You can perform various editing tasks, such as deleting a line, by entering short commands, called prefix subcommands, in the prefix area of a line. 5: The Current Line The current line is the file line in the middle of the screen (above the scale). It is highlighted, appearing brighter than the other file lines. In Figure 1 on page 4, the current line is the Top of File line; the file contains no data yet. The current line is an important concept, because most subcommands perform their functions starting with the current line. Naturally, the line that is current changes during an editing session as you scroll the screen, move up and down, and so forth. When the current line changes, the line pointer (not visible on the screen) has moved. Many XEDIT subcommands perform their functions starting with the current line and move the line pointer when they are finished.

XEDIT continued 6: Scale The scale appears under the current line to help you edit. It is like the margin scale on a typewriter. The vertical bar (|) in column one on the scale is the column pointer. Various subcommands perform their functions within a line starting at the column pointer, which you can move to different positions on the scale by using XEDIT subcommands that are discussed later. The current column is the column under which the column pointer is positioned. 7: Command Line The large arrow (====>) at the bottom of the screen points to the command input area. One way you communicate with the editor is to enter XEDIT subcommands on this line. You can type subcommands in uppercase or lowercase or a combination of both, and many can be abbreviated. For example, BOTTOM, Bottom, and b are all valid ways to type the BOTTOM subcommand. After typing a subcommand on the command line, press Enter to execute the subcommand. Figure 1 on page 4 shows the subcommand BOTTOM typed on the command line. (To move the cursor from any place on the screen to the command line, just press Enter or PF12.) 8: Status Area The lower right corner displays the current status of your editing session, for example, edit mode or input mode, and the number of files you are editing. The status area in Figure 1 on page 4 shows that one file is being edited.

The Batch Facility Can take over both short and long processing jobs for you Frees up your time to continue working at your terminal Two examples: Have the facility format text and send it to the printer, instead of doing it yourself Have large jobs run throughout the night to take advantage of lower computing costs or lighter loads The VM Batch Facility is a program that can take over processing jobs for you. Instead of doing a job at your terminal, you put the commands that have to be issued to do the job into a CMS EXEC. Then you send the exec to the VM Batch Facility, which runs the exec and does the job. You are free to continue working at your terminal while the VM Batch Facility completes the job. One feature of the VM Batch Facility is that you can control when and how your jobs are completed. You can, for example, tell the VM Batch facility to run a job at night, when computer costs may be lower. There are other commands that let you find out the status of a job, change the way it is to be run, or cancel it. Here are two example to show how the VM batch facility could work for you: Example 1: Mary has a long report to format and print. To save the 20 minutes it would take to format the report, she sends the job to the VM Batch Facility. It formats the report and sends it to the printer. Meanwhile, Mary has been able to keep working at her terminal. Example 2: Gene has a truckload scheduling program to run. He wants to run it overnight to take advantage of lower computer rates, so he sends the job to the VM Batch Facility, specifying when the job should start. The VM Batch Facility runs the job and has the output for him in the morning.

How the VM Batch Facility Works The process starts when you submit a job to the VM Batch Facility – a monitor VM and task VM The monitor virtual machine receives your job and holds it until it can start: A task virtual machine runs your job The monitor machine periodically checks your job while it runs Your commands can retrieve the status of a job, change how and when it is to run, and cancel a job When your job is completed, the task machine logs off and is ready for another job The process starts when you submit a job to the VM Batch Facility. When you use the Submit panel or the BATCH SUBMIT command, your job is sent to the VM Batch Facility monitor virtual machine that controls the VM Batch Facility. When you submit a job, you can use job control options to control how your job is to be run. Job control options let you specify, among other things, the following: Date and time period during which your job should start, limits on the resources the job can use while running, whether a console log should be generated from your job, whether your job is conditional on successful execution of another job (job chaining). You can also let the VM Batch Facility set the necessary job control options for you. The job class to which you submit your job has default values for several of the job control options. Job classes are effectively types of jobs that the VM Batch Facility can accept. Every job must belong to a job class. The VM Batch Facility also sets other options for you automatically, if you do not specify them when you submit your job. You can submit jobs for execution while in an XEDIT session. You can submit the file being edited in an XEDIT session, the previously saved version of the current file, or any CMS file. The monitor virtual machine receives your job and holds it until it can start. In the monitor virtual machine, your job waits its turn to run. It will be eligible to run when its start date and start time arrive. A task virtual machine runs your job. The VM Batch Facility uses other virtual machines, called task machines, to run jobs. When a task machine becomes available, the VM Batch Facility finds the next job that can run in the machine. Task machines accept jobs only from the job classes assigned to them. To be ready to run in a task machine, your job's start date and start time must have arrived. (For an urgent job, you can also have a VM Batch Facility administrator or authorized user start the job for you, even if its start time has not arrived.) The monitor machine periodically checks your job while it runs. As your job runs, the monitor machine checks on the status of the job. If your job exceeds the resource limits in effect for it, the monitor machine can cancel the job. Resource limits include limits on the amount of computer time a job can use and on the numbers of print and punch records it can produce. The limits may be specified by you or by the job class to which you assigned the job. If your job stops running for some reason, the monitor machine detects that it has stalled. If a stalled job does not restart, it is automatically canceled. Your installation determines how long a job can remain stalled before it is canceled. If your installation uses the VM Batch Facility Load Level Scheduler (LLS), your jobs may be automatically suspended if the system becomes overloaded, and resumed when the load falls. Your commands can retrieve the status of a job, change how and when it is to run, and cancel a job. While your job is being processed by the VM Batch Facility, you can use VM Batch Facility commands to check the status of your job; change job control options such as the job's start time; find out the status of task machines; review the job control options defined for each job class; or cancel one or more of your jobs. When your job is completed, the task machine logs off and is ready for another job. Before logging off, the task machine performs security procedures to ensure that other jobs cannot get access to the data and other resources that your job was using. The task machine's 191 minidisk is erased and cleaned, spool files that have not been closed and sent are erased, and links to minidisks are detached. When your job ends, you can also receive a “console log file” in your reader. The log file contains all of the messages that you would have seen at your terminal if you had run the job exec yourself.

z/VM Help Facility CMS Help Facility provide assistance for: Tasks Commands and options Subcommands REXX statements Callable routines Pipeline stages Assembler language macros Messages The z/MV Help Facility runs under CMS and provides online assistance for various z/VM functions in the form of menus. The CMS Help Facility provides information for tasks, commands and options, subcommands, REXX Statements, callable routines, Pipeline stages, Assembler language macros, and Messages. Other licensed programs may come with additional help topics. It is also possible for you to write your own help files. An important thing to remember is that you can access the z/VM Help Facility at anytime. All you need to do is type “HELP operand”, where the operand is a command you are having trouble with or the type of command you are looking for. To arrive at the main help menu, you would just need to enter “HELP HELP”.

Shared File System (SFS) Files are stored in file pools A user can be given an amount of file space in a pool The files in a file space are organized in directories A file can be placed in more than one directory A file pool is a collection of minidisks assigned to a single virtual machine called a file pool server machine. A minidisk is a partition of the DASD storage device and is a z/VM storage unit. Since the minidisks in the file pool are shared by many users, using SFS can save DASD space. Certain SFS directories can be placed into VM data spaces, providing additional DASD savings. Using VM data space may also provide a performance improvement. The files in a file space can be organized in specific directories and certain files can even be placed in more than one directory if needed.

Shared File System (SFS) continued Users can grant each other authorities for files or directories Multiple users can have concurrent access to the same file or directory Locks on files and directories ensure data integrity among multiple users You can share files and directories with users on other systems Regular SFS processing allows control at a file level, referred to as file level control, where you can grant authority for access to individual files. With this level of control you can lock individual files and you can see file changes made by other users as soon as they are committed. This type of control provides flexibility and concurrency (allowing multiple users to access data at the same time). This makes the SFS very efficient. Locks on files and directories ensure data integrity among multiple users. Locks are a type of security feature that allows the owner of the files or directories to stop other users from accessing these files or directories. Files and directories can also be shared with users from other systems. All of these attributes of the Shared File System makes it a very powerful tool. If you do not lock your data then other users can make changes to your files at any time. If changes are made, the SFS will display those changes. If your files are locked, changes to your files are not allowed and your data will never be changed by other users.

Syntax Diagrams (basics) Read syntax diagrams from left to right and from top to bottom This side module shows you descriptions and examples This short section teaches you to read and use syntax diagrams. To read a syntax diagram, follow the path of the line. Read from left to right and top to bottom. Syntax diagrams explain how and what commands are able to accomplish. A CMS command consists of a command name, usually followed by one or more positional operands and, in many cases, by an options list. The general format of CMS commands is shown in the diagram above. +++ Read “Understanding Syntax Diagrams”

CMS Commands This section lists and describes the most important and useful CMS commands. Four such commands are QUERY, SET, ACCESS, and FORMAT. Query – is used to gather information about your CMS virtual machine Set - is used to establish, turn off, or reset a particular function in your CMS virtual machine Access – is used to make minidisks or directories available to your virtual machine Format – is used to initialize a minidisk for the use with CMS files, count or reset the number of cylinders on a minidisk, and writes a label on the minidisk

QUERY The QUERY command has a general user authorization. You would use the QUERY command to gather information about your CMS virtual machine. You can retrieve information about the status of virtual machine characteristics that are controlled by the CMS SET command, the status of CMS/DOS functions, the search order for libraries (MACLIBs, TXTLIBs, CSLLIBs, and LOADLIBs), and information about your saved segments. QUERY also returns the status of your files and file pool directories, such as file definitions that are in effect, the status of your accessed disks and SFS directories, authorities that have been granted on file pools and SFS directories or the files contained within them, aliases that exist on files in file pools and SFS directories, information about your file pool, and whether your file pools are locked or disabled. You can also retrieve information about how your virtual machine is set up for windowing in full- screen CMS; for example, the characteristics of your physical screen, CMS PF key settings, characteristics of windows you have defined, the order in which the windows are being displayed, and characteristics of the virtual screens that support the window. The syntax diagram for the QUERY command is shown on the foil. The required attributes are the QUERY command and then the correct operand. The Options allow you pick FIFO (first-in, first-out) or LIFO (last-in, first-out) execution. If you don’t make that choice, you must choose a STACK option where FIFO is the default value and LIFO is the other option. STACK causes the results of the QUERY command to be placed in the program stack instead of being displayed at the terminal. Some operands of the QUERY command, ALIAS, AUTHORITY, and FILEATTR, can also be used in the XEDIT command area in order to place information in a file, rather than displaying it to the terminal. The output replaces the information in the file starting with the current line and continues until the end of the output is reached. The remaining text in the file, if any, is unchanged. The edited file must either be variable length format or fixed format with a logical record length (lrecl) of 190 for QUERY ALIAS, 165 for QUERY AUTHORITY, or 49 for QUERY FILEATTR.

QUERY – Usage Notes The diagram on the slide displays the operands available with the QUERY command. Usage Notes (General): These notes apply to all operands of the QUERY command: You may specify only one QUERY operand at a time. If a non-valid QUERY operand is specified from an exec, the implied CP (IMPCP) function is in effect, and no stack options are specified, then the return code is -3 and nothing is placed in the program stack. The program stack is where commands and applications are placed when waiting for execution.

SET The SET command has a general user authorization. The SET command establishes, turns off, or resets a particular function in your CMS virtual machine. Only one operand may be specified per SET command and the SET command cannot be issued without an operand. General Usage Notes for all SET command Operands: If you issue the SET command specifying an invalid function and the implied CP function is in effect, you may receive message “HCPCFC001E Invalid option – option”. If an invalid SET command function is specified from an exec and the implied CP function is in effect, then the return code is -0003. To determine or verify the setting of most functions, use the QUERY command.

ACCESS The CMS command ACCESS has a general user authorization and has three purposes. First, it can identify a minidisk or Shared File System (SFS) directory to CMS. Second, it can make a list of the files on the specified minidisk or directory available to your virtual machine. Third, it establishes a file mode letter for the files on a minidisk or in a directory. Therefore, it is mainly used to access disks on a virtual machine. When you log on to your virtual machine, you have a set of minidisks already located or accessed on your virtual machine guest, but with the ACCESS command you can add additional already-defined minidisks. (This is also a lab topic.) The ACCESS command gives you four different path options. The 0191 as fm A and topdirectory as fm A are defaults if a device and directory were not specified. The 0191 minidisk is the default virtual address for your individual user space. It is given the file mode (fm) A, just as the C: drive is the default user space on a Windows system. Valid file modes are A – Z and combinations such as Y/S. When searching minidisks for a filename (an exercise in the lab), z/VM starts at the beginning of the alphabet and continues until the end of the alphabet. If you issue ACCESS without any operands, the 0191 disk or top directory is accessed as file mode A. If both the 0191 disk and top directory exist, the top directory will be the one to be accessed as file mode A. For the most part, we will not be using Path A or Path B in this course, but here is a brief explanation of these options. With Path A, you specify dirid to identify an SFS directory to be accessed. For this command you cannot use the fm format of dirid. fm assigns a one character file mode letter to all files on the minidisk. In Option (1), /ext indicates the file mode of the parent minidisk or SFS directory. Files on the minidisk (vdev) or directory (dirid) being accessed are logically associated with files on the parent minidisk or directory. The minidisk or directory is considered a read-only extension. A parent minidisk or directory must be accessed in the search order before the extension. A blank must not precede or follow the slash. For Option (2), you must begin the options list with an open parenthesis, which can be closed or not. NOPROF suppresses the execution of a PROFILE EXEC file. This option is valid only if the ACCESS command is the first command entered after you IPL CMS, otherwise it is ignored. Only the minidisk or directory at file mode A and system disk (file mode S) with its associated extensions are accessed. The FORCERO and FORCERW options force the SFS directory to be accessed in read-only status or in read/write status.

ACCESS Path B begins in the same fashion as Path A. Option (1) is the same as Path A, but allows you to pick a specific file to access by using fn, ft, and fm. If you do not specify a file, all files are accessed. This is the default and is represented by the * . Option (2) is specified according to the section labeled Options B. Within Options B, you can specify NOPROF, ERASE, SAVEONLY, or NOSAVE. As in Path A, NOPROF suppresses the execution of a PROFILE EXEC file. This option is valid only if the ACCESS command is the first command entered after you IPL CMS, otherwise it is ignored. ERASE indicates that you want to erase all of the files on the specific minidisk. This option is only valid for read/write disks. SAVEONLY accesses the minidisk if a saved copy of the file directory information is available in a saved segment. If it is not available, the minidisk is not accessed. NOSAVE accesses the minidisk and places the fie directory information in your virtual machine. A saved copy of the file directory information in a saved segment is not used. After choosing one of the file management subcommands, you can choose NODISK and/or MODE0. NODISK lets you gain access to the CMS operating system with no minidisks accessed by CMS except the system disk and its extension. This option is only valid if the ACCESS command is the first command you enter after you IPL CMS. MODE0 accesses the minidisks and includes file mode 0 files. This option is meaningful only to minidisks that are linked read-only. The ACCESSM0 command must be set to ON before the ACCESS command to enable the MODE0 option.

ACCESS – Usage Notes Using the ACCESS command with a directory ID or a device number With and without a file pool Using the ACCESS command with a directory ID Determining status by ownership Using the ACCESS command with a virtual device number Access can create a file directory in your virtual machine when one is not present Using the ACCESS Command with a Directory ID or a Device Number: When you IPL CMS, if you have a default file pool defined in your z/VM directory, or if you define it when you IPL CMS, your top directory in that file pool is accessed as file mode A. If no file pool is defined and you have a defined disk number of 0191 in you z/VM directory, or you define it before you IPL CMS, your 0191 disk is accessed as A. If you do not have either a top directory in the default file pool or a 0191 disk defined, then nothing is accessed as file mode A. If you have defined disk number 190 and 19E in the z/VM directory, or if they are defined before you IPL CMS, these disks are accessed as file mode S and Y respectively. Using the ACCESS Command with a Directory ID: When you access an SFS directory without forcing the status to read-only or read/write, the status is determined by who owns it. If you are the directory owner, then it is accessed as read/write. If you are not the directory owner, the directory is accessed as read-only. If the your are not authorized to access the directory, you will not be given access. To force a directory that you own to be accessed in read-only status, you can either access the directory as an extension of another minidisk, a directory, or of itself. For example:  ( access vmsysu:yourid.test a/a ). You could on the other hand specify the FORCERO option:  ( access vmsysu:yourid.test a (forcero ). Any directory that you do not own is, by default, accessed in read-only status, even if you have write authority to that directory. Using the ACCESS Command with a Virtual Device Number: Associated with each CMS minidisk is a file directory, which contains an entry for every CMS file on the minidisk. Specifying ACCESS without the SAVEONLY or NOSAVE options accesses the minidisk using a saved copy of the file directory that contains entries for only those files that you can access. If the saved segment containing the saved copy is not available or is not current, ACCESS creates a file directory in your virtual machine.

RELEASE The RELEASE Command is used to free an accessed disk that was previously accessed with the ACCESS Command. Example: release 0293 The RELEASE command has a general user authorization and is used to free an accessed disk that was previously accessed with the ACCESS Command. You must specify vdev, dirid, or fm with the RELEASE command. vdev is the virtual device number of the minidisk to be formatted (the valid address range is from 0001 – FFFF for XA and XC virtual machines). You can use leading zeros. For example: release 0293 dirid is the name of the directory to be released. fm is the file mode letter for which the disk or directory is currently accessed. You will only be able to use vdev, dirid, or fm, when releasing a disk from your directories. Combinations of these will result in an error (Unexpected symbol or unrecognized device type). An additional option is DETach, which specifies that the disk is to be detached from your virtual machine configuration. The DETACH option is ignored when you are releasing a directory. Usage Notes: If a disk or directory is accessed as more than one file mode, the RELEASE vdev or RELEASE dirid command releases all modes. If you specify the file mode of an already active disk or directory, that disk or directory is released. You cannot release the system disk (disk at file mode S). A list of the files on an accessed disk is maintained in your storage. When a disk is released, this list of files is freed from your storage and that storage becomes available for other CMS commands and programs. When CMS does keep the list of files in your storage, the space may not be freed until it is needed by a CMS command or a program. When you release a R/W CMS disk either with the RELEASE command or implicitly with the FORMAT command or ACCESS commands, the list of files is sorted and rewritten on disk; as a result, the file search time may be reduced for users who subsequently access the same disk.

RELEASE If you want to release and detach the 498 disk that is accessed as your file mode b, then issue: release 498 (det OR -- release b (det To just release the disk currently accessed as file mode c, issue: release c Usage Notes Continued: When a disk or directory is released, its read-only extensions, if any, are not released. They may be referred to by their own file mode. If a disk or directory is then accessed with the original file mode that they were extensions of, they revert to being extensions of the new disk or directory at that file mode. The RELEASE command rewrites the file directory on any CMS disk accessed in R/W mode whether the disk was altered. In an XA or XC mode virtual machine, detaching a minidisk (with a CP DETACH command) will cause CMS to implicitly release the disk if it is accessed. Also, if a minidisk address is redefined (with a CP DEFINE or REDEFINE command), CMS will implicitly release the disk if it is accessed. Examples: If you want to release and detach the 498 disk that is accessed as your file mode b, then issue: release 498 (det or release b (det If you want to release the directory .PROJECT1 (in an SFS Directory Structure) that is accessed as your file mode c, enter: release .project1 release c

FORMAT The FORMAT command has a general user authorization and is used to initialize a minidisk for use with CMS files, to count or reset the number of cylinders on a minidisk, and to write a label on the minidisk. The vdev and fm operands are required. vdev is the virtual device number of the minidisk to be formatted (valid address range from 0001 – FFFF for XA and XC virtual machines). fm is the file mode letter to be assigned to the specified device address. Any single character letter, A through Z, excluding S, is valid. This field must be specified. If any other disk is accessed at this mode, it is released. If you specify S as the file mode, you will receive an error, because the file mode S contains the z/VM system disk. Next you have the option to choose nocyl or noblk. nocly is the number of cylinders to be made available for use. If this operand is omitted, or if the number specified exceeds the actual number of cylinders on the disk, then all the cylinders on the disk are made available for use. noblk is the number of blocks to be made available for use. If this operand is omitted, or if the number specified exceeds the actual number of blocks on the disk, then all the blocks on the disk are made available for use. After these parameters there is an optional area where you can choose your block size (the options within the parentheses can be in any order). Blksize specifies the physical DASD block size of the CMS minidisk. Acceptable values are 3350, 3375, 3380, 3390, and 9345, where 3350 represents a block size 2048 and the rest represent a block size of 4096. The Blksize option defaults to a block size that optimizes the I/O and data storage for the particular device. Noerase specifies for FB-512 devices that the formatted FB-512 blocks are not to be cleared to zero. FB- 512 block is a directory that uses 512 bits. For non-FB-512 devices, this option is ignored. Label specifies a label on the disk without formatting the disk. The CMS disk label is written on cylinder 0, track 0, record 3 of the minidisk, or block 1 of an FB-512 device. A prompting message request a six-character disk label made up of alphanumeric variables. Recomp changes the number of cylinders/blocks (FB-512 blocks) on the disk that are available to you. If you specify nocyl/noblk and that many cylinders/blocks are not available, you only get the available number of cylinders/blocks.

FORMAT – Usage Notes Examples of RECOMP and LABEL: format 192 b (recomp) format 193 c (label) Formatting a disk requires heavy processor utilization, so can be slow and affect performance Choose the appropriate block size to optimize: space utilization performance Automatic formatting is possible on the 192 disk Usage Notes: When you do not specify either the RECOMP or LABEL option, the disk area is initialized by writing a device-dependent number of records (containing binary zeros) on each track. RECOMP changes the number of cylinders/blocks (FB-512 blocks) on the disk that are available to you. If you specify nocyl/noblk and that many cylinders/blocks are not available, you only get the available number of cylinders/blocks. LABEL specifies a label on the disk without formatting the disk. Any previous data on the disk is erased. A read after write check is made as the disk is formatted. For example format 191 a 25 initializes 25 cylinders of the disk located at virtual address 191 in CMS format. The command format 192 b 25 (recomp) changes the number of cylinders available at virtual address 192 to 25 cylinders, but does not erase any existing CMS files. To change only the label on a disk, you can enter format 193 c (label), which CMS responds to by prompting you to create the new label. Because the FORMAT command requires heavy processor utilization and is heavily I/O bound, system performance may be degraded if there are many users on the system when you use FORMAT. When choosing an appropriate BLKSIZE to format a disk, there are two main concerns: space utilization and performance. Thus, larger block sizes are generally preferable for DASDs for optimum space utilization, but if you have many small files, a smaller block size might be preferable since each CMS block can only be used by a single file. A BLKSIZE of 4KB will optimize the I/O if the disk is to contain large files with no missing records (dense). Otherwise a smaller BLKSIZE is more preferable, like a BLKSIZE of 1KB when creating many small files or sparse files. If you have a minidisk defined as virtual device 192, it may be automatically formatted and accessed when you IPL CMS. This can be accomplished by specifying these commands within your PROFILE EXEC, which runs when you IPL CMS during logon.

Conclusion CMS – Conversational Monitor System Is a operating system that runs within z/VM CMS tasks include writing, testing, and debugging application programs to be used by CMS or z/VM guest systems CMS runs the full-screen editing facility called XEDIT The CMS help facility is a CMS Command that can be accessed when help is needed by entering: help cms CMS supports only a single user, which makes it rather simple. CMS is easy to use and works well with z/VM. CMS pipelines can be used to make tasks easier and more efficient. CMS Application Multitasking allows an application to divide itself into multiple units of execution, which are referred to as threads. XEDIT is a flexible editor in CMS. Application environments that CMS supports include: library services (such as CSE), CMS pipelines, multitasking facilities, OpenExtensions Services, the Reusable Server Kernel, XEDIT, the batch facility, and the help facility. The Shared File System creates file pools to assist file management and improve performance. To access a file pool, you must be authorized by someone with administrator authority for that file pool, or the user PUBLIC must be enrolled. If an administrator gives you an SFS file space in a file pool, you are the only one (other than an administrator) who can create files in that file space, unless you specifically grant this authority to another user. Therefore the System Administrator has the authority to create an SFS directory and the file pools needed. The CMS commands that we covered in this module are basic and easy to use, in future modules we will get into more complex commands.

Glossary Conversational Monitor System (CMS)- A component of z/VM that runs in a virtual machine and provides both the interactive z/VM end-user interface and the general z/VM application programming interface. CMS runs only under the control of the z/VM Control Program (CP). CMS Pipelines- CMS job control product for z/VM that enables complex tasks to be specified and executed. CMS Pipelines has three parts – a command parser, a library of built-in programs, and a dispatcher. Callable Services Library-A package of CMS routines that can be stored as an entity and made available to a high-level language, REXX, or an assembler program.

Glossary File pool-A collection of minidisks managed by a file pool server. It contains user files and directories and associated control information. The files and directories for many users can be contained in a single file pool. Group Control System (GCS)- A component of z/VM, consisting of a named saved system that the user can IPL and run in a virtual machine. It provides simulated MVS services and unique supervisor services to help support a native SNA network. Initial Program Load (IPL)- The process of loading an operating system into a machine OpenExtensions Services- The VM implementation of three POSIX standards

Glossary OpenExtensions Shell and Utilities- provides application development tools and an interactive environment in support of the POSIX application environment. REXX/VM- (REstructed eXtended eXecutor programming language) processes English-like commands. XEDIT- A full-screen editing facility that runs under CMS.

References CMS Command and Utility Reference. Manual Number: SC24-6010-02. Third Edition (May 2002). CMS User’s Guide. Manual Number: SC24-6009-00. First Edition (July 2001).