Distribution Concepts

What is object distribution

The distribution function of TD/OMS supported by the modules Object Distribution and Object Receiving, enables you to send and receive software components and configuration definitions to other servers in your network. In that way it is possible to manage a diversity of changes you make from a central source system and implement them on remote sites. The distribution process normally takes place from a main development IBM system, but it is also possible to have a receiving IBM system distributing in its turn components to other servers or nodes in the network. This enables you to divide network traffic and capacity among several sites also resulting in a reduction of time and costs.

A remote server can be an IBM i, a Windows Server, a Unix Server, an application server like WAS or Apache Tomcat or any other supported server.

A special configuration of Distribution is the definition of Distribution registration. Activating that feature results in a complete registration of the distribution and of all request or fix data that are included in that distribution. The distribution is identified by a unique key code. When such a distribution has been sent to a remote server, the installation of its components can be postponed. The content of the distribution is placed in a waiting queue that is implemented as a temporary work library. The correct sequence of installation of waiting distributions is always monitored.

Distribution is triggered by placing objects into a TD/OMS sub-environment (library list) containing distribution entries. These entries are created in the function Environment maintenance which is started from the Application Management menu.

Before distribution entries can be assigned to a library list, you have to create remote location definitions describing remote location characteristics at a general system level. These properties include the network node name, the current operating system release running on the server, the protocol type to use for the physical transfer and some configuration definitions that are send along with the components content of the distribution. The remote location attributes can be customized at a more detailed, application level when general remote location attributes do not apply for a certain TD/OMS application.

How to define remote locations

The term Remote Location is used within TD/OMS to describe system wide configuration characteristics of your IBM i-servers that should receive software component changes that originate from a central source system, where the development has been done. The remote locations are defined using the Remote location maintenance function which can be found on the TD/OMS Distribution management menu.

How to define remote location overrides

The term Remote Location Override is used within TD/OMS to describe configuration characteristics of your receiving IBM i-servers, that are specific for one TD/OMS application. The remote location overrides are defined using the Remote location override function which can be found on the TD/OMS Distribution management menu.

How to define distribution entries

Configuration of Distribution entries that should be connected to a sub-environment, have to be made in the function Environment Maintenance . Once defined, they operate as the actual triggers for the distribution process. In case the TD/OMS engine is executing the transfer of components to one of the environment library lists, the library list type is checked. If the library list has a remote or a mixed, local/remote type, then TD/OMS searches for distribution entries specified for this library list. If an actual entry is found, then the distribution process will be started according to the definition details.

How to configure Distribution Registration

Distribution registration is a remote location or address attribute that can only be defined at the most general, system wide level. That means that for any distribution to an address configured with the Registered Distribution property set *YES, the special distribution registration procedure will become active. The same address definition will not be appropriate for sending distributions at the classic way to the corresponding remote server. If it is necessary to send also common distributions to the same remote server, a separate address configuration named by an alias, have to be defined.

What are the results of Distribution Registration

When the Distribution registration procedure has been activated, the following results can be noticed:

A unique Distribution code is generated and it will be reported in the TD/OMS message log on the sending system.
The Request number if used, all Fixes and other data about the contents of the registered distribution are stored in the actual TD/OMS distribution database tables.
Also all remote locations (addresses) that participate in the registered distribution, are stored in the database.
Based on the contents of Fixes that are part of the distribution, a distribution dependency analysis is processed for all actual, registered distributions that are not completed. In a dependency analysis the order of installation on the remote locations are determined for all open Distribution registrations.
Distribution data stored in the database of the sending server, but also significant for the remote installation process, is saved in a save file and sent as part of the distribution to the remote locations.
Like common distributions without registration and in accordance with the distribution attribute settings, components and/or sources, configuration and definition data are saved and sent to the remote location.
The job script to start the second part of the transfer process (i.e. installation of the distribution) on the remote location is not sent as a remote job command to the receiving server. The job script is sent as a source member in a file and wrapped in a save file.
Another job script is actually sent as a remote job command to start a job on the remote location. This preparation job will execute a restore of save files and of configuration and control data in a temporary work library in order to wait when installation will be requested. Besides it will process the registered distribution data received from the source (development) system in order to inform the installation functions about dependencies and sequence of distribution installations.
When a new registered distribution has arrived and has been prepared on the remote server or when a released distribution installation has been completed, all remaining distribution installations that are waiting in the queue of the actual address, are evaluated once more to determine mutual dependencies that may change the restrictions for installation.

How is a Distribution code generated

A Distribution code may be generated implicitly by an automatic process or may be explicitly created using a manual transaction function. The automatic key generator retrieves the highest key used in the distribution registration database table. Next the numeric part of the key is raised by one and the result is converted according to the distribution code format.

How to link Request and/or Fixes to a Distribution Registration

To create a reference between Request and/or Fixes and a registered distribution may be a fully automatic process or it may linked by manual definition. If the distribution registration mechanism is active for some address, first the distribution process checks whether one or more fixes occur already in the distributed fix database table. If so the existing distribution code referred by that fix, is used to continue the distribution registration process that is currently running. If a distribution does not exist, the next distribution code will be generated and used to continue with the new distribution registration. Another way to create Distribution registration is to assign a request, release or fix to a distribution code before the actual distribution will be processed. This manual definition is a standard option (21) in the interactive user functions Request maintenance and Fix maintenance.

How are installation dependencies of registered Distributions determined

When the Distribution Registration property is active for an actual remote location (server address), it is possible and allowed to postpone the installation of any distribution received on that address. That means the transfer of a Request or one or more Fixes containing certain versions of components, is not directly realised in the available environment as defined on the remote server. After some period the situation may occur that various distributions waiting for installation, contain subsequent versions of the same component. In that case TD/OMS has to monitor which component version is the first to be installed and which version will be the next. This kind of dependency between subsequent distributions is always determined on the source (distributing) system in advance. Critical conditions that determine the distribution dependencies are:

The version number of individual components connected to the Fixes that are part of the distribution.
Components that have been assigned Solution type *terminate: distribution containing the *terminate will be the last to install;
Components that have been assigned follower or leader status: distribution containing the leader will be the last to install.

While dependencies are determined by version values or type of components connected to a Fix, the dependencies are registered at the level of a complete distribution that may contain various Fixes. This is important to be reminded when different versions of a series of the same components are included in different distributions. Those distributions are subsequently sent and put in an installation queue on the remote server. For example if a lower version of component A and the latest version of component B are combined in distribution 1 and next the latest version of A and a lower version of B are also combined in distribution 2, a conflict of installation order will arise. The versions of component A require installation of distribution 1 precedes installation of distribution 2. However the simultaneous presence of component B requires the opposite action. Obviously it should be avoided to include a multiple series of the same components in a series of cumulative distributions.

How to handle installation dependencies of registered Distributions

All information about the installation waiting queue of registered distributions is presented in the Remote location perspective of the TD/OMS Work management GUI client. This PC user application communicates with the distribution installation monitor on the remote server. Distributions that have not any dependency on other distributions in the waiting queue, can be installed at any time. The installation of those independent distributions can even be started by selecting several or all distribution items at once. The installation of a dependent distribution must always be started at the eldest parent in the sequence of preceding distribution installations. A dependent distribution may have dependencies referring more than one other distribution. In complicated situations a distribution dependency may result in a tree with several branches consisting of series of preceding distribution installations. In order to limit many different choices for processing all the necessary distribution installations three options are generally available:

Installation of the complete dependency tree at once including all the branches of sequences of distribution installations.
Installation of one branch until the first node where two branches join each other.
Installation of the outermost leaves (eldest parent distribution) of one, several or all branches.

When an allowed (combination of) installation will be started, the installation monitor on the remote server takes care of all distributions involved and will arrange the correct order of installations. If an installation execution is abnormally finished, the current installation and all remaining installations are preserved in the installation queue. The status of all distribution installations that have been normally completed, are updated in the installation information what means, the dependencies referring the completed parent distributions, are removed. When the installation is restarted according to the common conditions, the installation monitor will ignore the dependencies on the already completed distributions.

What choices must be made when defining a distribution configuration

(1) At which environment level the distribution service will become active?
If you wish to implement distribution services, you have to determine the stage in the life cycle process when it is appropriate to start the physical transfer of software or of installation definitions to the remote system. This issue asks for a thorough reflection of your maintenance procedure. Suppose you make use of a four environment application, e.g. development, test, user acceptance and production. In this cycle you have to define the moment of distribution. If users do acceptance testing on separate systems, you should consider a distribution procedure during the transfer process from test to acceptance phase. If programmer and user acceptance test are only located on the development system, your only need for distribution is when proceeding towards a remote production system or probably when moving from production to production (horizontal transfer).

(2) What remote server addresses are of interest for the distribution service?
You have to determine at which remote servers the actual user application, that is maintained by TD/OMS, is running.

(3) What are the configuration requirements of the remote server and the TD/OMS installation at that address?
Requirements or limiting conditions that may be of interest, are the server OS release, the up and down time of the online server connection, the facilities for starting and controlling remote jobs, the need of sending configuration definitions to the remote TD/OMS installation and optional preferences like distributing compiled objects with or without its corresponding source. Most of these preferences can be defined system wide or at some level within an TD/OMS application.

(4) Is there any preference for definition of a distribution tree?
Because of a tremendous growth of network speed and traffic width, the need for configuring various server in a distribution tree has been minimized. In some rare situations a distribution tree may have advantages for example when a number of remote servers have not frequently or maybe never online connection with the central source system that manages the distribution procedure.

After you have decide how to plan and design you distribution building you can enter all the required definition data into the TD/OMS configuration database. For that definition work the maintenance functions Remote location maintenance and Remote location override in the Distribution Management menu are available to you. Next you have to switch to the library list level of the Environment Maintenance function to add the Distribution entries. Remind that any distribution entry has to be linked to an address definition that can be used for only one type of distribution procedure.

How to configure the sending system

Before you start the configuration of the distribution process read the previous section of this manual. That informs you about the considerations how to set up your distribution channels. After this, you can proceed to define the distribution procedure based on the following checklist.

The sending machine must have the module Object Distribution installed.
If you have purchased this module as part of your TD/OMS installation, then the only thing you have to do is enter the license code for this Distribution module.
If the sending machine has been equipped with a CCSID that differs from that of the receiving machine, make sure that file OMFLT is set to the language independent CCSID value 65535 on all machines.
Create remote location entries (addresses) by starting the Remote Location Maintenance function , which can be found on the TD/OMS distribution menu.
Create remote location override specifications by starting the Remote Location Override Maintenance function, which can be found on the TD/OMS distribution menu.
Create remote library lists. The library list must be of remote location type what means, that valid values are ’1’ or ’2’.
A remote library list can be created in the function Environment Maintenance , which is on the Application Management menu. Use option 12 in front of an environment to enter the definition function Work with Library Lists.
Add distribution entries for each remote location to the library list by using option 8 in front of the remote library list specification.
If using SNADS mechanism, use the command WRKDIRE to check and/or update the network authority level for all TD/OMS users, that will be authorized to start the distribution function.
Add user profile OMS to the directory. These and other network definitions like distribution queues are not part of the distribution module and also not in other functions of the TD/OMS kernel.
If user profile OMS is not linked to corresponding message queue OMS, create that message queue in library QUSRSYS. You need those definitions for use in the Remote Job Monitor function. The Remote Job Monitor is standard part of the TD/OMS distribution module.

Your sending IBM i-server is now ready for use.

How to configure the receiving system

Before you start the configuration of the receiving module of TD/OMS distribution read the previous sections of interest in this user guide. These inform you about the considerations how to set up your distribution channels. After this, you can proceed to define the receiving part of distribution based on the following check-list.

Create the user profile OMS on the receiving system.
Install the TD/OMS kernel software on the receiving systems and next enter the required license codes especially for the receiving module.
The TD/OMS database is also created on a receiving system. This includes all application definitions, the request/ fix management and the component location database. Generally the remote system definitions are automatically created when the transfer job of a distribution arrives.

If you do not use or can not use the automatic configuration options:
Change or create the TD/OMS application definitions. Every TD/OMS application which receives objects from a sending system must be declared. If you do not distribute sources, then change the check source attribute in this application accordingly.

Change the environment definitions. If you are distributing objects on your sending machine during object transfer from some intermediary level to the final production environment, you need to define the full production environment on the receiving system. When you are sending objects in an earlier stage, you will have to define that environment, the production environment and all the environments in between.

Besides the environment on the receiving level and all higher environments, you will have to create an additional environment that is sequenced before the first (lowest) receiving environment. This may be an empty environment. The next figure illustrates an example situation.

Check the application and environment authorization (authorize user OMS) on the receiving system.
If you want to create a distribution tree then you have to create remote locations, remote location overrides and distribution entries. These are the same definitions as described in the section configuration of the sending machine. Next add that defined items to the library lists that are involved.
Create or change the job descriptions that must be used on the remote systems. The use of the job description DMSJOBD is recommended. Which job description is actually used, depends on the definitions of the remote locations which are entered on the sending system.

Use the following values for the keywords:

USRPRF(OMS)

INLIBL(QTEMP omslib)

Where omslib is the library in which TD/OMS resides.

If using SNADS mechanism, check the network attributes.
Use the command CHGNETA to check and/or change the JOBACN attribute. When this attribute contains the value *FILE, the network jobs (which are sent by the sending machine) are not submitted automatically. You will have to release them manually by using the WRKNETF USER(OMS) command and using option 3. For automatic scheduling of network jobs, change the JOBACN value to *SEARCH. The action to be taken then depends on the sender of the job. For every possible sender you have to define the wanted action by using the WRKNETJOBE command. Add the required entries by using the ADDNETJOBE command in the following form

       Add Network Job Entry (ADDNETJOBE)
 
Type choices, press Enter.
 
User ID:                         FROMUSRID
   User ID  . . . . . . . . . . .              > xxxxxxx___
   User ID qualifier  . . . . . .              > yyyyyyy___
 Network job action . . . . . . . ACTION       > *SUBMIT_____
 User profile . . . . . . . . . . SBMUSER      > OMS_________
 Message queue  . . . . . . . . . MSGQ         > *USRPRF_____
   Library  . . . . . . . . . . .                  ____________
 Job queue  . . . . . . . . . . . JOBQ         > jjjjjjj_____
   Library  . . . . . . . . . . .              >   lllllll___

where:

xxxxxxx = The sending user 
yyyyyyy = The node name of the sending machine 
jjjjjjj = The jobq to be used for the batch subsystem
lllllll = The library where the jobq resides

If using TCP/IP mechanism, set-up the TD/OMS TCP server by running the INZOMSSVR command. Please ensure that the generated subsystem gets started after an IPL of the IBM i.

Your receiving IBM i-system is now ready for use.

Which items can a distribution include in addition to native IBM i objects

Life cycle definitions

When TD/OMS encounters a distribution entry on a library list that is part of a fix transfer process, the remote locations override entries are checked for definition changes. Every time a life cycle definition (application details, environments or locations) have been changed, the remote locations override entries will be marked in order to start updating the configuration on remote servers. If life cycle definition data must be distributed (as is indicated in the distribution entries), TD/OMS zips the definitions and transfers them along with the objects.

Sources

If required, TD/OMS also distributes sources of native IBM i (compiled) objects to the remote locations. Remind that sources of logical file objects are always distributed, because logical file type objects are created from source instead of duplicated.

Definitions of Actions and Exceptions

Actions or Exceptions may be defined for execution during the fix transfer on the remote server. If distribution of those definitions has been indicated as required, according to the settings in remote locations and distribution entries, TD/OMS distributes the complete Actions database and the appropriate Exception definitions to the remote locations.

Transfer information

A file with transfer definitions (containing the request/ fix entries and all included solution data for the actual transfer) is distributed. All this information is used on the remote system to update the transfer related database tables. Based on these data the object transfer can be processed on the remote server.

A network job

If a common distribution without registration has to be processed, a single network job is sent to the receiving system. When this network job is started, all save files containing objects and all data files are restored. Next the remote TD/OMS database is updated with all transfer information and finally the actual fix transfer will be started. If a registered distribution for which the installation on remote may be postponed, has to be processed, a special network job is sent to the receiving system. This network job will directly start a pre-process job that restores all save files containing objects, data files and the job script that has been made to start the remote installation. All information will be placed in a temporary installation library exclusively reserved for this distribution.

Distribution Registration information

If the registered distribution function is active, all registration information about previously distributed fixes and about the dependency between those fixes is sent to all remote servers that participate in the Distribution Registration procedure. In addition to the database data an extra job script is saved in a source file member. This additional job will control and process the installation of the distribution content on remote location, see below the description of receiving registered distributions. All data are stored in a separate save file and sent to the remote server.

How does remote job monitoring work

The details of a remote system address entry indicate whether the remote transfer jobs must be monitored. This monitoring is done by use of network messages. The remote job monitor informs the original, sending system about the status of transfer jobs on the receiving, remote systems after distribution.

Start Remote Job Monitor (STRRJM)

The start remote job monitor command (STRRJM) has three job control functions:

1. Starting the Work with Remote Transfer Status monitoring function

This function starts the work with remote transfer status interactive session. This display function shows all or only the active transfer jobs, that have been distributed from the sending machine along with the monitored status. If the transfer is not at an intermediate level, or it has not be normally ended, the monitor allows you a manually closing of the item. This step may be necessary to continue processing of the task on the local system.

2. Process all queued responses from remote locations

This function receives all queued responses from the remote locations. The remote servers send the status of the distributed fix transfer to message queues on the originating system. If the Remote job monitor control function is not active (see point 3), then the responses are queued. This procedure starts processing of all responses, and stores the job status data into the TD/OMS database.

3. Submit an active monitor

The last function of the Remote job monitor command enables you to submit a permanently active monitor. This monitor processes the response messages from remote system addresses, just when they arrive on the originating system. Consequenly all abnormally terminated jobs are brought immediately to the attention of the TD/OMS managers.

Remote Job Monitor special settings

If the default settings result in too many restrctions for you, you can install the Remote job monitor with special control definitions:

If you have needed to install TD/OMS with an other TD/OMS system user profile, not using the default user OMS, and you want to run Remote Job Monitor, first you should pre-define the TD/OMS registry setting: OMQRMTJOBMONUSR.

If the TCP name of the distributing (local) machine on the remote system does not match the name in the host table, defined under CFGTCP, then you should use the TD/OMS registry setting: OMQTCPSYSNAME.

Remote Job Monitor controlling Fix status

In case of active monitoring remote transfer jobs after distribution, the fix status on the local, distributing system may be derived from the transfer status in the Remote Job monitor.

Can TD/OMS inform an user on a remote server

TD/OMS is able to send a job message to a specified user profile on another server for example the distributing system. Sending a message requires the use of the SNA protocol for the TD/OMS distribution. For sending a network completion message from the receiving system to the sending system, when the fix transfer process has finished, create data area DMS001 in the TD/OMS library. Enter starting from position 21 with length 8, the user profile name who must receive the message. Enter starting from position 29 with length 8, the server address name. The same data area DMS001 must also be created on the receiving system.

Application conversion between sending and receiving system

The TD/OMS Remote Application Conversion Maintenance function supports defining conversion of codes or names that are part of the TD/OMS internal configuration. System names like libraries, but also TD/OMS code definitions like application or environment may differ between those specified on the original, distributing system, and those on one or more remote systems. The TD/OMS conversion function enables you to define rules for renaming codes or names of the from-system into codes and names on some target system. This feature is commonly used, when you do not have any control over the TD/OMS configuration definitions of a remote, receiving system.

You can specify conversion names for all remote system addresses or for one, specific remote location. Besides you can define 1 -> 1 (single code is translated into other, single code) conversions and N -> 1 (many codes into single code) conversions.

Please you have to remind, that *global type conversion rules will be processed before distribution on the sending system, but address specific rules will be excuted after distribution on the receiving system. However, if the remote system address is involved in the distribution, all Application conversion data for that specific address are sent to remote location. Consequently, if your distributing system is not in control over the TD/OMS installation on the remote system, your locally defined conversion rules should most accurately obey all the TD/OMS application specifications of the remote system installation.

Technical Description of the Distribution Process

This section describes the technical steps done for the distribution process. We assume that you have setup your remote and local locations as described in the Concepts Guide

Sending standard distributions

This section describes the classic way of distributing objects.

Transfer Number

Any distribution is always part of a TD/OMS fix transfer that is uniquely identified by the Transfer number. This six digits code is automatically generated from its control value in data area OMOTD. During the distribution process the transfer number is also used to assign unique and identifiable names to temporary location references.

Creating object copies for Distribution

When TD/OMS starts an object distribution, the components are copied to a temporary location on the sending server. This location is different for three categories of objects (TTTTTT refers to the transfer number)

Native IBM i-server objects: Native IBM i-server objects are copied to a temporary library with the name ODTTTTTT.

IFS Components: IFS Components are copied into a temporary directory with the name ODTTTTTT in the root of the IFS file system.

QDLS Documents: If you use the old QDLS system then these components are copied into a temporary QDLS folder with the name ODTTTTTT in the root of the folder file system.

Using these temporary location names you may be able, for example, to extend the distribution mechanism by importing your own objects in the distribution locations. You can use exceptions and actions selections with the ’when to activate’ attribute on ’pre distribution ’ to control the extra process steps at this point of the distribution.

After the temporary locations are filled, the IFS, QDLS and native IBM i-server objects are saved in save files and placed in library OMSDISTR as follows:

Native IBM i-server objects: they are stored in save file OMSDISTR/ODTTTTTT

IFS Components: IFS Components are stored in savefile OMSDISTR/IODTTTTTT

QDLS Documents: The folder components are stored in savefile OMSDISTR/DODTTTTTT

4GL Components: 4GL components like LANSA possibly have their own savefile with information (e.g. LTTTTTT refers to LANSA)

Extraction of Definitions

Depending on the distribution settings, the definitions of the remote application are extracted and placed in a "flat file". This flat file is then placed in library OMSDISTR/ORTTTTTT with the member remote location name as the member of the file.

PLEASE NOTE Definitions to multiple remote locations at once will yield in a
            multiple member file. This data member also includes function 
            definitions and selections for exception or action procedures and
            programs that are used in conversion maintenance definitions

PLEASE NOTE that action and exception programs and other programs referred in exception or
            conversion functions are NOT distributed automatically.

Creation of the Remote Job

After saving objects and object transfer information TD/OMS tries to copy, for each remote location, a member with the address name from source file DMRCV located in the TD/OMS library. This member is copied to a member with the same name in file OMSDISTR/RJTTTTTT. If the member is not found in DMRCV then the default member DMRCV is used. This mechanism of job scripting in a source member facilitate you to add specific processing information per system (e.g. setting of the library list, sending of messages, etc..)

Distribution using SNADS protocol

When all save and data files are in place, each file in library OMSDISTR, except the RJTTTTTT, is sent by applying command SNDNETF to address OMS/remote location. The address can also be a distribution list entry (sending to multiple machines at once). You can work with distribution lists using the WRKDSTL command.

A distribution list must always be named OMS - name of remote location

After the files have been placed in the SNADS queue, the file RJTTTTTT is send using the SBMRMTJOB command. If the target server is the same as the sending server, the distribution job is not sent to a remote location, but started with the SBMDBJOB. This enables for distribution to the same system.

If you distribute to the same machine, be carefull with sending definitions for they
 might overwrite current local definitions.

Distribution using TCP/IP protocol

If using the TD/OMS internal queuing mechanism based on internet protocol, then you should have setup the distribution subsystems as described in the Queue Manager manual.

Each file in library OMSDISTR, except the RJTTTTTT, is sent by applying command SNDNETFOMS to address OMS/remote location. The address can also be a distribution list (sending to multiple machines at once). You can work with distribution lists using the WRKDSTL command.

A distribution list must always be named OMS - name of remote location

All save and data files are queued in a separate .../send directory. When the send procedure service notices items being ready to send, the service transfers the files to a .../recv directory on a remote location. The job script file RJTTTTTT is sent by applying the SBMRMTJOMS command. If the target server is the same as the sending server, the distribution job is not sent to a remote location, but started with the SBMDBJOB. This enables for distribution to the same system.

If you distribute to the same machine, be carefull with sending definitions for they
 might overwrite current local definitions.

The queuing of files is controlled through common *STMF type files in various sub paths of the '/QOpenSys/omsqueue' directory. These paths contain the file queue, control files and receiving files and several log files.

Monitor

At this point, an indication is made in the TD/OMS monitor (if activated) that the first step in the distribution completed.

Sending registered distributions

Distribution number

It should be an option that a registered distribution can be processed more than once. Another option is that definition of registered distribution and linking request or fix to that distribution should be made in advance. For that reason the transfer number does not suffice to identify a distribution for the first time and to recognize the same distribution for a second time. A registered distribution is identified by an eight positions, unique distribution code composed of spaces and a number starting from 1 ascending by 1. By replacing the leading spaces with one or more characters the range of Distribution keys can be extended by many millions.

Copying distribution registration data files

In addition to all creation and copy processes that are executed as part of the standard distribution, a registered distribution creates a copy of the distribution registration database and saves this copy in a save file OMSDISTR/DRTTTTTT. This save file is sent along with the other files in a way like the standard distribution, but only to remote locations (addresses), that are marked in Remote Location Maintenance as active for distribution registration and installation.

Creation of the remote jobs

In the case of Distribution registration the job script formulated to start the fix transfer job on remote and normally extracted from the DMRCV file, is not sent as a network job to the remote locations. The remote transfer job resulting from a registered distribution should not be executed until the installation will be confirmed by a manual user transaction and subsequently checked by the installation monitor on the remote server. For that reason the job script of the remote transfer job is changed from member DNRCV to file OMSDISTR/DMRCV with member ORTTTTTT. This file member is also stored in the separate registration save file OMSDISTR/DRTTTTTT. Because the receiving and restore of all save and data files on the remote location must not be postponed, a second network job script is created during the local registered distribution process. This script is extracted from member DRRCV in source file DMRCV and changed to member DRTTTTTT in the same file. Like the standard distribution the DRTTTTTT job script is sent to the remote system by applying SBMRMTJOB (SNADS) or TD/OMS command SBMRMTJOMS using the queuing mechanism based on TCP/IP.

Receiving standard distribution

Depending on the distribution queue settings (when using SNADS) on the remote system, the network job is filed in the receiving queue or dispatched immediately. When using TCP/IP the network job always starts right after its arrival. However the network job does nothing except it starts a TD/OMS procedure to continue distribution processing (and possibly execute your customized code added to the address specific job script as described in Creation of the Remote Job).

The TD/OMS receiving job is dispatched using the job description as defined on the receiving machine. This could result in a job with status HELD in the selected jobqueue.

The network files arrived on the remote server, can be viewed with WRKNETF USER(OMS) for SNADS or WRKNETFOMS USER(OMS) for TCP/IP. This could result in the following list:

                               File   -------From-------  ----Arrival----  
Opt  File        Member       Number  User ID   Address   Date      Time   
     DMRCV       OR013713         15  USER1     SYSDV     08-09-06  12:05  
     DOD013713                    12  USER1     SYSDV     08-09-06  12:05  
     IOD013713                    13  USER1     SYSDV     08-09-06  12:05  
     OD013713                     11  USER1     SYSDV     08-09-06  12:05  
     OR013713    PRODA            14  USER1     SYSDV     08-09-06  12:05

Receiving of Files

When the TD/OMS receiver job starts a monitor message is sent to the sending machine indicating a successful arrival. After that, library OMSRCVNETF is created if it does not exist and all the network files are received in this library. After the receiving process, all save files are restored to a temporary location as follows:

Native IBM i Objects: they are restored in library ORTTTTTT

IFS Components: IFS Components are restored in directory ORTTTTTT

QDLS Documents: These documents are restored in folder ORTTTTTT

4GL Components: 4GL components like LANSA possibly have their own savefile with information (e.g. LTTTTTT is for LANSA)

After restoring the files, TD/OMS builds its internal database based on the extraction definitions of the Application and Environment configuration as defined for the remote TD/OMS installation. Change requests and fixes are created and the restored objects are connected to the fixes.

Remote transfer job

The receiving and preparation phase is finished by sending a monitor message to indicate that the transfer job will start directly. The remote transfer processing is a common TD/OMS transfer job completely identical to the normal, local fix transfer. During this transfer, for any component class (native IBM i, QDLS, IFS) a fallback location will be created with the name OMTTTTTT. In that locations TD/OMS makes a temporary store of all components that will be replaced, and of all fall back information.

After the completion of the transfer a monitor message is sent to indicate the return status of the job.

If the job completed without errors or warnings, all temporary locations created on the remote, are cleaned up. Otherwise they are left on the remote system for an analysis of the problem. After the problem has been resolved the temporary locations can be removed manually.

Receiving registered Distribution

On a remote server address indicated for Distribution registration and queuing of installation, the initial, receiving part of the distribution procedure shows various different details when compared with the standard distribution process. The network files and the remote network job arrive in the same way at the remote system. Commonly the received job script is executed directly after its arrival, because it useless to delay the preparation job. After their arrival the network files of a registered distribution can be viewed in a list like the following example:

                                                          -----Received-----
File(member)            Qtyp   Ftyp    From                Date     Time    
DR021329                file   SAVF    NEWTON.remain.nl   10-06-18 13:59:35
IOD021329               file   SAVF    NEWTON.remain.nl   10-06-18 13:59:35
OR021329(PRODA)         file   PF      NEWTON.remain.nl   10-06-18 13:59:35
OD021329                file   SAVF    NEWTON.remain.nl   10-06-18 13:59:35

Receiving and preparing Distribution registration data

In a first step the remote network job starts a TD/OMS preparation procedure that receives only the DRTTTTTT (TTTTTT refers to transfer number) network file to a save file in library OMSRCVNETF. When the save file is restored into the temporary created library DRTTTTTT, this library contains all distribution registration data of the current address. Next the registration tables are copied or updated to the TD/OMS distribution and installation database on the remote system. In addition the job script to start the installation of the current distribution is copied to a member named ORTTTTTT of the DMRCV file in the standard TD/OMS library. When this first step has been completed normally, the worklibrary DRTTTTTT is cleared.

Receiving configuration and components files

In the second step of the TD/OMS preparation procedure all other network files are received in the appropriate save file or physical data file newly created in the DRTTTTTT library. All files remain in this state until the installation of the related distribution will be started on a user’s request. The worklibrary and its content will be preserved until all elements concerning that distribution have been completely installed without any error.

Installation management of registered distributions

When Distribution registrations have been arrived on a receiving system, the distribution definition and content waiting in the installation queue, can be viewed and managed by use of the graphical TD/OMS Work Management application on a desktop client installation. So you need to have the TD/OMS RCP software or TD/OMS as plugin part of your Eclipse workbench.

Selection & start of Distribution installation

After opening the TD/OMS Work Management GUI first a connection has to be set up with the remote server that receives the registered distributions, as described in Creating a Remote System.

Once the connection has been established you can open the TD/OMS Remote Locations perspective. This perspective has three views for managing the order of distributions installations in the waiting queue. To verify the rules and restrictions to start one or more installations see:CC:How to handle installation dependencies of registered Distributions

Installation monitor of Distribution dependencies

The Distribution installations view within the TD/OMS remote locations perspective shows all the registered distributions that are waiting for installation. The dependent distributions that are subjected to restrictions for installation, are marked and the dependency relations can be shown. When a distribution installation or sequence of installations that are allowed to release, are requested to start, first the installation monitor on the remote server will become active to check the relevant distribution dependencies. All distribution installations that have a “before” dependency with respect to the currently starting installation, must be part of the starting installation or it must be already completed correctly. If the request for starting the installation has been validated, all distribution installations being part of the request, are submitted as separate jobs in a selected job queue from which only one job may become active. The installation monitor controls the right order when placing the separate installation jobs in the job queue. However when the installation jobs are waiting in some job queue, there is always the risk to interrupt the right sequence of processing due to manual actions. For that reason any time when a separate distribution installation starts to process, the installation monitor checks whether the distribution dependencies of that installation will not be violated

CC:Distribution Concepts