|
POLYCENTER Software Installation Utility Developer's
Guide
REGISTER MODULE
The REGISTER MODULE statement registers in the product database one or
more existing modules in a command, help, macro, object, or text
library file.
Syntax
REGISTER MODULE TYPE type MODULE (module_name,...)
[ [NO] GENERATION generation ] [ LIBRARY
library ] ;
Parameters
TYPE type
Indicates the library type. Table 7-9 lists the keywords you can
use with this parameter.
Table 7-9 Library Types for Register Module Statement
Keyword |
Library Type |
Default Library File |
Command
|
Command definition library
|
[SYSLIB]DCLTABLES.EXE
|
Help
|
Help library
|
[SYSHLP]HELPLIB.HLB
|
Macro
|
Macro library
|
[SYSLIB]STARLET.MLB
|
Object
|
Object library
|
[SYSLIB]STARLET.OLB
|
Text
|
Text library
|
[SYSLIB]STARLETSD.TLB
|
MODULE module_name
Indicates the names of the modules contained within the library.
Options
[NO] GENERATION generation
Indicates that the module has an explicit generation number. Enter the
number as an unsigned integer in the range of 0 through 4294967295. See
the Description section of the MODULE statement for the meaning of this
value. By default, the module does not have an explicit generation
number (no generation), which is equivalent to 0.
LIBRARY library
The file specification of the library. The file you use must be a
library of the type you specified with the type parameter.
Description
The REGISTER MODULE statement registers in the product database one or
more existing modules in a command, help, macro, object, or text
library file. Typically, REGISTER MODULE statements are used when a
product provides a library file with a FILE statement that is already
populated with modules. Registering these modules in the product
database allows the utility to detect conflicts with other modules.
Do not use REGISTER MODULE statements to register information about
modules specified in a MODULE statement. When a MODULE statement is
processed, module information is automatically placed in the product
database. Therefore, use of REGISTER MODULE statements in this context
would be redundant.
See Also MODULE
Examples
#1 |
register module type HELP
module (":=","=","@",ACCOUNTING,ALLOCATE,ANALYZE,APPEND,...) ;
|
In this example, the REGISTER MODULE statement registers several help
modules in [SYSHLP]HELPLIB.HLB.
#2 |
register module type OBJECT generation 1
module (BAS$$CB,BAS$$COPY_FD,BAS$$DISPATCH_T,...) ;
|
In this example, the REGISTER MODULE statement registers several object
modules. The generation option allows the utility to perform conflict
resolution with these object modules.
REMOVE
The REMOVE statement deletes objects from the user's system. The REMOVE
and END REMOVE statements form a remove group.
Note
You cannot use the REMOVE statement in a transition PDF.
|
Syntax
REMOVE ;
[ PDL-statements ]
END REMOVE ;
Option
PDL-statements
Any product description language statement or a group of statements
described in this reference section, except the PRODUCT and END PRODUCT
statements.
Required Terminator
END REMOVE ;
Description
The REMOVE group is used to delete objects from the user's system.
Statements that normally provide managed objects (such as FILE and
DIRECTORY statements) cause these objects to be deleted when the
statements are enclosed in a REMOVE group.
By using the REMOVE group in a partial, patch, or mandatory update kit,
you can eliminate obsolete files from a previous version of your
product. By using the REMOVE group in a full kit, you can eliminate
objects provided by a previous installation mechanism (for example,
VMSINSTAL). You can also use a REMOVE group to delete objects that were
created by a previous version of your product, but which were not
recorded in the product database as managed objects. These include
archived files (those saved as *.*_OLD) and files created by command
procedures invoked through EXECUTE statements.
Statements that do not provide managed objects function normally within
a REMOVE group.
You can nest REMOVE, END REMOVE within SCOPE, END SCOPE, if necessary.
Examples
#1 |
remove ;
directory [SYSHLP.EXAMPLES.FOO] ;
file [SYSHLP.EXAMPLES.FOO]SMLUS.COM ;
file [SYSHLP.EXAMPLES.FOO]SMLUT.COM ;
file [SYSHLP.EXAMPLES.FOO]SMLUU.COM ;
end remove ;
|
The statements in this example remove some files and a directory (if
they exist) from the product database and the running system.
#2 |
scope bootstrap ;
remove ;
file [SYSEXE]PROD_PROC.EXE ;
end remove ;
file [SYSEXE]PROD_PROC_V2.EXE ;
end scope ;
|
The statements in this example remove a file in the bootstrap scope and
then provide a new file.
RIGHTS IDENTIFIER
The RIGHTS IDENTIFIER statement uses a command procedure to create a
rights identifier.
Syntax
RIGHTS IDENTIFIER name WITH (parameters,...) ;
Parameters
name
Indicates the name of the rights identifier. The rights identifier name
is passed to the command procedure as P1.
WITH (parameters,...)
Indicates the list of parameters that are passed to the command
procedure that creates the rights identifier. Each parameter must be a
single unquoted or quoted string that specifies P2 and P3, in order. If
there are no qualifiers to pass, specify a null string (" "). See the
Description section for the meaning of the parameters.
Description
The RIGHTS IDENTIFIER statement invokes a command procedure
(SYS$UPDATE:PCSI$CREATE_RIGHTS_IDENTIFIER.COM) to create rights
identifiers. This command procedure runs the AUTHORIZE utility to
perform the function. The utility passes the following parameters to
the command procedure:
- P1 specifies the name of the rights identifier (using the
name parameter).
- P2 specifies the optional qualifiers to use with the AUTHORIZE
command ADD/IDENTIFIER. If there are no qualifiers to pass, specify a
null string (" ").
- P3 specifies the /VALUE qualifier to use with the AUTHORIZE command
ADD/IDENTIFIER. You can specify this parameter only if the identifier
does not already exist on the system.
When you remove a product that created rights identifiers, the
POLYCENTER Software Installation utility uses a command procedure
(SYS$UPDATE:PCSI$DELETE_RIGHTS_IDENTIFIER.COM) to delete rights
identifiers associated with your product. This happens regardless of
whether the SYSUAF.DAT is shared by another system disk.
Note
In a future version, the utility may create and delete these managed
objects directly without the use of command procedures. If this is the
case, these statements will continue to function, but the command
procedures may not be maintained or shipped with future versions of the
utility.
|
The RIGHTS IDENTIFIER statement specifies a rights identifier managed
object that has the following characteristics:
- Its name is the value of the name parameter. The name must
be unique with respect to all rights identifier names in the operating
scope.
- It has operating lifetime.
- It does not recover from managed object conflict.
See Also ACCOUNT
Example
|
rights identifier PCSI_TEST
with ("/attributes=DYNAMIC",
"/value=IDENTIFIER:14600926") ;
|
In this example, the RIGHTS IDENTIFIER statement creates a rights
identifier named PCSI_TEST with a value of 14600926.
|