I will assume that since you specified the VM/TCPIP stack does the DIAL command to VM/VTAM you are using the SCEXIT provided by IBM. If so what I would do is put all the terminals that need a specified LU in the CICS partition in a different subnet. Then in the provided SCEXIT in or around line 155-158 there is a "TEST" that determines the IP addr of the client. You can change the REXX coding to DIAL a CICSVSE ADDR instead of DIAL VTAM (for VM) in the CICS Virt Mach, you can then have a pool of TCT Addresses that can conform to your needs. Yo can also DIAL a VM/VTAM address with a certain address but this is going to to a little more REXX coding.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTI) Sent: Tuesday, October 10, 2006 12:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM Cross Domain problem/question It has been awhile but this sounds like you need a VTAM Session Establishment exit where you dynamically change the attributes of the terminal before making the connection since at this time you should have the terminal LUNAME and the CICS APPLID. It could be the DLOGMOD, FEATUR2 or both. Then the next question would be how to rest the terminal id back to its original settings after the CICS connection is dropped. This would allow logging onto various CICS regions from the same logical terminal. It would be easier if you could inflict upon the users what virtual terminals are connected to what CICS at the DIAL command, but you would have to read the user's mind at that time. This would not prevent logging onto various CICS regions from the same logical terminal. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Tuesday, October 10, 2006 12:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VTAM Cross Domain problem/question I'm in need of a solution to a weird problem.... We have VM/VTAM control all of our real terminal controllers and the VM TCPIP stack does a "DIAL VTAM" so all terminals get the same look and feel. They come into a USSTAB (either the SNA or non-SNA version) and are able to select the CICS system they want. The 12 VSE VTAMs only define the cross domain services and the CICS applids. The 29 CICS systems, all use autoinstall. That part is all simple..... Our production CICS systems for inhouse developed applications.... well some of the applications were written in the mid '70s. I came into the CICS world with CICS 1.4, and these applications may have been written for a prior CICS release. Anyway, they don't have "attributes" specified in the BMS maps. The application programmers coded them in the application program. i.e. they moved "what they thought" was proper attribute bytes to their maps. This worked fine. That is for non-extended data stream devices. And all of our VM/VTAM definations define all devices as non-EDS. Well, now I need EDS capable devices but only on certain CICS regions. When I changed the VTAM devices to support EDS, we got all sorts of weird colors, blinking and reverse video on our old applications. Apparently, when the Cobol programmers created their attribute bytes (and it wasn't copy books, it is inline code that was redeveloped with each new program...or so it seems), they only cared about the bits they needed (highlight/normal) and the rest of the bits, didn't bother anything....until now. What I want to be able to do is, on a CICS by CICS basis, setup whether that system can handle EDS. My understanding of the negoiation of the bind, is when there are conflicts, they step down to the lowest common attributes. I would rather not make changes to our current production systems, but rather to the systems that need EDS. But I think those two conditions are in direct conflict with each other. What are some good ways of making this type of change? Thanks Tom Duerbusch THD Consulting -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------
