There use to be a zap that would make the DIAL use the real CUU. I am not sure it that is still available.
Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 > -----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: [email protected] > 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 > > > >
