DSMSCM Subsystem
DSM/SCM Subsystem
The Distributed Systems Management/Software Configuration Manager (DSM/ SCM) provides centralized planning, management, and installation of software on distributed (target) HP NonStop servers.
DSM/SCM runs on an HP NonStop server (host) and receives, archives, configures, and packages software for distributed (target) systems. From the host system, one uses DSM/SCM to transfer software files to target systems. DSM/SCM also runs on each target system, where it places (or applies) the software received from the host system.
DSM/SCM is a complex, multi- faceted utility that should be used and run by system knowledgeable personnel.
DSM/SCM Methodology
DSM/SCM has several parts :
Receive New Software into Archive
Create a Software Revision
Build new Revision
Apply the new Revision
Activate the new Revision on the Target System
Receive New Software into Archive
The first step in building a software configuration revision is to receive the new software (input) into the DSM/SCM archive. A software input consists of one or more products, which can be HP, customer, or third-party software, on either disk or tape.
When software is received, the files from each product are stored in the archive, and the file attributes are stored in the database.
RISK Once the software has been downloaded or restored from tape, but not received into DSM/SCM, the files are not compressed and therefore vulnerable. Files should be received into DSM/SCM immediately for compression and to mitigate this risk.
RISK The SUT tape should be stored in a secured place for both disaster recovery purposes and to prevent unauthorized access and modification.
Once received into DSM/SCM, the restored files are transitioned into a compressed format used only by the DSM/SCM subsystem.
RISK Generally there is no risk to the use of these files, except by DSM/SCM subsystem users.
Create a Software Revision
After receiving all required inputs into the DSM/SCM archive, plan and create a new software revision for the target system. A software revision is a list of products stored in the archive that together are built into a configuration revision. When creating a software revision, ensure that all products included are compatible with each other and that all requisite SPRs are accounted for.
As each new software revision is archived, it is up to the system administrator to determine when a new operating system upgrade is required. Not all products apply to all systems, and multiple revisions may be applied at one time to minimize impact to the running system
When the system administrator decides to upgrade the operating system, the inclusion of software for this revision is created with DSM/SCM and defined to DSM/SCM's database.
Build and Apply new Configuration Revision
A new configuration revision is the package that DSM/SCM builds to transfer the products listed in a software revision from the archive to the target system. After the
configuration revision is built and transferred to the target system, it is applied to the target system.
The target system can be the local system or a remote system. DSM/SCM can create and build software revisions for multiple systems and multiple software revision levels, as defined by the system administrator.
The activation package is built into a temporary location on $VOL.ZAnnnn.
RISK In some cases the BUILD step is done some period of time prior to the system cold load that brings the new revision on line. These temporary staging areas must be secured from tampering during the staging period.
Activate the new Revision on the Target System
Once an activation package is applied to a target system, the target system operator must activate the software before it can be used. Activating the new software involves preparing the system for the new software, then starting the new software
Software activation is outlined in operator instructions included with the activation package and viewable through the Target Interface. DSM/SCM generates operator instructions that might vary depending on the software being installed. Also, the planner might have edited the instructions to include site-specific tasks earlier in the configuration process. Only the instructions required for the particular installation are included in the activation package.
Finally, the software revision is activated on the server. In many cases the revision may require a full cold load. In other cases the revision may require the stopping and restarting of subsystems.
A new SYSnn subvolume will be created or updated
A new CSSnn subvolume will be created or updated
Following the activation of new software, the rename function moves software components into their final location. Rename is performed from a TACL running the ZPHIRNM program.
The appropriate files in $SYSTEM.SYSTEM will be replaced
The appropriate files in TSV subvolumes will be replaced
RISK File security is propagated to the new operating system. For instance, if the DIVER object file is owned by 255,255 and secured "UUUU", this security will be propagated into the next operating system
RISK A default security can be set within DSMSCM for new files. This should be set as "CUCU" and later expanded as determined by the security administrators.
Securing DSMSCM Components
BP-PROCESS-DSMSCM-01 The $YPHI Pathway application should be running.
BP-FILE-DSMSCM-01 DSMSCM* object programs should be secured "UUCU".
BP-OPSYS-OWNER-03 DSMSCM* object programs should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-03 DSMSCM* object programs reside in $<dsmscmvol>.ZDSMSCM.
BP-FILE-DSMSCM-02 DSMSCM* non-object files should be secured "CCCU".
BP-OPSYS-OWNER-03 DSMSCM* non-object files should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-03 DSMSCM* non-object files reside in $<dsmscmvol>.ZDSMSCM.
BP-OPSYS-LICENSE-03 CBEXE must be LICENSED.
BP-OPSYS-PROGID-03 CBEXE is PROGID'd.
BP-OPSYS-LICENSE-03 TAEXE must be LICENSED.
BP-OPSYS-PROGID-03 TAEXE is PROGID'd.
BP-FILE-DSMSCM-03 DSMSCM SQL Catalog should be secured "CCCU".
BP-OPSYS-OWNER-03 DSMSCM SQL Catalog should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-03 DSMSCM SQL Catalog resides in $<vol>.<?>.
BP-FILE-DSMSCM-04 DSMSCM SQL Database should be secured "CCCU".
BP-OPSYS-OWNER-03 DSMSCM SQL Database should be owned by SUPER.SUPER.
BP-OPSYS-FILELOC-03 DSMSCM SQL Database resides in $<vol>.<?>.
If available, use Safeguard software or a third party object security product to grant access to DSM/SCM object files and Pathway environment. Access should be granted to users who require access in order to perform their jobs.
BP-SAFE-DSMSCM-01 Add a Safeguard Protection Record to grant appropriate access to the DSMSCM Pathway environment and DSM/SCM files.
| Discovery Questions | Look here: | |
|---|---|---|
| FILE-POLICY | Who are the users who should have access to the DSM/SCM application? | Policy |
| PROCESS-DSMSCM-01 | Is the $YPHI process running? | Status |
| OPSYS-OWNER-03 | Who owns the DSM/SCM Pathway Objects in $<dsmscm-vol>.ZDSMSCM.? | Fileinfo |
| OPSYS-OWNER-03 | Who owns the DSM/SCM files in $<dsmscm-vol>.ZDSMSCM.? | Fileinfo |
| OPSYS-OWNER-03 | Who owns the DSM/SCM subsystem files in $<dsmscm-vol>.ZDSMSCM.? | Fileinfo |
| OPSYS-OWNER-03 | Who owns the DSM/SCM catalog and databases? | SQLCI |
| OPSYS-LICENSE-03 | Is the CBEXE object file licensed? | Fileinfo |
| OPSYS-LICENSE-03 | Is the TAEXE object file licensed? | Fileinfo |
| OPSYS-PROGID-03 | Is the CBEXE object file PROGID'd? | Fileinfo |
| OPSYS-PROGID-03 | Is the TAEXE object file PROGID'd? | Fileinfo |
| SAFE-DSMSCM-01 | Is the $YPHI Pathway correctly secured with Safeguard? | Safecom |
| FILE-DSMSCM-01 | Is the $<dsmscm-vol>.ZDSMSCM.* object files correctly secured with the Guardian or Safeguard system? | Fileinfo Safecom |
| FILE-DSMSCM-02 SAFE-DSMSCM-01 | Is the $<dsmscm-vol>.ZDSMSCM.* files correctly secured with the Guardian or Safeguard system? | Fileinfo Safecom |
| FILE-DSMSCM-03 | Is the DSM/SCM SQL catalog secured correctly? | SQLCI |
| FILE-DSMSCM-04 | Are the DSM/SCM SQL database objects secured correctly? | SQLCI |
Related Topics
DSM/TC
SQL
SYSGEN
