DSM/SCM User's Guide

Introduction to DSM/SCM

DSM/SCM User’s Guide — 529846-014

1 - 9

Managing the SYSnn Subvolumes

DSM/SCM creates a new operating system image, if needed during the Build request.

For software updates that do not require system generation, you can use the current

SYSnn. When system generation is required for an RVU or SPR, you must specify a

new SYSnn. However, you should minimize the number of SYSnn subvolumes on

each target. DSM/SCM requires only one SYSnn in order to operate. If you need to

back out to a previous revision, you need the previous SYSnn if the previous revision

was not on the current SYSnn.

File Types Supported

DSM/SCM supports both Guardian and OSS file types along with the format 2 files <

2GB.

Guardian File Types Supported

All Guardian files are always accessible to all logical targets.

OSS File Types Supported

DSM/SCM supports the management of these OSS file types:



Directories



Hard and symbolic links



Regular files (disk files)



FIFOs

You can configure DSM/SCM to manage OSS files. DSM/SCM requires that all OSS

products contain an A7CINFO file. If you do not configure DSM/SCM to manage OSS

files, you must use COPYOSS and PINSTALL. Use COPYOSS and PINSTALL only if

some OSS products are not DSM/SCM-enabled. You must use COPYOSS for those

files, but you can use DSM/SCM to manage everything else.

For DSM/SCM, a physical target system might have more than one OSS hierarchy, but

only one OSS hierarchy can run and be accessible at a time. An OSS hierarchy must

be running for DSM/SCM to manage the OSS files in it. For an OSS hierarchy to run,

the $SYSTEM volume

on which ZXOSSMON exists must be the system load volume

that is currently running.

Caution. Do not use COPYOSS to install OSS files that DSM/SCM manages. Doing so

replaces the DSM/SCM-managed files, which can make it difficult to determine whether OSS

files are managed by DSM/SCM. This confusion can cause problems in managing OSS files

with DSM/SCM.