Fall World 2014

Conference & Exhibit

Attend The #1 BC/DR Event!

Winter Journal

Volume 27, Issue 1

Full Contents Now Available!

December 8, 2009

Working from home since 1980

Written by  Bill Lang, CBCP, MBCI, CBCV
Rate this item
(0 votes)

suburbanhome1.jpg As I sit here on my fiery little laptop using high speed internet I remember the days when working from home meant something a little different.

I’m not quite as old as dirt, I’ve never had a dinosaur burger, I didn’t start and stop my car with my feet, and a well known figure ranked a little higher than corporal when I was born. The Cold War was a teenager, the music had already died, but Miranda Rights hadn’t made it to the Supreme Court.

After graduating high school I took the county bus to all the major factories and applied for a job hoping to get into one of the big names – AO Smith, P&H, Allis Chalmers, Rexnord, Miller brewing. Buddies got together and drove dad’s car to neighboring counties where firms like American Motors once lived. I learned that I lived on the edge of what would come to be known as the rust belt. No jobs for high school grads without some inside advantage. A brand new term, getting “laid off” meant there was a chance at getting your job back again and was much better than getting fired.

My buddy said we should get into computers. So I took out a school loan and went to a local quick start training program hosted by Manpower Business Training Institute (MBTI). With a 97 percent placement rate it was easy to get a job after seven and a half months of book work with some hands on computer operations.

images4.jpgMainframe computer operator terminal.

After a few years I found myself a systems programmer specializing in the installation and maintenance of mainframe operating systems (OS) named virtual machine (VM) and virtual storage extended (VSE) as well as all the applications that ran under the two OSes. This VM even had predecessors ranging back to the early 60s.

There’s nothing more fun than modifying an OS using a bunch of assembler instructions, as gracefully as a BALR-ina. You talk tech now and ask about control registers or chaining channel command words (CCWs) together and you get the deer in the headlights look. I used to joke that when I died a core dump would pass before my eyes. Running the RDEV blocks to find a broken chain when a device doesn’t respond. Using the program status word (PSW) to indentify the failing instruction in a thousand pages of system dump. Techies say, what are you talking about? Today, the most complex problem is understanding the Windows registry and rebooting.

Okay, some actual years. I graduated high school in 1977 and started in IT in 1980, then became a systems programmer in 1983.

Working from home

While some big companies had modems and terminals, I was still required to talk computer operators through what I wanted done over the phone. They’d say, “Bill, the printer is running slow.” I’d say, “OK, type in CP SET PRI VSEPRT 5 and when you’re done printing set it back to 99.”

Since 1980 I was using a neat little feature of the OS where I could type information into a file and then send that file to a user on the system. They could edit the file I sent them, add some text, and send it back to me. Although it wasn’t called “e-mail” at that time, it was quite handy in a noisy computer room where telephone conversations were difficult. Instead of hearing, “You’ve got mail!” you’d get “00023 PUN FILE RCV” and have to type in RDRLIST and press a few PF keys to get your mail.

Another neat little command allowed you to actually send some text to others on the system. You’d type in “CP M OPERATOR I NEED TAPE XYZ ON DRIVE 580” and the operator would type “CP M BLANG TAPE MOUNTED.”

No, using all caps wasn’t yelling back then, it was just easier to read on the screen. Interesting that I was texting back and forth with people in 1980. I thought texting was such a new technology.

Another cool piece of software took control of your terminal and actually allowed you to have multiple terminals (or windows) all running separate programs – in 1980. I could draft letters in a word processor, compile and run programs, view reports, all kinds of activities on a single terminal in multiple sessions.

In 1984, I received the first remote terminal, a Silent 700. About the size of a laptop, it had a small keyboard and used paper tape and electric typewriter technology to display what would ordinarily come up on the screen. It operated at a speedy 300 baud over an acoustic coupler which is “about” 300 Bps (no not Kbps just Bps) or about 30 characters a second. Oh yeah, an acoustic coupler takes the phone handset and uses it to transmit data via sound. It looks like –

Since the phone line was taken up with the terminal, I had to communicate with computer operators using that brand new technology, texting. “CP M OPERATOR …” The operator would message back, “CP M BLANG ….”

My company bought a brand new large PC that was capable of running PC VM on it, but at 20 Mhz it simply wasn’t fast enough to run any meaningful business applications. Interesting that in 1984 we were running VM on a PC.

I got sick and tired of restoring files for people from tape, so I set up a virtual machine to automatically backup everyone’s changed files to a special drive where I automatically maintained daily copies for one week. For some programmers that heavily modified files all day long I had to modify the XEDIT program’s “file” and “save” commands so that I would be sent a copy to be archived every time they filed or saved something. That made it easy and fast when they called and said the last good file was from 10 a.m. and I could send them back their 10 a.m. file.

In 1985, the IT director springs for new informer terminals in carrying cases a little larger than bowling ball bag. No more paper tape, all green screen, or amber screen in this case. Just like using a 3278 terminal at work, but much slower at 1200 baud. Bringing up files in full screen took forever, but using line mode commands worked really well. Line mode is a lot like the DOS prompt were all the commands are on a single line and all the response come back as if they were going to a printer. Later upgraded to 2400 baud, twice as fast.


In 1986, a new job downgraded me to an ADM3A terminal a little larger than a 13-inch TV and back down to about 300 baud. White screen which seemed nicer than green or amber, but it sure took up table space. And what a horrible color, teal blue over medium blue.

We had two data centers with pretty much the same technology, one in Milwaukee and the other in York, Penn. We agreed to exchange OS files weekly over a 9600 baud dial up line so that either data center could run each other’s operations under VM. Since very few business people had terminal access to the systems, they would really never know where the systems were running. Each data center had banks of dial in lines for programmers so they could work at either building or even some satellite buildings.

In 1988, a new job brought a PC dual diskette system with an IRMA card for 3270 mainframe connectivity to my desk.

For remote connectivity I had a 3276 remote control unit with 4800 baud dial in capabilities so I took a 3278 terminal and modem home.
Okay, this is a massive mainframe operator console, but the 3278-2 is similar – fewer colored buttons on the keyboard.

Eventually, I got a nice little laptop that ran off of two, 3.5 inch diskettes. Screen was painfully small, but with a Mb+ of disk space I could save some files to disk and use Edlin to make changes.

In 1989, I got a laptop with a 20Mb hard drive built in.

I began to spend more and more time dialed in, so I got a second phone line.

From 1990 to 1998, I worked through a series of laptops and eventually worked up to a 9600 baud, then 14.4Kbps, then 28.8Kbps, then 56Kbps. External modems and internal modems (ATZ, ATDT… if you know what I mean).

When 9600 baud modems were hundreds of dollars each you had to do the ROI on the time savings from the faster speed. Number of characters transmitted, how long it took, how a faster speed would allow you to get things done faster. Today we are getting to the point where we just can’t throw hardware at problems anymore, like it was in the old days when careful calculations and planning was needed to succeed.

I connected the mainframe up to the our hardware vendor’s global network bringing internet email to the company as well as internet faxing. Terminal connectivity through the vendor’s dialer and later through Systems Network Architecture (SNA) and Internet Protocol (IP) with and without dial up. I Administered more than 1,800 login ids for vendor’s network using the vendor’s nifty little terminal emulator package with scripting to upload/download production files and mainframe email.

Our vendor’s terminal emulator had a nice compression that made 9600 baud and anything higher almost as fast as being at work on a directly connected terminal and you could access the mainframe, as well as several midrange computer systems.

In 1995, I got into project management and traveled around the country implementing systems and conducting training. Remotely connecting to training computer systems using laptop and the a large hardware/software vendor’s global network.

In 1998, had a DR contract with a large vendor and bullied them into allowing us to use their technical network link to also connect to their DR site from work and home using the vendors dialer and terminal emulator product for remote DR.

From 1998 to 2005 I changed careers to BCM and didn’t need a laptop, but I did use my high speed internet and home computer to connect to work’s web based e-mail. I brought work diskettes and zip drives home to do work or just emailed files around.

I now use a laptop and VPN in to work over my high speed internet to access everything as if I were sitting at my desk – e-mail, VoIP phone, shared drives, messaging. There’s even VPN to our DR site so all our technicians can work from wherever they are over high speed internet.

A laptop backup client runs in the background and copies my changed files to the office servers as I update them. I can restore to just about any point in time. Or I can choose to work with files directly from the office servers, like I use to do when the server was a mainframe.

Indeed everyone in my current company can work from home if necessary and some even rotate working offsite to eliminate the need for new office space or to take care of the kids when the schools decide to close. Or when the winter flu comes around and people decide that it’s not worth coughing and sneezing all over each other to get the job done.


We’ve come a long way since the days of the Silent 700 and 300 baud. Slowly but surely we are moving from a brick and mortar business world to one where people can work from anywhere and still get their job done effectively.

The recent inauguration along with concerted efforts by telecom providers to prevent outages has made the internet more robust and resilient. It is by no means at the level of being termed resilient and probably won’t be for years. But in the mean time we can use our network infrastructure and technology to work remotely and improve our work environment preventing or mitigating the risks caused when working in close groups.


lang.jpgBill Lang, CBCP, MBCI, CBCV, is the business continuity program manager for VCPI and it clients (www.vcpi.com). Lang uses more than 25 years IT experience to implement BCM techniques that have been proven successful in disasters and is an active contributor to many online forums, long-term care and BCM conferences, and has memberships in several emergency management associations and BCM related standards committees.

Read 2894 times Last modified on October 11, 2012