I followed by the redbook sg24-8205-01, installed RD&T v9.1 in SUSE 11SP3 (eth1 IP: 10.233.82.148), the SUSE linux running on VM machine.  I have two client PC, one linux (IP: 10.233.82.150), one windows (IP: 10.232.68.119).

I migrated customer's z/OS to RD&T environment. The z/OS system ipl OK & works fine. I can access it from linux client through command "x3270 10.233.82.148:3270".  But when I access the z/OS from windows client P-COM, the first logon screen show OK, I input "L TSO" + enter, it return a blank screen. (see attach pictures).

How could I trace & resolve this problem? Any comments?

 

Given you got the correct USS message from the client PCOMM, this means the connectivity to z/OS through Linux was good. Since you got this far, you should have gotten a TSO message on the z/OS system console when you tried to log on and failed. Could you see if you got messages after attempting to log on to TSO? They will help tell us what is wrong.

Also, the following information will help.

1) The 3270 definitions in your devmap. They should look something like this:

name aws3274 00xx

device 0700 3279 3274 mstcon

device 0701 3279 3274 tso1

device 0702 3279 3274 tso2

 

2) It would be nice to see the LU definitions in the local non-SNA major node that match the channel unit addresses in the devmap,  The local non-SNA LU definitions give the terminal type, and must be correct based on the terminal trying to connect. When the logon screen comes up, you typically see the local non-SNA LU name. I can see what looks like MVEX03 on the pcomm logon screen. Can you issue a D NET,ID=MVEX03,E on the z/OS console after starting the PCOMM session? Also, when you bring up the logon screen for the X3270 session on linux, it should also have a local non-SNA LU name, probably something similar to MVEXxx. If you could issue a D NET,ID=xxxx,E for that LU name, that would help see which one got used that works.  

 

3) Finally, when you display the D NET,ID=xxxx for the x3270 logon screen LU name, the one that works, at the bottom of that display will be the TSO appl name that is in use. Something like this:

NAME        STATUS          SID        SEND            RECEIVE

A06TSO01 ACTIVE-P    xxxxxxx     0005               000E

 

Could you do a display of that name - D NET,ID=A06TSO01 (or whatever its name is). That will help us know which TSO major node is being used.

Thanks Bebe,

1) The 3270 definitions in our devmap:

[Manager]

name aws3274 0002

device 1D00 3279 3274 PLXMMSTR

device 1D01 3279 3274 mstcon

device 1D02 3279 3274 tso

device 1D03 3279 3274

device 1D04 3279 3274

 

2) I use the following commands:

/D NET,ID=MVEX03,E

/D NET,ID=MVEX03

/D NET,ID=MVEX02

/D NET,ID=MVEX02,E

the command result I take photoes as show in attachment file POC_PIC_06 ~ 10.

 

3)  I also display of network:

/D NET,ID=TRLMGTV

/D NET,ID=TRLMGTV,E

the command result I take photoes as show in attachment file POC_PIC_11

 

We use SYS1.VPLEXMG.UPGRADE.VTAMLST(TRLMGTV) Dataset :

TRLMGTV  VBUILD  TYPE=TRL

 

TRLE0600 TRLE LNCTL=MPC, READ=0600, WRITE=0601, DATAPATH=(0602), PORTNAME=OSAGEBE, MPCLEVEL=QDIO

TRLE0700 TRLE LNCTL=MPC, READ=0700, WRITE=0701, DATAPATH=(0702), PORTNAME=OSAGEBC, MPCLEVEL=QDIO

 

RD&T network configuration:

[manager]

name  awsosa  0009  --path=F0  --pathtype=OSD

device 700 osa osa

device 701 osa osa

device 702 osa osa

[manager]

name  awsosa  0019  --path=A0  --pathtype=OSD  --tunnel-intf=y

device 600 osa osa

device 601 osa osa

device 602 osa osa

 

 

We are working with Jian on this. The displays above show an active TSO session between TSO and PCOMM. So since the TSO session works and displays correctly on the Linux x3270 terminal, and the USS message looks correct on PCOMM, we are investigating a PCOMM configuration issue or perhaps a logmode issue. We will post back when we learn more.

 

 

 

We believe the fix for the scenario 5 issue described in a separate append also fixed this issue. For completeness, I have included that final append here.

 

        Bebe

===========================================================

 

We use command "iptables -L -n -v" & "iptables -L -v -n -t nat" to trace tcpip traffic, found that pkts in 10.1.1.2 is ok, but no pkts out from 10.1.1.2. So the problem maybe cause by the wrong routing configuration in z/OS.

ABC environment TCPIP PROFILE is dataset SYS1.TCPPARMS.UPGRADE(PROFILE):
BEGINRoutes
; Destination Subnet Mask FirstHop Link Size
ROUTE 10.0.0.0 255.0.0.0 = ETH1 MTU 1492
ROUTE DEFAULT 10.1.1.1 ETH1 MTU 1492
ENDRoutes

It must modify as following, because of ABC intranet IP is 10.233.XXX.XXX.:
BEGINRoutes
; Destination Subnet Mask FirstHop Link Size
ROUTE 10.1.1.0 255.255.255.0 = ETH1 MTU 1492
ROUTE DEFAULT 10.1.1.1 ETH1 MTU 1492
ENDRoutes