ZMF Support for CICS Web Services
CICS provides specific mechanisms (in addition to z/OS Connect facilities described above) for making CICS transactions available as Web Services in either of two ways:
- Using Simple Object Access Protocol (SOAP) Web Service Definition Language (WSDL) files.
- Using Representational State Transfer (REST)-ful services through Http/Javascript Object Notation (JSON).
CICS also provides utilities to aid in generating the artifacts required to make these mechanisms work and enable ChangeMan ZMF to manage them.
Four different build functions are supplied as the four sample build procedures described below to support the development and management of CICS Web Services. Each build process makes use of the CMNBAQ00 program in ZMF to generate the required script with which the relevant IBM-supplied utility is executed.
The four build functions are supplied by the following members of the CMNZMF.SKELS library:
| Sample CMNZMF.SKELS Library Skeleton | CICS-Supplied Utility | Description |
|---|---|---|
| CMNDFHJS | DFHLS2JS | Creates JSON schemas and bind file for input language structures such as COBOL and PL/I copybooks. This utility is aimed at exposing CICS to use externally provided RESTful services. |
| CMNDFHJL | DFHJS2LS | Creates language structures (copybooks) and bind file from input JSON schemas. This utility is aimed at allowing CICS to use externally provided RESTful services. |
| CMNDFHWS | DFHLS2WS | Creates WSDLs and bind file from input language structures. This utility is aimed at exposing CICS transactions as SOAP services. |
| CMNDFHWL | DFHWS2LS | Create language structures and bind file from input WSDLs. This utility is aimed at allowing CICS to use externally provided SOAP services. |
...
Parameters are passed from a like-SRC parm component to the build; the target skeleton adds to these parameters to direct how CMNBAQ00 proceeds. If there are parameters that CMNBAQ00 needs to override in order to maintain control of the build, CMNBAQ00 will do that. Otherwise, the parameters are passed on as is to the execution of the IBM-supplied utility. The resulting execution generates components that are stored in the package and associated with the original like-SRC parameter component.
Other generated zFS component types, for example, JSON schemas and WSDLs, will have their target staging directories allocated if they are missing when the generated components are copied back to the staging directories.
However, you need to preallocate the needed copybook staging library. You can preallocate this library with exit CMNEX0026. (See member CMNEX0026 of the CMNZMF.ASMSRC distribution library.)
The following example shows the coding you might add to CMNEX0026 to ensure that all relevant libtypes are allocated when the source component is built.
*---------------------------------------------------------------------*
* Application based library type table:
* This table is designed for generating a list of library types to
* be passed back for processing when staging. The staging libraries
* for the additional library types will be allocated to the package.
*
* Each entry in this table must contain the following information.
* 1) An applications name or mask '*' with a length of 4 (CL4).
* 2) The library type being staged or a mask '*' with a length
* of 3 (CL3).
* 3) A list of library types to process, maximum of 10.
* 0 library type would be defined as CL30' ' and CL30
* would be decremented by 3 for each library type until
* 10 library types are added.
*
*---------------------------------------------------------------------*
X26@LTYP DS 0CL37 library type description table
*
DC CL4'STEV' just STEV
DC CL3'C2J' DFHLS2JS control member
DC CL3'JSN' JSON component
DC CL3'LSH' zfs listings
DC CL24' ' the rest of them (8 spare)
*
DC CL4'STEV' just STEV
DC CL3'C2W' DFHLS2WS control member
DC CL3'WSD' WSDL component
DC CL3'LSH' zfs listings
DC CL24' ' the rest of them (8 spare)
*
DC CL4'STEV' just STEV
DC CL3'W2L' DFHWS2LS control member
DC CL3'WCP' generated copybook
DC CL3'LSH' zfs listings
DC CL24' ' the rest of them (8 spare)
*
DC CL4'STEV' just STEV
DC CL3'J2L' DFHJS2LS control member
DC CL3'WCP' generated copybook
DC CL3'LSH' zfs listings
DC CL24' ' the rest of them (8 spare)
* end of application table
X26#LTYP EQU (*-X26@LTYP)/37 number of entries
If a CICS transaction is to be identified as a RESTful (JSON) web service, a number of artifacts must be generated from the development process to allow that to happen.
A request and a response copybook is required to expose the transaction to the outside world (for example, a COBOL copybook mapping the data as the transaction program will see incoming requests and present outgoing responses). These copybook components are used to generate a number of zFS files as follows:
-
The request JSON schema xxx.json
-
The response JSON schema yyy.json
-
The data structure mapping zzz.wsbind
The IBM-provided utility DFHLS2JS is used to take the copybooks and generate these outputs.
A CICS transaction can also be identified as a SOAP web service, there are a number of artifacts which must be generated from the development process to allow that to happen.
A request and a response copybook is required to expose the transaction to the outside world (for example, a COBOL copybook mapping the data as the transaction program will see incoming requests and present outgoing responses). These copybook components are used to generate a number of zFS files as follows:
-
The WSDL xxx.wsdl.
-
The data structure mapping zzz.wsbind.
The IBM-provided utility DFHLS2WS is used to take the copybooks and generate these outputs.
Conversely, a CICS transaction may request information through a RESTful web service. To allow this to happen, we take in the JSON schemas that describe the response/request formats expected by the external service provider (as generated by that provider) and generate language structure copybooks to allow the CICS program to map those structures along with a bind file to describe the data mapping. The IBMprovided utility DFHJS2LS does this.
Similarly, a CICS transaction may request information through a SOAP web service. To allow this to happen, we take in the WSDL file that describes the service interface expected by the external service provider (as generated by that provider) and generate language structure copybooks to allow the CICS program to map those structures along with a bind file to describe the data mapping. The IBM-provided utility DFHWS2LS does this.
The following sections describe these build processes in detail.
Generate JSON Outputs from Input Copybooks (CMNDFHJS Skeleton)
This process requires an input like-SRC parameter component in which any directives required to be passed to the IBM-provided utility DFHLS2JS must be placed. This must include the names of the request and response copybooks from which the bind file and JSON outputs are generated. An example parameter member might look like this:
REQMEM=ZCONREQ
RESPMEM=ZCONRESP
LANG=COBOL
MAPPING-LEVEL=4.0
CHAR-VARYING=COLLAPSE
PGMNAME=CICSCBL
URI=http://host_computer:7082/CobolService/CobolService
PGMINT=COMMAREA
SYNCONRETURN=YES
CMNDFHJS is the skeleton that contains the sample procedure to be used. CMNDFHJS has the following steps:
-
SERCOPY copies the input parameter member to a temporary data set which is passed to the subsequent execution of CMNBAQ00.
-
CR8TEMP executes CMNHUTIL to create the temporary zFS directories used by the build. It also allocates the named temporary PDSE into which the input copybooks will be placed by the SYSLIB search performed by CMNBAQ00.
-
BAQ00 executes CMNBAQ00 with PARM=DFHLS2JS, which tells CMNBAQ00 we are working with a DFHLS2JS build process. The parameters from the SERCOPY step are passed as SYSIN along with extra, at are used to direct what CMNBAQ00 is doing. For example:
//SYSIN DD DISP=(OLD,DELETE),DSN=&&SOURCE(CICSCBL)
// DD *
PGMNAME=CICSCBL
ZMF-PKG=STEV001485
JAVA-DIR=java/J8.0_64
USS-DIR=cicsts52
SERVICE=:
PATH-PREFIX=/Service
UTILITY-LOC=/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHLS2JS
TARGET-DIR=/tmp/STEV001485/WSER58/cics/cmngen
LISTING-DIR=/tmp/STEV001485/WSER58/cics/cmnlst
COPYLIB=CMNDEV.WSER58.D180320.T012307.CICS.CPY
USER=WSER58
SSI=6D8059FA
PROC=CMNDFHJS
SRC-LTYP=C2J
JSON-LTYP=JSN
BIND-LTYP=WSB
/*
The parameters added by the skeleton are internal to CMNBAQ00 and, in general, are not passed to the actual execution of DFHLS2JS (unlike the parameters from the like-SRC component which is driving this whole process). These parameters are:
| Parameter | Description |
|---|---|
| PGMNAME= | Is set to the input component name and is used to generate the names of files that are part of the build process. For example, the log file will be written as filename |
| ZMF-PKG= | Is set to the name of the current package and is used to generate appropriate CMNBATCH transactions to activate the generated components. |
...
The next four parameters are all required by the IBM-supplied DFHLS2JS shell script. They should be specified in exactly the same format as you would for that shell script, that is, whatever works with the standard IBM process will work here.
| Parameter | Description |
|---|---|
| JAVA-DIR= | Is an indication of where JAVA can be found. |
| USS-DIR= | Is an intermediate zFS directory node that is used by the script. |
| SERVICE=: | An extra parameter that is used by the script. This parameter should only be changed under direction from IBM. |
| PATH-PREFIX= | Is a high-level node prepended to directory names built by the shell script. |
...
| Parameter | Description |
|---|---|
| UTILITY-LOC= | Is where the DFHLS2JS shell script is to be found. |
| TARGET-DIR= | Where outputs will be generated. It is a temporary zFS directory whose contents will be copied to the package staging directories if the build is successful. |
| LISTING-DIR= | Where information output will be directed. Contents will be gathered up into a single listing component at the end of the build. |
| COPYLIB= | The named temporary PDSE into which the request and response copybooks will be placed after they have been located in the SYSLIB concatenation. |
| USER= | The build-submitting user, used in creating activation transactions for CMNBATCH later. |
| SSI= | The build System Status Index (setssi) value for CMNBATCH. |
| PROC= | Name of this build procedure, for CMNBATCH |
| SRC-LTYP= | Library type of the input like-SRC parameter member, for CMNBATCH. |
| JSON-LTYP= | Library type into which any generated JSON schemas will be placed, for CMNBATCH. |
| BIND-LTYP= | Library type into which any generated wsbind files will be placed, for CMNBATCH. |
These CMNBAQ00 internal parameters are generated within the supplied CMNDFHJS skeleton. An indication of how this is done is given here (from the skeleton itself):
)CM
)CM The following variable definitions customize this process.
)CM They are specified here for clarity but could just as well
)CM be performed in CMN$$VAR.
)CM
)CM &DFHGEN is the temporary directory where the json/bind
)CM components will be placed. If the build is successful
)CM they will be copied back to staging libraries.
)CM &DFHLST is the temporary directory where all zfs hosted
)CM listings will be placed. These will be consolidated
)CM into the overall build listing at the end of the process.
)SETF DFHGEN = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmngen)
)SETF DFHLST = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmnlst)
)CM
)CM &JHOME is the home directory for Java (in the format required
)CM by the DFHLS2JS script as supplied by IBM)
)CM &DFHUSS is the intermediate zfs node (as required by
)CM by the DFHLS2JS script as supplied by IBM)
)CM &DFHSRV is the service modifier (as required by
)CM by the DFHLS2JS script as supplied by IBM)
)CM &DFHPFX is the path prefix (as required by
)CM by the DFHLS2JS script as supplied by IBM)
)CM &DFHLOC is the location for the DFHLS2JS script
)CM
)SETF JHOME = &STR(java/J8.0_64)
)SETF DFHUSS = &STR(cicsts52)
)SETF DFHSRV = &STR(:)
)SETF DFHPFX = &STR(/Service)
)SETF DFHLOC = &STR(/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/)
)SETF DFHLOC = &STR(&DFHLOC.DFHLS2JS)
)CM
)CM &DFHLIB is the name of the temporary PDS used for the copybooks
)CM e.g. DSN=yourhlq.userid.date.time.CICS.CPY
)CM
)SETF DFHLIB = &STR(yourhlq.&STGERID)
)SETF DFHLIB = &STR(&DFHLIB..D&SYMDEF(LYYMMDD).T&SYMDEF(LHHMMSS))
)SETF DFHLIB = &STR(&DFHLIB..CICS.CPY)
...
)CM
)CM &JSONLTP is the ZMF library type for the generated json components
)CM &BINDLTP is the ZMF library type for the generated wsbind cmpnts
)CM
)SETF JSONLTP = &STR(JSN)
)SETF BINDLTP = &STR(WSB)
)CM
The DFHLS2JS utility is invoked using an IBM-supplied shell script which expects the relevant parameters to be in a zFS file at a specific location. The shell command is generated by CMNBAQ00 and is passed in the output file allocated to ddname CMNSTDPM. This command, using the parameter values entered above, looks like this (as directed by IBM):
SH /Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHLS2JS
java/J8.0_64
cicsts52
/tmp/STEV001485/WSER58/cics/cmngen/LS2JS
:
/Service
-
The parameters used to drive the execution of the DFHLS2JS utility need to be written to a zFS file. This is done by passing a series of CMNHUTIL commands with ddname CMNHUTIL.
-
The two input copybooks are located from the SYSLIB concatenation (which is built in the sample skeleton like any other ZMF build SYSLIB is built) and written out to the named temporary library as directed by the COPYLIB= statement.
-
CMNBATCH transactions which will be used to activate the various generated components are written to the CMNBAT90 ddname.
-
Indication of everything that CMNBAQ00 has done is written to SYSPRINT.
-
The step that follows execution of CMNBAQ00 is RUNUTIL, which executes CMNHUTIL using the commands generated by CMNBAQ00 to the CMNHUTIL output ddname. This step sets up the input expected by the DFHLS2JS utility when it runs.
-
The step called DFHLS2JS runs BPXBATCH to execute the shell command passed from the CMNSTDPM ddname of the CMNBAQ00 step. This step generates the required outputs.
-
If the generation is successful, the next step, CPY2STG, executes CMNHUTIL to copy the generated components and listings back to the relevant package staging directories.
-
The SUCCESS step, executing CMNBATCH, makes the original like-SRC component active and then, directed by the CMNBAT90 output from CMNBAQ00, activates all the generated components.
-
Additional steps follow to deal with build failures and tidy up the intermediate working directories and PDSE.
The source-to-load display for a successfully built DFHLS2JS parameter component looks like this:
CMNSR2LD Source to Load Relationship Row 1 to 4 of 4
Command ===> Scroll ===> CSR
Package: STEV001485 Status: DEV Install date: 20180820
Source name . . . . CICSCBL +
Lib type . . . . . C2J
Setssi . . . . . . 6D8059FA
Related Load Modules:
Name + Type Promotion Changed User Setssi
CICSCBL LST 0 STAGING 20180320 012422 WSER58 6D8059FA
CICSCBL.wsbind WSB 0 STAGING 20180320 012420 WSER58 6D8059FA
CICSCBL.C2J.list LSH 0 STAGING 20180320 012420 WSER58 6D8059FA
CICSCBL_request.jso JSN 0 STAGING 20180320 012420 WSER58 6D8059FA
CICSCBL_response.js JSN 0 STAGING 20180320 012420 WSER58 6D8059FA
******************************* Bottom of data ********************************
The names of the generated components are formed as follows:
-
The LST listing takes the name of the original like-SRC component, in this case CICSCBL.
-
The LSH has the source libtype and the literal 'list' appended, in this case CICSCBL.C2J.list.
-
The bind component name takes the form
.wsbind where is taken from one of three sources in order of preference: -
From the WSBIND=xxxx/xxxx/xxxx/
.wsbind parameter statement present in the original like-SRC parameter component. This is typically how this value will be assigned. -
From the SERVICE-NAME=
parameter statement present in the original like-SRC parameter component. This is atypical for this process and is included for compatibility with the zosConnect build process. -
From the PGMNAME=
parameter as supplied by the skeleton input. Again atypical, but this provides a backstop.
-
-
The JSON request component name takes the form
.json (method 1) or _request.json (methods 2 and 3) where is one of, in order: -
From the JSON-SCHEMA-RESPONSE=xxxx/xxxx/xxx/
.json parameter in the original like-SRC parameter component. This is typically how this value will be assigned. -
From the SERVICE-NAME=
parameter statement present in the original like-SRC parameter component. This is atypical for this process and is included for compatibility with the zosConnect build process. -
From the PGMNAME=
parameter as supplied by the skeleton input. Again atypical, but this provides a backstop.
-
-
The JSON response component name takes a similar form to the request component, replacing 'request' with 'response.'
Generate WSDL Outputs from Input Copybooks
(CMNDFHWS Skeleton)
This process requires an input like-SRC parameter component in which any directives required to be passed to the IBM-provided utility DFHLS2WS must be placed. This must include the names of the request and response copybooks from which the bind file and WSDL outputs are generated. An example parameter member might look like this:
REQMEM=ZCONREQ
RESPMEM=ZCONRESP
SERVICE-NAME=CobolService
WSDL=/u/wser58/CobolService.wsdl
WSDL_2.0=/u/wser58/CobolService_20.wsdl
LANG=COBOL
MAPPING-LEVEL=4.0
CHAR-VARYING=COLLAPSE
PGMNAME=WSDLCBL
URI=http://host_computer:7082/CobolService/CobolService
PGMINT=COMMAREA
SYNCONRETURN=YES
CMNDFHWS is the skeleton that contains the sample procedure to be used. CMNDFHWS has the following steps:
-
SERCOPY copies the input parameter member to a temporary dataset which is passed to the subsequent execution of CMNBAQ00.
-
CR8TEMP executes CMNHUTIL to create the temporary zFS directories used by the build. It also allocates the named temporary PDSE into which the input copybooks will be placed by the SYSLIB search performed by CMNBAQ00.
-
BAQ00 executes CMNBAQ00 with PARM=DFHLS2WS, which tells CMNBAQ00 we are working with a DFHLS2WS build process. The parameters from the SERCOPY step are passed as SYSIN along with extra, skeleton-generated parameters that are used to direct what CMNBAQ00 is doing. For example:
//SYSIN DD DISP=(OLD,DELETE),DSN=&&SOURCE(WSDLCBL)
// DD *
PGMNAME=WSDLCBL
ZMF-PKG=STEV001485
JAVA-DIR=java/J8.0_64
USS-DIR=cicsts52
SERVICE=:
PATH-PREFIX=/Service
UTILITY-LOC=/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHLS2WS
TARGET-DIR=/tmp/STEV001485/WSER58/cics/cmngen
LISTING-DIR=/tmp/STEV001485/WSER58/cics/cmnlst
COPYLIB=CMNDEV.WSER58.D180320.T045833.CICS.CPY
USER=WSER58
SSI=6D808C79
PROC=CMNDFHWS
SRC-LTYP=C2W
BIND-LTYP=WSB
WSDL11-LTYP=WSD
/*
The parameters added by the skeleton are internal to CMNBAQ00 and, in general, are not passed to the actual execution of DFHLS2WS (unlike the parameters from the like-SRC component which is driving this whole process). These parameters are:
| Parameter | Description |
|---|---|
| PGMNAME= | Is set to the input component name and is used to generate the names of files that are part of the build process. For example, the log file will be written as filename |
| ZMF-PKG= | Is set to the name of the current package and is used to generate appropriate CMNBATCH transactions to activate the generated components. |
...
The next four parameters are all required by the IBM-supplied DFHLS2WS shell script. They should be specified in exactly the same format as you would for that shell script, that is, whatever works with the standard IBM process will work here.
| Parameter | Description |
|---|---|
| JAVA-DIR= | Is an indication of where JAVA can be found. |
| USS-DIR= | Is an intermediate zFS directory node that is used by the script. |
| SERVICE=: | An extra parameter used by the script. This parameter should only be changed under direction from IBM. |
| PATH-PREFIX= | Is a high-level node prepended to directory names built by the shell script. |
| UTILITY-LOC= | Is where the DFHLS2WS shell script is to be found. |
| TARGET-DIR= | Where outputs will be generated. It is a temporary zFS directory whose contents will be copied to the package staging directories if the build is successful. |
| LISTING-DIR= | Where information output will be directed. Contents will be gathered up into a single listing component at the end of the build. |
| COPYLIB= | The named temporary PDSE into which the request and response copybooks will be placed after they have been located in the SYSLIB concatenation. |
| USER= | The build-submitting user, used in creating activation transactions for CMNBATCH later. |
| SSI= | The build System Status Index (setssi) value for CMNBATCH. |
| PROC= | Name of this build procedure, for CMNBATCH. |
| SRC-LTYP= | Library type of the input like-SRC parameter member, for CMNBATCH. |
| WSDL11-LTYP= | Library type into which any generated 1.1 WSDL will be placed, for CMNBATCH. A synonym for this parameter name is WSDLLTYP=. |
| WSDL20-LTYP= | Library type into which any generated 2.0 WSDL will be placed, for CMNBATCH. If this parameter is missing, the same libtype specified for WSDL11-LTYP will be used. |
| BIND-LTYP= | Library type into which any generated wsbind files will be placed, for CMNBATCH. |
...
These CMNBAQ00 internal parameters are generated within the supplied CMNDFHWS skeleton. An indication of how this is done is given here (from the skeleton itself):
)CM
)CM The following variable definitions customize this process.
)CM They are specified here for clarity but could just as well
)CM be performed in CMN$$VAR.
)CM
)CM &DFHGEN is the temporary directory where the wsdl/bind
)CM components will be placed. If the build is successful
)CM they will be copied back to staging libraries.
)CM &DFHLST is the temporary directory where all zfs hosted
)CM listings will be placed. These will be consolidated
)CM into the overall build listing at the end of the process.
)SETF DFHGEN = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmngen)
)SETF DFHLST = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmnlst)
)CM
)CM &JHOME is the home directory for Java (in the format required
)CM by the DFHLS2WS script as supplied by IBM)
)CM &DFHUSS is the intermediate zfs node (as required by
)CM by the DFHLS2WS script as supplied by IBM)
)CM &DFHSRV is the service modifier (as required by
)CM by the DFHLS2WS script as supplied by IBM)
)CM &DFHPFX is the path prefix (as required by
)CM by the DFHLS2WS script as supplied by IBM)
)CM &DFHLOC is the location for the DFHLS2WS script
)CM
)SETF JHOME = &STR(java/J8.0_64)
)SETF DFHUSS = &STR(cicsts52)
)SETF DFHSRV = &STR(:)
)SETF DFHPFX = &STR(/Service)
)SETF DFHLOC = &STR(/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/)
)SETF DFHLOC = &STR(&DFHLOC.DFHLS2WS)
)CM
)CM &DFHLIB is the name of the temporary PDS used for the copybooks
)CM e.g. DSN=yourhlq.userid.date.time.CICS.CPY
)CM
)SETF DFHLIB = &STR(yourhlq.&STGERID)
)SETF DFHLIB = &STR(&DFHLIB..D&SYMDEF(LYYMMDD).T&SYMDEF(LHHMMSS))
)SETF DFHLIB = &STR(&DFHLIB..CICS.CPY)
)CM
)CM &BINDLTP is the ZMF library type for the generated wsbind cmpnts
)CM &WSDL1LT is the ZMF library type for the generated wsdl 1.1 cmpnts
)CM &WSDL2LT is the ZMF library type for the generated wsdl 2.0 cmpnts
)CM (optional)
)SETF BINDLTP = &STR(WSB)
)SETF WSDL1LT = &STR(WSD)
)CM
The DFHLS2WS utility is invoked using an IBM supplied shell script which expects the relevant parameters to be in a zFS file at a specific location. The shell command is generated by CMNBAQ00 and is passed in the output file allocated to ddname CMNSTDPM. This command, using the parameter values entered above, looks like this (as directed by IBM):
SH /Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHLS2WS
java/J8.0_64
cicsts52
/tmp/STEV001485/WSER58/cics/cmngen/LS2WS
:
/Service
-
The parameters used to drive the execution of the DFHLS2WS utility need to be written to a zFS file. This is done by passing a series of CMNHUTIL commands with ddname CMNHUTIL.
-
The two input copybooks are located from the SYSLIB concatenation (which is built in the sample skeleton like any other ZMF build SYSLIB is built) and written out to the named temporary library as directed by the COPYLIB= statement.
-
CMNBATCH transactions which will be used to activate the various generated components are written to the CMNBAT90 ddname.
-
Indication of everything that CMNBAQ00 has done is written to SYSPRINT.
-
The step that follows execution of CMNBAQ00 is RUNUTIL, which executes CMNHUTIL using the commands generated by CMNBAQ00 to the CMNHUTIL output ddname. This step sets up the input expected by the DFHLS2WS utility when it runs.
-
The step called DFHLS2WS runs BPXBATCH to execute the shell command passed from the CMNSTDPM ddname of the CMNBAQ00 step. This step generates the required outputs.
-
If the generation is successful, the next step, CPY2STG, executes CMNHUTIL to copy the generated components and listings back to the relevant package staging directories.
-
The SUCCESS step, executing CMNBATCH, makes the original like-SRC component active and then, directed by the CMNBAT90 output from CMNBAQ00, activates all the generated components.
-
Additional steps follow to deal with build failures and tidy up the intermediate working directories and PDSE.
The source-to-load display for a successfully built DFHLS2WS parameter component looks like this:
CMNSR2LD Source to Load Relationship Row 1 to 4 of 4
Command ===> Scroll ===> CSR
Package: STEV001485 Status: DEV Install date: 20180820
Source name . . . . WSDLCBL +
Lib type . . . . . C2W
Setssi . . . . . . 6D808C79
Related Load Modules:
Name + Type Promotion Changed User Setssi
CobolService.wsbind WSB 0 STAGING 20180320 045905 WSER58 6D808C79
CobolService.wsdl WSD 0 STAGING 20180320 045905 WSER58 6D808C79
CobolService_20.wsd WSD 0 STAGING 20180320 045905 WSER58 6D808C79
WSDLCBL LST 0 STAGING 20180320 045908 WSER58 6D808C79
WSDLCBL.C2W.list LSH 0 STAGING 20180320 045908 WSER58 6D808C79
******************************* Bottom of data ********************************
The names of the generated components are formed as follows:
-
The LST listing takes the name of the original like-SRC component, in this case WSDLCBL.
-
The LSH listing has the source library type and the literal 'list' appended, in this case WSDLCBL.C2W.list.
-
The bind component name takes the form
.wsbind where is taken from one of three sources in order of preference: -
From the WSBIND=xxxx/xxxx/xxxx/
.wsbind parameter statement present in the original like-SRC parameter component. This is typically how this value will be assigned. -
From the SERVICE-NAME=
parameter statement present in the original like-SRC parameter component. This is atypical for this process and is included for compatibility with the zosConnect build process. -
From the PGMNAME=
parameter as supplied by the skeleton input. Again atypical, but this provides a backstop.
-
-
The WSDL 1.1 component name takes the form
.wsdl where is one of, in order: -
From the WSDL=xxxx/xxxx/xxx/
.wsdl parameter in the original like-SRC parameter component. (WSDL_1.1= is a synonym.) This is typically how this value will be assigned. -
From the SERVICE-NAME=
parameter statement present in the original like-SRC parameter component. This is atypical for this process and is included for compatibility with the zosConnect build process. -
From the PGMNAME=
parameter as supplied by the skeleton input. Again atypical, but this provides a backstop.
-
-
The WSDL 2.0 component name takes the form
.wsdl where is from the WSDL_2.0=xxxx/xxxx/xxx/ .wsdl parameter in the original like-SRC parameter component. If this parameter is not present, no 2.0 WSDL will be generated.
Generate Copybooks from JSON Inputs (CMNDFHJL Skeleton)
This process requires an input like-SRC parameter component in which any directives required to be passed to the IBM-provided utility DFHJS2LS must be placed. This must include the name prefixes for the request and response copybooks which will be generated by the process as well as the names of the request/response JSON schemas from which the bind file and copybooks are generated. An example parameter member looks like this:
REQMEM=JSREQ
RESPMEM=JSRESP
JSON-SCHEMA-REQUEST=CobolService_request.json
JSON-SCHEMA-RESPONSE=CobolService_response.json
WSBIND=CobolJSON.wsbind
LANG=COBOL
MAPPING-LEVEL=4.0
CHAR-VARYING=YES
PGMNAME=CBLJSON
PGMINT=COMMAREA
CMNDFHJL is the skeleton that contains the sample procedure to be used. CMNDFHJL has the following steps:
-
SERCOPY copies the input parameter member to a temporary data set which is passed to the subsequent execution of CMNBAQ00.
-
CPY$ALC dynamically allocates the named temporary PDSE into which the required copybooks will be generated. This library must not be allocated in the JCL of any step in this job; otherwise, there will be contention issues with the BPXBATCH-spawned process which does the writing of the copybooks to this PDSE. We also allocate a second version of this PDSE into which the copybooks are copied so that this version can be allocated in JCL by the later CMNBAT90 step without causing problems with the spawned process.
-
CR8TEMP executes CMNHUTIL to create the temporary zFS directories used by the build.
-
BAQ00 executes CMNBAQ00 with PARM=DFHJS2LS, which tells CMNBAQ00 we are working with a DFHJS2LS build process. The parameters from the SERCOPY step are passed as SYSIN along with extra, skeleton-generated parameters that are used to direct what CMNBAQ00 is doing. For example:
//SYSIN DD DISP=(OLD,DELETE),DSN=&&SOURCE(CBLJSON)
// DD *
PGMNAME=CBLJSON
ZMF-PKG=STEV001485
STG-DIR=/cmndev/cmni/STEV/#001485
JAVA-DIR=java/J8.0_64
USS-DIR=cicsts52
SERVICE=:
PATH-PREFIX=/Service
UTILITY-LOC=/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHJS2LS
TARGET-DIR=/tmp/STEV001485/WSER58/cics/cmngen
LISTING-DIR=/tmp/STEV001485/WSER58/cics/cmnlst
COPYLIB=CMNDEV.WSER58.D180320.T055200.CICS.CPY
USER=WSER58
SSI=6D809900
PROC=CMNDFHJL
SRC-LTYP=J2L
BIND-LTYP=WSB
JSON-LTYP=JSN
CPY-LTYP=WCP
/*
The parameters added by the skeleton are internal to CMNBAQ00 and, in general, are not passed to the actual execution of DFHJS2LS (unlike the parameters from the like-SRC component which is driving this whole process). These parameters are:
| Parameter | Description |
|---|---|
| PGMNAME= | Is set to the input component name and is used to generate the names of files that are part of the build process. For example, the log file will be written as filename |
| ZMF-PKG= | Is set to the name of the current package and is used to generate appropriate CMNBATCH transactions to activate the generated components. |
| STG-DIR= | Names of the package staging directories, that is, where the input JSON components will be found. |
...
The next four parameters are all required by the IBM-supplied DFHJS2LS shell script. They should be specified in exactly the same format as you would for that shell script, that is, whatever works with the standard IBM process will work here.
| Parameter | Description |
|---|---|
| JAVA-DIR= | Is an indication of where JAVA can be found. |
| USS-DIR= | Is an intermediate zFS directory node that is used by the script. |
| SERVICE=: | An extra parameter that is used by the script. This parameter should only be changed under direction from IBM. |
| PATH-PREFIX= | Is a high-level node prepended to directory names built by the shell script. |
| UTILITY-LOC= | Is where the DFHJS2LS shell script is to be found. |
| TARGET-DIR= | Where outputs will be generated. It is a temporary zFS directory whose contents will be copied to the package staging directories if the build is successful. |
| LISTING-DIR= | Where information output will be directed. Contents will be gathered up into a single listing component at the end of the build. |
| COPYLIB= | The named temporary PDSE into which the request and response copybooks will be placed. |
| USER= | The build-submitting user, used in creating activation transactions for CMNBATCH later. |
| SSI= | The build System Status Index (setssi) value for CMNBATCH. |
| PROC= | Name of this build procedure, for CMNBATCH. |
| SRC-LTYP= | Library type of the input like-SRC parameter member, for CMNBATCH. |
| JSON-LTYP= | Library type from which the input JSON schemas will be taken. |
| CPY-LTP= | Library type into which any generated copybooks will be placed, for CMNBATCH. |
| BIND-LTYP= | Library type into which any generated wsbind files will be placed, for CMNBATCH. |
...
These CMNBAQ00 internal parameters are generated within the supplied CMNDFHJL skeleton. An indication of how this is done is given here (from the skeleton itself):
)CM
)CM The following variable definitions customize this process.
)CM They are specified here for clarity but could just as well
)CM be performed in CMN$$VAR.
)CM
)CM &DFHGEN is the temp directory where the json component(s) will
)CM be copied into from the package and where the generated
)CM bind component will be placed. If the build is successful
)CM the bind cmpnt will be copied back to staging directory.
)CM &DFHLST is the temporary directory where all zfs hosted
)CM listings will be placed. These will be consolidated
)CM into the overall build listing at the end of the process.
)SETF DFHGEN = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmngen)
)SETF DFHLST = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmnlst)
)CM
)CM &JHOME is the home directory for Java (in the format required
)CM by the DFHJS2LS script as supplied by IBM)
)CM &DFHUSS is the intermediate zfs node (as required by
)CM by the DFHJS2LS script as supplied by IBM)
)CM &DFHSRV is the service modifier (as required by
)CM by the DFHJS2LS script as supplied by IBM)
)CM &DFHPFX is the path prefix (as required by
)CM by the DFHJS2LS script as supplied by IBM)
)CM &DFHLOC is the location for the DFHJS2LS script
)CM
)SETF JHOME = &STR(java/J8.0_64)
)SETF DFHUSS = &STR(cicsts52)
)SETF DFHSRV = &STR(:)
)SETF DFHPFX = &STR(/Service)
)SETF DFHLOC = &STR(/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/)
)SETF DFHLOC = &STR(&DFHLOC.DFHJS2LS)
)CM
)CM &DFHLIB is the name of the temporary PDSE into which the
)CM generated copybooks will be placed. If the build is successful
)CM they will be copied back to the relevant staging library.
)CM e.g. DSN=yourhlq.userid.date.time.CICS.CPY
)CM
)CM Note that this dsname must not be allocated by JCL to any step
)CM in this job else the USS process will get an allocation error
)CM on it. We need to copy the contents to a different temp PDSE
)CM in order to work with it in later steps, this &CPYLIB.
)CM
)SETF DFHLIB = &STR(yourhlq.&STGERID)
)SETF DFHLIB = &STR(&DFHLIB..D&SYMDEF(LYYMMDD).T&SYMDEF(LHHMMSS))
)SETF CPYLIB = &STR(&DFHLIB..TEMP.CPY)
)SETF DFHLIB = &STR(&DFHLIB..CICS.CPY)
)CM
)CM &BINDLTP is the ZMF library type for the generated wsbind cmpnts
)CM &JSONLTP is the ZMF library type for the input json cmpnt(s)
)CM &CPYLTP is the ZMF library type for the generated copybook cmpnts
)CM
)SETF BINDLTP = &STR(WSB)
)SETF JSONLTP = &STR(JSN)
)SETF CPYLTP = &STR(WCP)
)CM
The DFHJS2LS utility is invoked using an IBM-supplied shell script which expects the relevant parameters to be in a zFS file at a specific location. The shell command is generated by CMNBAQ00 and is passed in the output file allocated to ddname CMNSTDPM. This command, using the parameter values entered above, looks like this (as directed by IBM):
SH /Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHJS2LS
java/J8.0_64
cicsts52
/tmp/STEV001485/WSER58/cics/cmngen/JS2LS
:
/Service
The parameters used to drive the execution of the DFHJS2LS utility need to be written to a zFS file. This is done by passing a series of CMNHUTIL commands with ddname CMNHUTIL.
-
The two input JSON schemas must be present in the package in which these components are being built.
-
The IBM-supplied utility will generate names for the copybooks based on the prefixes (up to 6 bytes) specified in the REQMEM and RESPMEM parameters. The utility will add nn (for example, 01) to the end of the prefixes. The copybooks will be written to the PDSE specified in the COPYLIB= parameter.
-
CMNBATCH transactions which will be used to activate the various generated components (except for the generated copybooks, whose names will be generated by the IBM utility) are written to the CMNBAT90 ddname.
-
Indication of everything that CMNBAQ00 has done is written to SYSPRINT.
-
The RUNUTIL step follows execution of CMNBAQ00. It executes CMNHUTIL using the commands generated by CMNBAQ00 to the CMNHUTIL output ddname. This step sets up the input expected by the DFHJS2LS utility when it runs.
-
The step called DFHJS2LS runs BPXBATCH to execute the shell command passed from the CMNSTDPM ddname of the CMNBAQ00 step. This step generates the required outputs.
-
If the generation is successful, the next step, CPY4BT90, copies all generated copybooks to a separate temp PDSE that can be allocated to the follow-on step, in the JCL, without conflicting with the spawned USS process which wrote them in the first place. The follow-on step, BAT90CPY, executes CMNBAT90 to analyze the contents of the temp PDSE in order to generate the activation transactions for all generated copybook names.
-
Subsequently, step CPY2STG copies the generated copybooks back to the staging library. Step ZFS2STG copies the zFS components (that is, the bind file) to the relevant staging directory.
-
The SUCCESS step, executing CMNBATCH, makes the original like-SRC component active and then, directed by the CMNBAT90 output from CMNBAQ00, activates all the generated components.
-
Additional steps follow to deal with build failures and tidy up the intermediate working directories and PDSE.
The source-to-load display for a successfully built DFHJS2LS parameter component looks like this:
CMN2R2LD Source to Load Relationship Row 1 to 4 of 4
Command ===> Scroll ===> CSR
Package: STEV001485 Status: DEV Install date: 20180820
Source name . . . . CBLJSON +
Lib type . . . . . J2L
Setssi . . . . . . 6D809900
Related Load Modules:
Name + Type Promotion Changed User Setssi
CobolJSON.wsbind WSB 0 STAGING 20180320 055235 WSER58 6D809900
CBLJSON LST 0 STAGING 20180320 055238 WSER58 6D809900
CBLJSON.J2L.list LSH 0 STAGING 20180320 055238 WSER58 6D809900
JSREQ01 WCP 0 STAGING 20180320 055235 WSER58 6D809900
JSRESP01 WCP 0 STAGING 20180320 055235 WSER58 6D809900
******************************* Bottom of data ********************************
The names of the generated components are formed as follows:
-
The LST listing takes the name of the original like-SRC component, in this case CBLJSON.
-
The LSH listing has the source library type and the literal 'list' appended, in this case CBLJSON.J2L.list.
-
The bind component name takes the form
.wsbind where is taken from one of three sources in order of preference: -
From the WSBIND=xxxx/xxxx/xxxx/
.wsbind parameter statement present in the original like-SRC parameter component. This is typically how this value will be assigned. -
From the SERVICE-NAME=
parameter statement present in the original like-SRC parameter component. This is atypical for this process and is included for compatibility with the zosConnect build process. -
From the PGMNAME=
parameter as supplied by the skeleton input. Again atypical, but this provides a backstop.
-
-
The request copybook component name takes the form
nn where is taken from the REQMEM= parameter statement present in the original like- SRC parameter component, and nn is the suffix added by the IBM utility (for example, 01). -
The response copybook component name takes the form
nn where is taken from the RESPMEM= parameter statement present in the original like-SRC parameter component, and nn is the suffix added by the IBM utility (for example, 01).
Generate Copybooks from WSDL Input (CMNDFHWL Skeleton)
This process requires an input like-SRC parameter component in which any directives required to be passed to the IBM-provided utility DFHWS2LS must be placed. This must include the name prefixes for the request and response copybooks which will be generated by the process as well as the names of the WSDL from which the bind file and copybooks are generated. An example parameter member might look like this:
REQMEM=WSREQ
RESPMEM=WSRESP
WSDL=/u/wser58/CobolService.wsdl
WSBIND=CobolSoap.wsbind
BINDING=WSDLCBLHTTPSoapBinding12
LANG=COBOL
MAPPING-LEVEL=4.0
CHAR-VARYING=YES
PGMNAME=WSDLCBL
URI=http://host_computer:7082/CobolService/CobolService
PGMINT=COMMAREA
SYNCONRETURN=YES
CMNDFHWL is the skeleton that contains the sample procedure. CMNDFHWL has the following steps:
-
SERCOPY copies the input parameter member to a temporary data set which is passed to the subsequent execution of CMNBAQ00.
-
CPY$ALC dynamically allocates the named temporary PDSE into which the required copybooks will be generated. This library must not be allocated in the JCL of any step in this job; otherwise, there will be contention issues with the BPXBATCH-spawned process which does the writing of the copybooks to this PDSE. We also allocate a second version of this PDSE into which the copybooks are copied so that this version can be allocated in JCL by the later CMNBAT90 step without causing problems with the spawned process.
-
CR8TEMP executes CMNHUTIL to create the temporary zFS directories used by the build.
-
BAQ00 executes CMNBAQ00 with PARM=DFHWS2LS which tells CMNBAQ00 we are working with a DFHWS2LS build process. The parameters from the SERCOPY step are passed as SYSIN along with extra, skeleton-generated parameters that are used to direct what CMNBAQ00 is doing. For example:
//SYSIN DD DISP=(OLD,DELETE),DSN=&&SOURCE(CBLWSDL)
// DD *
PGMNAME=CBLWSDL
ZMF-PKG=STEV001485
STG-DIR=/cmndev/cmni/STEV/#001485
JAVA-DIR=java/J8.0_64
USS-DIR=cicsts52
SERVICE=:
PATH-PREFIX=/Service
UTILITY-LOC=/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHWS2LS
TARGET-DIR=/tmp/STEV001485/WSER58/cics/cmngen
LISTING-DIR=/tmp/STEV001485/WSER58/cics/cmnlst
COPYLIB=CMNDEV.WSER58.D180320.T082516.CICS.CPY
USER=WSER58
SSI=6D80BCEC
PROC=CMNDFHWL
SRC-LTYP=W2L
BIND-LTYP=WSB
WSDL-LTYP=WSD
CPY-LTYP=WCP
/*
| Parameter | Description |
|---|---|
| PGMNAME= | Is set to the input component name and is used to generate the names of files that are part of the build process. For example, the log file will be written as filename |
| ZMF-PKG= | Is set to the name of the current package and is used to generate appropriate CMNBATCH transactions to activate the generated components. |
| STG-DIR= | Names of the package staging directories, that is, where the input WSDL components will be found. |
...
The next four parameters are all required by the IBM-supplied DFHLS2JS shell script. They should be specified in exactly the same format as you would for that shell script; that is, whatever works with the standard IBM process will work here.
| Parameter | Description |
|---|---|
| JAVA-DIR= | Is an indication of where JAVA can be found. |
| USS-DIR= | Is an intermediate zFS directory node that is used by the script. |
| SERVICE=: | An extra parameter that is used by the script. This parameter should only be changed under direction from IBM. |
| PATH-PREFIX= | Is a high-level node prepended to directory names built by the shell script. |
| UTILITY-LOC= | Is where the DFHWS2LS shell script is to be found. |
| TARGET-DIR= | Where outputs will be generated. It is a temporary zFS directory whose contents will be copied to the package staging directories if the build is successful. |
| LISTING-DIR= | Where information output will be directed. Contents will be gathered up into a single listing component at the end of the build. |
| COPYLIB= | The named temporary PDSE into which the request and response copybooks will be placed. |
| USER= | The build-submitting user, used in creating activation transactions for CMNBATCH later. |
| SSI= | The build System Status Index (setssi) value for CMNBATCH. |
| PROC= | Name of this build procedure, for CMNBATCH. |
| SRC-LTYP= | Library type of the input like-SRC parameter member, for CMNBATCH. |
| WSDL-LTYP= | Library type from which the input WSDL schemas will be taken. |
| CPY-LTP= | Library type into which any generated copybooks will be placed, for CMNBATCH. |
| BIND-LTYP= | Library type into which any generated wsbind files will be placed, for CMNBATCH. |
These CMNBAQ00 internal parameters are generated within the supplied CMNDFHWL skeleton. An indication of how this is done is given here (from the skeleton itself):
)CM
)CM The following variable definitions customize this process.
)CM They are specified here for clarity but could just as well
)CM be performed in CMN$$VAR.
)CM
)CM &DFHGEN is the temporary directory where the wsdl component will
)CM be copied into from the package and where the generated
)CM bind component will be placed. If the build is successful
)CM the bind cmpnt will be copied back to staging directory.
)CM &DFHLST is the temporary directory where all zfs hosted
)CM listings will be placed. These will be consolidated
)CM into the overall build listing at the end of the process.
)SETF DFHGEN = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmngen)
)SETF DFHLST = &STR(&HFSTEMP/&PKGNAME/&STGERID/cics/cmnlst)
)CM
)CM &JHOME is the home directory for Java (in the format required
)CM by the DFHWS2LS script as supplied by IBM)
)CM &DFHUSS is the intermediate zfs node (as required by
)CM by the DFHWS2LS script as supplied by IBM)
)CM &DFHSRV is the service modifier (as required by
)CM by the DFHWS2LS script as supplied by IBM)
)CM &DFHPFX is the path prefix (as required by
)CM by the DFHWS2LS script as supplied by IBM)
)CM &DFHLOC is the location for the DFHWS2LS script
)CM
)SETF JHOME = &STR(java/J8.0_64)
)SETF DFHUSS = &STR(cicsts52)
)SETF DFHSRV = &STR(:)
)SETF DFHPFX = &STR(/Service)
)SETF DFHLOC = &STR(/Service/usr/lpp/cicsts/cicsts52/lib/wsdl/)
)SETF DFHLOC = &STR(&DFHLOC.DFHWS2LS)
)CM
)CM &DFHLIB is the name of the temporary PDSE into which the
)CM generated copybooks will be placed. If the build is successful
)CM they will be copied back to the relevant staging library.
)CM e.g. DSN=yourhlq.userid.date.time.CICS.CPY
)CM
)CM Note that this dsname must not be allocated by JCL to any step
)CM in this job else the USS process will get an allocation error
)CM on it. We need to copy the contents to a different temp PDSE
)CM in order to work with it in later steps, this &CPYLIB.
)CM
)SETF DFHLIB = &STR(yourhlq.&STGERID)
)SETF DFHLIB = &STR(&DFHLIB..D&SYMDEF(LYYMMDD).T&SYMDEF(LHHMMSS))
)SETF CPYLIB = &STR(&DFHLIB..TEMP.CPY)
)SETF DFHLIB = &STR(&DFHLIB..CICS.CPY)
)CM
)CM &BINDLTP is the ZMF library type for the generated wsbind cmpnts
)CM &WSDLLTP is the ZMF library type for the input wsdl cmpnt
)CM &CPYLTP is the ZMF library type for the generated copybook cmpnts
)CM
)SETF BINDLTP = &STR(WSB)
)SETF WSDLLTP = &STR(WSD)
)SETF CPYLTP = &STR(WCP)
)CM
The DFHWS2LS utility is invoked using an IBM-supplied shell script which expects the relevant parameters to be in a zFS file at a specific location. The shell command is generated by CMNBAQ00 and is passed in the output file allocated to ddname CMNSTDPM. This command, using the parameter values entered above, looks like this (as directed by IBM):
SH /Service/usr/lpp/cicsts/cicsts52/lib/wsdl/DFHWS2LS
java/J8.0_64
cicsts52
/tmp/STEV001485/WSER58/cics/cmngen/WS2LS
:
/Service
The parameters used to drive the execution of the DFHWS2LS utility need to be written to a zFS file. This is done by passing a series of CMNHUTIL commands with ddname CMNHUTIL.
-
The input WSDL must be present in the package in which these components are being built.
-
The IBM utility will generate names for the copybooks based on the prefixes (up to 6 bytes) specified in the REQMEM and RESPMEM parameters. It will add nn (for example, 01) to the end of the prefixes. The copybooks will be written to the PDSE specified in the COPYLIB= parameter.
-
CMNBATCH transactions which will be used to activate the various generated components (except for the generated copybooks, whose names will be generated by the IBM utility) are written to the CMNBAT90 ddname.
-
Indication of everything that CMNBAQ00 has done is written to SYSPRINT.
-
The RUNUTIL step follows execution of CMNBAQ00. RUNUTIL executes CMNHUTIL using the commands generated by CMNBAQ00 to the CMNHUTIL output ddname. This step sets up the input expected by the DFHWS2LS utility when it runs.
-
The step called DFHWS2LS runs BPXBATCH to execute the shell command passed from the CMNSTDPM ddname of the CMNBAQ00 step. This step generates the required outputs.
-
If the generation is successful, the next step, CPY4BT90, copies all generated copybooks to a separate temp PDSE which can be allocated to the follow-on step, in the JCL, without conflicting with the spawned USS process which wrote them in the first place. The follow-on step, BAT90CPY, executes CMNBAT90 to analyze the contents of the temp PDSE in order to generate the activation transactions for all generated copybook names.
-
Step CPY2STG copies the generated copybooks back to the staging library and step ZFS2STG copies the zFS components (that is, the bind file) to the relevant staging directory.
-
The SUCCESS step, executing CMNBATCH, makes the original like-SRC component active and then, directed by the CMNBAT90 output from CMNBAQ00, activates all the generated components.
-
Additional steps follow to deal with build failures and tidy up the intermediate working directories and PDSE.
The source-to-load display for a successfully built DFHWS2LS parameter component looks like this:
CMNSR2LD Source to Load Relationship Row 1 to 4 of 4
Command ===> Scroll ===> CSR
Package: STEV001485 Status: DEV Install date: 20180820
Source name . . . . CBLWSDL +
Lib type . . . . . W2L
Setssi . . . . . . 6D80BCEC
Related Load Modules:
Name + Type Promotion Changed User Setssi
CobolSoap.wsbind WSB 0 STAGING 20180320 082623 WSER58 6D80BCEC
CBLWSDL LST 0 STAGING 20180320 082626 WSER58 6D80BCEC
CBLWSDL.W2L.list LSH 0 STAGING 20180320 082626 WSER58 6D80BCEC
WSREQ01 WCP 0 STAGING 20180320 082623 WSER58 6D80BCEC
WSRESP01 WCP 0 STAGING 20180320 082623 WSER58 6D80BCEC
******************************* Bottom of data ********************************
...
The names of the generated components are formed as follows:
-
The LST listing takes the name of the original like-SRC component, in this case CBLWSDL.
-
The LSH listing has the source library type and the literal 'list' appended, in this case CBLWSDL.W2L.list.
-
The bind component name takes the form
.wsbind where is taken from one of three sources in order of preference: -
From the WSBIND=xxxx/xxxx/xxxx/
.wsbind parameter statement present in the original like-SRC parameter component. This is typically how this value will be assigned. -
From the SERVICE-NAME=
parameter statement present in the original like-SRC parameter component. This is atypical for this process and is included for compatibility with the zosConnect build process. -
From the PGMNAME=
parameter as supplied by the skeleton input. Again atypical, but this provides a backstop.
-
-
The request copybook component name takes the form
nn where is taken from the REQMEM= parameter statement present in the original like-SRC parameter component, and nn is the suffix added by the IBM utility (for example, 01). -
The response copybook component name takes the form
nn where is taken from the RESPMEM= parameter statement present in the original like-SRC parameter component, and nn is the suffix added by the IBM utility (for example, 01).