Ed Anderson is the IT Platform Manager with Viking Electric Supply, headquartered in Minneapolis, Minnesota, with 21 branches throughout Minnesota and Wisconsin. Mr. Anderson has been with Viking for six years and is responsible for the operational integrity and infrastructure for production and development mainframes, as well as a number of critical Windows-based servers.

Viking Electric Supply was founded in Saint Paul, Minnesota, in July, 1964, by James C. Schacker to distribute electric supplies to electrical contractors. In 1969, expansion moved eastward with the acquisition of our Eau Claire (Wisconsin) location. Associate headcount grew from three to nine.

Viking’s first computer was purchased in 1975. By the end of the ‘70s, Viking comprised five locations, staffed by around 100 associates. The ‘80s saw an additional 5 locations created or acquired, and the formation of the Industrial Division. In the ‘90s, associate headcount grew to over 400, the Training and Automation departments were created, and 8 more warehouses opened.

2000 was a year of great change. Another store, a relocation, and the creation of the DataCom division started things off. Then in June, Mr. Schacker sold Viking Electric to Sonepar Distribution of France. Sonepar Distribution, the world’s largest privately held electrical distributor has almost 1,000 branches in 26 countries. Viking Electric continues to operate under the same name and management team. Greg Hames, then a 26-year associate of Viking Electric, was named President of the company.

At present, Viking Electric Supply includes 21 locations throughout Minnesota and Wisconsin, almost 500 associates, and annual sales over $200,000,000.

Viking uses a Unisys CS-7101 for primary production, including order processing, warehouse management, logistics, forecasting, and purchasing. We run Lawson Software’s financials suite on the Open Systems side of the box, and communicate between the MCP and Open systems via MQ server. Last year, we purchased a small LX-7100 mainframe for use in development and test, enabling us to free up more capacity on the production mainframe. Recently, we [took] delivery of a Libra 595 mainframe to replace the CS-7101.

They call me an IT Platform Manager. That essentially meant that I was primarily responsible for keeping the mainframe and Lawson software running. My job has evolved since then, and I have an open invitation to suggest a more meaningful title, but I haven’t had a chance to think of anything better yet. I have primary responsibility for specifying the production hardware and the infrastructure necessary to attach it to our network.

We were dissatisfied with our previous emulation services vendor. They were responsive enough to our requests for service or information, but their yearly maintenance was quite expensive. Also, because all communications with the mainframe had to go through their proprietary server, that little server represented a single point of failure that we were increasingly unable to abide. The last straw, however, was that if we wanted to upgrade to a Unisys Libra mainframe, we would have to purchase additional equipment at a significant price, just to be able to keep using our old vendor’s emulator.

I first learned about KMSYS Worldwide at the 2004 Unite show in Philadelphia. One of my goals at the show was to identify alternative emulator vendors, and determine whether our vendor’s perceived shortcomings were simply a fact of life, or if they really were problems that other vendors had been able to solve.

I spoke briefly with a KMSYS representative at the display booth, and told him about my experiences. He demonstrated the eXpress Plus product, as well as eXpress Chart and some dialog forms that really spiced up the interface. I was favorably impressed, but not ready to make a move yet. When we were ready to start thinking seriously about moving, I contacted KMSYS, as well as a couple other competitors. One competitor’s product was simply too underdeveloped to be able to address our needs. Another was overdeveloped, and their reps, too interested in telling me all the other things I could do with their product, to take the time to tell me how to do what I actually wanted to do. Their price reflected their vast capabilities list too.

KMSYS confidently assured me that eXpress Plus would do exactly what I needed, and at a price that was right.

Yes. We’ve had extensive tech support interaction.
Rather than simply telling us that this is how the product works, take it or leave it, the KMSYS technical support team took the time to understand our needs and desires, and how the emulator might be deployed to meet them. The end result is that we [Viking and KMSYS] either find a better way to do what we wanted, or a feature [enhancement] gets added to the emulator that not only makes it a better product in general, but makes my job much easier.

Most of our issues are resolved the same day, or the next. On occasion, it takes longer to address an issue, but we are kept abreast of any status changes, and that’s fine

First, T27 eXpress Plus can do the job. We looked at a couple emulators that simply did not have the capability to meet our needs, which was too bad, because they were certainly priced right — one of them was free. (I guess you get what you pay for.) Second, T27 eXpress Plus does the job without breaking the bank. The initial licensing fee* and annual maintenance [fee] are very reasonable.

Absolutely.

Pricing was a significant factor. Our initial license fee was comparable to what we were spending before for annual maintenance. The maintenance fee is a fraction of that, and we are looking forward to significant savings with greater functionality and responsiveness

I downloaded the trial version and installed that on my workstation, and used it for several days. I had an issue or two, and asked for some assistance, and [KMSYS developers] responded by modifying the emulator and providing a new improved product to me. Once I was convinced that eXpress Plus was a contender, we purchased a small block of licenses, so that we could install it throughout the IT department, and on a few key users’ workstations. Over the next several weeks, additional issues came to light, and we brought those to [the KMSYS support team], who, again, either helped us find a better way to work, or modified the program to add the functionality we wanted.

Finally, having decided that this was the emulator for us, we announced our intentions at a managers’ meeting. Then we requested key users in each of Viking’s functional areas to provide us with a list of key macros they felt they needed to do their job. We developed a template of key macros for each department. Over the course of a couple weeks, we converted all the departments one-by-one from the old emulator to the new.

We actually anticipated more resistance to change than we saw. Prior to the cutover, we made sure that people knew what was coming, and what to expect. We were respectful of their time and workload, and offered to reschedule if necessary. We also left the old emulator installed on their workstations temporarily, to give them the peace of mind of knowing that, even if eXpress Plus crashed and burned on them, they would still be able to do their jobs. Post-cutover, we received a few questions at the help desk, but not nearly as many as we thought there would be, and none of them were of the type, “Can you get this thing off my desktop and give me back my old one?” We saw immediate, widespread acceptance of the new emulator, and no real difficulty adjusting, since we had done so much work up front to make sure that everything the associates needed to do their jobs would be there for them.

Since we were cutting over at about the time our old vendor’s maintenance contract was due, and because we were still dependent on some of the APIs that came with the other vendor’s product, we opted to renew the maintenance on that system for one more year, as insurance. So no, so far there has been no cost savings. But by the end of this year, we expect to see a net savings of $35,000, and upwards of $40,000 per year each year thereafter.

We are just getting ready to implement a replacement GUI dialog for credit applications to replace a VB dialog that took advantage of the competitor’s APIs. The new dialog, written entirely with [the] KMSYS scripting language, is much simpler visually than the old one†, and uses some data-driven programming that enhances productivity by allowing the AR specialist to enter an applicant’s zip code and choose the city from a drop down that is populated on the fly based on the zip code. In the old dialog, the city name had to be typed in, [and] then validated, with no consistency check between city name and zip code.

I should probably point out that the old Credit App dialog (pictured below) was deficient in that it was not capable of managing multiple transmits per transaction. The data gathered in the GUI needed to feed two or three different mainframe screens, so the credit people would have to fill in the GUI, wait for one mainframe screen to get filled in, transmit, and return, and then they’d have to manually update the other screens.

The new GUI (shown below), which I developed via the Dialog Form Designer packaged with eXpress Plus, fills in the Customer Maintenance screen, transmits, waits for the on-screen confirmation, then automatically updates the other screens necessary, with no manual intervention.

In the old dialog, the user had to type in the city, state, and zip code for any addresses they were entering. In the new one, they type just the zip code, and it automatically assigns the state, and populates a drop-down for the city name, automatically selecting the most likely candidate. For example, 55122 could be either Saint Paul or Eagan. So if the credit analyst enters 55122, the logic puts MN in the state field, and populates the city drop-down with Saint Paul and Eagan, and selects Saint Paul. If the applicant is really in Eagan, the analyst can select that instead. That saves not only typing, but validation and error correction time as well.

We had scant documentation on how to use the competitor’s APIs, and the programmer who knew how to do so is no longer with the company, so we were hard pressed to support the old dialogs. Now that we have both support and documentation, we are able to rewrite those dialogs to support our current business practices, instead of having to make do with what we have, because we can’t reasonably change it.

I just want to say that throughout our rather long “courtship,” [everyone I dealt with at KMSYS] maintained a friendly and professional demeanor. We couldn’t ask for a more responsive, helpful relationship with a vendor.