Fallback considerations, Guardian user ids – HP Integrity NonStop H-Series User Manual
Page 215
1.
Back out from G06.26 to G06.24.
Follow the appropriate procedure in
“Backing Out if DSM/SCM is Running” (page 209)
or
“Previous Configuration Does Not Exist or DSM/SCM Does Not Run” (page 213)
2.
After the backout is complete, build and apply a new revision for G06.26. For details, see
Chapter 7: “Creating and Managing Software Revisions”
.
Do not be alarmed when the Configuration Revisions window appears and still lists the products
from the last applied configuration (in this example, G06.25). G06.24 is the configuration
you can back out to even though the G06.25 information is displayed in the Revision History
window.
Fallback Considerations
Guardian User IDs
After you migrate back to a product version update prior to T6031ABK on a NonStop S-series
system, the user IDs will be exactly as they were before installing T6031ABK. Any changes made
to the Guardian user IDs while on T6031ABK or later are not carried backward.
There are two possible scenarios:
•
You performed a backward migration from T6031ABK or later to pre-ABK but post-D46.
In this case, FALLBACK removes Safeguard alias security profile information from the DSM/SCM
databases. Any security profile changes that you made to Planners, Database Administrators,
or Operators while on ABK are not be carried backward. The security profile information is
exactly as it was before you installed T6031ABK.
•
You performed a backward migration from T6031ABK or later to pre-D46. In this case, in
addition to the new security tables, FALLBACK also removes OSS management information
from the DSM/SCM databases. (For details, see
“Removing OSS Management Information
The FALLBACK macro is run in the same manner as explained in
Removing OSS Management Information From the DSM/SCM Databases
Backing out to the previous configuration is the same when OSS files are managed as when only
Guardian files are managed, with one exception: the current configuration manages OSS files,
but the previous configuration did not.
The backout and activation processes are normal, and OSS files are returned to the state they were
in before the current configuration was applied. However, this backout puts DSM/SCM in a unique
state where the newly current configuration does not manage OSS files but the newly previous
configuration does. There are three possible results:
•
If the next Build/Apply is for this logical target and does not manage OSS files, OSS
management is removed.
•
If the next Build/Apply is for this logical target and manages OSS files, the build stops
restartable:
1.
Cancel the Apply.
2.
Run CLEANOSS to remove all DSM/SCM files from the OSS environment.
3.
Run Verify Database to remove OSS management from the logical target in the target
database.
4.
Restart the Apply.
•
If you back out from a configuration managed by a D46 or later DSM/SCM PVU to one
managed by a pre-D46 PVU, you must revert your DSM/SCM host and target databases to
their pre-OSS management setup.
Fallback Considerations
215