Deploy

The ISPW-Deploy-Reference outlines a 15-step process for setting up a deployment. We will follow those steps showing a sample setup for deploying Natural objects. Refer to the ISPW Deploy Reference guide for additional details. This section shows completed entries. Use the various Add functions to create your entries.

This section provides information about the following topics:

• • 1. Define a Deployment Category
  • 2. Define Deploy Types
  • 3. Associate Deploy Types to ISPW Types
  • 4. Define Deploy System
  • 5. Define a CT Server for Remote Deployment
  • 6. Define a Warehouse for Staging
  • 7. Define Deployment Domain
  • 8. Assign Domain to Application
  • 9. Define Deploy Environment
  • 10. Add Targets to Deploy Sub-Environment
  • 11. Add Deploy Type “Names”
  • 12. Activate Deployment Environment
  • 13. Indicate Deployment on Application
  • 14. Indicate Implementation for Each Type
  • 15. Specify Deployment Environment
  • 16. Refresh the Server
  • Other Deploy Notes

1. Define a Deployment Category

2. Define Deploy Types

We defined a deploy type for each type of Natural object. The following figure shows all of the defined types.

Defined Types on Deploy Type Table Screen

The following figure is a screen showing the definition for one type. The only difference between them all is the Deploy Type.

Type Definition on Browse Deploy Type Detail Screen

3. Associate Deploy Types to ISPW Types

As stated in the ISPW-Deploy-Reference: “ISPW Types defined within an Application are associated with Deployment Types at the Stream level.” Here’s one association. You need one of these for each ISPW Type/Deployment Type pair.

Association on Browse Stream NATR Component Type (M.ST/T) Screen

4. Define Deploy System

Here’s the one Deploy System for our example.

Browse Deploy System Detail Screen 

5. Define a CT Server for Remote Deployment

Note that in this example (Browse Server Table Detail Screen), the CT server is set up for remote deployment. The Deploy flag is set to Y and there is a valid Socket number.

Browse Server Table Detail Screen 

6. Define a Warehouse for Staging

The ISPW-Deploy-Reference recommends using a warehouse to stage the Natural objects prior to deploying them to a remote LPAR. The following figure shows the warehouse definition used in our example setup.

Warehouse Definition on the Browse Warehouse Table Detail Screen 

7. Define Deployment Domain

Here is the Deploy Domain for our example setup.

Browse Deploy Domain Detail Screen 

8. Assign Domain to Application

This is where you associate the deploy domain with the application. You must be in Update mode to perform this function. The following figure presents the screen showing the added domain.

Modify Application Stream Definition (M.AD) Screen 

9. Define Deploy Environment

This step and the following two steps are closely related. You are seeing a completed setup, so you will not see the screens used to create these entries. Refer to the ISPW-Deploy-Reference for those details. The following figure is a screen shot showing a defined deploy environment, named NADPENV.

Reference Data Maintenance (M.R) Screen

10. Add Targets to Deploy Sub-Environment

A deploy sub-environment, NADP, is shown in the following figure.

Deploy Sub-Environments Screen 

The following figure shows a target added to the deploy sub-environment.

Browse NADPENV - NADP Target Screen 

11. Add Deploy Type “Names”

Define an existing dataset that will contain the Natural objects that are to be deployed. This dataset must already exist and have the appropriate characteristics to house Natural objects. Here’s a screen (NADPENV - NADP Storage Names Screen) showing all of the deploy types and their storage datasets.

NADPENV - NADP Storage Names Screen 

The following figure shows the details for one of the storage definitions.

Browse NADPENV - NADP Storage Name Screen 

There are a number of interesting values shown. In the Implementation Process, the Type is set to C. That means the object is copied to the dataset defined in the Storage section of the screen. In the Activation Process, an RX job will perform the actual deployment. The Natural object in the Storage dataset is the thing that is deployed.

12. Activate Deployment Environment

You would need to be in Update mode in order to activate the deployment environment. The Active flag is set to Y.

Update Mode on Reference Data Maintenance (M.R) Screen 

13. Indicate Deployment on Application

The following figure shows that deploy occurs when objects are promoted to the PRD level. Note the D value in the Impl Exit field.

Deploy on Browse Application NATR Stream NATR Level (M.AD/L) Screen 

14. Indicate Implementation for Each Type

Every ISPW type participates in deploy at the PRD level, as shown in the following figure.

Application NATR Stream NATR Flags (M.AD/F) Screen 

15. Specify Deployment Environment

In this final setup step, you are at the Levels in the Stream definition. You select E against the level that you’ve selected for deploy. The following screen is displayed.

Deploy Environment Implementation T Screen 

Select the entry shown, and the screen in the following figure will be displayed.

Browse Deploy Environment Implement Detail Screen 

16. Refresh the Server

This is not part of setup, but it is something that you must do when you have completed all of the above steps: Refresh the server! 

Other Deploy Notes

Make sure the RX started task has access to the target deploy dataset as defined in your deploy sub-environment.

In a multi-LPAR environment, make sure the RX started task runs on the correct LPAR.

You must define the RX DSN prefixes in the External Reference (ER) data as follows:

• RXDPLOGP – RX log DSN prefix
• RXLOGPFX – RX DSN prefix.

You may have to update REXX EXEC WZU@ACI#:

• In routine Main_Process, check for the full name of deploy category.
• In routine Process_NATRL_Item, check the deploy type starts with NATR or whatever you named your deploy types.

The database information, as defined in the extension data, must be the same on all systems. Let’s say you have the following definitions for your ISPW where you perform your development. The columns are your life cycle levels, and the rows contain the database information. When you deploy to your remote systems, the database information on that system must match what you’ve defined on your development system. The deploy processing reads the database information defined on your development system. If this information does not match on all target systems, you will get failures when you deploy to them.