Installation and Test

Reviewing the Package

 
Once the download process is completed, the package should be appear in your desired folder as a ZIP file.   The filename should be something like zJOS_pacYYDDD_ptfYYDDD.zip, where YYDDD is a 5-digit numeric Julian date represents genlevel and PTF level of the package.   For example, zJOS_pac20077_ptf22199.zip is zJOS-XDI package genlevel of 20077 and PTF level 22199.   Extract the content of the ZIP file and the very first thing to do is to read the README.txt file and follow its instructions.   Afterward, you would find 2 files that need to be uploaded onto your z/OS system.   These are a text file INSTALLX.rexx and an XMI file ZJOSXDI.V219.PACYYDDD.PTFYYDDD.XMI with the same YYDDD as stated in ZIP filename.

 
INSTALLX.rexx is an installer program coded in Rexx.   It must be uploaded onto your TSO SYSEXEC or SYSPROC file on z/OS system in text mode.   Before you do it, ensure there is no INSTALLX member in SYSEXEC or SYSPROC concatenation.   Type TSO INSTALLX in ISPF command line or just INSTALLX in TSO prompt.   Once you got the response, find and delete it.

 
ZJOSXDI.V219.PACYYDDD.PTFYYDDD.XMI is a binary data which is the actual zJOS-XDI software package compiled in XMI or TSO XMIT format.   For ZIP file zJOS_pac20077_ptf22199.zip, definitely the filename of XMI file is ZJOSXDI.V219.PAC20077.PTF22199.XMI.   XMI file must be uploaded onto z/OS system in binary mode as a sequential dataset of 80-byte logical record length (LRECL=80) in fixed block format (RECFMT=FB) with 3120-byte block size (BLKSIZE=3120).   Use a preallocated dataset target to ensure its dimension is set correctly, unless all dimension parameters are supported in uploader tool.   Again, read README file carefully and some other notes provided in the ZIP file before you do anything.

Running INSTALLX

 
Once INSTALLX and XMI files are successfully uploaded onto your z/OS system in the right places, you may continue to run INSTALLX on your TSO terminal.   INSTALLX needs ISPF services, so it must be run within ISPF session on TSO.   Since the command is quite long because it must include the XMI dataset name, you are recommended to do it in the TSO shell panel as demonstrated in the video clip below.

Requesting activation keys

Upon successful completion of INSTALLX execution, zJOS-XDI is ready to try to activate.   From the internal logic-path structure point of view, there are 2 major components, a subsystem with the default name ZJOS and a system-task with the default name XDI.   Bringing XDI up at the first time will simultaneously enable the ZJOS subsystem.   However, once enabled, the subsystem will be enable throughout the IPL.   So “up” and “down” state of the subsystem is just a logical state regarding which set of services is callable, instead of its existence on the system.   Details on how to activate can be found in a number of instructions, including the installation guide.

 
Once the subsystem enable, its console called zJOS-XDI control panel is accessible on TSO terminal as shown in this picture.   The status of all 3 products of zJOS-XDI package, Sekar, Puspa and AutoXfer, plus NetServer an extra product to support information/instructions exchange between zJOS agent on other system with Sekar and Puspa.   The usage status of the three products will usually be stated as DEMO in the “usage” column for the first time zJOS-XDI is activated after installation.   That means, all the three products active for demonstration only.   Every day will only work 30 times.   To get them to work normally the way you want, you need an activation key for each product.   You need the key only for the product you need, and that’s the only product you pay for.

 
In order to generate the key for you, we need the genlevel information of the package you installed as well as your system identity, i.e. CPU-ID and model as well as system name and SMFID.   To get this information is very easy.   All that information is displayed on the bottom row in the control panel, as highlighted line in this picture.   Just copy-paste this line and send it to us.

 
Please do not bother in case the control panel appearance in your system is not exactly the same as shown in the above picture.   This picture was taken from very old genlevel in 2009.   But, the genlevel information will always there in the bottom of the panel.

Update levels

 
In our software engineering standard, “PTF level” (stand for “program temporary fix level”) means minor update level.   It is source code update for certain program modules exclusively.   This kind of update is a correction or improvement of the modules that will not affect other modules.   It can be ascertained that these modules won’t be linkedited with other modules and the changes are only in the codes outside of the macro instructions, and do not require changes to data that is accessed together with other modules.   Hence only need to regenerate their binary codes and insert them into existing package to replace the older ones.

 
While “genlevel” (stand for “generation level”) means major update level.     This is the opposite of minor update.   Corrections or changes may be only for one small module.   However, it has the potential to impact other modules.   For example, if updated module is a macro code, or program which are link-edited into other modules.   In such case, the new package must be regenerated from the whole source codes.

 
Both major and minor update levels are indicated by five digit Julian date, YYDDD.   Hence the qualifiers of “pac20077” and “ptf22199” in the package filename mean, genlevel of year 2020 day 77 or 17 March 2020, and PTF level of year 2022 day 199 or 18 July 2022.   Nevertheless, only major update level or genlevel is encrypted together with CPUID/model and system name and SMFID to generate activation key.   PTF level is not included to avoid key generation too frequent.

Current update level

 
Current update level of zJOS-XDI is 20077 PTF 22199, which was done in third quarter of 2022.   The main purpose of the update was to resolve some incompatibility between z/OS V2R5 and earlier releases/levels.   Nevertheless, the support to at least 3 earlier z/OS releases are also retained.   Hence, this package has also been successfully tested on z/OS V1R13, V2R1, V2R2, V2R3 and V2R5. In case your z/OS system is below V1R13, V2R4 or above V2R5, you are strongly recommended to run local sysgen in the final step of installation process. Installer will always prompt you to do it, and you easily answer “YES”.

IVP – Installation verification procedure

 
Below is a video clip showing IVP execution.