CDP reference information

• Information is organized using elements, each of which is represented by a start tag and an end tag. The start and end tags have identical names, except that the name of the end tag is preceded by a slash (/). In the following example, the outermost pair of begin and end tags describes an element called ServerList. The <ServerList> tag is the begin tag and the </ServerList> tag is the end tag. Everything in between these tags, including other tag pairs, is the content of the ServerList element.

  <ServerList>
    <Server name="SERV1" primaryServer="true"  type="broker"></Server>
  </ServerList>

• Elements of the form <element_name>content</element_name> are used to specify the type and content of each piece of information. The begin and end tags of an element indicate the type of the information located between them. For example, the tags <ServerList>...</ServerList> indicate that the information between the two tags is a list of servers.
• Elements can have attributes, which are included within the begin tag. Example: <OU name='BANKA'> has the attribute name, which has the value BANKA.
• An element that contains no content between the start and end tag pair (<element_name></element_name>) can instead use a single tag of the form <element_name/>. For example, the following are equivalent:

  <OU name="BANKA"></OU>
  <OU name="BANKA"/>

• Lines that begin with the characters <!-- indicate a comment. A comment can span any number of lines, and is ended by the characters -->.

• Inserts Placeholder elements within each element to which they apply:
  • Instance
  • Server
  • OU
• Creates the broker list section with the following elements:

  <BrokerList>
   <Broker servername="SERV1">
    <ExecutionGroupList>
     <ExecutionGroup name="EG1">
      <BrokerArchive additionalinstances="0" commitcount="1" commitinterval="0" name="barfile"/>
     </ExecutionGroup>
    </ExecutionGroupList>
   </Broker>
  </BrokerList>

dnicdp

This script starts the CDP in customization mode. Use this mode when generating deployment data either:

• To set up an initial FTM SWIFT runtime environment (customization)
• To modify an existing runtime environment (re-customization), for example, to add or remove OUs or servers, or to modify service bundle assignments

During re-customization, the CDP compares a modified CDD to the CDD that is currently implemented, and uses the contents of its internal customization definition data directories to create the necessary deployment data. After the new deployment data has been deployed, issue the implement command to make the modified CDD into the new current CDD. If necessary, you can roll back the implement command by issuing the recover command.

In customization mode, the CDP command prompt looks like this:

C-DNIvINST->

dnicdpm

This script starts the CDP in migration mode. Use this mode only when applying a program temporary fix (PTF) to an FTM SWIFT installation. The CDP generates the deployment data needed to migrate an existing runtime environment to a new level.

The PTF readme file contains migration instructions that describe how to generate the necessary deployment data. The CDP determines which deployment data is needed by comparing the level of the data in its internal customization definition data directories with the level of the data provided by the PTF, and updates its data as required. When migrating, do not change the current CDD unless instructed to do so by the migration instructions. After migration is complete (that is, after the deployment data that was generated for the migration has been deployed), issue the implement command to update the internal customization-definition data directories. If necessary, you can roll back the implement command by issuing the recover command.

In migration mode, the CDP command prompt looks like this:

M-DNIvINST->

dnicdp[m] -i DNIvINST [-ini ini_file] [-trace on|off]

DNIvINST

The name of the instance to be customized or migrated.

ini_file

The name of the initialization file that is to be used. This initialization file is described in Preparing a CDP initialization file. The default is set by the DNICINIFILE environment variable.

-trace on|off

Determines whether trace information is to be written to the file specified in the TraceFile element of the initialization file (see Table 1). Switch tracing on only if asked to do so by your IBM® service representative.

dnicdp -i INST1 -ini /var/ftmswift_v300/cus/dnicdp.ini -trace off

check -delta|-current|-target [file_name]

Generates a resource distribution report according to the specified option. For an example of a resource distribution report, see Figure 11.

The following options determine the contents of the generated resource distribution report:

-delta

The report contains information about all resources that will be added to, changed in, or deleted from the current customization definition if the target customization definition is implemented.

-current

The report contains information about all resources that would result from implementing the current customization definition.

-target

The report contains information about all resources that would result from implementing the target customization definition.

If no file is specified, the report data is sent to standard output only; otherwise, it is also stored in a file with the name specified.

export [-desc] file_name

Exports the current customization definition to a CDD with the specified file name. Use this command if the current CDD for an instance (that is, the CDD for that instance that is marked as implemented) is lost or corrupted, or if you want to be certain that the CDD you plan to modify is identical to the CDD stored internally by the CDP. If the option -desc is specified, descriptions of the placeholders and service bundles are inserted into the CDD as comments.

explain msg_id

Displays an explanation of the CDP message with the specified message ID.

help [command]

Displays information about the specified command or, if no command is specified, all commands.

import file_name

Imports a new target customization definition from the CDD with the specified file name:

• In customization mode, this CDD contains the changes needed for re-customization.
• In migration mode, this CDD must be identical to the implemented CDD, unless the migration instructions in the PTF readme file advise you to change the CDD.

implement

When the CDP runs in customization or migration mode, this command:

• Overwrites the previous customization definition with what was, until now, the current customization definition
• Overwrites the current customization definition with what was, until now, the target customization definition

When the CDP runs in migration mode, this command also:

• Creates a backup copy of the previous customization definition data directories
• Creates a backup copy of the deployment directory for administration modules
• Overwrites the current customization definition data directories with the contents of the customization definition data directories contained in the FTM SWIFT installation directories

This ensures that the current customization definition stored within the CDP is synchronized with the current runtime systems. The previous version can be recovered (see the description of the recover command).

prepare -delta|-full [-ignoresteps:com.ibm.dni.CLI_CON,com.ibm.dni.CLI_USR] [-display]

Generates the deployment data and deployment instructions. The deployment instructions are stored in the file:

deployment_dir/DNIvINST/timestamp/instructions.txt

-delta

Generates only the data necessary to modify the current environment so that it corresponds to the target customization definition, taking into account all resources defined in previous customization steps. For example, if a target customization definition was created by deleting an OU from and adding a server to the current CDD, this step would generate the deployment needed to:

• Delete the resources used by the deleted OU
• Create the resources used by the new server

-full

Generates all deployment data required to set up the complete target environment. This parameter is valid only if the CDP was started in customization mode, that is, by entering dnicdp.

-ignoresteps:com.ibm.dni.CLI_CON,com.ibm.dni.CLI_USR

This causes the deployment vehicles not to be separated into separate vehicles for "create and commit", "approve", and "deploy" steps. If dual authorization is switched off, a single person can carry out all these steps at once, using a single vehicles. Use this parameter to reduce the number of files that are generated, and hence the number of deployment steps.

-display

The deployment instructions are also sent to standard output.

quit

Ends the CDP, and unlocks the instance so that other users can customize it.

recover

Replaces the current customization definition with the most recent previous version (that is, with the customization definition that was current just before the implement command was last issued for this instance) and ends the CDP:

• In customization mode, the recover command replaces the current customization definition with its predecessor.
• In migration mode, the CDD has not changed, so the recover command returns the current customization definition to its state before migration.

After this command was issued, the CDP must be restarted.

show -delta|-current|-target [file_name]

Generates a customization definition report according to the specified option. For an example of a customization definition report, see Figure 9.

The following options determine the contents of the generated customization definition report:

-delta

The report contains information about all service bundles and placeholders that will be added to, changed in, or deleted from the current customization definition if the target customization definition is implemented.

-current

The report contains information about all service bundles and placeholders for the current customization definition.

-target

The report contains information about all service bundles and placeholders that would result from implementing the target customization definition.

If no file is specified, the report data is sent to standard output only; otherwise, it is also stored in a file with the name specified.

status

Displays information about the status of the current customization. Issue this command to check whether a customization operation is still pending.

supplement [-desc] input_file output_file

Reads the customization definition from the input file (an initial CDD) and:

• Inserts any missing placeholder elements
• Removes any unnecessary placeholder elements
• Creates a broker list section in the CDD if there is not one already or, if there already is one, inserts or removes BAR files as needed. If you assign or remove an SVB from the assignment list, the supplement command adjusts the broker section accordingly. After a recustomization, it is recommended that you open the CDD and check the assignment of BAR files to execution groups.
• Writes the supplemented customization definition to the output file (an intermediate CDD)
• To make it easier to locate placeholders that were newly added, such placeholders are flagged with a <!–-NEW–-> comment.

If the option -desc is specified, descriptions of the placeholders and service bundles are inserted into the intermediate CDD.

 1

This is a separator line that indicates the instance to which the deployment instructions apply.

 2

This line repeats the name of the instance.

 3

The deployment data directory is the directory in which the resource files for the instance are stored. It contains one subdirectory for each server in the instance.

 4

The deployment data sets are the partitioned data sets (PDSs) in which the deployment vehicles are stored. Each deployment data set has a name of the form

hlq.DNIvINST.date_code.server

where:

hlq

The high-level qualifier as defined in the customization initialization file (DNIvINST.ini).

DNIvINST

The name of the instance.

date_code

The date in the form ydddhhmm, where:

y

A letter indicating the year (A=2000, B=2001, …, J=2009, K=2010, L=2011, …, P=2015, Q=2016, R=2017, …).

ddd

The day of the year (for example, 365 = 31 December in a non-leap year).

hh

The hour of the day.

mm

The minute of the hour.

server

The name of the server.

Each deployment vehicle is stored in a separate PDS member. The name of each member is eight characters long, and composed of the name of the resource class followed by a serial number, for example, DB000000, ESM00000, or DBGNT000.

 5

This is a separator line that indicates the server to which the following portion of the deployment instructions apply.

 6

This line repeats the name of the server.

 7

This line indicates the subdirectory of the deployment data directory in which the deployment vehicles for the server are stored.

 8

The deployment vehicle data set is the PDS in which the deployment vehicles for this server are stored. Each vehicle is stored in a separate PDS member.

 9

This is a separator line that marks the beginning of the section containing instructions that result in the creation, modification, or migration of resources for this server. Instructions that result in the removal of resources, if any, are located in a previous section. For each server, removal of resources must take place before creation, modification, or migration of resources.

10

This is a separator line that indicates the resource class to which the following portion of the deployment instructions apply.

11

This line repeats the name of the resource class. The value in parentheses is the full name of the resource class, including a qualifier that uniquely identifies the service bundle set to which the resource class belongs.

12

This line indicates the subdirectory of the deployment vehicle directory in which the resource files for this resource class are stored. These files are required only if the administrator who deploys the corresponding resources elects not to use a deployment vehicle.

Note: This directory is also listed when resource files or deployment vehicles are not needed and so are not created; for example, when the deployment instructions require only that message flows be deleted. In such cases, this directory can be ignored.

13

A deployment vehicle is a job or other executable file that is used to deploy resources. Each vehicle corresponds to a particular resource file. A deployment vehicle contains the same resource definition statements as its corresponding resource file, but might contain additional statements as well, such as job control statements. Sometimes, more than one vehicle might be provided for a single resource file, for example:

• One that contains only the statements needed to deploy the resources
• One that contains a job that, when run, deploys the resources

An administrator can use any of the provided deployment vehicles to deploy the corresponding resources. If an administrator elects to use a deployment vehicle, the resource files for that class can be ignored.

Alternatively, an administrator can elect to use the statements stored in the corresponding resource files (these are identical to the contents of Vehicle #1). The resource file is located in the indicated resource file directory.

14

This line indicates which administrator is to deploy the resources.

15

This section contains the instructions that apply to this vehicle or resource file.