VTAM & Cross Domain Resources

Discussion:

VTAM & Cross Domain Resources - Help!

(too old to reply)

Matt Gourley

2012-06-20 20:15:49 UTC

Greetings,

I'm trying to get a Cross Domain Resource to work so our users can print
to the printing queues (via VPS/DRS) on one LPAR (LPAR-A) from their
applications on another LPAR (LPAR-B). Here's what I've verified:

- Printing works from TSO on LPAR-A.
- Printing works via VTAM from applications running on LPAR-A.
- LPAR-B's applications know to send their print requests for the
printer named TCP2610P to LPAR-A (CDRM04):

D NET,ID=CDVPST,E
IST097I DISPLAY ACCEPTED
IST075I NAME = CDVPST, TYPE = CDRSC SEGMENT 472
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST478I CDRSCS:
IST483I TCP2610P ACTIV , CDRM = CDRM04 , NETID = CACVTAM

- These requests (from LPAR-B, via CDRM06) get as far as LPAR-A, where
they're rejected:

CDINIT REQUEST FROM CDRM06 FAILED, SENSE=08880008 511
REAL OLU=CACVTAM.TCOM REAL DLU=CACVTAM.TCP2610P
SID = E69B8A588E309FC0
END

A search for SENSE=08880008 tells me that "[t]he specified OLU real
network name is known, but is a duplicate resource."

My VTAM knowledge is unfortunately limited. Is there someone who can
help me troubleshoot this?

Thanks in advance,

-Matt
--
Matt Gourley
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-865-8726
***@psu.edu

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Chris Mason

2012-06-20 23:21:45 UTC

Permalink

Matt

Is there someone who can help me troubleshoot this?

To answer your question, precisely as posed, is probably yes.

Now let's see whether this particular "someone" can answer the plea contained in the "Subject" line which would correspond to the following as a last sentence:

"Would someone help me troubleshoot this?", "please" optional!

-

What you need to do is determine how resource names CACVTAM.TCP2610P and CACVTAM.TCOM are represented within the control blocks of the VTAM running in LPAR-A, the VTAM making the complaint concerning "duplicate resources". You imply that you successfully use CACVTAM.TCP2610P as a resource representing a printer within the VTAM running in LPAR-A so I suspect your problem is with resource CACVTAM.TCOM.

You should post the output of the following commands in LPAR-A:

D NET,ID=TCP2610P,E
D NET,ID=TCOM,E

You should also post the statements from VTAMLST members which contain these two resource names. You need to post just the relevant statements but including the VBUILD (LBUILD?, BUILD?) header statements. I assume that the members, formally described as "major nodes", are active at the time the problem manifests itself. Typically they will be listed in your ATCCONxx member.

Do you have just one network identifier, NETID, for these two VTAMs?

What change have you made recently which gave rise to the appearance of this problem? For example, have you just created the LPAR-B system as a "clone" with what are assumed to be minimal required changes of the LPAR-A system?

-

My VTAM knowledge is unfortunately limited.

What does your colleague who is responsible for maintaining VTAM and has had sufficient VTAM education for the role of supporting a presumed critical aspect of your activities[1] say about this problem?

-

- Printing works from TSO on LPAR-A.
- Printing works via VTAM from applications running on LPAR-A.

Why are there two line items here? Surely "from TSO" is just a special case of "via VTAM from applications running".

-

[1] I said "business" but then I noticed you support university students!

-

Chris Mason

Greetings,
I'm trying to get a Cross Domain Resource to work so our users can print
to the printing queues (via VPS/DRS) on one LPAR (LPAR-A) from their
- Printing works from TSO on LPAR-A.
- Printing works via VTAM from applications running on LPAR-A.
- LPAR-B's applications know to send their print requests for the
D NET,ID=CDVPST,E
IST097I DISPLAY ACCEPTED
IST075I NAME = CDVPST, TYPE = CDRSC SEGMENT 472
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST483I TCP2610P ACTIV , CDRM = CDRM04 , NETID = CACVTAM
- These requests (from LPAR-B, via CDRM06) get as far as LPAR-A, where
CDINIT REQUEST FROM CDRM06 FAILED, SENSE=08880008 511
REAL OLU=CACVTAM.TCOM REAL DLU=CACVTAM.TCP2610P
SID = E69B8A588E309FC0
END
A search for SENSE=08880008 tells me that "[t]he specified OLU real
network name is known, but is a duplicate resource."
My VTAM knowledge is unfortunately limited. Is there someone who can
help me troubleshoot this?
Thanks in advance,
-Matt
--
Matt Gourley

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Matt Gourley

2012-06-21 12:37:46 UTC

Permalink

Post by Chris Mason
Matt

Is there someone who can help me troubleshoot this?

To answer your question, precisely as posed, is probably yes.
"Would someone help me troubleshoot this?", "please" optional!

Chris,

I apologize for my lack of courtesy. I've spent a couple of days trying
to get this thing to work, with help only from the manuals. The thing
I'm learning about VTAM is it seems to be a lot like UNIX: the manuals
are great if you know what you're doing. If not, well, Here Be Dragons.

(I'm coming from a *nix background myself. Please be gentle!)

Post by Chris Mason
-
What you need to do is determine how resource names CACVTAM.TCP2610P and CACVTAM.TCOM are represented within the control blocks of the VTAM running in LPAR-A, the VTAM making the complaint concerning "duplicate resources". You imply that you successfully use CACVTAM.TCP2610P as a resource representing a printer within the VTAM running in LPAR-A so I suspect your problem is with resource CACVTAM.TCOM.
D NET,ID=TCP2610P,E
D NET,ID=TCOM,E

D NET,ID=TCP2610P,E
IST097I DISPLAY ACCEPTED
IST075I NAME = CACVTAM.TCP2610P, TYPE = APPL
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1447I REGISTRATION TYPE = NO
IST977I MDLTAB=***NA*** ASLTAB=***NA***
IST861I MODETAB=MT3270 USSTAB=***NA*** LOGTAB=***NA***
IST934I DLOGMOD=S3270 USS LANGTAB=***NA***
IST1632I VPACING = 63
IST1938I APPC = NO
IST597I CAPABILITY-PLU ENABLED ,SLU ENABLED ,SESSION LIMIT 00000001
IST231I APPL MAJOR NODE = APPLDRST
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1500I STATE TRACE = OFF
IST271I JOBNAME = DRST, STEPNAME = DRST, DSPNAME = ISTA38DB
IST228I ENCRYPTION = OPTIONAL , TYPE = DES
IST1563I CKEYNAME = TCP2610P CKEY = PRIMARY CERTIFY = NO
IST1552I MAC = NONE MACTYPE = NONE
IST1050I MAXIMUM COMPRESSION LEVEL - INPUT = 0, OUTPUT = 0
IST1633I ASRCVLM = 1000000
IST1634I DATA SPACE USAGE: CURRENT = 0 MAXIMUM = 0
IST171I ACTIVE SESSIONS = 0000000000, SESSION REQUESTS = 0000000000
IST172I NO SESSIONS EXIST
IST314I END

D NET,ID=TCOM,E
IST097I DISPLAY ACCEPTED
IST075I NAME = CACVTAM.TCOM, TYPE = APPL
IST486I STATUS= CONCT, DESIRED STATE= CONCT
IST1447I REGISTRATION TYPE = NO
IST977I MDLTAB=***NA*** ASLTAB=***NA***
IST861I MODETAB=***NA*** USSTAB=***NA*** LOGTAB=***NA***
IST934I DLOGMOD=***NA*** USS LANGTAB=***NA***
IST1632I VPACING = 7
IST1938I APPC = NO
IST597I CAPABILITY-PLU INHIBITED,SLU INHIBITED,SESSION LIMIT NONE
IST231I APPL MAJOR NODE = APPLTCOM
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1500I STATE TRACE = OFF
IST271I JOBNAME = ***NA***, STEPNAME = ***NA***, DSPNAME = ***NA***
IST228I ENCRYPTION = OPTIONAL , TYPE = DES
IST1563I CKEYNAME = TCOM CKEY = PRIMARY CERTIFY = NO
IST1552I MAC = NONE MACTYPE = NONE
IST1050I MAXIMUM COMPRESSION LEVEL - INPUT = 0, OUTPUT = 0
IST1633I ASRCVLM = 1000000
IST1634I DATA SPACE USAGE: CURRENT = ***NA*** MAXIMUM = ***NA***
IST171I ACTIVE SESSIONS = 0000000000, SESSION REQUESTS = 0000000000
IST172I NO SESSIONS EXIST
IST314I END

Post by Chris Mason
You should also post the statements from VTAMLST members which contain these two resource names. You need to post just the relevant statements but including the VBUILD (LBUILD?, BUILD?) header statements. I assume that the members, formally described as "major nodes", are active at the time the problem manifests itself. Typically they will be listed in your ATCCONxx member.

DRSAPPL VBUILD TYPE=APPL
TCP2610P APPL EAS=1,VPACING=63,SESSLIM=YES,
ACBNAME=TCP2610P,
DLOGMOD=S3270,MODETAB=MT3270

APPLTCOM VBUILD TYPE=APPL
TCOM APPL AUTH=(ACQ),EAS=300,ACBNAME=TCOM

Post by Chris Mason
Do you have just one network identifier, NETID, for these two VTAMs?

Yes. Everything is in the CACVTAM NETID.

Post by Chris Mason
What change have you made recently which gave rise to the appearance of this problem? For example, have you just created the LPAR-B system as a "clone" with what are assumed to be minimal required changes of the LPAR-A system?

These LPARs are in our test plex. They do not always accurately reflect
what's going on in production, and changes that are made to help one
person solve one test problem may break something else.

We are able to print to our VPS/DRS queues in production. I'm trying to
determine what the difference is between production and test, and am
seeing no differences.

Post by Chris Mason
-

My VTAM knowledge is unfortunately limited.

He retired 8 years ago, before I was hired. He was great at building
our VTAM network, but not as good at documentation. (Not just the
*hows* but the *whys*.)

Post by Chris Mason
-

- Printing works from TSO on LPAR-A.
- Printing works via VTAM from applications running on LPAR-A.

Why are there two line items here? Surely "from TSO" is just a special case of "via VTAM from applications running".

"From TSO" in this case is printing to a VPS-defined printer via TCPIP.
DRS routes printer output via VTAM to the JES spool, and VPS picks it up
from there and prints it. In other words, I've ruled out VPS and DRS,
and have narrowed it down to a cross domain problem.

Thanks again,

-Matt

Post by Chris Mason
-
[1] I said "business" but then I noticed you support university students!
-
Chris Mason

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Matt Gourley
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-865-8726
***@psu.edu

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Chris Mason

2012-06-21 15:29:54 UTC

Permalink

Matt

Post by Matt Gourley

Post by Chris Mason
For example, have you just created the LPAR-B system as a "clone" with what are assumed to be minimal required changes of the LPAR-A system?

It appears you have copied the APPL statement with name TCOM from system LPAR-A to system LPAR-B without paying attention to the most fundamental of all SNA principles that you ***cannot*** have two SNA resources - of the type SSCP, PU and LU - with the same name under the same network identifier - or - think about it - how is poor old SNA to know which one you may happen to have in mind whenever you use a name which is, in principle, ambiguous?[1]

I'll try to find time to say more about this post later.

Meantime, if you can simply rename TCOM to TCOMA, say, in LPAR-A and to TCOMB in LPAR-B, that would solve the problem.

Or if you or someone near you can manipulate the name of the APPL statement in conjunction with the ACBNAME operand, that may be a more convenient alternative. You use the value of the ACBNAME operand for same-domain sessions and use the APPL statement name for cross-domain sessions.

-

[1] There are some pragmatic relaxations of this slightly rusty rule in certain VTAM-managed circumstances but your "ambiguity" is *not* one of them.

[2] Say a manager who used to look after VTAM a decade or so ago as there was - from userid evidence! - in the last customer I assisted.

-

Chris Mason

Post by Matt Gourley

Post by Chris Mason
Matt

Is there someone who can help me troubleshoot this?

To answer your question, precisely as posed, is probably yes.
"Would someone help me troubleshoot this?", "please" optional!

Chris,
I apologize for my lack of courtesy. I've spent a couple of days trying
to get this thing to work, with help only from the manuals. The thing
I'm learning about VTAM is it seems to be a lot like UNIX: the manuals
are great if you know what you're doing. If not, well, Here Be Dragons.
(I'm coming from a *nix background myself. Please be gentle!)

D NET,ID=TCP2610P,E
IST097I DISPLAY ACCEPTED
IST075I NAME = CACVTAM.TCP2610P, TYPE = APPL
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1447I REGISTRATION TYPE = NO
IST977I MDLTAB=***NA*** ASLTAB=***NA***
IST861I MODETAB=MT3270 USSTAB=***NA*** LOGTAB=***NA***
IST934I DLOGMOD=S3270 USS LANGTAB=***NA***
IST1632I VPACING = 63
IST1938I APPC = NO
IST597I CAPABILITY-PLU ENABLED ,SLU ENABLED ,SESSION LIMIT 00000001
IST231I APPL MAJOR NODE = APPLDRST
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1500I STATE TRACE = OFF
IST271I JOBNAME = DRST, STEPNAME = DRST, DSPNAME = ISTA38DB
IST228I ENCRYPTION = OPTIONAL , TYPE = DES
IST1563I CKEYNAME = TCP2610P CKEY = PRIMARY CERTIFY = NO
IST1552I MAC = NONE MACTYPE = NONE
IST1050I MAXIMUM COMPRESSION LEVEL - INPUT = 0, OUTPUT = 0
IST1633I ASRCVLM = 1000000
IST1634I DATA SPACE USAGE: CURRENT = 0 MAXIMUM = 0
IST171I ACTIVE SESSIONS = 0000000000, SESSION REQUESTS = 0000000000
IST172I NO SESSIONS EXIST
IST314I END
D NET,ID=TCOM,E
IST097I DISPLAY ACCEPTED
IST075I NAME = CACVTAM.TCOM, TYPE = APPL
IST486I STATUS= CONCT, DESIRED STATE= CONCT
IST1447I REGISTRATION TYPE = NO
IST977I MDLTAB=***NA*** ASLTAB=***NA***
IST861I MODETAB=***NA*** USSTAB=***NA*** LOGTAB=***NA***
IST934I DLOGMOD=***NA*** USS LANGTAB=***NA***
IST1632I VPACING = 7
IST1938I APPC = NO
IST597I CAPABILITY-PLU INHIBITED,SLU INHIBITED,SESSION LIMIT NONE
IST231I APPL MAJOR NODE = APPLTCOM
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1500I STATE TRACE = OFF
IST271I JOBNAME = ***NA***, STEPNAME = ***NA***, DSPNAME = ***NA***
IST228I ENCRYPTION = OPTIONAL , TYPE = DES
IST1563I CKEYNAME = TCOM CKEY = PRIMARY CERTIFY = NO
IST1552I MAC = NONE MACTYPE = NONE
IST1050I MAXIMUM COMPRESSION LEVEL - INPUT = 0, OUTPUT = 0
IST1633I ASRCVLM = 1000000
IST1634I DATA SPACE USAGE: CURRENT = ***NA*** MAXIMUM = ***NA***
IST171I ACTIVE SESSIONS = 0000000000, SESSION REQUESTS = 0000000000
IST172I NO SESSIONS EXIST
IST314I END

DRSAPPL VBUILD TYPE=APPL
TCP2610P APPL EAS=1,VPACING=63,SESSLIM=YES,
ACBNAME=TCP2610P,
DLOGMOD=S3270,MODETAB=MT3270
APPLTCOM VBUILD TYPE=APPL
TCOM APPL AUTH=(ACQ),EAS=300,ACBNAME=TCOM

Post by Chris Mason
Do you have just one network identifier, NETID, for these two VTAMs?

Yes. Everything is in the CACVTAM NETID.

These LPARs are in our test plex. They do not always accurately reflect
what's going on in production, and changes that are made to help one
person solve one test problem may break something else.
We are able to print to our VPS/DRS queues in production. I'm trying to
determine what the difference is between production and test, and am
seeing no differences.

Post by Chris Mason
-

My VTAM knowledge is unfortunately limited.

He retired 8 years ago, before I was hired. He was great at building
our VTAM network, but not as good at documentation. (Not just the
*hows* but the *whys*.)

Post by Chris Mason
-

- Printing works from TSO on LPAR-A.
- Printing works via VTAM from applications running on LPAR-A.

Why are there two line items here? Surely "from TSO" is just a special case of "via VTAM from applications running".

Post by Chris Mason
-
[1] I said "business" but then I noticed you support university students!
-
Chris Mason

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Matt Gourley
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-865-8726
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Robert Harrison

2012-06-21 15:33:31 UTC

Permalink

Matt,
I hope that I can help you. We have VPS, VPS/PCL, and VPS/TCPIP.
We do not have VPS/DRS.

What has caught my eye is your statement "from LPAR-B, via CDRM06".

From "SC31-8791-10 z/OS V1R12.0 Comm Svr: IP and SNA Codes" manual:

<snip>
VTAM hint: Sense code 0888000n might be issued when an attempt to
establish a session fails in an intermediate VTAM along the session setup
path. This error might occur because the intermediate VTAM that set the
sense code is operating with NQNMODE=NAME or is a pre-V4 VTAM. Therefore,
the intermediate VTAM cannot define multiple resources with the same name
even though the network identifiers are different.

Change the intermediate domain to operate with NQNMODE=NQNAME to allow
definition of multiple resources with the same name and different network
identifiers, or reroute the session through another path.
<end snip>

Those make me wonder whether CDRM06 is the node that holds the missing link to the problem.
Are there any messages showing up there about this problem?
Are there definitions for the printer on the CDRM06 system?

Alternatively, Do you have VPS available on LPAR-B?
Why not define the printer directly to the VPS on LPAR-B and cut out all of the middle-men?

Another possibility: are the JESes on LPAR-A and LPAR-B defined to each other (i.e. NJE) ?
We can print from our LPAR-B (Node2) to our LPAR-A (Node1) by specifying the output to go to N<node#>.<printer name>
(i.e. N1.PRINTER1).
The JES on LPAR-B, NJE's the output to LPAR-A, and our VPS on LPAR-A sends it to the printer.

Robert Harrison
Technology Services Division
Oklahoma Department of Transportation

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Barkow, Eileen

2012-06-21 16:58:49 UTC

Permalink

We use DRS going cross domain and have no problems with it.

You need to:

1. define cross domain resource on lpar for DRS virtual device where application runs
DRSLU001 CDRSC CDRM=HOSTMVS,ISTATUS=ACTIVE
Make sure that DRSLU001 is not already defined as as APPL on the lpar and that the correct CRDM is used

2. define VTAM APPLID on lpar for DRS virtual device where DRS resides
DRSLU001 APPL ACBNAME=DRSLU001,EAS=1,VPACING=63,SESSLIM=YES, X
DLOGMOD=SCS,MODETAB=CSCMOD
Make sure that DRSLU001 is not already defined as a CDRSC on lpar

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@listserv.ua.edu] On Behalf Of Matt Gourley
Sent: Wednesday, June 20, 2012 4:05 PM
To: IBM-***@listserv.ua.edu
Subject: VTAM & Cross Domain Resources - Help!

Greetings,

I'm trying to get a Cross Domain Resource to work so our users can print to the printing queues (via VPS/DRS) on one LPAR (LPAR-A) from their applications on another LPAR (LPAR-B). Here's what I've verified:

- Printing works from TSO on LPAR-A.
- Printing works via VTAM from applications running on LPAR-A.
- LPAR-B's applications know to send their print requests for the printer named TCP2610P to LPAR-A (CDRM04):

D NET,ID=CDVPST,E
IST097I DISPLAY ACCEPTED
IST075I NAME = CDVPST, TYPE = CDRSC SEGMENT 472 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST478I CDRSCS:
IST483I TCP2610P ACTIV , CDRM = CDRM04 , NETID = CACVTAM

- These requests (from LPAR-B, via CDRM06) get as far as LPAR-A, where they're rejected:

CDINIT REQUEST FROM CDRM06 FAILED, SENSE=08880008 511
REAL OLU=CACVTAM.TCOM REAL DLU=CACVTAM.TCP2610P
SID = E69B8A588E309FC0
END

A search for SENSE=08880008 tells me that "[t]he specified OLU real network name is known, but is a duplicate resource."

My VTAM knowledge is unfortunately limited. Is there someone who can help me troubleshoot this?

Thanks in advance,

-Matt
--
Matt Gourley
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-865-8726
***@psu.edu

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN