Magen > We are trying to migrate out CICS TOR from cross domain to VTAM GR.
It's difficult to understand what you might mean by this statement so it's no wonder Pat is confused. "Cross domain" typically means accessing an application in one domain from, according to the evidence, an SNA entity activated within another domain behaving as a secondary LU. "VTAM GR" typically means accessing one of multiple applications all providing the same service according to direction from a load balancing mechanism from an SNA entity behaving as a secondary LU no matter in which domain the LU was activated. As you can see these two are not the same so saying that you are migrating from one to the other would seem to be leaving a lot to be presumed. But I'll give it a try. In the past you have had one CICS system. You now want to run multiple CICS systems set up as a generic resource group within you sysplex. You want your clients not to have to change the name by which they know the CICS service. Perhaps this name is embedded in some customization in the client workstations. I am going to try to follow the steps you mentioned in the light of these guesses. I'm also going to have to try to remember the details of how VTAM behaves without having a test system to hand to verify my guesses so I hope I get it sufficiently right to help you make progress. 1. You close the VTAM ACB corresponding to the CICS system. This has the effect of making the name by which the CICS service is known go from ACTIV to CONCT. 2. You inactivate the VTAM APPL major node which contains the APPL minor node which corresponds to the CICS system - I hope. You activate VTAM APPL major nodes in each system which will support one of your CICS each one with a name which is *not* the same as the name you used for your single CICS system. You redefine/define your CICS systems so that they all know they are members of a generic resource group and they all share the same generic resource name, this name being the same name used previously for the single CICS system. The effect of this is that, as each CICS system makes itself known to VTAM, VTAM is aware that each CICS system is a member of a generic resource group. 3, 4 and 5. Trying to follow what you did I am now lost. > D net to the old TOR appid shows the the cross domain is still there and some terminals are in POLUIO status under it. This appears to be all about a particular SNA name so I'll invent the name MYCICS in order to make discussing it easier. As you clarified to some extent in response to Pat, you display MYCICS and discover it is a dynamic CDRSC in a domain other than the domain or domains where you have defined your CICS systems. When the name is defined as a generic resource name it is treated as an USERVAR. Unfortunately I cannot remember - if I ever knew - whether it makes sense for an USERVAR to appear as a dynamic CDRSC. In case it doesn't it's probably best to make sure that MYCICS disappears as a dynamic CDRSC before testing your generic resources configuration. Some of your description seems to imply that, 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] Forgive me if I have misinterpreted what I think you have been trying to do. One way of reading what you have said is that you have imagined that you need to manipulate the status of the name MYCICS as it appears in one of the domains where the secondary LUs are defined - where MYCICS is a CDRSC - by opening and closing the VTAM ACB defined with the name MYCICS - associated with your original CICS system. This is just not how it works. As Pat mentioned, static CDRSCs need to be activated and deactivated in one domain quite independently of the resource which they represent in another domain. Also as Pat mentioned, dynamic CDRSCs, although created dynamically during the flexible search process, can be deactivated manually or can be left to be deactivated upon expiry of the CDRSCTI timer for subarea or DIRTIME for APPN. Responding to the question at the end of your second post, in order to remove a session or sessions from the VTAM system, you should consider using VARY TERM rather than VARY INACT. If I have not understood your situation and concerns, please post again. If you do please clarify your configurations, before and after. You may also like to be clear over what the secondary LUs are. For example, I could guess that they are APPL statements used by a TN3270 server. I can foresee that, if your secondary LUs are defined as APPL statements on the same system as one of the members of your generic resource group, you may be posting in the future complaining that, despite the load, sessions involving those LUs are never distributed to other members. [1] Nevertheless it is interesting to follow up on the code POLUIO. It is defined as a "session initiation state" and means the following: <quote> Session state: POLUIO Status: Q - queued Meaning: Pending USS message response in OLU direction. The OLU device must respond to the USS message or no sessions will be initialized. </quote> It's difficult to be sure exactly what this means - maybe VTAM development know! It does imply that USS messages are involved and that the secondary LU has decided not to respond to a USS message. This may be an SNA "definite response" to a USS message sent out on the SSCP-LU session in the domain where the secondary LU was activated. Taking a wild guess it may be that the VTAM in that domain has got confused over the nature of the name MYCICS caused by the attempt to redefine it as a generic resource. Chris Mason On Thu, 29 May 2008 05:43:29 -0500, Magen Margalit <[EMAIL PROTECTED]> wrote: >Hi List, > >We are Z/OS 1.7 and CICS TS 2.3 > >We are trying to migrate out CICS TOR from cross domain to VTAM GR. >We have followed following procedure: >1. Shutting down TOR >2. Make definition chages in order that current applid will be VTAM GR id >3. vtam ACT to the new TOR applid. >4. vtam INACT (force) to the old TOR applid. >5. Restart TOR. > >We have encountered the following situation: >D net to the old TOR appid shows the the cross domain is still there >and some terminals are in POLUIO status under it. Other terminal's seemed to >be working via the VTAM GR. > >We brouht down the TOR again and used INACT+FORCE+DELETE >and the cross domain appl was still there. > >Questions: >1. It seems that terminals tring to conect after the TOR was up > worked vis the VTAM GR and others were stucked under the > old cross domain definition... >2. On the D net command, fields: Active Sessions was 0000 and > SESSION REQUESTS was > 0000 can this be the reason? >3. Any Ideas? > >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
