1.
|
Download or copy the TIB_srvcgw_file_6.0.0_zos.zip file to a PC that can connect to the z/OS host system.
|
file.xm1 — compressed file containing Service Gateway for Files.
The srvcgw.file.xm1,
install.bin,
ostarrec.bin,
property.bin, and
OSTAREDC files are not used in this procedure.
<HLQ>.FILE.XM1 (size 18 KB)
Use the same <HLQ> that you specified when you uploaded the base component. Below is sample JCL to allocate this data set. Provide a JOB card and submit the JCL.
4.
|
FTP the file.xm1 file in BIN mode to the <HLQ>.FILE.XM1 data set.
|
You must use the <HLQ>.INSTALL data set that was created during the installation of the TIBCO Object Service Broker base component.
Edit the PROPERTY member in
<HLQ>.INSTALL. Table 3 describes keywords in the properties file for installing this component.
The FILE.JCL data set is created at the successful completion of this step.
−
|
JCL in: <HLQ>.FILE.JCL (Edit JOB card to your site's standards)
|
−
|
Data Set: <HLQ>.FILE.JCL (SUB data set). Do not hold data set open in ISPF edit.
|
Uncompressing <HLQ>.FILE.XM1 produces the distribution library
<HLQ>.FILE.FILEI.
SEND messages are directed to the userid specified in the
NOTIFY parameter of each job submitted, informing user of submission and normal completion or abnormal termination. The successful completion of the final job in
JOBSF list is accompanied by the message
ALL MEMBERS PROCESSED.
You can install Service Gateway for Files remotely on separate hosts, where TIBCO Object Service Broker for z/OS is absent, that is, it is
not local to the Data Object Broker.
1.
|
Download or copy the TIB_srvcgw_file_6.0.0_zos.zip file to a PC that can connect to the z/OS host system.
|
−
|
install.bin – The REXX EXEC to perform the installation.
|
−
|
property.bin – A template of mandatory install variables required for product installation.
|
−
|
OSTAREDC – A decompression utility program.
|
where HLQ is any valid high-level qualifier.
HLQ.OS.FILE.XM1 (size 50,000 KB)
Use the same HLQ as the previous data set. Below is a sample JCL to allocate these data sets. Provide a JOB card and submit the JCL.
//ALLOC EXEC PGM=IEFBR14
//DD1 DD DSN=HLQ.INSTALL,
// DISP=(,CATLG,DELETE),UNIT=SYSDA,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),
// SPACE=(TRK,(10,5,10))
//DD2 DD DSN=HLQ.OS.FILE.XM1,
// DISP=(,CATLG,DELETE),UNIT=SYSDA,
// DCB=(RECFM=FB,LRECL=1024,BLKSIZE=0,DSORG=PS),
// SPACE=(TRK,(1000,50))
6.
|
FTP the srvcgw_file.xm1 file in BIN mode to the HLQ.OS.FILE.XM1 data set.
|
1.
|
Upload the OSTAREDC file to z/OS in binary format to a data set with LRECL=80 and RECFM=FB.
|
When prompted, specify DA('
HLQ.INSTLOAD' as the name of the load library where you want the
OSTAREDC program restored.
3.
|
Edit OSTARREC as follows:
|
where your.load.library is the name of the library referenced in Step 2.
|
The HLQ referenced throughout this chapter is the high-level qualifier you specified when you uploaded the product software. This is the value of the INSTALL and XM1 files you specified. It will be used as the default value for all distribution files created when an XM1 is uncompressed. It is equivalent to the value of symbolic parameter $HLQ$ as described in OSEMOD.
|
Before installation, review the system-environment information in Table 4 and determine whether to use the default value or provide your own value.
For details, see the TIBCO Object Service Broker for z/OS Installing and Operating manual.
Use the PROPERTY member in
HLQ.INSTALL as a template and modify it to suit your requirements.
Table 5 describes the keywords in the properties file that correspond to the system-environment variables in
System Environment Checklist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
YES for SMS site, NO for non-SMS site.
Warning: If you select the SMS=YES option, be sure to specify SMS-managed data-set names. The SMS automatic class selection (ACS) rules at your site determine whether a data-set name is eligible for SMS management. If the answer is yes, SMS manages that name. Otherwise, the result is unpredictable.
|
|
Use if SMS=YES. Valid values: YES for SMS compatible data set name classes; NO for SMS non-compatible data set name classes.
If COMPAT=NO, specify the following:
•
|
NMGTCLAS – MANAGEMENTCLASS for non-VSAM data sets
|
•
|
NDATCLAS – DATACLASS for non-VSAM data sets
|
•
|
NSTOCLAS – STORAGECLASS for non-VSAM data sets
|
•
|
VMGTCLAS – MANAGEMENTCLASS for VSAM data sets
|
•
|
VSTOCLAS – STORAGECLASS for VSAM data sets
|
|
|
If SMS=YES, specify one DASD volume for VSAM data set allocation. Default is USER01. If SMS=NO, specify three DASD volumes separated by commas. Defaults are OSBS06, OSBD18, OSBB02.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
STEP 1 will verify that files can be allocated successfully using the values provided in the PROPERTY file. Test files of type sequential, PDS, PDSE, and VSAM will be allocated then deleted. Installation will stop if any test allocation fails. You should investigate the cause, correct the condition and repeat STEP 1.
The HLQ.FILE.JCL data set is created at the successful completion of this step.
|
|
|
|
|
|
HLQ.FILE.JCL (Edit Job Card to your site’s standards.)
|
|
HLQ.FILE.JCL (SUB data set). Do not hold data set open in ISPF edit.
|
|
This batch job will uncompress the OS.FILE.XM1 file to produce the distribution libraries. If you modify the job name, make sure it does not exceed seven characters. The job should successfully complete with a return code of 0.
|
|
|
|
|
|
|
|
|
|
|
|
If Service Gateway for Files is connecting to a Data Object Broker that runs in an Open Systems platform. you must specify the values for these two OSEMOD variables: $HOST$ and $DOBPORT$.
These variables customize the member RELAYTCP in HLQNONV.INSTVER.CNTL before it is copied to the data set HLQNONV.SLQ.RELAYCFG. It is required to establish TCP/IP connectivity. For further details, see Configuration of TCP/IP.
|
|
|
|
|
|
|
|
•
|
HLQNONV.INSTVER.OS.FILE.JOBS – Install jobs for remote Service Gateway for Files
|
|
|
|
|
|
|
HLQNONV.INSTVER.OS.FILE.JOBS
|
|
|
|
Jobs in JOBSM are evaluated in the order they are listed and are submitted based upon their specified STATUS. The next job is submitted only if the previous one completed with its expected return code RC.
Status is modified from INSTALL to DONE only if the job's completion code is equal to or less than the stated return code.
You can modify the STATUS of any job as per your requirement. For example, if your shop normally ACCEPTs the product FMID at some future time, then change the status of S6M4ACPT from INSTALL to FUTURE.
|
|
|
|
|
|
HLQNONV.INSTVER.OS.FILE.JOBS
|
|
|
|
SEND messages are directed to the userid specified in the NOTIFY parameter of each job submitted, informing user of submission and normal completion or abnormal termination. The successful completion of the final job in the JOBSM list is accompanied by the message ALL MEMBERS PROCESSED.
|
|
|
|
|
|
If you have opted to delay accepting the product as described in step 5 by changing the original STATUS of job S6M4ACPT from INSTALL to FUTURE in member JOBSM, then be sure to accept the Service Gateway for Files product by performing the final ACCEPT when ready. This step is required for future maintenance of the product.
|
|
HLQNONV.INSTVER.OS.FILE.JOBS
|
|
|
You need TCP/IP to communicate between TIBCO Object Service Broker components—client processes, Execution Environments, Data Object Brokers, and external database
gateways—on a z/OS system and TIBCO Object Service Broker components on z/OS or non-z/OS platforms.
The relay file, RELAYTCP in the
CNTL data set, contains information on the TIBCO Object Service Broker components that use TCP/IP. The file associates TCP/IP host names and port numbers with the TIBCO Object Service Broker communication identifiers that are used by those components that run on any supported platform. Also, the file is a text file in XML format, which you must modify when changes to the TCP/IP environment are required. Each component could have a separate relay file or a common file could be shared across a number of components.
If XCF communications relay is deployed, TCP/IP parameters must be merged with the XCF parameters; the combined parameters are in
RELAYCFG in the
CNTL data set. For details on the XCF parameters, see Configuring XCF Communications in Chapter 2 of the
TIBCO Object Service Broker for z/OS Installing and Operating manual.
Run USERMODD in the JCL data set to customize the data set name of the relay file.
If you specify DSNAME=NULLFILE in
USERMODD, you disable TCP/IP access. In jobs and started tasks where you want to use TCP/IP, add an
S6BRELAY DD statement to point to the relay file. If you specify a non-null relay file in a batch job, it is likely to have a short-term region requirement at startup of over 64 MB as it runs
XMLPARSER and might cause jobs to fail.
USERMODD with
DSNAME=NULLFILE or an
S6BRELAY DD DUMMY JCL statement removes this storage requirement.
The installation process for TIBCO Object Service Broker copies RELAYTCP to the data set
$HLQNOVN$.$SLQ$.RELAYCFG, which contains your live TCP/IP information. To change your TCP/IP configuration, use the CNTL member
RELAYTCP to make and verify your changes, and then copy the new information to
$HLQNOVN$.$SLQ$.RELAYCFG. To override the data set name set by
USERMODD, add a
DDNAME S6BRELAY to your TIBCO Object Service Broker component or any other z/OS components that require TCP/IP communications. If this override is invalid during the component’s initialization, support for TCP/IP is disabled until you specify a valid parameter file. Once the relay file has been processed during component initialization, it is freed.
The relay file contains a set of protocol specific parameters, followed by a directory that maps communication identifiers to protocol-specific parameters. When configuring a TIBCO Service Gateway on z/OS to attach with a TIBCO Data Object Broker on Windows or Solaris, be sure to specify the
keepalive attribute for the node that describes the TIBCO Data Object Broker (
WINDOB in the sample below).
For a detailed description of TCP/IP protocol parameters, see TCP/IP Protocol Parameters for the Relay File in Chapter 2 of the
TIBCO Object Service Broker for z/OS Installing and Operating manual.
Installation verification for an external DBMS provides a quick method to verify that the installation of a TIBCO Object Service Broker DOB and one or more DBMS Service Gateways was successful. This verifies that the communication between the DOB and a Service Gateway, and a Service Gateway and the DBMS, is functioning properly.
Verification can be accomplished by including sample TIBCO Object Service Broker table definitions for DB2, IMS, CA-IDMS and CA-Datacom. Each of these comes with sample tables or demo databases.
Data set HLQNONV.INSTVER.JCL(IVPDAT) contains all the job steps required to execute the verification process. If all requirements are met customize the JCL and run it.
Have your z/OS systems programmer APF-authorize the library HLQNONV.INSTVER.AUTH so that you can use TCP/IP or z/OS cross-memory communications in
IVPDAT.
•
|
Run the job HLQNONV.INSTVER.OS.FILE.JOBS(S6M9CLEN). It will delete all the data sets previously created by job S6M3APLY, i.e., SMP/E-related libraries, etc.
|
1.
|
S6M3APLY – Should complete with a return code of 4.
|
2.
|
S6M4ACPT – Should complete with a return code of 4.
|
3.
|
S6M5CFGR – Should complete with a return code of 0.
|
•
|
Run the job HLQNONV.INSTVER.OS.FILE.JOBS(S6M9CLEN) to delete all previous SMP/E libraries.
|
•
|
Edit the members S6M3APLY, S6M4ACPT, S6M5CFGR, and S6M9CLEN in HLQNONV.INSTVER.OS.FILE.JOBS, changing all occurrences of SMP60 to that of your choice and then manually run these jobs:
|
1.
|
S6M3APLY – Should complete with a return code of 4.
|
2.
|
S6M4ACPT – Should complete with a return code of 4.
|
3.
|
S6M5CFGR – Should complete with a return code of 0.
|