The upgrade presented Cumbee with some major interoperability hurdles that involved many vendors and many products. The end results were problems with printing, 3270 emulation, and client-side applications that all had to be sorted out.

Fortunately, Cumbee was not facing this dilemma alone. LANMark Computer Concepts Inc., a service-oriented, Novell-authorized VAR and systems integrator in Tampa, Fla., had been brought in to help Cumbee make the move from NetWare 4.1 to IntranetWare 4.11. Consequently, Mark Evans, LANMark's senior consultant, had been involved with the bank's multi-vendor challenge from the start and was completely committed to making the system work.

Complete commitment was exactly what the bank would need. A small community bank with 19 employees in two offices and $40 million in assets, 1st National does not enjoy the same clout as a national financial institution such as Nation's Bank Corp. or BankAmerica Corp. As a result, trying to get vendors to collaborate and solve a mutual customer's problems was futile. As Cumbee and Evans quickly realized, 1st National and LANMark would have to fix the bank's problems on their own.

Banking on the Network

Moving to IntranetWare was not Cumbee's idea. Nor was it Evans'. The bank was successfully running NetWare 4.1 at its main office in Dade City. However, by the time the bank decided to network its branch office in Zephyrhills, Novell had introduced IntranetWare, and NetWare 4.1 licenses were no longer available. At that point, Cumbee and Evans decided to they had to upgrade the Dade City network as well.

"Novell wouldn't sell us more licenses for 4.1," says Cumbee. "We had no choice: The IntranetWare upgrade was mandatory, and that caused us some consternation. Frankly, a lot of the issues were brought on by the move to 4.11."

In addition to the network OS migration, 1st National decided to migrate from Microsoft Windows 3.11 desktops to Windows 95. Again, this move was driven primarily by a software vendor, specifically Banker's Systems Inc., which is working on a 32-bit Windows version of its banking application suite. The bank opted for Windows 95 desktops to take advantage of the forthcoming Banker's Systems upgrade, but until that upgrade ships, 1st National is stuck with the older, DOS versions of those programs.

Tackling Vendor Incompatibilities

The task at hand, then, was to blend IntranetWare and Windows 95 with the applications that had been successfully running on the NetWare 4.1 network in Dade City. That network included Novell's SAA gateway software and NetSoft Inc. DynaComm/Elite terminal-emulation software, which the bank used to connect to a mainframe in Milwaukee. That mainframe belonged to M&I Data Services Inc., the bank service bureau that 1st National commissioned to do its data processing.

In addition to the DOS-based banking applications and the mainframe communications, the new IntranetWare/Windows 95 environment had to accommodate Windows-based personal-productivity software from Microsoft Corp. and Lotus Development Corp.

While the odd combination of Windows and DOS programs generated few problems when running under Windows 3.11 and NetWare 4.1, the IntranetWare and Windows 95 combination posed difficulties.

"The problems started with the NetSoft 3270 emulation software, which does not work with the Microsoft Windows 95 client for Novell," says Evans. "And the Banker's Systems loan- and account-processing software would not work with Novell's Windows 95 client."

VLM to the Rescue

Since the NetSoft and Banker's Systems software are essential to the 1st National network to carry out loan and account processing, the incompatibilities with both Novell's and Microsoft's Windows 95 client left the bank without a 32-bit network client. Novell had not yet released its own IntranetWare Windows 95 client, so Cumbee and Evans reluctantly implemented 16-bit Novell VLMs.

"When I'd tell people that we were using VLMs, they'd look at me like I'd lost my mind," says Evans, who admits that the VLMs were not an ideal solution. "You sacrifice 32-bit capabilities for network communications, and the VLMs load under DOS, so they take up conventional memory.

"They also have a tendency to cause general-protection faults," Evans says. "So, we were trying to make all these things mix together."

Dictating the Mix

Melding together the bank's disparate application mix was the only real option for 1st National and LANMark. Like most vertical markets, the banking industry gives individual banks very little leeway in selecting which applications they can use to perform their financial work. Instead, the industry's service bureaus and government agencies end up dictating most of the application choices. As a result, 1st National is stuck with an unwieldy application mix that ranges from simple DOS programs to huge 32-bit office suites. "We're at the mercy of the programs people give us," says Cumbee.

While 1st National has little control over what applications it will run, it has tremendous control over how it will run them. Here, Cumbee's criteria is straightforward: Every computer must be able to run every application in the bank. Period.

"Some banks still dedicate specific PCs to specific jobs or even have standalone PCs," says Cumbee. "We want to have all of these programs on all the computers, so that no matter where the customer sits down, we can do a loan, look up an account, open an account, whatever."

Cumbee did not want the bank's network users to have to exit Windows and go to DOS to run a particular program. What he needed was to have full functionality of Windows 95, along with full network and emulation functionality and full print- and file-server functionality. Otherwise, he says, "you're taking two steps forward and one step back. If you're going to do it, it ought to work."

Vendor Beneficence

By June, 1st National's VLM implementation was working, but to nobody's satisfaction. The sticking point remained conventional memory. By loading as many device drivers into high memory as possible, Evans managed to free up enough memory to load the core loan- and application- processing applications. To run more DOS-based programs, such as the flood-zone certification program, the bank clerk would have to close one of the core applications. The general-protection faults also persisted.

If optimism drove Evans to continue tweaking his VLM solution, it also drove him to follow up with the individual software vendors in search of their assistance. Assistance finally came in the middle of June, when Novell released the beta version of its own Windows 95 client for IntranetWare. When coupled with some patches from Banker's Systems, it filled the dangerous holes that the VLM solution could not.

"We were caught in the classic multi-vendor problem," recalled Evans. "Nobody's really talking to anybody else, so the VAR ends up being the go-between."

Evans shrugs off any suggestion that his bird-dogging drove Novell to deliver its client-side beta software ahead of schedule. However, his determination may have had an impact at Banker's Systems, where both Evans and Cumbee spoke with that vendor's president about the patches necessary to make the loan- and account-processing applications work with Novell's beta code.

Regardless of his influence, Evans' dedication to making things work has reassured Cumbee that the bank is working with the right integrator. Cumbee has a number of automation projects on his plate, including a new, PC-based teller system, a wide-area link to connect the bank's two branches, a document-imaging system, as well as online banking applications. With every project promising its own pitfalls and problems, Cumbee needs a technology partner that is committed to finishing the job and doing it right.

"Mark [Evans] and his crew made it a point of honor to make this work," says Cumbee. "We're thankful that they were willing to do that for us."

Brent Dorshkind is a freelance writer and consultant in Santa Barbara, Calif. Contact him at tanright@ix.netcom.com.

Back to top