![]() |
Software > OpenVMS Systems > Documentation > 731final > 5841 ![]() HP OpenVMS Systems Documentation |
![]() |
OpenVMS Programming Concepts Manual
4.5.1.2 The Delete Sub-CommandThe format for the Delete sub-command is as follows:
The Delete sub-command deletes the scheduling class from the class scheduler database file, and all processes that are members of this scheduling class are no longer class scheduled. 4.5.1.3 The Modify Sub-CommandThe format for the Modify sub-command is as follows:
The Modify sub-command changes the characteristics of a scheduling class. The qualifiers are the same qualifiers as for the add sub-command. To remove a time restriction, specify a zero (0) for the time percentage associated with a particular range of hours. To remove a name or uic value, you must specify a minus sign in front of each name or value. 4.5.1.4 The Show Sub-CommandThe format for the Show sub-command is as follows:
Table 4-9 shows the qualifiers and their meanings for this SYSMAN command.
4.5.1.5 The Suspend Sub-CommandThe format for the Suspend sub-command is as follows:
The Suspend sub-command suspends the specified scheduling class. All processes that are part of this scheduling class remain as part of this scheduling class but are granted unlimited CPU time. 4.5.1.6 The Resume Sub-CommandThe format of the Resume sub-command is as follows:
The Resume sub-command complements the suspend command. You use this command to resume a scheduling class that is currently suspended. 4.5.2 The Class Scheduler DatabaseThe class scheduler database is a permanent database that allows OpenVMS to class schedule processes automatically after a system has been booted and rebooted. This database resides on the system disk in SYS$SYSTEM: VMS$CLASS_SCHEDULE.DATA. SYSMAN creates this file as an RMS indexed file when the first scheduling class is created by the SYSMAN command, class_schedule add. 4.5.2.1 The Class Scheduler Database and Process CreationBy using a permanent class scheduler, a process is placed into a scheduling class, if appropriate, at process creation time. When a new process is created, it needs to be determined whether this process belongs to a scheduling class. Since to determine this relies upon data in the SYSUAF file, and the Loginout image already has the process' information from this file, Loginout class schedules the process if it determines that the process belongs to a scheduling class. There are two other types of processes to consider during process creation: subprocess and detached process. A subprocess becomes part of the same scheduling class as the parent process, even though it may not match the class's criteria. That is, its user and account name and/or UIC may not be part of the class's record. A detached process only joins a scheduling class if it executes the Loginout image (Loginout.exe) during process creation. Though a process can join a scheduling class at process creation time, you can change or modify its scheduling class during runtime with the SET PROCESS/SCHEDULING_CLASS command. 4.5.3 Determining If a Process Is Class ScheduledYou can determine whether a process is class scheduled by the following:
The DCL command, SHOW SYSTEM, with the qualifier, /CLASS = "name", displays processes that belong to a specific scheduling class, or if no name is specified, it displays all class scheduled processes and the name of their scheduling class. The SHOW SYSTEM/FULL command shows the scheduling class name of all processes that are class scheduled. For more information about the DCL command SHOW SYSTEM, see OpenVMS DCL Dictionary: N--Z. The SYS$GETJPI system service item code, JPI$_CLASS_NAME, returns the name of the scheduling class, as a character string, that this process belongs to. If the process is not class scheduled, then a return length of zero (0) is returned to the caller. For more information about the SYS$GETJPI system service, see the OpenVMS System Services Reference Manual: A--GETUAI. When a new user is added to the SYSUAF file, or when a user's record is modified, Authorize searches the class scheduler database file to determine if this user is a member of a scheduling class. If it is, then Authorize displays the following message: UAF-I-SCHEDCLASS, which indicates that the user is a member of a scheduling class. 4.5.4 The SYS$SCHED System ServiceThe SYS$SCHED system service allows you to create a temporary class scheduling database. The processes are class-scheduled by PID, after the process has been created. The SYSMAN interface creates a separate and permanent class scheduling database that schedules you at process creation time. A process cannot belong to both databases, the SYS$SCHED and SYSMAN database. Therefore, the SYS$SCHED system service checks to see if the process to be inserted into a scheduling class is already class scheduled before it attempts to place the specified process into a scheduling class. If it is already class scheduled, then the error message, SS$_INSCHEDCLASS, is returned from SYS$SCHED. For more information about the SYS$SCHED system service, see the OpenVMS System Services Reference Manual: GETUTC--Z. 4.6 Changing Process NameUse the system service SYS$SETPRN to change the name of your process. SYS$SETPRN can be used only on the calling process. Changing process names might be useful when a lengthy image is being executed. You can change names at significant points in the program; then monitor program execution through the change in process names. You can obtain a process name by calling a SYS$GETJPI routine from within a controlling process, either by pressing the Ctrl/T key sequence if the image is currently executing in your process, or by entering the DCL command SHOW SYSTEM if the program is executing in a detached process. The following program segment calculates the tax status for a number of households, sorts the households according to tax status, and writes the results to a report file. Because this is a time-consuming process, the program changes the process name at major points so that progress can be monitored.
4.7 Accessing Another Process's ContextOn OpenVMS VAX systems, a system programmer must sometimes develop code that performs various actions (such as performance monitoring) on behalf of a given process, executing in that process's context. To do so, a programmer typically creates a routine consisting of position-independent code and data, allocates sufficient space in nonpaged pool, and copies the routine to it. On OpenVMS VAX systems, such a routine can execute correctly no matter where it is loaded into memory. On OpenVMS Alpha systems, the practice of moving code in memory is more difficult and complex. It is not enough to simply copy code from one memory location to another. On OpenVMS Alpha systems, you must relocate both the routine and its linkage section, being careful to maintain the relative distance between them, and then apply all appropriate fixups to the linkage section. The OpenVMS Alpha system provides two mechanisms to enable one process to access the context of another:
4.7.1 Reading and Writing in the Address Space of Another Process (Alpha Only)EXE$READ_PROCESS and EXE$WRITE_PROCESS are OpenVMS Alpha system routines in nonpaged system space. EXE$READ_PROCESS reads data from a target process's address space or registers and writes it to a buffer in the local process's address space. EXE$WRITE_PROCESS obtains data from a local process's address space and transfers it to the target process's context. Both routines must be called from kernel mode at IPL 0. One of the arguments to these procedures specifies whether or not the procedure is to access memory and registers in the target process. Another argument specifies the memory address or register number. The contents of these arguments are symbolic names (beginning with the prefix EACB$) that are defined by the $PROCESS_READ_WRITE macro in SYS$LIBRARY:LIB.MLB. (They are also defined in LIB.REQ for BLISS programmers.) 4.7.1.1 EXE$READ_PROCESS and EXE$WRITE_PROCESSThe following are descriptions of the callable interfaces to EXE$READ_PROCESS and EXE$WRITE_PROCESS. EXE$READ_PROCESS
Reads data from a target process's address space or registers and writes it to a buffer in the local process's address space.Module PROC_READ_WRITE Formatstatus = EXE$READ_PROCESS (ipid, buffer_size, target_address, local_address, target_address_type, ast_counter_address) Arguments
RETURNS
Return ValuesContext The caller of EXE$READ_PROCESS must be executing in kernel mode at IPL 0. Kernel mode ASTs must be enabled. DescriptionEXE$READ_PROCESS reads data from a target process's address space and writes it to a buffer in the local process's address space. EXE$WRITE_PROCESS
Reads data from the local process's address space and writes it either to a target process's registers or a buffer in a target process's address space.Module PROC_READ_WRITE Formatstatus = EXE$WRITE_PROCESS (ipid, buffer_size, local_address, target_address, target_address_type, ast_counter_address) Arguments
RETURNS
Return ValuesContext The caller of EXE$WRITE_PROCESS must be executing in kernel mode at IPL 0. Kernel mode ASTs must be enabled. DescriptionEXE$WRITE_PROCESS reads data from the local process's address space and writes it to a target process's registers or a buffer in a target process's address space.
|