Why we still have some coax users? 1. It is reliable. We had a lot of network type problems in the late 90s, but I do have to say that our network is reliable now. Except for some sites on our WAN, but then they don't have a coax option anymore.
2. 3270 tubes are reliable. When they break, they just get replaced. When broke, PCs are down for a much longer time. We try not to tell customers (tax payers), come back/call back tomorrow when my PC is working. 3. Believe it or not, we still have a set of real, true, IBM 3287 printers. They still run. They still work. And all of our CICS printing goes directly to printers, and not using EXEC CICS SPOOL... 4. There are only about 160 of the 3270s left. They served us well. We have many places that don't need anything else, then a mainframe session. Not that we don't use TN3270. We just bought, I believe I was told, 1,000 licenses for TN3270. I assume some of them are replacements for a TN3270 product that didn't seem to do so well with XP. I don't know who or what application is getting the rest of the licenses. BTW, what emulator is $300 per site? We tried several and the inexpensive ones, failed on some "required function". Anyway, some of our users, even the TN3270 ones, bounce between CICS systems. They need to be non-EDS for some regions and EDS for others. Connecting to different ports means support problems if they connect to an EDS "ports" and then connect to the older, non-EDS applications. I've also found that if you connect with a non-EDS terminal (or at least a non-EDS Logmode), some EDS type transactions abend. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 10/10/2006 3:14 PM >>> Why not? Once you have one range, you can set up another range and assign CUUs to different people. Have VM own the terminal so that they get the VM logo screen and have them then do the correct dial. That is how we handled the few remaining coax terminal. Of course, the next question is "why do users or programmers still have coax?". These same people should have PCs on their desk with TCP/IP and considering that there are TN3270 emulators for $300 per site, why not switch them over to non-coax. Tony Thigpen -----Original Message ----- From: Tom Duerbusch Sent: 10/10/2006 04:09 PM > 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 >> >> > >
