MasterOp is an operations monitoring/scheduling/controling utility that allows event introduction by time, date, business day, device availability, CS Device status, Job status, JCW state, or combinations of the above. If the event scheduled is the streaming of a job, MasterOp can also handle any pending replies on console for that job automatically. MasterOp can schedule a job to stream after the completion of one or more other jobs as well. This allows jobqueues of incredible complexity to be handled easily without worrying about jobfences or job limits. These jobqueues can even be regulated across systems, and one session using MasterOp can be used to "look in" on and/or control another MasterOp session on the same system or on another system. There is also no need to EVER change dates in a jobstream again. All the user does is put a simple date expression, along with the way it is to be formatted, into the jobstream where the date would normally appear, and MasterOp will automatically calculate, format, and substitute in that date. MasterOp also allows users to create files of parameters to substitute into jobstreams so that things like passwords, lockwords, and filenames can be changed uniformly from one central location. Events need not be limited to the streaming of jobs, however. An event can be any programatically executable MPE command, or any command recognized by MasterOp. MasterOp can also process RUN commands and UDC's (after loading by means of the UDC command). MasterOp even allows the processing of XEQ files as events. MasterOp allows optional reporting to console of relevant status information and problems arising during a session of MasterOp. Spoolfile alteration is much easier and faster with MasterOp. Groups of spoolfiles can be altered by one command. They can be grouped by device/class, priority, number of copies, file name, job number, state, or any combination of these. This is especially handy when a single job creates several spoolfiles that need to be printed together. MasterOp allows the user to list the time and date a job was streamed to his terminal and/or a spooled file. Finally, MasterOp allows users to be barred from the system by name, group, or account. MasterOp allows multiple commands within a single command line. The delimiter between commands is "\". Commands may be nested within status-monitoring commands (AFTER, AT, WHEN, etc.) by use of parentheses. To continue a command on the next line, type in a "&" as the last character in the line. No command may exceed 255 characters in length, however. MasterOp assumes that the user has access to, or can obtain access to, certain operator commands. These commands are: ALTSPOOLFILE, LIMIT, JOBFENCE, ALTJOB, DELETESPOOLFILE, ABORTJOB, REPLY, SHOWCOM, and WARN. If you can use the MPE command ALLOW, MasterOp will take care of this. If not, you will have to be ALLOWed the use of these commands in order for MasterOp to function properly. MasterOp is interactive and works equally well from batch or interactive mode. If used in batch mode, the last command in the MasterOp run MUST be either E or EXIT (E is preferred, since this gives MasterOp a chance to complete ALL its status monitor/control functions before logging off). MasterOp allows up to 1023 commands for the status monitoring functions AFTER, AT, AUTOREPLY, EXCLUDE, ONABORT, ONLOGON, OK, RECALL, SCHEDULE, STATBEGIN, STATEND, and WHEN at a time. It also allows 100 simultaneous LOOKUP, QLIMIT, STREAM, STREAM1, and STREAM2 commands to be processed at a time. MasterOp requires a large amount of storage space, since much of its operation involves scheduling events that will be processed at some future time. Since it is not practical to store this much data in main memory, MasterOp stores this data in files. It is therefore assumed that the user can create and save files. MasterOp also requires the ability to create at least 5 extra data segments for storage of supporting data structures. For EOJ to EOJ jobqueues, MasterOp requires that each job be able to retrieve its own job number. To do this the job in each jobqueue should be able either to access the JOBINFO Intrinsic, or to create a temporary file. There is no need to alter job files. If one of those conditions are met, MasterOp will automatically handle the means of getting a job its own job number. MasterOp/3000 has evolved over the last eight years into its current form. Much of it was written "on the fly," so comments are non-existent, some of the structures are less than intuitive, and the interrelationships between different segments of code are at times difficult to see. For these reasons, I DO NOT RECOMMEND THAT YOU ATTEMPT TO CHANGE THE CODE YOURSELF. I will, however, be most happy to enhance the code for you, so long as the change is reasonable and fits within the framework of what MasterOp/3000 is intended to be. My update policy has ALWAYS been quite liberal (to a fault, some would say) and I almost never turn down any reasonable enhancement request. Please send your requests to: Carl W. Kemp III, 718 E. Acacia Ave., Glendale, CA 91205. I look forward to hearing from you. Installing MasterOp/3000 The installation of MasterOp/3000 is relatively painless. First, restore the file BULDKEMP.PUB.KEMP using the ;LOCAL option of the RESTORE command. Edit the file, inserting passwords as needed. Then, stream the edited file. This file will create the KEMP account, where MasterOp/3000 resides. Finally, restore @.@.KEMP. General Syntax for Scheduling Commands MasterOp/3000 allows the user to schedule according to a wide variety of system events. It also lets the user schedule a wide variety of actions. To facilitate the learning process, most of MasterOp/3000's scheduling commands have the same basic form. A MasterOp/3000 scheduling command has three basic parts. The three parts are the type of triggering event, the specific events themselves, and the action to be taken. They appear in a MasterOp/3000 command as follows: command dependencies (action) The command tells MasterOp/3000 what type of dependency is being established. The types of dependencies are: calendar patterns (SCHEDULE), system time (AT), one or more jobs logging off (AFTER), a job aborting before EOJ (ONABORT), a job logging on (ONLOGON), Logical Device, CS Device, File, and/or JCW states (WHEN), pending replies (RECALL), and user verification (OK). Note that each type of dependency is associated with a MasterOp/3000 command. Once MasterOp/3000 knows what type of dependency it is looking for, it must know more specifically which event it is going to wait for. For example, the AT command specifies scheduling by system time. Therefore, the specific event to wait for is a time that must be specified by the user (such as AT 23:55, meaning when the system time crosses 11:55 p.m.). The command RECALL specifies scheduling by pending reply. Hence, the specific dependency is a description of the job(s)/session(s) whose pending replies are to be watched for. The commands SCHEDULE, AFTER, and WHEN allow more than one specific event to be specified. For the SCHEDULE and AFTER commands, the specified events must be separated by commas, and all must be satisfied before the action specified will be processed. For the WHEN command, the various specified events are linked to form a logical expression which must be true before the specified action will be taken. The OK command has no specific events because the type of dependency is also a specific event. Finally, MasterOp/3000 must know what it is scheduling. The action to be taken can be any command or series of commands understood by MasterOp/3000. If the user wishes to specify a series of actions to be taken, the actions must be separated by "\"'s, and the entire series must be surrounded by parentheses. Examples of MasterOp/3000 scheduling commands with translation: SCHEDULE NBD=@,DAY=MON XEQ MONHDAY will process the commands contained in the file MONHDAY on every Monday that is a holiday. AFTER JOB1,JOB2,JOB3 (STREAM JSYSDUMP\AUTOREPLY JSYSDUMP LDEV=7) will stream the job JSYSDUMP and will reply to the job with a 7 for any pending reply containing the string "LDEV" after the jobs JOB1, JOB2, and JOB3 have all logged off. WHEN FILE STRFL=CLOSED DO (FILE T;DEV=TAPE\STORE STRFL;*T) will store file STRFL to tape as soon as it is not being accessed. RECALL @ TELLME A REPLY IS PENDING will let the user know whenever a reply is pending. Command Parsing and Error Checking in MasterOp/3000 MasterOp/3000 allows the user to schedule events in such a way that the command may be interpreted differently at its issue from its final meaning when it is due to be executed. The change of meaning may be so drastic that it might be considered erroneous at one point while being considered perfectly valid at another. A few examples will explain this more clearly. Example #1: The user desires to run program TELECOM and, if it has not stopped by 23:55, terminate it. The following command sequence will handle it: AT 23:55 (CONTINUE\KILLSON TELECOM) RUN TELECOM Notice two things here. First, the AT command MUST appear first in this case. The reason for this is that, if the RUN command were to appear first, the AT command would not be read until the program had already terminated, quite possibly after 23:55. Second, notice that, at the issue of the AT command, the command KILLSON TELECOM makes no sense since it hasn't even been created yet. However, in the context in which the command will be processed, it makes perfect sense. The process TELECOM will have been created and indeed may still be active. This illustrates one of the most important features (and a potential problem for careless users) of MasterOp/3000: it will suspend error checking on a scheduled event until the event is released for processing. In MasterOp/3000 the CONTEXT of a command is as important as the TEXT of the command. To illustrate this point further, consider the following example: Example #2: Given the commands: WHENEVER FIXABLE>=FAIL DO DEFINE CMD1,QUIT WHENEVER FIXABLE0 DO (CMD1) What does CMD1 mean? In this case, it depends on the value of the JCW FIXABLE when DBERR is not equal to zero. If it is less than FAIL, then CMD1 means XEQ FIXFL. Otherwise, an abort is triggered. In this case, we not only don't know the format of CMD1 at the issue of the first command, we don't even know which command it will be. This can be extremely useful when the event to be triggered depends on several different variables that must be considered separately. Example #3: The commands: AFTER LASTJOB DEFINE ABORT,TELLOP AT 23:55 ABORT WE MADE IT!!! when issued from a MasterOp/3000 job, will cause the job to abort if LASTJOB has not finished by 23:55, and will send a tellop if it has finished by then. Notice that the command may be changed from a command with three different errors (ABORT has no parameters, can be issued only from sessions, and only when in BREAK mode) into a command with NO errors (TELLOP WE MADE IT!!!), depending on whether LASTJOB finishes before the designated time. Be aware, however, if you change the definition of a MasterOp/3000 command or that of an MPE command, trouble may result (especially if that command is used in several loaded UDC's). It is therefore suggested that, when the user wishes to issue a command to be defined later, that the user restrict himself to a command name that has not been previously defined. The above examples all serve to express one critical point about scheduling with MasterOp/3000. MASTEROP/3000 CANNOT CHECK A COMMAND FOR ERRORS UNTIL BOTH THE TEXT AND CONTEXT OF THE COMMAND ARE FIRMLY ESTABLISHED. The context is not established for any scheduled event until it is actually released for processing. This means that A SCHEDULED EVENT IS NOT PRE-PROCESSED. It is therefore up to the user to decide what the syntax of a scheduled event will be at the release of the event, and to insure that this syntax is adhered to. MasterOp/3000 Files The following is a partial list of some of the more important files used by MasterOp/3000. MASTEROP.PUB.KEMP: This is the program that is run to initiate a MasterOp/3000 job/session. MOP3.PUB.KEMP: This is MasterOp/3000's most important son process. It allows MasterOp/3000 to examine in detail the results of various MPE commands. EMOPCMDX.PUB.KEMP: The Help file for MasterOp/3000. It briefly documents the syntax and use of MasterOp/3000 commands. MANUAL.PUB.KEMP: MasterOp/3000's Technical Reference Manual. It contains extensive documentation regarding the operation of MasterOp/3000. ERRCAT.PUB.KEMP: The list of MasterOp/3000 error and warning messages. ENVCOPY.PUB.KEMP: This son process of MasterOp/3000 tracks this session's current JCW's and :FILE equations. The files maintained by this process are used to recover the user's environment in the event of a system failure or process failure. COMMAND.PUB.KEMP: This process handles all terminal I/O for the command-driven version of MasterOp/3000. PRIVCMD.PUB.KEMP: This process handles all terminal I/O for the PRIV mode command-driven version of MasterOp/3000. It uses NOWAIT I/O on $STDINX so that it may interrupt a pending read with incoming network messages and output from "piped" processes. NOWORK.PUB.KEMP: The list of MasterOp/3000 non-business days. IMPORTANT ---> Make sure this reflects your current non-business days to insure proper business day scheduling and calculation. refer to the section "Calculating and Substituting Dates" for the format of this file. MESNGR.PUB.KEMP: A program used to access the MasterOp/3000 network without having to run MASTEROP.PUB.KEMP. MOPWAKE.PUB.KEMP: A program used to re-activate MasterOp in the event that a BREAK becomes necessary (son process hung on Fread or in an infinite loop, etc.). This program is activated for this MasterOp/3000 session via the WAKEUP command. Thereafter, if anything is written to the file specified in the WAKEUP command while in BREAK (LISTF and the MPE-XL PRINT and COPY commands do this quite well from break), MasterOp/3000 will be awakened when RESUME is entered, and the text sent to the file will be processed as a command. SHOWME.PUB.KEMP and SMFILE.PUB.KEMP: The files used to retrieve a user's remote job number for use in the MasterOp/3000 network. RESET.PUB.KEMP and TRACER.PUB.KEMP: Programs used by jobs streamed from MasterOp/3000. These programs are used to alert MasterOp/3000 that the job involved did in fact complete successfully. MOPCMSET.DOC - This indirect file contains the file set for MasterOp/3000 running under MPE V. It contains executable and data files only. MOPXLSET.DOC - This indirect file contains the file set for MasterOp/3000 running under MPE-XL. It contains executable and data files only. EMOPMANL.PUB - This is the source file that TDP uses to create the Technical Reference Manual. This is the central manual for MasterOp. EMANLXEQ.PUB - This is the TDP USE file that creates the Technical Reference Manual. EOJLOG01 - EOJLOG99: These are files created by MasterOp/3000 to receive EOJ verification from MasterOp/3000 jobs. These files are usually purged by MasterOp/3000 at the end of the session, but a system failure, halt or hang will prevent this. Any of the EOJLOG files that are not being accessed should be purged. MOPL?###: These are recovery logs created by MasterOp/3000 in order to be able to recover from a job abort or system failure. If you are not going to recover a MasterOp/3000 job/session then these files may be purged.