Converting from SCO Xenix to Linux
There are many customized versions of SBT's accounting system programs because SBT (http://www.sbt.com/) has been supplying source code with the multi-user versions of their software for many years. The system I upgraded from SCO Xenix to Caldera OpenLinux used SBT's Accounts Receivable/Inventory program as the basis for a point-of-sale system. Both the original SBT programs and the add-ons were written in SCO Foxbase plus, one of the dBase-compatible languages. My client, Steve Maxwell, had been using the program for about ten years to run his department stores, and was pleased with its performance and stability. Unfortunately, when I tested how well this software worked with dates in the year 2000, it failed. SCO Foxbase did not work correctly after 1999.
While I was looking into the available solutions to the problem, I found, in addition to an upgrade from SCO, a couple of dBase-compatible languages also available for Linux. I liked a product called FlagShip from Multisoft (sold in the U.S. by Linux Mall, http://www.linuxmall.com/), because my initial tests indicated it would compile the original SBT source code with only a few changes, which I'll detail later, and it produced very fast code. It was also the least expensive solution, at less than $600. FlagShip compiles the source code in a two-step process that converts the original dBase source into C code, which is then compiled by Linux's C compiler into a native executable.
From the client's point of view, one of the major advantages of the upgrade to Linux was it allowed him to use much of his existing hardware, including the many terminals, receipt printers, bar code scanners and so on, as well as his main computers. The only hardware we had to replace was a 60MB tape drive and a multiport serial card. Both were no longer manufactured and were not supported by Linux. We upgraded the multiport serial board to a Cyclades Cyclom Y board, and upgraded the tape drive to a Hewlett Packard IDE 5GB unit with BRU backup software. The ability to recycle major components saved tens of thousands of dollars. By using the original programs, we also avoided training costs.
Since this was my first Xenix-to-Linux conversion, I was fairly concerned I would run into an unforeseen problem that would make the project fail. In this regard, I was fortunate to have a very experienced client. Steve Maxwell had been involved in the development of the original Xenix version of the programs, and had been maintaining the system without outside support. I felt much better having a truly smart client around, because I ran into trouble right away: I couldn't get the information on the Xenix system over to the Linux system. Although Linux can read Xenix file systems, I was not able to get Linux to read the Xenix hard drive that held the original source code and data. I was able to get the information off of the Xenix system using a program Steve called Term, which has both Xenix and DOS versions. I wound up with all needed files on the DOS partition of my Linux development system. This turned out to be quite useful in that it allowed me to use all the DOS development tools, in addition to the Linux tools, and produced code I could debug in either environment.
I started the conversion by doing the Y2K work. I converted anything that had to do with dates from the original format of 8 bytes of character data (e.g., 01/01/90) to dBase's date type. This is the approach used by SBT for its DOS and Windows products. I used the SET CENTURY ON command to enable four-digit years, then made the necessary changes to convert the date where needed. This turned out to be relatively easy.
In the next step of the conversion, I built a stripped-down copy of the department store's system, consisting of a main computer and a single point-of-sale workstation (a dumb terminal, bar code scanner and receipt printer). I also set up some system printers in the configuration used by the store.
None of the available Linux terminal types worked, and when I logged out from the terminal, I didn't get a login prompt again. This was something I hadn't expected and was a pain to resolve. I eventually produced a custom terminfo entry by reverse engineering the Xenix termcap settings. The login problem was solved by using mingetty instead of the standard getty program. After resolving these problems I had a working single-terminal version of the system.
The way SCO Foxplus handles a multi-user file is different than the way FlagShip handles it. Basically, I stripped out the Foxplus code and added the FlagShip code as needed, an easy process, but a bit tedious since I had to add a block of FlagShip code at each point in the program the USE command appeared. In about a month, I had finished all conversions and installed the Linux hard drive (which I'd done the development on) as the main store computer. I kept the Xenix hard drive handy, in case there was some more trouble in the upgrade. Amazingly enough, the Linux version worked on the first try. After that, I made minor changes to the code to optimize the way the printers worked, but the Linux system was up and running and I never needed to go back to Xenix.
The original point-of-sale programs supported multiple stores by updating a set of master files through a complicated operation involving transaction files created at each store and a batch update process. I was able to simplify this by using Linux's powerful communication features to connect the branch store directly to the main store via the Internet.
I obtained two dedicated IP addresses from Gilanet, the local ISP that serves the two towns where the stores are located, and configured the automatic dialer program to bring up the links during store hours and shut them down when not needed. Bill Stites, the system administrator from Gilanet, provided great support in getting the Internet connections working. Bill uses Caldera OpenLinux internally for some of his Gilanet servers.
When we started this project, Steve Maxwell and I had wanted to complete the upgrade prior to the busy Christmas season. As it turned out, even with the problems, I was able to complete the work in about half the expected time. The system runs beautifully.
Fred Treasure can be reached via e-mail at firstname.lastname@example.org.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
3 hours 54 min ago
- seo services in india
8 hours 25 min ago
- For KDE install kio-mtp
8 hours 26 min ago
- Evernote is much more...
10 hours 26 min ago
- Reply to comment | Linux Journal
19 hours 12 min ago
- Dynamic DNS
19 hours 46 min ago
- Reply to comment | Linux Journal
20 hours 44 min ago
- Reply to comment | Linux Journal
21 hours 34 min ago
- Not free anymore
1 day 1 hour ago
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?