 | |
Here are some SRS stories that may amuse or disgust
you --- depending on how close they hit to home.
Backing up. Beep, beep, beep.
At one company, as the size of their database grew, a full backup would
no longer fit on a single tape. The computer operator decided to back up just
the databases and the O/S. That worked well for a couple of years --- until
the disk drive crashed. They were able to recover their database and the
compiled application code, but the hands of the 3-person programming staff
were tied. They couldn't do much, other than change some dictionary items or
paragraphs, until the SRS gave them back the program source code.
Another company didn't realize their backup tapes for the last eight
months were all useless because of a hardware problem - a problem reported by
the backup software and ignored by the computer operator. They would have been
okay if some new hire hadn't inadvertently deleted the source code directory
one day. All of the application development done for the last eight months was
lost and would have been re-programmed, were it not for the SRS.
Note to self: Remember to verify that the backups are saving the
program source code.
You can't fire me. I'm the only one that knows the password for the source
code I've encrypted.
Tisk, tisk! Some folks seem to learn things the hard way. He was fired.
They didn't need no stinking password --- they knew about the SRS.
I'll show them. They'll never figure out all of the little bugs I've put
into the source code. (Some of these programs can't be compiled any longer;
otherwise, the application will stop working.) I'll show them! They need me.
A derivation of the previous story, but a scary one -- it was as though
all of the programs had potential viruses in them. The perpetrator made
insidious changes over a period of several months, knowing that the company's
backup procedures only provided a two-month window of recovery. The other
programmers wouldn't know whether or not they had been sabotaged until they
tried to compile and run the programs. The perpetrator copied the original
programs off to his own computer. Unfortunately, that copy wasn't available to
the company. The company used the SRS on the object code they were running. In
addition, they compiled the suspect source code and used the SRS on that set.
By comparing the two source code result sets they figured out which programs
had been sabotaged.
We're sorry, the number you have dialed has been disconnected and there is
no new number. If you believe you have reached this recording in error, please
hang up and try your call again.
Over the years, a variety of software application vendors have been
successful at licensing their products, only to stumble and fall into the big
bit bucket of software companies. Sometimes the software vendors keep the
source code escrow up to date; sometimes they don't. When the source code
escrow isn't there or it is out of date, the SRS saves the day.
Oh, you have that version? Wow, dude! Like, we stopped supporting that a few
years ago. Let's see... Hold, please... (Music...) Okay, I'm going to transfer
you to Spike in sales for a quote on the upgrade to the new version for the
Framus O/S. What? You don't run the Framus O/S? Wow... Hold, please…
(Music...)
Your company bought the computer system and application software many
years ago, and it seemed like a good idea at the time. Initially, the software
vendor would make changes here and there, but now the vendor doesn't want to
go there any more --- he has moved on to the latest and greatest whatever. So,
what's the problem? Just buy a new computer system and application software,
convert all of your data, and re-train all of your employees. That's simple,
right? Simple, maybe. Easy? No. Instead, some companies have decided to take
on the role of support themselves by using the SRS.
I'm sorry, your computer hardware is officially obsolete and we won't
support your configuration any longer.
The software vendor has evolved their application to the point that it
will no longer operate on your computer system. Consequently, they no longer
provide support for your version. This is another case where it may be easy to
recommend upgrading everything, but some companies have used the SRS to
establish their own self-help program.
Hey, George. Do you know where the source code to the _____ programs are
kept?
While in the midst of converting their application to a new database
platform, some companies have found that several key programs seem to be
missing. This is probably the most common call for the SRS.
We used the PI/open to UniVerse decompiler and now all of the programs look
like #@$%! They're chock-full of GOTOs. Trying to maintain this stuff is a bear!
The UniVerse decompiler for PI/open lets you cross the bridge, but once
you get to the other side…. to put it plainly, maintenance of the source
code can suck. Many of us like spaghetti - in a bowl, with some cheese - but
not in our programs. The SRS can tidy up the mess by bringing back the logical
structure and getting rid of many, if not all, of the GOTOs.
Hey, Mack. Let's compete against XYZZY Company. We've got that back up of
their application we stole from a site a few months ago. We'll send the stuff to
the SRS and we'll be in business.
Bzzzzt! I'm sorry, that's the
wrong answer! But, hey! Thanks for playing along! As a consolation gift,
Johnny has these nice nickel-plated handcuffs or you can choose what Mary has
behind curtain number one. Why, it's an all-expense-paid extended vacation at
your nearby penitentiary, a certificate for two tattoos, and a one-year supply
of soap-on-a-rope! Better luck next time - Bye-bye!
The SRS is not intended to be used to commit
intellectual property theft. We reserve the right to refuse service to anyone.
The stories are real. The names are changed to
protect their privacy. Any similarity to real people is purely unintentional…
but if you recognize yourself, you may need to use the SRS.
|
