David Strom

Final "On Site" Series: Citrix/NYC Health

By David Strom

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


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


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.


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


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.


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


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 David Strom Port Washington, NY 11050 USA US TEL: 1 (516) 944-3407