In order to start an instance of the TDI server when the Unix System Service of z/OS is started, have the HFS data set for TDI mounted before the Unix Service is initialized.
This could be done by adding a record for mounting the HFS data set to the BPXPRM01 data member of the USER.PARMLIB data set.
For example the record for mounting the HFS data set might look like this:
MOUNT FILESYSTEM('TDI.V7R1M0.HFS') TYPE(HFS) MODE(READ) MOUNTPOINT('/usr/lpp/itdi')
After mounting the HFS data set permanently, we should add a record in the /etc/rc file that starts an instance of the TDI Server. The record in the /etc/rc file must specify the solution directory.
For example:
/usr/lpp/itdi/ibmdisrv -s /u/musala/tdi_solutions -c rs.xml -r al
In order for the changes in the USER.PARMLIB(BPXPRM01) data member and the /etc/rc file to take effect, the z/OS computer needs to be re-IPLed (rebooted).
TDI ships with an example in order to illustrate how a TDI instance can be started as a normal z/OS task. It consists two parts: shell script and JCL.
Shell script: iditask.sh
The shell script iditask.sh can be found in the TDI_install_dir/bin folder (by default usr/lpp/itdi/bin). It contains the actual shell command for starting a TDI instance as well as exports several environment variables, which are needed by the further processing of the script by the z/OS native program.
The script sets the JAVA_HOME environment variable to the path of the Java 6 JVM, which is the required version to run the TDI server, and exports the LIBPATH variable by adding the TDI installation directory to it.
In order to run any child processes in the same address space as the started task the environment variable _BPX_SHAREAS is set to YES in the script.
The script implements logic to distinguish the actual installation directory of TDI under which it is visible in USS. In TDI 7.1, the iditask.sh script invokes the ibmdisrv command and passes it all arguments received from the ADITASK JCL script when invoked. The actual command doing this is as follows:
$TDI_DIR/ibmdisrv $*
where TDI_DIR specifies the TDI installation directory visible in USS.
This approach reduces the customization needed when starting the TDI server as a z/OS task. Now if we want to change the server start command or logging options, only the ADITASK JCL script needs to be modified. This way the iditask.sh doesn’t need to be modified, it also avoids any problems when the TDI directory is read-only.
JCL: ADITASK
The second part of the mechanism is the ADITASK JCL, which invokes the shell script described above and starts TDI as a normal z/OS task in its own address space.
It resides in MVS in the adi.HADI700.F1 library, where adi stays for the high level qualifier of the product chosen by the user (usually ADI or TDI), as well as in the corresponding AADIJCL and SADIJCL libraries (for example, TDI.V7R1M0.AADIJCL). From a legacy perspective it is better to first copy it into an user's CNTL and submit from there.
The ADITASK uses the BPXBATCH native utility to start the shell script.
Note that it specifies the predefined location of "iditask.sh" - /usr/lpp/itdi/bin/iditask.sh. In case TDI is installed in a location different from the default (/usr/lpp/itdi) or the script is moved to another location after the installation ADITASK JCL must be edited in order to function.
The ADITASK redirects STDOUT, STDERR and LOGOUT to the standard output of the task (SYSOUT). Thus every message sent to the console is logged under the task's name in SDSF. Configuring the TDI task to log to its SYSOUT The behavior can be changed, so that the relevant messages are stored in an intermediate USS file or another MVS dataset.
Below is an example as to how STDOUT can be redirected from SYSOUT to the USS file /usr/lpp/itdi/stdout.txt. In the ADITASK just replace the statement:
//STDOUT DD SYSOUT=*
with the following ones:
//STDOUT DD PATH='/usr/lpp/itdi/stdout.txt', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU
TDI autostarting
There is an additional step in order to automatically start the task with the start of the system. For this purpose the COMMNDxx member in the SYS1.PARMLIB dataset, which is a mechanism of having console start commands invoked during the bring-up of a system image, must be edited. By having a "started task" named for example ADITASK defined as an ADITASK member in the SYS1.PROCLIB dataset, the user can get that task started during system startup by having a CMD='S ADITASK' in the COMMNDxx member.
An alternative is to add the task to USER.PROCLIB and editing the COMMNDxx member of USER.PARMLIB or to use another library concatenated to the Job Entry Subsystem's (JES2 or JES3) PROCLIB allocation in case the user does not have write access to SYS1 members.
By this means the ADITASK can be started from the SDSF menu with the standard z/OS START command. For example:
/S ADITASK