larry@xxxxxxxxxxxxxxxxx wrote:
> Over the past few years I have been taking notice of the applications
> used at various business and many of them are pretty ancient.
>
> --I've read some fast food places have some sort of BASIC (QBASIC,
> Visual BASIC) thing that powers all ther resgisters and tracking
> systems. (check out the order queue screens at many fast food places
> and you usually see a text screen.)
Actually, most of those are SCO Unix systems. The cash registers
connected to them are running Linux. Most of the core of the
application used was written in C, almost 20 years ago. It works
really well, and provides a good way to manage the flow processing of
orders in real-time, making it possible to make sure that each customer
is served by the production line with the shortest possible average
wait time, and gets the freshest possible food.
SCO started this business almost back in the days when Microsoft first
sold them Xenix, and quickly established a good market at McDonalds,
Burger King, KFC, Pizza Hut, and eventually all of the Pepsico
affiliates.
Caldera began offering Linux based solutions to supplement the SCO
environment, and soon found that it needed the SCO support
organization. Unfortunately, to pull off the merger of SCO and
Caldera, Caldera had to issue a lot of extra shares, and some Microsoft
owning holding companies snapped up the extra stock - giving Microsoft
executives proxy control of the new merged company. They fired Ransom
Love, hired Daryl McBride, who purchased the SCO Software division,
filed a groundless lawsuit (Which testimony now shows that he KNEW it
was groundless) against IBM, sold unrestricted use of UNIX to Microsoft
for $7 million, who provided additional funding in the form of
debentures purchased by Bay Star capital, which is funded from
investments made by "undisclosed investors".
> - At one doctor office had an app that looks like it was developed
> wioth a Win a 3.1 circa tool and is currently running on windows 95
There were several medical records applications which were written
using DBase, and which are still widely used today. Many doctors and
their medical records clerks have looked for alternatives, and there
are Linux options now being offered, but the front-end interface is
still "compatible" - meaning the desktop still runs the Windows and
Windows client. Ironically, medical records software of this kind only
provides a very brief summary of visits, billing, and minimal
information provided when payments were requested.
New government regulations such as HIPA, and other issues related to
insurance company claims processing has resulted in upgrades to the
larger offices, most of which now use Linux or Unix based servers.
> - A lumberyard I noted thier system was piing through a text console on
> a window in a 95/98 type desktop. (probably a DOS app, though I know
> there are some legacy COBOL ones still floating around.)
Brobably a UNIX Curses app. Most warehousing software is designed to
interface to a common server in the "back room", but since keyboards
and monitors can be easily damaged, the "terminal" only needs to be
something that is "curses" compatible. Often, a surplus PC picked up
from the county PC recycling center is sufficient for these needs.
> Many of these people are prefectly happy with the programs, though as
> Windows evolves these will be unusable on newer hardware.
Ironically, that's the beauty of using a curses based application.
Even if Microsoft were to drop support for ANSII terminal emulation,
cheap Linux PCs could step in to fill the void in a heartbeat.. Some
of these applications date all the way back to Alpha Micro UNIX systems
that were developed in the 1970s. I worked at LaBelle's back in
1977-78, and they had a workflow management system that allowed the
cashier to enter an order into a curses application (didn't look like a
3270 terminal, but more like a black-on-white display), and the ticket
would be displayed on the warehouse terminal. When the items were
pulled, the warehouse used a curser to check of each item. When the
whole order was ready, all items were put on the conveyor belt, and
moved to the pick-up point. The pick up point had the original order,
the price of the merchandise, and confirmation of the customer's
payment, and the customer was paged to the pick-up area when their
order was ready.
It was my first experience with Unix, and I as very impressed. I sold
a lot of merchandise and almost never did I have to tell a custotmer
"sorry we don't have any of those" after taking his credit card
payment. This was because the database was tracking the inventory as
it was being ordered. If we were out of stock, I almost always knew
before I processed the customer's card. At that point, the customer
could choose another alternative, or opt to wait until we had the
product in stock.
As a good salesman, when a customer wanted to wait, I would get their
number and check the inventory every day. When the desired product
arrived, I could call the customer, let him know his product was in,
and if he still wanted to make his purchase, I could have the entire
order ready to be picked up when he arrived.
I can tell you for certain that this system was not powered by MS-DOS.
In 1977, Microsoft had just come out with BASIC for the 4kbyte TRS-80
Model 1 computer. They weren't even close to being in the inventory
management business. A few years later, Microsoft did aquire/develop
Xenix (did IBM think that Bill was talking about Xenix when he said he
had an operating system?), but when they decided that MS-DOS was the
key to their success, they turned Xenix over to SCO, who eventually
entered the 80386 market and sold directly to Dell, only to have
Microsoft shut down that OEM channel.
> As microsoft
> pushe updates there will be many forced into upgrading, and some of
> those vendors are long gone since when they developed these apps in the
> 90s.
Or the 70s.
The irony is that most of these POS terminals can very easily be
switched to Linux.
Many of them already have been switched to Linux. Some of these
applications are no longer available in source code form, but need ANSI
or VT100 compatible terminal emulation, but they are still functional.
In most cases, these are not "hot new markets" for Microsoft. In fact,
most of the terminals are expected to last as long as 10 years. Often,
factors such as cooling, power, and risk of damage have resulted in the
use of older or slower machines which do not need cooling fans (which
don't work well in environments where sawdust and other dust and debris
are the norm.
Even the cash registers are simple PCs with a "dumb terminal"
interface, or a "web browser" interface. In some cases, the web
browser interface just translates the CGI request into a series of
curses commands. IBM's HATS application uses Webpshere to convert web
browser screens into 3270 or 5250 data streams, and then scrapes the
responses into fields that can be formatted as HTML screens.
Ironically, Caldera introduced Linux to the Fast Food and Lumber Yard
environments primarily as a way of providing advertizing and tie-in
sales reccomendations. If you had ordered a Value Meal, the menu would
pop up pictures of desserts, and this would lead to more sales of pies
and ice-cream.
> Of course I think that is why virtualization is becomming a big issue at
> MS, but with it comes added complexity and also additional glitches
> from being another layer away from the hardware (not to mention
> outdated drives or devices that connot interface to modern systems).
Microsoft knows that Linux is fully capable of providing these "point
of sale" functions, and furthermore, many new inventory control and
workflow packages are now being developed on Linux servers, for Linux
workstations and POS terminals, often using interfaces written in
PERL/TK, Python, TCL/TK, or Ruby.
Linux, by itself, can't offer backward compatibility with Windows
applications. On the other hand, Linux, with virtualization can
provide Windows functionality using Windows as the client, using
Windows libraries provided with the OEM license, or using Windows as
the host and having Linux as the client.
Ironically, Microsoft's interest in Virtualization came when a number
of vendors began offering products which offered full support for
Windows 9x and Windows 3.1, just as Microsoft was trying to get
everybody to use Windows ME. Windows ME sales floundered, because ME
did not run gracefully, on it's own, as a client/supplement to Win4Lin,
or even as a client VM. In fact, ME was such a disaster, that many
users purchased "downgrades" to Windows 98. In some cases, they even
called the OEMs and demanded refunds and threatened to return the
machines, unless they were given Windows 98. Many users even converted
their ME machines to Linux.
Microsoft eventually purchased a third-rate Virtualization product
which only supported Windows as the host and Linux as the guest. It
supported other guests as well, including BSD, and several UNIX
variants. The guest environment was basic and crippled, but this is
just what Microsoft wanted. Today, it's sold as Microsoft's Virtual
PC. Appearantly, it's now available for download for free, in response
to the offer of VMWare Player from VMWare.
The Xen poject was able to devise a wrapper that allowed many Intel and
AMD chips to run Windows XP as a client, with no modifications
whatsoever. The software had to be reinstalled, but the emulation was
designed to emulate hardware that could be supported by nearly any OEM
version of Windows. The only problem was that Microsoft's anti-piracy
program kept detecting these VM images as "pirated" software.
When Microsoft first released XP to retail customers via the OEM
market, there were many users who decided that they needed to ad more
RAM, upgrade the video card, or otherwise alter the software in
legitimate ways. When Microsoft "shut them down" as software piracy,
many XP customers began calling their Linux buddies.
> So it seems Linux is at the right place and we are at the right time,
> all there needs to be is the developers to take on these tasks.
Keep in mind that developers have been using UNIX for almost 30 years
for these kinds of applications. Even before the Divestiture of AT&T
in 1983, there were variants and work-alikes of UNIX running on
"Microcomputers" that included OS/9, Cromemco Z-DOS, Alpha-Micro,
Xenix, and BSD 2.x.
Kernigan and Ritchie had the first working versions of UNIX back in
1968. It didn't have all of the features, bells, and whistles of Linux
or UNIX, but the foundation was there and the fundamental concepts have
changed very little. Had software patent laws been the way they are
today, K&R could have patented the pipe, the data stream, the object
oriented drive (bdevswitch, and cdevswitch) which were the earliest
form of object oriented programming, interface abstraction,
interprocess communication, preemptive multitasking, memory mapped
protection of processes, copy-on-write, and remote execution of
commands (UUCP and UUX).
>From 1970 to 1983, AT&T was in the telephony business. It couldn't
even enter the computer business because they were a regulated monopoly
and were barred from selling computers or operating systems directly.
AT&T did use UNIX for switches internally, including the #5 ACD, the #5
ESS, and numerous other switches used in call centers, COs, and for
trunk switching.
In fact, it was UNIX that made divestature possible. Because of UNIX
based switches, numerous voice connections could be multiplexed through
a single pair of wires previously only capable of supporting one call.
24 voice circuits could be switched through a single pair of copper
wires. With additional timing circuitry, thousands of calls could be
routed through fiber optic "wires" or cables, and Microwave towers.
When Judge Green ordered the Divestature of AT&T, one ofthe reasons
that AT&T was willing to accept the settlement, was that it would now
have the right to enter other markets, including the Computer market,
with UNIX.
> With modern networking, web-centric platforms and FOSS development
> environmants. such jobs may not be as hard as they once were.
Actually, they aren't hard at all. If you know the foundations of the
software, and the business rules, it's very easy to implement those
rules.
You need a relational database, inluding MySQL, PostGreSQL, DB2, or
Oracle. How much performance and reliability do you need? And how
much are you willing to spend to get it?
You need a user interface such as a web portal - you can use Apache
with Jakarta and Struts, or you can use WebSphere or WebLogic. Again,
how much will you pay for labor to "put the OSS together" vs how much
you want to spend for a complete solution.
You need to implement the business rules - this can be done using
hand-written Portlets and Servelets, or you can use a workflow engine
like WebSphere Process Server. Again, your needs depend on how often
the business rules change, and how much it costs to implement those
changes. A very stable system will run nicely on OSS. A volitile
environment, or an environment which must adhere to strict regulatory
guidelines - is often better implemented using commercial *nix (Unix or
Linux) implementations.
Putting this "Model/View/Control" environment together is also pretty
easy. You can use CGI or Servelets, or you can use XML, SOAP, and SOA
to interface to established standards and services ranging from zip
code lookup to credit card verification.
Even the connections between these components can be implmented using
simple HTTPS connections for real-time, immediate feedback
applications, or Message Queuing or Message Switching systems wich can
be used to interface to servers that don't need to be as aware of
current context information and can route response messages to "Message
Driven Beans" that can be tied to "Session Bean" objects which are
thread-safe and can manage the context for the duration of the work
involved.
Those old curses driven warehouse applications worked very well, and
still do. Which is why they haven't been replaced in almost 30 years.
They might have been upgraded, moved to better and faster hardware, or
ported from more expensive servers to cheaper servers, but the core
technology is fully functional.
Today, replacement of those old applications requires the knowledge and
experience of a good IT Architect who can really understand a number of
different environments and technologies down to the "bloody up to the
elbows coding" in order to effectively replace solutions that have
worked for years - with systems that can be upgraded and enhanced with
"interchangable parts".
|
|
