HP Muvee (.wmv)

Terry's 2009 Big Bend Tour; Austin to Marfa, Presidio, Terlingua Trading Post, Big Bend Ranch State Park, Big Bend National Park, the front porch at Terlingua, Chisos Basin, Alpine, Austin. Push that little play arrow below the Miata photo (or in the center); use F11 for full screen?

Don’t “Take a Message”

My attitude about responsive telephone communications is represented by the fact that we don’t use Voice Mail at our office. This was a conscious decision made in 1994, before the impact of email, IM, and the web. Being in the technical support area, we advertise our responsiveness and value it as a primary differentiator. Even though the mentioned wonders are now the mode of support for over half of our cases, there is still a need to continue to improve our phone communications.

The point of having no VM is to minimize the number of contacts on each case (to one). We want to eliminate phone tag and “we’ll get back to you.” An extension to this philosophy is handling calls for others: try to get it handled NOW instead of saying “I’ll have them call you back.”

Here’s an example: I ordered some cables online today but one of the parts was a special factory order line item. They may have to call us to confirm. If I’m not here, I hope the staff will pass the call to David. He’s somewhat aware of what I wanted. So is Bob. Perhaps one of them could make a decision or answer a question. Maybe Rob or Pam could decide what’s best. It’s worth a try.

Objective: don’t just say “I’ll take a message” before digging into what they really want and seeing if someone else can help them.

My ideal is to empower everyone to try to make decisions for others when it’s a “safe” call and time is of the essence. An impossible ideal, to be certain; mistakes will be made. But it’s worth a shot to try.

Ever since I was playing with one-inch tall green army soldiers on the dirt floor of a barn in Central Texas in 1955, I have wanted to build an “indestructible” concrete building that would last 500 years. The plan was set into my brain a couple of years later when my younger brother and I discovered that there was an old well about 20 feet deep on the back side of the ranch where we grew up. When we were about 8 and 9 years old, we used a rope to lower ourselves into that well and pretend it was a fort.

Now, at age 60, the company I own has built a datacenter on the 2 acres at Lake Travis where our office is located. It has tons of concrete and steel, no windows, and steel doors. There is even steel on the roof under a 4-inch concrete slab. It may not last 500 years, but it’s going to be very difficult for someone to tear down someday.

Why a datacenter? I must confess that one of my greatest fears as a small business person is that fire will destroy all of our assets. Insurance would help, but loss of everything would certainly damage or even destroy the business as well. It’s worse if some of the assets are not yours. I wanted to make sure that if my company became the guardian of the legacy hp3000’s of our customers, with all of their confidential data, we would be very sure that we would not lose anything or ever have to stop processing because of fire.

Ain’t it funny how mere ideas turn into reality, sometimes many years late? And reality bites us when we least expect it. Are you prepared for the worst? Systems redundancy is one possible way to protect your own company’s valuable assets and your own sanity. Ask us how we can help you cover your assets.

2009 makes 36 years I’ve been working on software. For over 30 of those years, it’s been with MANMAN. In 1978 I was at Thermon as MIS Manager when we bought MANMAN on an HP3000 Series II to manage our inventory, purchasing, customer orders, and accounting. By 1988 I had worked for ASK, left, and started my own company doing MANMAN modifications programming.

In 1998, MANMAN was “Alive and Well” according to the banner we hung in our booth at the CAMUS Annual Conference (see www.camus.org). Another banner proclaimed “It’s Not Time Yet”, a reference to the FUD surrounding the “impending demise” of MANMAN. Large companies were leaving MANMAN for Oracle and SAP and small companies were worried about Y2K. But MANMAN was actually as good for discrete manufacturers as any of the replacement systems at that time.

It was a great year for us, and now a decade later, we still support many of the same manufacturing companies running MANMAN. Almost a thousand companies survived Y2K on MANMAN, with a lot of work from 4 or 5 different competing teams of programmers and a few lone cowboys. MANMAN had a problem with FISCAL Periods, not dates. Dates worked great up through 2050 and beyond.

The ideal format to store FISCAL Period is CCYYMM (Century, Year, and Month). The FISCAL Period in MANMAN is stored in the less optimal format MMYY (Month and Year); i.e. 0198 was the first fiscal period of 1998. Too bad it wasn’t YYMM which would have sorted nicely, but that’s another story. There were several practical approaches to fixing this problem, but the differences were mainly in implementation and deployment considerations such as how easily the changes could be re-created in case of future modifications and where the source code was stored.

Most of the solutions used the same approach. It’s called split-century method and makes do with only 2 digits for YY (year) by assuming that any year greater than or equal to 00 must be the 21st Century (CC=20). Any Year (YY) greater than 49 is in the 20th Century (CC=19). Works great as long as no dates span a century, which is the case with all companies with MANMAN data. At this point in its life, we can say that MANMAN only has 43 years of usefulness left.

MANMAN was at its peak of use in 1998. We had been without enhancements for the decade. As for our customers (mostly on Release 9 or before), now it’s more like two decades. We’ve all managed to do what needed to be done to run large, mid-sized and small manufacturing enterprises with MANMAN for two decades with a minimum amount of resources and money. Two decades without upgrades! It’s been a great two decades.

HP stopped selling hp3000s in 2002, but over six years later there are still no clear reasons to migrate. Some package does some things better than other packages; they’re all different. Will there be real reasons to migrate ten years from now? In 2018? Probably, and I’ll believe it when I see it…

The best hope I see for the future is Open-Source ERP Software. There’s just no other way for small, lean manufacturing companies to afford ERP. The main reason that Oracle and SAP will be doomed in the mid-market is the cost of their annual “maintenance”. Large companies may be able to negotiate their “support” contracts down to 18%, but those who pay 25% (and more as time goes on, just wait and see), will eventually rebel. For the kind of money it costs to “completely repurchase” the application every 4 or 5 years, lots of in-house expertise can be acquired. And those resources will be working on what you need, not on what will sell the next copy of Bloated Apps’ to their next prospect.

I’ve been using and supporting a legacy ERP software application called MANMAN since 1978. One of the wonderful things about MANMAN is that many of the customers have all the source code for this large application they use as their primary manufacturing planning and execution system. The best part for me is that it is all written in FORTRAN/77 and runs on the HP3000 with the MPE OS and IMAGE database. MANMAN is currently owned by Infor.

There is also a version of MANMAN in the VAX/Alpha OpenVMS OS environment, but I am not as familiar with it as I am with the MPE versions. Neither product is considered viable from a marketability standpoint in today’s active ERP software arena. Nobody would buy MANMAN/MPE on its dying platform. Neither are any new sales of Infor’s MANMAN/VMS likely to occur. Almost comparable to today’s overwhelming ERP systems, MANMAN is simple but comprehensive and the data is accessible through MPE’s IMAGE Database and ODBC.

Note that I said many of the customers have all of the source code. MANMAN is now on its fourth owner, having been written by ASK Computer Systems (later The ASK Group) in the early 1970’s. I started my own company, the Support Group, inc. (tSGi) in 1994 when Computer Associates (CA) bought The ASK Group. MANMAN/MPE, my specialty, is now on Release 12, but many customers are still on a version prior to Release 10. In Release 9, the best version from a supportability perspective in my own opinion, the developers added some code, the source to which did not get sent to any customers. That code limits the number of users who can simultaneously access the application software. There is no practical limit for access through IMAGE or ODBC. Thousands of simultaneous users can access MANMAN/MPE on a large HP3000. But the “unlimited use” licenses are the minority, I believe.

As a separate issue from the numerous source code releases, there were, and still are, many versions of the license and contract to use MANMAN. ASK’s original contracts were set up so that MANMAN could be used on a particular machine (Serial Number). Later, in 1984, around the time of Release 5, ASK went to a “per user” pricing strategy. It was a “concurrent user” license, not a “named user” license.

When ASK announced the new pricing strategy, many customers who bought MANMAN before 1984 received a “grandfather” offer to be able to use MANMAN on any machine. A primary implication of “user pricing” as compared to the then prevalent “Serial Number pricing” is the “use on any one computer” paradigm. Prior to Release 9, there was no real checking or limiting of the number of users actually running the software at any particular time; it was an honor system that may or may not have been abused.

Around 1995 Computer Associates replaced the original ASK software license contracts with several replacement versions, all of which probably cancelled all prior agreements concerning the use of MANMAN. Instead of the perpetual use maintenance contract ASK had used to extend annual subscription support and software updates, CA inserted a usage clause that replaced the perpetual wording. I own a company that has, for 15 years, competed with whoever owns MANMAN. We offer various levels of support, from phone-in help desk to complete turn-key managed services and facilities provisioning. On my advice, many companies using MANMAN left support in 1995. They remain frozen on Release 9 to this day. They did not sign the CA contracts. Others signed the contracts but deleted the “usage” clauses, accepting and paying for only maintenance support and possible future upgrades.

Is it possible to go back to a prior release, stored on tape from old backups, and thereby fall under the original contract effective at the time of last use of that release? The CA and Infor contracts are for newer versions, Releases 10, 11, and 12. The ASK Computer Systems perpetual contracts were for Release 9 and before. Every company running MANMAN probably has a backup tape with their Release 9 data, programs, and configurations. Can they go back to the way things were before CA bought ASK? I’m just wondering…