https://wiki.vmssoftware.com/api.php?action=feedcontributions&user=Madsweeney&feedformat=atomVSI OpenVMS Wiki - User contributions [en]2024-03-29T14:29:50ZUser contributionsMediaWiki 1.31.0https://wiki.vmssoftware.com/index.php?title=F$GETQUI_Context&diff=2057F$GETQUI Context2020-06-18T23:03:09Z<p>Madsweeney: </p>
<hr />
<div>A queue manager will receive requests simultaneously from many processes and from many different threads within a process. The queue manager must maintain context for all of the requesting threads on the cluster. A data structure called the GETQUI_CONTEXT is passed back and forth between a queue manager and a client to manage communication. The context maintains a "pointer" to tell a queue manager where to retrieve information for the next F$GETQUI call. Context is an opaque structure and is not user visible.<br />
<br />
Processes have one built-in queue context called the Default Context, context number 0 (zero). Whenever the context is omitted from a F$GETQUI call, context 0 is used. DCL commands that retrieve queue system information like SHOW QUEUE and SHOW ENTRY contain many sys$getqui() system services calls using the default context. Remembering queue commands use the default context is important for DCL programmers because it can cause unexpected results from F$GETQUI calls using the default context. <br />
<br />
An example may explain the concept of the context best. <br />
<br />
Suppose your system or cluster has 3 queues, AQ, GQ and ZQ. The SHOW QUEUE command below makes 4 sys$getqui() calls to retrieve the queue information to output on your device. The figure below illustrates the contents of the GETQUI_CONTEXT data structure during the four sys$getqui() calls. The default context is used the four sys$getqui() calls. The text to the left of the bars is the DCL input and output. To the right of the bar is the value of the GETQUI_CONTEXT value followed by a short description of the processing of the sys$getqui() call.<br />
<pre><br />
<br />
SYSTEM IA10> show queue/summ %Q |GETQUI_CONTEXT Description<br />
| <null> client process sends null in getqui context<br />
Batch queue AQ, idle, on IA10:: |----------------- <br />
| AQ queue manager looks up the first queue in it's database<br />
Job summary: queue is empty | queue manager returns AQ to client in getqui_context<br />
|----------------- <br />
| client process sends AQ to the queue manager in getqui_context<br />
Batch queue GQ, idle, on IA10:: | queue manager uses client passed AQ to lookup the next queue in the database <br />
| GQ queue manager finds GQ, updates the getqui_context with GQ <br />
Job summary: queue is empty | queue manager returns GQ to client in getqui_context<br />
|-----------------<br />
Batch queue ZQ, idle, on IA10:: | client process sends GQ to the queue manager in getqui_context<br />
| ZQ queue manager uses client passed GQ to lookup the next queue in the database <br />
Job summary: queue is empty | queue manager finds ZQ, updates the context with ZQ<br />
| queue manager returns ZQ to client in getqui_context<br />
|-----------------<br />
| client process sends ZQ to the queue manager in getqui_context<br />
| queue manager looks up the next queue in the database<br />
| No queue found after ZQ<br />
| Queue manager returns JBC-Q-NOMOREQUE<br />
</pre><br />
<br />
When querying the queue system for information, the sys$getqui call message to the queue manager<br />
<br />
<br />
<br />
* DISPLAY_CHARACTERISTIC <br />
* DISPLAY_ENTRY<br />
* DISPLAY_FILE<br />
* DISPLAY_FORM<br />
* DISPLAY_JOB<br />
* DISPLAY_MANAGER<br />
* DISPLAY_QUEUE<br />
<br />
=Establishing a Context=<br />
<br />
To establish a queue context, make a wildcard call to F$GETQUI using a DISPLAY_QUEUE function, for example:<br />
<br />
<nowiki><br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*") <br />
</nowiki><br />
<br />
Calls to F$GETQUI between this one and the next similar call will use the context of this queue. For example:<br />
<br />
<nowiki><br />
<br />
$ SHOW QUEUE<br />
<br />
Batch queue QUEUE$ONE, idle, on SMAN43::<br />
<br />
Generic printer queue SYS$PRINT<br />
<br />
Entry Jobname Username Blocks Status<br />
----- ------- -------- ------ ------<br />
70 TEST1 JDOE 1 Pending<br />
(32 intervening jobs containing 65 blocks)<br />
71 TEST2 JDOE 3 Pending<br />
<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*") <br />
$ SHOW SYM QNAME<br />
QNAME == "QUEUE$ONE"<br />
$ NAME_ONE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_ONE<br />
QNAME == ""<br />
$ NAME_TWO = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_TWO<br />
QNAME == ""<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ NAME_FOUR = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_FOUR<br />
QNAME == "TEST2"<br />
</nowiki><br />
<br />
SHOW QUEUE reveals that we have two queues, QUEUE$ONE and SYS$PRINT. QUEUE_ONE has no jobs in it and QUEUE$PRINT has two jobs pending.<br />
The first call to F$GETQUI establishes queue context of the first queue - QUEUE$ONE. All subsequent calls to F$GETQUI until the context is changed obtain information within that context, i.e. on that queue. There are two calls to DISPLAY_JOB, both return an empty string, because there are no jobs in that queue and therefore their names are empty strings.<br />
The second call to F$GETQUI advances queue context, so all subsequent calls operate within the context of SYS$PRINT rather that QUEUE$ONE. And since SYS$PRINT has jobs, we start seeing actual names for these jobs. Note that DISPLAY_JOB establishes job context; if we wanted to display additional information for job TEST1 - say, its entry number - that call would have to include the "FREEZE_CONTEXT" flag at the end, otherwise the job context would advance and you would get the entry number of TEST2 (71) rather than TEST1 (70):<br />
<br />
<nowiki><br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ ENTRY = F$GETQUI("DISPLAY_JOB","ENTRY_NUMBER",,"ALL_JOBS")<br />
$ SHOW SYM ENTRY<br />
B = 71 Hex = 00000046 Octal = 00000000106<br />
</nowiki><br />
<br />
=Preserving the Context=<br />
<br />
To preserve context, use the "FREEZE_CONTEXT" flag. It is available for all functions that establish context. Here is how it can be used to preserve job context:<br />
<br />
<nowiki><br />
<br />
$ SHOW QUEUE<br />
<br />
Batch queue QUEUE$ONE, idle, on SMAN43::<br />
<br />
Generic printer queue SYS$PRINT<br />
<br />
Entry Jobname Username Blocks Status<br />
----- ------- -------- ------ ------<br />
70 TEST1 JDOE 1 Pending<br />
(32 intervening jobs containing 65 blocks)<br />
71 TEST2 JDOE 3 Pending<br />
<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ ENTRY = F$GETQUI("DISPLAY_JOB","ENTRY_NUMBER",,"FREEZE_CONTEXT")<br />
$ SHOW SYM ENTRY<br />
B = 70 Hex = 00000046 Octal = 00000000106<br />
</nowiki><br />
<br />
In the example above, NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS") is used to establish job context of job TEST1 with entry number 70. The subsequent call uses the "FREEZE_CONTEXT" flag, so the context remains that of TEST1 and its entry number (70) is displayed. Had that flag not been used, the job context would advance and the entry number of the next job (TEST2; 72) would be displayed - that is illustrated at the end of the [[F$GETQUI Context#Establishing a Context|section above]].<br />
<br />
=Cancelling a Context=<br />
A context can be cancelled with a call to F$GETQUI CANCEL_OPERATION function:<br />
<br />
<nowiki><br />
a = f$getqui("CANCEL_OPERATION")<br />
</nowiki><br />
<br />
The symbol does not matter. It is recommeded to do this every time before establishing a new context to make sure that no contexts that may have been established by the previous command procedures interfere with it.<br />
<br />
[[Category:Lexical Functions]]</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=F$GETQUI_Context&diff=2056F$GETQUI Context2020-06-18T21:33:13Z<p>Madsweeney: </p>
<hr />
<div>A queue manager will receive requests simultaneously from many processes and from many different threads within a process. The queue manager must maintain context for all of the requesting threads on the cluster. A data structure called the GETQUI_CONTEXT is passed back and forth between a queue manager and a client to manage communication. The context maintains a "pointer" to tell a queue manager where to retrieve information for the next F$GETQUI call. Context is an opaque structure and is not user visible.<br />
<br />
Processes have one built-in queue context called the Default Context, context number 0 (zero). Whenever the context is omitted from a F$GETQUI call, context 0 is used. DCL commands that retrieve queue system information like SHOW QUEUE and SHOW ENTRY contain many sys$getqui() system services calls using the default context. Remembering queue commands use the default context is important for DCL programmers because it can cause unexpected results from F$GETQUI calls using the default context. <br />
<br />
An example may explain the concept of the context best. <br />
<br />
Suppose your system or cluster has 3 queues, AQ, GQ and ZQ. The SHOW QUEUE command below makes 4 sys$getqui() calls to retrieve the queue information to output on your device. The figure below illustrates the contents of the GETQUI_CONTEXT data structure during the four sys$getqui() calls. The default context is used the four sys$getqui() calls. The text to the left of the bars is the DCL input and output. To the right of the bar is the value of the GETQUI_CONTEXT value followed by a short description of the processing of the sys$getqui() call.<br />
<pre><br />
<br />
SYSTEM IA10> show queue/summ %Q |GETQUI_CONTEXT Description<br />
| <null> client process sends null in getqui context<br />
Batch queue AQ, idle, on IA10:: |----------------- <br />
| AQ queue manager looks up the first queue in it's database<br />
Job summary: queue is empty | queue manager returns AQ to client in getqui_context<br />
|----------------- <br />
| client process sends AQ to the queue manager in getqui_context<br />
Batch queue GQ, idle, on IA10:: | queue manager uses client passed AQ to lookup the next queue in the database <br />
| GQ queue manager finds GQ, updates the getqui_context with GQ <br />
Job summary: queue is empty | queue manager returns GQ to client in getqui_context<br />
|-----------------<br />
Batch queue ZQ, idle, on IA10:: | client process sends GQ to the queue manager in getqui_context<br />
| ZQ queue manager uses client passed GQ to lookup the next queue in the database <br />
Job summary: queue is empty | queue manager finds ZQ, updates the context with GQ<br />
| queue manager returns ZQ to client in getqui_context<br />
|-----------------<br />
| client process sends ZQ to the queue manager in getqui_context<br />
| queue manager looks up the next queue in the database<br />
| No queue found after ZQ<br />
| Queue manager returns JBC-Q-NOMOREQUE<br />
</pre><br />
<br />
When querying the queue system for information, the sys$getqui call message to the queue manager<br />
<br />
<br />
<br />
* DISPLAY_CHARACTERISTIC <br />
* DISPLAY_ENTRY<br />
* DISPLAY_FILE<br />
* DISPLAY_FORM<br />
* DISPLAY_JOB<br />
* DISPLAY_MANAGER<br />
* DISPLAY_QUEUE<br />
<br />
=Establishing a Context=<br />
<br />
To establish a queue context, make a wildcard call to F$GETQUI using a DISPLAY_QUEUE function, for example:<br />
<br />
<nowiki><br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*") <br />
</nowiki><br />
<br />
Calls to F$GETQUI between this one and the next similar call will use the context of this queue. For example:<br />
<br />
<nowiki><br />
<br />
$ SHOW QUEUE<br />
<br />
Batch queue QUEUE$ONE, idle, on SMAN43::<br />
<br />
Generic printer queue SYS$PRINT<br />
<br />
Entry Jobname Username Blocks Status<br />
----- ------- -------- ------ ------<br />
70 TEST1 JDOE 1 Pending<br />
(32 intervening jobs containing 65 blocks)<br />
71 TEST2 JDOE 3 Pending<br />
<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*") <br />
$ SHOW SYM QNAME<br />
QNAME == "QUEUE$ONE"<br />
$ NAME_ONE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_ONE<br />
QNAME == ""<br />
$ NAME_TWO = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_TWO<br />
QNAME == ""<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ NAME_FOUR = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_FOUR<br />
QNAME == "TEST2"<br />
</nowiki><br />
<br />
SHOW QUEUE reveals that we have two queues, QUEUE$ONE and SYS$PRINT. QUEUE_ONE has no jobs in it and QUEUE$PRINT has two jobs pending.<br />
The first call to F$GETQUI establishes queue context of the first queue - QUEUE$ONE. All subsequent calls to F$GETQUI until the context is changed obtain information within that context, i.e. on that queue. There are two calls to DISPLAY_JOB, both return an empty string, because there are no jobs in that queue and therefore their names are empty strings.<br />
The second call to F$GETQUI advances queue context, so all subsequent calls operate within the context of SYS$PRINT rather that QUEUE$ONE. And since SYS$PRINT has jobs, we start seeing actual names for these jobs. Note that DISPLAY_JOB establishes job context; if we wanted to display additional information for job TEST1 - say, its entry number - that call would have to include the "FREEZE_CONTEXT" flag at the end, otherwise the job context would advance and you would get the entry number of TEST2 (71) rather than TEST1 (70):<br />
<br />
<nowiki><br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ ENTRY = F$GETQUI("DISPLAY_JOB","ENTRY_NUMBER",,"ALL_JOBS")<br />
$ SHOW SYM ENTRY<br />
B = 71 Hex = 00000046 Octal = 00000000106<br />
</nowiki><br />
<br />
=Preserving the Context=<br />
<br />
To preserve context, use the "FREEZE_CONTEXT" flag. It is available for all functions that establish context. Here is how it can be used to preserve job context:<br />
<br />
<nowiki><br />
<br />
$ SHOW QUEUE<br />
<br />
Batch queue QUEUE$ONE, idle, on SMAN43::<br />
<br />
Generic printer queue SYS$PRINT<br />
<br />
Entry Jobname Username Blocks Status<br />
----- ------- -------- ------ ------<br />
70 TEST1 JDOE 1 Pending<br />
(32 intervening jobs containing 65 blocks)<br />
71 TEST2 JDOE 3 Pending<br />
<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ ENTRY = F$GETQUI("DISPLAY_JOB","ENTRY_NUMBER",,"FREEZE_CONTEXT")<br />
$ SHOW SYM ENTRY<br />
B = 70 Hex = 00000046 Octal = 00000000106<br />
</nowiki><br />
<br />
In the example above, NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS") is used to establish job context of job TEST1 with entry number 70. The subsequent call uses the "FREEZE_CONTEXT" flag, so the context remains that of TEST1 and its entry number (70) is displayed. Had that flag not been used, the job context would advance and the entry number of the next job (TEST2; 72) would be displayed - that is illustrated at the end of the [[F$GETQUI Context#Establishing a Context|section above]].<br />
<br />
=Cancelling a Context=<br />
A context can be cancelled with a call to F$GETQUI CANCEL_OPERATION function:<br />
<br />
<nowiki><br />
a = f$getqui("CANCEL_OPERATION")<br />
</nowiki><br />
<br />
The symbol does not matter. It is recommeded to do this every time before establishing a new context to make sure that no contexts that may have been established by the previous command procedures interfere with it.<br />
<br />
[[Category:Lexical Functions]]</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=F$GETQUI_Context&diff=2055F$GETQUI Context2020-06-18T21:31:14Z<p>Madsweeney: </p>
<hr />
<div>A queue manager will receive requests simultaneously from many processes and from many different threads within a process. The queue manager must maintain context for all of the requesting threads on the cluster. A data structure called the GETQUI_CONTEXT is passed back and forth between a queue manager and a client to manage communication. The context maintains a "pointer" to tell a queue manager where to retrieve information for the next F$GETQUI call. Context is an opaque structure and is not user visible.<br />
<br />
Processes have one built-in queue context called the Default Context, context number 0 (zero). Whenever the context is omitted from a F$GETQUI call, context 0 is used. DCL commands that retrieve queue system information like SHOW QUEUE and SHOW ENTRY contain many sys$getqui() system services calls using the default context. Remembering queue commands use the default context is important for DCL programmers because it can cause unexpected results from F$GETQUI calls using the default context. <br />
<br />
An example may explain the concept of the context best. <br />
<br />
Suppose your system or cluster has 3 queues, AQ, GQ and ZQ. The SHOW QUEUE command below makes 4 sys$getqui() calls to retrieve the queue information to output on your device. The figure below illustrates the contents of the GETQUI_CONTEXT data structure during the four sys$getqui() calls. The default context is used the four sys$getqui() calls. The text to the left of the bars is the DCL input and output. To the right of the bar is the value of the GETQUI_CONTEXT value followed by a short description of the processing of the sys$getqui() call.<br />
<pre><br />
<br />
SYSTEM IA10> show queue/summ %Q |GETQUI_CONTEXT Description<br />
| <null> client process sends null in getqui context<br />
Batch queue AQ, idle, on IA10:: | <br />
| AQ queue manager looks up the first queue in it's database<br />
Job summary: queue is empty | queue manager returns AQ to client in getqui_context<br />
| <br />
| client process sends AQ to the queue manager in getqui_context<br />
Batch queue GQ, idle, on IA10:: | queue manager uses client passed AQ to lookup the next queue in the database <br />
| GQ queue manager finds GQ, updates the getqui_context with GQ <br />
Job summary: queue is empty | queue manager returns GQ to client in getqui_context<br />
|<br />
Batch queue ZQ, idle, on IA10:: | client process sends GQ to the queue manager in getqui_context<br />
| ZQ queue manager uses client passed GQ to lookup the next queue in the database <br />
Job summary: queue is empty | queue manager finds ZQ, updates the context with GQ<br />
| queue manager returns ZQ to client in getqui_context<br />
|<br />
| client process sends ZQ to the queue manager in getqui_context<br />
| queue manager looks up the next queue in the database<br />
| No queue found after ZQ<br />
| Queue manager returns JBC-Q-NOMOREQUE<br />
</pre><br />
<br />
When querying the queue system for information, the sys$getqui call message to the queue manager<br />
<br />
<br />
<br />
* DISPLAY_CHARACTERISTIC <br />
* DISPLAY_ENTRY<br />
* DISPLAY_FILE<br />
* DISPLAY_FORM<br />
* DISPLAY_JOB<br />
* DISPLAY_MANAGER<br />
* DISPLAY_QUEUE<br />
<br />
=Establishing a Context=<br />
<br />
To establish a queue context, make a wildcard call to F$GETQUI using a DISPLAY_QUEUE function, for example:<br />
<br />
<nowiki><br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*") <br />
</nowiki><br />
<br />
Calls to F$GETQUI between this one and the next similar call will use the context of this queue. For example:<br />
<br />
<nowiki><br />
<br />
$ SHOW QUEUE<br />
<br />
Batch queue QUEUE$ONE, idle, on SMAN43::<br />
<br />
Generic printer queue SYS$PRINT<br />
<br />
Entry Jobname Username Blocks Status<br />
----- ------- -------- ------ ------<br />
70 TEST1 JDOE 1 Pending<br />
(32 intervening jobs containing 65 blocks)<br />
71 TEST2 JDOE 3 Pending<br />
<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*") <br />
$ SHOW SYM QNAME<br />
QNAME == "QUEUE$ONE"<br />
$ NAME_ONE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_ONE<br />
QNAME == ""<br />
$ NAME_TWO = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_TWO<br />
QNAME == ""<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ NAME_FOUR = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_FOUR<br />
QNAME == "TEST2"<br />
</nowiki><br />
<br />
SHOW QUEUE reveals that we have two queues, QUEUE$ONE and SYS$PRINT. QUEUE_ONE has no jobs in it and QUEUE$PRINT has two jobs pending.<br />
The first call to F$GETQUI establishes queue context of the first queue - QUEUE$ONE. All subsequent calls to F$GETQUI until the context is changed obtain information within that context, i.e. on that queue. There are two calls to DISPLAY_JOB, both return an empty string, because there are no jobs in that queue and therefore their names are empty strings.<br />
The second call to F$GETQUI advances queue context, so all subsequent calls operate within the context of SYS$PRINT rather that QUEUE$ONE. And since SYS$PRINT has jobs, we start seeing actual names for these jobs. Note that DISPLAY_JOB establishes job context; if we wanted to display additional information for job TEST1 - say, its entry number - that call would have to include the "FREEZE_CONTEXT" flag at the end, otherwise the job context would advance and you would get the entry number of TEST2 (71) rather than TEST1 (70):<br />
<br />
<nowiki><br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ ENTRY = F$GETQUI("DISPLAY_JOB","ENTRY_NUMBER",,"ALL_JOBS")<br />
$ SHOW SYM ENTRY<br />
B = 71 Hex = 00000046 Octal = 00000000106<br />
</nowiki><br />
<br />
=Preserving the Context=<br />
<br />
To preserve context, use the "FREEZE_CONTEXT" flag. It is available for all functions that establish context. Here is how it can be used to preserve job context:<br />
<br />
<nowiki><br />
<br />
$ SHOW QUEUE<br />
<br />
Batch queue QUEUE$ONE, idle, on SMAN43::<br />
<br />
Generic printer queue SYS$PRINT<br />
<br />
Entry Jobname Username Blocks Status<br />
----- ------- -------- ------ ------<br />
70 TEST1 JDOE 1 Pending<br />
(32 intervening jobs containing 65 blocks)<br />
71 TEST2 JDOE 3 Pending<br />
<br />
$ QNAME = F$GETQUI("DISPLAY_QUEUE","QUEUE_NAME","*")<br />
$ SHOW SYM QNAME<br />
QNAME == "SYS$PRINT"<br />
$ NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_THREE<br />
QNAME == "TEST1"<br />
$ ENTRY = F$GETQUI("DISPLAY_JOB","ENTRY_NUMBER",,"FREEZE_CONTEXT")<br />
$ SHOW SYM ENTRY<br />
B = 70 Hex = 00000046 Octal = 00000000106<br />
</nowiki><br />
<br />
In the example above, NAME_THREE = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS") is used to establish job context of job TEST1 with entry number 70. The subsequent call uses the "FREEZE_CONTEXT" flag, so the context remains that of TEST1 and its entry number (70) is displayed. Had that flag not been used, the job context would advance and the entry number of the next job (TEST2; 72) would be displayed - that is illustrated at the end of the [[F$GETQUI Context#Establishing a Context|section above]].<br />
<br />
=Cancelling a Context=<br />
A context can be cancelled with a call to F$GETQUI CANCEL_OPERATION function:<br />
<br />
<nowiki><br />
a = f$getqui("CANCEL_OPERATION")<br />
</nowiki><br />
<br />
The symbol does not matter. It is recommeded to do this every time before establishing a new context to make sure that no contexts that may have been established by the previous command procedures interfere with it.<br />
<br />
[[Category:Lexical Functions]]</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=JOB_CONTROL&diff=2054JOB CONTROL2020-06-02T14:00:20Z<p>Madsweeney: </p>
<hr />
<div>The JOB_CONTROL process is the VMS Job controller process. <br />
<br />
Image Location: SYS$COMMON:[SYSEXE]JBC$JOB_CONTROL.EXE<br />
<br />
= Job controller process functional summary =<br />
The job controller performs multiple functions for VMS:<br />
<br />
#When a new terminal connection is detected the job controller creates a process attached to the terminal running LOGINOUT.EXE to initiate the login process.<br />
#Processes all VMS requests to write accounting data to the system accounting file.<br />
#Acts as the client communication to all VMS Queue Managers running in a cluster.<br />
##Creates batch processes and symbiont processes on the local system.<br />
##Notifies queue managers of the batch job and symbiont processes terminations on the local system.<br />
##Creates queue manager processes for queue managers that are prioritized to run on the local system.<br />
#Performs Standard Time and Daylight Saving Time clock adjustments, when the system parameter AUTO_DLIGHT_SAV is 1.<br />
#As a known, persistent process JOB_CONTROL is sometimes used by products and OS components as the target to queue ASTs to perform a desired actions. For example, the Availability Manager Product has an option to force crash a system. The Availability Manager RMDRIVER queues an AST to the JOB_CONTROL process to perform the crash.<br />
<br />
= Job controller communication =<br />
The job controller receives messages to perform operations through two methods:<br />
<br />
#Job Control permanent Mailbox MBA1:<br />
#IPC Queue Manangement Association Channel <association name to be supplied></div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=JOB_CONTROL&diff=2053JOB CONTROL2020-06-02T13:53:21Z<p>Madsweeney: /* Job controller process functional summary */</p>
<hr />
<div>The JOB_CONTROL process is the VMS Job controller process. <br />
<br />
Image Location: SYS$COMMON:[SYSEXE]JBC$JOB_CONTROL.EXE<br />
<br />
= Job controller process functional summary =<br />
The job controller performs multiple functions for VMS:<br />
<br />
#When a new terminal connection is detected the job controller creates a process attached to the terminal running LOGINOUT.EXE to initiate the login process.<br />
#Processes all VMS requests to write accounting data to the system accounting file.<br />
#Acts as the client communication to all VMS Queue Managers running in a cluster.<br />
##Creates batch processes and symbiont processes on the local system.<br />
##Notifies queue managers of the batch job and symbiont processes terminations on the local system.<br />
##Creates queue manager processes for queue managers that are prioritized to run on the local system.<br />
#Performs Standard Time and Daylight Saving Time clock adjustments, when the system parameter AUTO_DLIGHT_SAV is 1.<br />
#As a known, persistent process JOB_CONTROL is sometimes used by products and OS components as the target to queue ASTs to perform a desired actions. For example, the Availability Manager Product has an option to force crash a system. The Availability Manager RMDRIVER queues an AST to the JOB_CONTROL process to perform the crash.</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=Queue_manager&diff=2015Queue manager2020-05-20T17:56:00Z<p>Madsweeney: /* queue_manager.Qman$Journal */</p>
<hr />
<div>A '''queue manager''' is a section of an OpenVMS system that controls [[Queue|queue]] activity. One or more queue manager processes control queueing for all processes on a node or in an OpenVMS cluster environment. <br />
<br />
=Functions=<br />
When a user submits a [[Batch processing|batch]] or [[Printing|print]] job to a queue, the queue manager performs the following tasks:<br />
# Receives the user's queue request, including information about the type of job, the file name or names, the name of the queue, and any special options.<br />
# Stores and retrieves appropriate information from the queue database to print or execute the job.<br />
# Places the job in the appropriate queue to await its turn for processing:<br />
## Print jobs are sent to an independent process, called a symbiont, for formatting and are then sent to the printer for printing.<br />
## For batch jobs, the job controller creates a batch job process.<br />
<br />
User processes, symbionts, and job controllers on each node communicate directly with queue managers.<br />
In addition, the job controller [[JOB CONTROL]] works with the queue manager to perform the following queue management<br />
tasks:<br />
* Create and monitor [[Batch process|batch]], [[Symbiont|symbiont]], and queue manager processes<br />
* Restart the queue manager process on reboot<br />
* Handle failover of the queue manager in an OpenVMS Cluster environment<br />
<br />
==Queue Manager Failover==<br />
<br />
By default, in an OpenVMS Cluster environment, the queue manager tries to fail over to another node if the<br />
node on which the queue manager is running leaves the cluster. You can specify the order in which OpenVMS Cluster nodes claim the queue manager process. The '''/ON''' qualifier of the '''START/QUEUE/MANAGER''' command lets you specify a list of OpenVMS Cluster member nodes in the order that they should claim the queue manager process. It is recommended that you specify an asterisk (*) at the end of the node list to make sure that at least one node is always available to run the queue manager.<br />
<br />
=Obtaining Information about Queue Managers=<br />
To obtain information about one or more queue managers, enter the '''SHOW QUEUE/MANAGERS''' command (the '''/FULL''' qualifier is available).<br />
<br />
=Starting the Queue Manager=<br />
<br />
Before you can create queues, you must create a queue database by entering a command in the following<br />
format:<br />
'''START/QUEUE/MANAGER/NEW_VERSION[/ON=(node,...)] [dirspec]'''<br />
<br />
'''/NEW_VERSION''' specifies that new [[Queue database|queue database]] files are to be created.<br />
'''/ON''' allows you to customize failover of the queue manager.<br />
'''[dirspec]''' specifies the location of the [[Queue database|queue database]] files if you wish to create them in a location other than the defaut.<br />
<br />
You normally perform this task only once because when you enter the command, the system stores it, along with any qualifier or parameter you enter, in the queue database. The job controller automatically starts the queue manager during reboot unless you enter a '''STOP/QUEUE/MANAGER/CLUSTER''' command. For this reason, including '''START/QUEUE/MANAGER''' in your startup command procedure is unnecessary.<br />
<br />
=Stopping and Restarting the Queue Manager=<br />
<br />
<br />
Once created, a queue manager is stopped at shutdown and started at startup, so you never need to stop or restart it except when you need to modify the list of preferred nodes on which the queue manager can run on.<br />
<br />
==Stopping the Queue Manager==<br />
<br />
To shut down the queue manager on a standalone node or an OpenVMS Cluster node, enter the following command:<br />
'''$ STOP/QUEUE/MANAGER/CLUSTER'''<br />
<br />
The queue manager performs the following tasks:<br />
* Aborts all current jobs that cannot be restarted and requeues all current restartable jobs<br />
* Stops all execution queues<br />
* Disables autostart on all nodes<br />
* Closes all queue database files associated with that queue manager<br />
Once you enter '''STOP/QUEUE/MANAGER/CLUSTER''', the queue manager process remains stopped; requests to that queue manager are denied until you restart the queue manager by entering '''START/QUEUE/MANAGER'''. (Note that the queue system remains running as long as one or more queue managers are running.)<br />
OpenVMS Cluster transitions do not change the state of the queue manager. Newly available nodes do not attempt to start the queue manager (unless you enter '''START/QUEUE/MANAGER''').<br />
Use the /CLUSTER qualifier to stop a clusterwide queue manager. If you enter the obsolete command '''STOP/QUEUE/MANAGER''' (without the '''/CLUSTER''' qualifier), the command performs the same function as<br />
'''STOP/QUEUES/ON_NODE'''. (Use '''STOP/QUEUES/ON_NOD'''E to stop all queues on a single node without stopping the queue manager.)<br />
<br />
==Restarting the Queue Manager==<br />
<br />
The queue manager restarts automatically whenever you reboot the system. However, you might need to<br />
enter '''START/QUEUE/MANAGER''' for one of the following reasons:<br />
* If '''STOP/QUEUE/MANAGER/CLUSTER''' has been executed, enter START/QUEUE/MANAGER to restart the queue manager.<br />
* In an OpenVMS Cluster environment, enter '''START/QUEUE/MANAGER''' with the '''/ON''' qualifier to modify the list of preferred nodes on which the queue manager can run. <br />
* In an OpenVMS Cluster environment, enter START/QUEUE/MANAGER to ensure that the queue manager process executes on the most preferred, available node. If it does not, the queue manager will be moved to the most preferred, available node without interruption of service. If you are using the default node list (*), the queue manager will not be moved.<br />
=== Note System Parameter JOBCTLD ===<br />
* If the system parameter JOBCTLD low bit is set, the job controller will not start the queue manager. JOBCTLD is a dynamic system parameter.<br />
<br />
=Using Multiple Queue Managers=<br />
To work around CPU, disk space, or memory limitations, you can use multiple queue managers to distribute the batch and print work load among nodes as well as to distribute the database files among disks. For example, you might create separate queue managers for batch queues and print queues. Run the batch queue manager on one node and the print queue manager on a different node. You can also maintain queue and journal files on separate disks.<br />
<br />
<br />
==Restrictions on Using Multiple Queue Managers==<br />
Multiple queue managers have the following restrictions:<br />
* Queues running on one queue manager cannot reference queues running on a different queue manager. For example, a generic queue running on queue manager A cannot direct jobs to an execution queue running on queue manager B.<br />
* You cannot move a job from a queue on one queue manager to a queue on a different queue manager.<br />
* The operating system allows a maximum of five queue managers in an OpenVMS Cluster environment.<br />
<br />
==Names of Multiple Queue Managers==<br />
The process name for a queue manager is the first twelve characters of the queue manager name. The default queue manager name is SYS$QUEUE_MANAGER; the default queue manager process name is QUEUE_MANAGE. If you create an additional queue manager named PRINT_MANAGER, the process name is PRINT_MANAGE.<br />
<br />
==Queue Database Files==<br />
<br />
=== QMAN$MASTER.DAT ===<br />
Multiple queue managers share a single master file. However, a queue database with multiple queue managers contains a queue file and a journal file for each queue manager<br />
<br />
=== queue_manager_name.QMAN$QUEUES ===<br />
<br />
=== queue_manager.QMAN$JOURNAL ===<br />
<br />
==Managing Multiple Queue Managers==<br />
By default, the following commands affect the default queue manager SYS$QUEUE_MANAGER or the<br />
queues running on the default queue manager:<br />
* START/QUEUE/MANAGER<br />
* ENABLE AUTOSTART/QUEUES and DISABLE AUTOSTART/QUEUES<br />
* STOP/QUEUES/ON_NODE<br />
* STOP/QUEUE/MANAGER/CLUSTER<br />
* DELETE/QUEUE/MANAGER<br />
<br />
When you create a queue with the INITIALIZE/QUEUE command, specify the name of the queue manager on which it is to run by including the /NAME_OF_MANAGER qualifier. If you do not specify the /NAME_OF_MANAGER qualifier, the queue is created to run on the default queue manager, SYS$QUEUE_MANAGER.<br />
To move an existing queue from its original queue manager to a different queue manager, delete the queue with the DELETE/QUEUE command and re-create the queue with the INITIALIZE/QUEUE command.<br />
<br />
When entering DCL commands to maintain the queue manager, be sure to specify the /NAME_OF_MANAGER qualifier to specify the queue manager to which the command is to apply. If you do not specify the /NAME_OF_MANAGER qualifier, the command is executed on the default queue manager, SYS$QUEUE_MANAGER.</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=Queue_manager&diff=2014Queue manager2020-05-20T17:55:29Z<p>Madsweeney: /* Queue Database Files */</p>
<hr />
<div>A '''queue manager''' is a section of an OpenVMS system that controls [[Queue|queue]] activity. One or more queue manager processes control queueing for all processes on a node or in an OpenVMS cluster environment. <br />
<br />
=Functions=<br />
When a user submits a [[Batch processing|batch]] or [[Printing|print]] job to a queue, the queue manager performs the following tasks:<br />
# Receives the user's queue request, including information about the type of job, the file name or names, the name of the queue, and any special options.<br />
# Stores and retrieves appropriate information from the queue database to print or execute the job.<br />
# Places the job in the appropriate queue to await its turn for processing:<br />
## Print jobs are sent to an independent process, called a symbiont, for formatting and are then sent to the printer for printing.<br />
## For batch jobs, the job controller creates a batch job process.<br />
<br />
User processes, symbionts, and job controllers on each node communicate directly with queue managers.<br />
In addition, the job controller [[JOB CONTROL]] works with the queue manager to perform the following queue management<br />
tasks:<br />
* Create and monitor [[Batch process|batch]], [[Symbiont|symbiont]], and queue manager processes<br />
* Restart the queue manager process on reboot<br />
* Handle failover of the queue manager in an OpenVMS Cluster environment<br />
<br />
==Queue Manager Failover==<br />
<br />
By default, in an OpenVMS Cluster environment, the queue manager tries to fail over to another node if the<br />
node on which the queue manager is running leaves the cluster. You can specify the order in which OpenVMS Cluster nodes claim the queue manager process. The '''/ON''' qualifier of the '''START/QUEUE/MANAGER''' command lets you specify a list of OpenVMS Cluster member nodes in the order that they should claim the queue manager process. It is recommended that you specify an asterisk (*) at the end of the node list to make sure that at least one node is always available to run the queue manager.<br />
<br />
=Obtaining Information about Queue Managers=<br />
To obtain information about one or more queue managers, enter the '''SHOW QUEUE/MANAGERS''' command (the '''/FULL''' qualifier is available).<br />
<br />
=Starting the Queue Manager=<br />
<br />
Before you can create queues, you must create a queue database by entering a command in the following<br />
format:<br />
'''START/QUEUE/MANAGER/NEW_VERSION[/ON=(node,...)] [dirspec]'''<br />
<br />
'''/NEW_VERSION''' specifies that new [[Queue database|queue database]] files are to be created.<br />
'''/ON''' allows you to customize failover of the queue manager.<br />
'''[dirspec]''' specifies the location of the [[Queue database|queue database]] files if you wish to create them in a location other than the defaut.<br />
<br />
You normally perform this task only once because when you enter the command, the system stores it, along with any qualifier or parameter you enter, in the queue database. The job controller automatically starts the queue manager during reboot unless you enter a '''STOP/QUEUE/MANAGER/CLUSTER''' command. For this reason, including '''START/QUEUE/MANAGER''' in your startup command procedure is unnecessary.<br />
<br />
=Stopping and Restarting the Queue Manager=<br />
<br />
<br />
Once created, a queue manager is stopped at shutdown and started at startup, so you never need to stop or restart it except when you need to modify the list of preferred nodes on which the queue manager can run on.<br />
<br />
==Stopping the Queue Manager==<br />
<br />
To shut down the queue manager on a standalone node or an OpenVMS Cluster node, enter the following command:<br />
'''$ STOP/QUEUE/MANAGER/CLUSTER'''<br />
<br />
The queue manager performs the following tasks:<br />
* Aborts all current jobs that cannot be restarted and requeues all current restartable jobs<br />
* Stops all execution queues<br />
* Disables autostart on all nodes<br />
* Closes all queue database files associated with that queue manager<br />
Once you enter '''STOP/QUEUE/MANAGER/CLUSTER''', the queue manager process remains stopped; requests to that queue manager are denied until you restart the queue manager by entering '''START/QUEUE/MANAGER'''. (Note that the queue system remains running as long as one or more queue managers are running.)<br />
OpenVMS Cluster transitions do not change the state of the queue manager. Newly available nodes do not attempt to start the queue manager (unless you enter '''START/QUEUE/MANAGER''').<br />
Use the /CLUSTER qualifier to stop a clusterwide queue manager. If you enter the obsolete command '''STOP/QUEUE/MANAGER''' (without the '''/CLUSTER''' qualifier), the command performs the same function as<br />
'''STOP/QUEUES/ON_NODE'''. (Use '''STOP/QUEUES/ON_NOD'''E to stop all queues on a single node without stopping the queue manager.)<br />
<br />
==Restarting the Queue Manager==<br />
<br />
The queue manager restarts automatically whenever you reboot the system. However, you might need to<br />
enter '''START/QUEUE/MANAGER''' for one of the following reasons:<br />
* If '''STOP/QUEUE/MANAGER/CLUSTER''' has been executed, enter START/QUEUE/MANAGER to restart the queue manager.<br />
* In an OpenVMS Cluster environment, enter '''START/QUEUE/MANAGER''' with the '''/ON''' qualifier to modify the list of preferred nodes on which the queue manager can run. <br />
* In an OpenVMS Cluster environment, enter START/QUEUE/MANAGER to ensure that the queue manager process executes on the most preferred, available node. If it does not, the queue manager will be moved to the most preferred, available node without interruption of service. If you are using the default node list (*), the queue manager will not be moved.<br />
=== Note System Parameter JOBCTLD ===<br />
* If the system parameter JOBCTLD low bit is set, the job controller will not start the queue manager. JOBCTLD is a dynamic system parameter.<br />
<br />
=Using Multiple Queue Managers=<br />
To work around CPU, disk space, or memory limitations, you can use multiple queue managers to distribute the batch and print work load among nodes as well as to distribute the database files among disks. For example, you might create separate queue managers for batch queues and print queues. Run the batch queue manager on one node and the print queue manager on a different node. You can also maintain queue and journal files on separate disks.<br />
<br />
<br />
==Restrictions on Using Multiple Queue Managers==<br />
Multiple queue managers have the following restrictions:<br />
* Queues running on one queue manager cannot reference queues running on a different queue manager. For example, a generic queue running on queue manager A cannot direct jobs to an execution queue running on queue manager B.<br />
* You cannot move a job from a queue on one queue manager to a queue on a different queue manager.<br />
* The operating system allows a maximum of five queue managers in an OpenVMS Cluster environment.<br />
<br />
==Names of Multiple Queue Managers==<br />
The process name for a queue manager is the first twelve characters of the queue manager name. The default queue manager name is SYS$QUEUE_MANAGER; the default queue manager process name is QUEUE_MANAGE. If you create an additional queue manager named PRINT_MANAGER, the process name is PRINT_MANAGE.<br />
<br />
==Queue Database Files==<br />
<br />
=== QMAN$MASTER.DAT ===<br />
Multiple queue managers share a single master file. However, a queue database with multiple queue managers contains a queue file and a journal file for each queue manager<br />
<br />
=== queue_manager_name.QMAN$QUEUES ===<br />
<br />
=== queue_manager.Qman$Journal ===<br />
<br />
==Managing Multiple Queue Managers==<br />
By default, the following commands affect the default queue manager SYS$QUEUE_MANAGER or the<br />
queues running on the default queue manager:<br />
* START/QUEUE/MANAGER<br />
* ENABLE AUTOSTART/QUEUES and DISABLE AUTOSTART/QUEUES<br />
* STOP/QUEUES/ON_NODE<br />
* STOP/QUEUE/MANAGER/CLUSTER<br />
* DELETE/QUEUE/MANAGER<br />
<br />
When you create a queue with the INITIALIZE/QUEUE command, specify the name of the queue manager on which it is to run by including the /NAME_OF_MANAGER qualifier. If you do not specify the /NAME_OF_MANAGER qualifier, the queue is created to run on the default queue manager, SYS$QUEUE_MANAGER.<br />
To move an existing queue from its original queue manager to a different queue manager, delete the queue with the DELETE/QUEUE command and re-create the queue with the INITIALIZE/QUEUE command.<br />
<br />
When entering DCL commands to maintain the queue manager, be sure to specify the /NAME_OF_MANAGER qualifier to specify the queue manager to which the command is to apply. If you do not specify the /NAME_OF_MANAGER qualifier, the command is executed on the default queue manager, SYS$QUEUE_MANAGER.</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=Queue_manager&diff=2013Queue manager2020-05-20T17:52:22Z<p>Madsweeney: /* Stopping and Restarting the Queue Manager */</p>
<hr />
<div>A '''queue manager''' is a section of an OpenVMS system that controls [[Queue|queue]] activity. One or more queue manager processes control queueing for all processes on a node or in an OpenVMS cluster environment. <br />
<br />
=Functions=<br />
When a user submits a [[Batch processing|batch]] or [[Printing|print]] job to a queue, the queue manager performs the following tasks:<br />
# Receives the user's queue request, including information about the type of job, the file name or names, the name of the queue, and any special options.<br />
# Stores and retrieves appropriate information from the queue database to print or execute the job.<br />
# Places the job in the appropriate queue to await its turn for processing:<br />
## Print jobs are sent to an independent process, called a symbiont, for formatting and are then sent to the printer for printing.<br />
## For batch jobs, the job controller creates a batch job process.<br />
<br />
User processes, symbionts, and job controllers on each node communicate directly with queue managers.<br />
In addition, the job controller [[JOB CONTROL]] works with the queue manager to perform the following queue management<br />
tasks:<br />
* Create and monitor [[Batch process|batch]], [[Symbiont|symbiont]], and queue manager processes<br />
* Restart the queue manager process on reboot<br />
* Handle failover of the queue manager in an OpenVMS Cluster environment<br />
<br />
==Queue Manager Failover==<br />
<br />
By default, in an OpenVMS Cluster environment, the queue manager tries to fail over to another node if the<br />
node on which the queue manager is running leaves the cluster. You can specify the order in which OpenVMS Cluster nodes claim the queue manager process. The '''/ON''' qualifier of the '''START/QUEUE/MANAGER''' command lets you specify a list of OpenVMS Cluster member nodes in the order that they should claim the queue manager process. It is recommended that you specify an asterisk (*) at the end of the node list to make sure that at least one node is always available to run the queue manager.<br />
<br />
=Obtaining Information about Queue Managers=<br />
To obtain information about one or more queue managers, enter the '''SHOW QUEUE/MANAGERS''' command (the '''/FULL''' qualifier is available).<br />
<br />
=Starting the Queue Manager=<br />
<br />
Before you can create queues, you must create a queue database by entering a command in the following<br />
format:<br />
'''START/QUEUE/MANAGER/NEW_VERSION[/ON=(node,...)] [dirspec]'''<br />
<br />
'''/NEW_VERSION''' specifies that new [[Queue database|queue database]] files are to be created.<br />
'''/ON''' allows you to customize failover of the queue manager.<br />
'''[dirspec]''' specifies the location of the [[Queue database|queue database]] files if you wish to create them in a location other than the defaut.<br />
<br />
You normally perform this task only once because when you enter the command, the system stores it, along with any qualifier or parameter you enter, in the queue database. The job controller automatically starts the queue manager during reboot unless you enter a '''STOP/QUEUE/MANAGER/CLUSTER''' command. For this reason, including '''START/QUEUE/MANAGER''' in your startup command procedure is unnecessary.<br />
<br />
=Stopping and Restarting the Queue Manager=<br />
<br />
<br />
Once created, a queue manager is stopped at shutdown and started at startup, so you never need to stop or restart it except when you need to modify the list of preferred nodes on which the queue manager can run on.<br />
<br />
==Stopping the Queue Manager==<br />
<br />
To shut down the queue manager on a standalone node or an OpenVMS Cluster node, enter the following command:<br />
'''$ STOP/QUEUE/MANAGER/CLUSTER'''<br />
<br />
The queue manager performs the following tasks:<br />
* Aborts all current jobs that cannot be restarted and requeues all current restartable jobs<br />
* Stops all execution queues<br />
* Disables autostart on all nodes<br />
* Closes all queue database files associated with that queue manager<br />
Once you enter '''STOP/QUEUE/MANAGER/CLUSTER''', the queue manager process remains stopped; requests to that queue manager are denied until you restart the queue manager by entering '''START/QUEUE/MANAGER'''. (Note that the queue system remains running as long as one or more queue managers are running.)<br />
OpenVMS Cluster transitions do not change the state of the queue manager. Newly available nodes do not attempt to start the queue manager (unless you enter '''START/QUEUE/MANAGER''').<br />
Use the /CLUSTER qualifier to stop a clusterwide queue manager. If you enter the obsolete command '''STOP/QUEUE/MANAGER''' (without the '''/CLUSTER''' qualifier), the command performs the same function as<br />
'''STOP/QUEUES/ON_NODE'''. (Use '''STOP/QUEUES/ON_NOD'''E to stop all queues on a single node without stopping the queue manager.)<br />
<br />
==Restarting the Queue Manager==<br />
<br />
The queue manager restarts automatically whenever you reboot the system. However, you might need to<br />
enter '''START/QUEUE/MANAGER''' for one of the following reasons:<br />
* If '''STOP/QUEUE/MANAGER/CLUSTER''' has been executed, enter START/QUEUE/MANAGER to restart the queue manager.<br />
* In an OpenVMS Cluster environment, enter '''START/QUEUE/MANAGER''' with the '''/ON''' qualifier to modify the list of preferred nodes on which the queue manager can run. <br />
* In an OpenVMS Cluster environment, enter START/QUEUE/MANAGER to ensure that the queue manager process executes on the most preferred, available node. If it does not, the queue manager will be moved to the most preferred, available node without interruption of service. If you are using the default node list (*), the queue manager will not be moved.<br />
=== Note System Parameter JOBCTLD ===<br />
* If the system parameter JOBCTLD low bit is set, the job controller will not start the queue manager. JOBCTLD is a dynamic system parameter.<br />
<br />
=Using Multiple Queue Managers=<br />
To work around CPU, disk space, or memory limitations, you can use multiple queue managers to distribute the batch and print work load among nodes as well as to distribute the database files among disks. For example, you might create separate queue managers for batch queues and print queues. Run the batch queue manager on one node and the print queue manager on a different node. You can also maintain queue and journal files on separate disks.<br />
<br />
<br />
==Restrictions on Using Multiple Queue Managers==<br />
Multiple queue managers have the following restrictions:<br />
* Queues running on one queue manager cannot reference queues running on a different queue manager. For example, a generic queue running on queue manager A cannot direct jobs to an execution queue running on queue manager B.<br />
* You cannot move a job from a queue on one queue manager to a queue on a different queue manager.<br />
* The operating system allows a maximum of five queue managers in an OpenVMS Cluster environment.<br />
<br />
==Names of Multiple Queue Managers==<br />
The process name for a queue manager is the first twelve characters of the queue manager name. The default queue manager name is SYS$QUEUE_MANAGER; the default queue manager process name is QUEUE_MANAGE. If you create an additional queue manager named PRINT_MANAGER, the process name is PRINT_MANAGE.<br />
<br />
==Queue Database Files==<br />
Multiple queue managers share a single master file. However, a queue database with multiple queue managers contains a queue file and a journal file for each queue manager<br />
<br />
==Managing Multiple Queue Managers==<br />
By default, the following commands affect the default queue manager SYS$QUEUE_MANAGER or the<br />
queues running on the default queue manager:<br />
* START/QUEUE/MANAGER<br />
* ENABLE AUTOSTART/QUEUES and DISABLE AUTOSTART/QUEUES<br />
* STOP/QUEUES/ON_NODE<br />
* STOP/QUEUE/MANAGER/CLUSTER<br />
* DELETE/QUEUE/MANAGER<br />
<br />
When you create a queue with the INITIALIZE/QUEUE command, specify the name of the queue manager on which it is to run by including the /NAME_OF_MANAGER qualifier. If you do not specify the /NAME_OF_MANAGER qualifier, the queue is created to run on the default queue manager, SYS$QUEUE_MANAGER.<br />
To move an existing queue from its original queue manager to a different queue manager, delete the queue with the DELETE/QUEUE command and re-create the queue with the INITIALIZE/QUEUE command.<br />
<br />
When entering DCL commands to maintain the queue manager, be sure to specify the /NAME_OF_MANAGER qualifier to specify the queue manager to which the command is to apply. If you do not specify the /NAME_OF_MANAGER qualifier, the command is executed on the default queue manager, SYS$QUEUE_MANAGER.</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=Queue_manager&diff=2012Queue manager2020-05-20T17:36:50Z<p>Madsweeney: /* Functions */</p>
<hr />
<div>A '''queue manager''' is a section of an OpenVMS system that controls [[Queue|queue]] activity. One or more queue manager processes control queueing for all processes on a node or in an OpenVMS cluster environment. <br />
<br />
=Functions=<br />
When a user submits a [[Batch processing|batch]] or [[Printing|print]] job to a queue, the queue manager performs the following tasks:<br />
# Receives the user's queue request, including information about the type of job, the file name or names, the name of the queue, and any special options.<br />
# Stores and retrieves appropriate information from the queue database to print or execute the job.<br />
# Places the job in the appropriate queue to await its turn for processing:<br />
## Print jobs are sent to an independent process, called a symbiont, for formatting and are then sent to the printer for printing.<br />
## For batch jobs, the job controller creates a batch job process.<br />
<br />
User processes, symbionts, and job controllers on each node communicate directly with queue managers.<br />
In addition, the job controller [[JOB CONTROL]] works with the queue manager to perform the following queue management<br />
tasks:<br />
* Create and monitor [[Batch process|batch]], [[Symbiont|symbiont]], and queue manager processes<br />
* Restart the queue manager process on reboot<br />
* Handle failover of the queue manager in an OpenVMS Cluster environment<br />
<br />
==Queue Manager Failover==<br />
<br />
By default, in an OpenVMS Cluster environment, the queue manager tries to fail over to another node if the<br />
node on which the queue manager is running leaves the cluster. You can specify the order in which OpenVMS Cluster nodes claim the queue manager process. The '''/ON''' qualifier of the '''START/QUEUE/MANAGER''' command lets you specify a list of OpenVMS Cluster member nodes in the order that they should claim the queue manager process. It is recommended that you specify an asterisk (*) at the end of the node list to make sure that at least one node is always available to run the queue manager.<br />
<br />
=Obtaining Information about Queue Managers=<br />
To obtain information about one or more queue managers, enter the '''SHOW QUEUE/MANAGERS''' command (the '''/FULL''' qualifier is available).<br />
<br />
=Starting the Queue Manager=<br />
<br />
Before you can create queues, you must create a queue database by entering a command in the following<br />
format:<br />
'''START/QUEUE/MANAGER/NEW_VERSION[/ON=(node,...)] [dirspec]'''<br />
<br />
'''/NEW_VERSION''' specifies that new [[Queue database|queue database]] files are to be created.<br />
'''/ON''' allows you to customize failover of the queue manager.<br />
'''[dirspec]''' specifies the location of the [[Queue database|queue database]] files if you wish to create them in a location other than the defaut.<br />
<br />
You normally perform this task only once because when you enter the command, the system stores it, along with any qualifier or parameter you enter, in the queue database. The job controller automatically starts the queue manager during reboot unless you enter a '''STOP/QUEUE/MANAGER/CLUSTER''' command. For this reason, including '''START/QUEUE/MANAGER''' in your startup command procedure is unnecessary.<br />
<br />
=Stopping and Restarting the Queue Manager=<br />
<br />
<br />
Once created, a queue manager is stopped at shutdown and started at startup, so you never need to stop or restart it except when you need to modify the list of preferred nodes on which the queue manager can run on.<br />
<br />
==Stopping the Queue Manager==<br />
<br />
To shut down the queue manager on a standalone node or an OpenVMS Cluster node, enter the following command:<br />
'''$ STOP/QUEUE/MANAGER/CLUSTER'''<br />
<br />
The queue manager performs the following tasks:<br />
* Aborts all current jobs that cannot be restarted and requeues all current restartable jobs<br />
* Stops all execution queues<br />
* Disables autostart on all nodes<br />
* Closes all queue database files associated with that queue manager<br />
Once you enter '''STOP/QUEUE/MANAGER/CLUSTER''', the queue manager process remains stopped; requests to that queue manager are denied until you restart the queue manager by entering '''START/QUEUE/MANAGER'''. (Note that the queue system remains running as long as one or more queue managers are running.)<br />
OpenVMS Cluster transitions do not change the state of the queue manager. Newly available nodes do not attempt to start the queue manager (unless you enter '''START/QUEUE/MANAGER''').<br />
Use the /CLUSTER qualifier to stop a clusterwide queue manager. If you enter the obsolete command '''STOP/QUEUE/MANAGER''' (without the '''/CLUSTER''' qualifier), the command performs the same function as<br />
'''STOP/QUEUES/ON_NODE'''. (Use '''STOP/QUEUES/ON_NOD'''E to stop all queues on a single node without stopping the queue manager.)<br />
<br />
==Restarting the Queue Manager==<br />
<br />
The queue manager restarts automatically whenever you reboot the system. However, you might need to<br />
enter '''START/QUEUE/MANAGER''' for one of the following reasons:<br />
* If '''STOP/QUEUE/MANAGER/CLUSTER''' has been executed, enter START/QUEUE/MANAGER to restart the queue manager.<br />
* In an OpenVMS Cluster environment, enter '''START/QUEUE/MANAGER''' with the '''/ON''' qualifier to modify the list of preferred nodes on which the queue manager can run. <br />
* In an OpenVMS Cluster environment, enter START/QUEUE/MANAGER to ensure that the queue manager process executes on the most preferred, available node. If it does not, the queue manager will be moved to the most preferred, available node without interruption of service. If you are using the default node list (*), the queue manager will not be moved.<br />
<br />
=Using Multiple Queue Managers=<br />
To work around CPU, disk space, or memory limitations, you can use multiple queue managers to distribute the batch and print work load among nodes as well as to distribute the database files among disks. For example, you might create separate queue managers for batch queues and print queues. Run the batch queue manager on one node and the print queue manager on a different node. You can also maintain queue and journal files on separate disks.<br />
<br />
<br />
==Restrictions on Using Multiple Queue Managers==<br />
Multiple queue managers have the following restrictions:<br />
* Queues running on one queue manager cannot reference queues running on a different queue manager. For example, a generic queue running on queue manager A cannot direct jobs to an execution queue running on queue manager B.<br />
* You cannot move a job from a queue on one queue manager to a queue on a different queue manager.<br />
* The operating system allows a maximum of five queue managers in an OpenVMS Cluster environment.<br />
<br />
==Names of Multiple Queue Managers==<br />
The process name for a queue manager is the first twelve characters of the queue manager name. The default queue manager name is SYS$QUEUE_MANAGER; the default queue manager process name is QUEUE_MANAGE. If you create an additional queue manager named PRINT_MANAGER, the process name is PRINT_MANAGE.<br />
<br />
==Queue Database Files==<br />
Multiple queue managers share a single master file. However, a queue database with multiple queue managers contains a queue file and a journal file for each queue manager<br />
<br />
==Managing Multiple Queue Managers==<br />
By default, the following commands affect the default queue manager SYS$QUEUE_MANAGER or the<br />
queues running on the default queue manager:<br />
* START/QUEUE/MANAGER<br />
* ENABLE AUTOSTART/QUEUES and DISABLE AUTOSTART/QUEUES<br />
* STOP/QUEUES/ON_NODE<br />
* STOP/QUEUE/MANAGER/CLUSTER<br />
* DELETE/QUEUE/MANAGER<br />
<br />
When you create a queue with the INITIALIZE/QUEUE command, specify the name of the queue manager on which it is to run by including the /NAME_OF_MANAGER qualifier. If you do not specify the /NAME_OF_MANAGER qualifier, the queue is created to run on the default queue manager, SYS$QUEUE_MANAGER.<br />
To move an existing queue from its original queue manager to a different queue manager, delete the queue with the DELETE/QUEUE command and re-create the queue with the INITIALIZE/QUEUE command.<br />
<br />
When entering DCL commands to maintain the queue manager, be sure to specify the /NAME_OF_MANAGER qualifier to specify the queue manager to which the command is to apply. If you do not specify the /NAME_OF_MANAGER qualifier, the command is executed on the default queue manager, SYS$QUEUE_MANAGER.</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=JOB_CONTROL&diff=2011JOB CONTROL2020-05-20T16:27:16Z<p>Madsweeney: </p>
<hr />
<div>The JOB_CONTROL process is the VMS Job controller process. <br />
<br />
Image Location: SYS$COMMON:[SYSEXE]JBC$JOB_CONTROL.EXE<br />
<br />
= Job controller process functional summary =<br />
The job controller performs multiple functions for VMS:<br />
<br />
#When a new terminal connection is detected the job controller creates a process attached to the terminal running LOGINOUT.EXE to initiate the login process.<br />
#Processes all VMS requests to write accounting data to the system accounting file.<br />
#Acts as the client communication to all VMS Queue Managers running in a cluster.<br />
##Creates batch processes and symbiont processes on the local system.<br />
##Notifies queue managers of their batch job completions on the local system.<br />
##Creates queue manager processes for queue managers that are prioritized to run on the local system.<br />
#Performs Standard Time and Daylight Saving Time clock adjustments.<br />
#As a known, persistent process JOB_CONTROL is sometimes used by products and OS components as the target to queue ASTs to perform a desired actions. For example when the Availability Manager Product is crash a system, it queues an AST to the JOB_CONTROL process to perform the crash.</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=F$GETSYI()&diff=1955F$GETSYI()2020-02-17T20:03:48Z<p>Madsweeney: /* item */</p>
<hr />
<div>'''F$GETSYI()''' is a [[Lexical function|lexical function]] that returns status and identification information about the local system (or about a node in the local mixed-architecture OpenVMS Cluster system, if your system is part of an OpenVMS Cluster).<br />
<br />
=Format=<br />
<br />
F$GETSYI (item [,node-name] [,cluster-id])<br />
<br />
==item==<br />
<br />
In addition to the items below, you can specify any [[System Parameters|system parameter]].<br />
<br />
==node-name==<br />
<br />
Specifies the node in your OpenVMS Cluster system for which information is to be returned. Specify the node as a character string expression. You cannot use the asterisk (*) and the percent sign (%) wildcard characters to specify the '''node-name''' argument.<br />
<br />
==cluster-id==<br />
Specifies the cluster node identification number for which the information is to be returned.<br />
To get information for all the nodes in a cluster, use the F$CSID lexical function to obtain each cluster system identification number, and use the '''cluster-id''' argument of F$GETSYI to gather information about each node.<br />
<br />
=Examples=<br />
<pre>$ SYSID = F$GETSYI("SID")<br />
$ SHOW SYMBOL SYSID<br />
SYSID = 19923201 Hex = 01300101 Octal = 000401<br />
<br />
$ MEM = F$GETSYI("CLUSTER_MEMBER", "LONDON")<br />
$ SHOW SYMBOL MEM<br />
MEM = "TRUE"<br />
<br />
$ LIM = F$GETSYI("IJOBLIM")<br />
$ SHOW SYMBOL LIM<br />
LIM = 16 Hex = 00000010 Octal = 00000000020<br />
<br />
$ DECNETVERS = F$GETSYI("DECNET_VERSION")<br />
$ SHOW SYMBOL DECNETVERS<br />
DECNETVERS = "00050D01"<br />
$ DECNETPHASE = F$INTEGER(F$EXTRACT(2,2,DECNETVERS))<br />
$ SHOW SYMBOL DECNETPHASE<br />
DECNETPHASE = 5 Hex = 00000005 Octal = 00000000005<br />
<br />
$ RADCPU = F$GETSYI("RAD_CPUS")<br />
$ SHOW SYMBOL RADCPU<br />
0,0,0,1,1,4,1,5<br />
</pre><br />
<br />
[[Category: Lexical Functions]]</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=F$GETSYI()&diff=1954F$GETSYI()2020-02-17T20:02:25Z<p>Madsweeney: </p>
<hr />
<div>'''F$GETSYI()''' is a [[Lexical function|lexical function]] that returns status and identification information about the local system (or about a node in the local mixed-architecture OpenVMS Cluster system, if your system is part of an OpenVMS Cluster).<br />
<br />
=Format=<br />
<br />
F$GETSYI (item [,node-name] [,cluster-id])<br />
<br />
==item==<br />
<br />
In addition to the items below, you can specify any [[System Parameters|system parameter]].<br />
<br />
{| class="wikitable"<br />
|-<br />
! Item !! Return Type !! Information Returned<br />
|-<br />
| AI || style="text-align:center;" | String || TRUE if after-image (AI) journaling is enabled; FALSE if disabled.<br />
|-<br />
| ALQ || style="text-align:center;" | Integer || Allocation quantity.<br />
|-<br />
| BDT || style="text-align:center;" | String || Backup date/time.<br />
|-<br />
| BI || style="text-align:center;" | String || TRUE if before-image (BI) journaling is enabled; FALSE if disabled.<br />
|-<br />
| BKS || style="text-align:center;" | Integer || Bucket size.<br />
|-<br />
| BLS || style="text-align:center;" | Integer || Block size.<br />
|-<br />
| CBT || style="text-align:center;" | String || TRUE if contiguous-best-try; otherwise FALSE.<br />
|-<br />
| CDT || style="text-align:center;" | String || Creation date/time.<br />
|-<br />
| CTG || style="text-align:center;" | String || TRUE if contiguous; otherwise FALSE.<br />
|-<br />
| DEQ || style="text-align:center;" | Integer || Default extension quantity.<br />
|-<br />
| DID || style="text-align:center;" | String || Directory ID string.<br />
|-<br />
| DIRECTORY || style="text-align:center;" | String || Returns TRUE or FALSE. Returns TRUE if it is a directory.<br />
|-<br />
| DVI || style="text-align:center;" | String || Device name string.<br />
|-<br />
| EDT || style="text-align:center;" | String || Expiration date/time.<br />
|-<br />
| EOF || style="text-align:center;" | Integer || Number of blocks used.<br />
|-<br />
| ERASE || style="text-align:center;" | String || TRUE if a file's contents are erased before a file is deleted; otherwise FALSE.<br />
|-<br />
| FFB || style="text-align:center;" | Integer || First free byte.<br />
|-<br />
| FID || style="text-align:center;" | String || File ID string.<br />
|-<br />
| FILE_LENGTH_HINT || style="text-align:center;" | String || Record count and data byte count in the form (<br />
|-<br />
| FSZ || style="text-align:center;" | Integer || Fixed control area size.<br />
|-<br />
| GBC || style="text-align:center;" | Integer || Global buffer count.<br />
|-<br />
| GBC32 || style="text-align:center;" | Integer || Enhanced longword version of global buffer count with a per-file maximum size of about 2.1 billion for indexed files.<br />
|-<br />
| GBCFLAGS || style="text-align:center;" | String || Per-file management flags for sizing of global buffer cache. Returns PERCENT if global buffer count is expresses as a percent, DEFAULT if global buffer size is determined at runtime by an algorithm using two global buffer SYSGEN parameters (GB_CACHEALLMAX and GB_DEFPERCENT); or NONE if no per-file management flags are enabled for the file.<br />
|-<br />
| GRP || style="text-align:center;" | Integer || Owner group number.<br />
|-<br />
| JOURNAL_FILE || style="text-align:center;" | String || TRUE if the file is a journal; otherwise FALSE.<br />
|-<br />
| KNOWN || style="text-align:center;" | String || Known file; returns TRUE or FALSE to indicate whether file is installed with the Install utility (INSTALL). However, returns NOSUCHFILE if a file does not exist (for example, the file has been installed but subsequently deleted).<br />
|-<br />
| LOCKED || style="text-align:center;" | String || TRUE if a file is deaccessed-locked; otherwise FALSE.<br />
|-<br />
| LRL || style="text-align:center;" | Integer || Longest record length.<br />
|-<br />
| MBM || style="text-align:center;" | Integer || Owner member number.<br />
|-<br />
| MOVE || style="text-align:center;" | String || TRUE if movefile operations are enabled; otherwise FALSE.<br />
|-<br />
| MRN || style="text-align:center;" | Integer || Maximum record number.<br />
|-<br />
| MRS || style="text-align:center;" | Integer || Maximum record size.<br />
|-<br />
| NOA || style="text-align:center;" | Integer || Number of areas.<br />
|-<br />
| NOBACKUP || style="text-align:center;" | String || FALSE if the file is marked for backup; TRUE if the file is marked NOBACKUP.<br />
|-<br />
| NOK || style="text-align:center;" | Integer || Number of keys.<br />
|-<br />
| ORG || style="text-align:center;" | String || File organization; returns SEQ, REL, IDX.<br />
|-<br />
| PRESHELVED (Alpha/Integrity servers only) || style="text-align:center;" | String || TRUE if the file is preshelved; otherwise FALSE.<br />
|-<br />
| PRO || style="text-align:center;" | String || File protection string.<br />
|-<br />
| PVN || style="text-align:center;" | Integer || Prolog version number.<br />
|-<br />
| RAT || style="text-align:center;" | String || Record attributes; returns CR, PRN, FTN, "".<br />
|-<br />
| RCK || style="text-align:center;" | String || TRUE if read check; otherwise FALSE.<br />
|-<br />
| RDT || style="text-align:center;" | String || Revision date/time.<br />
|-<br />
| RFM || style="text-align:center;" | String || Record format string; returns the values VAR, FIX, VFC, UDF, STM, STMLF, STMCR.<br />
|-<br />
| RU || style="text-align:center;" | String || TRUE if recovery unit (RU) journaling is enabled; returns TRUE or FALSE.<br />
|-<br />
| RVN || style="text-align:center;" | Integer || Revision number.<br />
|-<br />
| SHELVABLE || style="text-align:center;" | String || TRUE if the file is shelvable; otherwise FALSE.<br />
|-<br />
| SHELVED || style="text-align:center;" | String || TRUE if the file is shelved; otherwise FALSE.<br />
|-<br />
| STORED_SEMANTICS || style="text-align:center;" | String || ASCII string that represents stored semantics.<br />
|-<br />
| UIC || style="text-align:center;" | String || Owner user identification code (UIC) string.<br />
|-<br />
| VERLIMIT || style="text-align:center;" | Integer || Version limit number. The value 32767 indicates that no version limit was set.<br />
|-<br />
| WCK || style="text-align:center;" | String || TRUE if write check; otherwise FALSE.<br />
|}<br />
<br />
==node-name==<br />
<br />
Specifies the node in your OpenVMS Cluster system for which information is to be returned. Specify the node as a character string expression. You cannot use the asterisk (*) and the percent sign (%) wildcard characters to specify the '''node-name''' argument.<br />
<br />
==cluster-id==<br />
Specifies the cluster node identification number for which the information is to be returned.<br />
To get information for all the nodes in a cluster, use the F$CSID lexical function to obtain each cluster system identification number, and use the '''cluster-id''' argument of F$GETSYI to gather information about each node.<br />
<br />
=Examples=<br />
<pre>$ SYSID = F$GETSYI("SID")<br />
$ SHOW SYMBOL SYSID<br />
SYSID = 19923201 Hex = 01300101 Octal = 000401<br />
<br />
$ MEM = F$GETSYI("CLUSTER_MEMBER", "LONDON")<br />
$ SHOW SYMBOL MEM<br />
MEM = "TRUE"<br />
<br />
$ LIM = F$GETSYI("IJOBLIM")<br />
$ SHOW SYMBOL LIM<br />
LIM = 16 Hex = 00000010 Octal = 00000000020<br />
<br />
$ DECNETVERS = F$GETSYI("DECNET_VERSION")<br />
$ SHOW SYMBOL DECNETVERS<br />
DECNETVERS = "00050D01"<br />
$ DECNETPHASE = F$INTEGER(F$EXTRACT(2,2,DECNETVERS))<br />
$ SHOW SYMBOL DECNETPHASE<br />
DECNETPHASE = 5 Hex = 00000005 Octal = 00000000005<br />
<br />
$ RADCPU = F$GETSYI("RAD_CPUS")<br />
$ SHOW SYMBOL RADCPU<br />
0,0,0,1,1,4,1,5<br />
</pre><br />
<br />
[[Category: Lexical Functions]]</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=JOB_CONTROL&diff=1383JOB CONTROL2019-10-08T18:31:45Z<p>Madsweeney: </p>
<hr />
<div>JOB_CONTROL is the VMS Job controller process. The job controller performs multiple functions for VMS:<br />
<br />
#When a new terminal connection is detected the job controller creates a process attached to the terminal running LOGINOUT.EXE to initiate the login process.<br />
#Processes all VMS requests to write accounting data to the system accounting file.<br />
#Acts as the client communication to all VMS Queue Managers running in a cluster.<br />
##Creates batch processes and symbiont processes on the local system.<br />
##Notifies queue managers of their batch job completions on the local system.<br />
##Creates queue manager processes for queue managers that are prioritized to run on the local system.<br />
#Performs Standard Time and Daylight Saving Time clock adjustments.</div>Madsweeneyhttps://wiki.vmssoftware.com/index.php?title=JOB_CONTROL&diff=1382JOB CONTROL2019-10-08T18:28:31Z<p>Madsweeney: Created page with "JOB_CONTROL is the VMS Job controller process. The job controller performs multiple functions for VMS: #When a new terminal connection is detected the job controller creates..."</p>
<hr />
<div>JOB_CONTROL is the VMS Job controller process. The job controller performs multiple functions for VMS:<br />
<br />
#When a new terminal connection is detected the job controller creates a process attached to the terminal running LOGINOUT.EXE to initiate the login process.<br />
#Processes all VMS requests to write accounting data to the system accounting file.<br />
#Acts as the client communication to all VMS Queue Managers running in a cluster.<br />
#Performs Standard Time and Daylight Saving Time clock adjustments.</div>Madsweeney