────────────────────────────────────────────────────────────────────────── TOOLS Disk/Conference Management System TOOLS Request File Submission Program User's Guide and Reference Service Level 6 Version 6.8 Document Number TOOLS-001-03 ──────────────────────────────────────────────────────────────────────────
┌─── Production of this document ────────────────────────────────────┐ │ │ │ This document was prepared and formatted using the BookMaster• │ │ document markup language. │ │ │ └────────────────────────────────────────────────────────────────────┘ ┌─── Online HELP ────────────────────────────────────────────────────┐ │ │ │ Most of the information in this document is available as online │ │ HELP. TryHELPTOOLS. For more information, see "INTRO to TOOLS │ │ HELP" in topic B.6. │ │ │ └────────────────────────────────────────────────────────────────────┘
| Fourth Edition, January 30th, 1995. | This is the fourth edition of this document, and applies to the TOOLS | EXEC, version 6.8, service level 6. | Cover art by Bill Trautman and Scott Tietjen, using CUADRAW. | © Copyright International Business Machines Corporation 1995 | All Rights Reserved
This document is a guide for using the TOOLS package. It introduces the concepts of the TOOLS system and describes the program (TOOLS EXEC) provided for sending requests to a TOOLSRUN service machine. This guide is intended to be used by people with a basic knowledge of CMS, and should be sufficient for routine use of the TOOLS EXEC. More detailed technical information is available in the companion document TOOLSRUN Administrators Guide (TOOLSRUN SCRIPT).
The TOOLS and TOOLSRUN programs are owned by the IBM ISSC Solution Center - Northeast. These programs and supporting documentation are provided as-is. We do not warrant uninterrupted or error free operation of the programs. We have no obligation to provide service, defect correction, or any maintenance for the programs or documentation. We have no obligation to supply any program or documentation updates or enhancements to you even if such are or later become available. TOOLS EXEC was developed by Mike Cowlishaw and is maintained by Bob Cronin. TOOLS SCRIPT is maintained by Scott Hightower. If you need to report a problem or have a question regarding TOOLSRUN EXEC or this documentation, you should append it to the TOOLS FORUM on IBMVM. If you have a suggestion for an enhancement, you should append it to the TOOLWISH FORUM on IBMVM. You can use the TOOLS EXEC to access the IBMVM disk. The disk name is IBMVM, managed by IBMVM at KGNVMC.
If you have a problem with TOOLSRUN and are not running the most recently distributed service level, you will be required to upgrade to the latest level and demonstrate that the problem still occurs before it will be actively investigated.
Book Cover COVER Notices NOTICES Edition Notice EDITION Preface PREFACE Table of Contents CONTENTS Figures FIGURES Summary of Changes CHANGES Fourth Edition, January 30th, 1995 CHANGES.1 Third Edition, April 21st, 1994 CHANGES.2 Second Edition, February 4th, 1994 CHANGES.3 First Edition, February 18th, 1991 CHANGES.4 Introduction 1.0 What is TOOLS? 1.1 How is data kept by TOOLSRUN? 1.2 How is TOOLS used for computer conferences? 1.3 How is TOOLS used for other disks? 1.4 Using the TOOLS Program 2.0 Overview 2.1 Addressing requests to a disk 2.2 Using the menu to send requests 2.3 Using commands to send requests 2.4 Syntax used in TOOLS Verb Formats 3.0 General TOOLS Request Verbs 4.0 TOOLS Request Verb APPEND 4.1 TOOLS Request Verb BATCH 4.2 TOOLS Request Verb CLEAN 4.3 TOOLS Request Verb CREATE 4.4 TOOLS Request Verb DISK 4.5 TOOLS Request Verb ERASE 4.6 TOOLS Request Verb GET 4.7 TOOLS Request Verb HELP 4.8 TOOLS Request Verb HIDE 4.9 TOOLS Request Verb INFORM 4.10 TOOLS Request Verb LIST 4.11 TOOLS Request Verb LITERAL 4.12 TOOLS Request Verb LOCK 4.13 TOOLS Request Verb NEWOWN 4.14 TOOLS Request Verb NOTIFY 4.15 TOOLS Request Verb OWN 4.16 TOOLS Request Verb PRUNE 4.17 TOOLS Request Verb PUNCHTAG 4.18 TOOLS Request Verb QUERY 4.19 TOOLS Request Verb REGISTER 4.20 TOOLS Request Verb REGRESS 4.21 TOOLS Request Verb RENEW 4.22 TOOLS Request Verb REPLACE 4.23 TOOLS Request Verb RESPONSE 4.24 TOOLS Request Verb SET 4.25 TOOLS Request Verb SUBSCRIBE 4.26 TOOLS Request Verb SUMMARY 4.27 TOOLS Request Verb UNINFORM 4.28 TOOLS Request Verb UNLOCK 4.29 TOOLS Request Verb UNSUBSCRIBE 4.30 TOOLS Request Verb UPDATE 4.31 TOOLS Request Verb VOTE 4.32 Privileged TOOLS Request Verbs 5.0 TOOLS SYSTEM Request Verb AGET 5.1 TOOLS SYSTEM Request Verb ALIST 5.2 TOOLS SYSTEM Request Verb AREPLACE 5.3 TOOLS PRIV Request BATCH RELEASE 5.4 TOOLS PRIV Request CLEAN 5.5 TOOLS SYSTEM Request Verb CMS 5.6 TOOLS PRIV Request Verb COPY 5.7 TOOLS PRIV Request GET disk AUDIT 5.8 TOOLS SYSTEM Request Verb LOGOFF 5.9 TOOLS PRIV Override NOCOPY 5.10 TOOLS PRIV Request Verb PLACE 5.11 TOOLS SYSTEM Request QUERY SYSTEM 5.12 TOOLS SYSTEM Request QUERY USAGE 5.13 TOOLS PRIV Request Verb REFRESH 5.14 TOOLS SYSTEM and PRIV Request Verb SHUTDOWN 5.15 TOOLS PRIV Request Verb START 5.16 TOOLS Override Verbs 6.0 TOOLS Override Verb ANSWER 6.1 TOOLS Override Verb FOR 6.2 TOOLS Override Verb NOCLOSE 6.3 TOOLS PRIV Override Verb NOCOPY 6.4 TOOLS Override Verb NODEID 6.5 TOOLS Override Verb NOPROMPT 6.6 TOOLS Override Verb NOSCREEN 6.7 TOOLS Override Verb PROPAGATE 6.8 TOOLS Override Verb QUIET 6.9 TOOLS Override Verb SENDTO 6.10 TOOLS Override Verb TO 6.11 TOOLS Override Verb TRACE 6.12 Appendix A. Summary of TOOLS request and override verb formats A.0 Request Verb Formats A.1 Override Verb Formats A.2 TOOLS versus TOOLSRUN Request Formats A.3 Appendix B. TOOLS Miscellaneous Topics B.0 TOOLSRUN authorizations B.1 Entering CMS commands from the TOOLS full screen menu B.2 Using TOOLS for conferencing B.3 TOOLS date formats B.4 Specifying the disk address B.5 INTRO to TOOLS HELP B.6 Sending TOOLSRUN commands as messages B.7 Specifying disk nicknames B.8 TOOLS filename and filetype patterns B.9 Packages of files B.10 How to UnInform/UnSubscribe B.11 Partial Shadows and Shared Forums B.12 TOOLS Commands from Other Systems B.13 TOOLS Library BIBLIOGRAPHY Getting Help BACK_1 Glossary of TOOLS and TOOLSRUN terms GLOSSARY Index INDEX
1. The initial TOOLS menu 2.2
2. The TOOLS menu after changing the nickname 2.2
3. General syntax of a TOOLS command. 2.4
4. TOOLS command line syntax example 3.1
5. A typical PACKAGE file B.10.1
| 6. TOOLS and TOOLSRUN Publications BIBLIOGRAPHY
Changes from the previous edition are marked with vertical bars (|) in the margins.
| This version of the document has been brought up to date for TOOLSRUN | version 6.8, service level 6.
| TOOLS Commands From Other Systems. | BATCH (self release)
| CLEAN | GET | INFORM | PRUNE | FOR | RESPONSE | SENDTO | TRACE | Partial Shadows and Shared Forums | TOOLS Library
| LOCK | UNLOCK | AGET | ALIST | COPY | REFRESH
This version of the document has been brought up to date for TOOLSRUN version 6.8, service level 2. Note: This version of TOOLSRUN has two important changes: GET batching and subscription expiration. Users should read the descriptions under "TOOLS Request Verb GET" in topic 4.7 and particularly "TOOLS Request Verb INFORM" in topic 4.10.
BATCH
CREATE (appendable files)
GET (batching)
INFORM (expiration)
NODEID override
QUERY (subscription expiration)
REFRESH (batching)
RENEW
SUBSCRIBE (expiration)
Partial Shadows and Shared Forums
Several minor corrections and enhancements have also been made.
The title of the document has been changed to more accurately reflect
document content.
GET SINCE for AUDIT, HISTORY and REQUESTS files.
INFORM REF
INFORM UPD
How to UnInform/UnSubscribe
TOOLS Library
Getting Help
This edition replaces TOOLS 5.0 - Disk/Conference Manager User's Guide, by Mike Cowlishaw.
This section describes the TOOLS system, how it manages data for you, how it may be used for computer conferencing, and how it can be used for other kinds of shared data. The topics covered in this section are:
Almost all computer users need to share information with others. The
TOOLS system provides a way for you to share information if you are using
a computer running the IBM Virtual Machine operating system (VM).
The information that can be shared is any data that can be put on computer
permanent storage (usually magnetic disks). The information might be
programs (in source or executable form), data (statistics, images,
documents, etc.), or computer mediated communications (computer
conferences). At present, TOOLS is limited to dealing with data objects
that can be held as simple files. It is not intended for the management
of traditional or relational databases.
The TOOLS system is composed of two REXX programs:
TOOLSRUN runs in a virtual machine of its own and manages the disks on
which the data is kept.
TOOLS is used to send requests to TOOLSRUN. Requests can be sent from
the same computer that runs TOOLSRUN, or they can be sent across
a network to the TOOLSRUN service machine.
You can use TOOLS to find out what files are kept on a disk, and
to get a copy of any of them. It is also possible to alter
files on a disk, either by appending some comment to the end of
an existing file (for computer conferencing), or by creating new
files. When you put a file on a disk, you become the owner of
that file and may alter or replace it whenever you wish. In
general, only the owner of a file may alter it.
The remainder of this introductory section will describe in more detail
the concepts used in the TOOLS system.
The TOOLSRUN program can manage any number of data repositories, called
disks. Each disk has a name assigned to it by the person administering
the TOOLSRUN installation. The name is chosen to give some idea of the
contents of the disk. For example, a disk that contains local tools is
often called "TOOLS," and one that contains local news might be called
"NEWS." Disks that are intended for general access tend to have unique
names that describe their purpose. In IBM, conferences that are used by
the whole corporation often have a name starting with "IBM," such as the
IBMPC conference (for discussions on Personal Computers), the IBMVM
conference (for discussions on VM), and the IBMMVS conference (for
discussions on OS-derived operating systems - e.g. MVS for S/370 and
S/390).
A disk can be uniquely identified by its name together with the userid and
nodeid of the virtual machine from which it is managed by TOOLSRUN. This
combination of name, userid, and nodeid is called the address of the disk.
On each disk, the data is kept in the form of objects called files. Each
file consists of any number of lines of data, and each line can be any
length. (1) Files are identified by a two-part identifier. The filename
is the name of the file, and the filetype describes the type of data
contained in the file. By convention, the filename is placed first, and
the filetype second. Thus "NEWS FORUM" is a file called NEWS with
filetype FORUM (a filetype commonly used for computer conferencing), and
"TOOLS SCRIPT" is a SCRIPT (documentation) file describing TOOLS. The
filetype, therefore, is used to categorize files by purpose or content.
Within the TOOLS system, filenames, filetypes, disk names, userids, and
nodeids are all limited by system constraints to be eight or fewer
characters, all in upper case.
Multiple copies of disks: A disk is often a unique collection of data of
just local importance, but it can also be a copy of another disk. Disks
can be copied for a number of reasons, the most common of which is to
provide fast local access. A disk which is a copy of another is called a
shadow disk, and a disk which is the master copy of a data collection is
called a master. You can usually send read only requests to the master
disk or to a shadow, but in most cases you can only make changes to the
disk by sending the request to the master.
(1) Each data object is in fact kept as a Conversational Monitor
System (CMS) file, using the VM/CMS file system. TOOLSRUN
creates an additional directory of the disk which is held in
the CMS NAMES format.
A computer conference is a discussion between two or more people which is
in some way mediated by a computer. A TOOLS-mediated conference usually
consists of a set of publicly appendable files on a dedicated CMS minidisk
managed by a virtual machine running TOOLSRUN. The participants in a
conference can create files that describe topics which interest them.
Once a file has been created on the disk, all participants (including the
owner of the file) can append comments to it. The result is a continuous
record of an open conversation by electronic mail. Each file typically
starts with a description of the topic under discussion, and this is then
followed by a series of pieces of text (called appends) which were
appended to the file by the people taking part in the discussion.
A file created for the purpose of a general discussion is a kind of open
forum, and therefore usually has the filetype "FORUM." Depending on the
purpose of the conference disk, there may be other special types of file,
such as "BUGS" (for reporting bugs in programs), "ANNOUNCE" (for
announcing new programs or facilities), "NEWS" (for news of changes etc.),
and "NOTE" (for longer discussion documents).
Once you know the address of a conference disk, (2) you can use the TOOLS
program to send requests to it (the method for sending requests is
described in the next section). A LIST request will ask TOOLSRUN to send
a list of the files on the disk to you, which is a good way to start.
Note that some of the files on the disk may have restricted access, so
they won't appear on the list. It may even be that the whole disk is
restricted to a certain group of users, in which case you will be informed
that you are not authorized to access the disk.
Once you have a list of the files on the disk, you can GET individual
files to read them. There is usually a file whose filename is the same as
the name of the disk, and whose filetype is GUIDE or RULES. This file
describes the guidelines or rules for the disk.
Most discussions will be in files with a filetype of FORUM. If you find a
forum that interests you, you can SUBSCRIBE to it. This means that
whenever someone makes an append to the file, you (and every other
subscriber) will be sent a copy of that append as a piece of electronic
mail. This subscribe process is faster and simpler (and much more
efficient) then getting a copy of the whole file at intervals.
If you follow a conference on a regular basis, and there is a copy of the
conference disk available on your system, you can often link directly to
it. If you can, there are numerous tools available to help you follow the
conference without requiring you to subscribe. This can often make it
easier for you to find the information you want, as well as reduce the
amount of spool space that your system needs to hold reader files. Of all
the tools available for this purpose, the FORAVIEW, FORALIST and OMNIDISK
tools are highly recommended.
You may decide to take part in a conference, rather than just watching and
reading discussions. You can do this in two ways: by making an append to
an existing forum, or by starting your own forum. For the former, you
should use the APPEND request, (3) and for the latter the CREATE request.
Once you create the file you become the owner of that file. In almost all
cases, you are encouraged to take an active part in conferences - the
value of any conference is the sum of its contributions.
In general, only certain files (such as those with filetype FORUM) may be
appended to by anyone, so an APPEND request may be rejected because the
file is not publicly appendable. You can find out whether a file is
publicly appendable by using the QUERY FILE request. Again, you may find
that you need special authorization to take an active part in a
conference. If your APPEND or CREATE request is rejected as not
authorized, you may have sent your request to a shadow by mistake. If
that is not the problem, then you should contact the conference
administrator to find out why your requests are being rejected.
The decision on which filetypes are allowed on a conference disk is
entirely the responsibility of the person that sets it up and administers
it. Before taking part in a conference you should read the GUIDE or RULES
file to find out how to name a file and also to judge whether your
contribution is appropriate for the conference. For example, the large
public conferences in IBM are limited to IBM Internal Use Only information
- participants must not add Confidential material to these disks.
Once you have appended information to a file, you are allowed to modify
that information (but not the information appended by other users, of
course). To send a new, modified, version of an append, you use the
APPEND command again, and specify the time and date of the original append
(as shown in the file).
(2) There is often a useful list of conference disks available
on your system, in a file called CONFEREN DISKS or OMNIDISK
NAMES.
(3) There is usually a file called TESTER FORUM on the disk
which is there for you to try out the Append request. TESTER
FORUM is a place for experimentation, rather than for
"serious" discussion.
TOOLSRUN manages all disks in exactly the same manner. There is no real
difference between files and disks used for conferencing and those
containing other data (indeed, the same disk may contain both conference
files and other data).
In addition to the requests described for conferencing, you may find the
REPLACE request (for replacing a copy of a file) useful. To hide a file
from view, you can use the HIDE request, and to "undo" a REPLACE or HIDE,
you can use REGRESS. To permanently remove a file from a disk use the
ERASE request, which also frees up the name of the file for use by others.
For most kinds of data disks, the integrity of the files on the disks is
extremely important, so TOOLSRUN makes changes to the disk in such a way
that:
• Users already accessing the disk using CMS will not find that replaced
or hidden files become unreadable.
• Only the registered owner of a file may change that file (however,
ownership can be simply transferred between users).
• At least one backup of a changed file is kept on the disk: the owner
(or disk administrator) may easily regress a change back to that
level.
• A history file detailing the changes to files is automatically
maintained on the disk, and an audit trail of all requests to the disk
is also kept.
• Authorization to access or update files on the disk may be restricted
to specific userids and/or nodes and/or filetypes.
Note that no attempt is made to prevent malicious changes by the real
owner of a file: only manual detailed inspection of changes could prevent
this. However the audit trail, histories, and other mechanisms provide
security sufficient for most environments.
This section explains how to use the TOOLS program, TOOLS EXEC, to send requests to a TOOLS service machine. The topics covered in this section are:
The TOOLS EXEC runs under the Conversational Monitor System (CMS) component of VM. It is a REXX EXEC that uses various facilities of CMS to prepare and submit requests to a virtual machine running TOOLSRUN. TOOLSRUN is the program (another REXX EXEC) that actually manages the files on disks. In effect, the syntax of the requests understood by TOOLSRUN is a command language. Any program that knows that command language interface can issue requests to TOOLSRUN; the TOOLS EXEC is just one example of such a program. TOOLS can be used as a menu-driven program (where you fill in fields on a display terminal to build up a request), or it may be used as a command driven program (where the request is made in the form of a one-line command like other CMS commands). In the command form, it can be used efficiently by other programs which provide a "front-end" that is tailored to a specific application. The command format may also be safely used by novices - if there is an error in the command, the menu will be used to prompt for the correct information. You may type in as much of the command as you wish, and if more details are required TOOLS will ask you for them.
Most people will wish to access more than one disk that is managed by TOOLSRUN. TOOLS therefore incorporates a mechanism for remembering the address of each disk that you use. You may choose your own nickname for a disk, which TOOLS will then associate with a particular disk. Nicknames may be up to eight characters long, and may if you wish be the same as the TOOLSRUN name of the disk. Before you can send any requests to a disk, you must first teach TOOLS the address to associate with your chosen nickname for the disk. To do this, just issue the command "TOOLS." You should be placed in a menu that looks like Figure 1. (If you get any error messages at this stage, or if the menu does not appear, ask your local support person for assistance.) If TOOLS has never been used on your userid, the nickname, diskname and diskid will all be TOOLS, and the disknode will be your node. Otherwise, some of the fields will be filled in with data from the last time TOOLS was used. ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ Please fill in fields as needed (TOOLS will prompt you... │ │ Press ENTER to send request, PF3 to quit, PF5 to... │ │ │ │ Disk/Conference ==>nickname(diskname disk managed by diskid at disknode) │ │ │ │ │ │ │ │ Request ==> ? Details: │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Any CMS command ==> │ │ │ │ PF1=Help PF3=Quit ENTER=Send request PF5=Send then quit PF6=Alter address │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ Figure 1. The initial TOOLS menu.nicknameis the disk nickname, often defaulting to TOOLS.disknameis the disk name, e.g. IBMVM.diskidanddisknodeare the userid and node of the TOOLSRUN service machine that manages the disk, e.g. TOOLS at KGNVMC. Near the top is an input field marked Disk/Conference. TheDisk/Conferenceinput field is used for nicknames: type your chosen nickname there (deleting any information already in the field if necessary), and press ENTER. If TOOLS was ever invoked on your userid for the nickname you specified, thenickname,diskidanddisknodewill change to the values last used for that nickname. Otherwise, TOOLS will check certain files that may have been provided at your installation (4) and may well find the name of the disk you want there. If it does, it will use the address found in the file. If it cannot find the name, it will assume some defaults. In either case, you will be presented with a new line on the menu that shows the address (diskname, userid, and node) that TOOLS will associate with your nickname. The menu now looks like Figure 2. ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ Please fill in fields as needed (TOOLS will prompt you... │ │ Press ENTER to send request, PF3 to quit, PF5 to... │ │ │ │ Disk/Conference ==>nickname│ │ │ │ Disk name ==>disknamemanaged bydiskidatdisknode│ │ │ │ Request ==> ? Details: │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ Please check that the address shown is correct for the disk │ │ nicknamednickname. If it is wrong, please change it now │ │ before proceeding. │ │ │ │ │ │ │ │ Any CMS command ==> │ │ │ │ PF1=Help PF3=Quit ENTER=Send request PF5=Send then quit PF6=Alter address │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ Figure 2. The TOOLS menu after changing the nickname.nicknameis the new nickname.disknameis the disk name associated withnickname.diskidanddisknodeare the userid and node of the TOOLSRUN service machine that manages the disk associated withnickname. If the address shown is incorrect, amend it as appropriate. Now either press PF3 to quit (if all you wanted to do was set up the address), or enter a request in the Request field if you want to send a request to the disk (as described in the next sections). You can also set up the address by using a command. The format for this is: TOOLS TO nickname DISK diskname userid AT node Here the nickname and the associated address are set directly by the command. Note: TOOLS uses GLOBALV to record the address information from call to call, so do not erase the file LASTING GLOBALV on your A-disk. (4) These are called "userid DISKS," "node DISKS," "TOOLS DISKS," or "OMNIDISK NAMES." The format of these index files is described in "Specifying disk nicknames" in topic B.8.
All requests can be sent to TOOLSRUN using either commands or the menu.
To use the menu, just type in "TOOLS." You will see a full screen menu
looking like Figure 1 in topic 2.2.
The fields on the menu should then be filled in as follows:
Disk/Conference
Include here the nickname of the disk to which you want to send
the request. This should have been set up as described in
"Addressing requests to a disk" in topic 2.2. To change the
address displayed by TOOLS, press PF6 to present for alteration
the three fields defining the address. This will present a menu
just like Figure 2 in topic 2.2.
Request
Type the keyword for the request here (e.g. "LIST"). If you
leave this field blank or "?," TOOLS will prompt you with a list
of common requests. The possible requests are described in
detail later in this document.
Details
This is used to give additional details for a request. For
example, the QUERY request can detail DISK, VERSION, INFORM, or
FILE to ask TOOLSRUN for different kinds of information.
Filename/Type
Many requests require that the filename and filetype of a file
be specified. The Filename/Type line is used to specify these
(and can also be used to specify the filemode, where
appropriate). For example, to get a file from a disk you
specify the request GET, and put the filename and filetype of
the file here.
Description
Certain requests (most of those that make a change to the disk)
require that a description of the change be provided. This
field (up to three lines) is used for the description for these
requests.
Once the menu has been completed as desired, you should press ENTER. At
this point TOOLS will check the information you entered, and will prompt
you if anything is missing or seems to be incorrect. If no problem is
found, the request will be sent to the TOOLSRUN machine and you will be
informed that the request has been sent. You can now either enter a new
request on the menu, or press PF3 to leave the menu. As an alternative to
pressing ENTER and then PF3 when you only have one request to send, you
can press PF5. If the request is valid, this will send the request and
quit from the menu, otherwise you will remain in the menu.
At the bottom of the menu, you will see a field marked Any CMS Command.
This field (two lines) may be used for entering CMS commands, just as
though they were entered from the normal CMS console. Typing a "?" here
will retrieve the last CMS command issued from the menu.
In many cases it can be more convenient to issue requests as commands
rather than through the menu (for example, from within FILELIST). If you
are logged on via a typewriter-style terminal then you have to use
commands because the menu will not be available. Many front-end (e.g.
OMNIDISK) and locally written tools issue TOOLSRUN requests by invoking
TOOLS commands, bypassing the menu.
The general syntax of a TOOLS command is:
┌────────────────────────────────────────────────────────────────────────┐
│ Figure 3. General syntax of a TOOLS command. │
├──────────┬─────────────────────────────────────────────────────────────┤
│ TOOLS │ <overrides> <request> <(description> │
└──────────┴─────────────────────────────────────────────────────────────┘
where the three optional parts are:
overrides Parameters that override the default action of the TOOLS
program. These are described in detail in "TOOLS Override
Verbs" in topic 6.0. One of the more useful overrides is the TO
nickname override, which specifies the nickname of a disk to
which the request is to be sent.
request The actual request to be sent to TOOLSRUN. The format of these
is described in "General TOOLS Request Verbs" in topic 4.0, and
"Privileged TOOLS Request Verbs" in topic 5.0. A summary of the
allowable requests is also included in Appendix A, "Summary of
TOOLS request and override verb formats" in topic A.0. All
requests consist of a keyword (the request verb), usually
followed by words naming a file and/or detailing the request.
description For those requests that require a description, you may include
the description on the command, separated from the request by a
left parenthesis. Alternatively, if a description is required
but none was supplied, TOOLS will prompt (on the console) for
one.
Here are some example TOOLS commands:
TOOLS ?
Displays the HELP for TOOLS. TOOLS ?? will do the same.
TOOLS TO IBMVM LIST * *
Sends a request to list all files on the disk nicknamed IBMVM.
TOOLS TO IBMVM GET TOOLS FORUM
Gets the file called TOOLS FORUM from the disk nicknamed IBMVM.
TOOLS TO IBMVM APPEND TOOLS FORUM
Appends your file called TOOLS APPEND to the file called TOOLS
FORUM on the disk nicknamed IBMVM.
TOOLS TO IBMVM CREATE CAVING FORUM (Forum for cavers
Sends the file called CAVING FORUM to the disk nicknamed IBMVM,
and gives it the description "Forum for cavers."
TOOLS TO IBMVM REPLACE CAVING FORUM (Update addresses
Sends the file called CAVING FORUM to the disk nicknamed IBMVM
to replace the copy already there, and describes the purpose of
the change.
TOOLS TO IBMVM QUERY DISK
Requests information about the disk nicknamed IBMVM.
Note: When you call TOOLS as a command, any responses are normally
displayed on the console. However, if called directly from XEDIT or LEXX
(possibly via an Exec or macro) then TOOLS will use the XEDIT or LEXX
"MSG" command for responses, where appropriate.
TOOLS request and override verb formats use the following syntax
notations:
1. Anything in uppercase and any parentheses must be typed exactly as
shown.
2. Many tokens are shown in mixed case: The first few characters are
uppercase and the rest are lowercase. The uppercase characters
represent the minimum acceptable abbreviation. Not all tokens may be
abbreviated - these will be shown in all upper case.
3. Anything that is all lowercase is variable - refer to the detailed
description following the format for what can be entered here.
4. Items enclosed in angle brackets (< > - "less than" and "greater
than") are optional. Do not type the angle brackets when entering one
of these items.
5. In a list of tokens that may appear in a variable field, the default
is highlighted (if there is a default).
6. Where applicable, the format is shown in both the command line form
and the TOOLS full screen menu form. Note that override verbs cannot
be entered on the TOOLS full screen menu.
7. Many requests use a date field. A brief description is included with
the verb description. A more detailed description of date fields used
by TOOLS may be found in "TOOLS date formats" in topic B.4.
8. Many requests use filename/filetype patterns. A brief description is
included with the verb description. A more detailed description of
filename/filetype patterns may be found in "TOOLS filename and
filetype patterns" in topic B.9.
┌────────────────────────────────────────────────────────────────────────┐
│ Figure 4. TOOLS command line syntax example │
├──────────┬─────────────────────────────────────────────────────────────┤
│ TOOLS │ <overrides> SET <ADDress> newaddr │
├──────────┼─────────────────────────────────────────────────────────────┤
│ TOOLS │ <overrides> SET <DEScription> fname ftype <fmode> (newdescr │
├──────────┼─────────────────────────────────────────────────────────────┤
│ TOOLS │ <overrides> SET <FILe> fname ftype <fmode> newfn newft │
├──────────┼─────────────────────────────────────────────────────────────┤
│ TOOLS │ <overrides> SET <MODe> fname ftype <fmode> newmode │
└──────────┴─────────────────────────────────────────────────────────────┘
This example shows the forms of the SET request verb.
TOOLS All command line descriptions begin with this. As shown, the
TOOLS EXEC will be invoked. However, you may have set up a
synonym for the TOOLS EXEC (see "Specifying disk nicknames" in
topic B.8) or you may be using a front-end or locally written
tool that sends TOOLSRUN commands by invoking TOOLS EXEC. In
this case, you would type in the synonym or the name of the
front-end or locally written EXEC.
SET The request verb. Note that there is no abbreviation allowed -
it must be typed exactly as shown.
<ADDress>
<DEScription>
<FILe>
<MODe> These are the options allowed for this request verb. If none of
these are specified, DESCRIPTION is the default. Each may be
abbreviated to as few as three characters.
<overrides> This is a special optional variable, and appears in all verb
descriptions. Overrides are described in more detail in "TOOLS
Override Verbs" in topic 6.0.
<fmode> This is an optional variable - it may be omitted. The things
that can go in this place are described in the text, along with
what will happen if you omit it (i.e. the default).
newaddr
fname
ftype
newfn
newft
newmode These are required variables - you must supply a token for each.
The things that go in these places are described in the text.
(newdescr This is a required variable - you must supply a description,
separated from the rest of the request tokens by a left
parenthesis.
These are the TOOLS request verbs that do not require PRIV or SYSTEM authority to issue:
Use the APPEND verb to place embedded data in an appendable file.
You must have at least APPENDER authority (plus the ADDER authority modifier if you are not the owner) to issue the APPEND verb.
Format of the APPEND verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> APPend fname ftype <fmode> <place> <(subject> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the APPEND verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> APPend Details: <place> │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> <subject> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required.
ftype The filetype of the file to be appended. This is required.
fmode The filemode of the file. This is optional. If omitted, the
default is "*" - all disks will be searched for the file "fname
APPEND."
All overrides are appropriate for the APPEND request.
A description is optional. If supplied, it will appear in the messages sent to users who have an INFORM matching the file to be appended. The description should be a brief description of the subject of the append.
place indicates where in the file the append is to be placed, and is
optional. It should be omitted for normal appends. If omitted,
the append will be embedded in the file in chronological order
with respect to other appends. The date and time used to
sequence the appends is the date and time they were originally
sent, not the time they were received at the master disk.
If specified, "place" must be one of the following:
date
date INSERT
date MODIFY
0
HEADER
where "date" is in append header form (HH:MM:SS on YY/MM/DD) or
TOOLSRUN standard form (YYYYMMDDHHMMSS).
The "place" detail field causes the append to be embedded at a
particular place in the file:
A value of 0 or HEADER causes the file header to be replaced.
A value of "date INSERT" causes the append to be embedded after
an append with the same or an earlier date and/or before an
append with a later date.
A value of "date MODIFY" must exactly match the date of an
append already embedded in the file, and will replace that
append.
A value of just "date" will be treated as MODIFY.
1. TOOLS will search for a file named "fname APPEND" to append to the
file "fname ftype."
2. Only the owner of the appendable file or a user with PRIV authority
for the disk may replace the file header or insert an append.
3. Only the owner of the appendable file, a user with PRIV authority for
the disk, or the owner of the append may modify an append. The owner
of the append is the person whose userid and node match the userid and
node in the append header inserted by TOOLSRUN. (If you make an
append on behalf of someone else, using the FOR override, both you and
that person may modify the append.)
4. The owner of a file may append to that file even though the file is
not publicly appendable (as long as the owner has at least APPENDER
authority). This is convenient in the case of a file that only one
user should update (e.g. an ANSWERS file) but which the viewers
perceive as an appendable file. Of course, careless use of this
feature (e.g. with an EXEC or MODULE) may cause the file to become
unusable.
5. The most common filetype for appendable files is "FORUM." Generally,
any file with a filetype of FORUM may be expected to be appendable.
(However, *you* may not be authorized to append to FORUMs on every
disk you find, even if you can GET the FORUM.)
Appendable files are by no means limited to filetypes of FORUM. The
owner of the disk makes filetypes publicly appendable by listing them
after the ONLY keyword on an ADDER control card. (See TOOLSRUN
Control File Language Reference.) Most appendable files will have a
note near the top to the effect that they are appendable. However,
the most reliable indicator is to look for append headers within the
file. These will look like:
----- fname ftype appended at time on date (by user at node)
"fname," "ftype," "time," "date," "user" and "node" are variable.
The leading dashes, the "appended at" and so on will always appear.
6. A PACKAGE file may never be appended.
For example, to append to FROG FORUM on the BLAH disk:
Command line example
TOOLS TO BLAH APPEND FROG FORUM
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> APPEND Details: │
│ │
│ Filename/Type ==> FROG FORUM * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS date formats" in topic B.4. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS filename and filetype patterns" in topic B.9.
Use the BATCH verb to: • determine what requests are held in the batch queue for you. • cancel one or more of your requests from the batch queue. • release some or all of the requests from the batch queue (PRIV only).
| You must have at least GETTER authority to issue BATCH QUERY, BATCH CANCEL | or BATCH RELEASE fnpat ftpat. | You must have PRIV authority for the disk to issue BATCH RELEASE (without | fnpat ftpat).
Formats of the BATCH verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> BATch CANCEL <fnpat ftpat> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> BATch QUERY │ ├──────────┼─────────────────────────────────────────────────────────────┤ | │ TOOLS │ <overrides> BATch RELEASE fnpat ftpat │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> BATch RELEASE <method> │ └──────────┴─────────────────────────────────────────────────────────────┘ Formats of the BATCH verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> BATch Details: CANCEL │ │ │ │ Filename/Type ==> <fnpat ftpat> * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> BATch Details: QUERY │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ | │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ | │ Request ==> BATch Details: RELEASE │ │ │ | │ Filename/Type ==> fnpat ftpat * │ │ │ | │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> BATch Details: RELEASE <method> │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat
| ftpat A filename and filetype pattern. This is ignored for BATCH
| QUERY. For BATCH CANCEL and BATCH RELEASE, if you specify
either fnpat or ftpat, you must specify both.
• For BATCH CANCEL, if fnpat and ftpat are omitted, all of
your requests are removed from the batch queue. (That is,
all requests that came from your userid and node, and
including any node that is equated to your node.)
| • For BATCH CANCEL, fnpat and ftpat are specified without
wildcard characters, all of your requests for that file are
removed from the batch queue (including requests from any
node that is equated to your node).
| • For BATCH CANCEL, fnpat and ftpat are specified with
wildcard characters, all of your requests that exactly
specified that pattern are removed from the batch queue
(including requests from any node that is equated to your
node).
| • For BATCH RELEASE, if fnpat and ftpat are specified, your
| batched request that specified that exact pattern is
| released. (This is for emergency use only, and might not be
| permitted for this disk. You will not be able to release
| your own request again for some period of time, as
| determined by the Toolsrun system administrators.)
All overrides are appropriate for the BATCH request, except:
NOCOPY
The description field is ignored.
method indicates the method of batching to be released. This is
optional for BATCH RELEASE and ignored for all other BATCH
types.
If specified, "method" must be one of the following:
GET
REFRESH
ALL
A value of "GET" causes all requests to be released, that were
GET requests without the COPY option. These are generally
requests that did not come from a TOOLSRUN machine.
A value of "REFRESH" causes all requests to be released, that
were GET requests with the COPY option. These are generally a
result of shadow TOOLSRUN machines doing refresh requests.
A value of "ALL" causes all requests to be released.
1. A BATCH QUERY command issued by a PRIV user will cause a report of the
entire contents of the batch queue to be generated. A BATCH QUERY
issued by a non-PRIV user will cause a listing of just that user's
files to be generated.
2. If the filename and filetype are omitted on a BATCH CANCEL request,
all of the submitting user's requests will be cancelled.
| 3. A BATCH RELEASE issued by a non-PRIV user FOR someone else is intended
| for emergency use only, and might not be permitted for this disk.
| Consequently, it counts the same as releasing for yourself; you will
| not be able to release again for yourself or anyone else for some
| period of time (as determined by the Toolsrun system administrators).
| 4. A BATCH RELEASE issued by a PRIV user, with the FOR override, will
release just the requests made by the user identified by the FOR
override.
For example, to see what requests you have in the batch queue for the BLAH
disk:
Command line example
TOOLS TO BLAH BATCH QUERY
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> BATCH Details: QUERY │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb GET" in topic 4.7. • "TOOLS PRIV Request Verb REFRESH" in topic 5.14. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS filename and filetype patterns" in topic B.9.
Use the CLEAN verb to erase discarded files from the disk, freeing up space.
You must have at least REPLACER authority to issue CLEAN SAFE. You must have PRIV authority for the disk to issue any other type of CLEAN request.
Format of the CLEAN verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> CLEan type <days> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the CLEAN verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> CLEan Details: type <days> │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the CLEAN request, except:
NOCOPY
The description field is ignored.
type Is required and must be one of:
| SAFE Remove erasable files older than the most recent
| system IPL.
| ERASABLE Remove all erasable files now.
| BACKUPSAFE Remove all erasable files older than the most recent
| system IPL. Convert backup files to erasable for
| later removal.
| BACKUP Remove all erasable and backup files now.
| ALLSAFE Remove all erasable files older than the most recent
| system IPL. Convert backup and hidden files to
| erasable for later removal.
| ALL Remove all erasable, backup and hidden files now.
NAMES Clean the disk NAMES file, resetting file statistics
and removing entries for nonexistent files. This form
of CLEAN should not ordinarily be needed. It is
intended for cases where the NAMES file is known to
have been damaged, for one reason or another.
days Preserve a file eligible for erasure for this many days. This
| is optional. If omitted, it defaults to zero. Note that
| discarded files created prior to a system IPL are never
| preserved - any CLEAN request will erase them.
| 1. Hidden, backup and erasable files are not generally visible to | Toolsrun users, but are kept on the disk to protect accessed users | from I/O errors. Automatic cleaning is often sufficient to prevent | the disk from filling up. However, a CLEAN SAFE request may be needed | if one or more large files have been replaced several times. Other | types of CLEAN requests should be avoided wherever possible, as the | effects on accessed users can be disastrous on older VM systems. (See | TOOLSRUN Control File Language Reference for more complete | descriptions of hidden, backup and erasable files, and automatic | cleaning.)
For example, to erase discarded files created prior to a system IPL:
Command line example
TOOLS TO BLAH CLEAN SAFE
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> CLEAN Details: SAFE │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS date formats" in topic B.4. • "TOOLS Override Verbs" in topic 6.0.
Use the CREATE verb to write a copy of a file to a disk where it does not already exist.
You must have at least OWNER authority to issue the CREATE verb for a file that you have not already been named the owner of (except for PACKAGE files). You must have at least PACKAGER authority to issue the CREATE verb for a PACKAGE file. You must have at least REPLACER authority to issue the CREATE verb for a file that you have already been named the owner of.
Format of the CREATE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> CREate fname ftype <fmode> (descr │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the CREATE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> CREate Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> descr │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required.
ftype The filetype of the file. This is required.
fmode The filemode of the file. This is optional. If omitted, the
default is "*" - all disks will be searched for the file.
Note that if "fmode" consists of both a filemode letter and a
filemode number, the file will be created with that filemode
number. Therefore, if you specify "A0" for the filemode, or if
you specify "*" and the file is found to have 0 for the filemode
number, the file will normally not be visible to users with
read-only links to the disk containing the file. (Normally, the
CREATE request will fail, though, because only PRIV users may
create mode zero files.)
All overrides are appropriate for the CREATE request, except:
PROPAGATE
descr Is the description of the file. It is required. This will
become the description in the disk NAMES file, and is the
description returned with LIST, QUERY FILE and SUMMARY requests.
This will also be included in the message sent to users who have
INFORMs and SUBSCRIBEs that match this file.
None.
1. If you are creating a file that you intend to be updated by the APPEND
request, it is a good idea to use filemode 6. Filemode 6 is the CMS
update-in-place filemode. Using it for appendable files helps avoid
problems associated with viewing them on a read/only disk while they
are being updated.
2. If TOOLSRUN adds one or more lines to the top of a file when you
create it, this means TOOLSRUN considers the file publicly appendable;
and the contents of a disk HEADER file were added. (However, this
usually happens only at the master disk.) Similarly, if the
notification you receive has the phrase "(and is publicly
appendable)," one or more lines may have been added to the top of the
file, at least at the master.
If a file is supposed to be publicly appendable and is not, or if it
is not supposed to be publicly appendable and is, get in touch with
the disk owner. The most likely cause is an ADDER authorization
without the ONLY keyword, or no ADDER authorization for that filetype.
(See TOOLSRUN Control File Language Reference.)
3. If you create a PACKAGE file, you are normally registered as the owner
of all files that it references, provided none of those files were
already owned by someone else.
In many cases, disks used as software repositories are set up so that
you cannot put any files on the disk until you have first created a
PACKAGE file that references the files you want to create. For these
disks, you should wait until you receive the DONE message, indicating
that the PACKAGE file has been created, before issuing CREATE requests
for the rest of the files. Or, use the NOCLOSE override to bundle the
rest of the CREATE requests with the CREATE of the PACKAGE. Or, use a
tool (such as PKGEDIT) that does this for you.
Even if the disk does not impose this restriction, it is always good
practice to create the PACKAGE file first.
4. You may use the SET request to: change the name, change the
description or change the mode number of a file that you have created.
5. You may use the NEWOWN request to transfer ownership of a file that
you have created. You may use the SET ADDRESS request to transfer
ownership of all files that you have created.
6. You may use the OWN request to reserve ownership of a file that you
are not quite ready to create. However, you should not normally have
to do this. If you never get around to creating the file, you have
cluttered up the disk NAMES file with an empty entry, thus slowing
system performance.
For example, to copy SUPER EXEC from your A-disk to the BLAH disk for the
first time:
Command line example
TOOLS TO BLAH CREATE SUPER EXEC A (DOES EVERYTHING
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> CREATE Details: │
│ │
│ Filename/Type ==> SUPER EXEC A │
│ │
│ Description ==> DOES EVERYTHING │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb NEWOWN" in topic 4.14. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS Request Verb OWN" in topic 4.16. • "Packages of files" in topic B.10. • "TOOLS Request Verb SET" in topic 4.25.
Use the DISK verb to set the disk name, and optionally the userid and node selected by the TO override or by the use of a synonym.
No authorization is required to use the DISK verb.
Format of the DISK verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> DISK name <userid <AT node>> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the DISK verb on the TOOLS full screen: The DISK request verb cannot be entered from the TOOLS full screen.
None.
All overrides are appropriate for the DISK request, except:
ANSWER
FOR
NOCOPY
NOCLOSE
NOPROMPT
PROPAGATE
SENDTO
TRACE
The description field is ignored.
name The disk name. This is required.
userid The userid of the TOOLSRUN service machine that manages "name."
This is optional. If omitted, the default is TOOLS.
node The node of the TOOLSRUN service machine that manages "name."
This is optional. If omitted, the default is the user's node.
1. Issuing the DISK request will affect all subsequent requests sent to
the disk currently selected by "name."
2. The DISK request does not, itself, cause a TOOLSRUN command to be sent
to the service machine. However, the information will be stored in
your LASTING GLOBALV file and used for all future requests sent to the
selected disk.
3. The SENDTO override is not really appropriate, but here's what will
happen:
• The information will be stored under the nickname "synonym" if
TOOLS was invoked with a synonym.
• The information will be stored under the nickname TOOLS if TOOLS
was not invoked with a synonym.
• If "node" is omitted, the node specified with SENDTO will be used.
• If "userid" is omitted, the userid specified with SENDTO will be
used.
For example, to select the BLAH disk by BLAHID at BLAHNODE:
Command line example
TOOLS DISK BLAH BLAHID AT BLAHNODE
TOOLS full screen example: The DISK request verb cannot be entered from
the TOOLS full screen.
• "TOOLS Override Verbs" in topic 6.0.
Use the ERASE verb to remove a file from a disk. The file will be removed from the disk NAMES file and discarded, along with its backup (if any).
You must have at least OWNER authority to issue the ERASE verb, except for PACKAGE files. You must have at least PACKAGER authority to issue the ERASE verb for PACKAGE files, or to implicitly erase other files by replacing a PACKAGE file.
Format of the ERASE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> ERAse fname ftype <fmode> (reason │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the ERASE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> ERAse Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> reason │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. fmode The filemode of the file. This is ignored.
All overrides are appropriate for the ERASE request, except:
PROPAGATE
reason Is a comment describing the reason the file is being erased. It
is required. This comment will appear in the messages sent to
persons with INFORMs or SUBSCRIBEs matching the file. It will
also appear in the appropriate HISTORY file.
None.
1. Only the owner of the file or a person with PRIV authority for the
disk may issue the ERASE request.
2. If you ERASE a PACKAGE file, files referenced by it may also be
affected, provided they are owned by you, and were not created before
being referenced by any PACKAGE file. If this is the last non-hidden
PACKAGE file to reference them, but a hidden or backup PACKAGE file
still references them, they will be hidden. Otherwise, if this is
truly the last PACKAGE file to reference them, they will also be
erased.
3. If you ERASE a VOTE file, the associated VOTERS file will also be
erased.
4. Unless OPTION UNSAFE (see TOOLSRUN Control File Language Reference) is
in effect for the disk, a file is not actually discarded when it is
erased. Instead, it is renamed to an ERASABLE filetype and discarded
during a CLEAN operation, sometime later. If you need to recover a
file that was accidentally erased, a PRIV user for the disk can find
out the name of the ERASABLE file from the disk AUDIT file. However,
you must link to the disk to copy the file.
For example, to erase OLD EXEC from the BLAH disk:
Command line example
TOOLS TO BLAH ERASE OLD EXEC (GOODBYE
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> ERASE Details: │
│ │
│ Filename/Type ==> OLD EXEC * │
│ │
│ Description ==> GOODBYE │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10.
Use the GET verb to retrieve copies of one or more files from a disk.
You must have at least GETTER authority to issue the GET verb. You must have PRIV authority for the disk to issue GET disk AUDIT, or to issue GET for a mode zero file.
Format of the GET verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> GET fnpat ftpat <fmode> <COPY> <date> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the GET verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> GET Details: <COPY> <date> │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. If "*" is specified for
the filename pattern, "date" must be specified.
ftpat A filetype pattern. This is required.
fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the GET request, except:
NOCOPY
The description field is ignored.
COPY Indicates that the file(s) are to be sent in TOOLS format.
Files sent in TOOLS format are intended to be processed by a
TOOLSRUN service machine. Therefore, this option should only be
used when the GET request is being sent by a TOOLSRUN service
machine.
date A date or header specification. This is optional, unless "*" is
specified for the filename pattern. The date must be expressed
in one of the following forms:
date
SINCE date
0
HEADER
where "date" is append header form (HH:MM:SS on YY/MM/DD) or
TOOLSRUN standard form (YYYYMMDDHHMMSS).
"date" has no effect if the COPY option is specified. The
effect depends on whether a pattern or a specific file was
specified, and the characteristics of the matching file. If
"date" is specified, and the file is:
• appendable, only a portion of the file will be sent - the
part containing appends created on or after the date.
• an AUDIT, HISTORY or REQUESTS file, only a portion of the
file will be sent - the part containing entries on or after
the date.
• a PACKAGE file (and no pattern was specified), the date will
be ignored for the PACKAGE file itself, but will apply to
any referenced files.
For any other file, the file will be sent only if it was created
or last updated on or after the specified date.
If "0" or "HEADER" is specified, only the header portion of
appendable files will be retrieved.
1. Most conference disks limit the number of files that you can GET with
a single request. If you specify a pattern for the filename, filetype
or both, you may receive a message telling you that you have requested
too many files. Use the LIST or SUMMARY request to find out which
files on the disk match the pattern, and request the ones you really
want individually.
2. Files with a filetype of "PACKAGE" are a special case. These files
contain a list of other files, along with descriptive comments.
If you GET a PACKAGE file, you will receive not only the PACKAGE file
itself, but also all of the files referenced by the PACKAGE file.
Pay attention to the comments in the PACKAGE file. Usually, there
will be information about the owner, maintainer and backup contact for
the package (in case you have questions or problems), and information
about the use of the collection of files. Most importantly, there may
be instructions on how to install the files: Some may need to be
renamed, some may need to be unpacked with TERSE (or some other
unpacking tool), and so on.
If you want just the PACKAGE file itself, and none of the referenced
files, specify a pattern of PACKAGE* for the filetype.
If you GET a PACKAGE, this fact is usually logged in a REQUESTS file.
This allows the owner of the package to gather statistics about the
popularity of the package (perhaps to justify the amount of time spent
developing and maintaining it) and to contact you directly if some
need arises. (See also REGISTER.)
3. The COPY option of GET is usually used in conjunction with the COPY
option of INFORM to set up and maintain a partial shadow. This is a
disk that contains copies of only some of the files maintained on the
master disk. Another use for GET COPY and INFORM COPY is to set up
and maintain an appendable file shared between two conference masters.
This is called a "shared forum." (See "Partial Shadows and Shared
Forums" in topic B.12 for more information.)
4. A user with PRIV authority for the maintained disk may use GET to
request the disk AUDIT file from the TOOLSRUN service machine's
A-disk.
5. GET batching may be in effect for the disk. If this is so, your GET
request will be held in a batch queue, to be released some time later.
The response you get from Toolsrun will tell you that this has
happened.
You may check the queue (using BATCH QUERY) and you may cancel some or
| all of your batched requests (using BATCH CANCEL). In an emergency,
| you might be able to release your own request (using BATCH RELEASE).
| However, you are prevented from doing this very often.
| These requests are never batched:
| • Requests from PRIV users.
| • Local requests (from the same node as the Toolsrun machine, or as
| determined by Toolsrun to be on the same complex, or as defined by
| the Toolsrun administrator, using NEARBY and EQUATE NODE.)
| • Files whose filename is the same as the disk name.
| • Files whose filetype is HISTORY or REQUESTS.
| • Requests with a since date.
For example, to get all MODULE files ending with M01:
Command line example
TOOLS TO BLAH GET *M01 MODULE
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> GET Details: │
│ │
│ Filename/Type ==> *M01 MODULE * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb BATCH" in topic 4.2. • "TOOLS date formats" in topic B.4. • "TOOLS Request Verb LIST" in topic 4.11. • "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10. • "Partial Shadows and Shared Forums" in topic B.12. • "TOOLS filename and filetype patterns" in topic B.9. • "TOOLS Request Verb REGISTER" in topic 4.20. • "TOOLS Request Verb SUMMARY" in topic 4.27.
Use the HELP verb to request information about one disk or all disks maintained by a TOOLSRUN service machine.
No authorization is required to issue the HELP verb.
Format of the HELP verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> HELp <ALL> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the HELP verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> HELp Details: <ALL> │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the HELP request, except:
NOCOPY
The description field is ignored.
ALL Indicates that help is requested for all disks maintained by the
TOOLSRUN service machine. This is optional. If omitted, HELP
is requested only for the disk to which the request is directed.
1. Not all disks have help information, and the amount of information
available is up to the disk maintainer.
2. If there is no disk at the service machine with the name that you have
specified, you will receive ALL help.
For example, to get information about the BLAH disk:
Command line example
TOOLS TO BLAH HELP
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> HELP Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Use the HIDE verb to make a file invisible to all non-PRIV ToolsRun access, and to users who subsequently ACCESS the disk in read/only mode. Any existing backup file is discarded and the current file becomes the backup file.
You must have at least REPLACER authority to issue the HIDE verb.
Format of the HIDE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> HIDe fname ftype <fmode> (reason │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the HIDE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> HIDe Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> reason │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. fmode The filemode of the file. This is ignored.
All overrides are appropriate for the HIDE request, except:
PROPAGATE
reason Is a comment describing the reason the file is being hidden. It
is required. This comment will appear in the messages sent to
persons with INFORMs or SUBSCRIBEs matching the file. It will
also appear in the appropriate HISTORY file.
None.
1. Only the owner of the file or a user with PRIV authority for the disk
may issue the HIDE request.
2. Use the REGRESS request to make the file visible again.
3. If you HIDE a PACKAGE file, files referenced by it may also be
affected, provided they are owned by you, and were not created before
being referenced by any PACKAGE file. If this is the last non-hidden
PACKAGE file to reference them, they will also be hidden.
For example, to hide BROKEN EXEC:
Command line example
TOOLS TO BLAH HIDE BROKEN EXEC (IT DONT WORK
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> HIDE Details: │
│ │
│ Filename/Type ==> BROKEN EXEC * │
│ │
│ Description ==> IT DONT WORK │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10. • "TOOLS Request Verb REGRESS" in topic 4.21.
Use the INFORM verb to receive notification of changes to existing files or creation of new files.
You must have at least GETTER authority to issue the INFORM verb. In addition, INFORM and SUBSCRIBE must be explicitly activated for the disk.
Format of the INFORM verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> INForm fnpat ftpat <fmode> <infotype> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the INFORM verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> INForm Details: <infotype> │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. ftpat A filetype pattern. This is required. fmode The filemode field is ignored.
All overrides are appropriate for the INFORM request, except:
NOCOPY
A description is not required.
infotype The type of notification desired. This is optional. If
omitted, the default is "ALL." The types of notification are:
ALL You will receive a message each time that a file
matching "fnpat ftpat" is created or changed.
NEW You will receive a message each time that a file
matching "fnpat ftpat" is created.
SUBscribe You will receive a copy of the whole file (or just the
append if the file is appendable) each time that a
file matching "fnpat ftpat" is created or changed.
You will also receive a message containing the reason
for the change (as supplied by the person who made
it), unless the change was an append. It is often
important to know why a file was changed, so that one
can make an informed decision as to what to do with
the updated file. It is therefore important that
people submitting updates supply meaningful change
descriptions.
COPy Similar to SUBSCRIBE, except that you receive a copy
of the actual TOOLS request that was submitted to
update the file. INFORM COPY is intended to be used
from a TOOLSRUN service machine for the purpose of
maintaining a partial shadow of a master disk or
sharing a forum between two conferences.
EXClude This is a request to limit a more liberal INFORM that
you previously made. You will not receive
notification of changes or creations of files matching
"fnpat ftpat."
REFerence You will receive a copy of any append that references
your node and userid. Typically, this would mean an
append that references some append that you made, or
that was made on your behalf. Specifically, this
means any append that contains a line in either of the
following forms:
REF: ... (BY userid AT node)
REF: ... (BY ... FOR userid AT node)
This is experimental and subject to change or removal
at any time.
UPDate You will receive a copy of the whole file (or just the
append) but no message describing the change.
This is experimental and subject to change or removal
at any time.
1. The UNINFORM request may be used to discontinue your INFORM.
2. The SET ADDRESS request may be used to instruct the service machine to
redirect your INFORMS to a new userid, new node or both.
3. INFORM COPY may be used to maintain a partial shadow or set up a
shared forum. If you issue INFORM COPY from the service machine that
maintains the shadow disk, it will receive and process all changes
made at the master disk that match "fnpat ftpat." (See "Partial
Shadows and Shared Forums" in topic B.12 for more information.)
4. Use INFORM EXCLUDE to avoid notification of changes to certain files
that fall within the pattern you specified with another type of
INFORM. For example, you may have issued INFORM * EXEC to receive
notification of changes to all EXEC files on the disk, but do not wish
to be notified of changes to PANDA EXEC, PANDACALC EXEC etcetera.
Issue INFORM PANDA* EXEC EXCLUDE.
To temporarily shut off all of your informs for a disk (for example,
when going on vacation), issue INFORM * * EXCLUDE. When you wish to
resume receiving informs, issue UNINFORM * *.
5. If you INFORM on a PACKAGE file, you will be notified of any changes
to the files that it references, as well as to the PACKAGE file
itself. However, if any of those files are also PACKAGE files, you
will not be notified of changes to the files that they reference.
6. If you use a pattern for INFORM that includes any PACKAGE files, you
will receive notification of changes only for the PACKAGE files
themselves, not for their contents.
7. You may have only one "fnpat ftpat" in effect at a time. For example,
if you had INFORM * * NEW in effect, and used INFORM * * EXCLUDE to
temporarily suppress your informs, the INFORM * * NEW is not just
suppressed - it is cancelled. (This is noted in the response from the
ToolsRun service machine.) If you make note of this, you can resume
all of your other informs and restore this one by issuing INFORM * *
NEW, replacing the exclusion.
8. Use QUERY INFORM to find out what patterns and types of informs are in
effect for you at a disk, and when they will expire. The response to
an INFORM request will also indicate when the new inform will expire
| (if this is your first INFORM for the disk).
9. A TOOLSRUN service machine can consume significant CPU and network
resources sending change notifications for a very active disk. As
such, INFORM and SUBSCRIBE support must be explicitly activated for
the disk before INFORM and SUBSCRIBE requests will be accepted,
regardless of whether you have sufficient authority. (QUERY DISK may
be used to find out if INFORM and SUBSCRIBE are supported.)
10. Subscription expiration is likely to be in effect for any disk at
which you have informs and subscribes. All of your informs will
expire after a period of time determined by the disk administrator.
Before they expire, you will receive one notice, explaining:
• that your subscriptions are about to expire
• what subscriptions you have in effect
• how to renew your subscriptions
• how to delete unwanted subscriptions
• how to change your address
Note that a "subscription" is any kind of INFORM, except INFORM COPY.
If you take no action after receiving the notice, all of your
subscriptions for that disk will be deleted. You will receive a
notice listing the deleted subscriptions, and how to reinstate them.
Use the RENEW request to renew your subscriptions. Note that you may
receive more than one notice from the same disk, sent to your userid
at different nodes, or sent to an old node and userid and forwarded to
you. You may use SET ADDRESS to change all of your addresses to a
single node and userid. After you do that, a single RENEW request,
sent to that disk, will renew all of your subscriptions on that disk.
For example, to receive notification every time FOOBAR EXEC is changed:
Command line example
TOOLS TO BLAH INFORM FOOBAR EXEC
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> INFORM Details: │
│ │
│ Filename/Type ==> FOOBAR EXEC * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10. • "TOOLS filename and filetype patterns" in topic B.9. • "TOOLS Request Verb QUERY" in topic 4.19. • "TOOLS Request Verb SET" in topic 4.25. • "TOOLS Request Verb RENEW" in topic 4.22. • "TOOLS Request Verb UNINFORM" in topic 4.28. • "How to UnInform/UnSubscribe" in topic B.11. • "Partial Shadows and Shared Forums" in topic B.12.
Use the LIST verb to get a list of files on the disk, including the size of each file and the date it was created or last changed. The description of the file (from the disk NAMES file) is also included.
You must have at least GETTER authority to issue the LIST verb, and the list you get back will contain only those files you are authorized to GET.
Format of the LIST verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> LISt fnpat ftpat <fmode> <COPY> <date> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the LIST verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> LISt Details: <COPY> <date> │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. ftpat A filetype pattern. This is required. fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the LIST request, except:
NOCOPY
The description field is ignored.
COPY Indicates that the file containing the list is to be sent in
TOOLS format. Files sent in TOOLS format are intended to be
processed by a TOOLSRUN service machine. Therefore, this option
should only be used when the LIST request is being sent by a
TOOLSRUN service machine.
date A date in append header form (HH:MM:SS on YY/MM/DD) or TOOLSRUN
standard form (YYYYMMDDHHMMSS), optionally preceded by SINCE.
This is optional. If specified, only files changed on or after
this date will be listed.
1. COPY form may be used to maintain lists of the contents of other disks
on a conference disk. This may be useful if there are no local
shadows of those disks.
2. The SUMMARY request verb will also return a list of the files on a
disk. The differences between LIST and SUMMARY are that LIST returns
information about the size and change date and SUMMARY returns
information about the owner of the file.
For example, to list all of the files on the BLAH disk:
Command line example
TOOLS TO BLAH LIST * *
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> LIST Details: │
│ │
│ Filename/Type ==> * * * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS date formats" in topic B.4. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS filename and filetype patterns" in topic B.9. • "TOOLS Request Verb SUMMARY" in topic 4.27.
Use the LITERAL verb to issue a TOOLS verb directly, without checking or formatting by the TOOLS EXEC.
Depends on the authority required for the TOOLS verb.
Format of the LITERAL verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> LITeral cmd (descr │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the LITERAL verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> LITeral Details: cmd │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> descr │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the LITERAL request.
descr Is the descriptive comment associated with the TOOLS verb, if
any.
cmd Is the TOOLS verb, and all of its parameters.
1. The LITERAL request may be used to issue TOOLS verbs that are not
currently supported by the TOOLS EXEC version that is available to
you.
This may include certain forms of commands that are not commonly used,
such as GET ASIS.
2. The LITERAL request may be used to issue commands to a modified
TOOLSRUN service machine. Either the TOOLSRUN software, or one of the
exit execs called by TOOLSRUN may recognize the command, but the
production version of TOOLSRUN will not.
3. You must supply all the parameters expected by TOOLSRUN. This means:
• The general form is:
command fileid details
• Abbreviations are not allowed.
• Dates must be in TOOLSRUN standard form:
YYYYMMDD<HH<MM<SS>>>
• For commands that return data, you must specify the method by
which the data is to be sent:
NETDATA
ASIS
COPY
• Addresses must be in the form:
node userid
• Synonyms are not recognized. For example, SUBSCRIBE is a synonym
for INFORM SUBSCRIBE and UNSUBSCRIBE is a synonym for UNINFORM.
4. If data is to accompany the command, you must use the NOCLOSE
override, and issue CMS commands to punch the data following the
command.
For example, to issue the HOOHAH verb, not currently supported by the
TOOLS EXEC:
Command line example
TOOLS TO BLAH LITERAL HOOHAH
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> LITERAL Details: HOOHAH │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Use the LOCK verb to prevent updates to a file until it is UNLOCKed.
You must have at least REPLACER authority to issue the LOCK verb.
Format of the LOCK verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> LOCk fname ftype <fmode> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the LOCK verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> LOCk Details: │ │ │ │ Filename/Type ==> fname ftype <fmode.> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. | fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the LOCK request, except:
PROPAGATE
The description field is ignored.
None.
1. Only the owner of the file, or a user with PRIV authority for the disk
may LOCK a file.
2. The file is unlocked with the UNLOCK request, or a REPLACE or PLACE by
the LOCK issuer.
3. LOCK will, in general, inhibit any appends, replaces or updates to the
file, except by the LOCK issuer. (A person with PRIV authority for
the disk may explicitly UNLOCK the file.) This makes it useful to:
• Prevent "lost appends" prior to issuing a PLACE or REPLACE request
for an appendable file. PLACE and REPLACE will automatically
UNLOCK the file.
• Shut down a FORUM (or other appendable file) when the FORUM has
outlived its purpose, is being replaced with another FORUM,
etcetera. The FORUM is left on the disk for awhile, but is no
longer open to new appends.
• Prevent collisions when a file has multiple owners (e.g. the owner
userid has been set to "*"). A person wishing to update the file
will first issue a LOCK request. If that succeeds, the file may
be safely updated and then unlocked. If it fails, someone else
has already issued a LOCK. The requestor should then wait until
the file is unlocked, get a fresh copy of it (to incorporate
changes), and try again.
• LOCK is occasionally needed by FORUM owners in the unfortunate
(but rare) circumstance when appenders persist in violating the
FORUM or disk rules. After a "cooling off" period, the FORUM is
usually unlocked.
4. The LOCK request is experimental and subject to change or deletion in
the future.
For example, to lock the UNRULY FORUM on the BLAH disk:
Command line example
TOOLS TO BLAH LOCK UNRULY FORUM
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> LOCK Details: │
│ │
│ Filename/Type ==> UNRULY FORUM * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "TOOLS PRIV Request Verb PLACE" in topic 5.11. • "TOOLS Request Verb REPLACE" in topic 4.23. • "TOOLS Request Verb UNLOCK" in topic 4.29.
Use the NEWOWN verb to transfer ownership of your file to another person.
You must have at least REPLACER authority to issue the NEWOWN verb.
Format of the NEWOWN verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> NEWown fname ftype <fmode> newaddr │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the NEWOWN verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> NEWown Details: newaddr │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. fmode The fmode field is ignored.
All overrides are appropriate for the NEWOWN request, except:
PROPAGATE
The description field is ignored.
newaddr is the userid and node of the new owner. It is required.
"newaddr" must be one of the following forms:
newuserid
newnode newuserid
newuserid AT newnode
If "newnode" is not specified, it will default to the name of
the node from which the NEWOWN request was issued.
You may specify an asterisk (*) for "newuserid," "newnode" or
both. For "newuserid," an asterisk means that everyone at
"newnode" has ownership of the file and may update it. For
"newnode," an asterisk means that everyone with the userid
"newuserid" has ownership of the file. If both fields are coded
as asterisks, anyone from anywhere can update the file.
1. You may issue the NEWOWN request only for files that you own, or for
any file if you have PRIV authority for the disk. You have ownership
of all files:
• that you CREATEd, or
• for which you issued the OWN request, or
• for which someone else has issued the NEWOWN request, specifying
you as the new owner, or
• that were not previously owned by anyone and are newly referenced
by a PACKAGE file that you CREATEd or REPLACEd.
2. NEWOWN may be used to simulate multiple ownership of a file. If the
"newuserid" is set to "*," more than one person has ownership of the
file.
For example, to transfer ownership of FROG EXEC to CHARLEY at RIVERTOP:
Command line example
TOOLS TO BLAH NEWOWN FROG EXEC CHARLEY AT RIVERTOP
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> NEWOWN Details: CHARLEY AT RIVERTOP │
│ │
│ Filename/Type ==> FROG EXEC * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb CREATE" in topic 4.4. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS Request Verb OWN" in topic 4.16.
Use the NOTIFY verb to send a message to the disk administrator(s) or the TOOLSRUN service machine system administrator.
No authorization is required to issue the NOTIFY verb.
Format of the NOTIFY verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> NOTify <ALL> (msgtext │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the NOTIFY verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> NOTify Details: <ALL> │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> msgtext │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the NOTIFY request, except:
NOCOPY
msgtext The text of the message.
ALL The message will be sent to the SYSTEM users of the TOOLSRUN
Service Machine.
This is optional. If omitted, the message will be sent to the
administrator of the specified disk.
1. The message will be sent to the disk administrator(s) if a disk name
is specified, the ALL option is omitted, and the specified disk is one
that is maintained by the TOOLSRUN Service Machine. Otherwise, it
will be sent to the system administrator(s). See the SENDTO override.
For example, to send a message to the BLAH disk administrator:
Command line example
TOOLS TO BLAH NOTIFY (PLEASE HELP - I HAVE MESSED UP MY ADDRESS
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> NOTIFY Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> PLEASE HELP - I HAVE MESSED UP MY ADDRESS │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Use the OWN verb to claim ownership of a file that is not currently owned by anyone else, or to reserve ownership of a file that does not yet exist.
You must have at least OWNER authority to issue the OWN verb. You must have at least PACKAGER authority to own a file by referencing it in a newly created or replaced PACKAGE file.
Format of the OWN verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> OWN fname ftype <fmode> (descr │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the OWN verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> OWN Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> descr │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. fmode The filemode of the file. This is ignored.
All overrides are appropriate for the OWN request, except:
PROPAGATE
descr Is the description of the file. It is required. This will
become the description in the disk NAMES file, and is the
description returned with LIST and SUMMARY requests.
None.
1. The OWN request makes you the owner of a filename which may not be
created by anyone else, except someone with PRIV authority for the
disk (and even then, you are notified).
2. The OWN request is also used to establish ownership of files that
exist on a disk prior to being placed under TOOLSRUN's control.
3. When you CREATE a PACKAGE file, all unowned files that it references
cause OWN requests to be issued on your behalf. Also, if you REPLACE
a PACKAGE file with new file references in it, all unowned files will
cause OWN requests to be issued on your behalf.
4. You may use the OWN request to reserve ownership of a file that you
are not quite ready to create. However, you should not normally have
to do this. If you never get around to creating the file, you have
cluttered up the disk NAMES file with an empty entry, thus slowing
system performance.
5. The ERASE request may be used to cancel ownership of a file, even if
the file has not been created.
For example, to reserve the GOLDEN EXEC on the BLAH disk:
Command line example
TOOLS TO BLAH OWN GOLDEN EXEC (THE BEST
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> OWN Details: │
│ │
│ Filename/Type ==> GOLDEN EXEC * │
│ │
│ Description ==> THE BEST │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb CREATE" in topic 4.4. • "TOOLS Request Verb ERASE" in topic 4.6. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS Request Verb REPLACE" in topic 4.23.
Use the PRUNE verb to remove old data from an appendable file and optionally send it to you.
You must have at least REPLACER authority to issue the PRUNE verb.
Format of the PRUNE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> PRUne fname ftype <fmode> before <disp> (reason │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the PRUNE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> PRUNE Details: before <disp> │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> reason │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. fmode The filemode of the file. This is ignored.
All overrides are appropriate for the PRUNE request, except:
PROPAGATE
reason Is a comment describing the reason the file is being pruned.
This will be included in messages sent to users with INFORMs and
SUBSCRIBEs for the file. It will also be logged in the disk
HISTORY file.
before Is the cutoff date for the prune. Entries prior to this date
| will be removed (except for the file header). The date must be
in append header form (HH:MM:SS on YY/MM/DD) or TOOLSRUN
standard form (YYYYMMDDHHMMSS).
disp Is the disposition of the removed data. This is optional. If
omitted, the default is RETURN. "disp" must be:
| DISCARD Discard the removed data. Warning: The data is not
| recoverable. No copy will remain anywhere if this
| option is specified, unless you have already saved it
| yourself.
RETURN Return the removed data to the requestor.
1. Only the owner of the file, or a person with PRIV authority for the
disk, may issue the PRUNE request.
2. When the owner prunes a file, and the data is considered to have
value, it is common practice to place the pruned data on the disk in a
file named "fname OLDnnnnn" or "fname PRnnnnn" for awhile, where
"nnnnn" is some number, the year of the prune, etcetera. This allows
users to refer to earlier appends that are now no longer in the
current file, or to make a copy of the data for themselves. After
some time, this prune data file should be erased to free up space on
the disk. It may be stored on an archive disk, if one is provided for
the main disk, or stored by the file owner.
| 3. Note that, unless you have already made a copy of the pruned data, the
| only copy that exists after pruning is the copy that is returned to
| you. It is not automatically archived anywhere. It is not even kept
| as an erasable file, because a common reason for pruning is a full
| disk.
For example, to prune the BIG FORUM and receive the removed appends:
Command line example
TOOLS TO BLAH PRUNE BIG FORUM (GOT TOO BIG
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> PRUNE Details: │
│ │
│ Filename/Type ==> BIG FORUM * │
│ │
│ Description ==> GOT TOO BIG │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS date formats" in topic B.4. • "TOOLS Override Verbs" in topic 6.0.
Use the PUNCHTAG verb to cause additional information to be added to the tag for all subsequent files sent to the selected disk.
No authorization is required to use the PUNCHTAG verb.
Format of the PUNCHTAG verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> PUNchtag <taginfo> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the PUNCHTAG verb on the TOOLS full screen: The PUNCHTAG request verb cannot be entered from the TOOLS full screen.
None.
All overrides are appropriate for the PUNCHTAG request, except:
ANSWER
FOR
NOCOPY
NOCLOSE
NOPROMPT
PROPAGATE
SENDTO
TRACE
The description field is ignored.
taginfo The information to be added to the standard tag for all requests
sent by TOOLS. This is optional. If omitted, the previous tag
information is deleted. No checking of the information is done
by the TOOLS exec - it is assumed that you know what you are
doing.
The standard tag information supplied by the TOOLS exec for
requests being sent to another node is:
tonode touser 30 w=touser
where "tonode touser" are the node and userid of the TOOLSRUN
service machine and "30" is the priority of the request.
You cannot alter this standard tag information via the PUNCHTAG
request.
Information to be added via the PUNCHTAG request is appended to
the standard information with a left parenthesis inserted:
tonode touser 30 w=touser (taginfo
The resultant tag information must be acceptable to all of the
RSCS (VNET) nodes that the request will pass through.
1. Issuing the PUNCHTAG request will affect all subsequent requests sent
to the disk currently selected by nickname. However, files sent from
the TOOLSRUN machine which are not in direct response to a request
(e.g. INFORM and SUBSCRIBE files) will not be affected by the user
PUNCHTAG setting.
2. The PUNCHTAG request does not, itself, cause a TOOLSRUN command to be
sent to the service machine. However, the information will be stored
in your LASTING GLOBALV file and used for all future requests sent to
the selected disk.
3. The "taginfo" will be added to the tag only for requests being sent to
a service machine that is not on your node.
4. The PUNCHTAG request may be used to control the RSCS "progress"
messages that you receive. The following list is not exhaustive, but
represents reasonable PUNCHTAG settings. (There is no point in
causing extra messages to be sent to the TOOLSRUN service machine):
ENQ=Y Causes the first node in the network to send a message to
the originator when it has sent the request file to the next
node.
ENQ=N Suppresses the message from the first node.
SE=O Causes each intermediate node in the network to send a
message as the request file passes through.
SE=N Suppresses the messages sent by intermediate nodes.
FIN=O Causes the last node in the network to send a message to the
originator when it has sent the request file to the service
machine.
FIN=N Suppresses the message from the last node.
5. The SENDTO override is not really appropriate, but here's what will
happen:
• The information will be stored under the nickname "synonym" if
TOOLS was invoked with a synonym.
• The information will be stored under the nickname TOOLS if TOOLS
was not invoked with a synonym.
For example, to specify that you do not want to receive a message when a
request file is delivered to the service machine by the network:
Command line example
TOOLS TO BLAH PUNCHTAG FIN=N
TOOLS full screen example: The PUNCHTAG request verb cannot be entered
from the TOOLS full screen.
• "TOOLS Override Verbs" in topic 6.0.
Use the QUERY verb to request:
• information about a particular disk,
• information about a particular file on a disk,
• the INFORMs and SUBSCRIBEs in effect for you at the disk (and when
they will expire),
• the list of users who have INFORMs in effect for a particular file or
• the TOOLSRUN version, number of disks maintained and system contact
for a service machine.
Persons who have SYSTEM authority for the service machine may also use the
QUERY verb to request information about the service machine or usage
statistics about each disk.
No authorization is required to issue QUERY VERSION. You must have at least GETTER authority to issue QUERY DISK, QUERY FILE or QUERY INFORM. You must have SYSTEM authority at the service machine to issue QUERY SYSTEM or QUERY USAGE.
Formats of the QUERY verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> QUEry DISK │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry <FILE> fname ftype <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry INFORM <fname ftype <fmode> > │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry SYSTEM │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry USAGE │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry VERSION │ └──────────┴─────────────────────────────────────────────────────────────┘ Formats of the QUERY verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> QUEry Details: DISK │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> QUEry Details: <FILE> │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> QUEry Details: INFORM │ │ │ │ Filename/Type ==> <fname ftype <fmode> > │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> QUEry Details: SYSTEM │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> QUEry Details: USAGE │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> QUEry Details: VERSION │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required for QUERY FILE.
This is optional for QUERY INFORM. This should be omitted for
all other QUERY types.
ftype The filetype of the file. This is required for QUERY FILE.
This is optional for QUERY INFORM. This should be omitted for
all other QUERY types.
fmode A filemode may be specified for QUERY FILE or QUERY INFORM, but
will be ignored.
All overrides are appropriate for the QUERY request, except:
NOCOPY
The description field is ignored.
The type of query. If omitted, it defaults to QUERY FILE. The QUERY
types are:
QUERY DISK returns information about the disk, including disk address,
space, help text, number of shadows, whether INFORM (and
SUBSCRIBE) is enabled (and whether subscription expiration is in
effect), whether GET batching is in effect, the number of
primary shadows, whether TOOLCARE is installed and usage data.
QUERY FILE returns information about the file, including the owner
description, size of file, file date, change date, existence of
a backup file and what package(s) include this file. "fname
ftype" is required.
QUERY INFORM without a filename and filetype returns a list of all INFORMs
and SUBSCRIBEs in effect for you at the disk, and when they will
expire.
QUERY INFORM with a filename and filetype returns a list of the people who
have INFORMs and SUBSCRIBEs in effect for the file at this disk.
QUERY SYSTEM returns CPU information, GMT offset, CP and CMS level,
storage data, any permanently shut down disks, A-disk space and
number of deferred and failed requests.
QUERY USAGE returns usage statistics for each disk maintained by the
service machine.
QUERY VERSION returns the version and level of the TOOLSRUN software
running on the service machine, the number of disks maintained
and the name of the system contact.
1. SYSTEM requests may not be mixed with non-SYSTEM requests in the same
deck. (See the NOCLOSE override.)
For example, to find out what INFORMs and SUBSCRIBEs you have in effect at
the BLAH disk:
Command line example
TOOLS TO BLAH QUERY INFORM
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> QUERY Details: INFORM │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10.
Use the REGISTER verb to record the fact that you have obtained one or more copies of a PACKAGE by some means other than a GET request.
You must have at least GETTER authority to issue the REGISTER verb.
Format of the REGISTER verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> REGIster fname <copies> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the REGISTER verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> REGIster Details: <copies> │ │ │ │ Filename/Type ==> fname <ftype> <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the PACKAGE file. This is required.
ftype The filetype of the file. This is optional for the TOOLS full
screen invocation only, and is ignored.
fmode The filemode of the file. This is optional for the TOOLS full
screen invocation only, and is ignored.
All overrides are appropriate for the REGISTER request, except:
NOCOPY
The description field is ignored.
copies The number of copies being registered. This is optional. If
omitted, the default is 1.
1. Use the REGISTER request to log your possession of the PACKAGE in a
REQUESTS file. If you obtained the copy via the GET request, you are
already registered and do not need to issue the REGISTER request. If
you obtained the copy by some other means, such as linking to a shadow
disk and using the CMS COPYFILE command, or copying it from a friend,
you should register your possession of the PACKAGE by issuing the
REGISTER request.
2. Registration of PACKAGEs permits the package owner to gather
statistics about the popularity of the package (perhaps to justify the
amount of time spent developing and maintaining the package) and to
contact you directly, should the need arise. In some cases, the
package owner may require registration as a prerequisite to providing
assistance.
For example, to register your copy of the PANDA PACKAGE:
Command line example
TOOLS TO BLAH REGISTER PANDA
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> REGISTER Details: │
│ │
│ Filename/Type ==> PANDA ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10.
Use the REGRESS verb to undo a REPLACE or HIDE request.
You must have at least REPLACER authority to issue the REGRESS verb.
Format of the REGRESS verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> REGRess fname ftype <fmode> (reason │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the REGRESS verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> REGRess Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> reason │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. fmode The filemode of the file. This is ignored.
All overrides are appropriate for the REGRESS request, except:
PROPAGATE
reason Is a comment describing the reason that the file is being
regressed. The comment is included in the message sent to users
who have an INFORM or SUBSCRIBE for the file. It will also
appear in the HISTORY file for the disk.
None.
1. The current file (if it exists) is discarded and the backup file is
renamed to its original name. Any previous backup files are not
recovered.
2. Only the owner of the current file, or a user with PRIV authority for
the disk can issue the REGRESS request.
3. If you REGRESS a PACKAGE file, referenced files hidden by a previous
HIDE or REPLACE will also be regressed, and files referenced by the
current copy of the PACKAGE file (but not by the backup) will be
hidden, if they are not referenced by any other package.
4. Backup and hidden files can be removed by certain forms of the CLEAN
request. Therefore, it is possible that you may not be able to
regress a file if the disk has been cleaned since you updated or hid
the file.
For example, if the current copy of BAD EXEC is found to be defective, and
you wish to revert to the old copy until you can fix it:
Command line example
TOOLS TO BLAH REGRESS BAD EXEC (UNTIL NEW VERSION IS REPAIRED
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> REGRESS Details: │
│ │
│ Filename/Type ==> BAD EXEC * │
│ │
│ Description ==> UNTIL NEW VERSION IS REPAIRED │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb HIDE" in topic 4.9. • "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10. • "TOOLS Request Verb REPLACE" in topic 4.23.
Use the RENEW verb to renew your subscriptions to a Toolsrun controlled disk.
You must have at least GETTER authority to issue RENEW. If INFORM processing is disabled or subscription expiration is disabled, the RENEW request will be rejected.
Format of the RENEW verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> RENew │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the RENEW verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> RENew Details: │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the RENEW request, except:
NOCOPY
None.
None.
1. The RENEW request may be used to reset the number of days left in a
disk subscription to the maximum allowed by the disk administrator.
2. The QUERY INFORM request may be used to find out when your
subscriptions will expire.
3. See the Usage Notes under INFORM for an explanation of subscription
expiration.
For example, to renew your subscriptions on the BLAH disk:
Command line example
TOOLS TO BLAH RENEW
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> RENEW Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb INFORM" in topic 4.10. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS Request Verb QUERY" in topic 4.19.
Use the REPLACE verb to replace the current copy of a file on the disk. The current copy becomes the backup copy. Any prior backup copy is discarded.
You must have at least REPLACER authority to issue the REPLACE verb. You must have at least PACKAGER authority to own files newly referenced by a PACKAGE file that you replace.
Format of the REPLACE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> REPlace fname ftype <fmode> (reason │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the REPLACE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> REPlace Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> reason │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required.
ftype The filetype of the file. This is required.
fmode The filemode of the file. This is optional. If omitted, the
default is "*" - all disks will be searched for the file.
All overrides are appropriate for the REPLACE request, except:
PROPAGATE
reason Is a comment describing why the file is being replaced. It will
be included in the message sent to users who have INFORMs and
SUBSCRIBEs that match this file. It is also logged in the
appropriate HISTORY file.
The message sent to users who have INFORMs and SUBSCRIBEs
matching this file should help them decide whether to GET the
file (if they have an INFORM set) or to receive and install the
file (if they have a SUBSCRIBE set). It is therefore important
that people submitting updates supply meaningful change
descriptions.
The description of the file in the disk NAMES file is not
altered.
None.
1. Only the owner of the file, or a user with PRIV authority for the
disk, may issue the REPLACE request.
2. If the file you are replacing is appendable, you should LOCK the file
before replacing it, so that appends that arrive just before the
replace are not lost. REPLACE will automatically UNLOCK the file.
3. Use the REGRESS request to undo the REPLACE.
4. If you replace a PACKAGE file, and the new version references files
that the old version did not, and the files are currently unowned, you
are made the owner of them.
5. If you replace a PACKAGE file, and:
a. the new version omits references to files referenced by the old
version
b. the files are not referenced by any other PACKAGE file on the disk
c. the files did not exist prior to being referenced by some PACKAGE
file
d. you own the files
then the files are hidden.
If the PACKAGE file is replaced again and:
a. References the files, they are regressed.
b. Still does not reference the files and:
1) No other hidden PACKAGE references the files, they are erased.
2) Some other hidden PACKAGE references the files, they remain
hidden.
6. The disk may impose a restriction that new files may not be created
until referenced by a PACKAGE file. If you are going to add new files
to a PACKAGE, you must first replace the PACKAGE file and then create
the new files. Most software repository disks choose to impose this
restriction.
7. On disks that do not impose this restriction, it is good practice to
replace a PACKAGE file that references new files before creating them.
Otherwise, users with INFORMs and SUBSCRIBEs for the PACKAGE file will
not receive notification of the new files.
8. The UPDATE request may be used instead of REPLACE to apply an
incremental update to a file.
For example, to replace OLD EXEC with a newer version:
Command line example
TOOLS TO BLAH REPLACE OLD EXEC (THIS ONE IS BETTER
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> REPLACE Details: │
│ │
│ Filename/Type ==> OLD EXEC * │
│ │
│ Description ==> THIS ONE IS BETTER │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb LOCK" in topic 4.13. • "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10. • "TOOLS Request Verb REGRESS" in topic 4.21. • "TOOLS Request Verb UPDATE" in topic 4.31. • "TOOLS Request Verb UNLOCK" in topic 4.29.
Use the RESPONSE verb to control responses that TOOLSRUN will send to you. You can control the spool class of mail files, the way the response is sent, and what to do with failed request files.
No authorization is required to use the RESPONSE verb.
Format of the RESPONSE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> RESponse class <how <format <baddie>>> │ └──────────┴─────────────────────────────────────────────────────────────┘ | Format of the RESPONSE verb on the TOOLS full screen: The RESPONSE | request verb cannot be entered from the TOOLS full screen.
None.
All overrides are appropriate for the RESPONSE request, except:
ANSWER
FOR
NOCOPY
NOCLOSE
NOPROMPT
PROPAGATE
SENDTO
TRACE
The description field is ignored.
class A letter or digit that selects the spool class to be used for
files and mail that are sent to the requestor. This is
required.
You may specify an asterisk (*) to select the default, class B.
You may not specify class M or class N.
how Sets the method to be used for responses. This is optional. If
omitted, the default is "*." The methods are:
NONE Send no response (for special applications only).
MSG Responses will be sent as immediate messages. Note
that these may be lost if you are disconnected or
logged off when the request is processed.
FAIL Send no response unless the request fails.
MAIL The response is sent as a mail file. No immediate
message will be sent. The filetype of the response
will include the spoolid of the original request
(allows responses to be correlated with requests).
BOTH The response is sent as an immediate message and a
mail file. The filetype of the mail response will
include the spoolid of the original request (allows
responses to be correlated with requests).
EITHER A mail file is normally sent, but immediate messages
will be used for local users. If the message fails to
get through (e.g. Disconnected or Not Logged On), then
a mail file will be sent.
* Selects the default, EITHER.
format Sets the mail format to be used. This is optional. If omitted,
the default is "*." The formats are:
OLD RMSG.
NEW Netdata.
* Selects the default, NEW.
baddie Controls the action to be taken with a failed request file.
This is optional. If omitted, the default is "*." The actions
are:
RETURN Return the request file to the sender.
DISCARD Purge the request file.
* Selects the default, RETURN.
1. Issuing the RESPONSE request will affect all subsequent requests sent
to the selected disk. However, files sent from the TOOLSRUN machine
which are not in direct response to a request (e.g. INFORM and
SUBSCRIBE files) will not be affected by the user RESPONSE setting.
2. The RESPONSE request does not, itself, cause a TOOLSRUN command to be
sent to the service machine. However, the information will be stored
in your LASTING GLOBALV file and used for all future requests sent to
the selected disk.
3. Use the ANSWER override verb to change the response for just one
request.
4. The SENDTO override is not really appropriate, but here's what will
happen:
• The information will be stored under the nickname "synonym" if
TOOLS was invoked with a synonym.
• The information will be stored under the nickname TOOLS if TOOLS
was not invoked with a synonym.
For example, to tell the BLAH disk to send responses as mail files and to
discard failed requests:
Command line example
TOOLS TO BLAH RESPONSE * MAIL * DISCARD
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> RESPONSE Details: * MAIL * DISCARD │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verb ANSWER" in topic 6.1. • "TOOLS Override Verbs" in topic 6.0.
Use the SET verb to alter the name, mode number or description of a file on the disk, or to change all of your file ownerships, INFORMs and SUBSCRIBEs to your new userid (or someone else's userid).
You must have at least GETTER authority to issue SET ADDRESS. You must have at least REPLACER authority to issue SET DESCRIPTION or SET MODE. (You must have PRIV authority to set the mode to 0.) You must have at least OWNER authority to issue SET FILE.
FORMATS OF THE SET verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> SET <ADDress> newaddr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SET <DEScription> fname ftype <fmode> (newdescr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SET <FILe> fname ftype <fmode> newfn newft │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SET <MODe> fname ftype <fmode> newmode │ └──────────┴─────────────────────────────────────────────────────────────┘ FORMATS OF THE SET verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> SET Details: <ADDress> newaddr │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> SET Details: <DEScription> │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> newdescr │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> SET Details: <FILe> newfn newft │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> SET Details: <MODe> newmode │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required, except for SET
ADDRESS, in which case it should not be entered.
ftype The filetype of the file. This is required, except for SET
ADDRESS, in which case it should not be entered.
fmode A filemode may be specified, except for SET ADDRESS, but will be
ignored.
All overrides are appropriate for the SET request, except:
NOCOPY
newdescr is the new description of the file, and replaces the current
description in the disk NAMES file. This is required for SET
DESCRIPTION and ignored for all other SET requests.
The type of the SET request. This is optional. If omitted, it defaults
to ADDRESS if "newuser AT newnode" is specified, FILE if "newfn newft" is
specified and MODE if "newmode" is specified. Otherwise, it defaults to
DESCRIPTION. The types are:
SET ADDress will change all of your file ownership, INFORMs and SUBSCRIBEs
to your new userid (or someone else's userid). "newaddr" is
required.
SET DEScription will replace the current description of "fname ftype" in
the disk NAMES file with "newdescr." "fname ftype" and
"newdescr" are required.
SET MODe will change the filemode number of "fname ftype" to "newmode."
"fname ftype" and "newmode" are required.
SET FILe will rename "fname ftype" to "newfn newft." "fname ftype" and
"newfn newft" are required.
Other details are:
newaddr is your new userid, and is required with SET ADDRESS. "newaddr"
must be one of the following forms:
newuserid
newnode newuserid
newuserid AT newnode
If "newuserid" is specified without "newnode," the userid will
be changed and the node will remain the same.
newfn is the new filename for the file. You may specify "=" if the
filename is to remain the same.
newft is the new filetype for the file. You may specify "=" if the
filetype is to remain the same.
newmode Must be a single digit between 0 and 6 (excluding 3):
1
2
5 are essentially the same.
0 will make the file "invisible" to normal users, and
should be used only by disk administrators.
6 enables CMS "update in place" and is useful for
appendable files. If a user is linked and accessed to
the disk and viewing an appendable file at the time it
is updated, serious problems can occur. These
problems are generally avoided if the file is mode 6.
4 is supposed to mean that the file is in OS simulated
data set format.
1. SET ADDRESS is useful when you change nodes or userid. It also is
useful when another user is assuming your responsibility for a disk.
You can transfer the ownership of all your files with one request.
2. If you no longer have access to your old node and/or old userid, you
may be able to use the FOR override to issue SET ADDRESS as if it were
coming from the old node and userid. If this does not work, or if you
owned any files, you will have to ask the disk administrator to issue
SET ADDRESS on your behalf.
3. If you accidentally change your node and/or userid to an invalid one,
you may be able to use the FOR override to issue SET ADDRESS as if it
were coming from the incorrect node and userid, to change to the
correct one. If this does not work, or if you owned any files, you
will have to ask the disk administrator to issue SET ADDRESS on your
behalf.
4. SET ADDRESS will not change your authority for a disk. For example,
if you have PRIV authority for the BLAH disk, SET ADDRESS will
transfer ownership of your files to your new userid, but the new
userid will not have PRIV authority unless the ToolsRun CONTROL file
is updated.
5. SET FILE may never be used on a PACKAGE file.
6. How to rename a file referenced by a PACKAGE. When a file is
referenced by a PACKAGE file, and the file was created after the
reference was made, and no other PACKAGE file references the file, you
may find it difficult to rename the file while retaining the
reference. If you first replace the PACKAGE file with the old name
deleted and the new name included, you will find that the file has
been hidden. Here is how to do it:
a. Use SET FILE to rename the file.
b. REPLACE the PACKAGE file with the old name deleted and the new
name included.
7. SET ADDRESS will generally result in a new set of subscriptions that
will expire after the maximum time set by the disk administrator (if
subscription expiration is in effect). However, if subscriptions were
already in effect for newaddr, the new set will expire at the same
time as those. Use QUERY INFORM to find out when your subscriptions
will expire.
| 8. SET ADDRESS will change file ownership at all shadows, if sent to a
| master disk. (This also has the side effect of changing all your
| informs at any shadows.) Change of file ownership and propagation to
| shadows does not occur if submitted FOR someone else, unless the
| submitter is PRIV for the disk.
For example, to tell the BLAH disk that you have a new node and userid, do
the following from your old node and userid:
Command line example
TOOLS TO BLAH SET ADDRESS NEWID AT NEWNODE
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> SET Details: ADDRESS NEWID AT NEWNODE │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb QUERY" in topic 4.19. • "TOOLS Request Verb RENEW" in topic 4.22. • "TOOLS Override Verbs" in topic 6.0.
The SUBSCRIBE request verb is used to receive copies of newly created files or changes to existing files.
You must have at least GETTER authority to issue the SUBSCRIBE verb. In addition, INFORM and SUBSCRIBE must be enabled for the disk.
Format of the SUBSCRIBE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> SUBscribe fnpat ftpat <fmode> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the SUBSCRIBE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> SUBscribe Details: │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. ftpat A filetype pattern. This is required. fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the SUBSCRIBE request, except:
NOCOPY
The description field is ignored.
None.
1. SUBSCRIBE is a synonym for the INFORM verb with the SUBSCRIBE option.
(See "TOOLS Request Verb INFORM" in topic 4.10 for information about
subscription expiration.
2. You may cancel a subscription with either the UNINFORM or UNSUBSCRIBE
verbs. UNSUBSCRIBE is a synonym for UNINFORM. (See "How to
UnInform/UnSubscribe" in topic B.11.)
3. The SET ADDRESS request may be used to instruct the service machine to
redirect your SUBSCRIBEs to a new userid, new node or both.
4. You may use INFORM with the EXCLUDE option to avoid receiving copies
of certain files that match a SUBSCRIBE pattern.
5. If you SUBSCRIBE to a PACKAGE file, you will receive copies of any
changes to files that it references, as well as copies of the PACKAGE
file itself. However, if any of those files are also PACKAGE files,
you will not receive copies of changes to files that they reference.
6. If you use a pattern for SUBSCRIBE that includes any PACKAGE files,
you will receive copies of changes only for the PACKAGE files
themselves, not for their contents. In particular, to subscribe to a
PACKAGE file, but not its referenced files, use * PACKAGE*.
7. If you update a file that you SUBSCRIBE to, you will receive a copy.
For example, to subscribe to changes in the FROG FORUM on the BLAH disk:
Command line example
TOOLS TO BLAH SUBSCRIBE FROG FORUM
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> SUBSCRIBE Details: │
│ │
│ Filename/Type ==> FROG FORUM * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb INFORM" in topic 4.10. • "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10. • "TOOLS filename and filetype patterns" in topic B.9. • "TOOLS Request Verb SET" in topic 4.25. • "TOOLS Request Verb UNINFORM" in topic 4.28. • "TOOLS Request Verb UNSUBSCRIBE" in topic 4.30. • "How to UnInform/UnSubscribe" in topic B.11.
Use the SUMMARY verb to get a list of files on the disk, including the owner's node and userid. The description of the file (from the disk NAMES file) is also included.
You must have at least GETTER authority to issue the SUMMARY verb.
Format of the SUMMARY verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> SUMmary fnpat ftpat <fmode> <COPY> <date> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the SUMMARY verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> SUMmary Details: <COPY> <date> │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. ftpat A filetype pattern. This is required. fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the SUMMARY request, except:
NOCOPY
The description field is ignored.
COPY Indicates that the file(s) are to be sent in TOOLS format.
Files sent in TOOLS format are intended to be processed by a
TOOLSRUN service machine. Therefore, this option should only be
used when the SUMMARY request is being sent by a TOOLSRUN
service machine.
date A date in append header form (HH:MM:SS on YY/MM/DD) or TOOLSRUN
standard form (YYYYMMDDHHMMSS), optionally preceded by SINCE.
This is optional. If specified, only files changed on or after
this date will be listed.
1. COPY form may be used to maintain lists of the contents of other disks
on a conference disk. This may be useful if there are no local
shadows of those disks. LIST COPY is more commonly used for this
purpose.
2. The LIST request verb will also return a list of the files on a disk.
The differences between LIST and SUMMARY are that LIST returns
information about the size and change date and SUMMARY returns
information about the owner of the file.
For example, to list all of the SCRIPT files on the BLAH disk:
Command line example
TOOLS TO BLAH SUMMARY * SCRIPT
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> SUMMARY Details: │
│ │
│ Filename/Type ==> * SCRIPT * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS date formats" in topic B.4. • "TOOLS Request Verb LIST" in topic 4.11. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS filename and filetype patterns" in topic B.9.
Use the UNINFORM verb to cancel a previous INFORM or SUBSCRIBE request.
You must have at least GETTER authority to issue the UNINFORM verb.
Format of the UNINFORM verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> UNInform fnpat ftpat <fmode> <EVERY <infotype> │ │ │ > │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the UNINFORM verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> UNInform Details: <EVERY <infotype> > │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname A filename. This is required. ftype A filetype. This is required. fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the UNINFORM request, except:
NOCOPY
The description field is ignored.
EVERY Indicates that the filename and filetype should be treated as a
pattern rather than literally. Every INFORM or SUBSCRIBE request
on file that matches the pattern is cancelled. This is
optional. If omitted, only the one INFORM/SUBSCRIBE that
exactly matches the filename and filetype will be cancelled.
infotype Is allowed only if "EVERY" is specified. Only INFORMs of this
type will be cancelled. This is optional. If omitted, and
"EVERY" is specified, all INFORMs that match the pattern will be
cancelled, regardless of type.
The types are:
*
ALL
COPy
EXClude
NEW
REFerence
SUBscribe
UPDate
where "*" is the same as omitting infotype altogether: Any matching
pattern will be cancelled, regardless of type.
1. UNINFORM is used to cancel an INFORM or SUBSCRIBE, not to limit the
scope of the files you receive notification of. Use INFORM EXCLUDE to
do this.
2. To find out what INFORMs and SUBSCRIBEs you have at a disk, issue the
QUERY INFORM request.
3. If you are receiving unwanted INFORM messages or unwanted SUBSCRIBE
copies, "How to UnInform/UnSubscribe" in topic B.11 will help you
figure out how to cancel them.
For example, to tell the BLAH disk to quit sending any change
notifications:
Command line example
TOOLS TO BLAH UNINFORM * * EVERY
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> UNINFORM Details: EVERY │
│ │
│ Filename/Type ==> * * * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb INFORM" in topic 4.10. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS Request Verb SUBSCRIBE" in topic 4.26. • "TOOLS Request Verb QUERY" in topic 4.19. • "How to UnInform/UnSubscribe" in topic B.11.
Use the UNLOCK verb to permit updates to a previously locked file.
You must have at least REPLACER authority to issue the UNLOCK verb.
Format of the UNLOCK verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> LOCk fname ftype <fmode> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the UNLOCK verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> UNLock Details: │ │ │ │ Filename/Type ==> fname ftype <fmode.> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. | fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the UNLOCK request, except:
PROPAGATE
The description field is ignored.
None.
1. Only the owner of the file or a person with PRIV authority for the
disk may UNLOCK a file.
For example, to unlock the UNRULY FORUM on the BLAH disk:
Command line example
TOOLS TO BLAH UNLOCK UNRULY FORUM
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> UNLOCK Details: │
│ │
│ Filename/Type ==> UNRULY FORUM * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb LOCK" in topic 4.13. • "TOOLS Override Verbs" in topic 6.0.
Use the UNSUBSCRIBE verb to cancel a previous SUBSCRIBE request.
You must have at least GETTER authority to issue the UNSUBSCRIBE verb.
Format of the UNSUBSCRIBE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> UNSubscribe fnpat ftpat <fmode> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the UNSUBSCRIBE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> UNSUBSCRIBE Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname A filename. This is required. ftype A filetype. This is required. fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the UNSUBSCRIBE request, except:
NOCOPY
The description field is ignored.
None.
1. UNSUBSCRIBE is used to cancel a SUBSCRIBE request, not to limit the
scope of the files you receive copies of. Use INFORM EXCLUDE to do
this.
2. To find out what INFORMs and SUBSCRIBEs you have at a disk, issue the
QUERY INFORM request.
3. UNSUBSCRIBE is a synonym for UNINFORM.
4. If you are receiving unwanted SUBSCRIBE copies, "How to
UnInform/UnSubscribe" in topic B.11 will help you figure out how to
cancel them.
For example, to tell the BLAH disk to quit sending copies of appends to
PANDA FORUM:
Command line example
TOOLS TO BLAH UNSUBSCRIBE PANDA FORUM
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> UNSUBSCRIBE Details: │
│ │
│ Filename/Type ==> PANDA FORUM * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb INFORM" in topic 4.10. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS Request Verb SUBSCRIBE" in topic 4.26. • "TOOLS Request Verb QUERY" in topic 4.19. • "How to UnInform/UnSubscribe" in topic B.11.
Use the UPDATE verb to apply an incremental update to a large file on the disk that has not been extensively modified.
You must have at least REPLACER authority to issue the UPDATE verb.
Format of the UPDATE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> UPDate fname ftype <fmode> (reason │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the UPDATE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> UPDate Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> reason │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required.
ftype The filetype of the file. This is required.
fmode The filemode of the file. This is optional. If omitted, the
default is "*" - all disks will be searched for the file "fname
IUPDATE."
All overrides are appropriate for the UPDATE request, except:
PROPAGATE
reason Is a comment describing why the file is being replaced. It will
be included in the message sent to users who have INFORMs and
SUBSCRIBEs that match this file. It is also logged in the disk
HISTORY file.
The message sent to users who have INFORMs and SUBSCRIBEs
matching this file should help them decide whether to GET the
update (if they have an INFORM set) or to receive and install
the update (if they have a SUBSCRIBE set). It is therefore
important that people submitting updates supply meaningful
change descriptions.
The description of the file in the disk NAMES file is not
altered.
None.
1. The UPDATE request does not create a backup version of the file. This
is not necessary, since a subsequent UPDATE may be issued to back off
the previous changes. Also, it saves on disk space when a large file
is being updated (as is usually the case).
2. The update file may be generated using the IUPDATE PACKAGE, available
from VMTOOLS (VMTOOLS at RALVM17).
3. The update data is in an update file named "fname IUPDATE." The update
file contains records that contain a command character, followed by
one space and text. The update commands are:
U fname ftype crc1 crc2 filedatetime flag This statement must be first
in the update information. The meanings of the fields are:
fname The filename of the file to update.
ftype The filetype of the file to update.
crc1 The CRC of the file before the update is applied.
If crc1 does not match the CRC of the file, the
update will fail at a master disk; at a shadow
disk, the update will be deferred until it does
match. Code an asterisk ("*") to bypass CRC
checking.
crc2 The CRC of the file after the update is applied.
filedatetime The date and time to be applied to the updated
file, in the form YYYYMMDDHHMMSS.
flag Update strategy indicator:
N No update is required. This may be used
to verify the file and/or update date
and time information.
A Update contains only appends.
U File may be updated in place, since
there are no deletions or insertions
(except insertions at the end of the
file), and all replacement lines are the
same length as the original (variable
length files only).
D Update meets all of the conditions for
"U" except that it contains one or more
deletions.
C File must be copied to be updated.
C n This statement instructs the update program to copy or skip
the next "n" lines in the original file.
D n This statement instructs the update program to delete the
next "n" lines in the original file.
R text This statement instructs the update program to replace the
next line in the original file with the text supplied.
I text This statement instructs the update program to insert a line
into the file which contains the text supplied.
V text This statement instructs the update program to compare the
next line in the original file with the text supplied. This
is used in addition to, or in conjunction, with the CRC
information to insure that the update is made correctly. If
the verification is not successful, the update is aborted at
this point.
This does not move the pointer in the original file, so that
the verified line in this file may be copied, deleted or
replaced if the verify is successful.
For example, to apply FROG IUPDATE to FROG EXEC:
Command line example
TOOLS TO BLAH UPDATE FROG EXEC (VERSION 2.3
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> UPDATE Details: │
│ │
│ Filename/Type ==> FROG EXEC * │
│ │
│ Description ==> VERSION 2.3 │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "TOOLS Request Verb REPLACE" in topic 4.23.
Use the VOTE verb to increment one of the vote counters in a VOTE file.
You must have at least APPENDER authority (plus the ADDER authority modifier if you are not the owner) to issue the VOTE verb.
Format of the VOTE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> VOTe fname token │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the VOTE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> VOTe Details: token │ │ │ │ Filename/Type ==> fname <ftype> <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the VOTE file. This is required.
ftype The filetype of the file. This is optional for the TOOLS full
screen invocation only, and is ignored.
fmode The filemode of the file. This is optional for the TOOLS full
screen invocation only, and is ignored.
All overrides are appropriate for the VOTE request, except:
NOCOPY
PROPAGATE
The description field is ignored.
token Is the identifier of the vote counter that you wish to
increment. It is often "YES" or "NO," but may be anything. See
the USAGE NOTES for a more detailed explanation.
1. You must send your vote to the master disk.
2. A VOTE file is a file with a filetype of VOTE and at least two counter
fields. When the file is created, the counter values are usually set
to zero (unless the owner has some reason for recording some
preliminary votes). As users register their votes, the appropriate
counters are incremented.
Each user that votes is recorded in a VOTERS file, so that attempts to
register more than one vote are detected and prevented. The order of
userids in the VOTERS file is scrambled and does not reflect the order
in which the votes were cast.
For example, someone may wish to conduct a vote on whether the UNRULY
FORUM should be shut down. They would then CREATE a file, perhaps
called SHUTUNRU VOTE, containing an explanation of the vote being
conducted, and at least two counter fields with identifying tokens:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ Should the UNRULY FORUM be shut down? │
│ │
│ Recent inactivity on this forum has led me to believe that it │
│ has outlived its usefulness and blah...blah...blah... │
│ │
│ If you wish to record your vote on this burning issue, enter │
│ │
│ TOOLS SENDTO KGNVMZ TOOLS IBMVM VOTE SHUTUNRU token │
│ │
│ where "token" is one of YES, NO or WAIT. │
│ │
│ Votes Tokens Description │
│ │
│ 0 YES Yes, shut it down. │
│ 0 NO No, don't shut it down. │
│ 0 WAIT Wait awhile to see if activity picks back up. │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
Any line that begins with an integer is assumed to be a vote count and
token. The next word in the line is assumed to be the token.
Anything after the token is ignored. All lines that do not begin with
an integer are ignored as comments.
When you cast your vote, the token that you specify must match one of
the tokens in the VOTE file.
3. If you have created a VOTE file, be sure to erase it after an
appropriate period.
4. Votes are useful as opinion polls, but should be viewed with a degree
of skepticism. Not everyone will know how to vote, or bother to.
Depending upon their emotions, some people may attempt to "stuff the
ballot box" by casting votes from multiple userids, friends' userids,
multiple non-equated nodes, etcetera.
For example, to register a NO vote in the PROPOSAL VOTE file:
Command line example
TOOLS TO BLAH VOTE PROPOSAL NO
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> VOTE Details: NO │
│ │
│ Filename/Type ==> PROPOSAL ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Users with PRIV authority may issue any request for the disk, in addition to the TOOLS PRIV request verbs listed in this chapter. Also, only users with PRIV authority may use the NOCOPY override. Users with SYSTEM authority do not automatically have authority to issue requests for any disks. These are the TOOLS request verbs that require either PRIV or SYSTEM authority to issue:
Use the AGET verb to retrieve a file from the TOOLSRUN service machine's A-disk.
You must have SYSTEM authority at the service machine to issue the AGET verb.
Format of the AGET verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> AGEt fname ftype <fmode> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the AGET verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> AGEt Details: │ │ │ │ Filename/Type ==> fname ftype <fmode.> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required. ftype The filetype of the file. This is required. | fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the AGET request, except:
FOR
NOCOPY
PROPAGATE
The description field is ignored.
The details field is ignored.
1. SYSTEM requests may not be mixed with non-SYSTEM requests in the same
deck. (See "TOOLS Override Verb NOCLOSE" in topic 6.3.)
2. A user with PRIV authority for a disk may request the AUDIT file for
that disk, even though the AUDIT file resides on the A-disk. A GET
disk AUDIT request is sent to the disk.
For example, to retrieve TOOLSRUN CONTROL from the BLAHID service machine
at BLAHNODE:
Command line example:
TOOLS SENDTO BLAHNODE BLAHID * AGET TOOLSRUN CONTROL
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> AGET Details: │
│ │
│ Filename/Type ==> TOOLSRUN CONTROL * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Use the ALIST verb to list files on the TOOLSRUN service machine's A-disk.
You must have SYSTEM authority at the service machine to issue the ALIST verb.
Format of the ALIST verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> ALIst fnpat ftpat <fmode> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the ALIST verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> ALIst Details: │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. ftpat A filetype pattern. This is required. | fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the ALIST request, except:
FOR
NOCOPY
PROPAGATE
The description field is ignored.
The details field is ignored.
1. SYSTEM requests may not be mixed with non-SYSTEM requests in the same
deck. (See "TOOLS Override Verb NOCLOSE" in topic 6.3.)
For example, to list all files with a filetype of EXEC on the BLAHID
service machine at BLAHNODE:
Command line example
TOOLS SENDTO BLAHNODE BLAHID * ALIST * EXEC
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> ALIST Details: │
│ │
│ Filename/Type ==> * EXEC * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "TOOLS filename and filetype patterns" in topic B.9
Use the AREPLACE verb to write a file to the TOOLSRUN service machine's A-disk.
You must have SYSTEM authority at the service machine to issue the AREPLACE verb.
Format of the AREPLACE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> AREplace fname ftype <fmode> <(reason> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the AREPLACE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> AREplace Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> <reason> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required.
ftype The filetype of the file. This is required.
fmode The filemode of the file. This is optional. If omitted, the
default is "*" - all disks will be searched for the file.
All overrides are appropriate for the AREPLACE request, except:
NOCOPY
PROPAGATE
A description is optional. If supplied, it will be logged in the @SYSTEM HISTORY file on the TOOLSRUN service machine's A-disk, and sent in the message to all system NOTIFY users.
The details field is ignored.
1. SYSTEM requests may not be mixed with non-SYSTEM requests in the same
deck. (See "TOOLS Override Verb NOCLOSE" in topic 6.3.)
2. The file must exist on an accessed minidisk before issuing this
request.
3. The AREPLACE request may be used to replace an existing file or to
create a new file.
4. To erase a file from the A-disk, use the CMS request verb: CMS ERASE
fname ftype A.
For example, to write TOOLSRUN CONTROL to the BLAHID service machine at
BLAHNODE:
Command line example
TOOLS SENDTO BLAHNODE BLAHID * AREPLACE TOOLSRUN CONTROL
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> AREPLACE Details: │
│ │
│ Filename/Type ==> TOOLSRUN CONTROL * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Use the BATCH verb with the RELEASE option to release requests from the batch queue. See "TOOLS Request Verb BATCH" in topic 4.2 for the complete format and description.
You must have PRIV authority for the disk to issue the BATCH request with | the RELEASE option (except when fnpat ftpat is specified).
Use the CLEAN verb to erase discarded files from the disk, freeing up space. See "TOOLS Request Verb CLEAN" in topic 4.3 for the complete format and description.
You must have PRIV authority for the disk to issue any type of CLEAN request except CLEAN SAFE.
Use the CMS verb to execute a CMS command at the service machine and return the console output.
You must have SYSTEM authority at the service machine to issue the CMS verb.
Format of the CMS verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> CMS cmd │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the CMS verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> CMS Details: │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> cmd │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the CMS request, except:
FOR
NOCOPY
PROPAGATE
cmd The CMS command (with parameters and options) to be executed by
the service machine. This is limited to 69 characters: 80
minus 11, where 11 is the length of ":TOOLS CMS"
The details field is ignored.
1. SYSTEM requests may not be mixed with non-SYSTEM requests in the same
deck. (See "TOOLS Override Verb NOCLOSE" in topic 6.3.)
2. Since any CMS command may be executed, this is potentially a dangerous
request - use carefully.
3. Do not use the CMS request to log off the service machine. Use LOGOFF
or SHUTDOWN (with a control loop) instead.
4. Commonly used to erase or rename files on the ToolsRun machine's
A-disk.
For example, to erase TOOLDAY OLDEXEC from the A-disk of BLAHID at
BLAHNODE:
Command line example
TOOLS SENDTO BLAHNODE BLAHID * CMS ERASE TOOLDAY OLDEXEC
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> CMS Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> ERASE TOOLDAY OLDEXEC │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Use the COPY verb to send selected files from one service machine to another, together with their backup files and NAMES file entries.
You must have PRIV authority for the disk to issue the COPY verb.
Format of the COPY verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> COPy fnpat ftpat <fmode> node userid disk │ │ │ <date> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the COPY verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> COPy Details: node userid disk <date> │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. ftpat A filetype pattern. This is required. | fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the COPY request, except:
NOCOPY
PROPAGATE
The description field is ignored.
node The nodeid of the service machine to receive the files. This is
required.
userid The userid of the service machine to receive the files. This is
required.
disk The name of the disk to receive the files. This is required.
date A date in append header form (HH:MM:SS on YY/MM/DD) or TOOLSRUN
standard form (YYYYMMDDHHMMSS), optionally preceded by SINCE.
This is optional. If specified, only files changed on or after
this date will be sent.
1. The COPY request can be used to:
• Initialize a shadow disk from the master.
• Transfer files from one conference disk to another.
• Synchronize a shadow disk with the master.
2. See also the REFRESH request.
3. COPY works like GET if the filetype is PACKAGE. (See "TOOLS Request
Verb GET" in topic 4.7.) (See "TOOLS Request Verb GET" in topic 4.7.)
For example, to initialize the BLAH shadow disk (BLAHID2 at BLAHNOD2) with
all EXEC files on the BLAH master:
Command line example
TOOLS TO BLAH COPY * EXEC BLAHNOD2 BLAHID2 BLAH
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> COPY Details: BLAHNOD2 BLAHID2 BLAH │
│ │
│ Filename/Type ==> * EXEC * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS date formats" in topic B.4. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS filename and filetype patterns" in topic B.9. • "TOOLS PRIV Request Verb REFRESH" in topic 5.14.
A user with PRIV authority may request the disk AUDIT file from the TOOLSRUN system A-disk. See "TOOLS Request Verb GET" in topic 4.7 for the complete format and description.
You must have PRIV authority for the disk to GET disk AUDIT.
Use the LOGOFF verb to cause the service machine to log itself off immediately.
You must have SYSTEM authority at the service machine to issue the LOGOFF verb.
Format of the LOGOFF verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> LOGoff │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the LOGOFF verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> LOGoff Details: │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the LOGOFF request, except:
FOR
NOCOPY
PROPAGATE
The description field is ignored.
The details field is ignored.
1. SYSTEM requests may not be mixed with non-SYSTEM requests in the same
deck. (See "TOOLS Override Verb NOCLOSE" in topic 6.3.)
For example, to kill the BLAHID service machine at BLAHNODE:
Command line example
TOOLS SENDTO BLAHNODE BLAHID * LOGOFF
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> LOGOFF Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0.
Use the NOCOPY override verb to inhibit the copying of change requests (e.g. CREATE or REPLACE) to other service machines. See "TOOLS PRIV Override Verb NOCOPY" in topic 6.4 for the complete format and description.
You must have PRIV authority for the disk in order to issue the NOCOPY verb.
Use the PLACE verb to write a file to a disk, whether or not it already exists.
You must have PRIV authority for the disk in order to issue the PLACE verb.
Format of the PLACE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> PLAce fname ftype <fmode> <(file description> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the PLACE verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> PLAce Details: │ │ │ │ Filename/Type ==> fname ftype <fmode> │ │ │ │ Description ==> <file description> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fname The filename of the file. This is required.
ftype The filetype of the file. This is required.
fmode The filemode of the file. This is optional. If omitted, the
default is "*" - all disks will be searched for the file.
All overrides are appropriate for the PLACE request, except:
PROPAGATE
A file description is optional.
The details field is ignored.
1. A PLACE will replace the file specified, without creating or affecting
any backup if one should exist.
2. The file must exist on an accessed minidisk before issuing this
request.
3. If you are using PLACE to replace an appendable file, you should issue
the LOCK request first, so that appends that arrive just before the
replacement will not be lost. PLACE will automatically UNLOCK the
file.
4. PLACE of a file that did not previously exist is the same as CREATE.
See the usage notes for ("TOOLS Request Verb CREATE" in topic 4.4) for
the effects of creating PACKAGE files and appendable files.
5. PLACE may be used to PLACE backup files on the disk.
For example, to PLACE the file FROG EXEC on the BLAH disk:
Command line example
TOOLS TO BLAH PLACE FROG EXEC (HOPPING ASSIST
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> PLACE Details: │
│ │
│ Filename/Type ==> FROG EXEC * │
│ │
│ Description ==> HOPPING ASSIST │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb CREATE" in topic 4.4. • "TOOLS Request Verb LOCK" in topic 4.13. • "TOOLS Override Verbs" in topic 6.0. • "Packages of files" in topic B.10. • "TOOLS filename and filetype patterns" in topic B.9. • "TOOLS Request Verb REPLACE" in topic 4.23. • "TOOLS Request Verb UNLOCK" in topic 4.29.
Persons who have SYSTEM authority for the service machine may use the QUERY verb to request information about the service machine. See "TOOLS Request Verb QUERY" in topic 4.19 for the complete format and description.
You must have SYSTEM authority at the service machine to issue QUERY SYSTEM.
Persons who have SYSTEM authority for the service machine may use the QUERY verb to request usage statistics about each disk. See "TOOLS Request Verb QUERY" in topic 4.19 for the complete format and description.
You must have SYSTEM authority at the service machine to issue QUERY USAGE.
Use the REFRESH verb to cause one or more shadow files to be refreshed from the master copy of the disk.
You must have PRIV authority for the disk in order to issue the REFRESH verb.
Format of the REFRESH verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> REFresh fnpat ftpat <fmode> <date> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the REFRESH verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> REFresh Details: <date> │ │ │ │ Filename/Type ==> fnpat ftpat <fmode> │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
fnpat A filename pattern. This is required. ftpat A filetype pattern. This is required. | fmode A filemode may be specified, but will be ignored.
All overrides are appropriate for the REFRESH request.
The description field is ignored.
date A date in append header form (HH:MM:SS on YY/MM/DD) or TOOLSRUN
standard form (YYYYMMDDHHMMSS), optionally preceded by SINCE.
This is optional, unless asterisks ("*") are specified for both
the filename and filetype. If specified, only files changed on
or after this date will be refreshed.
1. The REFRESH request may be used to:
• Initialize a shadow disk from the shadow service machine.
• Synchronize a shadow disk with the master.
2. If there is more than one MASTER, COPIER or PEER for the disk in
TOOLSRUN CONTROL, the request will be sent to the first one. If there
is a SOURCE in TOOLSRUN CONTROL, the request will be sent there,
instead.
3. See also "TOOLS PRIV Request Verb COPY" in topic 5.7.
4. REFRESH works like GET if the filetype is PACKAGE. (See "TOOLS
Request Verb GET" in topic 4.7.)
5. When you send a REFRESH request to a shadow disk, the shadow machine
sends a GET COPY to the master disk. This GET COPY request may be
placed in a batch queue at the master, instead of being processed
right away. You may use QUERY DISK to find out if GET batching is in
effect for the master disk. See also the BATCH request.
For example, to refresh all files on the BLAH disk beginning with PIG:
Command line example
TOOLS TO BLAH REFRESH PIG* *
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> REFRESH Details: │
│ │
│ Filename/Type ==> PIG* * * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Request Verb BATCH" in topic 4.2 • "TOOLS PRIV Request Verb COPY" in topic 5.7. • "TOOLS Override Verbs" in topic 6.0. • "TOOLS filename and filetype patterns" in topic B.9. • "TOOLS Request Verb QUERY" in topic 4.19
Use the SHUTDOWN verb to shut down the whole service machine or one of its maintained disks.
You must have PRIV authority for the disk to issue SHUTDOWN or SHUTDOWN PERMANENT. You must have SYSTEM authority for the service machine to issue SHUTDOWN ALL, SHUTDOWN FORCED or SHUTDOWN IMMEDIATE.
Format of the SHUTDOWN verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> SHUtdown <when> <(reason> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the SHUTDOWN verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> SHUtdown Details: <when> │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> <reason> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the SYSTEM SHUTDOWN request, except:
FOR
NOCOPY
PROPAGATE
All overrides are appropriate for the PRIV SHUTDOWN request, except:
NOCOPY
PROPAGATE
The description field is ignored for:
SHUTDOWN ALL
SHUTDOWN FORCED
SHUTDOWN IMMEDIATE
The description field is optional for:
SHUTDOWN
SHUTDOWN PERMANENT
and if supplied, will be returned as a message to all users who submit
requests while the disk is shut down.
when Is blank or one of: ALL, FORCEd, IMMediate or PERManent.
(blank) requires PRIV authority for the disk and will shut
down just this one disk. It may be re-started with
the START request. The disk will also be re-started
if TOOLSRUN is re-started at the service machine.
PERManent requires PRIV authority for the disk. It functions
the same as "blank" except that the disk can be
re-started only by a START request.
ALL requires SYSTEM authority for the service machine and
will shut down the whole service machine, as soon as
there are no more requests left to process. TOOLSRUN
EXEC will exit with a return code of 0.
IMMediate requires SYSTEM authority for the service machine. It
functions the same as "ALL" except that the shutdown
is immediate - no other requests are processed.
TOOLSRUN EXEC will exit with a return code of 0.
FORCEd requires SYSTEM authority for the service machine. It
functions the same as "IMMEDIATE" except that TOOLSRUN
EXEC will exit with a non-zero return code.
1. SYSTEM requests may not be mixed with non-SYSTEM requests in the same
deck. (See "TOOLS Override Verb NOCLOSE" in topic 6.3.)
2. Assuming message commands are authorized, this request can be sent to
a TOOLS machine via CP SMSG, to cause the TOOLS machine to be shut
down after processing the current request deck, since SYSTEM requests
via SMSG are ordered ahead of all other reader files.
3. For the SYSTEM SHUTDOWN requests, the TOOLSRUN EXEC return code may be
used to control automatic re-cycling of TOOLSRUN. If TOOLSRUN is
invoked from within another EXEC, the return code may be examined to
decide whether to re-invoke TOOLSRUN.
For example:
Do Until RC?=0
'EXEC TOOLSRUN DISCONNECT'
End
will automatically re-cycle TOOLSRUN on receipt of a SHUTDOWN ALL or
SHUTDOWN IMMEDIATE, but will not attempt to do so if a SHUTDOWN FORCED
is received or if TOOLSRUN ends abnormally.
This allows you to replace any file (such as TOOLSRUN EXEC or TOOLSRUN
CONTROL) and re-start TOOLSRUN without logging on to the service
machine, by using AREPLACE and SHUTDOWN ALL.
Another approach that involves a bit more overhead is to re-IPL the
service machine. For example, if the service machine's PROFILE EXEC
calls START EXEC, and START EXEC contains the following:
'EXEC TOOLSRUN DISC'
If rc=0 Then
'CP IPL CMS PARM AUTOCR'
then the service machine will be re-IPLed on receipt of a SHUTDOWN ALL
or SHUTDOWN IMMEDIATE, but not for a SHUTDOWN FORCED or TOOLSRUN
abnormal termination.
This allows the same flexibility as the first approach (plus the
ability to replace the START EXEC itself). It will also pick up
changes on system disks (such as the S-disk), "clean the slate" for
gradual storage fragmentation, and reduce the size of the service
machine's LASTING GLOBALV if it is being increased by frequent GLOBALV
SET commands.
4. A disk shutdown will detach the disk if it was detached when ToolsRun
started. This allows the disk to be linked Read/Write (for possible
maintenance) without stopping the whole ToolsRun machine.
For example, to shutdown the BLAHID service machine at BLAHNODE after it
finishes processing all other input files:
Command line example
TOOLS SENDTO BLAHNODE BLAHID * SHUTDOWN ALL
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> SHUTDOWN Details: ALL │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "TOOLS PRIV Request Verb START" in topic 5.16.
Use the START verb to start a shut down disk.
You must have PRIV authority for the disk in order to issue the START verb.
Format of the START verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> STArt │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the START verb on the TOOLS full screen: ┌─────────────────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │ │ │ │ │ │ │ │ Request ==> STArt Details: │ │ │ │ Filename/Type ==> ? ? * │ │ │ │ Description ==> │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
None.
All overrides are appropriate for the START request, except:
NOCOPY
The description field is ignored.
The details field is ignored.
1. Besides re-starting disks that have been shut down by the SHUTDOWN
request, START may also be used to bring up a disk that was not
available when TOOLSRUN started. This may happen when a disk pack was
not mounted during a system re-IPL.
For example, to start the BLAH disk:
Command line example
TOOLS TO BLAH START
TOOLS full screen example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> BLAH (BLAH disk managed by BLAHID at BLAHNODE) │
│ │
│ │
│ │
│ Request ==> START Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
• "TOOLS Override Verbs" in topic 6.0. • "TOOLS SYSTEM and PRIV Request Verb SHUTDOWN" in topic 5.15.
Override verbs alter the behavior of request verbs or of the TOOLS EXEC. There may be zero, one or more override verbs, in any order. They must precede the request verb (if any). Override verbs cannot be entered from the full screen menu, so must be specified when invoking the TOOLS EXEC. They apply to all request verbs entered from the menu. Not all combinations of override verb and request verb make sense. This is why each request verb has a section that lists inappropriate override verbs. (In a few cases, the TOOLS EXEC or TOOLSRUN will treat a combination as an error, but in most cases the override is just ignored.) These are the override verbs:
Use the ANSWER verb to control responses that TOOLSRUN will send to you, for this request only. You can control the spool class of mail files, the way the response is sent, and what to do with the request file if it fails.
Authorization depends upon the request verb.
Format of the ANSWER override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ ANSwer class how format baddie <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the ANSWER override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
class A letter or digit that selects the spool class to be used for
files and mail that are sent to the requestor. This is
required.
You may specify an asterisk (*) to select the default, class B.
You may not specify class M or class N.
how Sets the method to be used for responses. This is optional, if
no other verbs follow this one. If omitted, the default is "*."
The methods are:
NONE Send no response (for special applications only).
FAIL Send no response unless the request fails.
MSG Responses will be sent as immediate messages. Note
that these may be lost if you are dis- connected or
logged off when the request is processed.
MAIL The response is sent as a mail file. No immediate
message will be sent. The filetype of the response
will include the spoolid of the original request
(allows responses to be correlated with requests).
BOTH The response is sent as an immediate message and a
mail file. The filetype of the mail response will
include the spoolid of the original request (allows
responses to be correlated with requests).
EITHER A mail file is normally sent, but immediate messages
will be used for local users. If the message fails to
get through (e.g. Disconnected or Not Logged On), then
a mail file will be sent.
* Selects the default, EITHER.
format Sets the mail format to be used. This is optional, if no other
verbs follow this one. If omitted, the default is "*." The
formats are:
OLD RMSG.
NEW Netdata.
* Selects the default, NEW.
baddie Controls the action to be taken with a failed request file.
This is optional, if no other verbs follow this one. If
omitted, the default is "*." The actions are:
RETURN Return the request file to the sender.
DISCARD Purge the request file.
* Selects the default, RETURN.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The ANSWER override affects only the one request specified on the
command line, or all requests issued during this one TOOLS full screen
session.
2. Use the RESPONSE request verb to change response method for all
subsequent requests.
For example, to cause TOOLSRUN to send a response as both an immediate
message and as a class Z netdata mail file, and to discard the GET request
if it fails:
Command line example
TOOLS TO BLAH ANSWER Z BOTH NETDATA DISCARD GET FROG FORUM
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
• "TOOLS Request Verb RESPONSE" in topic 4.24.
Use the FOR override verb to issue a TOOLS request on behalf of someone else.
PRIV users may issue any request FOR another user. Otherwise, a user may generally issue any request for which they themselves are authorized, even if the FOR user is not authorized. Some disks restrict this general behavior, and there are some exceptions: SET ADDRESS will not change ownership of files FOR someone else; GET COPY and GET ASIS may not be done FOR someone else.
Format of the FOR OVERRIDE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ FOR user <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the FOR OVERRIDE verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
user The user on whose behalf you are issuing the request. This is
required. "user" must be in one of the following forms:
userid
node userid
userid AT node
The first form defaults to the current node, and is valid only
if no other verbs appear to the right on the command line.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The FOR override affects only the one request specified on the command
line, or all requests issued during this one TOOLS full screen
session.
| 2. The FOR override can help you recover from a common mistake: a typo
| in a SET ADDRESS. Just do another SET ADDRESS, FOR the erroneous
| node/userid, to the correct address. Note, however, that a PRIV user
| will have to help you if file ownership was involved.
| 3. In an emergency, a PRIV user may use the FOR override with BATCH
| RELEASE to release the requests for a particular user.
For example, to issue a GET request for JOEBLOW at NOWHERE:
Command line example
TOOLS TO BLAH FOR JOEBLOW AT NOWHERE GET FROG FORUM
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the NOCLOSE override verb to "stack" more than one request into a single request file.
Depends on the request verb.
Format of the NOCLOSE override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ NOCLOSE <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the NOCLOSE override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The NOCLOSE override is useful for ensuring that a given sequence of
requests arrive at the same time and in the proper order.
2. All requests stacked together into a single request file must be for
the same disk. The TOOLS EXEC does not check for this.
3. You may not mix SYSTEM (5) requests with DISK requests in the same
request file.
4. If you want to include a CMS request in a multi-request file, it must
be the last request in the file.
5. The NOCLOSE override leaves the virtual punch spooled CONTinuous.
If you specified the NOCLOSE override while entering TOOLS full screen
mode, requests will continue to be stacked until you exit TOOLS full
screen mode and:
Issue another TOOLS request without the NOCLOSE option (this
request will not be stacked with the previous requests)
-or-
Issue the following CP command:
SPOOL PUN CLOSE NOCONT
If you specified the NOCLOSE override on a command line request,
subsequent requests will be stacked as long as each request also has
the NOCLOSE override, until:
A command line request is issued without the NOCLOSE option (this
request will not be stacked with the previous requests)
-or-
You issue the following CP command:
SPOOL PUN CLOSE NOCONT
6. If a stacked request fails, all subsequent requests in the deck will
be ignored, and none of the requests in the deck will be propagated to
shadows of the disk.
7. Users with INFORM COPY in effect that matches a file updated by one
request in the deck will receive the entire deck.
For example, to create the FROG PACKAGE and the FROG EXEC (part of the
FROG PACKAGE) in one request file:
Command line example
TOOLS TO BLAH NOCLOSE CREATE FROG PACKAGE (HOPPING ASSIST
TOOLS TO BLAH NOCLOSE CREATE FROG EXEC (PART OF FROG PACKAGE
CP CLOSE PUNCH
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
(5) SYSTEM requests affect the ToolsRun service machine, rather
than any specific disk, and include: AGET, ALIST, AREPLACE,
CMS, LOGOFF, QUERY SYSTEM, QUERY USAGE, SHUTDOWN ALL,
SHUTDOWN FORCED and SHUTDOWN IMMEDIATE.
Use the NOCOPY override verb to inhibit the copying of change requests (e.g. CREATE or REPLACE) to other service machines.
You must have PRIV authority for the disk in order to issue the NOCOPY verb.
Format of the NOCOPY override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ NOCOPY <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the NOCOPY override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The NOCOPY request may be used only for disk-specific requests.
2. The NOCOPY request will usually result in the shadow disks becoming
different from the master copy.
3. The NOCOPY override affects only the one request for which it is
specified or, if full screen mode is entered, all requests issued
during that one full screen session.
4. NOCOPY is the opposite of PROPAGATE. Requests that cause changes on
the disk will usually be propagated to all of the shadows unless
NOCOPY is specified. (The disk NAMES file, disk HISTORY file and disk
CONTROL file will not be copied, so it is not necessary to use NOCOPY
for these.)
For example, consider a file called LOCAL EXEC. There is a LOCAL EXEC on
each disk in a conference, but each has been tailored to the local
installation. To replace LOCAL EXEC on the master, without disturbing the
files on each of the shadows:
Command line example
TOOLS TO BLAH NOCOPY REPLACE LOCAL EXEC (NEW VERSION
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the NODEID override verb to specify a preferred node.
Depends on the request verb. However, the preferred node must be known to Toolsrun as equated to your actual node.
Format of the NODEID OVERRIDE verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ NODEID node <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the NODEID OVERRIDE verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
node The preferred node. This is required. "node" must be one of
the following:
ACTUAL The actual node from which the request was sent is the
preferred node. (This will override a stored NODEID
value.)
GENERIC If generic node support is installed on the system,
RSCS is requested to treat the request as if coming
from the generic node defined by the system. (If the
request does not pass through RSCS, Toolsrun will
treat the request as if coming from the generic node
defined by the system.)
node RSCS is requested to treat the request as if coming
from node. (If the request does not pass through
RSCS, Toolsrun will treat the request as if coming
from node.)
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. On many systems, it is possible to log onto any of several nodes.
This means that your node, as seen by Toolsrun, may vary from one
logon session to another. The result can be multiple subscriptions
and a variety of nodes in append separators. If you prefer that all
requests appear to come from one node, you can specify that node with
the NODEID override.
2. You can find out if Generic Node Support is installed on your system
by typing IDENTIFY (GENERIC. If the return code is 24, Generic Node
Support is not installed on your system.
3. You can permanently specify your preferred node by typing the
following:
GLOBALV SELECT $userid SETLP NODEID node
where userid is your userid and node is the preferred node. This will
also affect other programs you use, such as SENDFILE and NOTE.
If you do this, you may find you need to override it on certain
requests. Use NODEID=ACTUAL to override.
For example, to issue an APPEND request with a preferred node of LEXGATE:
Command line example
TOOLS TO BLAH NODEID LEXGATE APPEND FROG FORUM (RIBET
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the NOPROMPT override verb to inhibit prompting by the TOOLS EXEC for the description. If the request requires a description and none is supplied, TOOLS will end without prompting for the description. The request will not be submitted.
Depends on the request verb.
Format of the NOPROMPT override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ NOPROMPT <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the NOPROMPT override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The NOPROMPT override is mainly useful when TOOLS is to be invoked
from within another exec. If the request requires a description, and
none is supplied, you want it to return to your exec instead of
prompting the user for the description.
2. The NOPROMPT override affects only the one request entered from the
command line, or, if full screen mode is entered, all requests issued
during that one full screen session.
3. When used in an exec that invokes TOOLS, NOPROMPT is often used in
conjunction with NOSCREEN and QUIET.
For example, you may be writing an exec that is to issue requests to the
BLAH disk. If the request requires a description, and none is supplied,
you want TOOLS to return to your exec without prompting the user:
Exec invocation example
'EXEC TOOLS SENDTO BLAHNODE BLAHID BLAH NOPROMPT' toolreq
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the NOSCREEN override verb to prevent the TOOLS exec from entering full screen mode. If TOOLS EXEC is unable to process the request, and the NOSCREEN override is specified, TOOLS will issue error messages and may prompt for the correct or missing information, but will not enter full screen mode.
Depends on the request verb.
Format of the NOSCREEN override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ NOSCREEN <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the NOSCREEN override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The NOSCREEN override is mainly useful when TOOLS is to be invoked
from within another exec. If TOOLS finds something wrong with the
request that you have passed to it, you want it to return to your exec
instead of entering full screen mode.
2. The NOSCREEN override affects only the one request issued in which it
is specified.
3. When used in an exec that invokes TOOLS, NOSCREEN is often used in
conjunction with NOPROMPT and QUIET.
For example, to CREATE POLLIWOG LISTING without entering full screen mode
(if the source file is not found, for instance):
Command line example
TOOLS TO BLAH NOSCREEN CREATE POLLIWOG LISTING (TADPOLE ADDRESSES
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the PROPAGATE override verb to force copying of the request to other service machines.
Depends on the request verb.
Format of the PROPAGATE override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ PROPagate <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the PROPAGATE override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The PROPAGATE override is used to force the service machine for the
disk to copy the associated request to all service machines that are
known to maintain a shadow of the disk. (Partial shadows are not
known to the service machine, and so the request will not be
propagated.)
CAUTION:
This override, when used with a request to a disk that has a lot of
shadows (such as IBMPC or IBMVM), can result in a large number of
files being returned to your reader.
2. PROPAGATE is the opposite of NOCOPY. Requests that do not change data
on the disk are not usually propagated, unless the PROPAGATE override
is specified.
3. PROPAGATE is often used by a file owner to get a list of all INFORMs
and SUBSCRIBEs for the file, on the master disk and all shadows:
TOOLS TO disk PROPAGATE QUERY INFORM fname ftype
4. PROPAGATE is often used by a PACKAGE owner to get copies of all of the
REQUESTS files from the master disk and all of its shadows. (The
pkgname REQUESTS file is a log of all GET requests and REGISTER
requests issued for the pkgname PACKAGE.)
TOOLS TO disk PROPAGATE GET pkgname REQUESTS
5. PROPAGATE might be used by a PRIV user to maintain identical disk
CONTROL files at the master and all shadows:
TOOLS TO disk PROPAGATE REPLACE disk CONTROL (UPDATES
6. PROPAGATE should not usually be used to force copying of the disk
NAMES file or disk HISTORY file.
7. The PROPAGATE override affects only the one request issued from the
command line, or, if TOOLS full screen mode is entered, all of the
requests issued during that one full screen session.
For example, to find out who has INFORMs and SUBSCRIBEs to the FROG EXEC
at the master and all shadows:
Command line example
TOOLS TO BLAH PROPAGATE QUERY INFORM FROG EXEC
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the QUIET override verb to suppress completion messages issued by TOOLS EXEC.
Depends on the request verb.
Format of the QUIET override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ QUIET <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the QUIET override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The QUIET override is useful when writing an exec that invokes TOOLS
if the exec is to issue its own messages.
2. When used with an exec that invokes TOOLS, QUIET is often used in
conjunction with NOPROMPT and NOSCREEN.
3. The QUIET override affects only the one request issued from the
command line, or, if TOOLS full screen mode is entered, all requests
issued during that one full screen session.
For example, to issue the GET request without TOOLS EXEC displaying:
Requesting a copy of "FROG EXEC"
GET request for disk BLAH sent to BLAHID at BLAHNODE (3333)
Command line example
TOOLS TO BLAH QUIET GET FROG EXEC
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the SENDTO override verb to specify the node, userid and disk name to which a request is to be sent.
Depends on the request verb.
Format of the SENDTO override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ SENDTO node userid disk <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the SENDTO override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
| node The node of the TOOLSRUN service machine. You may specify an
| asterisk (*) when the node is the same as yours. This is
required.
| userid The userid of the TOOLSRUN service machine. You may specify an
| asterisk (*) when the userid is the same as yours. This is
required.
disk The name of the disk maintained by the TOOLSRUN service machine.
This is required. If the request being issued is a SYSTEM
request, you may specify anything for "disk" (including "*") -
it will be ignored.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The SENDTO override is useful when writing an exec that invokes TOOLS.
No synonyms, GLOBALV information or DISK files need be set up so long
as the full address and name of the disk are known.
2. If you use the SENDTO override when entering TOOLS full screen mode,
and change the address using the full screen menu, this new address
will not be saved because TOOLS has no nickname with which to
associate the information.
3. The SENDTO override affects only the one request issued from the
command line, or, if TOOLS full screen mode is entered, all requests
issued during that one full screen session.
For example, to send a LIST request to the BLAH disk, maintained by BLAHID
at BLAHNODE:
Command line example
TOOLS SENDTO BLAHNODE BLAHID BLAH LIST * *
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the TO override verb to select a disk by nickname.
Depends on the request verb.
Format of the TO override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ TO disknick <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the TO override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
disknick The nickname of the disk. This is required.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. The TO override has the exact same effect as invoking the TOOLS EXEC
with a synonym of "disknick."
2. The TO override affects only the one request issued from the command
line, or, if TOOLS full screen mode is entered, all requests issued
during that one full screen session.
3. The TO override is commonly used with the DISK request to "teach"
TOOLS the address of a disk. For example, to set up the address of
the IBMMVS disk (managed by TOOLS at POKVMCR3), under the nickname
"MVS":
TOOLS TO MVS DISK IBMMVS TOOLS AT POKVMCR3
The address information is saved in your LASTING GLOBALV. The next
time that you want to address a request to the IBMMVS disk, just
enter:
TOOLS TO MVS
and TOOLS will remember that this is the IBMMVS disk, managed by TOOLS
at POKVMCR3.
For example, to enter a full screen session for the BLAH disk:
Command line example
TOOLS TO BLAH
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
Use the TRACE override verb to cause execution of the associated request to be traced at the TOOLSRUN service machine.
| You must have at least GETTER authority to use TRACE at all, plus you must | be authorized to issue the request being traced.
Format of the TRACE override verb on the command line: ┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ TRACE <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘ Format of the TRACE override verb on the TOOLS full screen: Override request verbs may not be issued from the TOOLS full screen.
other-overrides Other override verbs. These are optional, and may appear
in any order.
request A TOOLS request verb, with appropriate parameters and options.
A request verb is optional. If omitted, you will be placed into
the TOOLS full screen mode.
None.
1. CAUTION:
The TRACE override generates voluminous data and seriously slows
operation of the service machine.
You should use the TRACE override only when specifically directed to
by a TOOLSRUN maintainer.
2. If the TOOLSRUN software is compiled, it cannot be traced.
3. The TRACE override affects only the one request issued from the
command line, or, if TOOLS full screen mode is entered, all requests
issued during that one full screen session.
For example, to trace execution of the QUERY VERSION request:
Command line example
TOOLS TO BLAH TRACE QUERY VERSION
TOOLS full screen example: Override request verbs may not be issued from
the TOOLS full screen.
This is a summary of the complete TOOLS request and override verb formats.
┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ <overrides> AGEt fname ftype <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> ALIst fnpat ftpat <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> APPend fname ftype <fmode> <place> <(subject> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> AREplace fname ftype <fmode> <(reason> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> BATch CANCEL <fnpat ftpat> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> BATch QUERY │ ├──────────┼─────────────────────────────────────────────────────────────┤ | │ TOOLS │ <overrides> BATch RELEASE fnpat ftpat │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> BATch RELEASE <method> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> CLEan type <days> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> CMS cmd │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> COPy fnpat ftpat <fmode> node userid disk │ │ │ <date> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> CREate fname ftype <fmode> (descr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> DISK name <userid <AT node>> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> ERAse fname ftype <fmode> (reason │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> GET fnpat ftpat <fmode> <COPY> <date> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> HELp <ALL> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> HIDe fname ftype <fmode> (reason │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> INForm fnpat ftpat <fmode> <infotype> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> LISt fnpat ftpat <fmode> <COPY> <date> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> LITeral cmd (descr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> LOCk fname ftype <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> LOGoff │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> NEWown fname ftype <fmode> newaddr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> NOTify <ALL> (msgtext │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> OWN fname ftype <fmode> (descr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> PLAce fname ftype <fmode> <(file description> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> PRUne fname ftype <fmode> before <disp> (reason │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> PUNchtag <taginfo> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry DISK │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry <FILE> fname ftype <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry INFORM <fname ftype <fmode> > │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry SYSTEM │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry USAGE │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> QUEry VERSION │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> REFresh fnpat ftpat <fmode> <date> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> REGIster fname <copies> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> REGRess fname ftype <fmode> (reason │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> RENew │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> REPlace fname ftype <fmode> (reason │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> RESponse class <how <format <baddie>>> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SET <ADDress> newaddr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SET <DEScription> fname ftype <fmode> (newdescr │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SET <FILe> fname ftype <fmode> newfn newft │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SET <MODe> fname ftype <fmode> newmode │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SHUtdown <when> <(reason> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> STArt │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SUBscribe fnpat ftpat <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> SUMmary fnpat ftpat <fmode> <COPY> <date> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> UNInform fnpat ftpat <fmode> <EVERY <infotype> │ │ │ > │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> LOCk fname ftype <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> UNSubscribe fnpat ftpat <fmode> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> UPDate fname ftype <fmode> (reason │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ <overrides> VOTe fname token │ └──────────┴─────────────────────────────────────────────────────────────┘
┌──────────┬─────────────────────────────────────────────────────────────┐ │ TOOLS │ ANSwer class how format baddie <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ FOR user <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ NOCLOSE <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ NOCOPY <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ NODEID node <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ NOPROMPT <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ NOSCREEN <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ PROPagate <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ QUIET <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ SENDTO node userid disk <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ TO disknick <other-overrides> <request> │ ├──────────┼─────────────────────────────────────────────────────────────┤ │ TOOLS │ TRACE <other-overrides> <request> │ └──────────┴─────────────────────────────────────────────────────────────┘
There is a strong similarity between what the user types in and what the TOOLS EXEC sends on to TOOLSRUN. However, there are some important differences. See TOOLSRUN Request File Language Reference for a cross reference between the two formats.
These topics provide more detail on material covered elsewhere in this document:
This is a brief discussion of TOOLSRUN authorizations.
Information on how to set up or change authorizations for a particular
disk is beyond the scope of this document. (See TOOLSRUN Control File
Language Reference.)
In order to issue a TOOLS request to a disk, you must have the proper
authorization for that request. There are three requests that generally
do not require authorization:
HELP
QUERY VERSION
NOTIFY
There are also three TOOLS requests that do not do not send request files
to a TOOLSRUN service machine, and so do not require authorization:
DISK
PUNCHTAG
RESPONSE
In addition, the LITERAL TOOLS request verb does not itself require any
authorization. Authorization applies to the TOOLSRUN command being passed
via LITERAL.
All other requests require that the person responsible for the disk set up
some kind of authorization.
In general, TOOLS override verbs do not require any authorization to use -
authorization applies only to the TOOLS request verb modified by the
override verb. There is one exception:
NOCOPY You must have PRIV authority for the disk to use the NOCOPY
override verb.
Authorizations serve two purposes:
• To protect files from accidental or malicious tampering and
• To restrict access to classified information.
Conference disks may be set up as open or restricted:
Open Any person who has a VM userid and access to the TOOLS EXEC (or
some facsimile thereof) can issue LIST and GET requests to an
open conference, and usually most other requests.
Restricted Only those persons who have been granted specific authorization
may issue requests to a restricted conference.
The level of authorization controls what requests may be issued. It is
possible for a disk maintainer to set up some exotic authorization levels,
but here are the "plain vanilla" ones:
ACCESSER has no authority for the disk, and is shut out. Restricted
conferences use ACCESSER * * to shut out all except those with
specific authorizations. (The TOOLSRUN default is ACCESSER * *,
but it is often specified anyway.) This is primarily used to
restrict individuals or nodes from broader authorizations (e.g.
OWNER * *).
GETTER may issue read-only type requests - those which do not alter
data on the disk (other than log files). Examples are LIST,
GET, INFORM and SUBSCRIBE.
APPENDER may issue APPEND and VOTE requests.
REPLACER may not create new files, but may generally alter, rename and
transfer ownership for all owned files. This requires that
someone else create the files and then transfer ownership.
PACKAGER may create only files with a filetype of PACKAGE, and files
whose name he owns. All unowned files referenced by a PACKAGE
file become owned by the person who creates the PACKAGE file.
OWNER may create new files and freely manipulate and erase any owned
files.
PRIV may issue any request for the disk. Persons who are responsible
for maintaining the disk will have PRIV authority.
SYSTEM may issue SYSTEM requests to the TOOLSRUN service machine.
System authority does not imply any other authority - without
some other authorization in addition to system, the person may
not issue any requests to any of the disks maintained by the
TOOLSRUN service machine. Persons with system authority are
responsible for maintaining the service machine itself.
ADDER is not a level of authorization, but instead modifies other
authorizations.
The owner of a file may always issue APPEND requests for that
file, so long as he has at least APPENDER authority. ADDER is
used to allow others to append to files, so long as they have at
least APPENDER authority. ADDER is usually restricted by
filetype - only certain filetypes are appendable. This usually
includes FORUM files, but may include other types of files.
When a file is created on a disk, and its filetype is one of
those listed on an ADDER card for that disk, the INFORM messages
announcing its creation have the phrase "and is publicly
appendable," and a "Created by" line is added to the top of the
file.
Your level of authorization may be further restricted by filetype. For
example, you may be authorized to LIST and GET files with a filetype of
EXEC, SCRIPT and DATA, but be authorized to CREATE only files with a
filetype of DATA.
At the bottom of the TOOLS full screen menu is a field in which CMS commands may be entered. This allows you to edit files, rename files, etcetera, without exiting the full screen session, or processing the other fields on the menu.
│ │ │ │ │ │ │ │ │ │ │ Any CMS command ==> cmd │ │ │ │ PF1=Help PF3=Quit ENTER=Send request PF5=Send then quit PF6=Alter address │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
The Filename/Type fields do not affect CMS commands.
cmd Is the full text of the CMS command and its parameters and
options. If specified, the rest of the fields on the menu will
be updated, but will not be processed by TOOLS EXEC.
If you enter "?," the previous CMS command is retrieved and
displayed in the CMS command line area.
Overrides do not affect CMS commands.
The description field does not affect CMS commands.
The details field does not affect CMS commands.
1. You are limited to two lines of text: The line followingAnyCMScommand==>and the next line. 2. CMS commands entered in the CMS command line area do not affect TOOLS requests being processed during the full screen session. 3. If you use a CMS command to rename or otherwise affect a file that has already been processed by TOOLS in the full screen session (e.g. a CREATE or REPLACE request), the text sent with the request is not affected by the CMS command - it has already been sent or stacked.
For example, you remember that FROG AVAIL is incorrect, and you have already stacked the CREATE requests for FROG PACKAGE and all of the other associated files. (The CREATE request for FROG AVAIL has not yet been stacked, however.) You can edit FROG AVAIL without leaving the full screen session: │ │ │ │ │ │ │ │ │ │ │ Any CMS command ==> XEDIT FROG AVAIL │ │ │ │ PF1=Help PF3=Quit ENTER=Send request PF5=Send then quit PF6=Alter address │ │ │ └─────────────────────────────────────────────────────────────────────────────────┘
This is a brief discussion of TOOLSRUN conferencing and the use of TOOLS
requests to participate.
Information on how to set up a TOOLSRUN service machine and TOOLSRUN
maintained disks is beyond the scope of this document. (See TOOLSRUN
Control File Language Reference.)
TOOLSRUN TOOLSRUN is a program, written in the REXX language, that runs
continuously on a disconnected service machine. TOOLSRUN is
used to maintain one or more disks that are just like the VM
minidisks that you link and access while performing your job on
VM. Your A-disk and the CMS operating system's S-disk are
examples.
TOOLSRUN accepts commands, in the form of request files, that
allow users to manipulate data on its maintained disks. Data is
stored as files and users may create these files, erase them,
modify them, get copies of them, list them, and so on.
The TOOLSRUN service machine is a VM userid, at a network node,
just like your VM userid and node. However, there is rarely a
human logged onto the service machine. Therefore, you cannot
expect it to answer if you send notes, PROFS notes or messages,
like you would send to an associate or co-worker. TOOLSRUN
request files must be in a special format that TOOLSRUN can
understand.
TOOLS TOOLS is a program, also written in the REXX language, that puts
your requests into the format expected by TOOLSRUN and sends
them to the service machine of your choice.
TOOLSRUN CONFERENCES A TOOLSRUN conference is just a disk, maintained by a
TOOLSRUN service machine. Users place data on the disk, thereby
making the data available to all other users of the conference
disk. The data may be in the form of whole files, addenda to
files (called appends) or collections of files (called
packages).
A conference disk may be open to anyone, or may be restricted to
persons with a need to know about the (often confidential) data
stored on the conference disk.
If you are authorized to access a particular conference disk,
you can issue:
LIST requests to find out what files are on the disk and
GET requests to obtain copies of those files.
Usually, if you can issue LIST and GET requests, you can also
issue:
INFORM requests to receive notification of changes to files
or creation of new files and
SUBSCRIBE requests to receive copies of changed or new
files.
However, on some disks, you may not be permitted to issue
SUBSCRIBE requests, and on other disks you may not be permitted
to issue either SUBSCRIBE or INFORM requests.
Depending upon the way the disk is set up, you may also be able
to:
CREATE new files on the disk,
REPLACE old files that you own with an updated version and
ERASE old files that are no longer needed.
Certain files may be set up as appendable files. You may issue:
APPEND requests to add some text to these files.
LIST, GET, INFORM, SUBSCRIBE, CREATE, REPLACE, ERASE and APPEND
are all TOOLS requests. You invoke the TOOLS EXEC to issue
those requests. TOOLS sends them to the TOOLSRUN service
machine in a form that it can understand.
DISK ADDRESSES Every disk maintained by a TOOLSRUN service machine has a
disk name. When you send a request, you specify the disk name,
so that the TOOLSRUN service machine will know which disk you
intend the request to go to.
You also need to know the userid and node of the TOOLSRUN
service machine, so that the request is sent to the right
service machine.
Thus, the disk address consists of the disk name and the userid
and node of the TOOLSRUN service machine that maintains the
disk.
SHADOWS and MASTERS TOOLSRUN maintained disks are just VM minidisks. With
proper authority, anyone at the same VM node as the TOOLSRUN
service machine can link and access the disk, and view the files
directly. This is more convenient than issuing LIST requests to
find out what is on the disk, waiting for the response, and then
issuing GET requests to obtain copies of files that look like
they might be of interest.
Many of the more popular conference disks are set up with shadow
disks at several locations. A shadow disk is a TOOLSRUN
maintained disk that is an exact copy of a disk maintained by
some other TOOLSRUN service machine (called the master). Every
time the master disk is changed, the master service machine
sends instructions and data to the shadow service machine, so
that the shadow disk is updated.
Thus, users can link and access the shadow disk at their
location, and see the same data that users at the master
location can see. They can issue LIST, GET, INFORM and
SUBSCRIBE requests to the shadow disk. CREATE, REPLACE, APPEND
and ERASE requests must be directed to the master disk.
Note that all TOOLSRUN service machines are the same. Only
disks are designated as masters or shadows. One service machine
may well maintain several disks, some of them masters and some
of them shadows.
Note also that some appendable files are shared between two (or
more) conference disk masters. And note that some disks are
partial shadows - they contain copies of some, but not all, of
the files on the master. A disk may even be a partial shadow of
more than one master. See "Partial Shadows and Shared Forums"
in topic B.12 for more information.
FINDING DISK ADDRESSES Here are some popular conference disks:
Disk Userid Node Description of the Disk
IBMVM IBMVM KGNVMCB VM conference
IBMPC IBMPC YKTVMV IBM Personal Computer
Conference
IBMMVS TOOLS POKVMCR3 MVS conference
IBMDISKS TOOLSX FSHVMFK1 A collection of lists and
catalogs for most public
conference disks
If you have a copy of OMNIDISK NAMES or CONFEREN DISKS on some
disk at your location, you can use them to find the addresses of
other conference disk masters.
FINDING SHADOW ADDRESSES Many conference disks will contain a file called
"disk-name SHADOWS." You can use this file to find out if there
is a shadow at your node.
Even if there is no shadow right at your node, you should still
try to use a shadow, if there is one closer to you than the
master disk. Response time will be faster for GET and LIST
requests, both because of the shorter network path, and because
popular master disks tend to process many requests each day.
If you have a copy of SHADOW NAMES on some disk at your
location, you can use it to find the addresses of local shadows.
If you send a request to a master disk, and get a response from
some other toolsrun machine, you should direct future requests
to that machine. This is known as "load shedding" - the master
machine has passed your request to a shadow machine near you,
rather than filling the request itself.
Many TOOLS requests call for a date, as a required or optional detail.
For example, you may wish to GET all files created or changed after
January 1st, 1990. Or you may wish to modify an append that you made on
February 22nd, 1989.
The date may be specified in one of two ways: Append header form and
TOOLSRUN standard form.
APPEND HEADER FORM This is the date as shown in the append headers added
by TOOLSRUN.
• It contains both a date field and a time field. For
example: 12:30:12 on 85/08/27.
• "on" may be omitted. For example, the above date could be
expressed as: 12:30:12 85/08/27.
• The date and time may be in reverse order. To continue the
example: "85/08/27 12:30:12."
• The colons (but not the slashes) may be omitted: 85/08/27
123012 or 123012 85/08/27.
• Some or all of the time field may be omitted: 85/08/27 1230
or 85/08/27 12 or just 85/08/27. The remainder will be
padded with zeroes.
• You may also specify TODAY for the date field. Today's date
will be used in the TOOLS request.
TOOLSRUN STANDARD FORM This is the form that TOOLSRUN uses internally. It
is an 8 to 14 digit field of the form: YYYYMMDD<HH<MM<SS>>>.
For example, a date of August 27th, 1985 and a time of 12:30:12
would be expressed as: 19850827123012. Some or all of the time
field may be omitted: 198508271230, 1985082712 or just 19850827.
The remainder will be padded with zeroes.
You may specify the disk address to be used by TOOLS EXEC by setting up nickname information beforehand and then using the nickname when you invoke TOOLS EXEC, by specifying a nickname when you invoke TOOLS EXEC and then supplying the information in the TOOLS full screen session or by specifying the full address (using the SENDTO override) along with the TOOLS invocation.
1. If you use a disk nickname when invoking TOOLS EXEC, the disk address
is obtained from the first of the following sources where the nickname
is encountered:
LASTING GLOBALV
userid DISKS
node DISKS
TOOLS DISKS
OMNIFIND is used to search for information about the disk. See
the help for OMNIDISK (enter OMNIDISK ?). The search includes the
following files:
OMNIDISK NAMES
SHADOW NAMES
userid NAMES
CONFEREN DISKS
where "userid" is your CMS userid and "node" is your VM node.
If the nickname is not encountered in any of these sources, some
defaults will be assumed. You must use PF6 (in the full screen
session) to alter this address, or use the DISK override on the TOOLS
invocation.
See "Specifying disk nicknames" in topic B.8 for information on the
DISKS files.
2. If you use the DISK override with a nickname, the disk address will be
stored in your LASTING GLOBALV file to be retrieved by the next TOOLS
reference to that nickname. This is the simplest, and probably the
most common, method of "teaching" TOOLS a disk address.
For example, the first time you invoke TOOLS for the IBMMVS shadow
disk in Lexington (managed by TOOLS at LEXCJN1), you would enter:
TOOLS TO MVS DISK IBMMVS TOOLS AT LEXCJN1
and the address information for the nickname "MVS" would be stored in
your LASTING GLOBALV. The next time you want to invoke TOOLS for this
disk, you would simply enter:
TOOLS TO MVS
and the information would be retrieved from your LASTING GLOBALV.
Later, you decide that you need to address requests (e.g. APPENDs) to
the IBMMVS master disk (managed by TOOLS at POKVMCR3). You are
already using the nickname "MVS" for the shadow, so you choose a
nickname of "MVSMAS" and set it up as follows:
TOOLS TO MVSMAS DISK IBMMVS TOOLS AT POKVMCR3
and you would address subsequent requests as simply:
TOOLS TO MVSMAS
3. You can specify the disk name and address with the SENDTO override.
However, if you alter the address from within the TOOLS full screen
session, the new address will not be saved.
4. You can alter the disk name, node and userid from within a TOOLS full
screen session by pressing PF6. You can specify just a nickname, in
which case TOOLS will search LASTING GLOBALV, and so on, until it
finds the information. The new information will be presented for you
to verify.
Using PF6: When you first enter the TOOLS full screen menu, you will see
the following on the screen:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> nickname (name disk managed by diskid at disknode) │
│ │
│ │
│ │
│ Request ==> ? Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
where nickname is the disk nickname that you selected. (If you did not
select a nickname, the default is TOOLS.) name is the disk name. diskid
and disknode are the userid and node of the TOOLSRUN service machine that
manages the disk. You can alter the nickname, but not the disk name, disk
userid or disk node.
When you press PF6, another line appears on the screen, along with a
message:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ Disk/Conference ==> nickname │
│ │
│ Disk name ==> name managed by diskid at disknode │
│ │
│ Request ==> ? Details: │
│ │
│ Filename/Type ==> ? ? * │
│ │
│ Description ==> │
│ │
│ │
│ │
│ Please check that the address shown is correct for the disk │
│ nicknamed nickname. If it is wrong, please change it now │
│ before proceeding. │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
You can now type over name, diskid and disknode. When you press ENTER,
the new disk address information is saved.
Changing the disk nickname: When you type over the disk nickname and
press ENTER, you will see the same additional line and message as for when
you use PF6 to change the disk address.
For example, to select the BLAH disk, maintained by BLAHID at BLAHNODE:
TOOLS SENDTO BLAHNODE BLAHID BLAH
The help facility for TOOLS is extensive, and therefore can be confusing. This is a brief discussion of how to use the CMS HELP command to best advantage. For more detailed information about CMS HELP, enter HELP HELP.
If you know the name of the topic for which you want HELP, just enter
HELP TOOLS topic
If you do not know the name of the topic, there are several task menus
that will present a list of topics. If you enter
HELP TOOLS TASK
you will see a complete menu of all TOOLS help topics. (Note that some of
these topics are actually menus - the names begin with a colon, such as
:General.) Move the cursor to the line containing a topic in which you
are interested, and press PF1 or ENTER. You will see the help for that
topic.
If you are interested only in a general request verb, a system or
privileged request verb, an override verb or a special topic, you can see
a shorter menu containing just those topics by entering:
HELP TOOLSGEN TASK for general verbs,
HELP TOOLPRIV TASK for system and privileged verbs,
HELP TOOLOVER TASK for override verbs or
HELP TOOLSPEC TASK for special topics.
You may have noticed that most of the topics you see appear first as a
brief description - a description of the verb and an example of its use.
To switch from the brief description to the detailed description, press
PF1. (PF1 will also switch you back from the detailed description to the
brief description.)
Often, the brief description is all that you need. However, many people
will want to see the detailed description every time, and will tire of
pressing PF1.
You can control which section you see when you invoke HELP:
HELP TOOLS topic (BRIEF
HELP TOOLS topic (DETAIL
You can also set your HELP default:
DEFAULTS SET HELP SCREEN DETAIL
DEFAULTS SET HELP SCREEN BRIEF
Then, you will not have to specify BRIEF or DETAIL each time you invoke
HELP. Furthermore, you will get the desired section when you select a
topic from one of the task menus.
The detailed help section actually has several parts:
DESCRIPT The description.
FORMAT The format or syntax.
PARMS The parameters.
OPTIONS The options.
NOTES The usage notes.
ERRORS Error messages (not used in TOOLS help).
ALL All of the above.
You can specify one or more of these when you invoke HELP for a topic:
HELP TOOLS topic (DETAIL FORMAT
HELP TOOLS topic (DETAIL DESCRIPT NOTES
Some of the special topics do not have all of these sections.
PF3 will return you to the previous HELP screen. PF4 will exit all of the HELP screens.
Every topic has a list of related topics. From the brief description or detailed description section, you can switch to the related topics menu by pressing PF11. From the related topics menu you can go to the detailed description by pressing PF10 and the brief description by pressing PF11. A related topics menu is just like a task menu. Move the cursor to the desired topic and press ENTER or PF1. In general, if a topic references another topic in its description, the other topic will appear in the list of related topics.
If the TOOLSRUN service machine is enabled to receive them, you can send CP SMSG messages from the CMS command line, containing TOOLSRUN commands.
Depends on which TOOLSRUN command you are sending.
┌──────────────┬─────────────────────────────────────────────────────────┐ │ <CP> SMsg │ toolsid :<disk> cmd │ └──────────────┴─────────────────────────────────────────────────────────┘
toolsid The userid of the TOOLSRUN service machine. This is required.
disk The disk for which the command is being sent. This is optional.
If omitted, the command will be sent as a SYSTEM command to the
TOOLSRUN service machine system. (A blank must separate the
SYSTEM command from the colon.)
cmd The TOOLSRUN command being sent, and all of its parameters.
You cannot specify overrides when sending TOOLSRUN commands as messages.
You cannot specify a description when sending TOOLSRUN commands as messages.
None.
1. SYSTEM commands sent as CP SMSG messages are ordered ahead of all
other pending request files, and so will take effect after the current
file is processed.
2. You can send only commands that are complete within one line. This
means that you can send only commands that:
• Do not require a description and
• Do not require data (such as a CREATE or REPLACE command).
Some commands for which TOOLS requires a description do not require a
description when sent directly to TOOLSRUN.
3. The commands must be in TOOLSRUN form, not TOOLS form. This means:
• The general form is: command fileid details
• Abbreviations are not allowed.
• Dates must be in TOOLSRUN standard form: YYYYMMDD<HH<MM<SS>>>.
• For commands that return data, you must specify the method by
which the data is to be sent:
NETDATA
ASIS
COPY
• Addresses must be in the form node userid.
• Synonyms are not recognized. For example, SUBSCRIBE is a synonym
for INFORM SUBSCRIBE and UNSUBSCRIBE is a synonym for UNINFORM,
and thus are not permitted.
The complete description of request syntax expected by TOOLSRUN may be
found in TOOLSRUN Control File Language Reference.
For example, to list all of the files on the BLAH disk maintained by
BLAHID at your VM node, and to find out the version of TOOLSRUN used by
BLAHID:
CP SMSG BLAHID :BLAH LIST * * NETDATA
CP SMSG BLAHID : QUERY VERSION
You may invoke TOOLS with a disk nickname, thereby saving yourself some typing and reducing the chance of accidentally entering the wrong disk address. You may specify a disk nickname when invoking TOOLS EXEC. If the disk address has already been set up, TOOLS will automatically retrieve it. If it has not already been set up, you may alter the address from within the TOOLS full screen session. The new address will be stored in your LASTING GLOBALV file, so that the next time you specify the nickname, TOOLS will get the correct address.
1. You can use the TO override to specify the disk nickname when you
invoke the TOOLS EXEC.
2. You can set up the nickname as a synonym for the TOOLS EXEC. When
TOOLS is invoked using this synonym, the nickname will be used to
obtain address information.
3. You can type a nickname in the Disk/Conference ==> field on the TOOLS
full screen menu.
4. If you use a disk nickname when invoking TOOLS EXEC, the disk address
is obtained from the first of the following sources where the nickname
is encountered:
LASTING GLOBALV
userid DISKS
node DISKS
TOOLS DISKS
OMNIFIND is used to search for information about the disk. See
the help for OMNIDISK (enter "OMNIDISK ?"). The search includes
the following files:
OMNIDISK NAMES
SHADOW NAMES
userid NAMES
CONFEREN DISKS
where "userid" is your CMS userid and "node" is your VM node.
If the nickname is not encountered in any of these sources, some
defaults will be assumed. You must use PF6 (in the full screen
session) or the DISK override (on the TOOLS invocation) to alter this
address.
Address information in DISKS files is specified as follows:
a. Any line beginning with a blank is a comment and is ignored.
b. Any line beginning with a character that is not alphabetic or
numeric is a comment and is ignored.
c. Any line beginning with an alphabetic or numeric character is
assumed to contain disk address information. The first word is
the disk name, the second word is the TOOLSRUN service machine's
userid and the third word is the TOOLSRUN service machine's node.
Anything after the third word is assumed to be comments and is
ignored.
For example:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ CONFEREN DISKS - a list of conferences │
│ │
│ Disk Address │
│ Name Userid at Node Contents │
│ ----------------------------------------------- │
│ PC TOOLS CENTRAL Discussions relating to PCs │
│ GIFTS TOOLS NPOLE Suggestions for Xmas gifts │
│ SPELEO TOOLS MENDIP Conference for computish cavers │
│ REXX REXTOOLS WESSEX A place for REXX bigots to chat │
│ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
For example, if you have set up address information for the BLAH disk,
maintained by BLAHID at BLAHNODE, under the nickname MYBLAH, you may
invoke TOOLS EXEC with the MYBLAH nickname:
TOOLS TO MYBLAH
Many TOOLS requests permit a pattern to be specified for the filename and
filetype. These are read requests - they do not write data to the target
disk (although the request may cause one or more files to be written to
some other disk: e.g. the COPY request or GET COPY).
1. A filename or filetype pattern contains leading and/or trailing
asterisks (*). The asterisk represents any number of characters
(including none). Possible combinations and their meanings are:
* All filenames or filetypes.
*string All filenames or filetypes ending in "string."
string* All filenames or filetypes beginning with "string."
*string* All filenames or filetypes containing "string."
2. An asterisk may not appear in the middle of a pattern: AB*CD is not
valid.
3. TOOLS filename and filetype patterns are similar to the patterns for
the CMS LISTFILE command, except that "%" is not permitted.
Some examples:
GET FROG * will GET all files with a filename of FROG.
COPY * EXEC will COPY all files with a filetype of EXEC.
LIST * * will LIST all files on the disk.
SUMMARY ABC* DEF will return a summary of all files whose filename
begins with "ABC" and whose filetype is "DEF."
This would include:
ABC DEF
ABC01 DEF
GET *01 MODULE will GET all files whose filename ends in "01" and
whose filetype is "MODULE."
This would include:
01 MODULE
FOO01 MODULE
LIST *AB* * will LIST all files with "AB" in the filename.
This would include
AB PACKAGE
CAB EXEC
ABC INFO
CABLE SCRIPT
TOOLSRUN supports the concept of a package of files. A package is a file,
whose filetype is PACKAGE, which consists of a list of files. Files
grouped together as a package can be treated in many ways as a coherent
group of files. In particular:
• A GET request for a PACKAGE file will automatically GET all the files
listed in the package.
If any of those files are, in turn, PACKAGE files, you will get them,
but not get their contents unless the person who created the original
PACKAGE file requested it (by specifying a filemode of @).
If you want just the PACKAGE file itself, use PACKAGE* as the
filetype.
A GET request will also be logged in a REQUESTS file. This allows the
package owner to gather statistics, perhaps to justify the amount of
time spent developing and maintaining the package.
• If you INFORM to a package, then you will receive notifications of
changes to the contents of the package. However, you will not be
informed of changes to the contents of PACKAGE files referenced by the
package.
• If you SUBSCRIBE to a package, then you will also be subscribing to
the contents of the package. However, you will not receive copies of
changes to the contents of PACKAGE files referenced by the package.
• A CREATE of a PACKAGE file will OWN any files referenced by the
package, if they are not already owned by someone else. (However, you
cannot own another PACKAGE file, disk control file or any mode zero
file in this way.)
• A REPLACE of a PACKAGE file will OWN any files new to the package (if
they are not already owned) and HIDE any files removed from the
package list, if this is the last PACKAGE file to reference them and
if they did not exist prior to the creation of any PACKAGE file.
(However, you cannot own or erase another PACKAGE file, disk control
file or any mode zero file in this way.)
If the PACKAGE file is again replaced without restoring the reference
to a hidden file, it is erased.
If the PACKAGE file is replaced, with a restored reference to a hidden
file, it is regressed.
• A PLACE of a PACKAGE file will behave as CREATE or REPLACE, depending
upon whether the package file is created or replaced by the PLACE.
• Sending a HIDE request for a PACKAGE file will also hide files that
are referenced only by that package.
• If the PACKAGE file is REGRESSed, referenced files will be owned,
regressed or hidden, as appropriate to the list in the backup or
hidden copy of the package.
• If the PACKAGE file is ERASEd, files referenced only by it will be
erased, if they did not exist prior to being referenced by any
package. (However, you cannot erase another PACKAGE file, disk
control file or any mode zero file in this way.)
• The QUERY FILE request for any file returns a list of packages in
which that file is referenced.
• APPEND and SET FILE are not permitted for PACKAGE files.
• If you have obtained a copy of a package without using the GET
request, you should register this fact with the REGISTER request.
This allows the package owner to gather statistics about the use of
the package, perhaps to justify the amount of time spent developing
and maintaining the package. Some owners may require registration in
order to provide support for problems and questions about their
package.
Disks may be set up so that files can only be placed on the disk if they
are already listed in a PACKAGE file. This is useful for good control of
tools repository disks. Alternatively, PACKAGE files may be used on any
disk together with individually owned files. Any file may be listed in a
package, so (for example) you may have packages of FORUMs.
Each line in a PACKAGE file is either a comment or a file reference.
Comment lines (those whose first non-blank character is an asterisk) and
blank lines are ignored by TOOLSRUN. The file reference lines consist of
three significant words, and anything after the first three words is
ignored (treated as a comment). The three words of a file reference are a
filename, a filetype, and a filemode. In a TOOLS package, the filemode
must either be "*," implying use of the file on the disk, or it may be an
"@" (at) symbol. The "@" symbol indicates that the file described is
itself a list of files (in the same format), and those files should be
treated as part of the package. (That list of files may also include
references to further lists.)
The PKGEDIT package may be used to create or modify a PACKAGE file, and
send it (and the files it references) to the disk. PKGEDIT will
automatically build a comment header with fields recognized by CATGEN.
The CATGEN package may be used to generate a catalog of packages. The
TOOLCAT package may be used to view such catalogs and issue GETs,
SUBSCRIBEs etcetera, for the packages. PKGEDIT, CATGEN and TOOLCAT are
all available from the VMTOOLS disk, managed by VMTOOLS at RALVM17.
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ │
│ ********************** IBM Internal Use Only **********************│**
│ * :nick.PKGEDIT :sec.IBM Internal Use Only :disk.VMTOOLS │
│ * :title.Package Editing and Submission Facility │
│ * :version.1.71 :date.90/10/26 :summary.ANNOUNCE :support.N │
│ * :oname.Bob Ramsey :onode.TUCVM8 :ouser.RAMSEY │
│ * :aname.B. D. (Bob) Ramsey :anode.TUCVM8 :auser.RAMSEY │
│ * :ops.VM :lang.REXX :source.Y │
│ * :doc.HELPCMS │
│ * :kwd.Package Tools │
│ * :abs.PKGEDIT supports editing of PACKAGE files. It can reformat an│
│ * existing package file to standard format. The package can then be │
│ * sent to the selected TOOLS disk. Detailed HELP is provided to guid│
│ * the new user through the process. │
│ * :lic.By placing material on this conference, I agree to grant │
│ * IBM a non-exclusive, royalty-free license for the material │
│ * as set forth in the LICENSE AGREEMNT file on this conference. │
│ *********************************************************************│**
│ PKGEDIT ANNOUNCE * Overview of PKGEDIT capabilities and featur│s
│ PKGEDIT CHANGES * List of recent changes to PKGEDIT │
│ PKGEDIT INSTALL * Installation instructions │
│ PKGEDIT EXEC * The PKGEDIT cover EXEC │
│ PKGEDIT XEDIT * The heart of PKGEDIT │
│ PKGEDIT HELPCMS * Help for PKGEDIT │
│ PKGEDIT SAMPPROF * Sample PKGEDIT user profile │
│ PKGDESC SAMPEXEC * Sample package description user exit │
│ PKGSTAT SAMPEXEC * Sample package status user exit │
│ TOOLLOOK EXEC * Shows PKGEDIT disk address resolution │
│ TOOLLOOK HELPCMS * Help for TOOLLOOK │
│ │
│ │
└────────────────────────────────────────────────────────────────────────┘
Figure 5. A typical PACKAGE file. All of the fields within the comment
header are used by CATGEN to generate a catalog of PACKAGE files
that may be viewed with TOOLCAT. TOOLSRUN ignores these fields.
You are getting subscriptions and/or inform messages and you don't know how to shut them off. This topic explains how.
With UNSUB: The easiest way to cancel a subscription is by using UNSUB -
a tool written by Glenn Knickerbocker. Look for a file called "UNSUB
XEDIT" somewhere on your system. If it isn't there, you can order it from
VMTOOLS:
TOOLS SENDTO RALVM17 VMTOOLS VMTOOLS GET UNSUB PACKAGE
Once you have UNSUB XEDIT on some disk, do the following:
PEEK a subscription file.
On the command line inside the PEEKed file, enter UNSUB.
If you want to cancel all of your subscriptions, enter UNSUB ALL.
If you want to find out what subscriptions you have in effect, enter
UNSUB QUERY.
Without UNSUB: For various reasons, UNSUB might not work for you. The
rest of this text describes what to do.
The procedure is complicated, but not impossible. I am assuming that you
are not a PROFS user, or at least that PROFS has not taken the files out
of your reader.
The following procedure is lengthy, because I have to cover lots of
different cases. Take your time and read enough of each part to be sure
it does not apply to your case before skipping over it. You may need to
re-read it a couple of times to make sure you have everything. As you
find the various pieces of information, WRITE THEM DOWN.
What you need to know before you can cancel anything:
1. You must know the disk name, and you must know the node and userid of
the TOOLSRUN service machine that is sending things to you. This will
be explained in a minute.
2. You must know to whom the files are being sent. This may seem obvious
("They're being sent to me!"), but on certain complexes, the files may
have been addressed to one userid/node and forwarded to another.
This, too, will be explained.
3. You must:
a. know the form (pattern) of the original inform/subscribe, or
b. be willing to blow away all of your informs/subscribes.
How you find out:
1. Disk name, and TOOLSRUN service machine node and userid:
a. If you are receiving files, you will usually get an INFORM.
(Unless you are subscribed to an appendable file.) If you have a
subscription, you will also get a copy of the change. All of the
information you need is contained in the INFORM file. All of the
information you need is also contained as tag information
associated with both the INFORM file and the SUBSCRIBE file. (If
you don't have an INFORM file, see 1b, below.)
In your reader, the filename will be the disk name, the filetype
will be INFORM, and the userid and node are the userid and node of
the TOOLSRUN service machine. For example, in RDRLIST and in
response to Q RDR ALL:
IBMPC INFORM PUN B TOOLS01 NEWOR NONE ...
The disk name is IBMPC, and the TOOLSRUN service machine userid
and node are TOOLS01 at NEWOR. If you have received or discarded
the file, the information should still be in your "userid NETLOG".
The INFORM looks like a NOTE. Here's a typical example:
Date: 15 Apr 1991, 21:48:34 GMT
From: TOOLSRUN 6.5 (level 2) TOOLS01 at NEWOR
To: SMITH at NEWOR
IBMPC: Information: ISTHERE FORUM appended ...
Kumquat Parser
The disk name is IBMPC, and the TOOLSRUN service machine is
TOOLS01 at NEWOR. The inform message was sent to SMITH at NEWOR.
(Remember, we need to know to whom it was sent.)
b. TOOLSRUN does not send INFORM files for appendable files. Also,
you may have used INFORM UPDATE to avoid INFORM files. Or, you
may have discarded the INFORM files. For whatever reason, you
don't have an INFORM file, but you do have a subscribe file. Most
of the information you need is available, just not as obvious as
with an INFORM file. In your reader, the filename and filetype
depend on the file, and the userid and node are the userid and
node of the TOOLSRUN service machine. This information is visible
using RDRLIST. You cannot see the DIST code with RDRLIST, but you
can display it with Q RDR ALL. For example, in RDRLIST, you have
a line like this:
ISTHERE FO910415 PUN B TOOLS01 NEWOR NONE ...
The TOOLSRUN service machine is TOOLS01 at NEWOR. In the "Cmd"
field for the line, type "Q RDR / ALL" to display the DIST code.
For example:
ORIGINID FILE CLASS RECORDS ... NAME TYPE DIST
RSCS 2193 B PUN 00000034 ... ISTHERE FO910415 IBMPC
The disk name is IBMPC. If you have received or discarded the
file, the disk name is lost, but the node and userid should still
be in your "userid NETLOG".
c. If you are receiving messages, they will look something like:
1)
DMTRGX171I From NEWOR(TOOLS01): IBMPC: ISTHERE FORUM ...
2) or they might look like:
09:55:28
MSG FROM TOOLS01: IBMPC: ISTHERE FORUM appended at ...
3) or they might even look like:
* IBMPC: ISTHERE FORUM appended at ...
The exact form of the messages may vary, but the essential
information will be in the same order. If you are fortunate, you
are getting messages like the first example. The disk name is
IBMPC, and the TOOLSRUN service machine is TOOLS01 at NEWOR. In
the second example, the disk name is IBMPC, and we know the
TOOLSRUN service machine is TOOLS01, but we don't know its node.
In the third example, all we know for certain is that the disk
name is IBMPC.
In the second and third examples, the TOOLSRUN service machine is
on a local node. If your complex has only one node, that's it.
If you are on a multi-node complex, it could be on any of the
nodes. If OMNIDISK has been installed at your site, and if the
installer has been diligent, there should be a file somewhere out
there called "SHADOW NAMES." You quickly can find the information
you want by typing OMNIDISK diskname ID. In our example, you see
the following displayed:
Identifying information for disk IBMPC
Title: IBM Personal Computer Conf.
Master: IBMPC at YKTVMV
Shadow: TOOLS01 at NEWOR
Local link: TOOLS01 200 label: IBMPC
Local contact: Bob Smith
Administrator: Bill Jones (JONES at YKTVMV)
Defined in: OMNIDISK and SHADOW NAMES
2. To whom the files were sent:
You can tell this for certain only if you have an INFORM file (and
have not discarded it), and if the file was sent directly to you,
instead of through a list processor.
In 1a above was an example of an inform message file. If the "To:"
field was not "distribution," then it shows to whom the file was sent.
3. The form (pattern) of the original inform/subscribe:
If you are willing to blow away all of your informs and subscribes,
you can skip this part.
Once you know the disk name, userid and node of the TOOLSRUN service
machine and to whom the files are being sent, you can ask the TOOLSRUN
service machine what informs and subscribes are in effect:
a. If the files are being sent to the userid and node that you are
currently logged onto:
TOOLS SENDTO node userid diskname QUERY INFORM
In our continuing example:
TOOLS SENDTO NEWOR TOOLS01 IBMPC QUERY INFORM
b. If the files are being sent to another userid and node, and are
then forwarded to you:
TOOLS FOR ouser AT onode SENDTO node userid disk QUERY INFORM
where "ouser onode" are the other userid and node, and "disk" is
the disk name.
For example, you have determined that the disk name is IBMPC, the
node and userid of the TOOLSRUN service machine are TOOLS01 at
NEWOR, and that the files are being sent to SMITH at NOVM1, but
you are currently logged onto SMITH at NOVM2:
TOOLS FOR SMITH AT NOVM1 SENDTO NEWOR TOOLS01 IBMPC QUERY INFORM
You will get back a file that tells you all the patterns in effect
for you for that disk under that TOOLSRUN service machine. You
might be getting informs and subscribes for other disks and from
other TOOLSRUN service machines. You will have to repeat this
procedure for each of those.
WHAT TO DO IF:
1. You don't know to whom the files are being sent.
You might prefer to wait until you get the next INFORM file and PEEK
it. If this will not help, or if you don't want to wait, try all of
the various combinations of userid (usually will remain the same) and
node to which files could be sent and forwarded to you.
2. You know the disk name, but you don't know the TOOLSRUN service
machine node or userid.
Again, it might be better to wait until you get the next file.
However, if you are getting messages only, look in SHADOW NAMES (as
described under 1c above). If this does not help, you will have to
ask around to see if anyone knows. You know that the node is a local
node, so that limits the search somewhat. If the QUSERS EXEC is
available, you can use it to find disconnected userids. (TOOLSRUN is
always disconnected.) If you find names that have "TOOLS" in them,
that's a good clue -- but not a requirement to be a TOOLSRUN machine.
Other likely names are IBMPC and IBMVM.
3. You know the TOOLSRUN service machine's node and userid, but don't
know the disk name.
Ask the machine what disks it maintains:
TOOLS SENDTO node userid * HELP ALL
The response will not necessarily list all disks (that's up to the
service machine administrator). You can then try each of the listed
disks, and finally try a few likely guesses.
If worse comes to worst, you can contact the TOOLSRUN service machine
administrator and ask for help. Even if you do not know who this
person is, the following will send them a note:
TOOLS SENDTO node userid * NOTIFY ALL
You will be prompted for the text of your message. Keep it short and
give the essential information: For example, the names of the files
you are receiving.
Please try all other avenues before contacting this person - they are
busy, just like you.
4. The files are being sent to another node and userid and forwarded to
you; when you try to use the FOR override, you get a note from the
TOOLSRUN machine that says you are not authorized to use it.
Try logging onto the other node/userid and resubmitting the QUERY
INFORM without the FOR override.
If this is not possible, you will have to contact the disk
administrator for help. Even if you do not know who this person is,
the following will send them a note:
TOOLS SENDTO node userid disk NOTIFY
You will be prompted for the text of your message. Keep it short and
give the essential information: For example, the names of the files
you are receiving.
When you finally have all the essential information: You should have:
1. The disk name
2. The node and userid of the TOOLSRUN service machine
3. The node and userid to whom the files are being sent
4. The patterns in effect (unless you want to cancel everything)
If you do not have all of this, re-read the above procedures to make
certain you have not overlooked something. If you simply cannot find all
of the pieces of information, I am sorry, but I cannot help you. My best
recommendation would be to try to find someone around you who is
knowledgeable of TOOLS and TOOLSRUN and ask them for help.
If you have everything, and:
1. You have an exact pattern match:
You asked TOOLSRUN for the patterns in effect, and one of them exactly
matches the files you are getting. For example, you are getting
inform messages for ISTHERE FORUM and/or you are getting files that
are named "ISTHERE FOnnnnnn" (where "nnnnnn" is a number), and you
have a pattern of "ISTHERE FORUM (INFORM)" or "ISTHERE FORUM
(SUBSCRIBE)".
You can cancel this with either an UNINFORM or UNSUBSCRIBE (it does
not matter which):
TOOLS SENDTO node userid diskname UNINFORM fname ftype
-or-
TOOLS SENDTO node userid diskname UNSUBSCRIBE fname ftype
To continue the example:
TOOLS SENDTO NEWOR TOOLS01 IBMPC UNINFORM ISTHERE FORUM
2. You do not have an exact pattern match:
You asked TOOLSRUN for the patterns in effect, and none of them
exactly matches the files you are getting. For example, you are
getting informs/subscribes for ISTHERE FORUM, and you have two
patterns: "I* FORUM (INFORM)" and "A* TIPS (INFORM)".
The asterisks form a pattern that may match any number of files. The
first pattern will match any file that begins with the letter "I" and
has a filetype of "FORUM". The second pattern will match any file
that begins with the letter "A" and has a filetype of "TIPS". You are
getting inform messages due to the first pattern. You will also be
informed of changes to "IBM FORUM", "INDIGO FORUM" and any others that
begin with the letter "I".
At this point, you have two choices. You can EXCLUDE just the file
that you no longer want (using the INFORM EXCLUDE command - for more
information, see "TOOLS Request Verb INFORM" in topic 4.10) Or, you
can just cancel the whole pattern:
TOOLS SENDTO node userid diskname UNINFORM fnpat ftpat
The "fnpat ftpat" must exactly match the pattern in effect. For
example, in the case we have been describing:
TOOLS SENDTO NEWOR TOOLS01 IBMPC UNINFORM I* FORUM
3. You have no match at all:
You asked TOOLSRUN for the patterns in effect, and either you have
none, or none of them covers the files you are receiving.
Obviously, some essential piece of information is in error. You may
have the wrong disk name, the wrong userid and node for the TOOLSRUN
service machine, or the inform/subscribe is in effect for you under a
different node and/or userid, and the files are being forwarded to
your present node and userid.
You need to review the whole procedure again.
4. You would like to cancel all of your informs and subscribes:
To do this, you do not need to know anything about patterns. Just
enter the UNINFORM command with the EVERY keyword:
TOOLS SENDTO node userid diskname UNINFORM * * EVERY
This will cancel all of the different patterns in effect for you at
this disk. You can cancel just the informs or just the subscriptions
by adding other keywords after "EVERY". For more information, enter
HELP TOOLS UNINFORM.
By the way, the response you get back from TOOLSRUN will list all of
the informs and subscribes that were cancelled. It is a good idea to
look over this list before discarding the response, and of course it
is handy to have if you decide you goofed and want them back!
5. The files are being sent to another node and/or userid:
This is similar to one of the previous cases, except that you need to
use the FOR override:
TOOLS FOR otheruserid AT othernode SENDTO ...
WHAT TO DO IF:
1. You cancel your inform/subscribe, and TOOLSRUN says you do not have
one in effect that matches that pattern.
You may have the wrong disk name or the wrong TOOLSRUN service machine
node or userid. Review the procedure.
The files may be sent to another node and/or userid and forwarded to
your present node and userid. Review the procedure to find out what
node and userid they are being sent to, and then use the FOR override
to cancel the inform/subscribe on behalf of the other node/userid.
Or, log onto that node/userid and cancel the inform/subscribe from
there.
You may have incorrectly specified the pattern. Review the procedure
to find out what patterns are in effect for you. You must specify a
pattern that exactly matches one of the patterns in effect.
2. You cancel your inform/subscribe, and the files keep on coming.
You may have more than one pattern in effect that covers the file.
For example, "* FORUM", "I* FORUM" and "*E FORUM" will all match
"ISTHERE FORUM". Cancel each pattern that applies, or use INFORM
EXCLUDE to block just the one you don't want anymore. For more
information, enter HELP TOOLS INFORM.
You may have informs/subscribes in effect at more than one TOOLSRUN
service machine. Review the procedure to determine where the files
are coming from, and cancel them there.
You may have informs/subscribes in effect under more than one node
and/or userid, and some of them are arriving directly while others are
being forwarded to you. Review the procedure to determine to whom the
files are being sent, and use the FOR override to cancel them.
3. The files are being sent to another node and userid and forwarded to
you; when you try to use the FOR override, you get a note from the
TOOLSRUN machine that says you are not authorized to use it.
Try logging onto the other node/userid and resubmitting the UNINFORM
without the FOR override.
If this is not possible, you will have to contact the disk
administrator for help. Even if you do not know who this person is,
the following will send them a note:
TOOLS SENDTO node userid disk NOTIFY
You will be prompted for the text of your message. Keep it short and
give the essential information: The pattern you are trying to cancel.
This is a brief discussion of Partial Shadows and Shared Forums.
| Setting up partial shadows and shared forums requires authorities beyond
| those of the normal user:
| Setting up partial shadows requires:
| • PRIV on the shadow disk, and
| • SYSTEM on the shadow machine.
| • PRIV on the master disk is useful, and sometimes required.
| Setting up shared forums requires:
| • PRIV on both master disks, and
| • SYSTEM on both master machines.
If you do not have the required authority, you must seek help from someone
who does.
You should also know about several control cards in TOOLSRUN CONTROL
files:
• MASTER
• SOURCE
• EQUATE DISK
You can find out about these in TOOLSRUN Administrators Guide.
Partial Shadows: are shadows that typically do not contain all of the
files found on the master disk. Some disks are partial shadows of more
than one master disk.
As long as your Toolsrun machine has sufficient authority at the master
disk (GETTER will do), no action is required at the master.
CAUTION:
Follow these instructions carefully. Otherwise, you could cause a lot of
disruption at the master and elsewhere.
1. Your Toolsrun machine must have at least GETTER authority at the
master disk.
2. In your own TOOLSRUN CONTROL file, after the DISK card for the shadow
disk, you must have a MASTER card for the master machine. There is no
exception to this.
If your disk is a shadow of more than one master, you must have a
MASTER card for each. You will also want to have a SOURCE card for
each.
3. If your shadow disk has a different name than the master disk, you
must have an EQUATE DISK card in your own TOOLSRUN CONTROL file, prior
to the first DISK card (i.e. in the global section). There is no
exception to this.
| You will also want to have a SOURCE card after the DISK card.
4. You must restart the Toolsrun machine, so the changes will take
effect. Or, you must stop the Toolsrun machine now; you may restart
it after the INFORM COPY is issued. You must do this before you go on
to the rest of the steps.
5. You must issue an INFORM request, with the COPY option, for each file
that you wish to shadow. The request cannot come from your own
| userid, unless you have PRIV authority for the MASTER disk. The
request must:
• Be issued by your Toolsrun machine
| - (Or be issued FOR your Toolsrun machine by someone who has
| PRIV authority for the MASTER disk)
• Be sent to the master Toolsrun machine
• Use the master disk name
| If the request is to be issued by your Toolsrun machine, you may log
onto your Toolsrun machine to do this, or you may use the CMS request
to cause the INFORM request to be issued. If you do not have SYSTEM
authority for your Toolsrun machine, you will have to ask for help
from someone who does.
| If the request is to be issued FOR your Toolsrun machine, PRIV
| authority at the master disk is required.
6. After you have done all of the above, you must initialize the shadow
disk with a copy of each file that you wish to shadow. The best way
to do this is to send a REFRESH request to your Toolsrun machine, but
using the master disk name. This will cause your Toolsrun machine to
send a GET COPY request to the master.
If you do this for one file, and wait for the results, you will have
tested your setup, and can be sure that everything is working
correctly. You may then issue separate REFRESH requests for the other
files you wish to shadow.
Partial Shadow Examples:
Single Master, Same Disk Name. Assume the disk name is FRUIT, the master
machine is MAST1 at NODE1. The shadow machine is SHADA at NODEA, you want
to shadow KUMQUAT PACKAGE. In your TOOLSRUN CONTROL file, you need:
* Global Section
...
* Disk Section
DISK FRUIT ...
MASTER NODE1 MAST1 ; Master Machine
Let's say you make these changes by logging on to the Toolsrun machine and
stopping it. Before you restart it, you can go ahead and issue the INFORM
COPY from the Toolsrun userid:
| TOOLS SENDTO NODE1 MAST1 FRUIT INFORM KUMQUAT PACKAGE COPY
After you restart the shadow machine, you initialize your shadow disk with
the KUMQUAT PACKAGE like this:
TOOLS SENDTO NODEA SHADA FRUIT REFRESH KUMQUAT PACKAGE
Note that all files referenced by the KUMQUAT PACKAGE will be initialized
by the single REFRESH and will be updated by the single INFORM COPY.
Single Master, Differrent Disk Name. We're setting up the MEAT disk on
SHADA at NODEA. The master disk is FOOD on MAST1 at NODE1. We want both
the BEEF and PORK packages. In the TOOLSRUN CONTROL file, you need:
* Global Section
EQUATE DISK MEAT * * FOOD ; Requests for FOOD go to MEAT
...
* Disk Section
DISK MEAT ...
MASTER NODE1 MAST1 ; Master Machine
| SOURCE NODE1 MAST1 FOOD ; Send refreshes here
Your Toolsrun machine is too busy to shut down for very long, so you
replace the TOOLSRUN CONTROL file with AREPLACE, then do a SHUTDOWN ALL.
After the machine comes back up, you handle the INFORMs and
initializations as follows:
| TOOLS SENDTO NODEA SHADA * +
| CMS TOOLS SENDTO NODE1 MAST1 FOOD INF BEEF PACKAGE COP
| TOOLS SENDTO NODEA SHADA * +
| CMS TOOLS SENDTO NODE1 MAST1 FOOD INF PORK PACKAGE COP
TOOLS SENDTO NODEA SHADA FOOD REFRESH BEEF PACKAGE
TOOLS SENDTO NODEA SHADA FOOD REFRESH PORK PACKAGE
Multiple Masters. We are setting up the TRANSPOR disk, on SHADA at NODEA.
It will contain selected packages from disks AUTO, on MAST1 at NODE1, and
PLANE, on MAST2 at NODE2. In the TOOLSRUN CONTROL file, you need:
* Global Section
EQUATE DISK TRANSPOR NODE1 MAST1 AUTO ; Convert AUTO to TRANSPOR
EQUATE DISK TRANSPOR NODEA ME AUTO ; Allows ME to refresh
EQUATE DISK TRANSPOR NODE2 MAST2 PLANE ; Convert PLANE to TRANSPOR
EQUATE DISK TRANSPOR NODEA ME PLANE ; Allows ME to refresh
...
* Disk Section
| DISK TRANSPOR ...
MASTER NODE1 MAST1 ; Master Machine for AUTO
SOURCE NODE1 MAST1 AUTO ; Send AUTO refreshes here
MASTER NODE2 MAST2 ; Master Machine for PLANE
SOURCE NODE2 MAST2 PLANE ; Send PLANE refreshes here
Notice the specific node and userid in each of the EQUATE DISK cards. We
have found that users sometimes accidentally send a request to our local
partial shadow, when it should have gone to the master. So we equate the
disks only for the master machines, and for our own userid (ME) so we can
do refreshes.
| Let's say this time we have someone who is PRIV for each of the master
| disks. Therefore, we can issue INFORM COPY requests FOR our Toolsrun
| machine. For example:
| TOOLS FOR NODEA SHADA SENDTO NODE1 MAST1 AUTO INF VW PACKAGE COP
| TOOLS FOR NODEA SHADA SENDTO NODE2 MAST2 PLANE INF JET PACKAGE COP
TOOLS SENDTO NODEA SHADA AUTO REFRESH VW PACKAGE
TOOLS SENDTO NODEA SHADA PLANE REFRESH JET PACKAGE
| will set up the informs, and will send a GET VW PACKAGE COPY to MAST1 at
| NODE1, and a GET JET PACKAGE COPY to MAST2 at NODE2.
Shared Forums: are appendable files shared between two (or more)
conference disk masters. Appends sent to either master will appear in
both copies of the appendable file (as well as on all shadows of both
disks). Actions are required at both master Toolsrun machines.
CAUTION:
Follow these instructions carefully. Otherwise, you could cause a lot of
disruption at the masters and elsewhere.
1. Each Toolsrun machine must have at least GETTER authority at the other
disk. (MASTER does not confer GETTER authority.)
2. In each TOOLSRUN CONTROL file, after the DISK card for the master
disk, you must have a MASTER card for the other master machine. There
is no exception to this.
You will also want to have a SOURCE card in each TOOLSRUN CONTROL
file.
3. Since each master disk has a different name, you must have an EQUATE
DISK card in each TOOLSRUN CONTROL file, prior to the first DISK card
(i.e. the global section). There is no exception to this.
4. You must restart each Toolsrun machine, so the changes will take
effect. Or, you must stop the Toolsrun machine now; you may restart
it after the INFORM COPY is issued. You must do this before you go on
to the rest of the steps.
5. You must issue an INFORM request, with the COPY option, from each of
the master Toolsrun machines. The requests cannot come from your own
| userid, unless you have PRIV authority for the master disk(s). Each
request must:
• Be issued by one master Toolsrun machine
| - (Or be issued FOR that Toolsrun machine by someone who has
| PRIV authority for the other MASTER disk)
• Be sent to the other master Toolsrun machine
• Use the other master disk name
| If the request is to be issued by a Toolsrun machine, you may log onto
the Toolsrun machine to do this, or you may use the CMS request to
cause the INFORM request to be issued. If you do not have SYSTEM
authority for a Toolsrun machine, you will have to ask for help from
someone who does.
| If the request is to be issued FOR a Toolsrun machine, PRIV authority
| at the other master disk is required.
6. After you have done all of the above, you must initialize one master
disk with a copy of the forum from the other. (We assume the forum
already exists on the other master.) The best way to do this is to
send a REFRESH request to that Toolsrun machine, but using the other
master disk name. This will cause the Toolsrun machine to send a GET
COPY request to the other master.
Shared Forum Example: Assume one disk name is FRUIT, on MAST1 at NODE1,
and the other is MEAT, on MAST2 at NODE2. The BEEFAPPL FORUM exists on
the FRUIT disk, and would be of interest to MEAT participants.
In the MAST1 machine's TOOLSRUN CONTROL file, you need:
* Global Section
EQUATE DISK FRUIT NODE2 MAST2 MEAT ; Convert MEAT to FRUIT
EQUATE DISK FRUIT NODE1 ME MEAT ; Allow refreshes
...
* Disk Section
DISK FRUIT ...
MASTER NODE2 MAST2 ; Master Machine
SOURCE NODE2 MAST2 MEAT ; For refreshes
GETTER NODE2 MAST2 ; Allow INFORM-COPY
In the MAST2 machine's TOOLSRUN CONTROL file, you need:
* Global Section
EQUATE DISK MEAT NODE1 MAST1 FRUIT ; Convert FRUIT to MEAT
EQUATE DISK MEAT NODE2 HIM MEAT ; Allow refreshes
...
* Disk Section
DISK MEAT ...
MASTER NODE1 MAST1 ; Master Machine
SOURCE NODE1 MAST1 FRUIT; For refreshes
GETTER NODE1 MAST1 ; Allow INFORM-COPY
After both machines' control files have been changed, and both machines
restarted, we can set up the INFORM COPY requests, and cause the BEEFAPPL
FORUM to be copied from FRUIT to MEAT:
| TOOLS FOR NODE1 MAST1 SENDTO NODE2 MAST2 MEAT INF BEEFAPPL FORUM COP
| TOOLS FOR NODE2 MAST2 SENDTO NODE1 MAST1 FRUIT INF BEEFAPPL FORUM COP
TOOLS SENDTO NODE2 MAST2 MEAT REFRESH BEEFAPPL FORUM
The last request will not start an endless loop, because Toolsrun will not
send a copy back to MAST1 when it is received from MAST1.
|
| This is a brief discussion of how to communicate with Toolsrun from AIX | (UNIX) and OS/2 sessions. The roles of XAGENT and TOOLNOTE are discussed.
| Toolsrun is a program that runs on the VM operating system. VM has its | way of doing things, just as Unix and OS/2 each have their way of doing | things. (Which one is "best" is beyond the scope of this document.) | It is possible to communicate between the systems, including Tools | commands. There has to be some sort of gateway that connects the two | systems, allowing notes to be transferred. (Informs and append | subscriptions look like notes.) Besides actually transferring the note | text, it is useful if the addresses are also converted back and forth | between the VM form (e.g. BIGBIRD at LEXVMK) and the form usually used on | AIX and OS/2 LANs (e.g. bigbird@grumpy.lexington.ibm.com). And, since | many Toolsrun controlled disks have limited access, it is also useful if | the sender can be uniquely and safely identified.
| is just such a gateway system. It can be installed to look like an RSCS | node on the VM network. Once a user registers with it, traffic sent on | the VM network will be forwarded to the AIX or OS/2 LAN, and vice versa. | Actually setting up XAGENT or adding TCP/IP to your workstation is beyond | the scope of this document. Let us assume that XAGENT is set up (and is | at least release 4.0) and your workstation is configured for TCP/IP. (For | more information about XAGENT, typeHELPXAGENT.) | To register with XAGENT, you need to do the following from your VM | session: | CP SMSG rscsid CMD generic FORWARD ADD tcpuser tcphost protocol | where: | rscsid is the name of the RSCS machine on your node, usually RSCS. | (You can use the CMS IDENTIFY command to find the name of this | machine. The response istcpuserATnodeVIArscsid....) | generic is the XAGENT generic node. (You can use TELL XAGENT AT node; | the response will tell you the generic node name.) | tcpuser is your userid on the workstation. | tcphost is your TCP/IP workstation name. For example, in address | "bigbird@grumpy.lexington.ibm.com," the userid is "bigbird," the | workstation is "grumpy" and the domain is "lexington.ibm.com." | Normally, you need only specify the workstation name. XAGENT | serves the domain, and so can fill it in for you. | You may enter the domain along with the workstation name | (example "grumpy.lexington.ibm.com"). You should do this if you | have a complicated domain (example | "punkin.cv.lexington.ibm.com") or are registering with an XAGENT | server that is on a different domain than your workstation. | protocol is the transmission protocol to use: usually SMTP. | Assuming that all of XAGENTA, XAGENTF (or XAGENTFT) and XAGENTM are | installed, here's what happens when you issue the command from a VM | session "vmuser AT vmnode": | • "vmuser" AT "generic" is now registered, and associated with | "tcpuser@tcphost." | • Mail (notes, Toolrun appends and notifies) sent on VNET to "vmuser AT | generic" will be transferred (via SMTP) to "tcpuser@tcphost.domain." | • If undeliverable for a certain number of days, the mail will instead | be forwarded to "vmuser AT vmnode." | • When mail is transferred, it is converted from CMS NOTE format to Unix | (or OS/2) mail format. This includes conversion of VM addresses to | TCP/IP addresses in the mail header. | • Mail sent from the workstation to an address on the VNET is also | converted: The TCP/IP addresses become VM addresses. In particular, | the sender address becomes "vmuser AT generic." (Generally, you send | the mail to "userid@node.RSCS") | You may associate more than one workstation address with "vmuser AT | generic" by issuing (for each alternate workstation): | CP SMSG rscsid CMD generic FORWARD ADDALIAS tcpuser althost protocol | where "althost" is another workstation name. | • In roughly similar fashion, files and messages may be delivered from | VNET to the workstation, and may be sent from the workstation to a | VNET addressee. | • If DOCGATE is also installed, OV notes and documents may also be | transferred. | • If XAGENTA is installed, you may also send special mail that will be | converted to TOOLS commands, and use the IINUS1 Internet Mail Gateway. | There are numerous variations possible, based on exactly what is | installed. For example, messages might be forwarded to the VM address, | while everything else is transferred to the TCP/IP address. You may even | specify different disposition of mail, files and messages when you | register, or some time later. | To send a Tools command via XAGENT: | 1. A blank line must separate the Tools command and the address portion | of the note. | 2. The Tools command itself appears as the verb (followed by a colon), | the address override (e.g. TO or SENDTO), then any details. | 3. Any data that must accompany the command (e.g. the body of an append) | must follow the Tools command. | 4. Send the note to XAGENTA@generic, where "generic" is the XAGENT | generic node. | For example, to append to TESTER FORUM on LOCLDISK, managed by TOOLS at | LOCLNODE, compose a file containing: | append: sendto loclnode tools locldisk tester forum | (body of append) | Make sure there is one blank line at the top of the file. If the XAGENT | generic node is LCLGATE, this would do it: | mail xagenta@lclgate < toolcmd | Not every Tools command is supported.
| will convert properly formatted notes into TOOLS requests, and is an | alternative to XAGENTA. If XAGENT is installed, and you have registered | yourself as above, and TOOLNOTE is installed on your Toolsrun system, all | you have to do is send a properly formatted note. XAGENT will convert it | to CMS NOTE format, then TOOLNOTE will convert it to a TOOLS command. | The format of the note is very simple: Just put the command right after | theSubject:line in the note. If the command needs data (such as the | body of an append), the body of the note will be used. | Not every TOOLS command is handled by TOOLNOTE, and there is a delay: | Toolsrun does not respond immediately to notes. Furthermore, not every | Toolsrun service machine has TOOLNOTE installed. For these, and other | reasons, you may find it more convenient to userexecfor some commands.
| is an AIX and OS/2 command that lets you execute a command on a remote | system via TCP/IP. If TCP/IP is installed on your VM system, you may use |rexecto invoke the TOOLS EXEC. For example: | rexec lexvmk tools to ibmvm nodeid lexgate sub tools forum | will enter a subscription to TOOLS FORUM on IBMVM. Note the use of NODEID | to route the response and the subscriptions to the XAGENT generic node | LEXGATE. | TCP/IP must be installed on your VM system, and you must be logged off of | the VM session. In addition, you may have to grant RACF BATCH authority | to the FTP server(s). There is an exec called FTPPERM, distributed with | the VM FTP package, that will handle this for you. In case you need to do | this manually, here is the RACF command, to be issued once for each FTP | server machine ID: | PERMIT userid CLASS(VMBATCH) ACCESS(CONTROL) ID(ftpid) | where: | userid is your VM userid. | ftpid is the userid of an FTP server. | You could even userexecto issue XAGENT ADDALIAS commands on the fly, if | you find yourself logged onto a different machine than usual. | You can combine XAGENTA, TOOLNOTE notes andrexecinvocation of TOOLS, | perhaps using aliases or shell scripts, to provide full TOOLS function | from your AIX or OS/2 workstation.
All of these documents (except those being developed) are available on
VMTOOLS, managed by VMTOOLS at RALVM17, in the TOOLSDOC package. You can
order the package by entering this:
TOOLS SENDTO RALVM17 VMTOOLS VMTOOLS GET TOOLSDOC PACKAGE
Here's what you can get:
┌───────────┬──────────┬─────────────────────────────────────────────────┐
| │ Number │ Filename │ Title │
├───────────┼──────────┼─────────────────────────────────────────────────┤
| │ TOOLS-001 │ TOOLS │ TOOLS Request File Submission Program Users │
| │ │ │ Guide and Reference │
├───────────┼──────────┼─────────────────────────────────────────────────┤
| │ TOOLS-002 │ TOOLSCTL │ TOOLSRUN Control File Language Reference │
├───────────┼──────────┼─────────────────────────────────────────────────┤
| │ TOOLS-003 │ TOOLSREQ │ TOOLSRUN Request File Language Reference │
├───────────┼──────────┼─────────────────────────────────────────────────┤
| │ TOOLS-005 │ TOOLSRUN │ TOOLSRUN Administrators Guide │
├───────────┴──────────┴─────────────────────────────────────────────────┤
| │ Note: The following are under development: │
├───────────┬──────────┬─────────────────────────────────────────────────┤
| │ TOOLS-004 │ │ Zen and the Art of Shadow Maintenance │
├───────────┼──────────┼─────────────────────────────────────────────────┤
| │ TOOLS-006 │ │ TOOLS Conferencing Guide │
└───────────┴──────────┴─────────────────────────────────────────────────┘
| Figure 6. TOOLS and TOOLSRUN Publications. Numbered documents are
| available as BookMaster source, files already formatted for
| various printers, and BookManager online books.
| When you order the TOOLSDOC PACKAGE, you will receive TOOLSDOC PACKLIB and
| a separate BOOK file for each document. The BOOK files are suitable for
| immediate use via BookManager READ. The TOOLSDOC PACKLIB is an FCOPY
| packlib: It contains copies of the BookMaster source and preformatted
| printable files for each document. To view the list of files contained in
| the packlib, enter:
| FCOPY TOOLSDOC PACKLIB fmode (LIST
| where fmode is the filemode of the disk containing the packlib.
| To unpack one of the files and place it on a disk, display the list of
| files and type the following on the same line as the file to be unpacked:
| SELECT /N /T fmode
| where fmode is the filemode of the disk to receive the unpacked file. (If
| you just type SELECT it will unpack onto your A-disk.)
Toolsrun is a volunteer effort - but there are a lot of volunteers. The
most efficient way to get help is to post your question or problem where a
lot of people will see it. This gives you the maximum chance that someone
who knows the answer will see it, others will benefit from the answer and
you have not interrupted someone who cannot really afford interruptions
today. The place to do that is a FORUM. Here is a list of some of the
more popular ones:
TOOLS FORUM For reporting problems and asking general TOOLS and TOOLSRUN
related questions.
TOOLWISH FORUM For making suggestions and asking for enhancements.
TOOLSADM FORUM For asking fellow Toolsrun administrators for advice.
TOOLSIC FORUM For administrators of IBM Confidential disks.
TOOLSRUN LESSONS Q&A on how Toolsrun works.
TOOLS TIPS Answers to the most frequently asked questions.
TOOLTOOL FORUM Discussions about tools (EXECs and such) to help with TOOLS
and TOOLSRUN.
In addition, there are a couple of other files worth browsing, although
you cannot ask questions there:
TOOLS ANSWERS More answers to frequently asked questions.
TOOLTOOL INDEX An index of tools (EXECs and such) to help with TOOLS and
TOOLSRUN.
All of these files are found on the IBMVM conference disk, and many are
also found on IBMPC, IBMMVS and other popular conference disks.
To ask a question:
1. See if it has been asked already. (6)
2. Make sure you will see the answer before you ask the question. (7)
Otherwise, you may miss it.
You will start getting copies of appends about all sorts of things.
Among them should be the answer to your question.
3. Append your question to the forum. (8) Make it brief - if more
information is needed, someone will ask for it.
4. Wait for an answer. Sometimes it will take a day or more, so be
patient.
5. Once you have your answer, cancel your subscription (9) (if you don't
want to continue following the forum). However, wait a little while
before doing this. Sometimes you will get more than one answer, and
the first one might not be the best one, and may even be incorrect.
(6) We know you may not have the time to read all of the
suggested files. TOOLS TIPS and TOOLS ANSWERS are short
enough to be worthwhile, though. If you don't know how to
link and access a local shadow, here's how to request a copy
of a file: TOOLS SENDTO KGNVMC IBMVM IBMVM GET filename
filetype, where "filename filetype" name the file you want.
For example, TOOLS TIPS.
Note: This is a very busy master disk, and GET requests add
to its burden. You should really make an effort to find the
nearest shadow - perhaps as your next question. You may
notice that you get a response from somewhere other than
IBMVM at KGNVMC. If this happens, a shadow was selected for
you automatically. Use it in the future.
(7) If you don't know how to view local shadows or use the
various types of Inform, do this: TOOLS SENDTO KGNVMC IBMVM
IBMVM SUBSCRIBE filename filetype, where "filename filetype"
name the forum you are about to append to. For example,
TOOLS FORUM.
(8) If you don't know how to append to a forum, do the
following: Create and edit a file called "filename APPEND",
where "filename" is the same as the filename of the forum to
which you will append your question. When you are ready to
send it: TOOLS SENDTO KGNVMC IBMVM IBMVM APPEND filename
filetype, where "filename filetype" name the forum where you
want your question posted. For example, TOOLWISH APPEND is
the file containing your question, and TOOLWISH FORUM is
where it will go.
(9) Remember the "filename filetype" that you used to subscribe
in the first place? Just do this: TOOLS SENDTO KGNVMC IBMVM
IBMVM UNSUBSCRIBE filename filetype.
┌───┐
│ A │
└───┘
ACCESSER. TOOLSRUN authorization. Prohibits the use of any requests.
ADDER. TOOLSRUN authorization modifier. Permits users other than the
owner to append to a file, so long as they have at least APPENDER
authority.
Administrator. See Disk administrator and System administrator.
Append. (1) (Noun). One of a series of pieces of text added to an
appendable file as part of a computer conference discussion. (2) (Verb).
To add an append to an appendable file using the APPEND request. The
usual way, on a TOOLSRUN-managed conference, to ask questions and post
answers.
Appendable file. A file intended to contain the record of a computer
conference discussion. By use of the ADDER authorization modifier, users
are permitted to make appends to the file. See also Publicly Appendable.
APPENDER. TOOLSRUN authorization. Permits the use of APPEND and VOTE
requests, as well as any requests allowed by GETTER.
AUDIT file. A file kept by TOOLSRUN for a maintained disk, on the
TOOLSRUN system A-disk, that contains a record of every request sent to
the disk, and the responses to those requests. The Audit file for a disk
has the disk name as its filename, and a filetype of AUDIT. Audit files
are not generally accessible by users, although a PRIV user may GET the
Audit file for the disk.
┌───┐
│ B │
└───┘
Backup file. The previous version of a replaced file. The backup file is
invisible to normal users, but may be made visible again (replacing the
current file) by the REGRESS request.
BAD. (Broken As Designed). See WAD.
┌───┐
│ C │
└───┘
Clean. To free up space on a disk by purging discarded, backup and hidden
files, using the CLEAN request.
Closed conference disk. A conference disk with access restricted to a
certain group of users. The data contained on the disk is often
classified IBM Confidential.
CMS. (Conversational Monitor System). The interactive component of VM.
Command. (1) A complete request, including the verb and any overrides,
details and description. (2) Loosely, a request verb.
Command-line form. The form of a TOOLS request that is entered on the
command line (i.e. at the Ready prompt in CMS or the command line of XEDIT
or LEXX). See also Full-screen form.
Computer conference. A discussion between two or more people which is in
some way mediated by a computer.
Conference disk. A disk, maintained by TOOLSRUN, that is used to conduct
a computer conference.
Confidential conference disk. See Closed conference disk.
CONTROL file. A file that is read by TOOLSRUN, and that controls the
operation of the TOOLSRUN Service Machine and its maintained disks.
Copy. To cause a file to be copied from a master disk to a shadow disk,
using the COPY request at the master.
Create. To cause a file to exist on a disk for the first time, using the
CREATE request.
┌───┐
│ D │
└───┘
Deck. A set of virtual cards, usually unreadable as is by mere humans,
used to exchange information via the spool.
Description. Free-form text that follows the details in the command-line
form of a request, and is separated from the rest of the request by a left
parenthesis. This text describes the purpose of the request, and is
generally logged in History and Audit files, and included in the message
sent to users with INFORMs and SUBSCRIBEs that match the file.
Details. Tokens that follow the verb in the command-line form of a
request. See also Options.
Discarded file. (1) A file that has been erased, using the ERASE request.
(2) A backup file that has been replaced by a later backup file. (3) A
file that is referenced by only one PACKAGE file, and that did not exist
prior to first being referenced by any PACKAGE file, is hidden when the
PACKAGE file is replaced with the reference omitted. If the PACKAGE file
is again replaced without referring to the file, it is discarded. (4)
| (See ERASABLE FILE.)
Disk. (1) A data file repository managed by TOOLSRUN. (2) A magnetic
disk.
Disk address. The combination of disk name, disk userid and disk node
that uniquely identifies the disk.
Disk administrator. A person, with PRIV authority, who has the primary
responsibility for maintaining the TOOLSRUN disk.
Disk name. The name assigned to a TOOLSRUN managed disk by the TOOLSRUN
administrator.
Disk node. The VM network node of the disconnected VM service machine
running TOOLSRUN and managing the disk.
Disk userid. The userid of the disconnected VM service machine running
TOOLSRUN and managing the disk.
┌───┐
│ E │
└───┘
| ERASABLE file. (1) A file whose:
| • filename is randomly generated and in the form @1234567,
| • filetype is ERASABLE,
| • filemode number is zero,
| • and existence is not recorded in the disk NAMES file.
| (2) A discarded file that has not yet been removed from the disk by
| cleaning; it has the preceding characteristics. (3) A temporary file
| created by Toolsrun and ordinarily removed as soon as Toolsrun is finished
| with it; it has the preceding characteristics.
Erase. To cause a file to be removed from the disk NAMES file and
discarded, using the ERASE request.
┌───┐
│ F │
└───┘
File. A collection of data under CMS, consisting of any number of records
or lines of any length.
Filename. The first part of the two-part identifier of a file. The
filename is the name of the file.
Filemode. (1) A one or two character identifier that locates the file on
an accessed disk and controls the visibility of the file and whether or
not CMS update-in-place is to be used. (2) The first character is the
filemode letter, and identifies the place in the CMS search order at which
the disk is currently accessed. (A is first in the search order and Z is
last.) The filemode letter is required with certain TOOLS request verbs
(e.g. CREATE) to identify the source of the data to be passed to TOOLSRUN.
(3) The second character is the filemode number or digit, and controls the
visibility of the file and whether or not CMS update-in-place is to be
used.
File owner. The owner of the file. This is usually the person who
created the file, and is (in general) the only person who can replace,
hide or erase the file. (Note, however, that file ownership does not, in
itself, give authority to do anything with the file. You can own a file
and be unable to append to it unless you have APPENDER authority, replace
it unless you have REPLACER authority, and so on.) A person can also
become the owner of a file by creating or replacing a PACKAGE file that
references an unowned file. One person can also transfer ownership of a
file to another person by using the NEWOWN request or the SET ADDRESS
request.
Filetype. The second part of the two-part identifier of a file. The
filetype identifies the type of data contained in the file or the purpose
of the file.
FORUM. (1) A file with a filetype of FORUM. (2) Loosely, any appendable
file.
Forum, shared. See Shared forum.
Full-screen form. The form of a TOOLS request that is entered on the
full-screen TOOLS menu. The full-screen menu will be presented when TOOLS
EXEC is invoked by itself or with incomplete or erroneous data.
┌───┐
│ G │
└───┘
Get. To obtain a copy of a file from a disk, using the GET request.
GETTER. TOOLSRUN authorization. Permits the use of GET, INFORM, LIST and
other information and data retrieval requests.
┌───┐
│ H │
└───┘
Header. The part of an appendable file that precedes the first append.
Usually contains information about the purpose of the file, the owner and
a pointer to the rules of the conference disk.
HEADER file. A file on the maintained disk, with a filename the same as
the disk name and a filetype of HEADER, that contains standard information
to be added automatically by TOOLSRUN to the header of each appendable
file created on the disk.
Help. To request information about a disk or a TOOLSRUN system, using the
HELP request. This information is set up by the disk and system
administrators and is entirely at their discretion.
Hidden file. (1) A file that has been hidden, using the HIDE request.
(2) A file that is referenced by only one PACKAGE file, and that did not
exist before being referenced by a PACKAGE file, is hidden when the
PACKAGE file is replaced with the reference omitted. If the PACKAGE file
is again replaced without referring to the file, it is discarded.
Hide. To make a file invisible to normal users of the disk, using the
HIDE request.
HISTORY file. A file, with filetype of HISTORY, kept on a maintained
disk, that contains a history of changes. History may be kept separately
for each file, or collectively for the entire disk.
┌───┐
│ I │
└───┘
IMHO. In My Humble Opinion
Inform. A request to be notified each time a file matching a certain
filename/filetype pattern is modified, replaced or created, using the
INFORM request. See also Subscribe.
Insert. To place an append somewhere in the middle of an appendable file,
rather than at the usual place (the end), using the APPEND request with a
date and the INSERT detail keyword.
┌───┐
│ J │
└───┘
┌───┐
│ K │
└───┘
┌───┐
│ L │
└───┘
List. To obtain a list of the files on a disk, using the LIST request.
See also Summary.
List Processing. A method whereby a single copy of a file is sent to an
RSCS network service machine, with a list of addresses prefixed. The
service machine sends a copy of the file to each local addressee, removing
them from the list, and forwards copies to other service machines as
needed for the rest of the list.
Load Shedding. Busy TOOLSRUN masters may reroute requests to a shadow
machine near the requester. This reduces work done at the master, as well
as reducing network costs charged to the master.
Lock. To inhibit appends, replaces or updates to a file, except by the
LOCK issuer, by issuing the LOCK request.
Logoff. To cause the disconnected TOOLSRUN service machine to log itself
off, using the LOGOFF request.
Master. (1) The primary copy of a disk. Requests to make changes on the
disk are usually directed to the master disk, which may then copy the
changes to its shadows. (2) Loosely, the TOOLSRUN Service Machine for a
Master disk.
Master-Servant. A type of Master-Shadow network in which the shadow disks
accept and forward to the master requests that alter data on the disk
(e.g. CREATE, REPLACE or ERASE).
Mastersitter. The person in charge of the master disk, especially from a
technical (versus managerial) point of view.
Master-Slave. A type of Master-Shadow network in which the shadow disks
do not accept requests that alter data on the disk (e.g. CREATE, REPLACE
or ERASE). All such requests must be sent to the master disk.
Modify. To alter an existing append in an appendable file, using the
APPEND request with a date that matches the existing append.
MVS. (Multiple Virtual Storage). An IBM computer operating system.
┌───┐
│ N │
└───┘
NAMES file. A file created and updated by TOOLSRUN, kept on a maintained
disk, that contains information about each owned file on the disk. The
filename is the same as the maintained disk name and the filetype is
NAMES.
NAMINDEX file. A file created and updated by TOOLSRUN as a performance
aid.
Newown. To transfer ownership of a file, with the NEWOWN request.
Notify. To send a message to the disk or system administrator, using the
NOTIFY request.
┌───┐
│ O │
└───┘
Open conference disk. A conference disk that is generally open to all IBM
employees. However, some files on the disk may be restricted.
Options. Tokens that follow the verb in a request, and that modify the
specific action of the verb. Also known as Details.
Overrides. Tokens that precede the verb in a request. In contrast to
Options, overrides are broadly applicable to all verbs (although not all
overrides are appropriate for all verbs).
Own. To claim ownership of an unowned file, using the OWN request.
OWNER. (1) TOOLSRUN authorization. Permits the use of CREATE, ERASE, OWN
and other file manipulation requests, as well as all requests permitted by
PACKAGER. (2) See File owner.
┌───┐
│ P │
└───┘
PACKAGE file. A file that references other files. A single GET request
will return a copy of the PACKAGE file and all files that it references.
(If you want just the PACKAGE file, issue GET filename PACKAGE*).
Similarly, other requests (e.g. HIDE, ERASE, INFORM, SUBSCRIBE) will
affect both the PACKAGE file and files referenced by it.
PACKAGER. TOOLSRUN authorization. Permits the creation and manipulation
of PACKAGE files, as well as files referenced by an owned PACKAGE file and
not owned by anyone else. Includes requests permitted by REPLACER.
PACKAGER is commonly used by repository disks: A contributor is forced to
create or replace the PACKAGE file before any newly referenced files.
This ensures that persons with INFORMs/SUBSCRIBEs on the PACKAGE file will
also receive notification/copies of new files referenced by the PACKAGE.
Partial Shadow. A shadow disk that includes a subset of the files on the
master.
Peer. (1) A type of disk network in which no one disk is the master. Any
request may be sent to any of the peer disks, which will accept the
request and forward it to the other peers. There may also be slave shadow
disks associated with the network - these disks will not accept requests
that alter data on the disk (e.g. CREATE, REPLACE or ERASE). (2) One of
the disks in a peer network that acts as a master disk.
Place. To create or replace a file, claiming ownership and altering the
description, by using the PLACE request.
PRIV. TOOLSRUN authorization. Permits the use of any request, except
those reserved for SYSTEM. The PRIV user may CREATE, REPLACE, ERASE and
otherwise manipulate any file on the disk (including those owned by
others).
Prune. To remove old appends from an appendable file, using the PRUNE
request.
Publicly Appendable. An appendable file that may be appended by anyone
with access to the disk. Generally, the ADDER card covering the file has
* * for the node and userid.
┌───┐
│ Q │
└───┘
Query. To obtain information about your informs/subscribes, files on a
disk, the disk or service machine, using the QUERY request.
┌───┐
│ R │
└───┘
Refresh. To cause a file to be copied from a master disk to a shadow
disk, using the REFRESH request at the shadow.
Register. To log possession of a PACKAGE, by using the REGISTER request.
Regress. (1) To undo a replace by discarding the current file and making
the backup file visible, using the REGRESS request. (2) To undo a hide by
making the file visible again, using the REGRESS request.
Replace. To provide a new copy of the file on the disk, making the
current copy the backup.
REPLACER. TOOLSRUN authorization. Permits the user of requests that
modify a file, such as REPLACE, PRUNE and UPDATE, and other requests
related to maintaining a file, as well as all requests permitted by
APPENDER.
Repository disk. A disk that contains only PACKAGE files and files
referenced by those PACKAGEs. Generally, there will be no appendable
files on a repository disk. The purpose of the disk is for the sharing
and distribution of data, programs, etcetera. Most repository disks limit
user authority to PACKAGER.
Request file. A request for information or data, or a request to create
or modify data, sent as a deck by TOOLS to TOOLSRUN.
REQUESTS file. A file on a maintained disk, created and updated by
TOOLSRUN, with a filetype of REQUESTS, that contains a record of all GET
and REGISTER requests for PACKAGE files. There may be one REQUESTS file
for each PACKAGE file, or there may be one REQUESTS file for the whole
disk. Information about requestors of PACKAGEs is used by PACKAGE owners
to justify their efforts and to distribute urgent information about a
PACKAGE.
Restricted conference disk. See Closed conference disk.
┌───┐
│ S │
└───┘
Second-level shadow. A shadow whose server is not the master but one of
its shadows.
Servant disk. A shadow disk that will accept, and forward to the master,
requests that alter data on the disk (e.g. CREATE, REPLACE or ERASE). See
Slave disk.
Server. A TOOLSRUN Service Machine that sends decks to you or another
machine. The master is a server for its direct shadows.
Set. To alter your inform/subscribe and ownership address, or information
about a file, using the SET request.
Shadow disk. A secondary copy of a master disk. Requests for information
and for copies of data may be directed to a shadow disk.
Shadowsitter. The person in charge of a shadow.
Shared forum. A forum (or any appendable file) shared between two
conference disk masters, so that appends sent to either master will also
be seen at the other.
Shutdown. To shut down the TOOLSRUN service machine, or one of its
maintained disks, by using the SHUTDOWN request.
Slave disk. A shadow disk that will not accept requests that alter data
on the disk (e.g. CREATE, REPLACE or ERASE). See Servant disk.
SMOP. (Simple Matter Of Programming).
Spool. (Simultaneous Peripheral Operations OnLine). Auxiliary storage
(e.g. magnetic disk) used as a buffer between peripheral equipment and the
processors of a computer. Files sent to the reader of a virtual machine
(e.g. yours or a TOOLSRUN Service Machine) reside in spool files until
read.
Spool space. The amount of magnetic disk space available for storing
spool files. Spool space is a critical resource on a VM system: When no
more spool space is available, all userids on the system suffer. On older
versions of VM, spool file numbers are also a critical resource: When the
number of spool files reaches a certain limit, no more can be created.
TOOLSRUN has many safeguards built into it to prevent depletion of spool
space (or spool file numbers) due to unprocessed requests or requests that
generate large numbers of spool files.
Start. To re-start a shut disk, using the START request.
Subscribe. A request to receive a copy of any created or modified file
that matches a certain filename/filetype pattern, using the SUBSCRIBE
request (a synonym for INFORM SUBSCRIBE). If the file is appendable, you
will receive only a copy of each append. See also Inform.
Subshadow. Any shadow that is not fed directly by the master, such as a
second-level shadow. Third level shadows can also be found (but often are
not worth looking for).
Summary. To request a list of files on a disk, using the SUMMARY request.
See also List.
SYSTEM. TOOLSRUN authorization. Permits the use of requests that affect
the TOOLSRUN service machine itself, such as AGET, ALIST, AREPLACE and
SHUTDOWN. Does not imply any other authority.
System administrator. A person, with SYSTEM authority, who has the
primary responsibility for maintaining the TOOLSRUN service machine.
┌───┐
│ T │
└───┘
TOOLS. (1) The REXX program that is used to send requests to TOOLSRUN.
(2) The disk/conference management system composed of TOOLS EXEC and
TOOLSRUN EXEC.
TOOLS format. See TOOLSRUN form.
TOOLSRUN. The REXX program that runs on the disconnected VM service
machine and manages the disks.
Toolsrun form. A data file sent as a response to a GET or SUBSCRIBE
request, with the COPY option. The file has the form of a TOOLSRUN PUT
command (used by TOOLSRUN service machines to communicate with each
other). If received by another TOOLSRUN service machine, the file will be
created or (if it already existed) replaced.
Trace. To request a REXX trace of instructions executed by TOOLSRUN while
processing a request file, by using the TRACE override. Note that TRACE
will not work if the TOOLSRUN service machine is running a compiled
version of TOOLSRUN EXEC.
┌───┐
│ U │
└───┘
Uninform. To cancel a previous INFORM or SUBSCRIBE request, using the
UNINFORM request.
Unlock. To undo a LOCK request, by using the UNLOCK request, or by
replacing or placing the file.
Unsubscribe. To cancel a previous SUBSCRIBE request, using the
UNSUBSCRIBE request (a synonym for UNINFORM).
Update. (1) (Noun) Any request that changes a file. (2) (Verb) To
perform an incremental update of a large file, rather than replacement of
the whole file, using the UPDATE request. Incremental update data may be
produced using the IUPDATE PACKAGE, available from VMTOOLS (VMTOOLS at
| RALVM17).
┌───┐
│ V │
└───┘
Verb. The token in a request that determines the nature of the request
(i.e. the action to be taken by TOOLSRUN).
VM. (Virtual Machine). An IBM computer operating system. See also CMS.
Vote. To register a vote, incrementing the vote count for a token in a
VOTE file, by using the VOTE request.
┌───┐
│ W │
└───┘
WAD. (Working As Designed). See BAD.
WIBNI. (Wouldn't It Be Nice If...).
┌───┐
│ X │
└───┘
┌───┐
│ Y │
└───┘
┌───┐
│ Z │
└───┘
[A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [X]
| A |
ACCESSER TOOLSRUN authorization, B.1 ADDER, TOOLSRUN authority modifier, B.1 Address of a disk See Disks, address of Addressing disks See Disks, address of AGET, request verb, 5.1 AIX and TOOLS See Remote TOOLS commands, from AIX ALIST, request verb, 5.2 ANSWER, override verb, 6.1 APPEND, request verb, 4.1 APPENDER, TOOLSRUN authorization, B.1 Appending To Files, 1.3 See also Forums AREPLACE, request verb, 5.3
| B |
BATCH, request verb, 4.2 Batching, 4.2 Cancelling batched requests, 4.2 of GET requests, 4.7 of REFRESH requests, 5.14 Querying batched requests, 4.2 Releasing batched requests, 4.2
| C |
Catalogs of package files
See Packages of files, catalogs of
CATGEN, B.10.1
CLEAN, request verb, 4.3
CMS commands, entering, B.2
CMS, request verb, 5.6
Computer conferences, 1.3
appends to files
See Appending To Files
owning files, 1.3
multiple owners
subscribing to files, 1.3
Conferencing, using TOOLS for, B.3
COPY, request verb, 5.7
CP SMSG, B.7
CREATE, request verb, 4.4
| D |
Data disks
See Disks, for data and tools
Dates, TOOLS formats of, B.4
Append header form, B.4
TOOLSRUN standard form, B.4
Disk address, B.3
See also Disks, address of
Disk address, specifying, B.5
Disk addresses, finding, B.3
Disk name, B.3
Disk nicknames, specifying, B.8
DISK, request verb, 4.5
Disks, 1.2
address of, 1.2, 2.2
for conferences
See Computer conferences
for data and tools, 1.4
master, 1.2
multiple copies of, 1.2
nicknames of, 2.2
selecting, 2.2
shadow, 1.2
partial, B.12, 4.7, 4.10
DISKS files, B.8
| E |
ERASE, request verb, 4.6 Expiration of subscriptions See Subscription expiration
| F |
File packages
See Packages of files
Filename of a file, 1.2
Filename patterns, B.9
Files, 1.2
appendable
See Appending To Files
multiple owners
See Multiple owners of a file
Filetype of a file, 1.2
Filetype patterns, B.9
FOR, override verb, 6.2
Format of PACKAGE files, B.10
Forums
See also Appending To Files
shared, B.12, 4.7, 4.10
| G |
General request verbs APPEND, 4.1 BATCH, 4.2 CLEAN, 4.3 CREATE, 4.4 DISK, 4.5 ERASE, 4.6 GET, 4.7 HELP, 4.8 HIDE, 4.9 INFORM, 4.10 LIST, 4.11 LITERAL, 4.12 LOCK, 4.13 NEWOWN, 4.14 NOTIFY, 4.15 OWN, 4.16 PRUNE, 4.17 PUNCHTAG, 4.18 QUERY, 4.19 REGISTER, 4.20 REGRESS, 4.21 RENEW, 4.22 REPLACE, 4.23 RESPONSE, 4.24 SET, 4.25 SUBSCRIBE, 4.26 SUMMARY, 4.27 TRACE, 6.12 UNINFORM, 4.28 UNLOCK, 4.29 UNSUBSCRIBE, 4.30 UPDATE, 4.31 VOTE, 4.32 GET, request verb, 4.7 GETTER, TOOLSRUN authorization, B.1
| H |
HELP, request verb, 4.8 HIDE, request verb, 4.9
| I |
INFORM, request verb, 4.10
| L |
LEXX messages, 2.4 LIST, request verb, 4.11 LITERAL, request verb, 4.12 LOCK, request verb, 4.13 LOGOFF, request verb, 5.9
| M |
Master disks, B.3 See also Disks, master Messages, sending TOOLSRUN commands as, B.7 Multiple copies of disks See Disks, multiple copies of Multiple owners of a file, 4.13, 4.14
| N |
NEWOWN, request verb, 4.14 Nicknames for disks See Disks, nicknames of NOCLOSE, override verb, 6.3 NOCOPY, override verb, 6.4 NODEID, override verb, 6.5 NOPROMPT, override verb, 6.6 NOSCREEN, override verb, 6.7 NOTIFY, request verb, 4.15
| O |
OS/2 and TOOLS See Remote TOOLS commands, from OS/2 Override verbs ANSWER, 6.1 FOR, 6.2 NOCLOSE, 6.3 NODEID, 6.5 NOPROMPT, 6.6 NOSCREEN, 6.7 PROPAGATE, 6.8 QUIET, 6.9 SENDTO, 6.10 TO, 6.11 OWN, request verb, 4.16 OWNER, TOOLSRUN authorization, B.1 Owning conference files See Computer conferences, owning files
| P |
PACKAGE filetype See Packages of files PACKAGER, TOOLSRUN authorization, B.1 Packages of files, B.10 catalogs of, B.10.1 CREATE, effect of, 4.4, B.10 ERASE, effect of, 4.6, B.10 format of, B.10 GET, effect of, 4.7, B.10 HIDE, effect of, 4.9, B.10 INFORM, effect of, 4.10, B.10 PLACE, effect of, B.10 QUERY, effect of, 4.19, B.10 REGISTER, effect of, 4.20, B.10 REGRESS, effect of, 4.21, B.10 REPLACE, effect of, 4.23, B.10 SUBSCRIBE, effect of, 4.26, B.10 Partial shadows See Disks, shadow, partial Patterns, B.9 PKGEDIT, B.10.1 PLACE, request verb, 5.11 PRIV request verbs BATCH RELEASE, 5.4 CLEAN, 4.3, 5.5 COPY, 5.7 GET disk AUDIT, 5.8 NOCOPY (override), 5.10, 6.4 PLACE, 5.11 REFRESH, 5.14 SHUTDOWN, 5.15 START, 5.16 PRIV, TOOLSRUN authorization, B.1 PROPAGATE, override verb, 6.8 PRUNE, request verb, 4.17 PUNCHTAG, request verb, 4.18
| Q |
QUERY, request verb, 4.19 QUERY BATCH, 4.19 QUIET, override verb, 6.9
| R |
REFRESH, request verb, 5.14
REGISTER, request verb, 4.20
REGRESS, request verb, 4.21
Remote TOOLS commands, B.13
from AIX, B.13
from OS/2, B.13
from UNIX, B.13
via TOOLNOTE, B.13.3
via XAGENT, B.13.2
RENEW, request verb, 4.22
REPLACE, request verb, 4.23
REPLACER, TOOLSRUN authorization, B.1
Request batching
See also Batching
Releasing batched requests
FOR someone else, 4.2
Your own, 4.2
RESPONSE, request verb, 4.24
| S |
Selecting disks See Disks, selecting SENDTO, override verb, 6.10 SET, request verb, 4.25 Shadow addresses, finding, B.3 Shadow disks, B.3 See also Disks, shadow SHUTDOWN, request verb, 5.15 SMSG, B.7 START, request verb, 5.16 SUBSCRIBE, request verb, 4.26 Subscribing to conferences See Computer conferences, subscribing to files Subscription expiration, 4.10 INFORM, 4.10 Querying, 4.19 RENEW, 4.22 SET ADDRESS and .., 4.25 SUBSCRIBE, 4.26 SUMMARY, request verb, 4.27 SYSTEM request verbs AGET, 5.1 ALIST, 5.2 AREPLACE, 5.3 CMS, 5.6 LOGOFF, 5.9 SHUTDOWN, 5.15 SYSTEM, TOOLSRUN authorization, B.1
| T |
TO, override verb, 6.11
TOOLCAT, B.10.1
TOOLS, B.3
Tools disks
See Disks, for data and tools
TOOLS EXEC, 2.1, 1.1
addressing disks
See Disks, address of
overview, 2.1
selecting disks
See Disks, selecting
TOOLSRUN, B.3
TOOLSRUN authorizations, B.1
ACCESSER, B.1
ADDER authority modifier, B.1
ADDER, verbs requiring
APPEND, 4.1
RENEW, 4.22
VOTE, 4.32
APPENDER, B.1
APPENDER, verbs requiring at least
APPEND, 4.1
RENEW, 4.22
VOTE, 4.32
GETTER, B.1
GETTER, verbs requiring at least
BATCH CANCEL, 4.2
BATCH QUERY, 4.2
GET, 4.7
INFORM, 4.10
LIST, 4.11
QUERY, 4.19
REGISTER, 4.20
SET, 4.25
SUBSCRIBE, 4.26
SUMMARY, 4.27
TRACE (override), 6.12
UNINFORM, 4.28
UNSUBSCRIBE, 4.30
None required
See TOOLSRUN authorizations, Verbs requiring no authorization
OWNER, B.1
OWNER, verbs requiring at least
CREATE, 4.4
ERASE, 4.6
OWN, 4.16
SET, 4.25
PACKAGER, B.1
PACKAGER, verbs requiring at least
PRIV, B.1
PRIV, verbs requiring
BATCH RELEASE, 4.2, 5.4
CLEAN, 4.3, 5.5
COPY, 5.7
GET disk AUDIT, 4.7, 5.8
NOCOPY (override), 5.10, 6.4
PLACE, 5.11
REFRESH, 5.14
SHUTDOWN, 5.15
START, 5.16
REPLACER, B.1
REPLACER, verbs requiring at least
CLEAN, 4.3
HIDE, 4.9
LOCK, 4.13
NEWOWN, 4.14
PRUNE, 4.17
REGRESS, 4.21
REPLACE, 4.23
SET, 4.25
UNLOCK, 4.29
UPDATE, 4.31
SYSTEM, B.1
SYSTEM, verbs requiring
AGET, 5.1
ALIST, 5.2
AREPLACE, 5.3
CMS, 5.6
LOGOFF, 5.9
QUERY SYSTEM, 4.19, 5.12
QUERY USAGE, 4.19, 5.13
SHUTDOWN, 5.15
Verbs requiring no authorization
ANSWER (override), 6.1
DISK, 4.5
FOR (override), 6.2
HELP, 4.8
LITERAL, 4.12
NOCLOSE (override), 6.3
NODEID (override), 6.5
NOPROMPT (override), 6.6
NOSCREEN (override), 6.7
NOTIFY, 4.15
PROPAGATE (override), 6.8
PUNCHTAG, 4.18
QUIET (override), 6.9
RESPONSE, 4.24
SENDTO (override), 6.10
TO (override), 6.11
TOOLSRUN conferences, B.3
TOOLSRUN EXEC, 2.1, 1.1
TRACE, override verb, 6.12
| U |
Uninform, how to, B.11 UNINFORM, request verb, 4.28 UNIX and TOOLS See Remote TOOLS commands, from UNIX UNLOCK, request verb, 4.29 UNSUB, B.11 Unsubscribe, how to, B.11 UNSUBSCRIBE, request verb, 4.30 UPDATE, request verb, 4.31
| V |
VOTE, request verb, 4.32
| X |
XAGENT and TOOLS See Remote TOOLS commands, via XAGENT XEDIT messages, 2.4