Depending on the development needs and/or security rules defined at your site, it may be advantageous to define and start multiple instances of the CONNX for VSAM / QSAM / PDS server, either as started tasks, batch jobs, or a mixture of the two. Running the CONNX for VSAM / QSAM / PDS server as a batch job permits each user to test in a separate 'sandbox' environment, with separate versions of target VSAM / QSAM / PDS (physical sequential and partitioned data set) files, and without the need for systems programmer intervention to define new RACF user IDs for the started task procedure names. To define additional started task or batch job environment, use the following steps:

Define the Unique CONNX Environment Variables

1. Review the environment variables defined in default control member CNXPARMS in CONNX.STASK.CNTL. Begin with CNXRUNPORT, which must be unique per instance of the CONNX for VSAM TCP/IP Listener programs, inclusive of all currently running and regularly-scheduled CICS and Started Task versions of CNXRUN and CNXRUNB. Make a copy of this member for the new instance.

2. Review the persistent CONNX environment variables defined in the CNXCFG VSAM KSDS. Display the current persistent CONNX environment variables which reside in the default CNXCFG KSDS by executing the CNXCFG REXX exec file with no parameters.

From the ISPF Command Shell:

cnxcfg

or

exec 'connx.stask.cntl(cnxcfg)'

From any ISPF Command line:

tso cnxcfg

or

tso exec 'connx.stask.cntl(cnxcfg)'

3. The current variables/values defined in the default CNXCFG VSAM KSDS file are displayed on the invoking terminal:
   
   
   
   
    

4. Decide which, if any, CONNX environment variables to define in the CNXCFG KSDS. If this support is required, define a new CNXCFG KSDS using members CNXIDC and IDCCNX0 of CONNX.STASK.CNTL, and update the CNXVSAM / CNXVSCT JCL procedures to point the CNXCFG DDNAME to the new physical data set. If all CONNX environment variables are defined in the CNXPARMS PDS member, the CNXCFG DDNAME / DSN can be DUMMYed out, for example:

//CNXRUNB.CNXCFG DD DUMMY

5. To display, add, update, and delete environment variables/values defined in a new CNXCFG VSAM KSDS, you can use the f(file name) command-line parameter for the CNXCFG REXX file, for example:
   
   
   
   
    

6. Alternatively, make a copy of the CNXCFG REXX exec file, and change the default value for the file parameter in the command text;
   
   
    

7. Change

fpref = "CONNX.STASK"

and

cfgfile = ".cnxcfg"

These entries are concatenated to form the CNXCFG physical data set name, which is by default CONNX.STASK.CNXCFG.

8. Copy or update the CNXVSAM / CNXVSCT JCL procedure(s). Review the VSAM DDNAMEs defined in the CNXVSAM/CNXVSCT JCL procedure(s), add your installation VSAM DDNAME/DSNs, and delete those DDNAMEs/DSNs which are not defined at your site. For newly added VSAM DDNAMEs /DSNs, follow the CONNX import procedures in "To test CONNX for VSAM Started Task / Batch Job SCT Meta Data Import Functionality" on page 5-113 to add VSAM metadata to the CONNX Data Dictionary file.

9. Decide whether to run the copied or updated CNXVSAM or CNXVSCT procedure(s) as started tasks or as batch jobs.

10. If new started task JCL procedures are created, ask your system programmer to define the started task IDs to RACF or a RACF-compatible security package.  If the new CONNX environments are defined as batch jobs, make copies of the CNXVSAMJ or CNXVSCTJ JCL members in the CONNX.STASK.CNTL partitioned data set, and make the necessary changes to the job card and //EXEC statements to reference the new JCL procedure(s):
    
    
     

11. Start the new task(s) or submit the new batch job(s) to the batch execution job queue.