Re: VTAM Cross domain
Sorry. Reply to receive all this interesting information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTAM Cross Domain Resources - Help!
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 0001 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 = 100 IST1634I DATA SPACE USAGE: CURRENT = 0 MAXIMUM = 0 IST171I ACTIVE SESSIONS = 00, SESSION REQUESTS = 00 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 = 100 IST1634I DATA SPACE USAGE: CURRENT = ***NA*** MAXIMUM = ***NA*** IST171I ACTIVE SESSIONS = 00, SESSION REQUESTS = 00 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. -
Re: VTAM Cross Domain Resources - Help!
Matt As I suspected: 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 On Thu, 21 Jun 2012 08:36:26 -0400, Matt Gourley mmg...@psu.edu wrote: 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 0001 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 = 100 IST1634I DATA SPACE USAGE: CURRENT = 0 MAXIMUM = 0 IST171I ACTIVE SESSIONS = 00, SESSION REQUESTS = 00 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 = 100 IST1634I DATA SPACE USAGE: CURRENT = ***NA*** MAXIMUM = ***NA*** IST171I ACTIVE SESSIONS = 00, SESSION REQUESTS = 00 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
Re: VTAM Cross Domain Resources - Help!
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 Nnode#.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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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.TCOMREAL 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 mmg...@psu.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTAM Cross Domain Resources - Help!
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? - 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. - [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.TCOMREAL 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
