• Aucun résultat trouvé

Background Job

Dans le document RT–11 System Internals Manual (Page 30-35)

Thebackground jobin the single-job and multi-job systems is essentially identical for the purpose of this discussion. Figure 1–4 shows the general structure of an unmapped background job, as well as its relative location in memory. Chapter 3 describes and illustrates background job loading in a mapped system.

There are five ways in which RT–11 can load a background job: RUN, R, VRUN, V, and .CHAIN. They are described in the following sections.

1.1.4.1 RUN Command

One way to load a job is to use theRUNcommand. The RUN command is the same as the GET and START commands combined. First, if the SAV file is not on the system device, RUN (or GET) loads the handler for the proper device. When this occurs, KMON and the USR, which normally occupy the space above the background job and below RMON, relocate themselves, if necessary. For more information on the USR and KMON, see later sections of this chapter. For information on virtual and completely virtual background job loading, see Chapter 3.

The space available for background job loading consists of the background job area, the space occupied by KMON, and (in unmapped systems) the space occupied by the USR (unless the USR is set to NOSWAP). In mapped systems, the USR is always resident. If the job needs more space, an error message prints and then control returns to KMON.

With mapped systems, you can often run a background job in the completely virtual environment when there is insufficient memory to run it otherwise. See Chapter 3 for information about the SET RUN VBGEXE command, and other information about the completely virtual environment.

Figure 1–3: Interrupt Vector Area

Once the job passes the size tests, RUN loads from the file those memory locations (0 through 476) that are not protected. KMON reads block 0 of the .SAV file into an internal USR buffer. It extracts information from locations 40–64 and 360–377 (the CCB bitmap, described further in this section). Using the protection bitmap (called $LOWMA), which resides in RMON, KMON checks each word in block 0 of the file. It does not load locations that are protected, such as location 54 and the device interrupt vectors. It loads unprotected locations into memory from the USR buffer. Next, KMON sets $USRTO (location 50) to the top of the user program.

By default, the RUN command causes RT–11 to load main memory locations 500 through 776 with a copy of the command string following RUN ddn:filname. This enables a program to make use of the command string that was used to invoke it.

If required, RT–11 can load locations 500 through 776 from the save image of the program rather than with a copy of the command string. To do this with the RUN

Figure 1–4: Background Job

command, you must set CHAIN$ (bit 8) in $JSW (offset 40) in block 0 of the save image. CHAIN$ must be set in the file, not in memory, after the program is loaded.

For example, the command:

RUN SY:FOO INPUT OUTPUT

returns the string INPUT OUTPUT in locations 500 through 776 if CHAIN$ in

$JSW in block 0 of SY:FOO.SAV is clear. If CHAIN$ is set, RT–11 loads locations 500 through 776 from the save image.

To load locations 1000 and up, RUN examines thecore control block, called the CCB, which starts at location 360 in the job file and goes through location 377. The CCB is restricted for use by the system. The Linker stores the program memory usage bits in these eight words, which are called a bitmap. Each bit represents one 256-word block of memory and is set if the program occupies any part of that block of memory.

Bit 7 of byte 360 corresponds to locations 0 through 777; bit 6 of byte 360 corresponds to locations 1000 through 1777, and so on. The monitor uses this information when it loads the program. If KMON is in memory space that the program needs to use, KMON puts the block of the .SAV file into a USR buffer and then moves it to the file SWAP.SYS.

Finally, when it is time to begin execution of the program, KMON transfers control to RMON. RMON reads the parts of the program, if any, that are stored in SWAP.SYS into memory, where they overlay KMON and possibly the USR. The monitor keeps track of the fact that KMON (and perhaps the USR) are swapped out, and execution of the program begins. Figure 1–5 summarizes how the RUN command loads a job image into memory.

When the program terminates, RMON reads KMON and the USR back into memory from the monitor .SYS file. The memory area up to the bottom of KMON contains the background job image. If the job overlaid KMON and SET EXIT SWAP is in effect, the remainder of the job image is first written out to SWAP.SYS. This procedure allows the EXAMINE and DEPOSIT commands to operate on the job image on disk, even though KMON has written over the job’s locations in memory, and the RESTART command can restart the program. If SET EXIT NOSWAP is in effect, program termination is faster, but you cannot use the EXAMINE, DEPOSIT, or RESTART commands.

1.1.4.2 R Command

The R command is identical to the RUN command except the default location for the utility being run with the R command is SY.

1.1.4.3 VRUN Command

The VRUN command runs a job in the completely virtual environment under mapped monitors. The default location for the utility being run is DK. The completely virtual environment is described in Chapter 3.

1.1.4.4 V Command

The V commandis identical to the VRUN command except the default location for the utility being run with the V command is SY.

1.1.4.5 .CHAIN Request

The fifth way to load a job is to chain to it from another job. The first job issues the .CHAIN programmed request to do this. The second job can use information in memory locations 500 through 776 that was placed there by the first job.

Consequently, the only difference between loading a job with the RUN command and starting a job by chaining to it is that chaining does not load memory locations 500 through 776 from the second file unless you set the chain bit in the $JSW of the second file at assembly time.

Figure 1–5: RUN Command

Note that chaining to a FORTRAN job does not preserve channel information from the previous job. This is because FORTRAN itself closes the channels and discards the impure area.

Dans le document RT–11 System Internals Manual (Page 30-35)