> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of JPB-U2UG > Sent: Monday, July 21, 2008 8:34 PM > To: [email protected] > Subject: Re: [U2] converting from Universe on Red hat Linux to Universe > on Windows > > > A little bit of information on the Solaris/MUMPS to Universe/Linux system > connections. > The Solaris system runs an Open/M application that controls our dialer > system that is used in collection activities. The application is accessed > using a terminal emulator called CT-Vision which was furnished by the > company that built the MUMPS application. Because of the age of > the software > the only option we have is tenet. If there is a newer version it may have > ssh capability but that is not where the telnet problem is. The highest > Solaris rev I have been able to run the Dialer software on is > Solaris 7 but > what we are using is 2.6. We're talking 1993 technology here. Ssh doesn't > come with Solaris at that revision.
You don't need SSH on Solaris if you tunnel the telnet through a VPN. > The user logs into the MUMPS app, into a menu system that is strictly > monitored by the Supervisor through a screen that tells them what > the user > is doing every second they are on the system. The user can only reach > applications by menu that are defined by the Administrator. No personal > information of the customer is kept on the MUMPS system except their name > and phone number. > Here's where the telnet becomes a problem. When a user pulls up a pool of > phone numbers, for the dialer to call, the MUMPS application makes a > connection via telnet to the Universe/Linux server where they login using > their own user ID and password. The user, through a menu, can > then bring up > our inquiry program. The inquiry program contains the information on the > person being called. > The MUMPS app feeds the customer's number to the inquiry program, when a > connection is made by phone, so our customer service reps will > have all of > the information to talk to the customer intelligently. Really rather > sophisticated for it's time. Sounds like a neat implementation. How does the dialer work with the phone? Just curious about connectivity. We've been eyeballing some TAPI solutions for incoming calls and I'm hungry for implementation ideas from various markets. We're in distribution so it's a bit different. > The only other connection between the two systems is an NFS mount > exported > from the Linux server and mounted on the Solaris system for > transferring the > dialer pool file from the Universe system to the dialer system and the > collection statistics file from the dialer system to the Universe system. > At one time the MUMPS app was on the same system as Universe but > we changed > from Solaris to Linux for Universe and had to move the dialer software to > it's own system. Gee... no one has complained about an unecrypted NFS mount but telnet gets the gauntlet thrown? Interesting... > I don't know how this problem has anything to do with changing > from Universe > to SQL Server because the problem would still be there if we kept the > dialer. If the root problem is telnet security then the answer is a (free!!!) VPN. If the VPN suggestion raises an eyebrow, then I'd be wondering what the real agenda was. What company would thumb their nose at a free and widely supported solution to a potentially harmful issue unless the problem wasn't really the issue being discussed? > We can't change the Inquiry program to a GUI screen because of > this dialer > either so we will have to change it anyway. Beside that there are some in > the customer service department that think it would be better to > run without > a dialer system, which would eliminate this problem altogether. > Your last statement is more true than false. > > Jerry Banker > If I was concerned about losing a critical and well-suited piece of technology due to a small connectivity issue, then I'd be brainstorming ways to transform it into something that would fit better. Replacing technology only makes sense if the new version retains and expands the existing functionality. A simple solution that comes to mind is setting up a bridging service on the MUMPS or UV server and have it translate XML or HTTP requests into command sequences that operate the MUMPS software. That may sound exotic, but it's quite simple to implement if you have the right tools. Perl's Net::Telnet module and an XML module could help make quick work of XML translations. That could plug straight into UV or an external application. Someone that knows the MUMPS software inside and out would need to help script the key-stroke and data screen translations. You'd basically be doing screen scraping and key automation. GlenB ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
