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
