| Early days | Maritime Life | Sperry Univac |
| NS Credit Union League | Xerox, COS | Scotiatech |
I got a job at Scotiatech, in the Annapolis Valley of Nova Scotia. Scotiatech was the Information Technology department of Scotia Investments, the holding company of the Jodrey family. Scotiatech provided services to:
Scotiatech programmers and analysts were assigned to projects at the various companies, as needed. This environment provided rich opportunities for involvement in manufacturing, inventory control, order processing, and telecommunications.
 |
|
A few Scotiatechers at racquetball tournament. Top: Terry Dulong, a rectal orifice, Yvonne Van Blarcom Mid: Ann Jardine, Lorraine Banks, Gordon Cumming, Dave Frizzell Bot: Pierre Clouthier, Peter Gesner |
My first project was at COBI Foods. We evaluated, selected and implemented an order entry & inventory system. We rejected BPCS (Business Process Control System), in favour of the more comprehensive PMS (Product Management System), which was written in RPG, and ran on an IBM System 38, later AS/400.
We were able to combine the inventories and sales reporting for the Graves, Avon and Stokely-Van Kamp brands, which had up to then been kept separate.
I went on to manage the telecommunications network for the combined companies. We used the Datapac service, an X.25 packet-switching network. Datapac was a cost-effective way of connecting branches across the country to the head office computer. We were able to run HP and IBM traffic on the same line.
I wrote a program in QBASIC to monitor the network status. Called NIPS (Network Integrity and Performance System), it polled the X.25 PADs (Packet Assembler/Disassembler) and switches to check that they were running OK. It ran on an XT, a 4 MHz PC. A PAD converted Asynch traffic to X.25 packets. I was often required to visit remote sites to diagnose and fix faults in the communications systems. My patient wife would accompany me. I would optimistically under-estimate the repair time, and she would chide me about the "Scotiatech 15 minutes", code-word for an interval of understated and interminable duration.
Most of the other companies used HP 3000 systems written in COBOL or RPG.
I also evaluated and selected a computer system for Armour Transport when they took over the management of Pole Star. We found an excellent system called LTL/400 written by Reeve Fritchman, who lived in Philadelphia at the time. LTL is trucking lingo for "Less than Truckload", payloads that don't fill a trailer, and require assembling many loads to be cost-effective.
As the IT capabilities of the SIL companies grew increasingly sophisticated, they formed their own IT departments, and Scotiatech was dissolved and the employees laid off.
I incorporated my company, Kyber Consulting, and did a couple of very interesting projects, while beginning the development of what later became Progeny's Charting Companions, genealogy graphics software.
MPP makes cardboard, using huge rolls of linerboard made by Minas Basin. They have a plant in Dartmouth, NS. The carboard is manufactured in a continuous process by a Marquip corrugating machine. The Marquip is the length of a football field, and costs about $1M. Typically, three rolls of linerboard are fed into the corrugator. The centre roll is rippled or corrugated, giving the cardboard its rigidity. The three layers are glued together.
The web of cardboard travels quite fast. It is slit longitudinally by wheel knives, and cut cross-wise by a knife specially spiralled around a long metal bar. The width of the cardboard is determined by the position of the wheel knives, and the length by the frequency of rotation of the cross-knife. These are controlled by an AT PC (8 MHz).
 |
 |
| Rolls of liner board prepared for loading | Slitter station |
The dimensions can be entered by the employees that operate the corrugator. MPP wanted to automatically transfer the information directly from their customer order system, which ran on an HP 3000, to the Marquip PC. I accepted the assignment as an independant contractor.
 |
 |
| Cross-cut and stacker | Finished product |
I wrote MOP (Marquip Order Program) in Borland C. MOP ran on the Marquip PC, and was connected to the HP via an RS-242 Asynch line. I wrote a low-level interrupt handler to communicate with the HP. MOP logged on to a port on the HP, and simulated a human operator inquiring about an order. The PC would retrieve all the data: carton width, height, quantity, customer name, etc. It would write the information to a disc file, which was then picked up by the Marquip control program. This freed the operators to concentrate on the complexities of managing the Marquip, and reduced transcription orders.
 |
| Control room |
MPP also wanted to print shipping labels, in large, visible letters. I reverse-engineered font outlines from the Borland library, and adapted them to a dot-matrix printer. I implemented the rarely-used output buffer interrupt to compensate for the slow printer speed. When most Asynch applications need to output on a COM port, they just test whether the port is free, and loop until the previous characters are transmitted and the the port is available. This is called polling. After all, what else is there to do while waiting for the output to complete?
In a mutli-tasking environment such as MOP, this was not acceptable as the PC had to be continuously available for other tasks. So after outputting a character, I would resume operations, and wait for the output buffer interrupt to inform me that the output port was available again, whereupon the program would interrupt what it was doing and fire off another character.
Debugging interrupts was tricky business. You couldn't stop the program, or print out trace data, which would have been too slow. This was a DOS application, so we were limited to 640K, which wasn't enough memory to store thousands of real-time memory snapshots. The PC had 2MB of actual memory, inaccessible due to DOS' limitations. Fortunately, there was a trick which enabled the computer to treat the high-order memory as a 'disc'. The program could open a virtual file, write ot it, then later read it back. I stored high-speed debugging trace statements in this manner.
MOP ran reliably for many years.
Larsen Packers is a hog slaughterhouse in Berwick. They buy hogs from local pig farmers, cut, process and package the meat for sale to consumers.
The processing of hogs includes weighing the carcass after it has been gutted and cleaned, and measuring the percentage of fat and meat. This is done with a probe shaped like a gun with a long needle. At the tip of the needle is a photocell that can detect white fat and pink meat.
The carcasses are hung from hooks that travel along an overhead conveyor line, and pass in front of each station where an operator performs a task. Each hog is tatooed at birth with the farmer's number. As the hogs travel down the line, they are weighed on an electronic scale, then an operator probes the flank, where the meat/fat content is transmitted electronically.
 |
| Probing meat |
Previously, Larsen would print the information on a strip of paper, and then key it in manually. They wanted to automate and speed up the process. They retained my services to develop GPI - Grading Probe Interface. (My only regret is not having named it 'PIG': Probe Interface for Grading).
GPI used the communications interrupt handler I had developed for MPP. It ran on a 386, and communicated simultaneously with the electronic scale, the probe gun, the keyboard and a bar code scanner. It used a special communications board that added 8 Asynch ports to the PC. The information was merged into a single record, written to diskette at the end of a shift, then brought to an IBM AS/400 to calculate the amounts owed to each farmer.
The probe gun was interesting. It was manufactured in New Zealand, and used a current loop interface. It had the ability to display a six-digit number at the end facing the operator, which came in handy for synchronizing the weighing and probing. This number originated from GPI, and required using the gun's special communications protocol.
The whole process had unique challenges and pressures. Since the hogs were cut up, it was impossible to re-do a run if the data were lost. This would have been catastrophic as Larsen's could not re-create the information, and would have had to estimate, certainly to the detriment of one or other party. As a precaution, the data was written to two separate files. Each file was closed and re-opened after each transaction, to flush the buffer and prevent a loss if the power failed or the program crashed. The data was also printed in real-time as a backup.
The first day we went live was interesting. Larsen was too cheap to pay the employees for training. We did a few tests with a single carcass, during which I once got my hardhat knocked off by a swinging hog. But there was never a full-scale rehearsal because it would have involved twenty or thirty highly-paid unionized employees, and many expensive hogs. So we implemented the system cold turkey.
Picture this: I'm standing next to the operator at the weigh/probe station. At the other end of the line, the hog carcasses start rolling in from the kill station. In the first step, an operator directs a big propane flame at the carcass, burning off the hairs. The smell of burnt hair fills the hall. And here I am quickly teaching this guy, whom I've never met, how to operate this complex new computer system. Remember, these guys don't slaughter hogs because they are whizzes at business systems.
We have a couple of minutes before the first big, 400-lb carcass comes swinging at us. Here it comes! Quickly we spike a bar code on the carcass, wait for the weighing, stick the probe in, done! Whew! Then along comes the next one. Zero margin for error. What a circus.
We only had to abort the run once. The next time we pulled it off. This was one of the most nerve-wracking IT episodes in my life. But I did enjoy the project immensely, and the Larsen's staff, including Frank Weir and Barry Fowlow, were great people to work with.
I built my own protocol analyzer by making a split cable, writing a special program that ran on a 286, and displaying in hex the stream of bytes flowing over communications port. I also wrote a simulator for the scale and the probe, enabling me to debug GPI in my office in the trailer I had installed next to my home on the North Mountain.
The program was very stable. The only time I was called in for maintenance was to compensate for an operator who insisted on jigging the bar code label under the scanner.
MT&T (later Aliant) is one of the telcos (telephone companies) that provides telephone services in Canada. When a customer leases a data communication line from a telco, the line often crosses more than one provincial jurisdiction. When there is a problem and the communications link is down, the telcos collaborate to fix it. The customer need only talk to the telco where the customer's head office is located, and the latter coordinates fixing the problem. When the customer notifies his telco, a trouble ticket is created which registers the complaint.
In 1991, Canadian telcos developed a system to swap trouble tickets. Each telco had their own administrative system, so they each developed their own versions. MT&T called theirs RIC (Resource Interface Converter). I sub-contracted to DDA to write RIC in C, running under IBM's OS/2.
RIC was connected to the IBM mainframe using APPC (Advanced Peer-toPeer Communications) . The RIC PC also had an X.25 card, connected to the Datapac network. RIC would submit queries to the IMS data base. When a trouble ticket was opened, RIC would retrieve the information, re-format it, and transmit it to the other province over Datapac. RIC would also poll the national network for incoming trouble tickets, which were posted to MT&T's data base.
OS/2 was 5 years ahead of Microsoft Windows, and offered full 32-bit processing long before Windows did. However, OS/2's strength was also its weakness.
OS/2 was developed from scratch, and was not encumbered a legacy of DOS compatibility, 16-bit applications, and drivers like Windows was. This enabled IBM to innovate radically and more quickly. RIC was a multi-threaded program, written paradoxically with Microsoft's Programmer Workbench, the character-based precursor to Visual Studio.
However, this freedom from legacy code also meant there were few applications available for OS/2, and the only drivers were for IBM printers. OS/2 eventually disappeared in spite of its technological superiority at the time.
IBM's development environment was called C-Set, and, in spite of being a 32-bit compiler, was inferior to Programmer's Workbench. For instance, after a compliation, if you double-clicked on an error message, it would open up the source code in a separate editor window, in a proportional typeface. You could not trigger a compilation from this window. You had to make your change, save & close, then go back to the compiler window. Retarded.
There was no Resource Workshop for designing dialog boxes visually. You had to write all the statements in a text editor, and wouldn't see the appearance until compiling and running the program. This slowed down development.
While debugging, I recall trying to step into the GUI part of the application code. This locked up the computer so bad we had to re-install OS/2, a tedious process requiring 22 diskettes.
The IBM documentation was so inscrutable that even for ver. 2 of OS/2, we had to refer to Microsoft's ver. 1 manuals. IBM's support gave an interesting insight into OS/2's downfall. MT&T had an expensive OS/2 support contract with IBM. The MT&T contacts were two guys in the PC support section. When I required technical support to answer some obscure and specialized questions about OS/2, it didn't make sense to get the MT&T guys involved, even though they were supposed to be the only offical go-between with IBM. So I called IBM with MT&T's authorization, and impersonated one of the support techs. After a few calls I slipped and used my name. The IBM guy was livid and tore a strip of me, saying that as an independant contractor, I had no business blah blah. Here I was just trying to get a customer up & running.
The MT&T people I worked with, such as Fraser Smith, Ken Goodick and Ron Jordan, were friendly and smart, a pleasure to work with.
| << Xerox, COS | Back to the Rants |