NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/vmsnet/internal/1257

Internet Message Format | 1992-09-02 | 3.6 KB

Path: sparky!uunet!munnari.oz.au!network.ucsd.edu!mvb.saic.com!macro32
From: Hunter Goatley <[e-mail]>
Newsgroups: vmsnet.internals
Subject: re: PATCH on ALPHA ?
Message-ID: <[e-mail]>
Date: Wed, 02 Sep 1992 07:00:41 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List
Lines: 65

<[e-mail]> writes:
>
>>I don't think I'd want to subject my customers to the headache of trying
>>to manage patched images. DEC has been moving away from this as fast as
>>they can, and for good reason. It's much too easy for a customer to mis-
>>type a patch and really screw things up, and if you provide them with a
>>file to do it for them, why not provide them with an updated image?
>
>We generally distribute patches as DCL files to avoid problems like that.
>On those occations when I need to read someone a patch over the phone
>I have them read it back to me before they perform an update.  Then I ask
>them to rerun patch and examine the new binary values before they run the
>new image.  With Patch we can have a fix out to the customer within an hour
>instead of the day or two it takes to ship a new tape.
>
Exactly.  When I used to work for Clyde Digital (now Raxco), PATCH and
I became very good friends.  Not that the code had so many major
problems, but rather that a lot of customers liked to have their own
little tweaked version of a product.  Being a small company looking
for money anywhere they could get it, if a customer said "We'll renew
our maintenance if you'll change this", more often than not the
management said, "OK," and then made me come up with a way.  (Note: I
have no idea how Raxco runs things anymore---this was several years
ago, and is part of the reason I left there.)

By using PATCH to update an image:

  o  the customer had the fix or modification within minutes;
  o  as the developer, I didn't have to go back to the sources for
     the released product and make a change to them;
  o  I didn't have to release the current, not-even-in-alpha-test
     version of the product that already included the change;
  o  I didn't have to worry about having five or six different images
     that all did mostly the same thing.  The patches were easily
     categorized and customer support could dole out the appropriate
     patch to any customer who needed/wanted it.

By using REPLACE instead of DEPOSIT, we and the customer were assured
that they were patching the right place.  I don't remember ever having
a customer screw up a patch---even one that had been read to him over
the phone or FAXed to him.  Granted, that's pretty amazing, but.... 8-)

>Has any one else here had any problems using Patch?
>

I never had any problems using PATCH, but it doesn't surprise me that
a lot of people don't like it.
Not to get into too much name-bashing here, but I had several problems
with patches produced by other companies, including the previous
respondent's company.  I remember at least one crash scenario for
which the developer at the other company issued three different
patches before he got it right.  The Clyde product had been implicated
in the crash, but it was because it was monitoring the other company's
pseudo-terminal.  By working together, the proper patch was finally
written.

Again, let me point out that this was several years ago, and I am by
no means implying that such problems still exist, because I don't have
any idea if they do or not.  But it is true that improper use of PATCH
can cause more problems than it solves.

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
[e-mail], 502-745-5251