This is a perfect example of using CP Exit 1200. This cp exit allows you complete control over the DIAL command.
I suggest you give it a shot. We use it here quite a bit. I can supply our exit if you wish to look at it. Someone on this list pointed me at this thing a few years ago and I forget who it is was. Good Luck. _______________________ Jim Hughes 603-271-5586 "Action is the solitary ingredient that separates planning from delusion." =>-----Original Message----- =>From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =>Behalf Of Tom Duerbusch =>Sent: Tuesday, October 10, 2006 4:09 PM =>To: IBMVM@LISTSERV.UARK.EDU =>Subject: Re: VTAM Cross Domain problem/question => =>Can you now specify a range on the "DIAL" command? I've thought it was =>first available. =>Anyway, that doesn't help the coax attached devices. But interesting =>idea. => =>Tom Duerbusch =>THD Consulting => =>>>> [EMAIL PROTECTED] 10/10/2006 2:56 PM >>> =>At Volusia Schools, we: =>a) set up a higher range of virtual CUUs for VTAM with different =>attributes. (In our case, different sizes.) =>b) set VM/TCP to accept multiple ports for telnet. =>c) changed the rexx proc that performs the DIAL VTAM to dial different => =>port ranges based on the IP port being connected to. =>It was a simple change. => =>Tony Thigpen => => =>-----Original Message ----- => From: Tom Duerbusch => Sent: 10/10/2006 12:10 PM =>> 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 =>> =>>
