Filter
Top Products
prefix
Is a value you specify with the PREFIX keyword on the
TARGET command
sysname
Is the system name. This name must match the value in the
CVTSNAME field for the system it identifies.
ds_identity
Is either INMSG or OUTMSG
The naming convention for the workspace data sets for remote connections is now:
prefix.local_luname.remote_luname.ds_identity
where:
prefix
Is a value you specify with the PREFIX keyword on the
TARGET command
local_luname
Is the LU name of the local node
remote_luname
Is the LU name of the remote node
ds_identity
Is either INMSG or OUTMSG
If your installation has configured an RRSF network, you could lose requests that
are in your existing workspace data sets when you install multisystem RRSF node
support. To avoid losing requests, follow these steps before you install multisystem
RRSF node support on a system in an RRSF network:
1. Warn users of this migration. Start this process at a time appropriate for your
installation. Pay particular attention to the effects of locking the RACF
database (step 3). Updates to a locked RACF database are not allowed, and
result in ABEND483 or ABEND485. See
OS/390 Security Server (RACF)
System Programmer's Guide
for information on locking a database.
2. On the system on which you are installing multisystem node support, issue
TARGET DORMANT commands for all remote nodes, and wait until their
INMSG workspace data sets have drained. You can use a TARGET LIST
command for each specific remote node to verify that the INMSG file is empty.
As a result of this step:
Future requests from remote nodes are not received. They queue up in the
OUTMSG files for this system on the remote nodes.
Pending requests from remote nodes are processed before you lock the
RACF database.
3. Use the IRRUT400 utility to lock the RACF database. Specify
PARM='LOCKINPUT' with no OUTDD statements in the JCL. The utility gives a
return code of 4, but locks the database. Locking the database prevents the
database from getting out of synchronization with other RACF databases in the
RRSF network during the install.
It is important to completely finish step 2 before locking the database.
Otherwise, pending update requests already received from remote nodes will
result in abends, and could cause the out-of-sync condition that this step is
attempting to prevent.
4. Install RACF.
5. Stop the RACF subsystem address space.
If the INMSG and OUTMSG workspace data sets are empty at this time, new
workspace data sets can be allocated that follow the new naming convention.
You can preallocate these data sets, or let RACF allocate them for you. See
28 OS/390 V1R2.0 Security Server (RACF) Planning: Installation and Migration