XCOM passing the unexpected userid to the partner

Products

• XCOM Data Transport - z/OS

Issue/Introduction

A transfer initiated by the XCOMJOB batch interface uses SYSIN01 parameter USERID= to specify the user Id that will be used at the partner to perform the transfer.

The messages printed to XCOMLOG DD show that the parameter is accepted. However, the parameter is not used and the partner is presented the MVS ID of the job that executed XCOMJOB

The same effect is observed for parameter LUSER= (user id to be used when scheduling the transfer at the local XCOM started task)   

Cause

This indicates that XCOMJOB is running with default parameter USEROVR=NO. This parameter forces XCOMJOB to use the current MVS ID for processing of the transfer (in other words, it prevents "userid override")

With USEROVR=NO, XCOMJOB accepts SYSIN01 parameters USERID= and LUSER= and prints them as accepted, but simply ignores them so the user identification defaults to that of the MVS user who executes XCOMJOB. This may be a bit confusing.

Resolution

Check the default parameters in effect for the XCOMJOB run that submits the transfer. They print to ddname XCOMINIT. 

If the JCL step does not have a DD statement for XCOMINIT, it will be dynamically allocated. When this happens, since it is allocated with FREE=CLOSE, it may show up as a different entry in the JES2 queue displays and be hard to find.

To ensure you get XCOMINIT output, you can add a DD statement for it in the JCL, for example

//XCOMINIT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=133)

Here is an example XCOMINIT OUTPUT

1   CA XCOM(tm) Data Transport(r) v12.0 for z/OS   I N I T I A L I Z A T I O N   P A R A M E T E R S       
                                                                                                           
 25268 03:24:26.5                            XCOMM1401I Parameters from EXEC PARM= override:               
 25268 03:24:26.5                                                                                          
 25268 03:24:26.5                            TYPE=EXECUTE                                                  
 25268 03:24:26.5                            CONFIG=CONFIG                                                 
 25268 03:24:26.5                            TRACE=YES                                                     
 25268 03:24:26.5                                                                                          
 25268 03:24:26.5                                                                                          
 25268 03:24:26.5                            XCOMM1460I Symbol CONFIGDSN=XCOMCNTL                          
 25268 03:24:26.5                            XCOMM1461I Searching XCOMCNTL  for TYPE=CONFIG member CONFIG  
 25268 03:24:26.5                                                                                          
 25268 03:24:26.5                            XCOMM1400I Parameters from XCOMCNTL  TYPE=CONFIG member CONFIG
 25268 03:24:26.5                                                                                          
 25268 03:24:26.5                            ACBNAME=XCOMAPPL                                              
...
 25268 03:24:26.5                            USEROVR=NO
...

 

In the above example, parameter USEROVR has been read from TYPE=CONFIG member named CONFIG in the library allocated by XCOMCNTL DD. Note that it may also be specified in the JCL PARM, which would override the specification of the TYPE=CONFIG member

You need to ensure that XCOMJOB runs with USEROVR=YES. There are several possible ways:

• Specify the parameter in the JCL PARM
• Specify another member name in CONFIG= parameter in the JCL PARM
• Specify another library name in XCOMCNTL DD
• Adjust the specified TYPE=CONFIG member

WARNING: Adjusting the TYPE=CONFIG member will affect all XCOMJOB's and XCOM started tasks that use it. Please be careful.