On 6/20/2012 19:20, Chris Mason wrote:
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!
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!)
-
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
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
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
Do you have just one network identifier, NETID, for these two VTAMs?
Yes. Everything is in the CACVTAM NETID.
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.
-
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?
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*.)
-
Incidentally:
- 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
-
[1] I said "business" but then I noticed you support university students!
-
Chris Mason
On Wed, 20 Jun 2012 16:04:40 -0400, Matt Gourley <mmg...@psu.edu> wrote:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Matt Gourley
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-865-8726
mmg...@psu.edu
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
