despair - VMS

This is a discussion on despair - VMS ; On Sep 16, 5:06 pm, "David P. Murphy" wrote: > On Sep 16, 8:39 am, AEF wrote: > > > > > On Sep 15, 10:47 pm, "David P. Murphy" wrote: > >> followed by the inevitable > > >> ...

+ Reply to Thread
Page 3 of 11 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 219

Thread: despair

  1. Re: despair

    On Sep 16, 5:06 pm, "David P. Murphy" wrote:
    > On Sep 16, 8:39 am, AEF wrote:
    >
    >
    >
    > > On Sep 15, 10:47 pm, "David P. Murphy" wrote:
    > >> followed by the inevitable

    >
    > >> %SYSTEM-F-DEVMOUNT, device is already mounted

    >
    > >> and immediately thereafter

    >
    > >> %BACKUP-F-POSITERR, error positioning $1$MUA400:[000000]DAILY.BCK;
    > >> -SYSTEM-F-SERIOUSEXCP, serious exception detected by TMSCP
    > >> controller

    > > AHA!!!!! Withholding evidence!!! Sloppy, sloppy, sloppy! And you
    > > complain about the code author!!! ... HAH!

    >
    > > This is like when Tom and Ray on Car Talk are trying to diagnose a
    > > caller's car problems and after struggling for 5 minutes, the caller
    > > finally mentions, "Oh, by the way, the engine check light came on" or
    > > "It only does it when..."

    >
    > No, it's much more like getting dozens of errors from a compiler
    > when they're all due to a single missing variable declaration.
    > They're called "fallout errors", because they don't mean a damn
    > and disappear once you fix the actual problem upstream . . .
    > just like the BACKUP fatal messages are completely misleading
    > and would not have occurred if the command procedure had properly
    > handled either the failed ALLOCATE or INITIALIZE commands.
    >
    > In what way do you consider these messages "evidence"? The warning
    > should have been enough for anyone.


    I meant the totality of the error messages as evidence.

    I was saying that no one else puts tapes in the machine, probably
    things will run more or less okay -- at least not disasterously.

    Only LATER do you show that there was an actual resultant problem.

    That's all I meant. I mean, my whole point is that context matters.
    Are you running a nuclear power plant or playing stupid video games?

    When I have some time at work I'll check the sequence of events you
    report on my test box.

    > ok
    > dpm


    AEF


  2. Re: despair

    re: Management not granting you permission to make a simple change.

    Simply send (and record) and email warning them that a statement in the
    procedure would make it possible for the daily backup to overwrite some
    tape containing important data and that a simple modifocation to it
    would prevent this occurance.

    If they refuse, you then have the emails to say "I TOLD YOU SO" when the
    owner ofthe important data complains to management about loss of his data.



  3. Re: despair

    In article <1189996011.648131.314640@19g2000hsx.googlegroups.c om>, AEF writes:
    >
    >
    >On Sep 16, 9:49 pm, "David P. Murphy" wrote:
    >> On Sep 15, 11:29 pm, Ron Johnson wrote:
    >>
    >> > However... why shouldn't I rely on LOGINOUT.EXE to deallocate my
    >> > tape drives or free my VM?

    >>
    >> #1 Why _shouldn't_ you close/deallocate/free/release a resource
    >> explicitly? There is no good reason.
    >>
    >> #2 What if another, less experienced, programmer decides to copy
    >> your code? He won't realize that you're relying on LOGINOUT.

    >
    >(1) Comment your code!!!


    People, in my experience anyway, tend to not comment DCL whether it's a
    performance issue or otherwise. However, for a small procedure such as
    David has posted, the performance excuse is moot.



    >(2) Caveat emptor. You can't be expected to save the world. You can't
    >be responsible for every possible misuse of your code. If a knife is
    >used to murder someone, is the knife manufacturer responsible?


    Yes! And the retail establishment which sold the knife too as well as
    and the sales person who sold the knife without getting a full and com-
    plete personality profile of the buyer. Let's not forget that the em-
    ployer of the knife weilding murderer is also responsible because they
    hired and paid the buyer so he could buy the knife. Of course, there
    is the victim. Don't forget the victim; they're the most liable party.
    Why were they in front of the knife blade without wearing a government
    bureaucracy approved knife-proof protective garb? The victim was just
    asking for it!



    >(3) The inexperienced programmer will most likely screw something else
    >up that's even worse anyway.


    Back to comments, the inexperience programmer will learn more from said
    code if comments are included.

    One of the things I've heard newbies to DCL often ask: why is the clock
    set to 12:00:00.00 at this spot? ($ SET NOON) A little commenting can
    go a long way!


    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  4. Re: despair

    On 09/16/07 20:49, David P. Murphy wrote:
    > On Sep 15, 11:29 pm, Ron Johnson wrote:
    >
    >> However... why shouldn't I rely on LOGINOUT.EXE to deallocate my
    >> tape drives or free my VM?

    >
    > #1 Why _shouldn't_ you close/deallocate/free/release a resource
    > explicitly? There is no good reason.


    Truthfully?

    The vast bulk of my jobs are "backups" that send their data to a
    single tape drive (or multiple, for Rdb backups) and then exit.

    > #2 What if another, less experienced, programmer decides to copy
    > your code? He won't realize that you're relying on LOGINOUT.


    Good point.

    > #3 My first reason is so good that I'm going to repeat it.
    > In fact I'm trying sincerely to think of any justification
    > at all for skipping that code, and I cannot.


    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  5. Re: despair

    In article , VAXman- @SendSpamHere.ORG
    wrote:

    > In article <1189996011.648131.314640@19g2000hsx.googlegroups.c om>, AEF
    > writes:
    > >




    >
    > >(3) The inexperienced programmer will most likely screw something else
    > >up that's even worse anyway.

    >
    > Back to comments, the inexperience programmer will learn more from said
    > code if comments are included.
    >
    > One of the things I've heard newbies to DCL often ask: why is the clock
    > set to 12:00:00.00 at this spot? ($ SET NOON) A little commenting can
    > go a long way!


    The best comment I got about a SET NOON was delivered over my shoulder
    as I typed it.

    "Visions of Gary Copper here."

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  6. Re: despair

    In article , VAXman- @SendSpamHere.ORG
    wrote:

    > In article <1189996011.648131.314640@19g2000hsx.googlegroups.c om>, AEF
    > writes:
    > >




    >
    > >(3) The inexperienced programmer will most likely screw something else
    > >up that's even worse anyway.

    >
    > Back to comments, the inexperience programmer will learn more from said
    > code if comments are included.
    >
    > One of the things I've heard newbies to DCL often ask: why is the clock
    > set to 12:00:00.00 at this spot? ($ SET NOON) A little commenting can
    > go a long way!


    The best comment I got about a SET NOON was delivered over my shoulder
    as I typed it.

    "Visions of Gary Cooper here."

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  7. Re: despair

    VAXman- @SendSpamHere.ORG wrote:
    > One of the things I've heard newbies to DCL often ask: why is the clock
    > set to 12:00:00.00 at this spot? ($ SET NOON)



    That is simple. At noon, the DCL engine gets really hungry and is
    therefore willing to eat any/all DCL commands, and will continue eating
    DCL even after having eaten a bad line.

  8. Re: despair

    Interesting discussion.

    As someone who's been denied the DEC world for about 10 years this
    shows the fairly stark difference between "old time DEC philosophy"
    and the UNIX/windoze approach to things.

    The DEC way of doing things was for applications/libraries to be aware of
    everything that is occurring at every level, and dealing with that in a
    sensible manner.

    This meant that if you had a failure in an application or library you would
    be returned an error and the documentation for that component would tell
    you exactly what errors would occur under what circumstances. Makes
    debugging and fault tracing easy and also means that every process would
    behave in a specifically predetermined manner, no matter how it was used.

    In the UNIX world, we write code that charges ahead and relies on the
    underlying modules to deal with error conditions. This has the result that
    often error conditions go unnoticed, have bizare/unexpected side effects,
    or when the error is noticed, it's so out of context it's almost impossible
    to trace.

    The more recent try/except/catch constructs in languages have helped improve
    this somewhat, however it's still used so infrequently in libraries that a
    lot of "modern" programming is trying to work out what the designer of some
    random library was thinking when they wrote the thing.


    The first ARPAnet worm illustrates this quite well.

    The sin committed in that script wasn't not realizing that node adjacency is
    commutative until the enter key was hit, that was just a basic bug in the
    algorithm, but rather the first line of the script:
    SET NOON
    which was employed so that the script wouldn't bomb out when trying to
    submit jobs to the many '11s on the net at the time.

    The proper "DEC" approach would have been to test for the failed submit
    condition and continue at that point. Using SET NOON meant that the script
    was close to impossible to stop.

    And to continue the theme of scripts not being run by the same person in the
    way intended; remember that the worm had a second coming when someone on
    one of those '11s found the worm in one of the job spools, wondered what it
    did and so submitted to his nearest VAX

    Bruce
    RIP ~prep


    Ron Johnson wrote:

    > On 09/13/07 23:26, AEF wrote:
    >> On Sep 13, 6:19 pm, "David P. Murphy" wrote:
    >>> Real code at the beginning of the "daily backup" batch job:
    >>>
    >>> $ ON ERROR THEN CONTINUE
    >>> $ ALLOCATE 'tape_drive'
    >>> $ INIT 'tape_drive' 'label'
    >>> $ BACKUP/IMAGE/REWIND/'quals' -
    >>> 'disk' -
    >>> 'tape_drive'DAILY.BCK/SAVE
    >>>
    >>> I have lost what little faith in humanity remained in me.
    >>>
    >>> ok
    >>> dpm

    >>
    >>
    >> My questions:
    >>
    >> Is the same tape in the drive every day?
    >>
    >> Are there any more BACKUP commands in the rest of the procedure?

    >
    > Does it matter? Defensive programming says you defend against
    > hardware glitches other people's mistakes.
    >



  9. Re: despair

    On Sep 16, 5:06 pm, "David P. Murphy" wrote:
    > On Sep 16, 8:39 am, AEF wrote:
    >
    >
    >
    > > On Sep 15, 10:47 pm, "David P. Murphy" wrote:
    > >> followed by the inevitable

    >
    > >> %SYSTEM-F-DEVMOUNT, device is already mounted

    >
    > >> and immediately thereafter

    >
    > >> %BACKUP-F-POSITERR, error positioning $1$MUA400:[000000]DAILY.BCK;
    > >> -SYSTEM-F-SERIOUSEXCP, serious exception detected by TMSCP
    > >> controller

    > > AHA!!!!! Withholding evidence!!! Sloppy, sloppy, sloppy! And you
    > > complain about the code author!!! ... HAH!

    >
    > > This is like when Tom and Ray on Car Talk are trying to diagnose a
    > > caller's car problems and after struggling for 5 minutes, the caller
    > > finally mentions, "Oh, by the way, the engine check light came on" or
    > > "It only does it when..."

    >
    > No, it's much more like getting dozens of errors from a compiler
    > when they're all due to a single missing variable declaration.
    > They're called "fallout errors", because they don't mean a damn
    > and disappear once you fix the actual problem upstream . . .
    > just like the BACKUP fatal messages are completely misleading
    > and would not have occurred if the command procedure had properly
    > handled either the failed ALLOCATE or INITIALIZE commands.
    >
    > In what way do you consider these messages "evidence"? The warning
    > should have been enough for anyone.
    >
    > ok
    > dpm


    I meant the fact that you didn't tell us that there was a problem.
    IOW, I was referring to all the error messages, not just the last few
    error messages.

    It seems to me that it was mostly the result of someone having used
    the tape drive he shouldn't have, which, because even if the procedure
    were written correctly the backup still would not have been done,
    suggests that this ON ERROR THEN CONTINUE is not the biggest problem
    at your site!

    What does it matter?

    If your housekeeper or housemate or whoever left the door unlocked
    when he or she left, does it matter if someone robbed your house or
    apt. as a result? I say, YES! Does it matter if you live in a high
    crime neighborhood or not? I say, YES!

    If you live in The Plains, OH, you don't need to put a club on your
    steering wheel. This is not true in a big city! So don't complain
    about the lack of a club if you live in The Plains. You didn't tell us
    where you lived, so to speak. Yes, it's still bad programming and
    should be fixed. How bad a disaster it was depends on what happened to
    the tape, what was on the tape, what was missed in the thwarted backup
    operation, and whether any backups ever succeeded at this site!

    AEF


  10. Re: despair

    On Sep 18, 8:28 am, AEF wrote:

    > I meant the fact that you didn't tell us that there was a problem.
    > IOW, I was referring to all the error messages, not just the last few
    > error messages.


    Surely an experienced person such as yourself saw them coming.

    > It seems to me that it was mostly the result of someone having used
    > the tape drive he shouldn't have, which, because even if the procedure
    > were written correctly the backup still would not have been done,
    > suggests that this ON ERROR THEN CONTINUE is not the biggest problem
    > at your site!
    >
    > What does it matter?


    $ ON WARNING THEN GOTO ABORT
    $ ALLOCATE ...
    $ INIT ...
    $ BACKUP ...
    $ DEALLOCATE ...
    $ LOGOUT
    $!
    $ ABORT:
    $ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
    $ LOGOUT

    That's why. If the procedure is written correctly, then a human
    is notified of the inevitable problem.

    > If your housekeeper or housemate or whoever left the door unlocked
    > when he or she left, does it matter if someone robbed your house or
    > apt. as a result? I say, YES! Does it matter if you live in a high
    > crime neighborhood or not? I say, YES!


    I can only interpret that paragraph to mean that you need a reason
    to write code correctly, as otherwise it's not worth your time.
    Therefore I stand by my earlier statement of not wanting to work with
    you.

    > If you live in The Plains, OH, you don't need to put a club on your
    > steering wheel. This is not true in a big city! So don't complain
    > about the lack of a club if you live in The Plains. You didn't tell us
    > where you lived, so to speak. Yes, it's still bad programming and
    > should be fixed. How bad a disaster it was depends on what happened to
    > the tape, what was on the tape, what was missed in the thwarted backup
    > operation, and whether any backups ever succeeded at this site!


    "I didn't bother adding error handling to that code because
    I realized that it would only be a *small* disaster if it failed."

    ok
    dpm


  11. Re: despair

    On Sep 18, 8:28 am, AEF wrote:

    > If you live in The Plains, OH, you don't need to put a club on
    > your steering wheel.


    2004 Crime Statistics
    Athens County, OH
    % population affected
    Motor Vehicle Theft = 0.08%

    Given a population of 64,000 I conclude that 51 cars were
    stolen during 2004. I guess the trick is knowing whether
    or not you are one of the 63,949 people who *didn't* need
    to put a club on their steering wheel!

    Another way to look at it is if you're running that batch job
    every night on three nodes, your tolerance is having it fail
    once per year. It's good to know your limits.

    ok
    dpm


  12. Re: despair

    On Sep 18, 8:28 am, AEF wrote:

    > If you live in The Plains, OH, you don't need to put a club on
    > your steering wheel.


    2004 Crime Statistics
    Athens County, OH
    % population affected
    Motor Vehicle Theft = 0.08%

    Given a population of 64,000 I conclude that 51 cars were
    stolen during 2004. I guess the trick is knowing whether
    or not you are one of the 63,949 people who *didn't* need
    to put a club on their steering wheel!

    Another way to look at it is if you're running that batch job
    every night on three nodes, your tolerance is having it fail
    once per year. It's good to know your limits.

    ok
    dpm


  13. Re: despair

    On Sep 18, 9:19 am, "David P. Murphy" wrote:
    > On Sep 18, 8:28 am, AEF wrote:
    >
    > > I meant the fact that you didn't tell us that there was a problem.
    > > IOW, I was referring to all the error messages, not just the last few
    > > error messages.

    >
    > Surely an experienced person such as yourself saw them coming.


    Yes, but what actually happens matters.

    > > It seems to me that it was mostly the result of someone having used
    > > the tape drive he shouldn't have, which, because even if the procedure
    > > were written correctly the backup still would not have been done,
    > > suggests that this ON ERROR THEN CONTINUE is not the biggest problem
    > > at your site!

    >
    > > What does it matter?

    >
    > $ ON WARNING THEN GOTO ABORT
    > $ ALLOCATE ...
    > $ INIT ...
    > $ BACKUP ...
    > $ DEALLOCATE ...
    > $ LOGOUT
    > $!
    > $ ABORT:
    > $ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
    > $ LOGOUT
    >
    > That's why. If the procedure is written correctly, then a human
    > is notified of the inevitable problem.


    Based on what we know about your site, no one would have ever read the
    mail. The problem at your site is primarily something that is not
    curable by even the best code. And even if an operator did read it, at
    this site he or she probably would ignore it.

    > > If your housekeeper or housemate or whoever left the door unlocked
    > > when he or she left, does it matter if someone robbed your house or
    > > apt. as a result? I say, YES! Does it matter if you live in a high
    > > crime neighborhood or not? I say, YES!

    >
    > I can only interpret that paragraph to mean that you need a reason
    > to write code correctly, as otherwise it's not worth your time.


    You don't get it.

    > Therefore I stand by my earlier statement of not wanting to work with
    > you.


    I'm puzzled by this statement. It is not a logical conclusion based on
    our discussion.

    Regardless, you need to take an economics course. You do what it's
    worth to do. Would you spend thousands of dollars in protection and
    insurance to safeguard a thirty-dollar blender? I think not!

    >
    > > If you live in The Plains, OH, you don't need to put a club on your
    > > steering wheel. This is not true in a big city! So don't complain
    > > about the lack of a club if you live in The Plains. You didn't tell us
    > > where you lived, so to speak. Yes, it's still bad programming and
    > > should be fixed. How bad a disaster it was depends on what happened to
    > > the tape, what was on the tape, what was missed in the thwarted backup
    > > operation, and whether any backups ever succeeded at this site!

    >
    > "I didn't bother adding error handling to that code because
    > I realized that it would only be a *small* disaster if it failed."


    You missed the point, you still don't get it, and you'll never get
    it.

    Let me know how it goes when you put that bank-safe-door-lock on your
    bathroom, and its effect on your net worth!

    >
    > ok
    > dpm


    AEF


  14. Re: despair

    On Sep 18, 9:51 am, AEF wrote:

    >> Surely an experienced person such as yourself saw them coming.


    > Yes, but what actually happens matters.


    No, actually, it does not. What matters _when you're coding_
    is the *potential* of what *might* happen. A good programmer
    assumes that problems will occur. Whether or not they ever do
    is completely beside the point.

    > Regardless, you need to take an economics course. You do what it's
    > worth to do. Would you spend thousands of dollars in protection and
    > insurance to safeguard a thirty-dollar blender? I think not!


    You are saying that a backup procedure might not be worth
    the time it takes to add a few lines of code for error handling.
    I'm saying the question should never even arise.

    Why you are valuing a backup at $30 while valuing a few lines
    of code at > $2000 is beyond me.

    ok
    dpm


  15. Re: despair

    On Sep 18, 10:12 am, "David P. Murphy" wrote:
    > On Sep 18, 9:51 am, AEF wrote:
    >
    > >> Surely an experienced person such as yourself saw them coming.

    > > Yes, but what actually happens matters.

    >
    > No, actually, it does not. What matters _when you're coding_
    > is the *potential* of what *might* happen. A good programmer
    > assumes that problems will occur. Whether or not they ever do
    > is completely beside the point.


    How upset you get about it, is.

    And when no one reads the mail, what good has it done? This is the
    second time I've had to make this point.

    >
    > > Regardless, you need to take an economics course. You do what it's
    > > worth to do. Would you spend thousands of dollars in protection and
    > > insurance to safeguard a thirty-dollar blender? I think not!

    >
    > You are saying that a backup procedure might not be worth
    > the time it takes to add a few lines of code for error handling.
    > I'm saying the question should never even arise.


    I said it was bad code. I said to fix the bloody code. What more do
    you want?

    And something _did_ go wrong and it's not the end of the world. So
    relax already. No one really seems to care at your site.

    > Why you are valuing a backup at $30 while valuing a few lines
    > of code at > $2000 is beyond me.


    I was giving a hypothetical example for the general case because it
    seemed to me you were arguing to actually do silly things like that,
    in general.

    > ok
    > dpm


    Not ok. :-)
    AEF


  16. Re: despair

    On Sep 18, 9:33 am, "David P. Murphy" wrote:
    > On Sep 18, 8:28 am, AEF wrote:
    >
    > > If you live in The Plains, OH, you don't need to put a club on
    > > your steering wheel.

    >
    > 2004 Crime Statistics
    > Athens County, OH
    > % population affected
    > Motor Vehicle Theft = 0.08%
    >
    > Given a population of 64,000 I conclude that 51 cars were
    > stolen during 2004. I guess the trick is knowing whether
    > or not you are one of the 63,949 people who *didn't* need
    > to put a club on their steering wheel!


    And how many of these stolen cars were in The Plains? Is your car even
    something worth stealing? Etc., etc.

    At these odds I'd rather not bother with the Club.

    Do you carry a gun around to protect yourself from being mugged? How
    do you know you're one of the lucky people who won't get mugged? Are
    you protecting yourself from Al Qaeda? Did you write some code for
    that? ;-)

    Etc.

    There is such a thing as cost-benefit analysis. With the odds you gave
    for Athens county, I'd pass on the Club.

    There is always risk, and you do what's reasonable given the case. In
    your case, I'd tell mgmt. that the code needs to be fixed and, perhaps
    more importantly, some data center rules need to be rewritten or
    enforced or whatever it takes to stop people from loading their
    personal tapes into the drive used for system backups.

    > Another way to look at it is if you're running that batch job
    > every night on three nodes, your tolerance is having it fail
    > once per year. It's good to know your limits.


    And one failed backup a year is a disaster? It in part depends on what
    you're backing up. Apparently, at your place, a nightly failure is
    acceptable. If a once-a-year backup failure is a disaster at your
    site, you need to do a hell of a lot more than what you did in your
    posted fixed-up example!!! Could it be, like at my site, that the most
    critical files are separately copied to another system far away in
    case of backup failure or disaster so that the tape backup is partly
    just a precaution?

    At your place, fixing the code will still not fix the problem. You
    should be more concerned about that. You're being penny-wise and pound-
    foolish.

    > ok
    > dpm


    AEF


  17. Re: despair

    On Sep 18, 9:19 am, "David P. Murphy" wrote:
    > On Sep 18, 8:28 am, AEF wrote:
    >
    > > I meant the fact that you didn't tell us that there was a problem.
    > > IOW, I was referring to all the error messages, not just the last few
    > > error messages.

    >
    > Surely an experienced person such as yourself saw them coming.
    >
    > > It seems to me that it was mostly the result of someone having used
    > > the tape drive he shouldn't have, which, because even if the procedure
    > > were written correctly the backup still would not have been done,
    > > suggests that this ON ERROR THEN CONTINUE is not the biggest problem
    > > at your site!

    >
    > > What does it matter?

    >
    > $ ON WARNING THEN GOTO ABORT
    > $ ALLOCATE ...
    > $ INIT ...
    > $ BACKUP ...
    > $ DEALLOCATE ...
    > $ LOGOUT
    > $!
    > $ ABORT:
    > $ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
    > $ LOGOUT
    >
    > That's why. If the procedure is written correctly, then a human
    > is notified of the inevitable problem.


    This code doesn't even meet your own standards. Suppose MAIL fails.
    Then it will go to the ABORT label and run MAIL again. In that case,
    you'll be depending on the default error handler, ON ERROR THEN EXIT,
    which will finally end it, and you'll be depending on LOGINOUT.EXE to
    deallocate your drive.

    And where is your cleanup! You didn't check if the drive is allocated
    in the ABORT section, so again(!) you're depending on LOGOUT to
    deallocate your drive. Horrors!

    [...]

    > I didn't bother adding error handling to that code because
    > I realized that it would only be a *small* disaster if it failed."


    If the result with correct programming is the same as with bad
    programming, what does it matter? You should still fix the code and
    fix the operations staff. Both need to be fixed in your case.

    I SAID TO FIX THE BLOODY CODE. HOW MANY TIMES DO I HAVE TO SAY THIS.
    AND WARNING, I'VE GOT A LOT MORE UPPER CASE LETTERS IN MY ARSENEL.
    ALMOST UNLIMITED, IN FACT! AND FIXING THE CODE STILL DOESN'T GET YOUR
    BACKUP DONE IF SOME FOOL IS USING THE DRIVE TO BACKUP HIS STUPID VIDEO
    GAMES OR WHAT NOT DURING SYSTEM-BACKUP TIME.

    Besides, he did have error handling code: ON ERROR THEN CONTINUE. Yes,
    it's bad, but it's still error handling. And I suspect that whoever
    put it there thought it would act more like SET NOON.

    [...]

    > ok
    > dpm




  18. Re: despair

    In article <1190128284.178297.247170@e34g2000pro.googlegroups. com>,
    AEF writes:
    > On Sep 18, 9:19 am, "David P. Murphy" wrote:
    >> On Sep 18, 8:28 am, AEF wrote:
    >>
    >> > I meant the fact that you didn't tell us that there was a problem.
    >> > IOW, I was referring to all the error messages, not just the last few
    >> > error messages.

    >>
    >> Surely an experienced person such as yourself saw them coming.
    >>
    >> > It seems to me that it was mostly the result of someone having used
    >> > the tape drive he shouldn't have, which, because even if the procedure
    >> > were written correctly the backup still would not have been done,
    >> > suggests that this ON ERROR THEN CONTINUE is not the biggest problem
    >> > at your site!

    >>
    >> > What does it matter?

    >>
    >> $ ON WARNING THEN GOTO ABORT
    >> $ ALLOCATE ...
    >> $ INIT ...
    >> $ BACKUP ...
    >> $ DEALLOCATE ...
    >> $ LOGOUT
    >> $!
    >> $ ABORT:
    >> $ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
    >> $ LOGOUT
    >>
    >> That's why. If the procedure is written correctly, then a human
    >> is notified of the inevitable problem.

    >
    > This code doesn't even meet your own standards. Suppose MAIL fails.
    > Then it will go to the ABORT label and run MAIL again. In that case,
    > you'll be depending on the default error handler, ON ERROR THEN EXIT,
    > which will finally end it, and you'll be depending on LOGINOUT.EXE to
    > deallocate your drive.
    >
    > And where is your cleanup! You didn't check if the drive is allocated
    > in the ABORT section, so again(!) you're depending on LOGOUT to
    > deallocate your drive. Horrors!
    >
    > [...]
    >
    >> I didn't bother adding error handling to that code because
    >> I realized that it would only be a *small* disaster if it failed."

    >
    > If the result with correct programming is the same as with bad
    > programming, what does it matter? You should still fix the code and
    > fix the operations staff. Both need to be fixed in your case.
    >
    > I SAID TO FIX THE BLOODY CODE. HOW MANY TIMES DO I HAVE TO SAY THIS.
    > AND WARNING, I'VE GOT A LOT MORE UPPER CASE LETTERS IN MY ARSENEL.
    > ALMOST UNLIMITED, IN FACT! AND FIXING THE CODE STILL DOESN'T GET YOUR
    > BACKUP DONE IF SOME FOOL IS USING THE DRIVE TO BACKUP HIS STUPID VIDEO
    > GAMES OR WHAT NOT DURING SYSTEM-BACKUP TIME.
    >
    > Besides, he did have error handling code: ON ERROR THEN CONTINUE. Yes,
    > it's bad, but it's still error handling. And I suspect that whoever
    > put it there thought it would act more like SET NOON.
    >


    Grampa, tell me again about how bad all Unix programmers were and how
    great all VMS programmers were. :-)


    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  19. Re: despair

    In article <1190128284.178297.247170@e34g2000pro.googlegroups. com>, AEF writes:
    >
    > This code doesn't even meet your own standards. Suppose MAIL fails.
    > Then it will go to the ABORT label and run MAIL again. In that case,
    > you'll be depending on the default error handler, ON ERROR THEN EXIT,
    > which will finally end it, and you'll be depending on LOGINOUT.EXE to
    > deallocate your drive.


    No it won't. The "ON" statement is good once, after which a failure
    of MAIL would follow default behaviour. Since he isn't showing any
    other path to the MAIL statement there can be no loop in the code
    he's shown.


  20. Re: despair

    On Sep 18, 1:14 pm, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article <1190128284.178297.247...@e34g2000pro.googlegroups. com>, AEF writes:
    >
    >
    >
    > > This code doesn't even meet your own standards. Suppose MAIL fails.
    > > Then it will go to the ABORT label and run MAIL again. In that case,
    > > you'll be depending on the default error handler, ON ERROR THEN EXIT,
    > > which will finally end it, and you'll be depending on LOGINOUT.EXE to
    > > deallocate your drive.

    >
    > No it won't. The "ON" statement is good once, after which a failure
    > of MAIL would follow default behaviour. Since he isn't showing any
    > other path to the MAIL statement there can be no loop in the code
    > he's shown.


    Yeah, you're right. I posted in haste and waste. (Thanks for the
    catch!)

    But it still won't deallocate or dismount his tape if needed. And he
    made a BIG FUSS over not depending on LOGOUT to deallocate your drive.
    And he has no DISMOUNT command whatsoever. And he's depending on
    BACKUP to MOUNT the tape, most or all of which are big no-no's
    according to Mr. Murphy.

    AEF


+ Reply to Thread
Page 3 of 11 FirstFirst 1 2 3 4 5 ... LastLast