•         
• Home
  • Home
  • Contact
• Formal Resume....
  • Project Manager
  • Business Analyst
  • Mainframe Developer
• Further details by company.............
  • Independant Consultant
  • Walker Interactive (aka Elevon, Infor)
    • Company Overview
    • Consultant
    • Software Development Manager
    • Consultant
    • Customer Support Analyst
    • Product Manager
  • GT Software
  • Rendeck
  • Altergo (aka Insac Software)
  • Unichem
  • British Insurance Association
• Roles and Skills......
  • Summary
  • Project Manager
  • Business Analyst
  • Mainframe Developer
  • Software Development Manager
  • Extra Curricular Activities
•           

Unichem Ltd (1973-1976)

Company Overhead:

Unichem is a Pharmaceutical Wholesaler, and at the time had around 4,000 customers (Chemists - the equivalent to an American Drug Store) and a product line of around 30,000 products. Their unique was that they called each customer, usually every day, asking what products they would like to order.

When I joined, they had a 360/25 with 48K of main memory, three or four 2314 disk drives (one non-IBM), a couple of tape drives and a dozen or two local 2260 terminals used for order entry. The operating system was DOS/360.

At some time, the 360/25 was replaced by a 370/125 and DOS/VS.

When I left, they had a 370/135 with 3330 disk drives and a couple of hundred remote 3270s in the field (the warehouses). The operating system was DOS/VS, the TP Monitor was THIRST (Task Handling with Immediate Response for Terminals), developed and written by Geoff Brown, and direct access files were mainly ISAM (I don't think they went VSAM while I was there).

They still called their customers most every day but instead of writing the order down on paper, the order clerks entered the order in the computer while the customer was on the phone. The system produced a combined pick-list (for the warehouse operations) and invoice (for the customer) and had a crude out of stock mechanism. For the early '70s, this was quite an advanced system.

My Involvement:

I joined Unichem as a Computer Operator, then became shift leader as they expanded their operations. I was lucky to be able to transfer to the programming department as a programmer analyst, using my knowledge of the 360 Instruction Set to quickly pick up Assembler. I also did a bit in RPG II, but that was an exercise in frustration for me.

I became a Systems Programmer while we were starting to design the new order entry system, and contributed by writing some of the Systems Software required. Specifically, I designed and wrote:

• The Product Identification part of the order entry system
• A remote spooling system for remote printers called TOSS (Terminal Oriented Spooling System)

Shining Moments:

I was (and still am) quite proud of the software I wrote for the remote order entry system. These were written in Assembler and ran under the THIRST TP Monitor.

The Product Identification system had interesting requirements. The order clerk had to identify the desired product within 6 seconds while the customer was on the phone, but we could not rely on standardized product codes. We also had to be flexible enough to use the existing product names and realize that the customer could describe a product in many different ways. I used two techniques to make this a manageable project:

• I required that the first three characters of the product name be standardized
• I weighted products into fast movers and slow movers based on sales history

The order clerk would type in the first three characters (at least) of the product name, plus the first part of any other words from the product's name. The system would provide a list of matching products from the fast movers:

• If there were no matching fast movers, it would continue to search through the slow movers
• If there were still no matches, the system would drop the last word and try again
• The order clerk could:
  • Select a product and proceed with the order
  • Search further through the slow movers

The system was very successful, meeting and exceeding expectations. From the order clerk's point of view, it was forgiving of entry mistakes and rewarded those who learned the product names. It was an easy system to learn.

TOSS (Terminal Oriented Spooling System) was a remote spooling system for 3270 type printers. The order system produced a combined pick-list and invoice, which had to be sent to a remote printer in the same warehouse. Each terminal or group of terminals had a default printer. If there were problems with a printer, its work load could be transferred to a different printer.

I was surprised I was allowed to call it TOSS - and yes, it did have an output file called TOSSOF.

In that same vein, THIRST programs (which were pseudo-conversational) all started with a table and a bit of code that identified where it was in the process and what it should be doing next. We called the table the Concise Leg Initiation Table.

---