How to Version System Customizations Across CA SDM Servers

CA SDM version control helps you to manage the system customizations across all CA SDM servers (client and servers). Depending upon the CA SDM configuration, the following client and servers are used:
CA SDM version control helps you to manage the system customizations across all CA SDM servers (client and servers). Depending upon the CA SDM configuration, the following client and servers are used:
  • Conventional configuration,
    • Client: Secondary server
    • Server: Primary server
  • Advanced availability configuration,
    • Client: Application and Standby servers
    • Server: Background server
Example: As a system administrator, you added a field in the detail_usp_server.htmpl page of CA SDM. Now, you want to synchronize this change across the client and the servers. This example is used throughout the scenario to explain how the customization is synchronized.
The following diagram shows how to version the system customizations across the CA SDM servers:
Diagram depicting How to Version System Customizations Across CA SDM Servers
Diagram depicting How to Version System Customizations Across CA SDM Servers
Follow these steps:
  1. Make changes in CA SDM. In this example, add the new field in the CA SDM HTMPL page.
Verify the Prerequisites
Verify the following prerequisites:
  • Ensure that the ver_ctl option set to the
    value. When a version discrepancy is detected, an upgrade of the affected components is attempted on the client. If the upgrade is successful, the client connection with the server continues; otherwise, the connection terminates. For more information about the ver_ctl option, see the
    Online Help
  • Ensure that the server_secondary_custom.ver file is created at $NX_ROOT\site\mods directory of the primary server or background server (depending upon the CA SDM configuration). All customizations to a version control component must be done in this file. If the file does not exist, ensure that you create it at the same location.
Modify the Server Version Control File
After you complete the customization, (for example, added a field in the HTMPL page) add or update the version control components on the server version control file. A version control component can represent a file, directory, or the client_nx.env environment variable file.
Follow these steps:
  1. Log in to the following server depending on your CA SDM configuration:
    • Conventional: Primary server
    • Advanced availability: Background server
  2. Go to the following directory:
  3. Open the server_secondary_custom.ver file.
  4. Add the following components:
    [ MY_USP_SERVERS_HTMPL ] directory="$NX_ROOT/site/mods/www/htmpl/web/analyst/Analyst" filename="detail_usp_servers.htmpl" version="2.0 , 20121119" o_mode="RW" g_mode="RW" w_mode="RW" file_ctl
    For more information about adding or updating version control components, see the Version Control Component topic.
  5. Save the server_secondary_custom.ver file.
    The version control component is added in the version control file.
Version Control Components
To define a new component,
  • Use the following syntax. Items in
    represent data that you supply. The
    and version parameters are always required. Other parameters are required, depending on the value of
    . All other items represent keywords that you must enter exactly as shown in the following example:
    [ component-name ] version = "x.x, yyyymmdd" control-type filename = "filename" directory = "directory" link = "link-directory" source = "source-directory" effectivity = "effect-spec" checksum min_release = "release" max_release = "release" component_type = "file-type" o_mode = "owner-mode" g_mode = "group-mode" w_mode = "world-mode"
    For more information about the parameters, see Version Control Parameters. For more information about the structure and syntax of version control files, see the .ver files that are installed in the $NX_ROOT\site directory. These files have useful comments and example settings that can help you.
To update an existing component entry,
  • Change the parameter. For example, you change the version number.
To remove control from a component,
  • Edit the component as follows:
    ! uncontrol component-name
Version Control Parameters
The following parameters apply to version control:
  • [ component-name ]
    Specifies the name of an item under version control. The name must be unique and enclosed in square brackets.
    is not case-sensitive. This parameter is required to begin a component definition.
  • version="x.x. yyymmd"
    Specifies a version number (
    ) and a date (
    ) that define the version of the component. This parameter is required, and must be enclosed in double quotes. Version control verifies the version of a component by comparing the version number and date on the server with the version number and date on the client. Both version number and date must match for the component to be considered in sync between the client and server. Optionally, if the checksum property is enabled, the file is verified by checksum verification before being updated.
  • control-type
    Specifies the type of version control for this component. The following settings are valid for control-type:
Specifies that the component represents a directory. You must provide the directory parameter to specify the path to the directory. You can also provide the filename parameter to specify the filename parameter to filter a set of files in the directory. Subdirectories are not upgraded on either UNIX or Windows.
Specifies that the component represents a file. You must provide the directory and filename parameters to specify the path to the file.
Specifies that this component represents the client_nx.env file, which is used to store internal CA SDM environment variables. CA SDM version control and the Options Manager automatically maintain this file. There is one nxenv_ctl component, and its component name must be CLIENT_NXENV.
This is the default control type. It specifies that the component is generic; that is, not associated with any specific external object. You can use a generic component to provide version control for the client as a whole, or for a file or directory too large for an automatic upgrade. Components with a control type of ver_ctl cannot be upgraded; a version mismatch on a ver_ctl component when the server is in UPGRADE mode causes the client connection to fail.
  • filename="filename"
    Specifies the name of a file under version control. It does not contain directory specifications. This parameter is required for file_ctl components, but is optional for directory (dir_ctl) control components. When used with directory components, the filename parameter acts as a file mask to restrict the files associated with the dir_ctl component. For example, if the filename for a dir_ctl component is *.README, then an upgrade from that directory includes only files ending with “.README.”.
  • directory="directory"
    Specifies the path to the directory for dir_ctl components, or to the directory containing the file for file_ctl components. This parameter is ignored for ver_ctl and nxenv_ctl components. The directory path must be enclosed in quotes, and can contain references to environment variables preceded with a $.
    Always use forward slashes (not backslashes) to separate subdirectories in the path name, even on a Windows server.
  • link="link-directory"
    Specifies a link directory on the client in the same format described previously for directory parameter. This parameter is optional for file_ctl and dir_ctl components, and ignored for ver_ctl and nxenv_ctl components. If it is specified, an upgrade to a Linux client causes a symbolic link to be placed in the link directory, pointing to the actual file copied to the location specified by the directory parameter. An upgrade to a Windows client causes the actual file to be copied to both the link and directory locations.
  • source="source-directory"
    (Optional) Specifies a different directory on the server where the server can retrieve files for delivery. This parameter has the same format described previously for the directory parameter. It is useful if the files that are to be delivered to the client are different from the same files in the directory location on the server. This parameter is used to tell the server to retrieve the file from
    and deliver it to the location on the client specified by the directory parameter. The directory parameter is required if you specify the source parameter.
  • effectivity="effect-spec"
    (Optional) Specifies whether the client should get this component. It lets you exclude download to some clients. If a client is not included in the effectivity specification, it does not get the component. If this parameter is omitted, all clients receive the component. The effectivity specification uses the following symbols:
    • + (plus sign)
      Indicates to add a client group.
    • - (minus sign)
      Indicates to exclude a client group.
The following client groups are valid:
  • AIX
  • LINUX390
  • HP
For example, the following specification indicates that only UNIX clients get the files:
effectivity = "+ UNIX_CLIENTS"
  • checksum
    Directs the component to upgrade if the checksum of the component on the client does not match the corresponding checksum on the server. If it is applied to a directory, then checksum is applied to each file.
  • min_release=“release” and max_release="release"
    Specifies the oldest and latest client to which this component should be distributed. Statements in the server_default.ver file define releases. These parameters are in the following form, where Ga
    indicates the release, and the values following are genlevels associated with the release.
    ! Release GA50 50MVV000900 50W7T000900 ! Release GA45 45MW000900 50WTT000900
    The order indicates that GA50 is newer than GA45.
  • component_type
    Specifies the type of component used. Following types of components are used:
This is the default component type. It specifies that files copied to the client be obtained directly from the location on the server indicated by the directory parameter.
Specifies that files copied to the client be obtained from a location on the server that is dependent on the client’s operating system, as shown by the following:
windows (Windows)
sun4Sol (Solaris)
hp (HP-UX)
aix -- AIX)
linux (Linux)
linux390 (Linux390)
Locations for these subdirectories are dependent on the directory parameter setting. If this parameter is set, then subdirectories are located under the indicated
. Otherwise, they are located under the bin directory of the main CA SDM installation directory.
  • o_mode="owner-mode"
    Specifies file access permissions for the owner of the file.
  • g_mode="group-mode"
    Specifies file access permissions for users in the file owner group (used for UNIX clients only).
  • w_mode="world-mode"
    Specifies file access permissions for users not in the file owner group (used for UNIX clients only).
    The three mode parameters allow different versions of the same executable to be maintained on the server. They specify access controls on the file when copied to the client. These parameters are used only during an upgrade operation. They consist of one to three characters, with the following significance:
PC clients ignore Write and Execute permissions.
You can specify any combination of one or more file access modes. On UNIX clients, the file is given the access mode of specified. On PC clients, the file is made writable or read-only, depending on whether w_mode has been specified.
Restart CA SDM on Client
You restart CA SDM on the client servers to update the client version control files with the customizations.
Control Panel
Administrative Tools
. Right-click the
CA SDM Server
and choose
to restart or start a server.
Follow these steps:
  1. For the conventional configuration, restart the secondary server.
  2. For the advanced availability configuration, complete the following steps:
    1. Restart all standby servers.
    2. Restart the less active application server.
    3. Start the application server.
    4. Performs steps d and e for more application servers.
    The client connects to the server to send a list of its controlled components. The server compares the list to its own master list. The affected components on the client are upgraded.
Choose the Less Active Application Server
You choose an application server with the least user activity. Run the following command on each application server to choose the one with no or minimal active sessions.
: This command does not capture the SOAP or REST Web Service sessions.
Stop the Other Application Server
You inform all the active users on an application server to move to the less active application server before you stop it. Ensure that you have restarted the less active application server before moving all the users to it.
Follow these steps:
  1. (Recommended) Inform all active Support Automation analysts on the application server which you want to stop, to create a ticket in CA SDM with their session information. This process ensures that the session information is not lost. For example, the Support Automation analyst is in a session with a customer to resolve a hardware issue. In such a case, the Support Automation analyst can create an issue in CA SDM with the session information before the application server shuts down.
  2. Send a notification (for example, an email notification) to all the active users on the application server to move to the less active application server that you just restarted. This notification can include the details of the updated application server.
  3. Execute the following command on the application server:
    pdm_server_control [-h] -q interval -s server_name
    • -h
      Displays the help page.
    • -q interval -s server_name
      Notifies a local or remote application server to quiesce in a specified time interval.  This interval is the number of seconds before the server goes offline. When using this option without a server_name, the local server is notified to quiesce. This option cannot be used for a background or a standby server.
    A pop-up message is displayed to all the active users on the application server to notify them about the server shutdown and the time left for the shutdown. The users must save their work and logout within that time. The application server stops after the specified time. The users log on to the other application server to resume their work. The Support Automation analyst can refer to the ticket and resume their work.
    The application server is stopped successfully.
Verify the Customizations on the Client
You verify the version control file on the client to check if all customizations have been synchronized.
Follow these steps:
  1. Log in to the following client depending on your CA SDM configuration:
    • Conventional: Secondary server
    • Advanced availability: Standby server and Application server
  2. Open the stdlog file from the following location:
  3. Find out if all the customizations made on the server are applied on the client.