The following sections describe how to use the system job feature. It is assumed you have already read (INT_XM_chap) and are now running under the XM or ZM monitor.

This chapter contains the following information: (unnumbered) Points you should consider before starting any system jobs Three ways you can start a system job Calling a system job once you have started it Stopping (aborting) a system job once you no longer need it Unloading a system job to regain the memory it used Creating indirect command files to abort and unload system jobs

Each section contains exercises to familiarize you with the system job environment.

You will find it helpful to have already read and worked through the exercises in (int_KED_chap).

Use the on-line index utility, INDEX, and see the on-line help utility, HELP, for more information on the topics described in this chapter. (Before Starting System Jobs\sysjob_bef_sec)

You should consider the following points before you start a system job: (unnumbered) All device handlers used by a system job must reside on your system device and be loaded. The system device handler is always resident and loaded, so it is of no concern here.

Think for a moment about the devices used by a system job, such as SPOOL. SPOOL manages files that you direct to your printer. Therefore, the device handlers you are concerned with are those for the device containing the file and the device handler for your printer. If you are unsure about the status of the device handlers, examine the directory of your system device by using the following command: (.)(DIRECTORY SY:%%X.SYS (RET))

The percent character (%) in that command is a single-character wildcard. All handlers you use under mapped monitors must have the X suffix. If a handler that is used by a system job does not reside on your system device, you must copy it to there.

Use the SHOW command to determine the status of the device handlers. Issue the command: (.)(SHOW (RET))

The SHOW command displays all the device handlers installed on your computer system and their status. Handlers are displayed in their general form; the X suffix is not displayed. (Any handler displayed as being Resident is required by RT--11, is loaded, and cannot be unloaded.) If the SHOW command does not display a handler you require, install that handler. Use the following command where (dd) represents the 2-character general form of the handler you want to install: (.)(INSTALL dd (RET))

If the SHOW command displays the handler you require but does not indicate it is loaded, you must load that handler. Use the following command where (dd) represents the 2-character general form of the handler you want to load: (.)(LOAD dd (RET))

You can load a handler from an indirect command file, your start-up command file, or directly at the monitor prompt as shown here. System jobs, foreground jobs, and jobs that run as pseudohandlers like SL, are loaded into memory in the order that you start them.

This is an important consideration because you will occasionally stop (abort) and unload jobs when you need the memory allocated to a job.

After you boot your computer, each job you run as a foreground or system job is loaded at the highest place possible in low memory. To keep from fragmenting the memory in your computer, you unload jobs from the lowest point in memory and proceed upward. Therefore, you should plan to run jobs first that you will rarely want to unload. You should be more willing to unload each successive job you load.

For example, if you are going to use the single-line (SL) command editor, you will normally always use SL and therefore not want to unload it. Therefore, SL is a good candidate for loading first. (Starting System Jobs)

The method you use to start a system job should be determined by how you are going to use that system job and the complexity of the startup procedure. You can start a system job three ways: (unnumbered) With the start-up command file for the monitor you are using

If you are going to use a system job whenever you first boot your computer, you should probably start that job from your start-up command file. If you are going to normally keep that job loaded in memory, you should run that job early in the start-up command file. By running an indirect command file that starts the job

If you are going to use a system job periodically and the startup procedure for that system job requires more than a single command, you should probably start that job by running an indirect command file. Directly at the keyboard using the SRUN command

System jobs that require only a single command line to start should probably be started directly from the keyboard.

The following three sections describe starting system jobs. (Starting System Jobs from Start-Up Command Files)

RT--11 is distributed with default start-up command files for each monitor. For example, when you boot the XM monitor, that monitor looks for the start-up command file STRTXM.COM. (The ZM monitor looks for STRTZM.COM.) The start-up command file must reside on your system (SY) device.

You can edit your start-up command file to start system jobs when you first boot your computer. You can also create your own start-up command file, but you must retain the same file name. Digital recommends that you edit the distributed start-up command file rather than create your own, especially if you are a new user of the RT--11 operating system.

The distributed start-up command files for XM and ZM contain most of the commands necessary to run two system jobs, VTCOM and SPOOL. If you want to maintain continuous communication with a host processor when you first boot your RT--11 system, you probably want to start VTCOM from your start-up command file. If you typically begin printing files shortly after you boot your RT--11 system, you probably want to start SPOOL from your start-up command file.

Because RT--11 assigns priority to system jobs in the order in which they are started (unless you specify otherwise), you should start a time-critical system job such as VTCOM, before a non-time-critical job such as SPOOL or KEX. Because of this, VTCOM is positioned in the distributed start-up command files as the first system job.

(int_startup_chap) contains information on editing your start-up command file. (Starting System Jobs from an Indirect Command File\sysjob_ind_sec)

You can create an indirect command file that runs a particular system job. Use this method to start a system job when: (unnumbered) You do not require that job when you first boot your computer The start procedure is more than a single command line.

Such a system job may be SPOOL. You can start SPOOL from your start-up command file; the command lines to do that are included in the file. However, if you only need the SPOOL utility periodically, you can start it from an indirect command file. By only loading SPOOL in memory when needed, you preserve more computer memory when you are not printing files or using SPOOL for some other purpose.

The following procedure creates an indirect command file you can use to start the SPOOL utility. The procedure assumes you are familiar with basic KED operations as described in (int_KED_chap). It also assumes you are going to use the SPOOL utility to send files to a serial printer that uses the LS handler. (numbered) Issue the following command to open your start-up command file (STRTXM.COM or STRTZM.COM) for inspection: (.)(EDIT/INSPECT SY:STRTXM.COM (RET)) (or) (.)(EDIT/INSPECT SY:STRTZM.COM (RET)) Press the (PF1) (PF3) keypad sequence and search for the string (spool). The result of that search places the cursor at the following text: ! ! Start the spooler on a Pro 300 or a PDP-11 with a serial printer. ! On PDP-11 systems, the LS handler must have its CSR and vector cor- ! rectly selected using the SET LS CSR=nnnnnn and SET LS VECTOR=nnn ! commands. LS is distributed with its CSR and vector preset for a Pro ! 300 computer. If you are a Professional 350 user and have a printer, ! the following commands are normally selected. ! !SRUN SPOOL.SAV/PAUSE !LOAD LS=SPOOL !RESUME SPOOL !ASS SP0 LP !ASS SP0 LP0 !ASS SP0 LS !ASS SP0 LS0 Press the (PF1) ( 7 ) keypad sequence. (Command:)(OPEN OUTPUT SPOOL.COM (ENTER)) Scroll down through the file until your cursor rests on the exclamation point (!) before the command SRUN SPOOL.SAV/PAUSE. Create a select range by pressing the ( . ) keypad key. Then repeatedly press the ( 0 ) keypad key until the cursor rests on the exclamation point (!) one line below the command !ASS SP0 LS0 Press the (PF1) ( 7 ) keypad sequence. (Command:)(WRITE SELECT (ENTER)) Press the (PF1) ( 7 ) keypad sequence. (Command:)(CLOSE (ENTER)) Press the (PF1) ( 7 ) keypad sequence. (Command:)(QUIT (ENTER)) (.) Using KEX's auxiliary output file feature, you have created a file named SPOOL.COM on your data (DK) device and are back at the monitor prompt (.). Issue the following command to open the file SPOOL.COM, using the KEX editor: (.)(EDIT SPOOL.COM (RET)) Edit that file to remove the exclamation points (!), which act in the file as comment delimiters. After you edit it, your file should look like the following: ! SPOOL.COM, created dd-mmm-yy, edited dd-mmm-yy ! Starts SPOOL from indirect command file ! SRUN SPOOL.SAV/PAUSE LOAD LS=SPOOL RESUME SPOOL ASS SP0 LP ASS SP0 LP0 ASS SP0 LS ASS SP0 LS0 You have now created an indirect command file that, when called with the following command, starts the SPOOL utility: (.)($@SPOOL (RET)) This indirect command file, SPOOL.COM, does not contain all the commands to fully implement the spooler and configure your serial printer. (int_startup_chap) discusses other commands you might require to fully implement the spooler and configure your printer. After you have completed the exercises in (int_startup_chap), you can use the information from this section to create indirect files to start the SL editor, the VTCOM communications package, and SPOOL. (Starting System Jobs from the Command Line)

Some system jobs, such as KEX, can be started directly at the command line using the SRUN command. For example, the following command starts the KEX editor as a system job. Issue the command: (.)(SRUN KEX.SAV (RET))

RT--11 notifies you that KEX is now running as a system job by displaying the KEX system job prompt (KEX>) and KEX utility command prompt (*), and then returns you to the background. You are in the background environment and can enter commands even though the monitor prompt (.) may not be displayed. You can press (RETURN) to display the monitor prompt.

You can see KEX loaded in memory by issuing the command: (.)(SHOW MEMORY (RET))

In the display on your screen, note that KEX requires approximately 28K words of extended memory and somewhat less than 1K words of low memory. (Naming System Jobs)

You can use the /NAME:jobname option to assign a name to a system job. The name can be any alphanumeric string of 1 to 6 characters. RT--11 starts the system job and assigns it that name. Then, you always refer to the system job by the name you assigned it.

You can use the /NAME:jobname option to start more than one KEX editor and distinguish between them. Issue the following command to start a second KEX editor and assign it the name KEX1: (.)(SRUN KEX.SAV/NAME:KEX1 (RET))

Then, issue the command: (.)(SHOW MEMORY (RET))

Note that KEX1 is loaded in memory below KEX and requires the same amount of memory as KEX. (Calling the System Job)

System jobs are of two types. One type of system job runs transparently once started. Such a system job is SPOOL. Once you start SPOOL you need not call it. This section discusses the other type of system job --- the type you call to use.

You can connect to only one background job or foreground job. Therefore, to summon a job running in the background environment, press (CTRL/B). Press (CTRL/F) to summon a job running in the foreground environment. System jobs are different from background and foreground jobs in that you have to call them by name. Press (CTRL/X) to summon the system job environment, then specify the system job by name because there can be up to six system jobs running at the same time. (From the Background)

As a result of the previous section, you are now running two editors as system jobs: KEX and KEX1. The following exercise demonstrates how to call those jobs. (numbered) Press (CTRL/X). RT--11 displays the system job environment prompt: (Job?) Type KEX in response to the system job environment prompt and press (RETURN): (Job?)( KEX (RET)) RT--11 displays the system job prompt and positions the cursor below that prompt: (KEX>) ()

Although the asterisk (*) is not displayed, the cursor resides at the KEX utility command prompt. You can optionally display the KEX utility command prompt by pressing (RET). You then type the name of the file you want to edit or create. For the purpose of this exercise, create a file on your default data device named MYFIL.TXT: (KEX>) (MYFIL.TXT (RET))

RT--11 searches your directory for that file, does not find it (you are creating it), and returns the following prompt in reverse video: (?KEX-W-File not found - Create it (Y,N)?)

Type Y to create that file. The KEX editor then opens that file for you to edit. For the purpose of this exercise, press (RETURN) a couple of times and then type the following text: (This is file MYFIL.TXT created using KEX.) Press (CTRL/B). The background environment prompt (B(>)) appears on your terminal screen; you are now in the background. Optionally, you can press (RET) to display the keyboard monitor prompt (.). You can now enter a command to start another system job, run a foreground job or a background job, or perform an operation such as copying or printing a file. The file MYFIL.TXT is still open on the KEX editor. Do the following to return to your file MYFIL.TXT (open on KEX): (alphabetic) Press (CTRL/X) to display the system job environment prompt. Specify the system job KEX. Press (RETURN). Press (CTRL/W) to repaint your screen.

You are back in your file MYFIL.TXT and the cursor is in the same position as you left it.

In that manner, you can move between a system job and the background environment. You move between a system job and the foreground environment in the same manner, except you use (CTRL/F) to summon the foreground job. (From Another System Job)

You can also move from one system job to another. You started another KEX editor in the previous section and named that second KEX editor KEX1. You are now going to open a file with KEX1 and move back and forth between the two editors. (numbered) While still in the file MYFIL.TXT, press (CTRL/X). RT--11 displays the system job environment prompt: (Job?) Type the system job KEX1. Press (RETURN). (Job?)( KEX1 (RET)) RT--11 displays the system job prompt: (KEX1>) Type the file name MYFIL1.TXT and press (RETURN). (KEX1>) (MYFIL1.TXT (RET))

RT--11 searches your default data device directory for that file, does not find it (you are creating it), and returns the following prompt in reverse video: (?KEX-W-File not found - Create it (Y,N)?)

Type Y to create that file. KEX1 then opens that file for you to edit. For the purpose of this exercise, press (RETURN) a couple of times and then type the following text: (This is file MYFIL1.TXT created using KEX1.) () (This sentence is going to be copied over to MYFIL.TXT further along) (in this section.) Press (CTRL/B) to return to the background environment. You can then press (RETURN) a few times to make the display easier to read.

You now have files open on two different editors and are in the background environment. You can enter a command to start another system job, start a program in the foreground environment or the background environment, or perform other operations.

You can summon either editor by pressing (CTRL/X), supplying the editor name, and pressing (RETURN). Pressing (CTRL/W) repaints your terminal screen with the file opened on that editor. The cursor is positioned in each file where you left it --- each editor is currently running, contains an opened file, and is waiting for input. (Example Interaction Between System Jobs)

You can use KEX's auxiliary file feature to transfer any part of a file between two (or more) KEX editors you are running as system jobs. The following is the general procedure, followed by an exercise that illustrates the procedure. You should read the procedure and perform the exercise. (numbered) Open an output file from the editor that contains the part of a file you want to transfer.

You should use a consistent file extension when you are creating an auxiliary output file for this purpose, such as .AUX. Write the part of the file you want to transfer to the auxiliary output file. Then close that auxiliary output file. Call the editor which has the file opened that is to receive the contents of the auxiliary file. Using your keypad, move to the point in that file where you want the auxiliary file written. Open that auxiliary file as an input file. Then, include the contents of the auxiliary file in the file you are currently editing. Optionally, you can then go to the background environment and delete the auxiliary file.

The following exercise demonstrates the procedure described above. You currently have files opened on two KEX editors: MYFIL1.TXT on KEX1 and MYFIL.TXT on KEX. You are going to transfer the following line from MYFIL1.TXT to MYFIL.TXT: This sentence is going to be copied over to MYFIL.TXT further along in this section.

Do the following: (numbered) Call the editor which has the file opened that contains the part you want to transfer: (alphabetic) Press (CTRL/X) (Job?)( KEX1 (RET)) Press (CTRL/W) to repaint your screen with the contents of MYFIL1.TXT. Open the auxiliary output file:

Press (PF1) ( 7 ) (Command:)(OPEN OUTPUT MYFIL1.AUX (ENTER)) Write the file part to the auxiliary file: (alphabetic) Using the keypad, move the cursor to the beginning of the target, ((This sentence is going ...)), and press ( . ) to initiate a select range. Move the cursor to the end of the target and press (PF1) ( 7 ). (Command:)(WRITE SELECT (ENTER))

This exercise involves only one line. In practice, you can transfer virtually any amount of text or data in this manner. The size of your cut and paste buffer does not limit auxiliary files.

Note that the line still remains in the file; you have not deleted it but rather copied it. Press (PF1) ( 7 ) (Command:)(CLOSE (ENTER)) Call the editor containing the file to which you want to write the auxiliary file: (alphabetic) Press (CTRL/X) (Job?)( KEX (RET)) Press (CTRL/W) to repaint your screen with the contents of MYFIL.TXT. Open the auxiliary file as an input file:

Press (PF1) ( 7 ) (Command:)(OPEN INPUT MYFIL1.AUX (ENTER)) Include the auxiliary file: (alphabetic) Using the keypad, move the cursor to where you want to write the target line. Press (PF1) ( 7 ) (Command:)(INCLUDE REST (ENTER))

You will see the contents of the auxiliary file MYFIL1.AUX written into your file. Delete the auxiliary file:

Under different circumstances, you may want to save the auxiliary file. However, as this is an exercise: (alphabetic) Press (CTRL/B) Issue the following command: (.)(DELETE MYFIL1.AUX (RET))

In that manner, you can transfer text or data between files that are open on editors running as system jobs.

For the purpose of this exercise, you are now going to make permanent the file MYFIL.TXT. Any time you open a file on an editor, you open a temporary file. If you open a file but do not close it, no directory entry is created for that file. You are going to close the file MYFIL.TXT and make it permanent with the EXIT command. You will then display the file's directory entry, type the file, and delete the file. (numbered) Press (CTRL/X) to display the system job environment prompt. Notify RT--11 that you want to summon the KEX editor by typing KEX in response to that prompt and pressing (RETURN): (Job?)( KEX (RET)) (KEX>) Press (CTRL/W) to repaint your terminal screen. KEX displays the contents of MYFIL.TXT. Press the (PF1) ( 7 ) keypad keys and issue the command EXIT: (Command:)(EXIT (ENTER)) KEX closes the file MYFIL.TXT and displays its utility command (*) prompt. You could at that point create another file or open an existing file for editing on KEX by typing a file name. Instead, press (CTRL/B) to return to the background environment. Issue the following command to display the directory entry for MYFIL.TXT: (.)(DIRECTORY MYFIL.TXT (RET))

RT--11 displays the directory entry for that file. Issue the following command to type that file on your terminal screen: (.)(TYPE MYFIL.TXT (RET))

RT--11 types that file on your terminal screen. Issue the following command to delete MYFIL.TXT from your directory. You have not protected that file by issuing the PROTECT command, so you can delete that file without issuing the UNPROTECT command: (.)(DELETE MYFIL.TXT (RET))

RT--11 deletes that file from your directory.

For the purpose of this exercise, you are now going to eliminate the temporary file MYFIL1.TXT, currently opened on KEX1. No permanent directory entry exists for MYFIL1.TXT because you have opened it on KEX1 for the first time. The QUIT command stops the editing of the file MYFIL1.TXT without closing it. Therefore, no directory entry is created for MYFIL1.TXT; it is not made permanent. (numbered) Press (CTRL/X) to display the system job environment prompt. Notify RT--11 that you want to summon the KEX1 editor by typing KEX1 in response to that prompt and pressing (RETURN): (Job?)( KEX1 (RET)) (KEX1>) Press (CTRL/W) to repaint your terminal screen. KEX1 displays the contents of MYFIL1.TXT. Press the (PF1) ( 7 ) keypad keys and issue the command QUIT: (Command:)(QUIT (ENTER)) KEX1 removes the file MYFIL1.TXT, does not save it, and displays its utility command (*) prompt. You could at that point create another file or open an existing file for editing on KEX1 by typing the file name. Instead, press (CTRL/B) to return to the background environment. (Aborting System Jobs\sysjob_abort_sec)

You probably do not want to abort (stop) a system job that you will require again unless you will also unload it to regain the system memory that job is using.

Because of the exercises in previous sections, you are currently running two system jobs: KEX and KEX1. Issue the following command to verify that: (.)(SHOW JOBS (RET))

RT--11 displays data about the jobs that are currently loaded. (The RESORC utility is loaded because the command SHOW JOBS calls the RESORC utility.) Most important for this exercise, notice the State of jobs KEX and KEX1 is Run.

You can abort a system job by using either of two methods: (unnumbered) You can press (CTRL/C) at the utility input prompt (*) for the system job you want to abort. You commonly use this method if you are in the system job environment at the system job you want to abort. You can issue the ABORT command at the monitor prompt (.) and specify the system job you want to abort. You commonly use this procedure when you are in the background environment.

The following exercise aborts the two system jobs you are currently running. It illustrates both methods. (((CTRL/C) Method\bold))

The following procedure uses the (CTRL/C) method to abort the system job KEX1. You are currently in the background environment, so to illustrate the procedure, you must first summon KEX1 and then abort it. (numbered) Press (CTRL/X). In response to the system job environment prompt, type KEX1 and press (RETURN): (Job?)( KEX1 (RET))

You are now at the KEX1 command prompt, although it is not displayed. Press (CTRL/C) to abort KEX1.

RT--11 returns you to the background environment and displays the background environment prompt (B>). If your terminal beeps when you press (CTRL/C), that indicates a file is currently open in that editor. You should then press (CTRL/W) to repaint your terminal screen with that file, examine the file, exit or quit that file, and then again press (CTRL/C). ((ABORT Command Method\bold))

The following procedure uses the ABORT command to abort the system job KEX. (numbered) Issue the following command to abort the system job KEX by using the ABORT command: (.)(ABORT KEX (RET)) Optionally, you can then issue the SHOW JOBS command to verify that you aborted KEX. If you successfully aborted KEX, the State of the job KEX is Done. If a file was currently open on KEX, KEX would refuse the abort, and the State of the job KEX would still be Run.

Aborting a job by using either method removes the job from your computer's extended memory. If you now issue the command SHOW MEMORY, you will see that KEX and KEX1 no longer reside in extended memory, thereby freeing over 50K words of that memory. However, portions of KEX and KEX1 still reside in low memory. You must unload them to free that memory. That procedure is described in the next section. (Unloading System Jobs\sysjob_unload_sec)

You cannot unload a job or its assigned device handlers unless the job exits or you abort it. Once a system job exits or you have aborted it, you should unload it (and any device handlers assigned to only it) to free the low memory allocated to that job. Use the UNLOAD command to remove a job from the computer's low memory.

(sysjob_bef_sec) states that jobs are loaded in memory in the order that you run them. If the job you are unloading is the lowest job in your computer's memory, unloading that job (and any device handlers assigned it) consolidates that job's memory with the rest of the computer's free low memory. If the job you are unloading is not the lowest in your computer's memory, you must also abort and unload any jobs below it to consolidate free low memory. Once you have consolidated computer memory in that manner, you can restart any jobs you require.

You should currently have the jobs KEX and KEX1 loaded in low memory. To verify that, issue the following command: (.)(SHOW MEMORY (RET))

To demonstrate memory fragmentation, issue the following command that unloads the job KEX: (.)(UNLOAD KEX (RET))

Issue again the following command to display memory: (.)(SHOW MEMORY (RET))

Note in the display above the job KEX1, which is still loaded in memory, you have a fragmented memory area in which KEX resided. The amount of fragmented memory is shown in decimal notation. That memory is not consolidated with the main free low memory area (..BG..). Your computer can use that fragmented memory only to contain something that fits in that space. To consolidate the memory you freed by unloading KEX, you must unload KEX1: (.)(UNLOAD KEX1 (RET))

Issue again the following command to display memory: (.)(SHOW MEMORY (RET))

Note in that display that the memory occupied by KEX and KEX1 is now consolidated with your computer's main free memory.

The KEX editor does not have any device handlers assigned to it, so there are none to unload. Other system jobs, such as VTCOM and SPOOL, do have device handlers assigned to them when you start them. When you abort and unload those jobs, you should probably then unload those device handlers. That procedure is discussed in the following section. (Aborting and Unloading System Jobs Using Indirect Files\sysjob_nind_sec)

In (sysjob_ind_sec), you learned a method of starting system jobs using an indirect command file. This section discusses creating indirect command files that, when run, abort and unload a system job.

Consider the following points when creating such indirect command files: (unnumbered) Some system jobs are simple enough to directly abort and unload. You do not require an indirect command file for them.

(sysjob_abort_sec) and (sysjob_unload_sec) showed that system jobs started from a single command can be aborted and unloaded using single commands. Such system jobs do not own device handlers; you do not assign specific device handlers to those jobs. KEX is such a system job. Some system jobs require you to perform operations at the keyboard to abort them. VTCOM is such a system job. You cannot abort VTCOM from an indirect command file. You should only abort a system job by using an indirect command file when that system job is in the state where it would accept a direct command to abort.

(sysjob_abort_sec) stated that you should only abort a system job when that job is idle. If the system job is performing an operation, you should end that operation before you can abort that job. For example, you cannot abort the KEX editor when there is a file open on that editor. You should not abort the SPOOL utility when there is output in the SPOOL queue. You cannot unload a device handler that is assigned to a system job without first aborting that system job.

The commands necessary to abort and unload a system job are particular to that system job. However, some general rules and order of procedure apply in all cases. Use the following as a general guide for creating indirect command files that abort and unload system jobs: (numbered) Examine the commands you used to start the system job. Those commands will be located in either an indirect command file you created specifically to start that job or in your start-up command file. It is helpful to have a listing; print the file containing the commands. Issue the SHOW command. Any handler listed in the SHOW command display that is followed by the text Loaded=system job is coupled to the system job indicated by that text.

Once you have made idle, aborted, and unloaded that system job, you can unload that handler without affecting any other job on your system. The only job on your system using that handler is the indicated system job. Determine if there is a SET command condition that will idle the system job. If there is such a condition, include that command condition first in your file. For example, you can make the SPOOL utility idle by issuing the following command: SET SP KILL

Although it is not technically a system job but rather a pseudohandler, you can treat the single-line (SL) command editor as a system job in terms of aborting and unloading it from a file. If you are creating such a file, the command to abort and unload SL is: SET SL OFF Once you have made the system job idle, abort it, using the appropriate command. For example, you abort SPOOL by issuing: SET SP EXIT

On the other hand, the editor is aborted by issuing the ABORT command, while VTCOM is aborted by explicitly exiting from the job by pressing (CTRL/P) and issuing the EXIT command. Once you have aborted the system job, unload it by using the UNLOAD command. Once you have unloaded the system job, unload any device handlers that were specifically assigned to that job. You can optionally include the command SHOW MEMORY at the end of your file to check that the system job is unloaded. You can also check that your computer memory is not fragmented; that you can use the memory retrieved by unloading the job and handler.

Any jobs or handlers loaded in memory below the system job you unloaded must be unloaded to consolidate the free low memory on your system.

The following example indirect command file, LOOPS.COM, makes idle, aborts, and unloads the SPOOL utility. It illustrates the information discussed above. You can use the following procedure to create LOOPS.COM: (numbered) Issue the following command: (.)(EDIT/CREATE LOOPS.COM (RET)) Enter the following command lines (or ones you prefer) in that file: ! LOOPS.COM, created dd-mmm-yy, edited dd-mmm-yy ! Closes down the print spooler ! SET SP KILL SET SP EXIT UNLOAD SPOOL UNLOAD SP UNLOAD LS DEASSIGN LP DEASSIGN LP0 SHOW SHOW MEMORY Exit from that file by issuing the following commands: ((PF1)( 7 )) (Command:)(EXIT (ENTER)) You can then run the indirect command file, LOOPS.COM, which idles, aborts, and unloads SPOOL, by issuing the following command: (.)($@LOOPS (RET))

You will find it helpful to create indirect command files which start each system job that you use an indirect command file to abort and unload. Creating such a file lets you restart a system job without having to issue a lot of commands or reboot your system. This is true even if you typically start a system job from your start-up command file. (Chapter Summary)

The following summary is the order of operations for using system jobs. (Starting system jobs)

All device handlers used by a system job must reside on the system (SY) device and be loaded in memory.

System jobs can be started three ways: (unnumbered) At system boot (start-up command file) From an indirect file ($@filespec.COM) From the keyboard (SRUN command) (Calling system jobs)

Once a system job is started, it must be called by name from the system job environment prompt, (Job?). You summon the system job environment prompt by pressing (CTRL/X). (Aborting system jobs)

When a system job is no longer required, you can abort it. How a system job is aborted is determined by a number of factors described in the chapter, but, in general there are three ways: (unnumbered) Press (CTRL/C) at the CSI prompt. Issue the ABORT command and specify the job name. Call the job and issue the EXIT command:

SET SP EXIT to abort SPOOL

(CTRL/P) and EXIT to abort VTCOM (Unloading system jobs)

Aborting a system job unloads the portion of the job that resides in extended memory. It does not, however, unload the low-memory portion. You must explicitly unload the job, using the UNLOAD command, to reclaim use of the low memory. So as to not fragment memory, you should unload in (last loaded/first unloaded) order ("unwinding").