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 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
