Marathoners call the experience "hitting the wall" -- when they reach the 18th or 19th mile of the race and they are close to running out of the strength needed to finish. IS directors are familiar with this concept, especially if they are running another race: the ability to extract the last bit of performance out of their legacy xBase applications before migrating to client/server products. Our xBase marathon was conducted at at a New York City-based health agency last month. The agency, who doesn't want their name used because their application is sensitive, uses a Foxpro database that has over a hundred thousand records, with hundreds more added each day. They have a conservative IS director who tells me "I want to see client/server applications that have been in full production for many months -- until then, don't talk Oracle to me." Getting this Foxpro application to peak performance was tricky. They had several complicating factors: First, the agency's network had to be accessible from a variety of city offices and other networks. This meant a complex series of routers and interconnected servers so that clerks could connect to the agency's NetWare file servers from all over the city. The router at their downtown offices, for example, connects via a smattering of T-1 lines to offices in each of the city's five boroughs. Other connections include "CityNet," the backbone wide area network that is run by the city of New York's data processing department. And the agency is also connected to another network that is run by another city department. Just looking at a network map (that was simplified for my benefit) gave me a big headache. Second, to optimize network bandwidth, each data entry clerk could only access data via Symantec's PC/Anywhere remote access software. The network designers wanted to reduce traffic coming over the WAN run by the city by limiting data processing to their own local network segments. The agency has two NetWare 3.11 file servers, with one running a copy of Microsoft's Foxpro database software that contained the hundred-plus thousand record database. Given the many routers between a data entry person and the NetWare file server, without any remote access links the "the volume of data flooding the leased lines would make response time so slow and variable that clerks complained," said Sam Blumenstyk, an internal city consultant hired to advise the agency on their WAN design. Blumenstyk heads up InSource Consulting Services in the Department of Information Technology and Telecommunications. Third, the PC/Anywhere solution provided extra security since only PCs connected to authorized machines in the agency's offices could access the Foxpro database. The PC/Anywhere solution had grown like a multi-headed hydra since it was installed about two years ago at the agency. It now took over an entire wall at their offices, with a series of 43 machines connected to the network. Blumenstyk, along with the agency's own IS staff, were looking for a way to provide added functionality and to support more users without a tremendous hardware investment. They had several reasons: First, their users wanted to have concurrent mainframe and Foxpro sessions to cross-check information on the Foxpro database with the city's mainframe payment records. And second, network designers were compelled to begin offering support for Windows-based applications, and wanted to have something in place that would allow for centralized administration and management of these applications. "We have a small staff, and we had heard all the horror stories about supporting a variety of Windows configuration across the city," said the agency's network director. "Hopefully, by having a central server running a fixed Windows configuration we could minimize our support needs." Next, any new solution that would be implemented would have to work with Intel's LANDesk and other support tools used by the agency to help remote users when they ran into networking problems. Finally, they wanted to minimize multiple network logins without compromising network security. The product recommended to replace the PC/Anywhere "stack o' PCs" by the InSource group was Citrix Systems' WinView for Networks Applications Server. Winview runs on a specialized, streamlined, and stripped-down version of OS/2 and seems to offer everything that both users and network administrators were looking for: since the applications execute on the WinView server, they could set up a single configuration for Windows users. Indeed, remote users could run Windows quite comfortably on their existing 286-based DOS machines, since the necessary hardware, memory, and processing power for Windows is located at the server rather than at the remote clients. And the Citrix machine could eliminate their racks of PCs running PC/Anywhere and reduce maintenance hassles by having fewer remote access servers to care for. Next week we'll look at how the installation of WinView went at the agency. 33 The hardest thing about getting any remote access solution up and running is configuring the products to work with your network and handle the habits of your existing users. I found this out working with a health agency in New York City and Citrix Systems' WinView Applications server. Our installation of WinView took the better part of three days spread out over three separate weeks in July: partly this was because the various support staff weren't available for more than a day at a time, but partly this is because WinView is a complex product being installed one of the more complex network environments at the agency, who doesn't want their name used because of the sensitivity of the application. Our installation had problems from the start: when we loaded the first WinView disk, the machine would start up and then just appear to stop -- no error messages, no warnings, just a dead machine. After rebooting and getting the same situation, we placed our first call to Citrix support. We discovered that the problem was the Compaq server itself. We needed to download a new OS/2 disk driver for the Compaq's SCSI adapter (called CPQ53CX.ADD) and place this driver in the CONFIG.SYS file on the Citrix install disk. (Nowhere in Citrix' documentation is this mentioned, unfortunately.) A digression on Compaq: Finding the right driver on Compaq's bulletin board (or their Internet Web server) is the easy part -- all the various drivers are assembled together in a single file according to operating system. However, this means that you have to download more code than you need, and go through a rather tortured maze of unpacking, unZIPing, and other routines until you finally can copy the needed file from the set of software. Compaq should simplify this system. Back at the agency, we tried the installation again, and this time managed to create a working Citrix server by the end of the first day. Well, almost. We (and Citrix install program) forgot to add that pesky Compaq SCSI driver to the server's own CONFIG.SYS file after the installation was finished. We had to boot from the Citrix OS/2 diskettes and then get to a command line prompt to edit the file and add the driver. After getting some more help from tech support, we were up and running. Well, almost. We still had trouble connecting a test client machine to the server. After calling Citrix again, we discovered that because of the network topology, it was taking too long for the Citrix client to connect to the NetWare server, and the connection would time out. (A normal login under NetWare over the agency's local network would often take more than a minute to find a server and connect.) We changed the network connection for our Compaq so that it would be on the same Ethernet segment as the NetWare servers (rather than pass through many router hops), and we were up and running using the Citrix LANLINK client that connects a NetWare workstation to the Citrix server. Well, almost. Back the next week to begin our testing, we discovered a few other nits that took the better part of the day to resolve. One was the ability to run a 3270 session concurrently with a Citrix LANLINK session. The other was being able to see any of the remote users of our Citrix machine from an Intel LANDesk supervisor's console. The former we were able to resolve, but only after we had an on-site visit of one of Citrix' system engineers. He redesigned the startup configuration for our client logins. The engineer helped set up two full-screen DOS sessions that users could toggle between. The other issue we could only partially resolve, perhaps because Citrix users were loading LANDesk's DOS-based USER.COM TSR upon logging into our NetWare server, and then accessing Citrix' OS/2-based application. LANDesk was also never designed to handle multiple sessions sharing the same network adapter card, the configuration used by the Citrix server. After spending some time on the phone with both Citrix and Intel support, we were able to see the Citrix user from the LANDesk console, but view only one of their DOS sessions. The biggest issue for both problems was figuring out the flow of work and how users (who already had a LAN connection, although not necessarily to the same server) would work with the combination of Citrix, 3270, and Windows software. While the remote access process is similar between WinView and PC/Anywhere, the way it gets implemented is very different. Part of the problem is also an opportunity for Citrix: its server gives you all sorts of controls that aren't available in PC/Anywhere, but the downside is that you'll have to spend more time studying what each of these parameters can do and why they are important. For example, Citrix clients have all sorts of choices when they login: they can get a private NETX session and establish a separate connection to NetWare for each session, or use their existing mappings and share a single NetWare connection among all Citrix users (the latter choice, called global by Citrix, was what we used). Clients can immediately bring up Windows, run a DOS executable, or be presented with a task selector (just like the OS/2 1.1 user interface). We fumbled around by ourselves trying to figure things out, but when our Citrix engineer was with us he managed to resolve these issues quickly. We ended up using the task selector to kick off two DOS sessions when remote users connected in to the Citrix server: one for their Foxpro database, the other for their 3270 mainframe session. It was all rather slick, once we got everything going. Next week, I'll describe some of the results at the agency. Data: Citrix Systems WinView for Networks version 2.3 210 University Drive, #700 Coral Springs, Fla. 33071 800 437 7503 305 755 0559 305 341 6880 fax Internet: sales@citrix.com 10-user package: $2995 extra five users: $695 server tested: Compaq Prosignia VS 486/66 with 48 megabytes of RAM, 1 gigabyte hard disk, internal Compaq Ethernet adapter Digiboard multi-port serial board, Multitech V.34 modems 34 This is my last column on my saga of using Citrix' WinView Application server at a health agency in New York City, and also my last regularly-scheduled "On Site" column here at Infoworld. No, I won't disappear from the publication entirely -- I'll still be here, just not on a weekly basis. This change is largely of my own doing: after writing one of the longest running series of columns for one trade magazine or another for over eight years, I am ready to move on to other opportunities. The "On Site" series grew out of my own contacts in the Infoworld readership and greater IS community. Over the past year that I've been writing these series I've been quite literally all over North America: from Vancouver to Orlando, from Los Angeles to Boston. I estimate that over 150 people helped contribute to the series, both on the end-user side as well as with very dedicated people from all the vendors covered. While I can't name all of you here, you do have my heartfelt thanks. Without all of your very considerable efforts, this column wouldn't have been possible. Much of the credit for the high quality in this column must go to one of the finest editors that I've had the privilege to work with, Rachel Parker. Rachel has a rare talent to be both a great editor who has a solid grasp of the technology that we write about: she could instantly spot weak arguments, eliminate ambiguous references, and improve much of what you read here. It was a pleasure working with her, and I look forward to continuing our partnership in subsequent feature stories in her Enterprise section. (It is at this point that Rachel would remind me that I do have to get back to the topic at hand, so let me sum up some of the lessons I learned with our Citrix installation at the city agency:) First, the good news: the program personnel are hugely happy with the product, and have begun to use it in place of their older PC/Anywhere remote access solution. "Screen updates over the network using LANLINK are much faster than with PC/Anywhere," said the network administrator for the agency, who doesn't want their name used for security reasons. "With PC/Anywhere, we had problems with jerky mouse movements that we don't have with Citrix." And the program data entry clerks appreciate having the ability to move quickly between their 3270 mainframe sessions and entering data in their Foxpro database, something that they didn't have with PC/Anywhere. All our adventures chronicled in last week's column about installation and configuration are not forgotten, however. One of my issues with Citrix is that you really need someone on-site who is an expert to help you set up the product. Normally, Citrix just sells to resellers and as such makes sure that the reseller is properly trained and has the necessary tools to help you get the product going. However, I am not sure about this approach: like Novell's resellers, I know there are some good ones and bad ones. The issue I have with using a reseller-based support system is that you need to choose a reseller that really understands your network infrastructure and can help fit in the right Citrix configuration. If the same person that helped build out your network also sells Citrix products, you are in good shape. If you didn't use a reseller to design your network (as in the case here) or have different resellers for the overall network design and Citrix support, then you are going to be in the same boat that we were in. Besides the reseller issue, I also feel that Citrix could do a better job with its configuration process. Some parameters are set in a series of user profiles, some are set in a series of batch files located in particular subdirectories on the server, and some are set in special configuration files. For example, NWLOGIN.CFG sets a very important parameter that can affect your overall network security, and this information is contained in a README file and not in any of the normal WinView documentation. The company needs to do a better job putting this together in one coherent package, to make it easier to administer and configure its plethora of services. Where does all this leave me regarding Citrix? Well, I am mostly in favor of this product, although the company can do much more to simplify its installation and reduce their overall support burden. Our installation experience wasn't without its issues, although most remote access servers that I've installed have had their share of problems as well. WinView does deliver what it promises: a high-performance applications server that is fairly easy to administer and works well with NetWare and Windows. That in itself is a tall order, given the level of complexity involved. And, the folks from the agency are happy with the product, and are planning how they will migrate many of their PC/Anywhere users over to WinView. The City of New York is also looking at using WinView in other agencies, largely as a result of this successul experience here. Well, it is nice to end on a such a happy note, particularly as many of you know that I've haven't had the best of times in every On Site visit. Regardless of how each visit ended, it was always an honor to come to your shops and see you and learn how you implemented new technologies, and I hope to continue to stay in touch with all of you as you evaluate, test, and discover new worlds of networking.
Click here to return to the previous
page
David Strom
Port Washington, NY 11050 USA
US TEL: 1 (516) 944-3407