IBM User's Guide, Thirteenth Edition


4 Timesharing on VM: CMS


Introduction

VM is the IBM timesharing operating system that runs on the IBM 3081 computer at UTCC. The VM operating system consists of two major components: CP (the Control Program), and CMS (the Conversational Monitor System). These two components work together to give each VM user a personal-computer-like environment. The CP component manages the real computer hardware such as disk drives, terminals and printers and creates a complete, simulated "personal" computer for each user when the user logs on. This simulated computer is known as a "virtual machine," from which the operating system name "VM" is derived. A user may issue CP commands to change the simulated hardware configuration for his or her simulated computer. For example, the command CP DEFINE STORAGE 8M instantly changes the amount of memory on a simulated computer to eight Other CP commands can add, delete, move, or change the characteristics of simulated devices such as disk drives, terminals, and printers. To see a list of the CP commands that you can issue, type CP COMMANDS at the CMS command line. Further online information about any of the commands in the list can be seen by typing HELP CP command CMS is the operating system for the simulated computers created by CP. CMS commands help VM users do their work. For example, the CMS command XEDIT MY STORY opens a file called MY STORY and invokes XEDIT, the CMS text editor. This file can be printed using the CMS PRINT command:

PRINT MY STORY

Other CMS commands can compile a source program, run it on CMS, and display the program output. Also, programs for batch execution under the MVS operating system on the IBM 3090 can be created in a CMS file and submitted to MVS with the RJE (Remote Job Entry) command. The remainder of this chapter discusses CMS features and commands as implemented at UTCC. More information about VM, CP, and CMS can be found in online help files, other UTCC documentation, and IBM publications. For online help, log on to CMS and enter the command HELP. A list of IBM publications about VM, CP and CMS is found at the end of this chapter, section 4.27. References to UTCC documentation (U01s) appear throughout this guide; U01s can be accessed using the PRTDOC facility on CMS (see section 4.11). In addition, the following one-page U01s, called "quick-reference cards," are bound into the back of this guide, to be kept at hand for a highly condensed reference on CMS:

U01-0568, "IBM VM/CMS Introduction Quick Reference Card"
U01-0573, "XEDIT on CMS Quick Reference Card"
U01-0595, "CMS BITNET and Internet Quick Reference Card"
U01-0626, "IBM CMS Rice MAIL Quick Reference Card"
UTCC offers "Introduction to CMS," a short course, once each academic term. See section 1.4.2.3 for information about how to obtain the current short course schedule.

CMS accounts and userids

A valid CMS userid is required to log on to CMS. At UTCC, a CMS userid consists of the user's programmer number with PA appended to the front, e.g., PA999998. If programmer number 999998 is validated to use CMS on more than one project code, then the userid associated with the second project code will be PB999998, the third, PC999998, etc. Each project code is assigned a UTCC consultant who can assist the user in getting started with CMS.

Passwords

When a CMS project code is opened, each user of the project code is given a validated userid and a corresponding password six to eight characters in length. The userid and the password together are necessary to log on to CMS. In order to protect project codes from unauthorized use, passwords should be chosen carefully and changed periodically. After a successful logon, a password may be changed by issuing the following directory maintenance command:

CMSPASSW

Instructions will appear on the screen.


Logging on to CMS

Most ASCII terminals at UTCC (including those in the remotes and user work areas) access CMS through a terminal port selection and multiplexing network called the Racal-Milgo Series 300 system. By well-ingrained habit, most UTCC users refer to this network as the "DCA" network, because that was the name of the product that for a long time performed the functions now carried out by the Racal-Milgo system. Consequently, in this guide, this network system is called the "DCA" network. Leased-line terminals are connected directly to the "DCA" network. Terminals with dial-up lines must be connected to the network by telephone and modem. Note that the word "terminal" is used here to describe both actual terminals and microcomputers emulating terminals. A terminal is connected to the "DCA" network if, when the terminal is turned on and RETURN is pressed a couple of times, the terminal responds with the prompt

UTCC TIMESHARING NETWORK
ENTER HOST NAME OR HELP > Basic procedures for logging on to CMS through the "DCA" network are given below. Also, "IBM VM/CMS Introduction Quick Reference Card," U01-0568, is included in the back of this manual. Note : Terminals and terminal-emulating packages should be set to eight bit, no parity.

Ethernet terminal servers
There are some terminals on campus that can connect to CMS via an Ethernet terminal server. When such a terminal is turned on and RETURN is pressed, the terminal will respond with the prompt Local> terminal server is included in section 4.4.3.

Logging on to CMS through the "DCA" network

To log on to CMS:

1. At the ENTER HOST NAME prompt, type CMS and press RETURN.

2. You will be prompted to enter the terminal type at which you are working. (For a list of terminal types supported, press RETURN after the prompt.) Enter your terminal type.

3. When the VM/SP logo appears on the screen, the cursor will be positioned for entry of your CMS userid:

USERID   ===> _
PASSWORD ===>
 
COMMAND  ===>

Type your userid and enter your password. Press RETURN.

4. When the correct password is entered, the system will first print some notices and then the line:

** UTCC CMS xx **

where "xx" indicates the release and maintenance level of the VM/SP operating system being accessed. This information may be helpful in making sure that any reference manuals you are using are compatible with the release of the operating system currently in use by UTCC.

If this is your very first logon on this CMS account, proceed to section 4.4.1.1 now.

If this is not your first logon, press RETURN when the display pauses at ** UTCC CMS xx **. The logon news will be displayed, followed by some statements about the status of your disk area. After you respond to these comments and/or press RETURN, the "Ready;" prompt is displayed, indicating that CMS is ready to receive commands.

If the messages displayed by the terminal fill the screen, then the word "MORE" will appear at the bottom right corner of the screen. To clear the screen, press the CLEAR key. For VT100/200-series terminals and emulations, the CLEAR function is mapped to the ENTER key on the numeric keypad. When the words "VM READ" appear in the bottom right corner of the screen, CMS is awaiting input from you (minimum input: press RETURN). To end a session on CMS, enter the command

LOGOFF or LOG

Procedure for first logon

If logging on to a new CMS account for the first time, follow steps 1, 2 and 3 outlined above. When the line "** UTCC CMS xx **" is displayed, type

HELLO

The HELLO command establishes the CMS disk environment and introduces the new user to CMS. You can get information about the HELLO command by entering

HELP HELLO

Logging on to CMS in line mode

Some types of terminals are unable to execute a logon to CMS as outlined above; one such group of terminals are the hardcopy terminals located in of the UTCC user work areas. A user working at such a terminal can log on to CMS in line mode. To log on to CMS in line mode, at the ENTER HOST NAME prompt, type

IBM

and press RETURN. Then type

V

and press RETURN. The following message will appear at your terminal:

     VIRTUAL MACHINE/SYSTEM PRODUCT--VM3081  --PRESS BREAK KEY
     !
 
     Enter one of the following commands:
 
        LOGON userid           (EXAMPLE:  LOGON PA999998)
 
        LOGOFF
     .
     ._

When you have entered the LOGON command with your userid, you will be prompted for your password:

   Enter password:
   .SSSSSSSSSSSSSSSSSSSSSSSSS
For more information about using CMS in line mode, see the UTCC videotape "Introduction to CMS," in Audiovisual Services at the Hodges Library, available during regular library hours. Printed course materials to accompany this video course can be obtained at 200 Stokely Management Center. An excellent reference for CMS line-mode users is CMS Primer for Line-Oriented Terminals Also, "XEDIT on CMS," U01-0573, discusses using the CMS editor, XEDIT, and includes some commands that can be entered at the command line; this document is bound into the back of this user's guide and is also available through PRTDOC.

Logging on to CMS through an Ethernet terminal server

A terminal server allows you to have several computer sessions active simultaneously; you can switch among the sessions by pressing the BREAK key. To connect to CMS from a terminal server:

1. Turn the terminal on.
2. Press the RETURN key. The terminal server will respond with the prompt

Local>

If you already have another active session, you can get the Local> prompt by pressing the BREAK key.
3. To initiate a CMS session, enter the command CONNECT CMS and press RETURN. You will be prompted to enter your terminal type.
4. When the connection is complete, the screen will display the VM/SP logo and prompt you for your userid and password. Complete the CMS logon by following steps 3 and 4 in the list in section 4.4.1. Once you are logged on to CMS, you can return to the terminal server by pressing the BREAK key. This does not terminate your login session. You must do that by issuing the LOGOUT command. You can get more information about the services available from the terminal server by entering the HELP command after the Local> prompt.


CMS NEWS

The NEWS facility on CMS offers detailed information about software and hardware changes and other new features on CMS. To see this information enter

HELP NEWS


CMS files

Files in CMS have a three-part identification, consisting of a a filetype and a filemode. The filename and filetype can each be one to eight characters in length and must be specified by the user. Valid characters for the filename and filetype include A-Z, 0-9, $, #, @, +, - (hyphen), : (colon), and _ (underscore).* The is the virtual disk on which the file is to reside, which defaults to A (representing the user's private disk storage area) if not specified. To display a list of your CMS files on the terminal screen, enter the command FILELIST. Although CMS files are backed up to tape periodically, users are advised to back up important files to tape or floppy disk themselves. See section 4.18 on Kermit, a file transfer program, and section 4.20 on the VMARCHIVE file archival system.

*For a list of reserved filetypes, which have special meanings to CMS, see the ;.us CMS User's Guide , SC19-6210.


XEDIT, the CMS editor

XEDIT is the IBM text editor on CMS. This editor can be used to create, modify, and manipulate CMS files. It allows you to edit program source files (e.g., FORTRAN, SAS, or SCRIPT files) and create EXEC files. XEDIT is the editor in which electronic mail messages are created when using MAIL or NOTE. A quick reference card for using XEDIT, U01-0573, is bound into the back of this guide; it can also be viewed online or printed using PRTDOC. Additional help is available online while you are editing a file. While in XEDIT mode, press PF1 to get a menu of the subcommand help files available. An online tutorial on XEDIT is invoked with the command SLFTEACH. For information about the tutorial, enter HELP SLFTEACH.

Documentation

The following documents are available through PRTDOC:

U01-0543, "CMS Full-Screen Editing for VT100, VT220, VT240, VT320, IBM PC, and Macintosh"
U01-0573, "XEDIT on CMS Quick Reference Card" (a copy of this is bound into the back of this user's guide)

The following publications are on reserve in Hodges Library:

SC24-5220, System Product Editor User's Guide (also in the manual racks at Remotes 1, 8 and 17, in Ayres 101, Claxton, Hodges 255A, Human Ecology, Law Library, Vet Med)
SC24-5221, System Product Editor Command and Macro Reference (also in the manual racks at Remotes 1, 8 and 17, in Ayres 101 and Hodges 255A)
SC24-5236, CMS Primer


Printing from CMS

The basic command to print a CMS file on paper is

PRINT filename filetype filemode

If you have not expressly selected other print options since logon, the file will be printed on the line printer at the remote location that you okayed when you logged on (choosing other print options is discussed in the next section). The file will be printed on 11" x 14" paper with green and white stripes ("greenbar" paper), and the printed output will be sorted into the bins at the remote, based on the name that you okayed when you logged on to CMS.

Choosing print options

You can choose other print options by issuing the RIFLE command. The command syntax is

RIFLE option value [option value ...]

where "option" is one of the options listed in the online RIFLE help file and "value" is a choice appropriate to the option. Some examples are:

DEST Destination, i.e., RMTn, where "n" is a UTCC-assigned remote number. UTCC Remotes 0, 1, 2, 8, 17, 28 and 96 are public remotes, accessible to UT students, faculty and staff. Their locations are listed in the equipment list in section 1.6.3. ROOM A UTCC delivery drop site. Output printed at Remote 0 can be delivered to one of the drop sites listed in section 1.4.13. FORM What kind of paper. Default is greenbar. FORM 0416 is 8-1/2" x 11" white paper; FORM 0216 is 11" x 14" white paper. Forms 0416 and 0216 are printed only at Remote 0 in Stokely Management Center and can be picked up there or delivered by runner to a public remote or a destination on the UTCC runner delivery route (see section 1.4.13). The HP LaserJet printers (section 4.8.2) use the FORM option to select the printer and define the format. DSCOPIES How many copies of the file are to be printed

For example, to choose Remote 8 and request three copies of the output, enter

RIFLE DEST RMT8 DSCOPIES 3 Changes made to your RIFLE print option settings during a CMS session stay in effect until you change them again with another RIFLE command or until you log off. To see what your current RIFLE settings are, enter

RIFLE

To change a RIFLE option setting back to the default value, issue the RIFLE command with an asterisk for the value, i.e.: RIFLE option *

Printing on the HP LaserJet printers

CMS users can print on the HP LaserJet printers at Remotes 1, 8 and 96. The HP printers print on 8-1/2 x 11 inch paper in either landscape or portrait mode. The landscape mode prints nine lines per vertical inch with a 13-pitch font; the line length is 132 characters. Portrait mode prints 6.5 lines per vertical inch in a 10-pitch font, 72 characters per line with no line wrap. Presently there are two HP LaserJet printers at Remotes 1 and 8; IBM users can print only to the one attended by the student assistant. Output is distributed to the bins. There is only one HP LaserJet printer at Remote 96; it is self-service. Selection of the HP laser printer is controlled by the FORM and DEST parameters of the RIFLE command. Allowable values are RMT1, RMT8 or RMT96 for DEST and LAND or PORT for FORM. For example, issue the command

RIFLE FORM PORT DEST RMT8

before issuing a PRINT command for a file to be printed on the HP laser printer at Remote 8. These values for FORM and DEST will stay in effect for the entire CMS session or until they are expressly changed by the user. To change back to the default form (greenbar paper from the line printer) without logging off, issue the command

RIFLE FORM *

Printing on the IBM 3816 laser printer

The IBM 3816 laser printer is located at Remote 0 in Stokely Management Center. This printer prints on 8-1/2" x 11" sheets of white paper. Output is distributed to the bins or can be delivered through the UTCC runner service (see section 1.4.13). The 3816 printer is configured for default output formatting that emulates line printer output, i.e., it is printed in landscape mode, 66 lines per page, 132 characters per line. The printer can print on both sides of the page (duplex), which is the default setting. To select the 3816 printer, use the DEST option of the RIFLE command:

RIFLE DEST SMC3816 BANNER NO

For more information about printing on the IBM 3816 laser printer, see section 9.4.

Printing on the Imagen laser printer

The Imagen laser printer at Remote 0 produces high-quality laser output. To send output to the Imagen from CMS, enter the command

IMPRINT filename filetype (options

The options are discussed in the online help file, which can be accessed by entering HELP IMPRINT.

PPRINT lets you print to a printer attached to a personal computer

The PPRINT command prints CMS files on a printer attached to your PC, Macintosh, or VT200 terminal. The syntax of the PPRINT command is

PPRINT fn ft fm

You will be prompted to enter your terminal type; the choices are VT100, VT200, IBMASYNC or 3270/950. For information about options to the PPRINT command, see the online help file.

Using a hardcopy terminal for a quick copy of a file

A hardcopy terminal is a terminal that types your CMS session onto paper instead of displaying it on a video screen, as most terminals do. A hardcopy terminal is incapable of carrying on a full-screen CMS session; it can only function in CMS line mode, which is definitely a limitation. But a hardcopy terminal is handy if you are not at a remote site (where there are line printers) and need a quick copy of a file. Hardcopy terminals are located at many of the residence hall terminal sites and several of the UTCC user work areas; consult the equipment list on in section 1.6.3 for exact locations. The procedure to log on to a hardcopy terminal is different. Follow the steps given in section 4.4.2 to log on to CMS in line mode. When you get the CMS ready prompt, you can use the TYPE command to get the terminal to type out a copy of a CMS file:

TYPE filename filetype filemode

To log off, enter the CMS command LOGOFF.


The PROFILE EXEC file

A PROFILE EXEC file contains a set of commands that are executed each time a CMS user logs on. These commands alter the CMS environment with respect to options that are available to the user. A PROFILE EXEC file is created for each new account after the HELLO command is entered at the initial logon. Users who want to customize their PROFILE EXEC files should consult the CMS User's Guide

Getting help on CMS

CMS offers an online HELP facility, including help on commands and messages. You can get help on any command by typing

HELP command-name

If you don't know the name of the command you need you can type

HELP

to get a menu listing subjects for which help files are available. UTCC has added a great deal of software to the basic VM system, including compilers and software for statistics, database, graphics and word processing. All of the added software has help information. To see a menu of UTCC-added software type

HELP UTCC

and select the software topic. Then you can get help on any particular command or package. UTCC has also added information to the help facility about local documentation and utilities. You can find out about keyboard emulation, NEWS items about current activities and recent or coming changes, and how to manage your userid. You can find out how to submit batch jobs to MVS and retrieve the output on CMS. You can also view most UTCC documentation online. Type

HELP UTCC

and select the topic about which you would like to know.

Getting printed copies of online help files To get a printed copy of a CMS online help file, press PF6 while the help file is on your screen. This function key assignment is visible at the bottom of your screen when in the help facility. Destination of this printed output is controlled by the settings in your RIFLE file (see section 4.8.1).


Accessing UTCC documentation with the PRTDOC command

Except for the IBM and VAXcluster user's guides and microcomputer-based documentation, UTCC publications having form numbers beginning with "U01" can be accessed by using the PRTDOC command. These publications, commonly called U01s, can be a valuable, up-to-date source of information about software on the UTCC computers. To see a list of U01s available, type HELP U01. The PRTDOC command can display a U01 online at your terminal or micro or can print it on the line printer at any UTCC remote, the attended HP LaserJet printers at Remotes 1 and 8, the Imagen laser printer at Remote 0, or other, locally attached (private) printers. For more information about PRTDOC, type:

HELP PRTDOC Note: Because some printers and terminals have limited ability to print/display special characters, UTCC cannot guarantee the complete accuracy of U01s accessed through PRTDOC unless they are printed on the IBM 4245 line printer or the Imagen laser printer at Remote 0. Some U01s have such specialized formatting requirements that they will not print on some printers and may not be viewable at your terminal. The majority of U01s have no special formatting requirements.


Electronic mail and other communication services

This section includes the following communication topics:

` Mail
   ` UTCC electronic mail directory
   ` CREN network guidelines
   ` Create your own CMS NAMES file
` File transfer
   ` SENDFILE
   ` FTP
` Interactive messages
` Remote logon (Telnet)
` LISTSERV discussion groups

Key to network services

The kinds of network services available from a remote computer are related to the type of node name that identifies the computer. There are two major types of node names: BITNET-style and domain-style. A BITNET-style node name is one word, up to eight characters, with no periods, or dots, in the name. For example, UTKVM1 is the BITNET-style node name for UTCC's CMS computer. A domain-style node name is characterized by the inclusion of dots in the name. UTKVM1.UTK.EDU is the Internet domain-style node name for UTCC's CMS computer. The University of Tennessee, Knoxville, like many large universities, belongs to both the BITNET and Internet networks. Some smaller institutions may belong to only one.

MAIL facility on CMS

The Rice MAIL facility on CMS allows users to send and receive electronic mail. The MAIL facility is an alternative to the NOTE facility native to CMS. Both can be used with a CMS NAMES file to resolve userids and nicknames. Both also use the CMS notebook system to store old messages, both incoming and outgoing. Sending and receiving e-mail on CMS are described in "Rice MAIL on CMS Quick Reference Card," U01-0626, which is bound into the back of this user's guide; the document is also available through the PRTDOC facility. To read e-mail sent to you, enter the CMS command

MAIL

From the menu that is presented, you can read the mail (PF2), reply if you wish (PF5), file a copy of the mail in another notebook (LOG command), forward a copy to someone else (PF6), and/or discard it (PF9). Commands assigned to the function keys are displayed at the bottom of the screen in MAIL. For help with any MAIL command, enter at the command line HELP command-name

Sending Mail

To send electronic mail, issue the CMS command

MAIL userid@node

where "userid@node" are the intended recipient's userid and node. A nickname can be substituted for the userid and node if the nickname is recorded in your CMS NAMES file (see section 4.12.1.3). If you are writing to another CMS user at UTK, then you don't need to specify the node. If the user is not in your NAMES file, then you will prompted to enter the user's real name, to be included in the mail header (this is optional). Enter a name or press RETURN to proceed. If you entered a name, you will be prompted to enter a subject heading, which is also optional. Enter a subject or press RETURN to proceed.

Documentation

Online help is available within MAIL by pressing PF1. At the CMS command level, you can enter HELP MAIL or HELP MAILBOOK.

The following documents are available through PRTDOC:

"A User's Guide to Electronic Mail on CMS," U01-0622 "Rice MAIL on CMS Quick Reference Card," U01-0626 (This is also bound into the back of this user's guide.)

UTCC online electronic mail directory

To facilitate electronic mailing, UTCC maintains an online directory of UTCC users. The directory lists userid, node and name; departmental code and office telephone are optional. To look up a particular user, enter the CMS command

LOOKUP string

where "string" is the search string, e.g., the person's name or part of the name. The LOOKUP command will find all entries in the directory that contain the search string and will display them on the screen. The search string can contain an asterisk as a wildcard and is not case sensitive. For help with the LOOKUP command, enter HELP LOOKUP. CMS users can add themselves to the online directory, or change or delete their entries, by entering the command REGISTER. A screen menu will be displayed, with spaces for name, department and telephone number. Press PF2 to add an entry, PF6 to change an existing entry, PF10 to delete an entry, or PF3 to exit the menu without altering the online directory. Information can be entered or deleted only for the userid to which you are logged on at the time you enter the REGISTER command. For more information about REGISTER, enter HELP REGISTER, or press PF1 when the REGISTER screen menu is displayed.

CREN guidelines for the use of electronic network resources

The University of Tennessee is affiliated with the Corporation for Research and Educational Networking (CREN) through UT's BITNET membership. As a CREN network affiliate, UT expects its computer users to adhere to CREN's policies and standards for computing and to the UTCC Code of Computing Practice (on page xix). Below is the Acceptable Use Policy for CREN networks, including BITNET and CSNET.

Corporation for Research and Educational Networking Acceptable Use Policy
CREN networks are for the use of persons legitimately affiliated with CREN member or affiliate organizations, to facilitate the exchange of information consistent with the academic, educational and research purposes of its members. All individuals affiliated with CREN member or affiliate organizations are responsible for seeing that their communities are aware of these guidelines, and that the guidelines are followed, both in letter and in spirit. CREN networks are, at the discretion of the institutions involved, open to use by students enrolled at participating CREN member or affiliate educational institutions.

Use of CREN networks shall:

` Be consistent with the purposes and goals of the networks
` Avoid interfering with the work of other users of the networks
` Avoid disrupting the network host systems (nodes)
` Avoid disrupting network services

Acceptable use of the networks

The following examples may help users of the networks apply these principles in particular cases.

` Messages that are likely to result in the loss of recipients' work or systems are prohibited.

` CREN networks are not to be used for commercial purposes, such as marketing, reselling bandwidth, or business transactions between commercial organizations.

` Advertising is forbidden. Discussion of a product's relative advantages by users of the product is encouraged. Vendors may respond to questions about their products as long as the responses are not in the nature of advertising.

` CREN networks may be used for the provision of services which support the needs and purposes of the CREN networks, and for which a charge is made, if the network is an optional mechanism for provision of this service for which no additional charge is made, and as long as the use of the service is consistent with the bandwidth of the network and the forwarding hosts. Providers of such information may be nonprofit or for-profit organizations.

` Any communication which violates applicable laws and regulations is not allowed.*

Users of CREN networks are expected to be responsible in their use:

` "Chain letters," "broadcasting" messages to lists or individuals, and other types of use which would cause congestion of the networks or otherwise interfere with the work of others are not allowed.

` BITNET files will be limited to sizes determined and reviewed periodically. (Note: The current limit is 300,000 bytes per file transmitted.) CREN members or affiliates are expected to take reasonable measures (given the constraints of technology and management) to ensure that traffic using gateways between CREN networks and other networks conforms to these guidelines. Final authority for CREN acceptable use policies lies with the CREN Board. It is the responsibility of member representatives to contact the CREN Board, in writing, regarding questions of interpretation. Until such issues are resolved, questionable use should be considered "not acceptable."

* In particular, messages and data sent to destinations outside the United States must satisfy the Department of Commerce regulations (either be within the GTDA guidelines for information which may be generally transmitted or have the required license).

Creating a CMS NAMES file to simplify e-mail addressing

The LNAME command on CMS lets you choose a nickname for a userid and node address pair. Nicknames that are defined by using the LNAME command are stored by CMS in a file called "userid NAMES," where "userid" is your CMS userid. Once you have defined a nickname in your NAMES file, you can simply type the nickname in place of the entire e-mail address when sending mail, files, or interactive messages. When you enter the LNAME command, an onscreen menu appears with blanks to fill in. At a minimum, the NICKNAME, USERID, and NODE values must be filled in. If you fill in the NAME, then the person's name will automatically appear in the header of e-mail you send to him/her. Also, if you fill in an LNAME entry for your userid, including your name, then the FROM portion of the e-mail header will automatically contain your name. A nickname can define a group of users, which makes it simple to send e-mail to a fixed group of correspondents. A discussion of the LNAME command is in "A User's Guide to Electronic Mail on CMS", U01-0622, available through PRTDOC. For online help with LNAME, enter HELP LNAME.

Sending a file to a user on BITNET

Use the SENDFILE command to send a data file, a program, or a document to another user. The destination node name must be a BITNET node (i.e., no dots). When you enter the command SENDFILE, an onscreen menu appears for you to enter the filetype, and address. The address can be a nickname or a userid/node pair.

For more information about sending files, enter HELP SENDFILE.

In contrast to Internet FTP, discussed in another section, SENDFILE does not require that the sender be able to log on to the receiving host. SENDFILE is more similar to e-mail, in that the sent file is held in a system receiving area at the destination node until the recipient takes action to move the file to his/her disk area.

Receiving Files
Files sent to your CMS account come to your CMS virtual reader, or "reader" for short.

Your CMS virtual reader

Files and mail sent to your CMS account come to your CMS virtual reader, a system holding area, where they are held until you act to receive or discard them. You are notified at logon if you have files in your reader. If you have not acted after two weeks, reader files are discarded by the system. Use the RDRLIST command (abbreviation, RL) to display information about files in your virtual reader. Each line of the display includes:

` a prefix area (a blank area to the left of each file description)
` filename and filetype
` class and type
` originating userid and node
` whether or not the file is held
` number of records
` creation date and time
While in the RDRLIST environment, the following commands can be executed with respect to any files in your reader:

PEEK To display the file on the screen without reading it onto disk, move the cursor to the line describing a file and press PF11 (PEEK); press PF3 (QUIT) to get out of PEEK.

RECEIVE To write the file to your minidisk with fileid as sent, move the cursor to the line describing a file and press PF9 (RECEIVE). You can assign a new fileid by typing in the prefix area RECEIVE / newfn newft (this will partially type over the text of the RDRLIST line) and pressing RETURN.

DISCARD Delete a file in your reader by typing DISCARD in the prefix area of the line describing the file and pressing RETURN.

TRANSFER To transfer a reader file to another CMS user, type in the prefix area of the line describing the file TRANSFER RDR / userid where "userid" is the CMS userid of the person to whom you are transferring the file. (This typing will partially cover the text of the RDRLIST line.) Press RETURN to execute the transfer. When a file is transferred in this way, you no longer have a copy of the file.

To transfer a reader file to someone on a computer other than CMS, use a two-step process: First, type in the prefix area on the line describing the file TAG FILE / BITNET_node userid and press RETURN. ("BITNET_node" and "userid" are the recipient's node and userid.) Then type in the same prefix area TRANSFER RDR / RSCS and press RETURN once more to complete the transfer.

Internet file transfer program (ftp)

FTP is used to transfer files between hosts on the Internet network (i.e., node name with dots). You usually need an account on each host. Files transferred using ftp are placed in the disk area of the receiving user, not in a reader queue or receive area. The syntax of the ftp command is

ftp hostname

You cannot ftp to your CMS account from another host if you are already logged in to your CMS account. Also, before you can ftp to a CMS account, read/write passwords must have been set for that CMS minidisk. To do this, issue the CMS command

dirmaint mdisk

CMS minidisk passwords must be 3 to 8 characters, with no embedded blanks. See the online help file for DIRMAINT (directory maintenance) and select the MDISK subfile, for more information.

Anonymous FTP
Some Internet hosts have made files available for public access under a special account, usually with the username anonymous , to which you can connect through ftp without having a personal account on the host computer. To see a list of sites that accept anonymous ftp, enter HELP INTERNET and choose "FTP Sites." For more information about ftp, including examples, see "Internet," U01-0629, available through PRTDOC.

Talk to a logged-on user on BITNET

To send a short message (about 60 characters) to someone who is logged on to a computer in the BITNET network, use the TELL command. The command syntax is

TELL userid AT node message

A nickname can be substituted for the userid and node. The destination node must be a BITNET node (i.e., no dots). For example, if user PA1234 issues the following command:

TELL JJOHNSON AT UTKVX IS CHAP. 3 READY?

the message and the sender's userid and node are displayed on the terminal where JJOHNSON is logged on:

(UTKVM1)PA1234 - IS CHAP. 3 READY?

If the recipient might not recognize the sender's userid, the sender's name can be included in the TELL message text (e.g., TELL JJOHNSON AT UTKVX FROM MARY--IS CHAP. 3 READY?). JJOHNSON can respond (on the VAXcluster, the equivalent command is SEND), and a "conversation" can be held by sending messages back and forth. If JJOHNSON is not logged on when the message is sent, then the message will be discarded by the system, and the sender will receive a notice:

From UTKVX: JJOHNSON not logged in. In order to receive interactive messages on CMS, issue the command CP SET MSG ON; (ON is the default value for the SET MSG option). Conversely, if you wish to disable interactive messages to your CMS account, issue the command CP SET MSG OFF. For more information, type HELP TELL.

Internet remote login: Telnet

The telnet utility is used to log in to an Internet host from another Internet host. You usually need an account on the remote host to log in and execute commands. The syntax of the telnet command is

telnet hostname Some Internet hosts have made files available for public access under a special account to which you can connect through telnet without having a personal account on the host computer. For more information about telnet, including examples, see "Internet," U01-0629, available through PRTDOC.

Join an electronic discussion group through LISTSERV

LISTSERV is a BITNET program that maintains network mailing lists/discussion groups on hundreds of topics. Persons who join a list can send and receive mail on a particular topic to/from others on the list. To get a list of current topics and discussion groups, enter HELP BITNET and choose the topic "Information about LISTSERV Discussion Groups." If you are interested in a list's topic and want to receive e-mail from the list, you must subscribe to that list. To subscribe, issue the command

TELL LISTSERV@nodename SUB listname yourname

LISTSERV automatically picks up your userid and node name. After becoming a subscriber, you will receive all messages and mail sent to the list. You can contribute to a LISTSERV discussion only if you have subscribed to that list. Mail your contribution to the discussion group's list address; it will be distributed to everyone on the list. For example, to contribute to the list PLAY-L@UTKVM1, enter the command

MAIL PLAY-L@UTKVM1

and then type in your message. Some LISTSERV groups generate a lot of mail. It is important to check your mail regularly and delete mail that you don't want to keep. For very large volumes of incoming mail, you can preview your mail by issuing the RDRLIST command and using the PEEK, RECEIVE and DISCARD functions. To have an introduction to LISTSERV commands sent to your CMS reader, enter the command

TELL LISTSERV INFO REFCARD

For a quick help response to your screen, you can enter TELL LISTSERV HELP

To unsubscribe from a LISTSERV group
To remove your name from a discussion group, enter the following command:

TELL LISTSERV@nodename SIGNOFF listname (Again, LISTSERV automatically reads your userid and node name for the signoff procedure.) You should remove your name from all LISTSERV lists to which you subscribe if your account is going to expire or you are leaving the university. If you fail to do this, the lists will continue to send you mail across the BITNET network, only to have it discarded at UTK. To unsubscribe with a single command from all LISTSERV lists to which you are subscribed, enter

TELL LISTSERV SIGNOFF * (NETWIDE


Electronic conferencing on CMS

The CONVENE command invokes the CMS group conferencing system. Conferences are established and maintained by UTCC staff. However, all UTCC CMS users can participate in the conferences, i.e., they can read entries posted by other users and can reply or contribute entries of their own. When you enter the command CONVENE, a list of PF key functions will appear on-screen. Press PF10 to see a list of available conferences. Use the cursor-arrow keys on the keyboard to move the cursor to the line naming the conference of your choice and press PF10 to display the conference. Four PF keys are essential to moving around in the conference.

PF10 will display the contents of the entry on which the cursor is positioned; the contents will be either the text of a contribution or reply, or a menu of subchoices.

PF2 will allow you to contribute to the discussion on screen at the time you press the PF key. If someone else's contribution is on-screen when you press PF2, then your contribution will be posted as a reply to that contribution. If you don't want to reply to the on-screen message but want to make a new contribution, press PF9, Alternate PFkeys; then PF2 will enable a new contribution.

PF3 will go back to the previous level of the conference

PF12 will exit the conference system completely, returning you to the CMS "Ready" prompt.


Using the COMMENT facility to make suggestions

A special CMS userid, called COMMENT, is provided to facilitate communication between CMS users and UTCC. The COMMENT facility is intended for use as an electronic suggestion box. It allows users to create electronic mail containing suggestions and comments about UTCC facilities and services. The electronic mail is submitted directly to a UTCC User Services staff member for consideration and a reply. The purpose of the COMMENT facility is to provide a means for users to express concerns about system performance, to request new facilities and functions, or to suggest improvements and clarifications of system programs. It is meant to provide an immediate feedback to UTCC on how the system is meeting the needs of its users and is not intended to replace the consulting services offered by UTCC. To submit a comment, enter the CMS command

COMMENT

The COMMENT command invokes the Rice MAIL facility to create electronic mail addressed to the userid COMMENT, so creating a comment is identical to sending e-mail to any other CMS user. For details about the COMMENT command, enter HELP COMMENT Submitted comments, suggestions, and complaints are read daily by a UTCC User Services staff member. An answer to the comment or problem is sought from the appropriate source and a response is sent to the person who originally submitted the comment. Although most comments are answered daily, you should allow up to seven working days for a response.


User-defined commands (EXECs)

An EXEC is a file with the filetype of EXEC which contains CMS and/or CP commands. It is a way to set up a group of frequently used commands into a special procedure to eliminate the repetitious retyping of those command sequences. The filename of the EXEC file operates like a CMS command. The user enters the filename as if it were a command (followed by any parameters particular to the EXEC); this causes the group of commands in the EXEC file to be executed. In fact, several CMS commands are in reality EXECs (e.g., RIFLE, PRTDOC, SENDFILE, DIRMAINT). EXEC files may be written in the programming language REXX, which is similar in many respects to PL/I. An introduction to the REXX language is contained in "REXX: Restructured EXtended eXecutor Language," U01-0571, available through PRTDOC.

Documentation

For more information about the REXX language, see the following IBM publications:

SC24-5236, CMS Primer (on reserve in Hodges Library)
SC24-5238, VM/SP System Product Interpreter User's Guide
SC24-5239, VM/SP System Product Interpreter Reference


PIPE command on CMS processes data

In computer terms, a "pipeline" is a series of programs through which data flows. Each stage in the pipeline passes data to the next; no stage needs to know anything about the previous or following stages. Stages can be connected to perform one task and then rearranged to do another. The program in a stage can be a device driver, which gets data in or puts it out, or a filter, which alters, or processes, the data in some way. The Pipelines facility on CMS implements the concept of a pipeline. Data coming from a file, a tape or a CMS command can be passed and/or altered by the stages of a PIPE command and then be output to a file, a tape or your terminal screen. For example, the PIPE command

PIPE < MYFILE DATA A | LOCATE /FEMALE/ | CONSOLE

will take as input the disk file MYFILE DATA A, extract all lines containing the string "FEMALE," and display them on the terminal screen. This example is intended only to pique your interest. The example is simple, but the concept is powerful and has many capabilities. See the document U01-0631, available through PRTDOC, for more examples. Also helpful is the online help file accessed when you enter HELP PIPE MENU.


Professional Office System (PROFS)

PROFS is a menu-driven software system which allows the user to process calendars, documents, and electronic mail. Among the features of the PROFS system are automatic reminders, spelling checking, synonyms, and reading level analysis. PROFS will be of particular interest to university personnel who have had little or no previous computer experience, but who might be interested in its features such as electronic mail. All non-student CMS accounts created after September 1986 are validated automatically for PROFS access. Older CMS accounts can be validated for PROFS access by contacting your User Services consultant at 974-6831. To invoke PROFS, log on to your CMS account and enter the command DOPROFS. The PROFS main menu presents the major functions of PROFS. On this and all other PROFS menus, PF9 on the keypad is HELP and PF12 is END or RETURN. Entering PF12 will return to the next higher level of menu. From the PROFS main menu, PF12 exits PROFS. An extensive help facility is built into PROFS. For more information about PROFS, call your UTCC consultant.

Kermit

Kermit is a family of terminal emulation and file transfer programs that permit a microcomputer to connect to a remote host computer through an RS232 serial interface. If Kermit is run simultaneously on two computers, files can be transferred between them. For information on using Kermit with CMS, enter the command HELP KERMIT. The UTCC publications "KERMIT," U01-0557, and "Kermit Quick Reference Card for the Macintosh and DOS and PS/2 Machines," U01-0561, can be accessed through PRTDOC.

CMS directory maintenance

The directory maintenance program, DIRMAINT, performs a variety of tasks related to a user's virtual machine. Some of its more common uses are establishing access passwords to minidisks and redefining the default main storage size of a virtual machine. For more information on DIRMAINT, enter

HELP DIRMAINT


Use VMARCHIVE to store files infrequently used

Portions of the following discussion of VMARCHIVE are taken from documentation published by the developer of the software, VM Software, Inc. VMARCHIVE is a CMS file management system that provides virtually unlimited storage beyond that allocated on your CMS minidisk. Files that have been archived with VMARCHIVE may be erased from your minidisk, yet they remain accessible and can be recalled to your minidisk when needed.

Archive to disk or tape? Files may be archived either to online disk space or to an offline tape set. Both storage media are owned and managed by the VMARCHIVE storage system. In considering which storage medium to choose, consider the following factors.

1. Time. A request to archive a file to online disk space is carried out immediately. Later, if you wish to recall the archived file from the online area to your minidisk, the request is carried out immediately. By contrast, there is some delay in archiving and retrieving files to/from tape. When you request that a file be archived to tape, the file is immediately copied to a disk staging area; once per 24-hour period, all files in the staging area are written to tape, after which they are deleted from the staging area. Requests to recall archived files from offline storage are also "batched" and submitted for recall at 10-minute intervals. Files archived with the ONLINE or STAGE option may be erased from your minidisk after receiving the VMARCHIVE message informing you of a successful archive to these areas. Information about archive activity to OFFLINE storage will be spooled to your virtual reader after successful archiving.

2. Cost. There is no storage charge to archive files to tape, but files archived to online disk space will accrue a charge for the disk space used. VMARCHIVE stores files in a compressed format (up to 50 percent less for online space).

3. Limits on Duplicate File Specifications. Obviously, there is little point in archiving exactly the same file twice. However, many files go through monthly or yearly revisions, and it is often sensible to save a file at various stages during its life, say, the 1987 version, the 1988 version, etc. Only two files with identical filenames, filetypes, and filemodes belonging to the same userid may reside on ONLINE and STAGE space simultaneously. Further archive requests to archive the same file, except when using the DELAY option for OFFLINE, require the REPLACE option, which replaces the oldest copy. There are no limits for identical files on OFFLINE tape storage.

How to archive a file VMARCHIVE commands can be issued at the CMS command line, but the menu presentation mode is much easier. To archive one or more files from your issue the CMS command

VMARCH ARCHIVE (MENU

This is the most general form of the command; it will cause a list of all your files to be displayed, from which you can choose which to archive. You can limit the list to specific files by including filename and/or filetype (the wildcard character "*" is allowed) in the command. For example,

VMARCH ARCHIVE * DATA (MENU

will cause a list of all of your files of type DATA to be displayed in a menu form, from which you can select which to archive. Issuing this command does not archive the files but merely displays a list of the files for further action by you. Upon issuing the command VMARCH ARCHIVE * DATA (MENU , the screen might look like this:


18Aug90 Release 5.2D V M A R C H I V E (c)1989,Systems Center,Inc.

CMS Files Available For Archival For: PA999998

Cmd Filename Filetype Fm Format Lrecl Records Blocks Date Time
CHAP3 DATA A1 V 95 233 8 4/16/89 16:11:42 SUMMARY DATA A1 V 75 120 5 4/12/89 10:26:48 OLDCHAP DATA A1 V 95 310 9 2/20/89 14:06:16

1=Help 2=Refresh 3=Quit 4=Stype 5=Sdate 6=Sname 7=Backward 8=Forward 9=Ssize 10=Archive 11=Xedit 12=Cursor

====>


Suppose you want to archive the file OLDCHAP DATA A1. If you move the cursor to the command space at the left of the line that describes the file and press PF10, then the file will be copied to the VMARCHIVE stage area (this is the default), to be archived to permanent offline tape storage when the once-a-day transfer from the stage area is made. Files archived in this way can be erased from your minidisk as soon as you receive a message indicating successful copying to the stage area.

How to recall an archived file to your minidisk The menu presentation of VMARCHIVE is especially convenient for recalling to your minidisk files that have been previously archived. When you issue the command

VMARCH QUERY FILES (MENU

a list of archived files for your userid is displayed on your screen (see example below), and the PF keys allow you to recall or purge (erase) an archived file or cancel a pending archive request.


18Aug90 Release 5.2D V M A R C H I V E (c)1989,Systems Center,Inc.

CMS Files Previously Archived For: PA999998

Cmd Filename Filetype Cuu Date Time Refnum Recs Expdt Status
OLDCHAP DATA 191 7/2/89 14:55 635 381 12/31/99 OFF

1=Help 2=Refresh 3=Quit 4=Stype 5=Sdate 6=Sname 7=Backward 8=Forward 9=Q F/n 10=Recall 11=Sexpdt 12=Cursor

====>


Use the DELAY option to archive large amounts to tape Files may be archived directly to offline tape storage, bypassing the temporary staging area, by using the DELAY option of the archive command. If the volume of data being archived exceeds the capacity of the staging area (e.g., if you are archiving your entire A-disk), then the DELAY option may be the best choice. If you use the DELAY option, then at the time that the archiving to tape is actually done (presently at UTCC, this is being done once per 24-hour period), you will receive notification to detach the minidisk from which the file is being archived IF YOUR USERID IS LOGGED ON AT THAT TIME. In most cases, it is simpler to log off when you receive notification to detach, wait a minute or so, and log back on, instead of detaching and relinking. Information about detaching and linking minidisks is contained in the CMS Primer , SC24-5236.

Note: When using the DELAY option, you must not erase your file from your minidisk before the archive has been processed.

UTCC default values for ARCHIVE options Archive requests default to offline tape storage if ONLINE is not specified on the archive command. Archived files are deleted from archive storage after they have either expired (expiration date set by you) or have been erased with the PURGE command. The default expiration date is 99365 (based on the Julian calendar), indicating that files are to be held permanently unless they are purged or the expiration date is changed by you.

Documentation HELP files are available to get started with VMARCHIVE. Enter HELP VMARCH MENU. The HELP files show examples of responses to VMARCHIVE commands. "VMARCHIVE User's Guide," U01-0584, can be accessed with PRTDOC.


VM/CMS tape service available through VMTAPE

VMTAPE, a tape management system, allows CMS users to mount and manage tapes. You can use the VMTAPE command to display information about your tape or to ask the system operator to mount your tape so that you can use CMS commands to manipulate the tape position and read or write your data. Because VM depends on the user to position the tape before writing on it, CMS users need to understand tape format thoroughly in order to avoid accidental overwriting of tape data. UTCC recommends that users who are new to using tapes on CMS contact their consultant for a demonstration on using tapes. CMS users who need to use tapes brought from other sites (called foreign or alien tapes) need to be familiar with UTCC conventions about identifying labels. Please read sections 10.3 and 10.4 if you plan to use alien tapes. CMS tape users who need to query information about their tapes in the UTCC tape management catalog can get some information from the VMTAPE LIST command. For more extensive information, or to modify catalog information, you may need use MVS utilities described in section 10.7. For information on using the VMTAPE command, enter

HELP VMTAPE

Also available is "VMTAPE User's Guide," U01-0578, available through PRTDOC.


VMBATCH allows batch execution on CMS

The VMBATCH system on CMS lets you submit a long-running exec or program for execution on CMS as a batch job and frees your terminal for other work. An online help file may be viewed by entering the command

HELP VMBATCH

If you are within the VMBATCH menu system, help is available for each of the menus. Press the PF1 key for help with the information required on the menu you are viewing.

Documentation

The following manuals are on reserve in Hodges Library or can be ordered from VM Software Incorporated, 1800 Alexander Bell Drive, Reston, VA 22091.

VMBATCH User's and Group Manager's Guide
VMBATCH Messages and Codes


A CMS nolog account allows shared access to data

A nolog account on CMS provides a way of sharing data. Members of a group can use a common area to store a single copy of EXECs, JCL or text used by the group, or may store data which a number of group members need to update. Multiple users can take turns writing and reading CMS files on a single minidisk. Users do not log on to a nolog account. Rather, one or more normal userids are authorized to link to the minidisks on the nolog account and thus control access to the disks. For more information about a CMS nolog account, call your UTCC consultant or see "CMS Nolog Accounts," U01-0645, available through PRTDOC.

Access to the MVS operating system from CMS

Virtually all users of the MVS batch operating system submit jobs to MVS for execution through a timesharing facility such as CMS, TSO, the VMS VAXcluster, or UTKUX1 (UNIX). In this section are presented the commands CMS users must know to submit a batch job to MVS, receive the output and work with MVS data sets.

Changing your MVS password

The MVS userid and password must be supplied when any MVS batch job is submitted for execution. A new MVS account must have the password changed from the value on the UTCC-issued sticker before the account can be used for any other purpose. The MVS password can be changed from CMS. Whether for the initial password change or for a subsequent password change, enter the CMS command

MVSPASSW

The terminal will ask for the MVS programmer code, which is of the form Pnnnn. (The expression "Enter null to exit" means press RETURN to exit.) Next, the user is prompted for his or her MVS project code, which is of the form Jnnnn. Next, enter the current MVS password (which for a new account is the password recorded on the UTCC-issued sticker). Last, the user is prompted for a new password and for re-entry of the new password to verify it. A password must be 6 to 8 characters in length, consisting of alphabetic characters and/or national characters (#$@). The MVS Resource Access Control Facility (RACF) keeps a record in encrypted form of a user's last five passwords. When the password is changed, it cannot be changed to any of these last five values. For more information on MVSPASSW, enter

HELP MVSPASSW The MVS password can also be changed from the VMS VAXcluster; see section 8.11.1.

Remote job entry and retrieval

The Remote Job Entry (RJE) facility allows CMS users to submit one or more CMS files to the MVS operating system for execution as a single batch job. Upon completion, the job's output may be retrieved at a terminal with the STAT command, printed on one of the IBM line printers, or returned directly to the CMS user's reader. Jobs submitted using RJE compete for MVS system resources with all other jobs in the system. The user may submit a job and log off. At a later time the user may log on again to determine the status of the job and, if the job has completed, retrieve its output. The following sections give more information on the use of RJE and STAT.

Submitting a job to MVS (Remote Job Entry)

A job to be submitted to MVS with the RJE command must be entered as one or more CMS files, each line representing one card image. The first line of the first file must be an MVS JOB statement. Only a single job may be submitted with any one RJE command, although the single job may be contained in multiple files. For example, the following three commands will concatenate FILE1, FILE2, and FILE3 and submit them as one JES2 job:

RJE FILE1 (START
RJE FILE2 (CONTINUE
RJE FILE3 (END

By default, the filetype and filemode of these files are assumed to be JCL A1. If the PASSWORD parameter is coded with a question mark, as in the following example:

//DOIT     JOB ,SMITH,GROUP=J999991,USER=P999998,
//         PASSWORD=?

when the file is submitted, the RJE command will prompt for the user's current MVS password. The password entered will replace the question mark in the submitted job (not in the file itself). Users are encouraged to use this feature of the RJE command instead of coding their MVS password into the file itself, since the MVS password can (and should periodically) be changed without necessitating going back into the file and editing the password typed in the JCL. Do not, however, place the PASSWORD=? parameter at the end of a long JCL line, because when the actual password replaces the question mark, the line may then exceed 71 characters, the maximum for a JCL line.

For more help on RJE, enter the CMS command HELP RJE.

Retrieving MVS job output from CMS

Using STAT to retrieve MVS job output

JCL requirements for held output Output from jobs executed under MVS can be made available for online inspection from CMS by making the following changes to the JCL in the MVS job stream:

1. MSGCLASS=H or MSGCLASS=D must be coded on the JOB statement to request that printed output be held. MSGCLASS is discussed in section 7.2.1.

2. On the DD statement for the output to be held, code the SYSOUT parameter in one of the following ways:

` SYSOUT=* to request that the output be processed according to the value in the MSGCLASS parameter on the JOB statement

` SYSOUT=H or SYSOUT=D (line printer format), or SYSOUT=I (card-image format)

` SYSOUT=A or SYSOUT=B along with HOLD=YES.

3. If users other than the submitting user are to access the job output, then place the following JES2 statement immediately after the JOB statement:

/*ROUTE CMSRJO parameters

where "parameters" are one or more of the following, separated by commas:

USERID=userid
PROJECT=projectcode
CODEWORD=name

USERID is the CMS userid for which the output is to be held. To view the output, the user must have logged on to CMS using this userid.

An alternative to the USERID parameter is the PROJECT parameter, which is used to specify the project code of the VM account for which the output is to be held. Any user logged on under this project code may view the output.

The CODEWORD parameter (optional) is used to give a password that must be supplied in order to view the job's output. The codeword parameter is a convenient way to give a disparate group of users access to the job output; anyone who knows the job name and the codeword can access the job output in STAT.

How to use STAT to view held output The STAT command displays a list of the jobs in the MVS batch system, with their status and job numbers. By entering the job number, the STAT subsystem is entered, from which batch job output can be reviewed, purged, or released for printing. For more information on STAT, type

HELP STAT

"The CMS STAT Command," U01-0552, can be accessed with PRTDOC. Online help is also available from the STAT subsystem. First enter the STAT subsystem by typing

STAT jobname

where "jobname" is the job name on the MVS JOB statement. Then type HELP at the following prompt:

-->ENTER OPTIONS OR HELP<--

One of these help files, EXAMPLE2, gives a detailed example of how to retrieve MVS batch output from STAT into a CMS file. The END command is typed to exit from the HELP file. The END command is typed again to exit STAT and return to CMS command level.

MVS sysout transmission to VM/CMS The sysout (system output) transmission facility on UTCC's MVS/JES2 system allows the transmission of MVS batch job output, sysout, directly to the VM/CMS timesharing system. (For an explanation of the sysout facility, see section 8.10. See section 8.10.4 for a discussion of UTCC limits on the size and number of records that can be sent in a single network unit.) The following is an example job stream of an MVS sysout data transmission to a VM/CMS user. In this example, a user is sending a copy of an MVS disk data set to her VM/CMS account. The following JCL statements represent one of several possible approaches:

//SENDCMS  JOB  ,SMITH,USER=P999998,GROUP=J999991,
//         PASSWORD=?
/*ROUTE    PRINT RMT1
/*JOBPARM  LINES=7,ROOM=BINS
//STEP1    EXEC EZCOPY
//EZIN     DD  DSNAME=J999991.DISK.DATA,DISP=SHR
//EZOUT    DD  SYSOUT=*,DEST=(UTKVM1,PA999998)

The jobname, the user name, and the MVS USER=, and GROUP= values on the JOB statement should be specified as appropriate for the originating user, as well as the password entered when prompted. The VM/CMS userid in the DD statement DEST= keyword is that of the receiving user. Note that coding MSGCLASS=H will not hold network sysout as it will hardcopy sysout; however, MSGCLASS=H can be coded to cause the system messages and JES2 news to be held. After execution of the above sample job stream, MVS/JES2 will divide the output of the job into two groups: (1) hardcopy sysout and (2) network sysout. The hardcopy sysout (JES2 news, job log, JCL listing, etc.) will be routed to RMT1 BINS as specified on the /*ROUTE and /*JOBPARM statements. The network sysout (output produced by the EZOUT DD statement) will be routed to node UTKVM1 userid PA999998 as specified by the DEST= keyword on the EZOUT DD statement. The network sysout will be placed immediately into a single transmission unit on the network sysout queue.

Receiving the Sysout Data When the sysout data is transmitted to node UTKVM1, it is stored in the recipient's CMS reader queue. The receiving user can examine the data by entering the RDRLIST environment. (For more information about your CMS reader queue, enter the command HELP RDRLIST.) The transmitted data can be printed directly from the reader and/or can be moved to the user's permanent minidisk area. Reader files which have not been moved to permanent mini-disk storage will be discarded after two weeks. If it is desirable to preserve the sysout data's original carriage control characters while moving the data from the reader queue to permanent mini-disk storage, the file must be moved using the READPRT command. For more information about READPRT, enter the CMS command HELP READPRT. Online help is available also for the RDRLIST command. The number of reader queue files generated by any given sysout transmission unit depends on the number of sysout data sets within the transmission unit with differing sysout attributes (class, type, form number, destination, etc.). When the data arrives at the destination node, the sysout data will be separated into different files according to data attributes.

Accessing MVS disk data sets

CMS users at UTCC have read-only access to MVS disk data sets placed on the VMSHR1 disk unit. Write access to VMSHR1 is not available to CMS. VMSHR1 data sets are created, modified or deleted on MVS (see section 11.1.1). VMSHR1 data sets are created by specifying UNIT=VMSHR on the DD statement and omitting the VOL parameter. All other JCL for creating an MVS disk data set is unchanged. It should be noted that any data set that has been placed on the VMSHR1 disk pack will be available to ;.us all CMS users. The CMS system provides no security for MVS disk data sets on the VMSHR1 disk. This fact must be considered when evaluating the appropriateness of placing data on this pack.

Making VMSHR1 data sets available to CMS

Three commands are required to make a VMSHR1 data set available to CMS: a CP LINK command and a CMS ACCESS command are required to make the disk pack available, and a CMS FILEDEF command is required to make the desired data set available. UTCC provides the following two CMS commands to simplify the process:

` The OSFILDEF command issues the three commands required to make an MVS data set on the VMSHR1 pack available to CMS. The user must provide the MVS data set name and the DDNAME which is assigned to the data set. For more information on the OSFILDEF command, enter

HELP OSFILDEF

` The OSDISK command issues only the LINK and ACCESS commands to make the VMSHR1 disk available from CMS. The user then issues either the OSFILDEF or FILEDEF command to make the individual MVS data set available to CMS. For more information on the OSDISK command, enter

HELP OSDISK

Creating MVS data sets from CMS files

The CMSTOMVS command is provided to simplify creating MVS data sets from CMS disk files. This facility supports fixed or variable length CMS files with record sizes less than or equal to 4096 bytes. UNIT names supported include ONLINE, VMSHR, TAPE, TAPE6250, and TAPE1600. Partitioned and sequential data sets are supported, although generation data sets are not. Alien tapes are supported. For command syntax and details on its use, enter

HELP CMSTOMVS


Submitting a batch job from CMS to the VAXcluster

CMS users who have an account on the UTCC VAXcluster can submit a batch job to be executed on the VAX by creating a CMS file containing a VAX batch job stream. See the UTCC VAXcluster User's Guide for help with creating the job stream. To submit the job, use the CMS command SENDFILE and send it to user JOB at UTKVX.

SENDFILE filename filetype filemode TO JOB AT UTKVX If you want the job output to be returned to your CMS reader, use the following qualifiers in the VAX job statement:

$ JOB vaxuserid/PRINTER=JNET_JOBLOG/LOG_FILE=UTKVM1.cmsuserid
$ PASSWORD vaxpassword


Command abbreviations

Most of the command names and options available in CMS may be abbreviated (e.g., X for XEDIT, A for ASSEMBLE). The command

QUERY SYNONYM ALL

shows the shortest forms for CMS commands.


Other VM/SP Documentation

The following manuals are on reserve in Hodges Library. Those marked with an asterisk can be found in the manual racks at Remotes 1, 8 and 17, Ayres 101, Human Ecology and Hodges 255A.

*SC24-5220,  XEDIT User's Guide;.ct  (also at Claxton, Law Library, Vet Med)
*SC24-5221,  XEDIT Command and Macro Reference;.ct  (not at Human Ecology)
 SC24-5236,  CMS Primer
*SC19-6209,  CMS Command and Macro Reference;.ct  (not at Hodges 255A)
*SC19-6210,  CMS User's Guide;.ct  (also at Claxton, Law Library, Vet Med)
 SC19-6211,  HPO CP Command Reference for General Users


[ Top of Page | Previous Page | Next Page | Table of Contents ]