XCOM SNA transfer from z/OS to AS/400 goes INACT for no reason
search cancel

XCOM SNA transfer from z/OS to AS/400 goes INACT for no reason

book

Article ID: 268547

calendar_today

Updated On:

Products

XCOM Data Transport - z/OS XCOM Data Transport XCOM Data Transport - Linux PC XCOM Data Transport - Windows

Issue/Introduction

XCOM SNA transfer from z/OS to AS/400 is scheduled but never executes.

Steps leading to this situation

1.  DISABLE/ENABLE XCOM z/OS DEST table entry  All SNA sessions are dropped.
2. Vary off (INACT) AS/400 CTL/DEV   The AS/400 PU/LU is INACTIVE.
3. Schedule two z/OS initiated transfers   Any session start (GETSESS=YES) will receive sense 087D0001 at each ERRINTV.
4. Vary on (ACT) AS/400 CTL/DEV   At the next ERRINTV the z/OS initiated sessions SNASVCMG/XCOM16K will start, the 2 transfers are performed.
5. Issue a CHGSSNMAX command  A 2nd SNASVCMG session with AS/400 LU being PLU is bound and a AS/400 CNOS is executed.
6. Schedule two z/OS initiated transfers              Those 2 transfers will stay INACTIVE and even if there is a XCOM16K winner session, they won't run.

 

Environment

Release : 12.0

Resolution

Temporary workaround to get the 2 transfers to run:

  • DISABLE/ENABLE XCOM z/OS DEST table entry

Permanent solution:

  • Use 2 LUs (XCOM z/OS dest table entries and AS/400 devices), one for z/OS initiated transfers, one for AS/400 initiated transfers

 

Further details:

Engineering found that the root cause of the problem is related to the use of CHGSSNMAX/STRMOD commands on AS/400.
XCOM z/OS gets the parallel session LU (Two SNASVCMG sessions, one winner, one loser) in a state where z/OS initiated transfers hang. The user manually DISABLE/ENABLEs the XCOM z/OS DEST table entry, and then those hanging z/OS transfers start. Engineering could not reproduce the situation until they used the above AS/400 commands CHGSSNMAX/STRMOD. Those AS/400 commands are not necessary as far as they can see and they don’t have any issues initiating transfers from either side in any order without using them.
They tried to circumvent the problem with an XCOM z/OS configuration change (DROPSESS=NO), but without success. The next best thing is a look on the AS/400 side to see where those CHGSSNMAX (and/or STRMOD) CL commands are used, probably prior to doing an XCOM transfer in a CL program.
The more radical way is the use of one parallel session LU for XCOM z/OS initiated transfers and another LU for AS/400 initiated transfers. No more SNASVCMG session one way, and another the other way, only one way is possible for each LU.

The user will change the z/OS initiated transfers to a new LU. That will be a new dest table entry. For the LU to be known in the network, an entry in the AS/400 local configuration list is required. APPN should take care of VTAM locating the LU.