Magen So it would seem in pragmatic terms that what you want to do works - "clients were able to connect using generic resource name (MYCICS)" - but that you have an untidy situation in having some resources in POLIOU status. Can any client wanting to create a session using the generic resource name succeed? Is it that any which do not succeed have this status?
If you suspect that you cannot create a "clean" environment in which to begin testing your generic resources configuration because "as long a client is trying to connect", you should make sure that the clients cannot connect. I assume that you could, for example, deactivate the major node or nodes in which the resources showing POLIOU status are defined. You haven't told us how the CICS clients are defined. I assumed that they were defined for use with a TN3270 server of some sort since that is so popular these days compared to the real thing. If you need more help, you should cover that point, explain the key aspects of your configuration and show the VTAM DISPLAY command output which illustrates the resources with the POLIOU status - just one line to illustrate many if there are a large number. Be sure to mention in which VTAM's domain the DISPLAY command was issued. I took the trouble to look through the redbooks where the "generic resource" topic is to some extent covered. These are SNA in a Parallel Sysplex Environment (SG24-2113-01) VTAM V4R4 for MVSESA Implementation Guide (SG24-2100-00) Using VTAM Generic Resources with IMS (SG24-5487-00) and VTAM V4R2 Early User Experiences (GG24-4250-00) Normally, if a topic is covered well in a redbook, there are descriptions with VTAM command outputs which show what a successful set of definitions looks like as coded and in operation. Unfortunately, this does not apply sufficiently thoroughly to these redbooks. I was looking particularly for how, if at all, the generic resource name appeared in DISPLAY command output when entered in the VTAM owning the client LUs. Perhaps someone with a working generic resources configuration can cover that point. Incidentally, there are requirements on a generic resources configuration. For example, your VTAMs must be enabled for APPN and there must be APPN links between the VTAM nodes involved. Please assure us that you have followed up on all these requirements. I can say with some confidence that, because of the way the USERVAR function works, the, specifically *volatile*, USERVAR function being the key function used by the generic resource function, if there is a CDRSC with the generic resource name, DISPLAY command output it will never show any actual sessions associated with the name but may show session requests. This covers a point made in your first post. Chris Mason On Tue, 3 Jun 2008 15:19:33 -0500, Magen Margalit <[EMAIL PROTECTED]> wrote: >Hi Chris > >First of all thanks for the detailed response. > >you wrote >"... in one of the domains where >the secondary LUs have been activated, VTAM is still assuming an association >between MYCICS as a CDRSC and the secondary LUs in the form of a session >request which has the status code POLUIO associated with it. This would >explain the number of session requests being greater than zero. I would >expect it would be easy enough simply to use a command of the form VARY >NET,INACT,ID=MYCICS,DELETE=YES in that domain in order to remove all >trace of MYCICS prior to performing your tests with MYCICS as a generic >resource.[1]" > >And this is exactly what we tried to do, but after issuing >the VARY NET,INACT,ID=MYCICS,DELETE=YES command >issuing a D NET,ID=MYCICS,SCOPE=ALL showed that MYCICS >was still defined as before ... > >My guess was that since this is a dynamic CDRSC it is defined >as long a client is trying to connect (session requests>0) >so he is redefiend again and again > >After Restarting CICS with the new appl name an with MYCICS as >generic resource name it seems that clients were able to connect >using generic resource name (MYCICS)... but still D NET showed >a CDRSC definition with sec-lu in POLIOU status... > > >thanks > >Magen ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
