https://wiki.vmssoftware.com/api.php?action=feedcontributions&user=Jane.doe&feedformat=atomVSI OpenVMS Wiki - User contributions [en]2024-03-19T11:44:10ZUser contributionsMediaWiki 1.31.0https://wiki.vmssoftware.com/index.php?title=User_talk:Jane.doe&diff=2648User talk:Jane.doe2023-12-20T10:22:43Z<p>Jane.doe: Created page with " test"</p>
<hr />
<div> test</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=F$GETQUI_Context&diff=2647F$GETQUI Context2023-12-20T10:18:58Z<p>Jane.doe: Fixed some typos reported in Jon Pinkley's email</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 />
NAME_THREE == "TEST1"<br />
$ NAME_FOUR = F$GETQUI("DISPLAY_JOB","JOB_NAME",,"ALL_JOBS")<br />
$ SHOW SYM NAME_FOUR<br />
NAME_FOUR == "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 />
$ 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>Jane.doehttps://wiki.vmssoftware.com/index.php?title=F$GETQUI_Context&diff=2646F$GETQUI Context2023-12-20T09:50:01Z<p>Jane.doe: fixed formatting as per comment by Jon Pinkley</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 />
$ 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>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Label&diff=2645Label2023-12-18T14:16:28Z<p>Jane.doe: Created page with "A '''label''' is a statement in a DCL command procedure that marks a certain place in the command procedure for purposes of execution flow control. It ca..."</p>
<hr />
<div>A '''label''' is a statement in a DCL [[Command procedure|command procedure]] that marks a certain place in the command procedure for purposes of execution flow control. It can be any string preceded by a dollar sign and followed by a colon (:):<br />
<br />
$ SHOW TIME<br />
$LOOP:<br />
$ FILE = F$SEARCH("FILE.LIS")<br />
...<br />
<br />
In the example above, "LOOP" is a label. It is possible to refer to this label with [[GOTO]] or [[GOSUB]] as well as /END and /ERROR qualifiers of the [[READ]] command and some other commands.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=READ&diff=2644READ2023-12-18T14:01:25Z<p>Jane.doe: </p>
<hr />
<div>'''READ''' is a [[DCL]] [[Command|command]] that reads a single record from a specified input [[File|file]] and assigns the record's contents to a specified local [[Symbol|symbol]] name.<br />
<br />
=Syntax=<br />
READ logical-name[:] symbol-name<br />
<br />
logical-name is the device you are reading from, [[SYS$COMMAND]], [[SYS$INPUT]], or a [[Logical Name|logical name]] defined to an open file with the [[OPEN]] command (see example below).<br />
<br />
symbol-name is a name for the symbol to read the record's contents into.<br />
<br />
==Qualifiers==<br />
* /DELETE deletes a record from an indexed file after it has been read. An indexed file must be opened with the /READ and /WRITE qualifiers in order to use the READ/DELETE command.<br />
* /END_OF_FILE=label transfers control to the location specified by the [[Label|label]] keyword (in the current command procedure) when the end of the file is reached. When the last record in the file is read, the OpenVMS Record Management Services (RMS) returns an error condition indicating the end-of-file (EOF). If the /END_OF_FILE qualifier is specified, the command interpreter transfers control to the command line at the specified [[Label|label]]. If the /END_OF_FILE qualifier is not specified, control is given to the error [[Label|label]] specified with the /ERROR qualifier when the end of the file is reached. If neither the /ERROR nor the /END_OF_FILE qualifier is specified, then the current ON condition action is taken.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to [[Label|label]] END when the end of file is reached.<br />
<br />
* /ERROR=label transfers control to the location specified by the [[Label|label]] keyword (in the current command procedure) when a read error occurs. If no error routine is specified and an error occurs during the reading of the file, the current ON condition action is taken. Overrides any [[ON]] condition action specified. If an error occurs and the target [[Label|label]] is successfully given control, the reserved global symbol $STATUS retains the error code.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END /ERROR=ERROR FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 0<br />
$ERROR:<br />
$ WRITE SYS$OUTPUT "Oops"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to label END when the end of file is reached and /ERROR is used to branch to label ERROR when an error occurs.<br />
<br />
* /INDEX=n specifies the index (n) to be used to look up keys when reading an indexed file. If you do not specify the /INDEX qualifier, the most recent /INDEX qualifier value is used. If a previous value was not specified, the primary index is used (/INDEX=0).<br />
* /KEY=string reads a record with the key that matches the specified character string. Binary and integer keys are not allowed. This qualifier, when used together with the /INDEX qualifier, allows you random access to indexed files. Key matches are made by comparing the characters in the /KEY string to characters in the record key. To read records at random in an indexed file, you must specify the /KEY qualifier. Once a record is read randomly, all subsequent reads without the /KEY qualifier access records in the indexed file sequentially.<br />
*/MATCH=option specifies the key match algorithm to be used when searching for matching keys. Specify one of the following options:<br />
<br />
EQ Selects keys equal to the match value (default).<br />
GE Selects keys greater than or equal to the match value.<br />
GT Selects keys greater than the match value.<br />
LE Selects keys less than or equal to the match value.<br />
LT Selects keys less than the match value.<br />
<br />
If you are reading indexed files and you do not use the /MATCH qualifier, the default is /MATCH=EQ.<br />
* /NOLOCK specifies that the record to be read not be locked and enables a record to be read that has been locked by other accessors. By default, records are locked as they are read and unlocked on the next I/O operation on the file.<br />
*/PROMPT=string specifies an alternate prompt string to be displayed when reading from the terminal. The default prompt string is DATA:.<br />
<br />
$ READ SYS$COMMAND LINE /PROMPT="Enter data:"<br />
Enter data:<br />
<br />
In the example above, READ SYS$COMMAND is used to obtain data from the terminal. Whatever the user enters at the "Enter data:" prompt, will be saved as the value of the LINE symbol (case sensitive).<br />
<br />
*/TIME_OUT=n specifies the number of seconds after which the READ command is terminated if no input is received. If you enter the /TIME_OUT qualifier, you must specify a value from 0 to 255. The default is /NOTIME_OUT. If you enter both the /ERROR=label and /TIME_OUT qualifiers, and the time limit expires, the error branch is taken.<br />
* /WAIT sets RAB$V_WAT to make a process wait for a record in a file. Can be used in combination with /TIME_OUT to restrict how long the process should wait before timing out upon failure to find the record.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=READ&diff=2643READ2023-12-18T14:01:09Z<p>Jane.doe: </p>
<hr />
<div>'''READ''' is a [[DCL]] [[Command|command]] that reads a single record from a specified input [[File|file]] and assigns the record's contents to a specified local [[Symbol|symbol]] name.<br />
<br />
=Syntax=<br />
READ logical-name[:] symbol-name<br />
<br />
logical-name is the device you are reading from, [[SYS$COMMAND]], [[SYS$INPUT]], or a [[Logical Name|logical name]] defined to an open file with the [[OPEN]] command (see example below).<br />
<br />
symbol-name is a name for the symbol to read the record's contents into.<br />
<br />
==Qualifiers==<br />
* /DELETE deletes a record from an indexed file after it has been read. An indexed file must be opened with the /READ and /WRITE qualifiers in order to use the READ/DELETE command.<br />
* /END_OF_FILE=label transfers control to the location specified by the [[Label|label]] keyword (in the current command procedure) when the end of the file is reached. When the last record in the file is read, the OpenVMS Record Management Services (RMS) returns an error condition indicating the end-of-file (EOF). If the /END_OF_FILE qualifier is specified, the command interpreter transfers control to the command line at the specified [[Label|label]]. If the /END_OF_FILE qualifier is not specified, control is given to the error [[Label|label]] specified with the /ERROR qualifier when the end of the file is reached. If neither the /ERROR nor the /END_OF_FILE qualifier is specified, then the current ON condition action is taken.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to [[Label|label]] END when the end of file is reached.<br />
<br />
* /ERROR=label transfers control to the location specified by the [[Label|label]]keyword (in the current command procedure) when a read error occurs. If no error routine is specified and an error occurs during the reading of the file, the current ON condition action is taken. Overrides any [[ON]] condition action specified. If an error occurs and the target [[Label|label]] is successfully given control, the reserved global symbol $STATUS retains the error code.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END /ERROR=ERROR FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 0<br />
$ERROR:<br />
$ WRITE SYS$OUTPUT "Oops"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to label END when the end of file is reached and /ERROR is used to branch to label ERROR when an error occurs.<br />
<br />
* /INDEX=n specifies the index (n) to be used to look up keys when reading an indexed file. If you do not specify the /INDEX qualifier, the most recent /INDEX qualifier value is used. If a previous value was not specified, the primary index is used (/INDEX=0).<br />
* /KEY=string reads a record with the key that matches the specified character string. Binary and integer keys are not allowed. This qualifier, when used together with the /INDEX qualifier, allows you random access to indexed files. Key matches are made by comparing the characters in the /KEY string to characters in the record key. To read records at random in an indexed file, you must specify the /KEY qualifier. Once a record is read randomly, all subsequent reads without the /KEY qualifier access records in the indexed file sequentially.<br />
*/MATCH=option specifies the key match algorithm to be used when searching for matching keys. Specify one of the following options:<br />
<br />
EQ Selects keys equal to the match value (default).<br />
GE Selects keys greater than or equal to the match value.<br />
GT Selects keys greater than the match value.<br />
LE Selects keys less than or equal to the match value.<br />
LT Selects keys less than the match value.<br />
<br />
If you are reading indexed files and you do not use the /MATCH qualifier, the default is /MATCH=EQ.<br />
* /NOLOCK specifies that the record to be read not be locked and enables a record to be read that has been locked by other accessors. By default, records are locked as they are read and unlocked on the next I/O operation on the file.<br />
*/PROMPT=string specifies an alternate prompt string to be displayed when reading from the terminal. The default prompt string is DATA:.<br />
<br />
$ READ SYS$COMMAND LINE /PROMPT="Enter data:"<br />
Enter data:<br />
<br />
In the example above, READ SYS$COMMAND is used to obtain data from the terminal. Whatever the user enters at the "Enter data:" prompt, will be saved as the value of the LINE symbol (case sensitive).<br />
<br />
*/TIME_OUT=n specifies the number of seconds after which the READ command is terminated if no input is received. If you enter the /TIME_OUT qualifier, you must specify a value from 0 to 255. The default is /NOTIME_OUT. If you enter both the /ERROR=label and /TIME_OUT qualifiers, and the time limit expires, the error branch is taken.<br />
* /WAIT sets RAB$V_WAT to make a process wait for a record in a file. Can be used in combination with /TIME_OUT to restrict how long the process should wait before timing out upon failure to find the record.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=READ&diff=2642READ2023-12-18T14:01:00Z<p>Jane.doe: </p>
<hr />
<div>'''READ''' is a [[DCL]] [[Command|command]] that reads a single record from a specified input [[File|file]] and assigns the record's contents to a specified local [[Symbol|symbol]] name.<br />
<br />
=Syntax=<br />
READ logical-name[:] symbol-name<br />
<br />
logical-name is the device you are reading from, [[SYS$COMMAND]], [[SYS$INPUT]], or a [[Logical Name|logical name]] defined to an open file with the [[OPEN]] command (see example below).<br />
<br />
symbol-name is a name for the symbol to read the record's contents into.<br />
<br />
==Qualifiers==<br />
* /DELETE deletes a record from an indexed file after it has been read. An indexed file must be opened with the /READ and /WRITE qualifiers in order to use the READ/DELETE command.<br />
* /END_OF_FILE=label transfers control to the location specified by the [[Label|label]] keyword (in the current command procedure) when the end of the file is reached. When the last record in the file is read, the OpenVMS Record Management Services (RMS) returns an error condition indicating the end-of-file (EOF). If the /END_OF_FILE qualifier is specified, the command interpreter transfers control to the command line at the specified [[Label|label]]. If the /END_OF_FILE qualifier is not specified, control is given to the error [[Label|label]]specified with the /ERROR qualifier when the end of the file is reached. If neither the /ERROR nor the /END_OF_FILE qualifier is specified, then the current ON condition action is taken.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to [[Label|label]] END when the end of file is reached.<br />
<br />
* /ERROR=label transfers control to the location specified by the [[Label|label]]keyword (in the current command procedure) when a read error occurs. If no error routine is specified and an error occurs during the reading of the file, the current ON condition action is taken. Overrides any [[ON]] condition action specified. If an error occurs and the target [[Label|label]] is successfully given control, the reserved global symbol $STATUS retains the error code.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END /ERROR=ERROR FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 0<br />
$ERROR:<br />
$ WRITE SYS$OUTPUT "Oops"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to label END when the end of file is reached and /ERROR is used to branch to label ERROR when an error occurs.<br />
<br />
* /INDEX=n specifies the index (n) to be used to look up keys when reading an indexed file. If you do not specify the /INDEX qualifier, the most recent /INDEX qualifier value is used. If a previous value was not specified, the primary index is used (/INDEX=0).<br />
* /KEY=string reads a record with the key that matches the specified character string. Binary and integer keys are not allowed. This qualifier, when used together with the /INDEX qualifier, allows you random access to indexed files. Key matches are made by comparing the characters in the /KEY string to characters in the record key. To read records at random in an indexed file, you must specify the /KEY qualifier. Once a record is read randomly, all subsequent reads without the /KEY qualifier access records in the indexed file sequentially.<br />
*/MATCH=option specifies the key match algorithm to be used when searching for matching keys. Specify one of the following options:<br />
<br />
EQ Selects keys equal to the match value (default).<br />
GE Selects keys greater than or equal to the match value.<br />
GT Selects keys greater than the match value.<br />
LE Selects keys less than or equal to the match value.<br />
LT Selects keys less than the match value.<br />
<br />
If you are reading indexed files and you do not use the /MATCH qualifier, the default is /MATCH=EQ.<br />
* /NOLOCK specifies that the record to be read not be locked and enables a record to be read that has been locked by other accessors. By default, records are locked as they are read and unlocked on the next I/O operation on the file.<br />
*/PROMPT=string specifies an alternate prompt string to be displayed when reading from the terminal. The default prompt string is DATA:.<br />
<br />
$ READ SYS$COMMAND LINE /PROMPT="Enter data:"<br />
Enter data:<br />
<br />
In the example above, READ SYS$COMMAND is used to obtain data from the terminal. Whatever the user enters at the "Enter data:" prompt, will be saved as the value of the LINE symbol (case sensitive).<br />
<br />
*/TIME_OUT=n specifies the number of seconds after which the READ command is terminated if no input is received. If you enter the /TIME_OUT qualifier, you must specify a value from 0 to 255. The default is /NOTIME_OUT. If you enter both the /ERROR=label and /TIME_OUT qualifiers, and the time limit expires, the error branch is taken.<br />
* /WAIT sets RAB$V_WAT to make a process wait for a record in a file. Can be used in combination with /TIME_OUT to restrict how long the process should wait before timing out upon failure to find the record.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=READ&diff=2641READ2023-12-18T13:59:45Z<p>Jane.doe: Created page with "'''READ''' is a DCL command that reads a single record from a specified input file and assigns the record's contents to a specified local Symbol|sym..."</p>
<hr />
<div>'''READ''' is a [[DCL]] [[Command|command]] that reads a single record from a specified input [[File|file]] and assigns the record's contents to a specified local [[Symbol|symbol]] name.<br />
<br />
=Syntax=<br />
READ logical-name[:] symbol-name<br />
<br />
logical-name is the device you are reading from, [[SYS$COMMAND]], [[SYS$INPUT]], or a [[Logical Name|logical name]] defined to an open file with the [[OPEN]] command (see example below).<br />
<br />
symbol-name is a name for the symbol to read the record's contents into.<br />
<br />
==Qualifiers==<br />
* /DELETE deletes a record from an indexed file after it has been read. An indexed file must be opened with the /READ and /WRITE qualifiers in order to use the READ/DELETE command.<br />
* /END_OF_FILE=label transfers control to the location specified by the label keyword (in the current command procedure) when the end of the file is reached. When the last record in the file is read, the OpenVMS Record Management Services (RMS) returns an error condition indicating the end-of-file (EOF). If the /END_OF_FILE qualifier is specified, the command interpreter transfers control to the command line at the specified label. If the /END_OF_FILE qualifier is not specified, control is given to the error label specified with the /ERROR qualifier when the end of the file is reached. If neither the /ERROR nor the /END_OF_FILE qualifier is specified, then the current ON condition action is taken.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to label END when the end of file is reached.<br />
<br />
* /ERROR=label transfers control to the location specified by the label keyword (in the current command procedure) when a read error occurs. If no error routine is specified and an error occurs during the reading of the file, the current ON condition action is taken. Overrides any [[ON]] condition action specified. If an error occurs and the target label is successfully given control, the reserved global symbol $STATUS retains the error code.<br />
<br />
$ OPEN/READ FILE FILE.LIS<br />
$LOOP:<br />
$ READ/END_OF_FILE=END /ERROR=ERROR FILE LINE<br />
...<br />
$ GOTO LOOP<br />
$END:<br />
$ WRITE SYS$OUTPUT "Finished"<br />
$ CLOSE FILE<br />
$ EXIT 0<br />
$ERROR:<br />
$ WRITE SYS$OUTPUT "Oops"<br />
$ CLOSE FILE<br />
$ EXIT 1<br />
<br />
In the example above, /END_OF_FILE is used to branch to label END when the end of file is reached and /ERROR is used to branch to label ERROR when an error occurs.<br />
<br />
* /INDEX=n specifies the index (n) to be used to look up keys when reading an indexed file. If you do not specify the /INDEX qualifier, the most recent /INDEX qualifier value is used. If a previous value was not specified, the primary index is used (/INDEX=0).<br />
* /KEY=string reads a record with the key that matches the specified character string. Binary and integer keys are not allowed. This qualifier, when used together with the /INDEX qualifier, allows you random access to indexed files. Key matches are made by comparing the characters in the /KEY string to characters in the record key. To read records at random in an indexed file, you must specify the /KEY qualifier. Once a record is read randomly, all subsequent reads without the /KEY qualifier access records in the indexed file sequentially.<br />
*/MATCH=option specifies the key match algorithm to be used when searching for matching keys. Specify one of the following options:<br />
<br />
EQ Selects keys equal to the match value (default).<br />
GE Selects keys greater than or equal to the match value.<br />
GT Selects keys greater than the match value.<br />
LE Selects keys less than or equal to the match value.<br />
LT Selects keys less than the match value.<br />
<br />
If you are reading indexed files and you do not use the /MATCH qualifier, the default is /MATCH=EQ.<br />
* /NOLOCK specifies that the record to be read not be locked and enables a record to be read that has been locked by other accessors. By default, records are locked as they are read and unlocked on the next I/O operation on the file.<br />
*/PROMPT=string specifies an alternate prompt string to be displayed when reading from the terminal. The default prompt string is DATA:.<br />
<br />
$ READ SYS$COMMAND LINE /PROMPT="Enter data:"<br />
Enter data:<br />
<br />
In the example above, READ SYS$COMMAND is used to obtain data from the terminal. Whatever the user enters at the "Enter data:" prompt, will be saved as the value of the LINE symbol (case sensitive).<br />
<br />
*/TIME_OUT=n specifies the number of seconds after which the READ command is terminated if no input is received. If you enter the /TIME_OUT qualifier, you must specify a value from 0 to 255. The default is /NOTIME_OUT. If you enter both the /ERROR=label and /TIME_OUT qualifiers, and the time limit expires, the error branch is taken.<br />
* /WAIT sets RAB$V_WAT to make a process wait for a record in a file. Can be used in combination with /TIME_OUT to restrict how long the process should wait before timing out upon failure to find the record.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=X86_Porting_Considerations&diff=2640X86 Porting Considerations2023-11-22T10:33:27Z<p>Jane.doe: </p>
<hr />
<div>'''x86 Porting Considerations''' are things that application developers are advised to consider when porting an application to x86. This is a community-maintained list; it should not be considered a full list of architectural differences or an official porting document. Although [[VMS Software]] maintains the wiki and may make changes to this document, it assumes no responsibility for any errors or omissions.<br />
<br />
=General Porting Considerations=<br />
<br />
* Machine instructions specific to certain architectures. <br />
* Assumptions on the number of registers. <br />
* Code that relies on the VAX, Alpha, or IA64 calling standards. <br />
* Code that is conditionalized or includes logic that assumes it is running on a certain architecture (see examples in the [https://docs.vmssoftware.com/vsi-openvms-porting-applications-from-vsi-openvms-alpha-to-vsi-openvms-industry-standard-64-for-integrity-servers/#sect_4.8.1 VSI OpenVMS Porting Applications from VSI OpenVMS Alpha to VSI OpenVMS Industry Standard 64 for Integrity Servers]). <br />
* Code that depends on a different architecture's internal data structures. <br />
* Code that references terminal drivers that do not use the call interface. <br />
* Code that contains user-written threading. <br />
* Code that uses nonstandard or undocumented code practices or interfaces. <br />
* Code that contains unaligned data. <br />
* Code that uses privileged interfaces or operates at inner access modes. <br />
<br />
=Architectural and Related Differences= <br />
<br />
* Logical names that point to the location of shareable and loadable images are different: X86$LIBRARY for x86-64, IA64$LIBRARY for I64, ALPHA$LIBRARY for Alpha, and SYS$LIBRARY for VAX links; X86$LOADABLE_IMAGES on x86-64 systems, IA64$LOADABLE_IMAGES on I64 systems, or ALPHA$LOADABLE_IMAGES on Alpha systems respectively. <br />
* An x86-64 symbol vector entry is a pair of quadwords, An I64 symbol vector entry is a single quadword. <br />
* For x86-64 images, a function symbol's value is always a code address. There is no GP and no short data segment. For x86-64 images, the entry in the symbol vector with the index value of 1 contains the values 00002080 and 80000020. <br />
* Alignment on the default target page size, which is 8 KB for x86-64 and 64 KB for I64 linking. You can override this default by specifying the /BPAGE qualifier. <br />
* Sections Embedded in Code Segments (x86-64 only) – see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#d0e5033 Linker Manual]. <br />
* Procedure Linkage Table (PLT) Import Stubs (x86-64 only) – see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#d0e5043 Linker Manual]. <br />
* On x86-64, all segments within a shared library must have the same positions relative to each other that they were given by the linker. The image activator is free to load segments in a shareable image independently of each other. To allow segments to be loaded independently, VMS compilers generate code that uses indirect addressing. This way, the only segments whose relative positions have to be maintained are the code segment, the unwind segment, and the Global Offset Table segment. The linker flags those segments. A segment which requires the linker-given position to the preceding segment is flagged as "Fixed Offset" (Fof). In an image with code segments in multiple clusters, each cluster will have its own unwind segment and Global Offset Table so that their relationship can be maintained. The image activator and the install utility maintain the relative positions of these segments. <br />
* The x86-64 linker places code segments in the P2 region by default and uses the default page size of 2000 hexadecimal. The /SEGMENT=CODE=P0 option can be specified to place code segments in the P0 region. Non-code segments (without the ALLOC_64BIT attribute specified) are placed in the P0 region by default. The I64 linker places segments in the P0 region by default and uses the default page size of 10000 hexadecimal. The /SEGMENT=CODE=P2 option can be specified to place segments in the P2 region. On x86-64 systems, the first P0 segment is placed at 2000 hexadecimal. On I64 systems, the first P0 segment is placed at 10000 hexadecimal, leaving the first page unused as a guard page. <br />
* For the I64 symbol vector, you can set or clear the SHORT attribute. For the x86-64 symbol vector, setting or clearing the SHORT attribute is ignored. <br />
* On I64, to move all code into P2 space, you can use the /SEGMENT_ATTRIBUTE=CODE=P2 command qualifier. On x86, to move all code into P0 space, you can use the /SEGMENT_ATTRIBUTE=CODE=P0 command qualifier. Please note, that if you use clusters in the same link command (with linker options) and if EXE sections are put on specific clusters, setting ALLOC_64BIT does not change the per cluster segment creation. You then will see more than one executable segment with base addresses in P2 space. <br />
* Some segments created by linkers on IA64 and x86-68 are different (see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#GOT_SEGM Linker manual] for more information): <br />
** Global Offset Table segments (x86-64 only) <br />
** Unwind segments (I64 only) <br />
** Short data segments (I64 only) <br />
** Signature segments (I64 only) <br />
** Dynamic segments <br />
* On x86-64 systems, when an executable image calls a function in a shareable image, the call goes through one or two linker-generated code stubs. <br />
* On I64 systems, at run-time, when the image activator maps the shareable image into memory, it calculates the actual locations of the routines and relocatable data within the image and stores these values in its symbol vector. The image activator then fixes up the references to these symbols in the executable image. <br />
* Check the format of the [[LINK]] command; not all qualifiers are available for x86. Default values can also be different: for instance, the default value of the page size qualifier is 8 KB for x86 and 64 KB for IA64. The default value in x86 is /THREAD, which may not be appropriate for older architectures. <br />
* For I64 systems, a hardware extension is used as described in the Intel Itanium Processor-specific Application Binary Interface. For x86-64 systems, a hardware extension is used as described in the System V Application Binary Interface, AMD64 Architecture Processor Supplement. <br />
* When porting an application from IA64 to x86-64, be aware that the image layout may change in an incompatible way – although the compile and link commands/options did not change. This is an architectural difference. <br />
* On IA64, the compiler may generate short data, which is accessed in an efficient way. The IA64 linker always collects short data to the DEFAULT CLUSTER, no matter where the object module that defines this short data is collected. That is, in a partially protected shareable image, an object module may be collected into a protected linker cluster, but its short data may be collected into a unprotected cluster, and so it is not protected. User-mode code in the shareable image can write to it. On x86-64, there is no short data. All data defined in an object module will go where the module goes (except the defining PSECT, which is moved with an explicit COLLECT option). That is, on x86-64, for partially protected shareable images, all data defined by an object module which is collected into a protected linker cluster will be protected. User-mode code in the shareable image can not write to it. <br />
* VSI recommends that any privileged image linked /SYSEXE should be relinked for the V9.2 or subsequent releases because data structures and interfaces are subject to change for each new version. <br />
* Currently, the x86-64 cross compilers set the debug language to C by default. This means that when the debugger regains control, the language is set to C, even if the module being debugged was written in another language. The way to work around this problem is simply to use the SET LANGUAGE command to set the default language to that which is being debugged. <br />
* User-written x86-assembler code must follow the VSI OpenVMS calling standard (see the [https://docs.vmssoftware.com/vsi-openvms-calling-standard/#X86_64_CONVENTIONS_CH VSI OpenVMS Calling Standard manual]) to provide exception handling information that is used by the exception handling mechanism to find a handler in one of the callers of the assembler module. Without that information, exception handling can only call the last chance handler, which means the application will likely not be able to handle the exception. <br />
* Review the CRTL manual for CRTL changes. For example, the interface for the function isatty has been modified. Previously, in case of an error, the function returned -1. This is not compatible with the POSIX 1003.1 standard. This leads to errors that are hard to find. With this release, in case of an error, the function returns 0 and stores the error in errno. If your code assumes a return value of 0, this means that the fd is not a tty. If your code assumes a return value of -1, this means an error, you will need to change the code. <br />
* The implementation of variable argument lists on x86-64 is different than on Integrity and Alpha and may require source code changes, depending on how the lists are used.<br />
<br />
=See also=<br />
* [https://vmssoftware.com/docs/VSI_CALLING_STD.pdf VSI Calling Standard]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=X86_Porting_Considerations&diff=2639X86 Porting Considerations2023-11-15T14:01:50Z<p>Jane.doe: </p>
<hr />
<div>'''x86 Porting Considerations''' are things that application developers are advised to consider when porting an application to x86. This is a community-maintained list; it should not be considered a full list of architectural differences or an official porting document. Although [[VMS Software]] maintains the wiki and may make changes to this document, it assumes no responsibility for any errors or omissions.<br />
<br />
=General Porting Considerations=<br />
<br />
* Machine instructions specific to certain architectures. <br />
* Assumptions on the number of registers. <br />
* Code that relies on the VAX, Alpha, or IA64 calling standards. <br />
* Code that is conditionalized or includes logic that assumes it is running on a certain architecture (see examples in the [https://docs.vmssoftware.com/vsi-openvms-porting-applications-from-vsi-openvms-alpha-to-vsi-openvms-industry-standard-64-for-integrity-servers/#sect_4.8.1 VSI OpenVMS Porting Applications from VSI OpenVMS Alpha to VSI OpenVMS Industry Standard 64 for Integrity Servers]). <br />
* Code that depends on a different architecture's internal data structures. <br />
* Code that references terminal drivers that do not use the call interface. <br />
* Code that contains user-written threading. <br />
* Code that uses nonstandard or undocumented code practices or interfaces. <br />
* Code that contains unaligned data. <br />
* Code that uses privileged interfaces or operates at inner access modes. <br />
<br />
=Architectural and Related Differences= <br />
<br />
* Logical names that point to the location of shareable and loadable images are different: X86$LIBRARY for x86-64, IA64$LIBRARY for I64, ALPHA$LIBRARY for Alpha, and SYS$LIBRARY for VAX links; X86$LOADABLE_IMAGES on x86-64 systems, IA64$LOADABLE_IMAGES on I64 systems, or ALPHA$LOADABLE_IMAGES on Alpha systems respectively. <br />
* An x86-64 symbol vector entry is a pair of quadwords, An I64 symbol vector entry is a single quadword. <br />
* For x86-64 images, a function symbol's value is always a code address. There is no GP and no short data segment. For x86-64 images, the entry in the symbol vector with the index value of 1 contains the values 00002080 and 80000020. <br />
* Alignment on the default target page size, which is 8 KB for x86-64 and 64 KB for I64 linking. You can override this default by specifying the /BPAGE qualifier. <br />
* Sections Embedded in Code Segments (x86-64 only) – see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#d0e5033 Linker Manual]. <br />
* Procedure Linkage Table (PLT) Import Stubs (x86-64 only) – see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#d0e5043 Linker Manual]. <br />
* On x86-64, all segments within a shared library must have the same positions relative to each other that they were given by the linker. The image activator is free to load segments in a shareable image independently of each other. To allow segments to be loaded independently, VMS compilers generate code that uses indirect addressing. This way, the only segments whose relative positions have to be maintained are the code segment, the unwind segment, and the Global Offset Table segment. The linker flags those segments. A segment which requires the linker-given position to the preceding segment is flagged as "Fixed Offset" (Fof). In an image with code segments in multiple clusters, each cluster will have its own unwind segment and Global Offset Table so that their relationship can be maintained. The image activator and the install utility maintain the relative positions of these segments. <br />
* The x86-64 linker places code segments in the P2 region by default and uses the default page size of 2000 hexadecimal. The /SEGMENT=CODE=P0 option can be specified to place code segments in the P0 region. Non-code segments (without the ALLOC_64BIT attribute specified) are placed in the P0 region by default. The I64 linker places segments in the P0 region by default and uses the default page size of 10000 hexadecimal. The /SEGMENT=CODE=P2 option can be specified to place segments in the P2 region. On x86-64 systems, the first P0 segment is placed at 2000 hexadecimal. On I64 systems, the first P0 segment is placed at 10000 hexadecimal, leaving the first page unused as a guard page. <br />
* For the I64 symbol vector, you can set or clear the SHORT attribute. For the x86-64 symbol vector, setting or clearing the SHORT attribute is ignored. <br />
* On I64, to move all code into P2 space, you can use the /SEGMENT_ATTRIBUTE=CODE=P2 command qualifier. On x86, to move all code into P0 space, you can use the /SEGMENT_ATTRIBUTE=CODE=P0 command qualifier. Please note, that if you use clusters in the same link command (with linker options) and if EXE sections are put on specific clusters, setting ALLOC_64BIT does not change the per cluster segment creation. You then will see more than one executable segment with base addresses in P2 space. <br />
* Some segments created by linkers on IA64 and x86-68 are different (see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#GOT_SEGM Linker manual] for more information): <br />
** Global Offset Table segments (x86-64 only) <br />
** Unwind segments (I64 only) <br />
** Short data segments (I64 only) <br />
** Signature segments (I64 only) <br />
** Dynamic segments <br />
* On x86-64 systems, when an executable image calls a function in a shareable image, the call goes through one or two linker-generated code stubs. <br />
* On I64 systems, at run-time, when the image activator maps the shareable image into memory, it calculates the actual locations of the routines and relocatable data within the image and stores these values in its symbol vector. The image activator then fixes up the references to these symbols in the executable image. <br />
* Check the format of the [[LINK]] command; not all qualifiers are available for x86. Default values can also be different: for instance, the default value of the page size qualifier is 8 KB for x86 and 64 KB for IA64. The default value in x86 is /THREAD, which may not be appropriate for older architectures. <br />
* For I64 systems, a hardware extension is used as described in the Intel Itanium Processor-specific Application Binary Interface. For x86-64 systems, a hardware extension is used as described in the System V Application Binary Interface, AMD64 Architecture Processor Supplement. <br />
* When porting an application from IA64 to x86-64, be aware that the image layout may change in an incompatible way – although the compile and link commands/options did not change. This is an architectural difference. <br />
* On IA64, the compiler may generate short data, which is accessed in an efficient way. The IA64 linker always collects short data to the DEFAULT CLUSTER, no matter where the object module that defines this short data is collected. That is, in a partially protected shareable image, an object module may be collected into a protected linker cluster, but its short data may be collected into a unprotected cluster, and so it is not protected. User-mode code in the shareable image can write to it. On x86-64, there is no short data. All data defined in an object module will go where the module goes (except the defining PSECT, which is moved with an explicit COLLECT option). That is, on x86-64, for partially protected shareable images, all data defined by an object module which is collected into a protected linker cluster will be protected. User-mode code in the shareable image can not write to it. <br />
* VSI recommends that any privileged image linked /SYSEXE should be relinked for the V9.2 or subsequent releases because data structures and interfaces are subject to change for each new version. <br />
* Currently, the x86-64 cross compilers set the debug language to C by default. This means that when the debugger regains control, the language is set to C, even if the module being debugged was written in another language. The way to work around this problem is simply to use the SET LANGUAGE command to set the default language to that which is being debugged. <br />
* User-written x86-assembler code must follow the VSI OpenVMS calling standard (see the [https://docs.vmssoftware.com/vsi-openvms-calling-standard/#X86_64_CONVENTIONS_CH VSI OpenVMS Calling Standard manual]) to provide exception handling information that is used by the exception handling mechanism to find a handler in one of the callers of the assembler module. Without that information, exception handling can only call the last chance handler, which means the application will likely not be able to handle the exception. <br />
* Review the CRTL manual for CRTL changes. For example, the interface for the function isatty has been modified. Previously, in case of an error, the function returned -1. This is not compatible with the POSIX 1003.1 standard. This leads to errors that are hard to find. With this release, in case of an error, the function returns 0 and stores the error in errno. If your code assumes a return value of 0, this means that the fd is not a tty. If your code assumes a return value of -1, this means an error, you will need to change the code. <br />
* The implementation of variable argument lists on x86-64 is different than on Integrity and Alpha and may require source code changes, depending on how the lists are used.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=X86_Porting_Considerations&diff=2638X86 Porting Considerations2023-11-15T13:57:33Z<p>Jane.doe: Created page with "'''x86 Porting Considerations''' are things that application developers are advised to consider when porting an application to x86. This is a community-maintained list; it sho..."</p>
<hr />
<div>'''x86 Porting Considerations''' are things that application developers are advised to consider when porting an application to x86. This is a community-maintained list; it should not be considered a full list of architectural differences or an official porting document. Although [[VMS Software]] maintains the wiki and may make changes to this document, it assumes no responsibility for any errors or omissions.<br />
<br />
=General Porting Considerations=<br />
<br />
* Machine instructions specific to certain architectures. <br />
* Assumptions on the number of registers. <br />
* Code that relies on the VAX, Alpha, or IA64 calling standards. <br />
* Code that is conditionalized or includes logic that assumes it is running on a certain architecture (see examples in the [https://docs.vmssoftware.com/vsi-openvms-porting-applications-from-vsi-openvms-alpha-to-vsi-openvms-industry-standard-64-for-integrity-servers/#sect_4.8.1 VSI OpenVMS Porting Applications from VSI OpenVMS Alpha to VSI OpenVMS Industry Standard 64 for Integrity Servers]). <br />
* Code that depends on a different architecture's internal data structures. <br />
* Code that references terminal drivers that do not use the call interface. <br />
* Code that contains user-written threading. <br />
* Code that uses nonstandard or undocumented code practices or interfaces. <br />
* Code that contains unaligned data. <br />
* Code that uses privileged interfaces or operates at inner access modes. <br />
<br />
=Architectural and Related Differences= <br />
<br />
* Logical names that point to the location of shareable and loadable images are different: X86$LIBRARY for x86-64, IA64$LIBRARY for I64, ALPHA$LIBRARY for Alpha, and SYS$LIBRARY for VAX links; X86$LOADABLE_IMAGES on x86-64 systems, IA64$LOADABLE_IMAGES on I64 systems, or ALPHA$LOADABLE_IMAGES on Alpha systems respectively. <br />
* An x86-64 symbol vector entry is a pair of quadwords, An I64 symbol vector entry is a single quadword. <br />
* For x86-64 images, a function symbol's value is always a code address. There is no GP and no short data segment. For x86-64 images, the entry in the symbol vector with the index value of 1 contains the values 00002080 and 80000020. <br />
* Alignment on the default target page size, which is 8 KB for x86-64 and 64 KB for I64 linking. You can override this default by specifying the /BPAGE qualifier. <br />
* Sections Embedded in Code Segments (x86-64 only) – see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#d0e5033 Linker Manual]. <br />
* Procedure Linkage Table (PLT) Import Stubs (x86-64 only) – see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#d0e5043 Linker Manual]. <br />
* On x86-64, all segments within a shared library must have the same positions relative to each other that they were given by the linker. The image activator is free to load segments in a shareable image independently of each other. To allow segments to be loaded independently, VMS compilers generate code that uses indirect addressing. This way, the only segments whose relative positions have to be maintained are the code segment, the unwind segment, and the Global Offset Table segment. The linker flags those segments. A segment which requires the linker-given position to the preceding segment is flagged as "Fixed Offset" (Fof). In an image with code segments in multiple clusters, each cluster will have its own unwind segment and Global Offset Table so that their relationship can be maintained. The image activator and the install utility maintain the relative positions of these segments. <br />
* The x86-64 linker places code segments in the P2 region by default and uses the default page size of 2000 hexadecimal. The /SEGMENT=CODE=P0 option can be specified to place code segments in the P0 region. Non-code segments (without the ALLOC_64BIT attribute specified) are placed in the P0 region by default. The I64 linker places segments in the P0 region by default and uses the default page size of 10000 hexadecimal. The /SEGMENT=CODE=P2 option can be specified to place segments in the P2 region. On x86-64 systems, the first P0 segment is placed at 2000 hexadecimal. On I64 systems, the first P0 segment is placed at 10000 hexadecimal, leaving the first page unused as a guard page. <br />
* For the I64 symbol vector, you can set or clear the SHORT attribute. For the x86-64 symbol vector, setting or clearing the SHORT attribute is ignored. <br />
* On I64, to move all code into P2 space, you can use the /SEGMENT_ATTRIBUTE=CODE=P2 command qualifier. On x86, to move all code into P0 space, you can use the /SEGMENT_ATTRIBUTE=CODE=P0 command qualifier. Please note, that if you use clusters in the same link command (with linker options) and if EXE sections are put on specific clusters, setting ALLOC_64BIT does not change the per cluster segment creation. You then will see more than one executable segment with base addresses in P2 space. <br />
* Some segments created by linkers on IA64 and x86-68 are different (see the [https://docs.vmssoftware.com/vsi-openvms-linker-utility-manual/#GOT_SEGM Linker manual] for more information): <br />
** Global Offset Table segments (x86-64 only) <br />
** Unwind segments (I64 only) <br />
** Short data segments (I64 only) <br />
** Signature segments (I64 only) <br />
** Dynamic segments <br />
* On x86-64 systems, when an executable image calls a function in a shareable image, the call goes through one or two linker-generated code stubs. <br />
* On I64 systems, at run-time, when the image activator maps the shareable image into memory, it calculates the actual locations of the routines and relocatable data within the image and stores these values in its symbol vector. The image activator then fixes up the references to these symbols in the executable image. <br />
* Check the format of the LINK command; not all qualifiers are available for x86. Default values can also be different: for instance, the default value of the page size qualifier is 8 KB for x86 and 64 KB for IA64. <br />
* For I64 systems, a hardware extension is used as described in the Intel Itanium Processor-specific Application Binary Interface. For x86-64 systems, a hardware extension is used as described in the System V Application Binary Interface, AMD64 Architecture Processor Supplement. <br />
* When porting an application from IA64 to x86-64, be aware that the image layout may change in an incompatible way – although the compile and link commands/options did not change. This is an architectural difference. <br />
* On IA64, the compiler may generate short data, which is accessed in an efficient way. The IA64 linker always collects short data to the DEFAULT CLUSTER, no matter where the object module that defines this short data is collected. That is, in a partially protected shareable image, an object module may be collected into a protected linker cluster, but its short data may be collected into a unprotected cluster, and so it is not protected. User-mode code in the shareable image can write to it. On x86-64, there is no short data. All data defined in an object module will go where the module goes (except the defining PSECT, which is moved with an explicit COLLECT option). That is, on x86-64, for partially protected shareable images, all data defined by an object module which is collected into a protected linker cluster will be protected. User-mode code in the shareable image can not write to it. <br />
* VSI recommends that any privileged image linked /SYSEXE should be relinked for the V9.2 or subsequent releases because data structures and interfaces are subject to change for each new version. <br />
* Currently, the x86-64 cross compilers set the debug language to C by default. This means that when the debugger regains control, the language is set to C, even if the module being debugged was written in another language. The way to work around this problem is simply to use the SET LANGUAGE command to set the default language to that which is being debugged. <br />
* User-written x86-assembler code must follow the VSI OpenVMS calling standard (see the [https://docs.vmssoftware.com/vsi-openvms-calling-standard/#X86_64_CONVENTIONS_CH VSI OpenVMS Calling Standard manual]) to provide exception handling information that is used by the exception handling mechanism to find a handler in one of the callers of the assembler module. Without that information, exception handling can only call the last chance handler, which means the application will likely not be able to handle the exception. <br />
* Review the CRTL manual for CRTL changes. For example, the interface for the function isatty has been modified. Previously, in case of an error, the function returned -1. This is not compatible with the POSIX 1003.1 standard. This leads to errors that are hard to find. With this release, in case of an error, the function returns 0 and stores the error in errno. If your code assumes a return value of 0, this means that the fd is not a tty. If your code assumes a return value of -1, this means an error, you will need to change the code. <br />
* The implementation of variable argument lists on x86-64 is different than on Integrity and Alpha and may require source code changes, depending on how the lists are used.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=X86&diff=2637X862023-11-15T13:45:14Z<p>Jane.doe: </p>
<hr />
<div>The '''x86''' is an instruction set architecture developed by [[Intel]].<br />
<br />
==Useful links==<br />
* [[x86 Porting Considerations]]<br />
<br />
[[Category:Architectures]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Main_Page&diff=2636Main Page2023-11-15T13:44:33Z<p>Jane.doe: </p>
<hr />
<div><!-- This is the box on the left. --><br />
{| style="float:left;vertical-align:top;background-color:white;"<br />
|<br />
|-<br />
|<br />
{| class="wikitable" <br />
! style="text-align:center; background-color:#2378FF;color:white;height:50px;width:1200px;" | <big>Introduction</big><br />
|-<br />
| style="text-align:left;height:50px;width:1200px;"| <big>About this Wiki</big><br />
<br />
VSI OpenVMS wiki is the world's biggest encyclopedia entirely dedicated to the OpenVMS operating system. <br />
The purpose of the project is to consolidate and organize information about this operating system and create an easily searcheable reference base to answer any questions about it. Ultimately, this encyclopedia should contain basic information on common features of OpenVMS and operations frequently performed by programmers and system managers using this system as well as links to the current documentation. The wiki model used to create this encyclopedia allows any registered user to write an article or suggest changes to an existing article, thus maximizing the number of contributions and maintaining the integrity and neutrality of the data.<br />
To date, our wiki has {{NUMBEROFARTICLES}} articles. View the full list [[Special:AllPages|here]] or use the search box in the top right corner to search this wiki. Or, if you are feeling adventurous, visit [[Special:Random|a random page]].<br />
<br />
<big>About OpenVMS</big><br />
<br />
OpenVMS is an operating system created in 1977 by the Digital Equipment Corporation and still widely used by large companies in the military, healthcare, banking, telecommunications and other industries. It is primarily known for its security and unrivaled clustering capabilities. It currently supports VAX, Alpha, and Itanium architectures and is working on a port to x86.<br />
|}<br />
|-<br />
|<br />
{| class="wikitable"<br />
|-<br />
! scope='col'; style="text-align:center;height:50px;width:1200px;background-color:#2378FF;color:white;" | <big>Categories</big><br />
|-<br />
| style=text-align:left;height:50px;width:1200px;" | <br />
* [[:Category:Architectures|Architectures]]<br />
* [[:Category:Lexical Functions|Lexical Functions]]<br />
* [[:Category:Security|Security]]<br />
* [[:Category:User Management|User Management]]<br />
* [[:Category:Volume Management|Volume Management]]<br />
* [[:Category:System Files|System Files]]<br />
* [[:Category:Startup Command Procedures|Startup Command Procedures]]<br />
* [[:Category:System Services|System Services]]<br />
* [[:Category:Privileges|Privileges]]<br />
* [[:Category:System Parameters|System Parameters]]<br />
* [[:Category:Utilities|Utilities]]<br />
* [[:Category:Process States|Process States]]<br />
* [[:Category:Freeware|Freeware]]<br />
* [[:Category:DCL Commands|DCL Commands]]<br />
* [[:Category:VMS IDE|VMS IDE]]<br />
* [[:Category:Opensource|Opensource Software]]<br />
[[Special:AllPages|Browse all articles]]<br />
|}<br />
|}<br />
<!-- This is the box on the right. --><br />
{| style="float:right;vertical-align:top;background-color:white;"<br />
|<br />
{| class="wikitable"<br />
! scope='col' style="height:50px; width:400px; text-align:center;background-color:#2378FF;color:white;" | <big>Article of the day</big><br />
|-<br />
| style="height:50px; width:400px; text-align:left;" | <big>'''Escape Sequence'''</big><br />
An '''escape sequence''' is a combination of characters that signifies a command for the terminal rather than a literal combination of characters. In terminals that respond to ANSI character sequences, the escape character has the ASCII value of hexadecimal 1B, octal 33, or decimal 27. <br />
[[Escape Sequence|Read more]]<br />
|}<br />
|-<br />
|<br />
{| class="wikitable"<br />
! colpan="3" style="height:50px; width:400px; text-align:center;background-color:#2378FF;color:white;" | <big>Resources</big><br />
|-<br />
| style="height:50px; width:400px; text-align:left;" |<br />
* [https://en.wikipedia.org/wiki/Help:Wikitext Wiki guidelines]<br />
* [https://vmssoftware.com/ VMS Software Inc.]<br />
* [https://docs.vmssoftware.com OpenVMS Documentation]<br />
* [[Useful Links]]<br />
* [[:Category:VMS IDE|VMS IDE]]<br />
|}<br />
|-<br />
|<br />
{| class="wikitable"<br />
! colpan="3" style="height:50px; width:400px; text-align:center;background-color:#2378FF;color:white;" | <big>Did you know...</big><br />
|-<br />
| style="height:50px; width:400px; text-align:left;" |<br />
* that you could use angle brackets (<>) instead of square brackets ([]) in DCL [[File specification|directory specifications]]?<br />
* that the maximum value of the [[LGI parameters|LGI_HID_TIM]] parameter which specifies how long OpenVMS does not let intruders log in to the system is 1261440000 seconds, or 40 years?<br />
* that a [[Volume Label|label]] can contain a maximum of 255 characters?<br />
|}<br />
|}<br />
<br />
<br />
{| class="wikitable" style="background-color:white;float:bottom;style=height:100px;width:1680px;"<br />
! scope="col" colspan="3" style="height:50px; width:1680px; text-align:center;" | <big>You can help</big><br />
|-<br />
| colspan="3" style="height:50px; width:1680px;text-align:left; |Please help this wiki become the most informative and reliable source of information on OpenVMS! <br />
To help the project, you can:<br />
* [[How to write an article|write new articles]]<br />
* [[How to edit an article|expand and edit existing articles]]<br />
* add links to dead end pages<br />
* add pages to categories<br />
* translate this wiki to your language and more.<br />
To get editing access to this wiki, log in by clicking the button above. If you don't have an account or see a registration link, please contact training@vmssoftware.com for a registration.<br />
|}<br />
<br />
{| style="background-color:white;float:bottom;style=height:100px;width:1680px;"<br />
|<br />
{| class="wikitable"<br />
! scope='col' style="height:50px; width:400px; text-align:center;" | <big>Write</big><br />
|-<br />
| style="height:50px; width:400px; text-align:left;" | You can help the project by writing the following articles:<br />
* [[INSTALL]] utility<br />
* [[SDA]]<br />
* [[DEC]]<br />
* [[SCSI]]<br />
* [[DECnet Phase IV]]<br />
[[Special:WantedPages|See all wanted pages]]<br />
|}<br />
|<br />
{| class="wikitable"<br />
! scope='col' style="height:50px; width:400px; text-align:center;" | <big>Add</big><br />
|-<br />
| style="height:50px; width:400px; text-align:left;" | You can help the project by expanding the following articles:<br />
* [[INDEXF.SYS]]<br />
* [[SETPRV]]<br />
* [[ADDUSER.COM]]<br />
* [[BADLOG.SYS]]<br />
* [[BADBLK.SYS]]<br />
[[Special:ShortPages|See all short pages]]<br />
|}<br />
|<br />
{| class="wikitable"<br />
! scope='col' style="height:50px; width:400px; text-align:center;" | <big>Edit</big><br />
|-<br />
| style="height:50px; width:400px; text-align:left;" | You can help the project by editing the following articles:<br />
* [[Audit ACE]]<br />
* [[Identifier ACE]]<br />
* [[ACE]]<br />
* [[BADBLK.SYS]]<br />
* [[Default directory]]<br />
[[Special:FewestRevisions|See all nonrevised pages]]<br />
|}<br />
|<br />
{| class="wikitable"<br />
! scope='col' style="height:50px; width:400px; text-align:center;" | <big>Categorize</big><br />
|-<br />
| style="height:50px; width:400px; text-align:left;" | You can help the project by categorizing the following articles:<br />
* [[$GETQUI output item codes]]<br />
* [[ACE]]<br />
* [[ACL]]<br />
* [[ACP DATACHECK]]<br />
* [[ACP SWAPFLGS]]<br />
[[Special:UncategorizedPages|See all uncategorized pages]]<br />
|}<br />
|}</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Digital_Test_Manager&diff=2634Digital Test Manager2023-11-13T16:08:12Z<p>Jane.doe: </p>
<hr />
<div>'''Digital Test Manager (DTM)''' is a [[layered product]] distributed by [[VMS Software]], part of [[DECset]], that can be used to run, review, and store software regression tests and test results. DTM organizes and automates the software regression testing process.<br />
<br />
=Environments=<br />
<br />
DTM supports three testing environments:<br />
* Noninteractive (command procedure)<br />
* Interactive terminal (recorded input)<br />
* Interactive DECwindows<br />
<br />
=Components=<br />
The three basic components of DTM are:<br />
* A '''DTM library''' - a data structure that DTM uses to store the information it needs to manage a test system in an OpenVMS directory.<br />
* A '''DTM test''' - a collection of fields that contains the information that VSI Digital Test Manager needs to run a particular test. A test description requires a template file and can have other optionally specified test-related entities. A '''template file''' is an OpenVMS command procedure that executes a noninteractive test, or a session file containing a recorded interactive terminal or DECwindows session. A '''benchmark file''' contains the expected output for the test's execution.<br />
* A '''collection''' - a set of tests selected for execution. You can execute a test only in the context of a collection. You can select tests for inclusion in a collection by test name or groups.<br />
<br />
==Tests==<br />
<br />
DTM tests are characterized by test descriptions. A '''DTM test description''' consists of the following elements:<br />
* '''Test name''': identifies the test description.<br />
* '''Test prologue''': identifies a DCL command file that runs immediately before the template file. You use a prologue file to set up any special environment that the test requires. Output from a prologue file does not appear in the test results.<br />
* '''Test epilogue''': identifies a DCL command file that runs immediately after the template file. You use an epilogue file to clean up operations, or to apply user-created filters to the result file. Unlike the prologue file, the epilogue file can directly alter the test results.<br />
* '''Template''': identifies a DCL command file for an on interactive test, or the session file for an interactive terminal or DECwindows test. This field defaults to test-name.SESSION for an interactive terminal or DECwindows test and test-name.COM for noninteractive tests.<br />
* '''Benchmark''': identifies a file that contains the expected test output. It is the standard against which VSI Digital Test Manager compares the results of a test run. This field defaults to test-name.BMK.<br />
* '''Variables''': identifies the variables and associated values used with the template, prologue, or epilogue files for this test.<br />
* '''Groups''': identifies the groups to which the test description belongs.<br />
* '''Test type''': identifies the test as either an interactive terminal, DECwindows, or noninteractive test.<br />
* '''Command''': Identifies a DCL command to be spawned when a DECwindows test is recorded or executed. This command can be used to invoke applications for inclusion in the test.<br />
* '''Comparison type''': identifies the comparison type: screen, record, or character.<br />
* '''Filters''': identifies one or more filters to remove run-timedependent information from the result file.<br />
* '''Remark''': identifies a comment that you add to the history.<br />
<br />
==Collections==<br />
<br />
A '''collection''' is a snapshot of specified test descriptions and the VSI Digital Test Manager library as they exist at the time you create the collection. You must organize tests into collections before you can execute them to produce result files for comparison.<br />
<br />
When you execute a collection, VSI Digital Test Manager sets up the test environment and executes all the tests in the collection (this can be done in batch mode). Each test in a collection generates a separate result file. The result file contains the output generated by the template file. The result file is used for comparison against a test's benchmark file.<br />
<br />
When you execute a collection, VSI Digital Test Manager compares the test results with the benchmark file for each test that has been run. If the comparison is unsuccessful (differences are detected), VSI Digital Test Manager creates a difference file. If the comparison is successful (no differences are detected), the result file is deleted and no difference file is created.<br />
<br />
=Instructions=<br />
Before any DTM tests can be created, a DTM library needs to be created first. To do that, you create an empty directory and then run the CREATE LIBRARY command on this directory. If you already have a library, you can execute SET LIBRARY. When the library is set, it will be pointed to by the DTM$LIB logical.<br />
<br />
Tests are created with a CREATE TEST_DESCRIPTION command. You can specify an existing template (.COM file) and benchmark (.BMK) file or RECORD an interactive test. To execute the tests, add them to a collection with CREATE COLLECTION, and then RUN that collection.<br />
<br />
You can then review the differences using the Review subsystem, which gives you access to the results obtained by executing the collection, as well as other information about the collection. It also enables you to invoke the Performance and Coverage Analyzer (PCA) to gather performance and coverage data for the test. <br />
You must execute and compare a collection before it can be reviewed.<br />
<br />
You can specify an initialization file to be executed when you run DTM either by defining the logical name DTM$INIT to it or with the /INIT qualifier when you run DTM.<br />
<br />
You can execute DTM commands from a file using @filespec inside of DTM.<br />
<br />
<br />
==See also==<br />
* [https://vmssoftware.com/docs/VSI_DTM_GD.PDF VSI DECset for OpenVMS Guide to VSI Digital Test Manager]<br />
<br />
[[Category:VSI Products]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Concealed_Logical_Name&diff=2633Concealed Logical Name2023-11-06T14:28:23Z<p>Jane.doe: </p>
<hr />
<div>A '''concealed logical''' is a type of [[Logical Name|logical name]] that conceals a part of the directory specification. The logical can then be used like a disk name. It is used to shorten and simplify file specifications as well as hide the directory structure from unprivileged users. In the following example, a concealed logical SUB is defined and used. Note the period at the end of the directory specification:<br />
<br />
<nowiki><br />
SMAN43$ define /sys /translation=concealed sub dsa1:[jdoe.sub.]<br />
SMAN43$ sh log sub<br />
"SUB" = "DSA1:[JDOE.SUB.]" (LNM$SYSTEM_TABLE)<br />
<br />
SMAN43$ dir sub:[000000]<br />
<br />
Directory SUB:[000000]<br />
<br />
B.LIS;1 ORIGINAL.LIS;1 SUB2.DIR;1<br />
<br />
Total of 3 files.<br />
</nowiki><br />
<br />
Note that a concealed logical behaves like a disk; you have to use [000000] to go to the concealed directory itself. For example, when default is set to a concealed logical, it replaces the disk part of the specification:<br />
<br />
<nowiki><br />
SMAN43$ sh def<br />
DSA1:[JDOE]<br />
<br />
SMAN43$ dir sub<br />
%DIRECT-E-OPENIN, error opening SUB:[JDOE]*.*;* as input<br />
-RMS-E-DNF, directory not found<br />
-SYSTEM-W-NOSUCHFILE, no such file<br />
<br />
SMAN43$ set def sub<br />
SMAN43$ sh def<br />
SUB:[JDOE]<br />
%DCL-I-INVDEF, SUB:[JDOE] does not exist<br />
<br />
</nowiki><br />
<br />
[[Category:Logical Name]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=CC&diff=2632CC2023-09-19T12:32:18Z<p>Jane.doe: </p>
<hr />
<div>'''CC''' is the command to invoke the [[C Compiler]]. <br />
<br />
See the syntax and qualifiers [[C Compiler|here]].<br />
<br />
If it is not available, it is possible that the C Compiler is not installed (check that by running PRODUCT SHOW PRODUCT).<br />
<br />
[[Category: DCL Commands]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=CC&diff=2631CC2023-09-19T12:30:50Z<p>Jane.doe: </p>
<hr />
<div>'''CC''' is the command to invoke the [[C Compiler]].<br />
<br />
[[Category: DCL Commands]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=C_Compiler&diff=2630C Compiler2023-09-19T12:30:25Z<p>Jane.doe: </p>
<hr />
<div>The '''C Compiler''' is the software that compiles code written in C into object files.<br />
<br />
=Syntax=<br />
CC file-spec,... +library-file-spec/LIBRARY...<br />
<br />
=Qualifiers=<br />
* /ACCEPT(option[,...]) allows the compiler to accept C language syntax that it might not normally accept.<br />
<br />
{| class="wikitable"<br />
| Option<br />
| Description<br />
|-<br />
| [NO]C99_KEYWORDS<br />
| Controls whether or not the C99 Standard keywords inline and restrict (which are are in the C89 namespace for user identifiers) are accepted without double leading underscores. The spelling with two leading underscores (__inline, __restrict) is in the namespace reserved to the compiler implementation and is always recognized as a keyword regardless of this option. In /STANDARD=RELAXED mode, the default is C99_KEYWORDS. In all other compiler modes, the default is NOC99_KEYWORDS.<br />
|-<br />
| [NO]GCCINLINE<br />
| The gcc compiler implements an inline function qualifier for functions with external linkage that gives similar capabilites as the C9x extern inline feature for functions, but the usage details are somewhat different: the combination of extern and inline keywords makes an inline definition, instead of the exlusive use of the inline keyword without the extern keyword. This option controls which variation of the feature is implemented. In all compiler modes, the default is NOGCCINLINE.<br />
|-<br />
| [NO]TRIGRAPHS<br />
| Turns trigraph support on or off. In COMMON and VAXC compiler modes, trigraphs are disabled by default. In all other modes, they are enabled by default.<br />
|-<br />
| [NO]VAXC_KEYWORDS<br />
| Controls whether or not the compiler recognizes the VAX C keywords (such as "readonly") regardless of the /STANDARD mode used.<br />
|-<br />
| [NO]RESTRICT_KEYWORD<br />
| Controls whether or not the compiler recognizes the C9x standard restrict keyword regardless of the /STANDARD mode used. This only affects recognition of the spelling of the keyword as proposed for inclusion in the C9x standard. The spelling with two leading underscores, __restrict, is in the namespace reserved to the compiler implementation, and it is always recognized as a keyword regardless of this option. Note that [NO]RESTRICT_KEYWORD is a subset of [NO]C99_KEYWORDS. They have the same compiler-mode defaults.<br />
|} <br />
<br />
The default values are based upon the settings of the /STANDARD qualifier:<br />
<br />
* For /STANDARD=RELAXED the default is: /ACCEPT=(VAXC_KEYWORDS,C99_KEYWORDS,NOGCCINLINE,TRIGRAPHS)<br />
* For /STANDARD=VAXC, the default is: /ACCEPT=(VAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE,NOTRIGRAPHS)<br />
* For /STANDARD=COMMON, the default is: /ACCEPT=(NOVAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE,NOTRIGRAPHS)<br />
* For /STANDARD=C99 or /STANDARD=LATEST, the default is: /ACCEPT=(NOVAXC_KEYWORDS,C99_KEYWORDS,NOGCCINLINE,TRIGRAPHS) <br />
* In all other modes, the default is: /ACCEPT=(NOVAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE,TRIGRAPHS)<br />
<br />
* /[NO]ANALYSIS_DATA[=file-spec] controls whether the compiler generates a file of source code analysis information. The default file name is the file name of the primary source file; the default file type is .ANA. The default value is /NOANALYSIS_DATA.<br />
<br />
* /[NO]ANNOTATIONS[=(option,...)] controls whether or not the source listing file is annotated with indications of specific optimizations performed or, in some cases, not performed. These annotations can be helpful in understanding the optimization process. The default is /NOANNOTATIONS. Specifying /ANNOTATIONS with no keywords is the same as specifying /ANNOTATIONS=(ALL,NODETAIL).<br />
** ALL: Selects all annotations. This output can be quite verbose because it includes detailed output for all annotations. For more concise output for each kind of annotation, use /ANNOTATIONS=(ALL,NODETAIL), or just /ANNOTATIONS with no qualifier options.<br />
** [NO]CODE: annotates the machine-code listing with descriptions of special instructions used for prefetching, alignment, and so on. The /MACHINE_CODE qualifier must also be specified for /ANNOTATION=CODE to have any visible effect.<br />
** [NO]DETAIL: provides additional level of annotation detail, where available.<br />
** [NO]FEEDBACK: Indicates use of profile-directed feedback optimizations. Feedback optimizations are not implemented on OpenVMS systems, so this keyword has no visible effect.<br />
** [NO]INLINING: indicates where code for a called procedure was expanded inline.<br />
** [NO]LOOP_TRANSFORMS: Indicates optimizations such as loop reordering and code hoisting.<br />
** [NO]LOOP_UNROLLING: indicates where advanced loop nest optimizations have been applied to improve cache performance (unroll and jam, loop fusion, loop interchange, and so on).<br />
** [NO]PREFETCHING: indicates where special instructions were used to reduce memory latency.<br />
** [NO]SHRINKWRAPPING: indicates removal of code establishing routine context whenit is not needed.<br />
** [NO]SOFTWARE_PIPELINING: indicates where loops have been scheduled to hide functionalunit latency.<br />
** [NO]TAIL_CALLS: indicates an optimization where a call from routine A to Bcan be replaced by a jump.<br />
** [NO]TAIL_RECURSION: indicates an optimization that eliminates unnecessary routinecontext for a recursive call.<br />
** NONE: same as /NOANNOTATIONS.<br />
* /[NO]ANSI_ALIAS: directs the compiler to assume the ANSI C aliasing rules, thus giving it the freedom to generate better optimized code. The aliasing rules are explained in Section 3.3, paragraphs 20 and 25 of the ANSI C Standard. The default is /NOANSI_ALIAS for the /STANDARD=VAXC and /STANDARD=COMMON compiler modes. The default is /ANSI_ALIAS for all other modes.<br />
* /ARCHITECTURE=option: currently ignored for x86-64 systems but we expect to provide options to pass along to the LLVM code generator to select machine attributes<br />
* /ASSUME=(option[,...]): controls compiler assumptions.<br />
{| class="wikitable"<br />
! scope='col'; | Option<br />
! scope='col';| Description<br />
|-<br />
| [NO]ACCURACY_SENSITIVE<br />
| Specifies whether certain code transformations that affect floating-point operations are allowed. These changes may or<br />
may not affect the accuracy of the program's results. If you specify NOACCURACY_SENSITIVE, the compiler is free to<br />
reorder floating-point operations, based on algebraic identities (inverses, associativity, and distribution). This allows the compiler to move divide operations outside of loops, improving performance. The default, ACCURACY_SENSITIVE, directs the compiler to use only certain scalar rules for calculations. This setting can prevent some optimization.<br />
|-<br />
| [NO]ALIGNED_OBJECTS<br />
| Controls an optimization for dereferencing pointers. On OpenVMS Alpha systems, dereferencing a pointer to a longword- or quadword-aligned object is more efficient than dereferencing a pointer to a byte- or word-aligned object. Therefore, the compiler can generate more optimized code if it makes the assumption that a pointer object of an aligned pointer type does point to an aligned object. Since the compiler determines the alignment of the dereferenced object from the type of the pointer, and the program is allowed to compute a pointer that references an unaligned object (even though the pointer type indicates that it references an aligned object), the compiler must assume that the dereferenced object's alignment matches or exceeds the alignment indicated by the pointer type. The default, /ASSUME=ALIGNED_OBJECTS, allows the compiler to make such an assumption. With this assumption made, the compiler can generate more efficient code for pointer dereferences of aligned pointer types. To prevent the compiler from assuming the pointer type's alignment for objects that it points to, use the /ASSUME=NOALIGNED_OBJECTS qualifier.<br />
|-<br />
| [NO]CLEAN_PARAMETERS<br />
| Controls compiler assumptions about short-integer formal parameters. The Alpha Calling Standard requires integers less than 64 bits long that are passed by value to have their upper bits either zeroed or sign-extended to make full 64-bit values. These are referred to as clean parameters. Some old code does not follow this convention. This can cause problems if the called program assumes that the caller followed the Calling Standard by passing only clean parameters. Specifying /ASSUME=NOCLEAN_PARAMETERS allows a program to be called by old code that might pass unclean integer parameters. It directs the compiler to generate run-time code to clean the short integers so they comply with the Calling Standard. The default is /ASSUME=CLEAN_PARAMETERS.<br />
|-<br />
| [NO]EXACT_CDD_OFFSETS<br />
| Controls the alignment of Control Data Dictionary records. If /ASSUME=EXACT_CDD_OFFSETS is specified, the records input from the CDD are given the exact alignment (relative to the start of the record) specified by the CDD definition. This alignment is independent of the current compiler member-alignment setting. If /ASSUME=NOEXACT_CDD_OFFSETS is specified, the compiler may modify the offsets specified in a CDD record according to the current member-alignment setting. The default is /ASSUME=NOEXACT_CDD_OFFSETS.<br />
|-<br />
| [NO]POINTERS_TO_GLOBALS<br />
| Controls whether or not the compiler can safely assume that global variables have not had their addresses taken in code that is not visible to the current compilation. The default, /ASSUME=POINTERS_TO_GLOBALS, assumes that global variables have had their addresses taken in separately compiled modules and that, in general, any pointer dereference could be accessing the same memory as any global variable. This is often a significant barrier to optimization. The /ANSI_ALIAS qualifier allows some resolution based on data type, but /ASSUME=NOPOINTER_TO_GLOBALS provides significant additional resolution and improved optimization in many cases.<br />
|-<br />
| [NO]WEAK_VOLATILE<br />
| Affects the generation of code for assignments to objects that are less than or equal to 16 bits in size (for example: char, short) that have been declared as volatile. Specifying /ASSUME=WEAK_VOLATILE directs the compiler to generate code for volatile assignments to single bytes or words without using the load-locked store-conditional sequences that, in general, are required to assure volatile data integrity when direct byte or word memory-access instructions are not being used. This option is intended for use in special I/O hardware access situations, and should not generally be used. The default is /ASSUME=NOWEAK_VOLATILE, which uses interlocked instructions for sub-longword volatile accesses when byte or word instructions are not enabled.<br />
|-<br />
| [NO]WHOLE_PROGRAM<br />
| Asserts to the compiler that except for "well-behaved library routines," the whole program consists only of the single object module being produced by this compilation. The optimizations enabled by /ASSUME=WHOLE_PROGRAM include all those enabled by /ASSUME=NOPOINTER_TO_GLOBALS, and possibly additional optimizations as well. The default is /ASSUME=NOWHOLE_PROGRAM.<br />
|-<br />
| [NO]WRITABLE_STRING_LITERALS<br />
| Stores string constants in a writable psect. Otherwise, such constants will be placed in non-writable psect. For /STANDARD=VAXC or /STANDARD=COMMON, the default is /ASSUME=WRITABLE_STRING_LITERALS. For all other compiler modes, the default is /ASSUME=NOWRITABLE_STRING_LITERALS.<br />
|-<br />
| [NO]MATH_ERRNO<br />
| Controls whether or not intrinsic code is generated for math functions that set the errno variable. The default is /ASSUME=MATH_ERRNO, which does not allow intrinsic code for such math functions to be generated, even if /OPTIMIZE=INTRINSICS is in effect. Their prototypes and call formats, however, are still checked.<br />
|-<br />
|[NO]HEADER_TYPE_DEFAULT<br />
| Specifies whether the default file-type mechanism (.h) for header files is enabled (HEADER_TYPE_DEFAULT) or disabled (NOHEADER_TYPE_DEFAULT). The default is /ASSUME=HEADER_TYPE_DEFAULT.<br />
|} <br />
* /[NO]CHECK[=(option[,...])]: this qualifier is for use only as a debugging aid. It should not be used to build production code without carefully assessing its performance impact on the application in question for each platform on which the application runs. For example, the I64-only FP_MODE check can add significant overhead to every function in the compilation, even if the application uses little or no floating point.<br />
** /CHECK=NONE is equivalent to /NOCHECK<br />
** /CHECK=UNINITIALIZED_VARIABLES initializes all automatic variables to the value 0x7ff580057ff58005. This value is a double signaling NaN and, if used as a floating-point value in certain double operations, causes a floating-point trap if traps are enabled. Traps are not enabled if the program is compiled /FLOAT=IEEE and the /IEEE value is something other than FAST.<br />
** /CHECK=BOUNDS enables run-time checking of array bounds. Check HELP on CC for array-bounds processing rules.<br />
** /CHECK=POINTER_SIZE directs the compiler to check 32-bit pointer values to make sure they will fit in a 32-bit pointer. If such a value cannot be represented by a 32-bit pointer, the run-time code signals a range error (SS$_RANGEERR). Use /POINTER_SIZE option keywords (below) to determine the pointer-size checks you want made.<br />
* /COMMENTS: governs whether or not comments appear in preprocess output files and, if they are to appear, whether they appear themselves or are replaced by a single space.<br />
** /COMMENTS=SPACE (D) (ANSI89, RELAXED, and MIA compiler modes): specifies that a single space replaces the comment in the output file.<br />
** /NOCOMMENTS (D) (all other compiler modes)<br />
** /COMMENTS or /COMMENTS=AS_IS: Specifies that the comment appears in the output file.<br />
* /[NO]CROSS_REFERENCE: Specifies whether the compiler generates cross-references. If you specify /CROSS_REFERENCE, the compiler lists, for each variable referenced in the procedure, the line numbers of the lines on which the variable is referenced. You must use the /CROSS_REFERENCE qualifier with either the /SHOW=SYMBOLS or the /SHOW=BRIEF qualifiers. To obtain any type of listing, you must specify /LIST.<br />
* /[NO]DEBUG[=(option[,...])]: includes information in the object module for use by the OpenVMS Debugger. You can select the following options:<br />
{| class="wikitable"<br />
! scope='col'; | Option<br />
! scope='col';| Description<br />
|-<br />
| ALL<br />
| Includes all possible debugging information. On Alpha systems, /DEBUG=ALL is equivalent to /DEBUG=(TRACEBACK,SYMBOLS). On VAX systems, /DEBUG=ALL is equivalent to /DEBUG=(TRACEBACK,SYMBOLS,INLINE). Specifying /DEBUG with no options is equivalent to specifying /DEBUG=ALL. If the /DEBUG qualifier is not specified, the default is /DEBUG=(TRACEBACK,NOSYMBOLS).<br />
|-<br />
| NONE<br />
| Excludes any debugging information.<br />
|-<br />
| NOSYMBOLS<br />
| Suppresses generation of symbol table records.<br />
|-<br />
| SYMBOLS<br />
| Generates symbol table records.<br />
|-<br />
| NOTRACEBACK<br />
| Suppresses generation of traceback records.<br />
|-<br />
| TRACEBACK<br />
| Generates traceback records.<br />
|} <br />
* /DECC: The /DECC qualifier is provided for compatibility with HP C on OpenVMS VAX systems. On OpenVMS Alpha systems, CC and CC/DECC are always equivalent.<br />
* /[NO]DEFINE=(identifier[=definition][,...]) performs the same function as the #define preprocessor directive. That is, /DEFINE defines a token string or macro to be substituted for every occurrence of a given identifier in the program. DCL converts all input to uppercase unless it is enclosed in quotation marks.<br />
* /[NO]DIAGNOSTICS[=file-spec] Creates a file containing compiler diagnostic messages. The default file extension for a diagnostics file is .DIA. The diagnostics file is used with the DEC Language-Sensitive Editor (LSE). To display a diagnostics file, enter the command REVIEW/FILE=file-spec while in LSE.<br />
* /ERROR_LIMIT[=number]<br />
* /EXTERN_MODEL=option<br />
* /[NO]FIRST_INCLUDE=(file[,...])<br />
* /FLOAT=option<br />
* /GRANULARITY<br />
* /IEEE_MODE=option<br />
* /[NO]INCLUDE_DIRECTORY=(pathname[,...])<br />
* /L_DOUBLE_SIZE=option<br />
* /LIBRARY<br />
* /[NO]LINE_DIRECTIVES<br />
* /[NO]LIST[=file-spec]<br />
* /[NO]MACHINE_CODE<br />
* /[NO]MEMBER_ALIGNMENT<br />
* /[NO]MMS_DEPENDENCIES[=(option[,option])]<br />
* /NAMES=(option1,option2)<br />
* /NESTED_INCLUDE_DIRECTORY[=option]<br />
* /[NO]OBJECT[=file-spec]<br />
* /[NO]OPTIMIZE[=option]<br />
* /PDSC_MASK=option<br />
* /[NO]PLUS_LIST_OPTIMIZE<br />
* /[NO]POINTER_SIZE=option<br />
* /PRECISION={SINGLE | DOUBLE}<br />
* /[NO]PREFIX_LIBRARY_ENTRIES<br />
* /[NO]PREPROCESS_ONLY[=filename]<br />
* /[NO]PROTOTYPE[=(option[,...])]<br />
* /PSECT_MODEL=[NO]MULTILANGUAGE<br />
* /REENTRANCY=option<br />
* /REPOSITORY=option<br />
* /ROUNDING_MODE=option<br />
* /[NO]SHARE_GLOBALS<br />
* /SHOW[=(option[,...])]<br />
* /[NO]STANDARD=(option)<br />
* /[NO]UNDEFINE=(identifier[,...])<br />
* /[NO]UNSIGNED_CHAR<br />
* /[NO]VERSION<br />
* /[NO]WARNINGS[=(option[,...])]<br />
<br />
=Includes=<br />
<br />
CC /INCLUDE_DIRECTORY qualifier provides similar functionality to the -I option of the cc command on DIGITAL UNIX systems: it allows you to specify additional places to search for include files. It can be one of the following:<br />
<br />
* OpenVMS file-spec to be used as a default file-spec to RMS file services:<br />
/INCLUDE=DISK$:[directory]<br />
* UNIX style pathname in quotation marks<br />
/INCLUDE=/sys<br />
* Empty string ("")<br />
/INCLUDE=""<br />
<br />
The interpretation depends on the format of the #include directive: whether it is is quotes or angle brackets:<br />
<br />
#include "stdio.h"<br />
#include <stdio.h><br />
<br />
==Quoted includes==<br />
1. Look at the /NESTED qualifier on the CC command.<br />
* missing or /NESTED=INCLUDE: search the directory containing the source file with the #include directive<br />
* /NESTED=PRIMARY: search the default file type for headers using the context of the primary source files<br />
* /NESTED=NONE: do nothing<br />
<br />
2. Search for the places specificed in the /INCLUDE directive. If it does not include the file types, look for .H files.<br />
<br />
3. Is DECC$USER_INCLUDE defined?<br />
<br />
If so:<br />
if /ASSUME=NOHEAD on the CC command, search DECC$USER_INCLUDE for any file types<br />
if /ASSUME=HEAD (or missing), search DECC$USER_INCLUDE for .H files<br />
If not, so nothing<br />
<br />
4. If still not found, assume angle brackets and try the instructions below.<br />
<br />
==Angle bracketed includes==<br />
<br />
1. Search the / location<br />
<br />
2. Search for the places specificed in the /INCLUDE directive. If it does not include the file types, look for .H files.<br />
<br />
3. Is DECC$USER_INCLUDE defined?<br />
If so:<br />
if /ASSUME=NOHEAD on the CC command, search DECC$USER_INCLUDE for any file types<br />
if /ASSUME=HEAD (or missing), search DECC$USER_INCLUDE for .H files<br />
If not, so nothing.<br />
<br />
4. Look at the definitions of DECC$LIBRARY_INCLUDE and DECC$SYSTEM_INCLUDE logicals.<br />
* both defined or only DECC$SYSTEM_INCLUDE is defined: search "DECC$SYSTEM_INCLUDE:.H", or just "DECC$SYSTEM_INCLUDE:." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.<br />
* only DECC$LIBRARY_INCLUDE is defined: search "DECC$LIBRARY_INCLUDE:.H", or just "DECC$LIBRARY_INCLUDE:." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.<br />
* neither is defined: search<br />
SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF]*.H<br />
SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C]*.H<br />
<br />
5. Seacrch the libraries included with the /LIBRARY qualifier for modules with the same name. If /INCLUDE contained an empty string, stop there - otherwise also search DECC$TEXT_LIBRARY.<br />
If DECC$LIBRARY_INCLUDE is defined, do not search further. Otherwise search SYS$LIBRARY:DECC$RTLDEF.TLB and SYS$LIBRARY:SYS$STARLET_C.TLB for .H and . files and SYS$LIBRARY:SYS$STARLET_C.TLB for any files other than .H and .<br />
<br />
6. Search SYS$LIBRARY:.H or . if /ASSUME=NOHEADER_TYPE_DEFAULT.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=CC&diff=2629CC2023-09-19T11:53:05Z<p>Jane.doe: Created page with "'''CC''' is the command to invoke the C Compiler."</p>
<hr />
<div>'''CC''' is the command to invoke the [[C Compiler]].</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=C_Compiler&diff=2628C Compiler2023-09-19T11:52:42Z<p>Jane.doe: </p>
<hr />
<div>The '''C Compiler''' is the software that compiles code written in C into object files.<br />
<br />
=Includes=<br />
<br />
CC /INCLUDE_DIRECTORY qualifier provides similar functionality to the -I option of the cc command on DIGITAL UNIX systems: it allows you to specify additional places to search for include files. It can be one of the following:<br />
<br />
* OpenVMS file-spec to be used as a default file-spec to RMS file services:<br />
/INCLUDE=DISK$:[directory]<br />
* UNIX style pathname in quotation marks<br />
/INCLUDE=/sys<br />
* Empty string ("")<br />
/INCLUDE=""<br />
<br />
The interpretation depends on the format of the #include directive: whether it is is quotes or angle brackets:<br />
<br />
#include "stdio.h"<br />
#include <stdio.h><br />
<br />
==Quoted includes==<br />
1. Look at the /NESTED qualifier on the CC command.<br />
* missing or /NESTED=INCLUDE: search the directory containing the source file with the #include directive<br />
* /NESTED=PRIMARY: search the default file type for headers using the context of the primary source files<br />
* /NESTED=NONE: do nothing<br />
<br />
2. Search for the places specificed in the /INCLUDE directive. If it does not include the file types, look for .H files.<br />
<br />
3. Is DECC$USER_INCLUDE defined?<br />
<br />
If so:<br />
if /ASSUME=NOHEAD on the CC command, search DECC$USER_INCLUDE for any file types<br />
if /ASSUME=HEAD (or missing), search DECC$USER_INCLUDE for .H files<br />
If not, so nothing<br />
<br />
4. If still not found, assume angle brackets and try the instructions below.<br />
<br />
==Angle bracketed includes==<br />
<br />
1. Search the / location<br />
<br />
2. Search for the places specificed in the /INCLUDE directive. If it does not include the file types, look for .H files.<br />
<br />
3. Is DECC$USER_INCLUDE defined?<br />
If so:<br />
if /ASSUME=NOHEAD on the CC command, search DECC$USER_INCLUDE for any file types<br />
if /ASSUME=HEAD (or missing), search DECC$USER_INCLUDE for .H files<br />
If not, so nothing.<br />
<br />
4. Look at the definitions of DECC$LIBRARY_INCLUDE and DECC$SYSTEM_INCLUDE logicals.<br />
* both defined or only DECC$SYSTEM_INCLUDE is defined: search "DECC$SYSTEM_INCLUDE:.H", or just "DECC$SYSTEM_INCLUDE:." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.<br />
* only DECC$LIBRARY_INCLUDE is defined: search "DECC$LIBRARY_INCLUDE:.H", or just "DECC$LIBRARY_INCLUDE:." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.<br />
* neither is defined: search<br />
SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF]*.H<br />
SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C]*.H<br />
<br />
5. Seacrch the libraries included with the /LIBRARY qualifier for modules with the same name. If /INCLUDE contained an empty string, stop there - otherwise also search DECC$TEXT_LIBRARY.<br />
If DECC$LIBRARY_INCLUDE is defined, do not search further. Otherwise search SYS$LIBRARY:DECC$RTLDEF.TLB and SYS$LIBRARY:SYS$STARLET_C.TLB for .H and . files and SYS$LIBRARY:SYS$STARLET_C.TLB for any files other than .H and .<br />
<br />
6. Search SYS$LIBRARY:.H or . if /ASSUME=NOHEADER_TYPE_DEFAULT.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=C_Compiler&diff=2627C Compiler2023-09-19T11:20:26Z<p>Jane.doe: Created page with "The '''C Compiler''' is the software that compiles code written in C into object files. =Includes= CC /INCLUDE_DIRECTORY qualifier provides similar functionality to the -I o..."</p>
<hr />
<div>The '''C Compiler''' is the software that compiles code written in C into object files.<br />
<br />
=Includes=<br />
<br />
CC /INCLUDE_DIRECTORY qualifier provides similar functionality to the -I option of the cc command on DIGITAL UNIX systems: it allows you to specify additional places to search for include files. It can be one of the following:<br />
<br />
* OpenVMS file-spec to be used as a default file-spec to RMS file services:<br />
/INCLUDE=DISK$:[directory]<br />
* UNIX style pathname in quotation marks<br />
/INCLUDE=/sys<br />
* Empty string ("")<br />
/INCLUDE=""<br />
<br />
If you specify one of the places as an empty string, the compiler will not search for any of its conventionally-named places (DECC$USER_INCLUDE, DECC$SYSTEM_INCLUDE, DECC$LIBRARY_INCLUDE, SYS$COMMON:[DECC$LIB.INCLUDE.*], DECC$TEXT_LIBRARY, DECC$RTLDEF.TLB, SYS$STARLET_C.TLB). It searches only places specified explicitly on the command line by the /INCLUDE_DIRECTORY and /LIBRARY qualifiers (or by the location of the primary source file, depending on the /NESTED_INCLUDE_DIRECTORY qualifier).<br />
<br />
The basic search order depends on the form of the header-file name (after macro expansion). Additional aspects of the search order are controlled by other command-line qualifiers and the presence or absence of logical name definitions.<br />
<br />
==All forms of header-file inclusion==<br />
<br />
* In quotes<br />
#include "stdio.h"<br />
<br />
* In angle brackets<br />
#include <stdio.h><br />
<br />
* An identifier to be treated as a text-module name<br />
stdio<br />
<br />
Except where otherwise specified, searching a "place" means that the string designating the place is used as the default file-spec in a call to an RMS [[System Service|system service]] (for example, [[$SEARCH]]/[[$PARSE]]), with a file-spec consisting of the name in the #include directive without enclosing delimiters. The search terminates successfully as soon as a file can be opened for reading.<br />
<br />
==Quoted includes==<br />
<br />
1. One of the following:<br />
<br />
* If /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE (the default) is in effect, search the directory containing the file in which the #include directive itself occurred. The meaning of "directory containing" is: the RMS "resultant string" obtained when the file in which the #include occurred was opened, except that the filename and subsequent components are replaced by the default file type for headers (".H", or just "." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect). The "resultant string" will not have translated any concealed device logical.<br />
* If /NESTED_INCLUDE_DIRECTORY=PRIMARY_FILE is in effect, search the default file type for headers using the context of the primary source file. This means that just the file type (".H" or ".") is used for the default file-spec but, in addition, the chain of "related file-specs" used to maintain the sticky defaults for processing the next top-level source file is applied when searching for the include file.<br />
* If /NESTED_INCLUDE_DIRECTORY=NONE is in effect, this entire step (Step 1) is bypassed.<br />
<br />
2. Search the places specified in the /INCLUDE_DIRECTORY qualifier, if any. A place that can be parsed successfuly as an OpenVMS file-spec and that does not contain an explicit file type or version specification is edited to append the default header file type specification (".H" or ".").<br />
<br />
A place containing a "/" character is considered to be a UNIX-style name. If the name in the #include directive also contains a "/" character that is not the first character and is not preceded by a "!" character (that is, it is not an absolute UNIX-style pathname), then the name in the #include directive is appended to the named place, separated by a "/" character, before applying the decc$to_vms pathname translation function.<br />
<br />
3. If "DECC$USER_INCLUDE" is defined as a logical name, search "DECC$USER_INCLUDE:.H", or just "DECC$USER_INCLUDE:." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.<br />
<br />
4. If the file is not found, follow the steps for the angle-bracketed form of inclusion.<br />
<br />
==Angle bracketed includes==<br />
<br />
1. Search the place "/". This is a UNIX-style name that can combine only with UNIX names specified explicitly in the #include directive. It causes a specification like <sys/types.h> to be considered first as /sys/types.h, which is translated to SYS:TYPES.H.<br />
<br />
2. Search the places specified in the /INCLUDE_DIRECTORY qualifier, exactly as in Step 2 for the quoted form of inclusion.<br />
<br />
3. If "DECC$SYSTEM_INCLUDE" is defined as a logical name, search "DECC$SYSTEM_INCLUDE:.H", or just "DECC$SYSTEM_INCLUDE:." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.<br />
<br />
4. If "DECC$LIBRARY_INCLUDE" is defined as a logical name and "DECC$SYSTEM_INCLUDE" is NOT defined as a logical name, search "DECC$LIBRARY_INCLUDE:.H", or just "DECC$LIBRARY_INCLUDE:." if /ASSUME=NOHEADER_TYPE_DEFAULT is in effect.<br />
<br />
5. If neither "DECC$LIBRARY_INCLUDE" nor "DECC$SYSTEM_INCLUDE" are defined as logical names, then search the default list of places for plain text-file copies of compiler header files as follows:<br />
<br />
SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF]*.H<br />
SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C]*.H<br />
<br />
If the file is not found, perform the text library search described in the next step.<br />
<br />
6. Extract the simple filename and file type from the #include specification and use the filename as the module name to search a list of text libraries associated with that file type. For any file type, the initial text libraries searched consist of those named on the command line with /LIBRARY qualifiers. If the /INCLUDE_DIRECTORY qualifier contained an empty string,no further text libraries are searched. Otherwise, DECC$TEXT_LIBRARY is searched for all file types. If "DECC$LIBRARY_INCLUDE" is defined as a logical name, then no further text libraries are searched. Otherwise, the subsequent libraries searched for each file type are:<br />
<br />
- For ".H" or ".":<br />
<br />
SYS$LIBRARY:DECC$RTLDEF.TLB<br />
SYS$LIBRARY:SYS$STARLET_C.TLB<br />
<br />
- For any file type other then ".H" or ".":<br />
<br />
SYS$LIBRARY:SYS$STARLET_C.TLB<br />
<br />
7. If the previous step fails, search:<br />
<br />
SYS$LIBRARY:.H<br />
<br />
Under /ASSUME=NOHEADER_TYPE_DEFAULT, the default file type is modified as usual.<br />
For the text-module (non-portable) form of #include: <br />
<br />
The name can only be an identifier. It, therefore, has no associated "file type". The identifier is used as a module name to search the following:<br />
<br />
1. The text libraries named on the command line with /LIBRARY qualifiers, in left-to-right order.<br />
<br />
2. The following list of text libraries in the order shown (unless the /INCLUDE_DIRECTORY qualifier contains an empty string, in which case no further text libraries are searched):<br />
<br />
DECC$TEXT_LIBRARY<br />
SYS$LIBRARY:DECC$RTLDEF.TLB<br />
SYS$LIBRARY:SYS$STARLET_C.TLB</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=File_version&diff=2626File version2023-09-18T09:27:55Z<p>Jane.doe: </p>
<hr />
<div>A '''file version number''' is a part of the [[File specification|file specification]] preceded with a semicolon (;) or a period(.) that tells you which version of the file that is. Each file version is stored as a separate file with different [[File ID|FID]]s.<br />
<br />
Version numbers are decimal numbers from 1 to 32,767. When you create a file with a [[File name|file name]] that is unique in the directory, the file is assigned version number 1 (unless a different version number is explicitly specified). If a file with a non-unique name is created, it is assigned the next file version. If you attempt to create a new file with a version number higher than 32767, you will receive an error message - this also means that you cannot edit the files with version 32767 even as a privileged user.<br />
<br />
=Version number defaults=<br />
Various commands default to different version numbers.<br />
{| class="wikitable"<br />
|-<br />
! Command !! Default version numbers<br />
|-<br />
| TYPE || Highest version number<br />
|-<br />
| DIRECTORY|| All version numbers<br />
|-<br />
| PURGE || All version numbers but the highest (you cannot specify a version number; if you need to keep more than one version, use the /KEEP qualifier)<br />
|-<br />
| DELETE || No default (version must be specified explicitly)<br />
|}<br />
<br />
=Relative version numbers=<br />
Relative version numbers can be used to point to various versions of a file if the actual file versions are unknown.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Relative version number !! Meaning<br />
|-<br />
| None (;) || Highest version<br />
|-<br />
| 0 || Highest version<br />
|-<br />
| -1 || Second highest version<br />
|-<br />
| -2 || Third highest version<br />
|-<br />
| -0 || Lowest version<br />
|}<br />
<br />
=Version limit=<br />
A version limit can be imposed on a file or all files created in a given directory. If a file version is created beyond the limit, the lowest existing version of that file will be purged.<br />
<br />
To set a version limit on a file, use the SET FILE/VERSION_LIMIT=n command. By default, the version limit is 0, which means unlimited versions (the number is still limited by the [[Files-11]] architectural limit of 32,767.<br />
To set a version limit on all files created in a certain directory, use the /VERSION_LIMIT qualifier with the SET DIRECTORY or CREATE/DIRECTORY command.<br />
To view the version limit on a file, use the DIRECTORY/FULL command or [[F$FILE_ATTRIBUTES()|F$FILE_ATTRIBUTES(filename,"VERLIMIT")]] [[Lexical functions|lexical function]].<br />
<br />
=See also=<br />
* [https://docs.vmssoftware.com/guide-to-openvms-file-applications OpenVMS Guide to File Applications]<br />
* [https://docs.vmssoftware.com/vsi-openvms-user-s-manual OpenVMS User's Manual]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=ACL&diff=2625ACL2023-09-18T09:23:40Z<p>Jane.doe: </p>
<hr />
<div>'''Access Control Lists''', or '''ACLs''' ("ackles"), are a way to control access to objects on an OpenVMS system by granting various types of access to holders of a specific [[Identifier|identifier]] rather than based on a [[UIC]]. It is more flexible but also more complex than [[UIC Protection]], so system managers and security administrators use ACLs more often than general users.<br />
<br />
Access Control Lists are attached to [[System object|system objects]] such as [[File|files]] and [[Queue|queues]] and consist of [[ACE|Access Control Entries]].</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=OpenVMS_Debugger&diff=2618OpenVMS Debugger2023-07-28T11:35:42Z<p>Jane.doe: </p>
<hr />
<div>The '''OpenVMS Debugger''' is a tool to locate run-time programming or logic errors, also known as bugs, in a program that has been compiled and linked successfully but does not run correctly. For debugging programs that run in privileged processor mode at interrupt priority level 0, see [[OpenVMS DELTA Debugger]].<br />
<br />
=Languages=<br />
On [[Alpha]], the OpenVMS Debugger supports:<br />
* [[Ada]] <br />
* [[BASIC]] <br />
* [[BLISS]] <br />
* [[C]]<br />
* [[C++]] <br />
* [[COBOL]] <br />
* [[Fortran]] <br />
* [[MACRO-32]] (must be compiled with the AMACRO compiler)<br />
* [[MACRO-64]]<br />
* [[Pascal]]<br />
* [[PL/I]]<br />
<br />
On [[Integrity]], the OpenVMS Debugger supports:<br />
* [[Assembler]] (IAS) <br />
* [[BASIC]] <br />
* [[BLISS]] <br />
* [[C]]<br />
* [[C++]] <br />
* [[COBOL]] <br />
* [[Fortran]] <br />
* [[MACRO-32]] (must be compiled with the AMACRO compiler)<br />
* [[IMACRO]]<br />
* [[Pascal]]<br />
<br />
=Features=<br />
* symbolic debugging (you can refer to program locations by the symbols used in the program, or explicit memory addresses or machine registers)<br />
* support for all data types<br />
* flexible data formats<br />
* starting or resuming program execution<br />
* breakpoints<br />
* tracepoints<br />
* watchpoints<br />
* manipulations of variables and program locations<br />
* evaluation of expressions<br />
* control structures<br />
* [[Shareable Image|shareable image]] debugging<br />
* multiprocess debugging<br />
* task debugging<br />
* [[DECwindows]] and Microsoft Windows interface<br />
* client/server configuration<br />
* command procedures<br />
* symbol definitions<br />
<br />
=See also=<br />
* {{Template:Debugger}}<br />
<br />
[[Category:VSI Products]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Template:Debugger&diff=2617Template:Debugger2023-07-28T11:34:52Z<p>Jane.doe: Created page with "[https://docs.vmssoftware.com/vsi-openvms-debugger-manual VSI OpenVMS Debugger Manual]<noinclude> Category:Documentation templates</noinclude>"</p>
<hr />
<div>[https://docs.vmssoftware.com/vsi-openvms-debugger-manual VSI OpenVMS Debugger Manual]<noinclude><br />
<br />
[[Category:Documentation templates]]</noinclude></div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=OpenVMS_Debugger&diff=2616OpenVMS Debugger2023-07-28T11:33:15Z<p>Jane.doe: </p>
<hr />
<div>The '''OpenVMS Debugger''' is a tool to locate run-time programming or logic errors, also known as bugs, in a program that has been compiled and linked successfully but does not run correctly. For debugging programs that run in privileged processor mode at interrupt priority level 0, see [[OpenVMS DELTA Debugger]].<br />
<br />
=Languages=<br />
On [[Alpha]], the OpenVMS Debugger supports:<br />
* [[Ada]] <br />
* [[BASIC]] <br />
* [[BLISS]] <br />
* [[C]]<br />
* [[C++]] <br />
* [[COBOL]] <br />
* [[Fortran]] <br />
* [[MACRO-32]] (must be compiled with the AMACRO compiler)<br />
* [[MACRO-64]]<br />
* [[Pascal]]<br />
* [[PL/I]]<br />
<br />
On [[Integrity]], the OpenVMS Debugger supports:<br />
* [[Assembler]] (IAS) <br />
* [[BASIC]] <br />
* [[BLISS]] <br />
* [[C]]<br />
* [[C++]] <br />
* [[COBOL]] <br />
* [[Fortran]] <br />
* [[MACRO-32]] (must be compiled with the AMACRO compiler)<br />
* [[IMACRO]]<br />
* [[Pascal]]<br />
<br />
=Features=<br />
* symbolic debugging (you can refer to program locations by the symbols used in the program, or explicit memory addresses or machine registers)<br />
* support for all data types<br />
* flexible data formats<br />
* starting or resuming program execution<br />
* breakpoints<br />
* tracepoints<br />
* watchpoints<br />
* manipulations of variables and program locations<br />
* evaluation of expressions<br />
* control structures<br />
* [[Shareable Image|shareable image]] debugging<br />
* multiprocess debugging<br />
* task debugging<br />
* [[DECwindows]] and Microsoft Windows interface<br />
* client/server configuration<br />
* command procedures<br />
* symbol definitions<br />
<br />
=See also=<br />
* [https://docs.vmssoftware.com/vsi-openvms-debugger-manual The OpenVMS Debugger Manual]<br />
<br />
[[Category:VSI Products]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=AUDIT_SERVER&diff=2615AUDIT SERVER2023-07-25T14:59:06Z<p>Jane.doe: </p>
<hr />
<div>'''AUDIT_SERVER''' is a detached system process created during system startup that performs [[Security Auditing|security auditing]] on an OpenVMS system. The following tasks are performed by the audit server:<br />
* Create a clusterwide security audit log file (SECURITY.AUDIT$JOURNAL) in SYS$COMMON:[SYS$MGR]<br />
* Control the logging of security events to the log file and the delivery of alarms to any operator terminals enabled to receive security class messages<br />
* Enable auditing of a site-defined set of security events<br />
* Monitor disk and memory resources<br />
* Maintain a database of security-auditing characteristics<br />
<br />
The audit server sends informational and error messages to the [[OPCOM|operator communication manager (OPCOM)]]. [[OPCOM]] broadcasts these messages to operator terminals and writes the messages to the [[Operator Log File|operator log file]].<br />
<br />
Security auditing settings are stored in the [[Security Auditing#Audit Server Database|audit server database]] and can be modified with [[SET AUDIT]] and viewed with [[SHOW AUDIT]]. Depending on these settings, audit messages can be written to the [[Security Auditing#Security Audit Log File|security audit log file]] or sent to a security-enabled operator terminal (i.e. security alarms).<br />
<br />
The audit server process is started automatically; cluster object support requires the audit server. To shut down security auditing on the system, use the following commands on each node in the cluster:<br />
$ SET AUDIT/ALARM/AUDIT/DISABLE=ALL/CLASS=*<br />
$ SET AUDIT/SERVER=EXIT<br />
<br />
To restart security auditing and [[OPCOM]] on the system, enter:<br />
<br />
$ @SYS$SYSTEM:STARTUP OPCOM<br />
$ @SYS$SYSTEM:STARTUP AUDIT_SERVER<br />
<br />
To avoid starting the audit server during startup, remove it from the startup database (requires [[OPER]] and [[BYPASS]]:<br />
<br />
$ SET PROCESS/PRIVILEGES=(OPER,BYPASS)<br />
$ MCR SYSMAN<br />
SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMS<br />
SYSMAN> STARTUP DISABLE FILE VMS$CONFIG-050_OPCOM.COM/NODE=*<br />
SYSMAN> STARTUP DISABLE FILE VMS$CONFIG-050_AUDIT_SERVER.COM /NODE=*<br />
SYSMAN> EXIT<br />
<br />
To add the audit server to the startup sequence, add it to the startup database (requires [[OPER]] and [[BYPASS]]:<br />
<br />
$ SET PROCESS/PRIVILEGES=(OPER,BYPASS)<br />
$ MCR SYSMAN<br />
SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMS<br />
SYSMAN> STARTUP ENABLE FILE VMS$CONFIG-050_OPCOM.COM/NODE=*<br />
SYSMAN> STARTUP ENABLE FILE VMS$CONFIG-050_AUDIT_SERVER.COM -<br />
_SYSMAN> /NODE=*<br />
SYSMAN> EXIT<br />
<br />
To start a new audit journal log file, do<br />
set audit/server=new<br />
<br />
This will close the current file and open a new one.<br />
<br />
[[Category:Security]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=MESSAGE&diff=2614MESSAGE2023-07-19T11:45:15Z<p>Jane.doe: </p>
<hr />
<div>'''MESSAGE''' is a utility in OpenVMS that allows you to supplement OpenVMS [[Error Message|system messages]] with your own messages.<br />
<br />
=Syntax=<br />
MESSAGE file-spec[,...]<br />
<br />
The MESSAGE command compiles a .MSG source file into an object modules. The message object module can then be linked with the facility object module to produce one executable image file.<br />
<br />
=Message Source Files=<br />
The message source file contains statements or directives and the information included in the message, the message code, and the message symbol. The default extension for message source files is .MSG.<br />
<br />
The message source file statements are as follows:<br />
<br />
• Facility directive (.FACILITY)<br />
• Severity directive (.SEVERITY)<br />
• Base message number directive (.BASE)<br />
• Message definition message-name<br />
• End directive (.END)<br />
• Literal directive (.LITERAL)<br />
• Identification directive (.IDENT)<br />
• Listing directives<br />
• Title directive (.TITLE)<br />
• Page directive (.PAGE)<br />
<br />
Expressions similar to [[F$FAO()]] can be used in the message source file.<br />
<br />
=See also=<br />
* [https://docs.vmssoftware.com/vsi-openvms-command-definition-librarian-and-message-utilities Command Definition, Librarian, and Message Utilities]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=MESSAGE&diff=2613MESSAGE2023-07-19T11:42:39Z<p>Jane.doe: Created page with "'''MESSAGE''' is a utility in OpenVMS that allows you to supplement OpenVMS system messages with your own messages. =Syntax= MESSAGE file-spec[,...] The..."</p>
<hr />
<div>'''MESSAGE''' is a utility in OpenVMS that allows you to supplement OpenVMS [[Error Message|system messages]] with your own messages.<br />
<br />
=Syntax=<br />
MESSAGE file-spec[,...]<br />
<br />
The MESSAGE command compiles a .MSG source file into an object modules. The message object module can then be linked with the facility object module to produce one executable image file.<br />
<br />
=Message Source Files=<br />
The message source file contains statements or directives and the information included in the message, the message code, and the message symbol. The default extension for message source files is .MSG.<br />
<br />
The message source file statements are as follows:<br />
<br />
• Facility directive (.FACILITY)<br />
• Severity directive (.SEVERITY)<br />
• Base message number directive (.BASE)<br />
• Message definition message-name<br />
• End directive (.END)<br />
• Literal directive (.LITERAL)<br />
• Identification directive (.IDENT)<br />
• Listing directives<br />
• Title directive (.TITLE)<br />
• Page directive (.PAGE)<br />
<br />
Expressions similar to [[F$FAO()]] can be used in the message source file.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=DNS&diff=2609DNS2023-07-12T13:56:36Z<p>Jane.doe: </p>
<hr />
<div>'''DNS''' stands for Domain Name Service. Here is how to set up BIND in [[TCP/IP Services for OpenVMS]] so it uses Domain Name Service:<br />
<br />
1. Do a TCPIP SHOW NAME:<br />
$ tcpip sh name<br />
BIND Resolver Parameters<br />
Local domain: <your_company.com><br />
System<br />
State: Started, Enabled<br />
Transport: UDP<br />
Domain: <your_company.com><br />
Retry: 2<br />
Timeout: 5<br />
Servers: ip1, ip2<br />
Path: No values defined<br />
Process<br />
State: Enabled<br />
Transport:<br />
Domain:<br />
Retry:<br />
Timeout:<br />
Servers:<br />
Path:<br />
<br />
2. Set it up with the following commands:<br />
<br />
SET NAME /domain=<your_company.com> /server=<ip of the BIND server, e.g. 8.8.8.8> /ENABLE /SYSTEM<br />
<br />
The state needs to be "Started, Enabled" for the BIND server to work. Values can be removed with /nodomain and /noserver respectively. Test by pinging a valid domain name. If one of the ips that you specified does not work, DNS will not be enabled, so remove it from the list.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Linker&diff=2608Linker2023-07-06T09:40:47Z<p>Jane.doe: Created page with "'''Linker''' is a program used to create images. It is invoked by the LINK command. =Functions= * '''Symbol resolution''': source modules may reference symbols..."</p>
<hr />
<div>'''Linker''' is a program used to create [[Image|images]]. It is invoked by the [[LINK]] command.<br />
<br />
=Functions=<br />
<br />
* '''Symbol resolution''': source modules may reference symbols defined externally to the module, and the linker finds their definitions in the files specified and substitutes the value of the symbol for the reference to the symbol.<br />
* '''Virtual memory allocation''': the linker allocates virtual memory for the image, based on the memory requirements specified by the input files<br />
* '''Image initialization''': the linker initializes the image by filling it with the compiled binary data and code. The linker also inserts the actual value of resolved symbols at each instance where the symbol is referenced.<br />
* '''Image optimization''': for OpenVMS Alpha images, the linker can perform certain optimizations to improve the run-time performance of the image it is creating. These optimizations include replacing JSR instruction sequences with the more efficient Branch to Subroutine (BSR) instruction sequence wherever the language processors specify. For OpenVMS I64 images, the linker can optimize data references to the short data segment.<br />
<br />
=Input Files=<br />
{| class="wikitable"<br />
| File<br />
| Default Type<br />
| Description <br />
|-<br />
| Object file<br />
| .OBJ<br />
| Created by a language processor. May be specified on the LINK command line or in a linker options file. This is the default input file accepted by the linker.<br />
|-<br />
| Shareable image<br />
| .EXE<br />
| Produced by a previous link operation. Must be specified in a linker options file; you cannot specify a shareable image as an input file on the command line. Identify the input file as a shareable image by appending the /SHAREABLE qualifier to the file specification.<br />
|-<br />
| Library file<br />
| .OLB<br />
| Produced by the [[Librarian]] utility. May contain object modules or shareable images. May be specified on the LINK command line, in a linker options file, or as a default user library processed by the linker. Identified by the /LIBRARY or /INCLUDE qualifiers.<br />
|-<br />
| Symbol table file<br />
| .STB<br />
| Produced by a previous link operation or a language processor. May be specified on the LINK command line or in an options file. Because a symbol table file is processed as an object module, it requires no identifying qualifier.<br />
|-<br />
| Options file<br />
| .OPT<br />
| Text file containing link option specifications or link input file specifications. May be specified only on the command line; you cannot specify an options file inside another options file. Identify the input file as an options file by appending the /OPTIONS qualifier to the end of the file specification.<br />
|}<br />
<br />
=Output Files=<br />
{| class="wikitable"<br />
| File<br />
| Default Type<br />
| Description <br />
|-<br />
| Executable image<br />
| .EXE<br />
| A program that can be run at the command line. This image is the default output file created by the linker. Specify the /EXECUTABLE qualifier to create an executable image.<br />
|-<br />
| Shareable image<br />
| .EXE<br />
| A collection of procedures and data that usually can be referenced after being included in a link operation in which another image is created. Specify the /SHAREABLE qualifier to create a shareable image.<br />
|-<br />
| System image<br />
| .EXE<br />
| A program that is meant to be run as a standalone system. Specify the /SYSTEM qualifier to create a system image.<br />
|-<br />
| Symbol table file<br />
| .STB<br />
| An object module containing the global symbol table from an executable or system image, or the universal symbol table from a shareable image. Specify the /SYMBOL_TABLE qualifier to create a symbol table file.<br />
|-<br />
| Map file<br />
| .MAP<br />
| A text file created by the linker that provides information about the layout of the image and statistics about the link operation. Specify the /MAP qualifier to create a map file.<br />
|-<br />
| Debug symbol file (64-bit specific)<br />
| .DSF<br />
| A file containing debug information for use by the OpenVMS Debugger or System Code Debugger. Specify the /DSF qualifier to create a debug symbol file.<br />
|}</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Image&diff=2607Image2023-07-06T08:54:02Z<p>Jane.doe: </p>
<hr />
<div>An '''image''' is an executable file containing binary code and data that a computer can execute without parsing. Images are built by [[Linker|linker]] programs from object modules produced by a [[Compiler|compiler]]. At run time, the image activator, which is part of the operating system, opens the image file and reads activation information from the image to set up process page tables and pass control to the location (transfer address) where image execution is to begin. An image stored as an .EXE file can be executed with the [[RUN]] or [[MCR]] command. Some [[DCL]] [[Command|commands]] invoke images, others execute inside of the CLI. <br />
<br />
A '''shareable image''' is a collection of procedures and data that can be called by executable images or by other shareable images. A shareable image is similar to an executable image. The linker separates shareable from nonshareable code and data. Shareable code and data can be shared via global sections that are set up by the Install utility or by the image activator. In order to use the procedures or data of a shareable image, the shareable image has to be included in a link operation for another image, either explicitly in a linker option or implicitly from a default shareable image library. At run time, when the image activator processes an executable image, it activates all the shareable images to which the executable image was linked.<br />
<br />
The OpenVMS Alpha and OpenVMS VAX linker can also create a system image, which can be run as a standalone system. System images generally do not contain image activation information and are not activated by the image activator. Images without activation information are not defined in the OpenVMS I64 object language. As a result, the OpenVMS I64 linker does not create this special type of image.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Creation_Date&diff=2606Creation Date2023-07-06T08:47:09Z<p>Jane.doe: </p>
<hr />
<div>'''Creation date''' is an attribute of a [[File|file]] that reflects the date and time when the file was created.<br />
<br />
=Displaying=<br />
You can display the file's creation date by:<br />
* running [[DIRECTORY (command)|DIRECTORY]]/FULL on it<br />
* using the [[F$FILE_ATTRIBUTES()]] [[Lexical functions|lexical]]: F$FILE_ATTRIBUTES(filespec,"CDT") returns the creation date and time<br />
<br />
=File Selection=<br />
Many [[DCL]] [[Command|commands]] such as [[DIRECTORY]] offer a similar set of [[File Selection Qualifiers|qualifiers for file selection]]. Since [[File Selection Qualifiers#/CREATED|/CREATED]] is the default qualifier, you may simply use /BEFORE and /SINCE to select files created before or since a certain [[Absolute time format|absolute time]], [[Delta time format|delta time]], a combination of these two, BOOT, LOGIN, TODAY (default), TOMORROW, or YESTERDAY.<br />
<br />
=Modifying=<br />
You may modify the creation date of a file with [[SET FILE]]/ATTRIBUTES=CREDATE.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Relative_File&diff=2605Relative File2023-07-06T08:46:56Z<p>Jane.doe: </p>
<hr />
<div>A '''relative file''' is a type of [[File Organization|file organization]] that allows [[Sequential File Access|sequential]] and [[Random File Access|random]] access of records. A relative file consists of a series of numbered fixed-length records; [[RMS]] uses the relative record number - the record's position relative to the beginning of the file - to randomly access records. Relative files allow random get and put operations and can be write-shared. In relative files, all records are in fixed-length cells regardless of their format.<br />
<br />
To find out if a file is relative, use [[DIRECTORY (command)|DIRECTORY]]/FULL or the [[F$FILE_ATTRIBUTES()]] [[Lexical functions|lexical]]: F$FILE_ATTRIBUTES(filespec,"ORG") will return "REL".<br />
<br />
=Sequential Access=<br />
<br />
Relative files may be accessed sequentially even if some of the fixed-length file cells are empty (because records were never stored in them or because records were deleted from them). RMS ignores empty cells and sequentially searches for the next occupied cell. For example, assume a relative file contains records only in cells 1, 3, and 6. RMS responds to a sequential retrieval request by retrieving the record in cell 1, then the record in cell 3, and then the record in cell 6.<br />
<br />
=Relative Access=<br />
[[RMS]] supports [[Random File Access|random access]] for all relative files, all indexed files, and a restricted set of sequential disk files - those having fixed-length records. In random access mode, your program (not the file organization) determines the record processing order. For example, to randomly access a record in a relative file or a record in a sequential disk file having fixed-length records, your program must provide the relative record number of the cell containing the record.<br />
<br />
=See also=<br />
* {{Template:Fap}}<br />
<br />
[[Category:File Organization]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Sequential_File&diff=2604Sequential File2023-07-06T08:46:37Z<p>Jane.doe: </p>
<hr />
<div>A '''sequential file''' is a type of [[File Organization|file organization]] where [[Record|records]] are stored adjacent to one other. To retrieve a particular record within the file, you must open the file and successively retrieve all records between the current record position and the selected record.<br />
<br />
In OpenVMS, sequential file organization is supported for all device types; this is the only file organization for non-disk devices. A sequential file is created by default when you use the [[CREATE]] command.<br />
<br />
To find out if a file is sequential, use [[DIRECTORY (command)|DIRECTORY]]/FULL or the [[F$FILE_ATTRIBUTES()]] [[Lexical functions|lexical]]: F$FILE_ATTRIBUTES(filespec,"ORG") will return "SEQ" if the file is sequential.<br />
<br />
=See also=<br />
* {{Template:Fap}}<br />
<br />
[[Category:File Organization]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=BEFORE_qualifier&diff=2603BEFORE qualifier2023-07-06T08:46:24Z<p>Jane.doe: </p>
<hr />
<div>'''/BEFORE''' is a recurrent qualifier used by a few [[DCL]] commands that selects files created or modified prior to the date specified as the value.<br />
<br />
=Syntax=<br />
/BEFORE[=time][/CREATED|MODIFIED]<br />
<br />
=Value=<br />
Specify date and time in [[Absolute Time|absolute format]] or as a combination of absolute and [[Delta Time|delta]] times, or as one of the following keywords:<br />
* BOOT<br />
* LOGIN<br />
* TODAY (default)<br />
* TOMORROW<br />
* YESTERDAY<br />
<br />
=Qualifiers=<br />
'''/CREATED''' or '''/MODIFIED''' can be used to indicate the time attribute to be used as the basis for selection. The '''/CREATED''' qualifier is the default.<br />
<br />
=Commands=<br />
The following commands use this qualifier:<br />
* [[SET FILE]]<br />
* [[DIRECTORY (command)]]<br />
<br />
=See also=<br />
* [[SINCE Qualifier]]<br />
<br />
=See also=<br />
* [https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623195 OpenVMS DCL Dictionary Vol II]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Logical_Name&diff=2602Logical Name2023-07-06T08:45:54Z<p>Jane.doe: </p>
<hr />
<div>A '''logical name''' is a string that can be used in place of another name to represent system objects such as files, directories, devices, or queues. For example, you might assign a logical name to your default disk and directory. <br />
<br />
=Use=<br />
Logical names serve two main functions: they increase readability and file independence.<br />
<br />
You can define commonly used files, directories, and devices with short, meaningful logical names. Such names are easier to remember and type than the full file specifications. You can use your login command procedure to define names that you use frequently. A system manager can define names that people use frequently in the system startup command procedure. <br />
<br />
You can use logical names to keep your programs and command procedures independent of physical file specifications. For example, if a command procedure references the logical name ACCOUNTS, you can equate ACCOUNTS to any file on any disk. <br />
<br />
=Logical Name Tables=<br />
[[Logical Name Table|Logical name tables]] are data structures that store logical names. There are a few pre-defined logical name tables that exist on every system; custom logical name tables can also be created. When logical names are defined, the process logical name table is assumed; to use other tables, add the /TABLE qualifier.<br />
<br />
=Logical Name Creation Modes=<br />
OpenVMS has four access modes depending on how trustworthy the image is:<br />
* [[User mode]]<br />
* [[Supervisor mode]]<br />
* [[Executive mode]]<br />
* [[Kernel mode]]<br />
Logical names can also be created in these different modes. By default, logicals are created in supervisor mode. Logicals created in user mode are available for the run of the next image and then deassigned. Logicals created in executive mode are used by privileged images such as system utilities; [[SYSNAM]] or [[SYSPRV]] are required to create executive mode logicals in any logical name table. Kernel mode is reserved for the operating system.<br />
<br />
=Types=<br />
* [[Logical search lists]]: logical names that have several equivalence strings. When used with the [[DIRECTORY (command)|DIRECTORY]] command, all equivalence strings are used. When used with the [[CREATE]] command, files are created using the first valid equivalence string.<br />
* [[Concealed Logical Name|Concealed]] and [[Rooted Logical Name|rooted]] logicals: logical names that conceal and replace a part of a directory specification.<br />
<br />
=Commands=<br />
Use '''DEFINE''' or '''ASSIGN''' to create a logical name. By default, the name is created in supervisor mode in the process logical name table. Use '''/USER_MODE''' or '''/EXECUTIVE_MODE''' to specify a different mode and /TABLE to specify a different table if necessary. Note that you need [[SYSNAM]] or [[SYSPRV]] to create executive mode logicals, and if you don't have either, the system will just silently define a supervisor mode logical.<br />
Use '''SHOW LOGICAL''' to display the current logical name definition. '''/FULL''' gives you additional information on the logical name type and access mode.<br />
Use '''DEASSIGN''' to delete a logical name. By default, the logical you indicate is only search among the logicals created in the process logical name table in supervisor mode. Use '''/EXECUTIVE_MODE''' and '''/TABLE''' to search in other tables and among executive mode logicals.<br />
<br />
=See also=<br />
* {{Template:Userman}} (chapter 11 on logical names)</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=File&diff=2601File2023-07-06T08:45:23Z<p>Jane.doe: </p>
<hr />
<div>A '''file''' is a data structure for storing information on a storage media, an ordered collection of logically related records treated as a unit. File operations are provided by the [[RMS|Record Management Services]]. Files are identified by [[File ID|file IDs]] which contain the location of the [[File header|file header]]. File headers stored in [[INDEXF.SYS]] contain file metadata and pointers to where the file data is stored on disk.<br />
<br />
=File Organization=<br />
[[RMS]] supports the following file organization types:<br />
<br />
* [[Sequential File|sequential]]<br />
* [[Relative File|relative]]<br />
* [[Indexed File|indexed]]<br />
<br />
To find out the organization of a particular file, do a [[DIRECTORY (command) |DIRECTORY]]/FULL.<br />
<br />
Record Access Mode<br />
RMS provides two record access modes: [[Sequential Access to Files|sequential access]] and [[Random Access to Files|random access]].<br />
Random access can be further catalogued as one of the three following modes:<br />
* Random access by key value<br />
* Random access by relative record number<br />
* Random access by record file address (RFA)<br />
Although you cannot change its file organization after you create a file, you can change the record access mode each time you access a record in the file. For example, a relative file can be processed in sequential access mode one time and in a random access mode the next time. <br />
<br />
{| class="wikitable"<br />
! rowspan="2;" | Access Mode<br />
! colspan="3;" | File Organization<br />
|-<br />
! colspan='col' | Sequential<br />
! colspan='col' | Relative<br />
! colspan='col' | Indexed<br />
|-<br />
| Sequential<br />
| Yes<br />
| Yes<br />
| Yes<br />
|-<br />
| Random by relative record number<br />
| Permitted with fixed-length record format on disk devices only<br />
| Yes<br />
| No<br />
|-<br />
| Random by key value<br />
| No<br />
| No<br />
| Yes<br />
|-<br />
| Random by record file address<br />
| Permitted on disk devices only<br />
| Yes<br />
| No <br />
|}<br />
<br />
=FID=<br />
A file is idenitified by the [[File_ID|file ID]] (for example, "277058,4,0") which consists of three numbers:<br />
* the file number - the offset into [[INDEXF.SYS]] where the [[File header|file header]] is stored<br />
* the file sequence number specifying how many times this file number has been used<br />
* the relative volume number specifying the number of the volume in the [[Volume Set|volume set]] where the file is stored<br />
<br />
=Aliases=<br />
Several directory entries with different names possibly found in different directories can point to the same [[File_ID]] and thus same data on disk. This is called aliases or links.<br />
<br />
In the following example, an alias is created for REPORT.DAT:<br />
<br />
<nowiki><br />
$ dir<br />
<br />
Directory DKA0:[JDOE]<br />
<br />
DATA.DIR;1 REPORT.DAT;1<br />
<br />
Total of 2 files.<br />
$ set file/enter=report_alias.dat<br />
_File: report.dat<br />
$ dir<br />
<br />
Directory DKA0:[JDOE]<br />
<br />
DATA.DIR;1 REPORT.DAT;1 REPORT_ALIAS.DAT;1<br />
<br />
Total of 3 files.<br />
$ dir /file_id<br />
<br />
Directory DKA0:[JDOE]<br />
<br />
DATA.DIR;1 (6170,17222,0)<br />
REPORT.DAT;1 (6169,17222,0)<br />
REPORT_ALIAS.DAT;1 (6169,17222,0)<br />
<br />
Total of 3 files.<br />
<br />
</nowiki><br />
<br />
Normally when a file that has an alias is deleted, a dangling directory entry appears - that is, the alias cannot be used to access the file header and the file is "lost":<br />
<br />
<nowiki><br />
$ delete report.dat;1<br />
$ type REPORT_ALIAS.DAT;1<br />
%TYPE-W-OPENIN, error opening DKA0:[JDOE]REPORT_ALIAS.DAT;1 as input<br />
-RMS-E-FNF, file not found<br />
</nowiki><br />
<br />
[[ODS-5]] volumes with [[Hardlink|hardlinks]] enabled support hard links: that is, aliases that can act like files. On a volume with hard links enabled, you can delete the original file, and if there is at least one alias pointing to the file header, the file data is accessible.<br />
<br />
=Directory Files=<br />
[[Directory file|Directory files]] are special files that contain the list of files in a directory and their FIDs. Directory files always have the extension of .DIR and version 1 (files with version numbers greater than one cannot be used as directory files). With sufficient privileges, the directory label can be removed from a file with [[SET FILE]]/NODIRECTORY. You can see if a file is a directory file with [[DIRECTORY]]/FULL; running [[F$FILE_ATTRIBUTES()|F$FILE_ATTRIBUTES]](filespec,"DIRECTORY") on a file returns "TRUE" if it is a directory file.<br />
<br />
=Metadata=<br />
File metadata are stored in the file header in [[INDEXF.SYS]]. You can view it with DIRECTORY/FULL or DUMP/HEADER:<br />
<br />
<nowiki><br />
$ dir/full data.dir<br />
<br />
Directory DKA0:[JDOE]<br />
<br />
DATA.DIR;1 File ID: (6170,17222,0)<br />
Size: 1/16 Owner: [JDOE]<br />
Created: 29-MAR-2019 15:56:38.74<br />
Modified: 29-MAR-2019 15:56:38.74 (0)<br />
Expires: <None specified><br />
Backup: <No backup recorded><br />
Effective: <None specified><br />
Recording: <None specified><br />
Accessed: <None specified><br />
Attr Mod: <None specified><br />
Data Mod: <None specified><br />
Linkcount: 1<br />
File organization: Sequential<br />
Shelved state: Online<br />
Caching attribute: Writethrough<br />
File attributes: Allocation: 16, Extend: 0, Global buffer count: 0<br />
No default version limit, Contiguous, MoveFile disabled<br />
Directory file<br />
Record format: Variable length, maximum 512 bytes, longest 512 bytes<br />
Record attributes: No carriage control, Non-spanned<br />
RMS attributes: None<br />
Journaling enabled: None<br />
File protection: System:RWE, Owner:RWE, Group:RE, World:E<br />
Access Cntrl List: None<br />
Client attributes: None<br />
<br />
Total of 1 file, 1/16 blocks.<br />
</nowiki><br />
<br />
=See also=<br />
* {{Template:Fap}}</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Authentication_on_OpenSSH_Windows_10_Host_from_OpenVMS_Using_Public_Keys&diff=2600Authentication on OpenSSH Windows 10 Host from OpenVMS Using Public Keys2023-06-29T13:25:29Z<p>Jane.doe: </p>
<hr />
<div>== Prerequisites ==<br />
<br />
=== Environment ===<br />
<br />
* OpenVMS V8.4 and above<br />
* [[TCP/IP V5.7]] (SSH.COM format) <br />
* Windows 10 SSH server (OpenSSH format)<br />
<br />
=== System Configuration ===<br />
<br />
* Public key authentication is allowed on both hosts being connected.<br />
* SSH Client is enabled on OpenVMS<br />
*: The client is enabled by calling the <code>SYS$MANAGER:TCPIP$CONFIG.COM</code> script and selecting <code>2. Client components</code> &rarr; <code>7. SSH client</code> from the menu.<br />
* User with administrator privileges on Windows 10<br />
* Running OpenSSH server on the Windows 10 host<br />
*: OpenSSH server is enabled by checking the appropriate checkbox from <code>Settings</code> &rarr; <code>Apps</code> &rarr; <code>Apps & Features</code> &rarr; <code>Optional features</code>.<br />
*: To start the server, one needs to open <code>Computer Management</code> &rarr; <code>Services and Applications</code> &rarr; <code>Services</code>, select OpenSSH SSH Server Service, and then click on <code>Start the service</code>. It is also recommended to change the startup type to <code>Automatic</code> to start the service upon Windows loading.<br />
* OpenVMS Telnet connectivity to the Windows host running OpenSSH.<br />
*: To test connectivity, execute:<br />
*: <code>$ TELNET OpenSSH 22</code><br />
*: A banner should be displayed in the terminal upon successful connection. If unable to connect, contact appropriate support.<br />
<br />
== Common Steps ==<br />
<br />
# Generate the key pair:<br />
#:<code>$ set def sys$login&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;! This is for the account on VMS that will use public key authentication.</code><br />
#:<code>$ set def [.SSH2]</code><br />
#:<code>$ @sys$manager:tcpip$define_commands&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;! The account must have appropriate privileges.</code><br />
#:<code>$ ssh_keygen OpenVMS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;! This command produces the keypair. Note the lack of extension on the target filename - OpenVMS.</code><br />
#:<code></code><br />
#:<code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;OpenVMS.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;! Is the Private key</code><br />
#:<code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;OpenVMS.PUB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;! Is the Public key</code><br />
# Verify the public key (example):<br />
#:<code>$ ssh_keygen -"F" OpenVMS.pub</code><br />
#:<code>Fingerprint for key:</code><br />
#:<code>xemer-dovak-cevol-kukoh-fifav-zopub-sucil-tydic-gebar-nalen-cyxax</code><br />
#: If the fingerprint is not returned, then the public key is not usable. Try generating the keys again. Contact appropriate support for further assistance if it is still not working.<br />
# Populate the <code>IDENTIFICATION.</code> file :<br />
#:<code>$ create IDENTIFICATION. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;! Note the lack of a file extension</code><br />
#:<code>IdKey OpenVMS</code><br />
#:<code>[CTRL-Z] Exit</code><br />
#:<code>dir IDENTIFICATION.;</code><br />
#:<code></code><br />
#:<code>Directory SYS$SYSDEVICE:[user.ssh2]</code><br />
#:<code></code><br />
#:<code>IDENTIFICATION.;1</code><br />
#:<code></code><br />
#:<code>Total of 1 file.</code><br />
# Set protection on the files:<br />
#:<code>$ SET FILE/PROT=(S,W,G,O:RE) IDENTIFICATION. </code><br />
#:<code>$ SET FILE/PROT=(S,W,G,O:RE) OpenVMS.*</code><br />
# Transfer the <code>.PUB</code> file to the OpenSSH Windows 10 SSH server.<br />
<br />
=== Method A ===<br />
<br />
SFTP the <code>.PUB</code> to OpenSSH:<br />
<br />
<code>sftp user@OpenSSH<br />
<br />
&nbsp;&nbsp;user@OpenSSH's password:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;! Note the password prompt<br />
<br />
sftp> cd .ssh<br />
<br />
/C:/Users/user/.ssh/<br />
<br />
sftp><br />
<br />
sftp> put OpenVMS.PUB<br />
<br />
OpenVMS.PUB | 1.2kB | 1.2 kB/s | TOC: 00:00:01 | 100%<br />
<br />
sftp> quit</code><br />
<br />
=== Method B ===<br />
<br />
# Copy/paste the contents of the public key from OpenVMS to OpenSSH on Windows 10:<br />
#:<code>$ TYPE OpenVMS.PUB</code><br />
#: The user needs to be logged into an <u>Administrator</u> account on a Windows 10 PC. Files cannot be edited from a command line.<br />
# Open a Notepad session and paste the contents of the TYPE command output from above into a text editor, such as Notepad. Include the beginning and ending lines as well as all of the text between them:<br />
#:<code>---- BEGIN SSH2 PUBLIC KEY ----</code><br />
#:<code>&nbsp;&nbsp;&nbsp;&nbsp;. text .</code><br />
#:<code>&nbsp;&nbsp;&nbsp;&nbsp;. text .</code><br />
#:<code>&nbsp;&nbsp;&nbsp;&nbsp;. text .</code><br />
#:<code>---- END SSH2 PUBLIC KEY ----</code><br />
# Save the Notepad session in the <code>.ssh</code> folder for the user as <code>OpenVMS.PUB</code>.<br />
# Open a CMD prompt window on the Windows 10 system to perform the following steps:<br />
## Convert the SSH.COM format public key to an OpenSSH test file and verify the converted key:<br />
##:<code>C:\Users\%USERNAME%\.ssh>ssh-keygen -i -f openvms.pub > vms2openssh.pub</code><br />
##:<code>C:\Users\%USERNAME%\.ssh>ssh-keygen -B -f vms2openssh.pub</code><br />
##:The output of the second command should generate a fingerprint that contains the same output as the one that was generated on the OpenVMS system by <code>$ ssh_keygen -"F" OpenVMS.pub</code> from Step 2. If the fingerprint is not returned, the key is not usable. In this case, try Method A and/or Method B above again. If it is still failing, contact appropriate support for further assistance.<br />
## Once verified, the vms2openssh.pub file can be deleted.<br />
# Convert the SSH.COM format key to the OpenSSH format and add it to the <code>authorized_keys</code> file. Older versions of OpenSSH used a file called <code>authorized_keys2</code>. Windows 10 uses a newer version of OpenSSH which changed the file name to <code>authorized_keys</code>:<br />
#:<code>C:\Users\%USERNAME%\.ssh>ssh-keygen -i -f openvms.pub >> authorized_keys</code><br />
# Change permissions on the authorized_keys file in the users <code>.ssh</code> folder. Both <code>SYSTEM</code> and the user should have full control over the file.<br />
## Open a File Explorer window and navigate to the <code>.ssh</code> folder.<br />
## Right click on authorized_keys and go to <code>Properties</code> &rarr; <code>Security</code> &rarr; <code>Advanced</code>.<br />
## Click <code>Disable inheritance</code>.<br />
## Choose <code>Convert inherited permissions into explicit permissions on this object</code> when prompted. Remove all permissions from the file except for the <code>SYSTEM</code> and the user. There must remain exactly two permission entries on the file.<br />
# To enable the public key type of ssh-dss (needed to support the SSH.COM format key from the OpenVMS system) and to prevent public key access from trying to read the <code>administrators_authorized_keys</code> file in <code>C:\PROGRAMDATA\ssh</code>, the <code>sshd_config</code> file needs to be modified as follows:<br />
## Right click and copy the <code>sshd_config</code> file from <code>C:\PROGRAMDATA\ssh</code> and save it to a folder local to the user (<code>Documents</code>, <code>Downloads</code>, etc.).<br />
## Right click on the copied file and select <code>Open with</code>. Select Notepad or your preferred text editor/processor from the popup window and click OK.<br />
## In the editor window, scroll down to the line that reads <code>#PubkeyAuthentication yes</code>. Enter the following line below it:<br />
##:<code>PubkeyAcceptedKeyTypes=+ssh-dss</code><br />
## Scroll to the bottom of the file and comment out the lines that read:<br />
##:<code>Match Group administrators</code><br />
##:<code>&nbsp;&nbsp;&nbsp;&nbsp;AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys</code><br />
##:by adding a <code>#</code> character at the beginning of each line. They should look like this:<br />
##:<code># Match Group administrators</code><br />
##:<code>#&nbsp;&nbsp;&nbsp;&nbsp;AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys</code><br />
## Save the modified <code>sshd_config</code> file to the local user folder. Right click the saved file, select <code>Copy</code>, and then right click in the <code>C:\PROGRAMDATA\ssh</code> folder and select <code>Paste</code>. Click on <code>Replace the file</code> in the destination in the popup window. Click <code>Continue</code> in the <code>Destination Folder Access Denied</code> popup window that appears. This provides administrator permission to allow copying into the folder.<br />
## Start or restart the <code>OpenSSH SSH Server</code> service on the Windows 10 system to have the service read the new <code>sshd_config</code> file.<br />
# Test SFTP from OpenVMS:<br />
#:<code>$ sftp OpenSSH</code><br />
#:<<<NOTE THE LACK OF PASSWORD PROMPT>>><br />
#:<code>sftp> pwd</code><br />
#:<code>/C:/Users/user</code><br />
#:<code>sftp></code><br />
<br />
[[Category:Networking]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=DNS&diff=2599DNS2023-06-29T13:00:01Z<p>Jane.doe: Created page with "'''DNS''' stands for Domain Name Service. Here is how to set up BIND in TCP/IP Services for OpenVMS so it uses Domain Name Service: 1. Do a TCPIP SHOW NAME: $ tcpip sh n..."</p>
<hr />
<div>'''DNS''' stands for Domain Name Service. Here is how to set up BIND in [[TCP/IP Services for OpenVMS]] so it uses Domain Name Service:<br />
<br />
1. Do a TCPIP SHOW NAME:<br />
$ tcpip sh name<br />
BIND Resolver Parameters<br />
Local domain: <your_company.com><br />
System<br />
State: Started, Enabled<br />
Transport: UDP<br />
Domain: <your_company.com><br />
Retry: 2<br />
Timeout: 5<br />
Servers: ip1, ip2<br />
Path: No values defined<br />
Process<br />
State: Enabled<br />
Transport:<br />
Domain:<br />
Retry:<br />
Timeout:<br />
Servers:<br />
Path:<br />
<br />
2. Set it up with the following commands:<br />
<br />
SET NAME /domain=<your_company.com> /server=<ip of the BIND server, e.g. 8.8.8.8> /ENABLE /SYSTEM<br />
<br />
The state needs to be "Started, Enabled" for the BIND server to work. Values can be removed with /nodomain and /noserver respectively. Test by pinging a valid domain name.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=SET_WATCH&diff=2598SET WATCH2023-05-23T12:02:53Z<p>Jane.doe: Created page with "'''SET WATCH FILE''' is a DCL command that monitors selected file activity. It requires the CMEXEC privilege. =Syntax= SET WATCH FILE /CLASS ==Qualifier..."</p>
<hr />
<div>'''SET WATCH FILE''' is a [[DCL]] [[Command|command]] that monitors selected file activity. It requires the [[CMEXEC]] privilege.<br />
<br />
=Syntax=<br />
SET WATCH FILE /CLASS<br />
<br />
==Qualifiers==<br />
* /CLASS=keyword specifies the class of activity to be monitored.<br />
<br />
==Keywords==<br />
{| class="wikitable"<br />
! colspan="col" | Keyword<br />
! colspan="col" | Description<br />
|-<br />
| ALL<br />
| Enable all file activity monitoring.<br />
|-<br />
| [NO]ATTACHED<br />
| Undetermined<br />
|-<br />
| [NO]ATTRIBUTE<br />
| Reading and writing of file attributes; such as done with the directory command.<br />
|-<br />
| [NO]CONTROL_FUNCTION<br />
| Use of file system control functions.<br />
|-<br />
| [NO]DIRECTORY_OPERATIONS<br />
| Modifications to directories by creating, deleting and renaming files.<br />
|-<br />
| [NO]DUMP <br />
| Dump contents of File Information Blocks (FIB).<br />
|-<br />
| [NO]MAJOR_FUNCTION <br />
| Log activities for major functions including file lookup, access and deaccess.<br />
|-<br />
| NONE <br />
| Turn off all file activity monitoring.<br />
|-<br />
| [NO]QUOTA_OPERATIONS <br />
| Activity associated with changes to disk quotas and usage. <br />
|}<br />
<br />
=Examples=<br />
<br />
$ set watch file /class=all<br />
$ dir<br />
%XQP, Thread #0, FIB contents:<br />
00000000 000629E9 00000000 00000000 00000000 00000080 00000000 00000000<br />
00000000 00000000 00000000 00030000 00000000 00000000 00000000 00000000<br />
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
%XQP, Thread #0, FIB contents:<br />
00000000 000629E9 00000000 00000000 00000000 00000080 00000000 00000000<br />
00000000 00000000 00000000 00030000 00000000 00000001 00000000 00000000<br />
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
%XQP, Thread #0, Volume protection: Access requested: 00000001, Status: 00000001, PrvUsd: 00000000<br />
%XQP, Thread #0, File protection (10729,6,0): Access requested: 00000001, Status: 00000001, PrvUsd: 00000000<br />
%XQP, Thread #0, Read attributes: Record attributes tests.DIR;1 (10729,6,0)<br />
%XQP, Thread #0, Read attributes: User file characteristics tests.DIR;1 (10729,6,0)<br />
%XQP, Thread #0, Read attributes: File header tests.DIR;1 (10729,6,0)<br />
%XQP, Thread #0, Access tests.DIR;1 (10729,6,0) Status: 00000001<br />
%XQP, Thread #0, Final status: 02000001<br />
%XQP, Thread #0, FIB contents:<br />
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
%XQP, Thread #0, FIB contents:<br />
00000000 000629E9 00000000 00000000 00000000 00000000 00000000 00000000<br />
00000000 00000000 00000000 00000000 00000000 00000001 00000000 00000000<br />
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
%XQP, Thread #0, Deaccess (10729,6,0) Reads: 1, Writes: 0, Status: 00000001<br />
<br />
Directory USER$DISK:[JDOE.OPENVMS.tests]<br />
...<br />
Total of 14 files.<br />
<br />
<br />
<br />
[[Category:DCL Commands]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=SET_ACCOUNTING&diff=2597SET ACCOUNTING2023-05-23T11:21:28Z<p>Jane.doe: </p>
<hr />
<div>'''SET ACCOUNTING''' is a [[DCL]] [[Command|command]] that controls the current [[Accounting|accounting]] file. It requires the [[OPER]] privilege.<br />
<br />
=Syntax=<br />
SET ACCOUNTING<br />
<br />
==Qualifiers==<br />
* /ENABLE=[[#Keywords|keyword]] enables tracking of the resources specified by the keywords.<br />
* /DISABLE=[[#Keywords|keyword]] prevents tracking of the resources specified by the keywords.<br />
* /LOG writes information to the current [[SYS$OUTPUT]] device as the command executes.<br />
* /NEW_FILE closes the current accounting file, and starts up a new version of it. The name of the new file depends on whether the logical name [[ACCOUNTNG]] is defined in your system logical name table. If this logical name is not defined, the SET ACCOUNTING command opens the file [[SYS$MANAGER]]:ACCOUNTNG.DAT. If this logical name is defined, the command opens the file that this logical name points to. If you omit the directory, [[SYS$MANAGER]] is the default, and if you omit the file type, .DAT is the default. The /NEW_FILE qualifier writes a record to the end of the old file that contains a forward pointer to the new file, and a record to the beginning of the new file that contains a backward pointer to the old file. These records contain the names of the new and old files respectively.<br />
<br />
==Keywords==<br />
{| class="wikitable"<br />
! colspan="col" | Keyword<br />
! colspan="col" | Description<br />
|-<br />
| IMAGE<br />
| Resources used by an image<br />
|-<br />
| LOGIN_FAILURE<br />
| Resources used by an unsuccessful attempt to log in<br />
|-<br />
| MESSAGE<br />
| Unformatted record written to the accounting file by a call to the $SNDJBC system service<br />
|-<br />
| PRINT<br />
| Resources used by a print job<br />
|-<br />
| PROCESS<br />
| Resources used by a process. You do not need to stop the tracking of all processes and images. You can prevent resources being tracked for specific types of process and for images running in these types of process. The following table lists the keywords you can use to specify the type of process:<br />
{| class="wikitable"<br />
! colspan="col" | Keyword<br />
! colspan="col" | Type of process<br />
|-<br />
| BATCH<br />
| Batch process<br />
|-<br />
| DETACHED<br />
| Detached process<br />
|-<br />
| INTERACTIVE<br />
| Interactive process<br />
|-<br />
| NETWORK<br />
| Network process<br />
|-<br />
| SUBPROCESS<br />
| Subprocess (the parent process can be a batch, detached, network, or interactive process)<br />
|}<br />
|}<br />
<br />
=Examples=<br />
$ SET ACCOUNTING /DISABLE /ENABLE=(PROCESS,BATCH,INTERACTIVE)<br />
$ SET ACCOUNTING /ENABLE=IMAGE<br />
<br />
This example tells the system to track the resources used only by batch and interactive processes, and by images running in batch and interactive processes. It illustrates the cumulative effect of /ENABLE and /DISABLE qualifiers, and of SET ACCOUNTING commands.<br />
<br />
The /DISABLE qualifier prevents the tracking of all resources. The /ENABLE qualifier then tells the system to track the resources used by batch and interactive processes. The second SET ACCOUNTING command tells the system to track the resources used by images.<br />
<br />
$ SET ACCOUNTING /NEW_FILE<br />
$ RENAME SYS$MANAGER:ACCOUNTNG.DAT;-1 WEEK_24_RESOURCES.DAT<br />
<br />
This example closes the current accounting file, opens a new version of it, and changes the name of the old file to WEEK_24_RESOURCES.DAT.<br />
<br />
[[Category:DCL Commands]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=F$DEVICE()&diff=2590F$DEVICE()2023-04-06T05:12:58Z<p>Jane.doe: </p>
<hr />
<div>'''F$DEVICE''' is a [[Lexical functions|lexical function]] that returns the device names of all devices on a system that meet the specified selection criteria. Note that the device names are returned in random order. <br />
<br />
=Syntax=<br />
<br />
F$DEVICE([search_devnam],[devclass],[devtype], [stream-id])<br />
<br />
=Return Value=<br />
<br />
A character string containing the name of a device in the system's list of devices. After the last device name in the system's device list is returned, the F$DEVICE function returns a null string ("").<br />
<br />
=Arguments=<br />
<br />
==search_devnam==<br />
<br />
Specifies the name of the device for which F$DEVICE is to search. The asterisk (*) and the percent sign (%) wildcard characters are allowed in the search_devnam argument. Specify the search_devnam argument as a character string expression. <br />
<br />
==devclass== <br />
<br />
Specifies the device class for which F$DEVICE is to search. Specify the devclass argument as a character string expression that corresponds to a valid device class name:<br />
* DISK Disk device<br />
* TAPE Tape device<br />
* SCOM Synchronous communications device<br />
* CARD Card reader<br />
* TERM Terminal<br />
* LP Line printer<br />
* REALTIME Real-time<br />
* MAILBOX Mailbox<br />
* MISC Miscellaneous device<br />
<br />
==devtype== <br />
<br />
Specifies the device type for which F$DEVICE is to search. Specify the devtype argument as a character string expression that corresponds to a valid type name. See the DVI$_DEVTYPE item in the $GETDVI system service for additional information. NOTE Specifying a device type without specifying a device class will result in an error. <br />
<br />
==stream-id== <br />
<br />
A positive integer representing the search stream identification number. The search stream identification number is used to maintain separate search contexts when you use the F$DEVICE function more than once and when you supply different search criteria. If you use the F$DEVICE function more than once in a command procedure and if you also use different search criteria, specify stream-id arguments to identify each search separately. If the search criteria are changed in a call before the device name list is exhausted, the context will be reinitialized and the search will restart. If you omit the stream-id argument, the F$DEVICE function assumes an implicit single search stream. That is, the F$DEVICE function starts searching at the beginning each time you specify different search criteria.<br />
<br />
<br />
=Examples=<br />
<br />
$ START: <br />
$ DEVICE_NAME = F$DEVICE("*0:","DISK","RA60") <br />
$ IF DEVICE_NAME .EQS. "" THEN EXIT <br />
$ SHOW SYMBOL DEVICE_NAME <br />
$ GOTO START <br />
<br />
This command procedure displays the device names of all the RA60s on a unit numbered 0. Because no stream-id argument is specified, F$DEVICE uses an implicit search stream. Each subsequent use of the F$DEVICE function uses the same search criteria to return the next device name. After the last device name is displayed, the F$DEVICE function returns a null string and the procedure exits.<br />
<br />
[[Category:Lexical Functions]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Logical_Disk_Utility&diff=2586Logical Disk Utility2023-02-28T12:34:26Z<p>Jane.doe: </p>
<hr />
<div>The '''Logical Disk utility''' is a system management tool for controlling logical disk usage developed by Jur van der Burg based on the LD driver written by Adrie Sweep for VAX/VMS in 1985. LD has been a part of OpenVMS since [[OpenVMS Version 7.3|VMS V7.3-1]], fully integrated since [[OpenVMS Version 8.2|Version 8.2]].<br />
<br />
=Logical Disk=<br />
<br />
A logical disk is a file available on a physical disk, which acts as a real physical disk (the file may or may not be contiguous). The logical disks are available in any directory of the physical disk. Logical disks may be just a single disk, part of a volumeset, part of a stripeset, part of a host-based shadowset, part of a host-based raid set or any combination. The file to be used for the logical disk may be placed on any physical disk, in any directory. A backup can be made to protect the disk. A physical device may be 'replaced' by a logical disk to enable logging of all I/O of the physical disk.<br />
<br />
=Setup=<br />
To start using LD, you need to run LD$STARTUP.COM which is normally placed in SYS$STARTUP.<br />
<br />
=Commands=<br />
<br />
LD CREATE [/LOG] [/SIZE=xxx] [/BACKUP] [/CONTIGUOUS] [/LBN=xxx]<br />
[/TRACKS=xxx] [/SECTORS=xxx] [/CYLINDERS=xxx] [/ERASE]<br />
[/MAXBLOCKS=xxx] [/CLONE=device] [/EXTEND] Filespec<br />
<br />
creates a file to be used as a logical disk<br />
<br />
LD CONNECT [/LOG] [/SYMBOL] [/REPLACE] [/SHARE] [/CLONE=device]<br />
[/TRACKS=xxx] [/SECTORS=xxx] [/CYLINDERS=xxx] [/FULL]<br />
[/MAXBLOCKS=xxx] [/ALLOCLASS=xxx] [/AUTOGEOMETRY]<br />
[/OVERRIDE] [/SAVE] [/LBN=(START=xxx,END=xxx,COUNT=xxx)] <br />
[/LOGICAL=(NAME=logical-name[,TABLE=table][,MODE=mode])] <br />
[/LOCK] [/FORCED_ERROR] [/INIT] [/[NO]LOAD] [/EXTEND[=n]]<br />
[/LIMIT=n] Filespec [LDan:] [Logicalname]<br />
<br />
connects the logical disk file to the logical disk device<br />
<br />
LD LOAD Filespec LDan: (Qualifiers like CONNECT)<br />
<br />
loads the specified file on the LM device<br />
<br />
LD SWITCH Filespec LDan: (Qualifiers like CONNECT)<br />
<br />
allows volume switching for backup. The existing virtual tapeunit is re-used with a the new container file. The old file will be disconnected.<br />
<br />
LD DISCONNECT [/ALL] [/LOG] [/ABORT] [/TRUNCATE] LDan:<br />
<br />
disconnects the logical disk device from the logical disk file, or from the physical disk<br />
<br />
LD UNLOAD [/LOG] [/TRUNCATE] LDan:<br />
<br />
unloads the specified file from the LM device. This is different from LM DISCONNECT in that the unit will be kept available for subsequent reuse with the LM LOAD command. <br />
<br />
LD TRACE [/ACCURATE] [/FDT] [/SIZE=xxx] [/RESET] [/ALL] LDan:<br />
initializes the trace buffer for the specified device<br />
<br />
LD TRACE/STOP [/ALL] [LDan:]<br />
<br />
stops another process which has issued a SHOW/TRACE/CONTINUOUS command<br />
<br />
LD NOTRACE LDan:<br />
<br />
deallocates the tracebuffer. All data currently available in the buffer will be lost<br />
<br />
LD WATCH LDan: lbn [,lbn...] [/FUNCTION=READ,WRITE,ALL,CODE=xxx]<br />
[/ACTION=SUSPEND,CRASH,OPCOM,ERROR[=xxx]]<br />
[/FILE=filespec]<br />
set a watchpoint on a virtual or logical blocknumber on the specified device<br />
<br />
LD NOWATCH LDan: [lbn [,lbn...]] [/INDEX=n]<br />
<br />
removes the specified watchpoint<br />
<br />
LD WATCH/RESUME LDan: [lbn [,lbn...]] [/INDEX=n]<br />
<br />
resumes a suspended watchpoint<br />
<br />
LD PROTECT [/PERMANENT] LDan:<br />
<br />
write-protects the specified device<br />
<br />
LD NOPROTECT [/PERMANENT] LDan:<br />
<br />
removes write-protection of the specified device<br />
<br />
LD SHOW [/ALL] [/FULL] [LDan:]<br />
<br />
Example:<br />
<br />
$ ld show $34$LDA93:<br />
%LD-I-CONNECTED, Connected $34$LDA93: to DISK:[JDOE]DKA200_USERDISK.DSK;2<br />
<br />
$ ld show $34$LDA93: /full<br />
%LD-I-CONNECTED, Connected $34$LDA93: to DISK:[JDOE]DKA200_USERDISK.DSK;2<br />
-LD-I-OPTIONS, Not Forced Error capable<br />
<br />
displays information about the status and the connected Logical Disk file or device<br />
<br />
LD SHOW/WATCH LDan: [lbn [,lbn...]]<br />
<br />
When this qualifier is specified, the currently set watchpoints of the specified device will be dumped.<br />
<br />
LD SHOW/TRACE [/STATUS] [/RESET] [/OUTPUT=Filespec] [/INPUT=filespec]<br />
[/BINARY] [/ENTRIES=[(XXX,YYY)]] [/HEADER] [/CONTINUOUS]<br />
[/VERSION_LIMIT=xxx] [/BLOCKS=xxx] [/WARNINGS]<br />
[/NUMBER] [/PID] [/LBN] [/BYTECOUNT]<br />
[/IOSB[=COMBINATION,TEXT,HEX,LONGHEX]]<br />
[/TIMESTAMP[=ABSOLUTE,ELAPSED,COMBINATION,DELTA,START,END]]<br />
[/FUNCTION[=TEXT,HEX]] [/ACCURATE] [/FDT] [/SYMBOL] LDan:<br />
<br />
When this qualifier is specified, the trace buffer of the specified device will be dumped<br />
<br />
LD ANALYZE [/RECORDS[=HEX,DECIMAL]] [/DATA] [/DIRECTORY[=HEX,DECIMAL]]<br />
[/CONTINUE] [/OUTPUT=Filespec] Filespec<br />
<br />
This command will verify the integrity of the container file. It can only be used for virtual tapes, disks have their own format (ODS-2/5).<br />
<br />
LD HELP [command]<br />
<br />
Displays help for the lodical disk utility and driver<br />
<br />
LD VERSION<br />
<br />
This command will show the current version of the LD utility and the driver.<br />
<br />
=See also=<br />
* [https://www.digiater.nl Official website for LD driver info and updates]<br />
* [https://www.digiater.nl/downloads/lddriver_technical_journal_jun2005.pdf Disk Partitioning on VMS:LD driver secrets] (Jur van der Burg for OpenVMS Technical Journal V5, Jun 2005)</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=OpenSSH&diff=2585OpenSSH2023-02-21T11:33:10Z<p>Jane.doe: Created page with "'''OpenSSH''' is an Open Source (BSD licensed) suite of secure networking utilities based on the Secure Shell (SSH) protocol, which provides a secure channel over a potentiall..."</p>
<hr />
<div>'''OpenSSH''' is an Open Source (BSD licensed) suite of secure networking utilities based on the Secure Shell (SSH) protocol, which provides a secure channel over a potentially unsecured network. <br />
<br />
=How to connect over SSH=<br />
To connect from a Unix system to an OpenVMS system running OpenSSH, follow these steps:<br />
1. On the Unix system, generate an ed26619 key pair:<br />
ssh-keygen -t ed25519<br />
2. Once ready, connect to the OpenVMS machine and navigate to the [.SSH] directory of the user:<br />
set def [.ssh]<br />
3. Open the AUTHORIZED_KEYS. file (or create a new one) and paste your public key there:<br />
$ create authorized_keys.<br />
ssh-ed25519 AAAAC3NzaC...<br />
user@test<br />
4. Use the following command for connecting from your Unix system:<br />
ssh -o "KexAlgorithms +diffie-hellman-group1-sha1"<br />
-o HostKeyAlgorithms=+ssh-dss<br />
-o PubkeyAcceptedAlgorithms=+ssh-dss <br />
user@openvms_system <br />
-i your_key_file<br />
where '''user''' is the username on OpenVMS, '''openvms_system''' is the IP of your OpenVMS system running OpenSSH, and '''your_key_file''' is the path to the private key file on the Unix system generated in step 1.</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=ZIP&diff=2584ZIP2023-02-20T12:28:01Z<p>Jane.doe: Created page with "'''ZIP''' is a freeware utility that allows the user to create zip archives. It can be run with the RUN command from the .exe file, or you can create a Foreign Command|f..."</p>
<hr />
<div>'''ZIP''' is a freeware utility that allows the user to create zip archives. It can be run with the [[RUN]] command from the .exe file, or you can create a [[Foreign Command|foreign command]] to run it from the command line:<br />
<br />
zip == "$ disk:[dir]zip.exe<br />
<br />
=Example=<br />
The following command puts file.dsk into a zip archive named file.zip while preserving VMS file attributes and using better compression.<br />
<br />
zip "-V9" file.zip file.dsk<br />
<br />
=Sample run=<br />
<br />
$ zip<br />
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.<br />
Zip 3.01 (October 6th 2014). Usage: zip == "$ disk:[dir]zip.exe"<br />
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]<br />
The default action is to add or replace zipfile entries from list, which<br />
can include the special name - to compress standard input.<br />
If zipfile and list are omitted, zip compresses stdin to stdout.<br />
-f freshen: only changed files -u update: only changed or new files<br />
-d delete entries in zipfile -m move into zipfile (delete OS files)<br />
-r recurse into directories -j junk (don't record) directory names<br />
-0 store only -l convert LF to CR LF (-ll CR LF to LF)<br />
-1 compress faster -9 compress better<br />
-q quiet operation -v verbose operation/print version info<br />
-c add one-line comments -z add zipfile comment<br />
-@ read names from stdin -o make zipfile as old as latest entry<br />
-x exclude the following names -i include only the following names<br />
-F fix zipfile (-FF try harder) -D do not add directory entries<br />
-A adjust self-extracting exe -J junk zipfile prefix (unzipsfx)<br />
-T test zipfile integrity -X eXclude eXtra file attributes<br />
-C preserve case of file names -C- down-case all file names<br />
-C2 preserve case of ODS2 names -C2- down-case ODS2 file names* (*=default)<br />
-C5 preserve case of ODS5 names* -C5- down-case ODS5 file names<br />
-V save VMS file attributes (-VV also save allocated blocks past EOF)<br />
-w store file version numbers -ww store file version numbers as ".nnn"<br />
-y store symbolic links as the link instead of the referenced file<br />
-e encrypt -n don't compress these suffixes<br />
-h2 show more help<br />
(Must quote upper-case options, like "-V", unless SET PROC/PARSE=EXTEND)<br />
<br />
=See also=<br />
* [[UNZIP]]<br />
* [[Freeware CD]]<br />
<br />
[[Category:Freeware]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Module_Management_System&diff=2583Module Management System2023-02-15T13:21:21Z<p>Jane.doe: </p>
<hr />
<div>'''Module Management System''' (MMS) is a utility for automating building of software systems, part of [[DECset]]. It is similar to Unix make and uses description files that describe how to build the system, which are then executed by MMS.<br />
<br />
'''Targets''' are OpenVMS files that need to be built, e.g. EXE or OBJ files.<br />
<br />
'''Sources''' are OpenVMS files that are used to build targets, e.g. OBJ or C or PAS files.<br />
<br />
'''Action lines''' are OpenVMS commans that MMS executes. Action lines start with at least one space.<br />
<br />
Built-in rules are made up of default macros, special macros, and string variables. A copy of the built-in rules resides at SYS$COMMON:[SYSHLP.EXAMPLES.MMS]MMS$DEFAULT_RULES.MMS.<br />
<br />
=Macros=<br />
A macro is a name that represents a character string:<br />
<br />
name = string<br />
<br />
==Name==<br />
A macro name can be of unlimited length and can consist of any alphanumeric characters except the $( ) sequence, carriage return, control characters, equal sign, quotation marks, space, and tab.<br />
<br />
==String==<br />
The macro string is the text that replaces the macro name when the macro is expanded. A macro string can consist of any character sequence. You can use a hyphen ( - ) as a continuation character to continue a macro string onto the next line of the description file. To invoke a macro, the following syntax is used:<br />
<br />
$(name)<br />
<br />
For example:<br />
<br />
target = FILE.LIS<br />
$(target) :<br />
<br />
If the value is not defined by the time it is used, its value is the null string.<br />
<br />
==Default macros==<br />
===ADDPREFIX===<br />
$(ADDPREFIX prefix,text)<br />
This function prepends the value of prefix to the start of each word specified by text. Example:<br />
targets = FILE1 FILE2<br />
p_targets = $(ADDPREFIX OBJ$:,$(targets)) !resolved to OBJ$:FILE1, OBJ$:FILE2<br />
<br />
===ADDSUFFIX===<br />
$(ADDSUFFIX suffix,text)<br />
This function appends the value of suffix to the end of each word specified by text. Example:<br />
targets = FILE1 FILE2<br />
s_targets = $(ADDSUFFIX .OBJ,$(targets)) !resolved to FILE1.OBJ, FILE2.OBJ<br />
<br />
===FILTER===<br />
$(FILTER pattern...,text)<br />
This function filters text. Words specified by text that do not match any words specified by pattern are removed. Pattern words can contain the wildcard characters asterisk ( * ) and percent sign (%). Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
one_targets = $(filter *1,$(s_targets)) !resolved to FILE1.OBJ <br />
<br />
===FILTER-OUT===<br />
$(FILTER-OUT pattern...,text)<br />
This function filters text. Words specified by text that match any words specified by pattern are removed. Pattern words can contain the wildcard characters asterisk ( * ) and percent sign (%). Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
one_targets = $(filter-out *1,$(s_targets)) !resolved to FILE2.OBJ <br />
<br />
===FINDSTRING===<br />
$(FINDSTRING find,text)<br />
This function performs a string search. If the value of the string specified by find occurs in the source text specified by text, the value of find is returned. Otherwise, the value is empty. Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
found_targets = $(findstring FILE1.OBJ,$(s_targets)) !resolved to FILE1.OBJ<br />
found_targets = $(findstring ALPHA,$(s_targets)) !resolved to empty string<br />
<br />
===FIRSTWORD===<br />
$(FIRSTWORD text)<br />
This function returns the first word in the source text specified by text. Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
found_targets = $(firstword $(s_targets)) !resolved to FILE1.OBJ<br />
<br />
===FOREACH===<br />
$(FOREACH macro,list,text)<br />
This function repeatedly expands text. For each word specified by list, the value of text is repeated with the value of macro defined as the word from list.<br />
<br />
===JOIN===<br />
$(JOIN list,text)<br />
This function concatenates words. Each word specified by text is appended to the corresponding word in list forming a new word in the result. When the number of words in list and text are not the same, the remaining words from the longer list are simply appended to the result. Example:<br />
targets = FILE1 FILE2<br />
obj_targets = $(join $(targets),.OBJ) ! resolved to FILE1.OBJ, FILE2.OBJ<br />
<br />
===PATSUBST===<br />
$(PATSUBST pattern...,to,text)<br />
This function performs pattern substitution. Each word specified by text that matches a word specified by pattern is replaced by the value of to. Pattern words can contain the wildcard characters asterisk ( * ) and percent sign (%). <br />
If the value of to also contains wildcard characters, the wildcards are replaced by the text that matched the wildcard characters in pattern. Example:<br />
targets = A.LIS B.LIS<br />
new_targets = $(patsubst A*,$(s_targets),NEW.LIS) ! resolved to NEW.LIS, B.LIS<br />
<br />
===SORT===<br />
$(SORT text)<br />
This function sorts text. The words specified by text are sorted and arranged in lexical order; duplicate words are removed. Example:<br />
targets = A.LIS C.LIS A.LIS<br />
new_targets = $(sort $(targets)) ! resolved to A.LIS, C.LIS<br />
<br />
===STRIP===<br />
$(STRIP text)<br />
This function performs whitespace compression. Leading and trailing whitespace is removed from source text specified by text. Each internal sequence of whitespace characters is replaced by a single space.<br />
<br />
===SUBST===<br />
$(SUBST from,to,text)<br />
This function performs string substitution. Each occurrence of the value from in the source text specified by text is replaced by the value of to.<br />
<br />
===WORD===<br />
$(WORD n,text)<br />
This function returns a word (based on its position) from the source text specified by text. The value of n should range from 1 to the total number of words in the list. If n is not in this range, the result is empty. Example:<br />
targets = A.LIS C.LIS<br />
my_target = $(word 1,$(targets)) ! A.LIS<br />
my_target = $(word 2,$(targets)) ! C.LIS<br />
my_target = $(word 3,$(targets)) ! empty string<br />
<br />
===WORDS===<br />
$(WORDS text)<br />
This function returns the number of words in text. Example:<br />
targets = A.LIS C.LIS<br />
number = $(words $(targets)) !2<br />
<br />
===BASENAME===<br />
$(BASENAME text)<br />
For each file specification specified by text, this function returns the name portion of the specification (omitting the file type and version). Example:<br />
targets = A.LIS C.LIS<br />
number = $(basename $(targets)) !resolved to A, C<br />
<br />
===DIR===<br />
$(DIR text)<br />
For each file specification specified by text, this function returns the directory portion of the specification (omitting the file name, type, and version). Example:<br />
targets = OBJ$:A.OBJ SRC$:C.LIS<br />
dir = $(dir $(targets)) !resolved to OBJ$, SRC$:<br />
<br />
===FILETYPE=== <br />
$(FILETYPE text)<br />
For each file specification specified by text, this function returns the file type portion of the specification (omitting the file name and version).<br />
<br />
===FILEVERSION===<br />
$(FILEVERSION text)<br />
For each file specification specified by text, this function returns the version portion of the specification (omitting the file name and type).<br />
<br />
===NOTDIR===<br />
$(NOTDIR text)<br />
For each file specification in text, this function returns the file name and type portion of the specification (omitting the directory and version).<br />
targets = OBJ$:A.OBJ SRC$:C.LIS<br />
dir = $(dir $(targets)) !resolved to A.OBJ,C.LIS<br />
<br />
===WILDCARD===<br />
$(WILDCARD text)<br />
This function is used to search for files. It returns the name and type portion of files that match the file specifications specified by text. The file specifications may contain the wildcard characters asterisk ( * ) and percent sign (%).<br />
<br />
===ORIGIN===<br />
$(ORIGIN macro)<br />
This function returns the one of the following text strings, which indicates the source of the definition of macro:<br />
* FILE<br />
* COMMAND LINE<br />
* SPECIAL<br />
* DEFAULT<br />
* CLI SYMBOL<br />
* TEMPORARY<br />
* UNDEFINED<br />
<br />
[[Category:Utilities]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Module_Management_System&diff=2582Module Management System2023-02-15T13:15:10Z<p>Jane.doe: </p>
<hr />
<div>'''Module Management System''' (MMS) is a utility for automating building of software systems, part of [[DECset]]. It is similar to Unix make and uses description files that describe how to build the system, which are then executed by MMS.<br />
<br />
'''Targets''' are OpenVMS files that need to be built, e.g. EXE or OBJ files.<br />
<br />
'''Sources''' are OpenVMS files that are used to build targets, e.g. OBJ or C or PAS files.<br />
<br />
'''Action lines''' are OpenVMS commans that MMS executes. Action lines start with at least one space.<br />
<br />
Built-in rules are made up of default macros, special macros, and string variables. A copy of the built-in rules resides at SYS$COMMON:[SYSHLP.EXAMPLES.MMS]MMS$DEFAULT_RULES.MMS.<br />
<br />
=Macros=<br />
A macro is a name that represents a character string:<br />
<br />
name = string<br />
<br />
==Name==<br />
A macro name can be of unlimited length and can consist of any alphanumeric characters except the $( ) sequence, carriage return, control characters, equal sign, quotation marks, space, and tab.<br />
<br />
==String==<br />
The macro string is the text that replaces the macro name when the macro is expanded. A macro string can consist of any character sequence. You can use a hyphen ( - ) as a continuation character to continue a macro string onto the next line of the description file. To invoke a macro, the following syntax is used:<br />
<br />
$(name)<br />
<br />
For example:<br />
<br />
target = FILE.LIS<br />
$(target) :<br />
<br />
If the value is not defined by the time it is used, its value is the null string.<br />
<br />
==Default macros==<br />
===ADDPREFIX===<br />
$(ADDPREFIX prefix,text)<br />
This function prepends the value of prefix to the start of each word specified by text. Example:<br />
targets = FILE1 FILE2<br />
p_targets = $(ADDPREFIX OBJ$:,$(targets)) !resolved to OBJ$:FILE1, OBJ$:FILE2<br />
<br />
===ADDSUFFIX===<br />
$(ADDSUFFIX suffix,text)<br />
This function appends the value of suffix to the end of each word specified by text. Example:<br />
targets = FILE1 FILE2<br />
s_targets = $(ADDSUFFIX .OBJ,$(targets)) !resolved to FILE1.OBJ, FILE2.OBJ<br />
<br />
===FILTER===<br />
$(FILTER pattern...,text)<br />
This function filters text. Words specified by text that do not match any words specified by pattern are removed. Pattern words can contain the wildcard characters asterisk ( * ) and percent sign (%). Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
one_targets = $(filter *1,$(s_targets)) !resolved to FILE1.OBJ <br />
<br />
===FILTER-OUT===<br />
$(FILTER-OUT pattern...,text)<br />
This function filters text. Words specified by text that match any words specified by pattern are removed. Pattern words can contain the wildcard characters asterisk ( * ) and percent sign (%). Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
one_targets = $(filter-out *1,$(s_targets)) !resolved to FILE2.OBJ <br />
<br />
===FINDSTRING===<br />
$(FINDSTRING find,text)<br />
This function performs a string search. If the value of the string specified by find occurs in the source text specified by text, the value of find is returned. Otherwise, the value is empty. Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
found_targets = $(findstring FILE1.OBJ,$(s_targets)) !resolved to FILE1.OBJ<br />
found_targets = $(findstring ALPHA,$(s_targets)) !resolved to empty string<br />
<br />
===FIRSTWORD===<br />
$(FIRSTWORD text)<br />
This function returns the first word in the source text specified by text. Example:<br />
s_targets = FILE1.OBJ, FILE2.OBJ<br />
found_targets = $(firstword $(s_targets)) !resolved to FILE1.OBJ<br />
<br />
===FOREACH==<br />
$(FOREACH macro,list,text)<br />
This function repeatedly expands text. For each word specified by list, the value of text is repeated with the value of macro defined as the word from list.<br />
<br />
===JOIN===<br />
$(JOIN list,text)<br />
This function concatenates words. Each word specified by text is appended to the corresponding word in list forming a new word in the result. When the number of words in list and text are not the same, the remaining words from the longer list are simply appended to the result. Example:<br />
targets = FILE1 FILE2<br />
obj_targets = $(join $(targets),.OBJ) ! resolved to FILE1.OBJ, FILE2.OBJ<br />
<br />
===PATSUBST===<br />
$(PATSUBST pattern...,to,text)<br />
This function performs pattern substitution. Each word specified by text that matches a word specified by pattern is replaced by the value of to. Pattern words can contain the wildcard characters asterisk ( * ) and percent sign (%). <br />
If the value of to also contains wildcard characters, the wildcards are replaced by the text that matched the wildcard characters in pattern. Example:<br />
targets = A.LIS B.LIS<br />
new_targets = $(patsubst A*,$(s_targets),NEW.LIS) ! resolved to NEW.LIS, B.LIS<br />
<br />
===SORT===<br />
$(SORT text)<br />
This function sorts text. The words specified by text are sorted and arranged in lexical order; duplicate words are removed. Example:<br />
targets = A.LIS C.LIS A.LIS<br />
new_targets = $(sort $(targets)) ! resolved to A.LIS, C.LIS<br />
<br />
===STRIP===<br />
$(STRIP text)<br />
This function performs whitespace compression. Leading and trailing whitespace is removed from source text specified by text. Each internal sequence of whitespace characters is replaced by a single space.<br />
<br />
===SUBST===<br />
$(SUBST from,to,text)<br />
This function performs string substitution. Each occurrence of the value from in the source text specified by text is replaced by the value of to.<br />
<br />
===WORD===<br />
$(WORD n,text)<br />
This function returns a word (based on its position) from the source text specified by text. The value of n should range from 1 to the total number of words in the list. If n is not in this range, the result is empty. Example:<br />
targets = A.LIS C.LIS<br />
my_target = $(word 1,$(targets)) ! A.LIS<br />
my_target = $(word 2,$(targets)) ! C.LIS<br />
my_target = $(word 3,$(targets)) ! empty string<br />
<br />
===WORDS===<br />
$(WORDS text)<br />
This function returns the number of words in text. Example:<br />
targets = A.LIS C.LIS<br />
number = $(words $(targets)) !2<br />
<br />
===BASENAME===<br />
$(BASENAME text)<br />
For each file specification specified by text, this function returns the name portion of the specification (omitting the file type and version). Example:<br />
targets = A.LIS C.LIS<br />
number = $(basename $(targets)) !resolved to A, C<br />
<br />
===DIR===<br />
$(DIR text)<br />
For each file specification specified by text, this function returns the directory portion of the specification (omitting the file name, type, and version). Example:<br />
targets = OBJ$:A.OBJ SRC$:C.LIS<br />
dir = $(dir $(targets)) !resolved to OBJ$, SRC$:<br />
<br />
===FILETYPE=== <br />
$(FILETYPE text)<br />
For each file specification specified by text, this function returns the file type portion of the specification (omitting the file name and version).<br />
<br />
===FILEVERSION===<br />
$(FILEVERSION text)<br />
For each file specification specified by text, this function returns the version portion of the specification (omitting the file name and type).<br />
<br />
===NOTDIR===<br />
$(NOTDIR text)<br />
For each file specification in text, this function returns the file name and type portion of the specification (omitting the directory and version).<br />
targets = OBJ$:A.OBJ SRC$:C.LIS<br />
dir = $(dir $(targets)) !resolved to A.OBJ,C.LIS<br />
<br />
===WILDCARD===<br />
$(WILDCARD text)<br />
This function is used to search for files. It returns the name and type portion of files that match the file specifications specified by text. The file specifications may contain the wildcard characters asterisk ( * ) and percent sign (%).<br />
<br />
===ORIGIN===<br />
$(ORIGIN macro)<br />
This function returns the one of the following text strings, which indicates the source of the definition of macro:<br />
* FILE<br />
* COMMAND LINE<br />
* SPECIAL<br />
* DEFAULT<br />
* CLI SYMBOL<br />
* TEMPORARY<br />
* UNDEFINED<br />
<br />
[[Category:Utilities]]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Mailbox&diff=2581Mailbox2023-02-13T11:53:47Z<p>Jane.doe: </p>
<hr />
<div>A '''mailbox''' is a pseudo device used for interprocess communication and synchronization. The [[Device code|device code]] for mailboxes is MBAn.<br />
<br />
=Mailbox characteristics=<br />
Mailboxes can store a certain amount of information to be shared between processes, signal to a process when there is information to be read by that process. There is also a queueing mechanism for when multiple messages are being written to a mailbox.<br />
Multiple channels can be assigned to a mailbox.<br />
Mailboxes can be permanent and temporary. Temporary mailboxes are deleted when all channels to the mailbox have been deassigned; permanent mailboxes must be explicitly deleted.<br />
Mailboxes can have many writers and many readers.<br />
Mailboxes have a "size" determined by the buffer quota.<br />
<br />
==Protection==<br />
Mailboxes have four kinds of access: read (R), write (W), logical I/O (L), and or physical I/O (P).<br />
<br />
=Privileges=<br />
* TMPMBX is required to create temporary mailboxes<br />
* PRMMBX is required to create permanent mailboxes<br />
* SYSNAM or GRPNAM are required to place the logical name for the mailbox in the appropriate table<br />
<br />
=See also=<br />
* [https://docs.vmssoftware.com/vsi-openvms-programming-concepts-manual-volume-i OpenVMS Programming Concepts]<br />
* [https://docs.vmssoftware.com/vsi-openvms-system-services-reference-manual-getutc-z OpenVMS System Services Reference Manual]<br />
* [https://docs.vmssoftware.com/vsi-openvms-io-user-s-reference-manual OpenVMS I/O User’s Reference Manual]<br />
* [http://h41379.www4.hpe.com/openvms/journal/v9/mailboxes.pdf OpenVMS Mailboxes: Concepts, Implementation, and Troubleshooting by Bruce Ellis for OpenVMS Technical Journal V9:]</div>Jane.doehttps://wiki.vmssoftware.com/index.php?title=Mailbox&diff=2580Mailbox2023-02-13T11:50:27Z<p>Jane.doe: </p>
<hr />
<div>A '''mailbox''' is a pseudo device used for interprocess communication and synchronization. The [[Device code|device code]] for mailboxes is MBAn.<br />
<br />
=Mailbox characteristics=<br />
Mailboxes can store a certain amount of information to be shared between processes, signal to a process when there is information to be read by that process. There is also a queueing mechanism for when multiple messages are being written to a mailbox.<br />
Multiple channels can be assigned to a mailbox.<br />
Mailboxes can be permanent and temporary. Temporary mailboxes are deleted when all channels to the mailbox have been deassigned; permanent mailboxes must be explicitly deleted.<br />
Mailboxes can have many writers and many readers.<br />
Mailboxes have a "size" determined by the buffer quota.<br />
<br />
==Protection==<br />
Mailboxes have four kinds of access: read (R), write (W), logical I/O (L), and or physical I/O (P).<br />
<br />
=Privileges=<br />
* TMPMBX is required to create temporary mailboxes<br />
* PRMMBX is required to create permanent mailboxes<br />
* SYSNAM or GRPNAM are required to place the logical name for the mailbox in the appropriate table<br />
<br />
=See also=<br />
* [https://docs.vmssoftware.com/vsi-openvms-programming-concepts-manual-volume-i OpenVMS Programming Concepts]<br />
* [https://docs.vmssoftware.com/vsi-openvms-system-services-reference-manual-getutc-z OpenVMS System Services Reference Manual]<br />
* [https://docs.vmssoftware.com/vsi-openvms-io-user-s-reference-manual OpenVMS I/O User’s Reference Manual]<br />
* [http://webcache.googleusercontent.com/search?q=cache:i13Y_hUOieUJ:h41379.www4.hpe.com/openvms/journal/v9/mailboxes.pdf+&cd=1&hl=ru&ct=clnk&gl=ru| OpenVMS Mailboxes: Concepts, Implementation, and Troubleshooting by Bruce Ellis for OpenVMS Technical Journal V9:]</div>Jane.doe