despair - VMS

This is a discussion on despair - VMS ; On Sep 15, 10:39 am, AEF wrote: > Please tell me what error from the ALLOCATE command would screw things > up and how. True, attempting to allocate an already-owned device results in a warning. Clearly, instead of $ ON ...

+ Reply to Thread
Page 2 of 11 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 219

Thread: despair

  1. Re: despair

    On Sep 15, 10:39 am, AEF wrote:

    > Please tell me what error from the ALLOCATE command would screw things
    > up and how.


    True, attempting to allocate an already-owned device results in a
    warning. Clearly, instead of
    $ ON ERROR THEN CONTINUE
    the handler should state
    $ ON WARNING THEN GOTO ABORT_THIS_JOB

    > What error from INIT would screw things up? My experience is that when
    > INIT fails, it's an F error.


    Obviously, the message is
    %SYSTEM-F-DEVMOUNT, device is already mounted
    and, has been pointed out to you already, a severe error (-F-) will be
    trapped by an ON ERROR handler.

    > Relax, dude! The world is not going to end because of this command
    > procedure.


    I never said that. It's wrong, and your slacker attitude is exactly
    why it's wrong. Who are you to _not_ do your best work? You clearly
    have a decent grasp on this subject, yet you're trying to argue that
    it makes a difference whether the tapes get changed daily. WHAT THE
    HELL DOES THAT MATTER? It's a command procedure and should be written
    as best you can, in anticipation of things going wrong, because things
    *will* go wrong. I'm not talking about wild, extremely unlikely acts.
    I'm talking about "someone left the wrong tape in" or "someone else is
    using the drive and in fact allocated it" or "someone else is the
    operator now and is using the tape drive in a different manner than
    when this command procedure was coded". I'm upset that someone could
    have written this correctly but didn't, because there's no excuse.

    I'm not going to relax. I'm going to educate, if the culprit is
    willing to learn, or rant, if he is not. I've seen too much sloth
    and ignorance over the years to be complacent about it.

    >>> Maybe it was written by a BOFH!


    >> Nah, the Bastard always knows exactly what he's doing.


    > Sorry, I disagree or missed your point (about BOFH).


    Then you aren't very familiar with him. His competence is very high.

    > I find it interesting that you get all upset over this code snippet
    > yet you can't even tell me if the tape is changed daily! You appear to
    > know nothing at all about this environment except this code snippet.


    I fail to see how that matters in regard to the quality of this code.
    Nothing you can learn about the environment can justify that mistake.

    > How did you come across this code in the first place? What is your
    > role at this place that you have access to this code but still don't
    > know if the tape is ever changed?


    Because I saw this in the logfile:

    %SYSTEM-W-DEVALLOC, device already allocated to another user

    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

    I certainly hope you do not regard this as an acceptable outcome.
    I certainly hope you agree that the INIT and BACKUP commands should
    not have been executed at all.

    > At my current job no one but me loads tapes. No one but me uses DCL on
    > the system. The tape drives are in the data center which is locked.
    > Only people who need access to the room are allowed in. So a command
    > procedure that would be okay at my site would not be okay at others.


    Well I think it's safe to say that my site is not as self-contained
    as yours, because the "impossible" did in fact happen. Good luck to
    you and your co-workers when it happens to you.

    > For example, you complained that the code didn't have a DEALLOCATE
    > command. Why is this a big problem? Could it not be, maybe, that no
    > one else ever uses this tape drive, in which case the lack of a
    > DEALLOCATE command is not a problem?


    Because it's simple decent programming. You allocate a resource, you
    deallocate it when you're done. You open a file, you close the file.
    You reserve an event flag, you free the event flag. You release the
    virtual memory you've grabbed when you're through with it. You don't
    *rely* on the operating system to do it for you via LOGINOUT.EXE.
    Why do I have to explain this to you?

    Nothing personal, since I have no idea who you are, but I wouldn't
    want you near any code I'm involved in, if you have such a slacker
    attitude towards cleaning up. You either have good habits or you're
    going to screw up . . . and from the number of posts I've seen from
    you
    arguing this point, I'm afraid it's the latter.

    ok
    dpm


  2. Re: despair

    On 09/15/07 21:47, David P. Murphy wrote:
    [snip]
    >
    > Because it's simple decent programming. You allocate a resource, you
    > deallocate it when you're done. You open a file, you close the file.
    > You reserve an event flag, you free the event flag. You release the
    > virtual memory you've grabbed when you're through with it. You don't
    > *rely* on the operating system to do it for you via LOGINOUT.EXE.
    > Why do I have to explain this to you?


    I totally agree with you about the badness of slacker programming.

    However... why shouldn't I rely on LOGINOUT.EXE to deallocate my
    tape drives or free my VM? (Note that I did not comment on your
    other examples.)

    --
    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!

  3. Re: despair

    Ron Johnson wrote:
    > On 09/15/07 21:47, David P. Murphy wrote:
    > [snip]
    >
    >>Because it's simple decent programming. You allocate a resource, you
    >>deallocate it when you're done. You open a file, you close the file.
    >>You reserve an event flag, you free the event flag. You release the
    >>virtual memory you've grabbed when you're through with it. You don't
    >>*rely* on the operating system to do it for you via LOGINOUT.EXE.
    >>Why do I have to explain this to you?

    >
    >
    > I totally agree with you about the badness of slacker programming.
    >
    > However... why shouldn't I rely on LOGINOUT.EXE to deallocate my
    > tape drives or free my VM? (Note that I did not comment on your
    > other examples.)
    >


    Suppose your process hangs somewhere before it gets to LOGINOUT.EXE.
    Now it's sitting there, tying up resources needed by others. If you're
    lucky somebody can kill your process. If you are NOT so lucky, your
    process may require a "big red switch reset" and reboot. I believe that
    this situation is less common now than it used to be but I doubt if it
    has vanished completely.


  4. Re: despair

    On 09/16/07 01:59, Richard B. Gilbert wrote:
    > Ron Johnson wrote:
    >> On 09/15/07 21:47, David P. Murphy wrote:
    >> [snip]
    >>
    >>> Because it's simple decent programming. You allocate a resource, you
    >>> deallocate it when you're done. You open a file, you close the file.
    >>> You reserve an event flag, you free the event flag. You release the
    >>> virtual memory you've grabbed when you're through with it. You don't
    >>> *rely* on the operating system to do it for you via LOGINOUT.EXE.
    >>> Why do I have to explain this to you?

    >>
    >>
    >> I totally agree with you about the badness of slacker programming.
    >>
    >> However... why shouldn't I rely on LOGINOUT.EXE to deallocate my
    >> tape drives or free my VM? (Note that I did not comment on your
    >> other examples.)
    >>

    >
    > Suppose your process hangs somewhere before it gets to LOGINOUT.EXE. Now
    > it's sitting there, tying up resources needed by others. If you're


    If DEALLOCATE is the last thing my script does...

    Obviously I'd use DEALLOC in a very complex script that does a lot
    of stuff after it's finished with the tape drives, but in reality
    I'd probably split that kind of huge job into multiple pieces and
    have SCHEDULER pre- and post-dependencies handle it all.

    > lucky somebody can kill your process. If you are NOT so lucky, your
    > process may require a "big red switch reset" and reboot. I believe that
    > this situation is less common now than it used to be but I doubt if it
    > has vanished completely.


    In my experience, if a tape drive or mini-library confuses VMS, then
    it (either the drive, mini-library or Alpha or some combination
    thereof) needs to get bounced. DEALLOC won't help.

    --
    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

    On Sep 15, 10:47 pm, "David P. Murphy" wrote:
    > On Sep 15, 10:39 am, AEF wrote:
    >
    > > Please tell me what error from the ALLOCATE command would screw things
    > > up and how.

    >
    > True, attempting to allocate an already-owned device results in a
    > warning. Clearly, instead of
    > $ ON ERROR THEN CONTINUE
    > the handler should state
    > $ ON WARNING THEN GOTO ABORT_THIS_JOB


    So why don't you ask why the ALLOCATE command only gives a W when it
    fails?

    > > What error from INIT would screw things up? My experience is that when
    > > INIT fails, it's an F error.

    >
    > Obviously, the message is
    > %SYSTEM-F-DEVMOUNT, device is already mounted
    > and, has been pointed out to you already, a severe error (-F-) will be
    > trapped by an ON ERROR handler.


    Obviously you've never worked with 4mm DAT drives! I've seen more
    interesting fatal errors, like "fatal controller error", e.g., due to
    the drive having gone bad.

    ON ERROR THEN CONTINUE is a rather odd command.

    Yes, I realized the code was bad. I even said so. But I could envision
    circumstances in which it would not cause a problem. If only the
    system manager loaded tapes, there'd be no problem. Yes, if I were to
    come across code like this I'd fix it if I had the time. But keep in
    mind that many IT shops are undermanned and many admins have to work
    with multiple OSes and are probably reasonably competent in only one
    or two of them.

    I was trying to come up with reasons for what looks to me like a quick
    and dirty fix. Maybe the person didn't have more time to spend on the
    code. Maybe this _was_ the best he could do. Maybe not. I just don't
    like it when people like you are so quick to blame someone without
    knowing all the facts.

    Maybe the author was a VMS novice. You can't expect someone to be an
    expert from day 1.

    > > Relax, dude! The world is not going to end because of this command
    > > procedure.

    >
    > I never said that. It's wrong, and your slacker attitude is exactly
    > why it's wrong. Who are you to _not_ do your best work?


    Hey, *I* didn't write that code snippet. I also clearly stated in my
    previous posts in this thread that I didn't recommend that style of
    code-writing. I just didn't see it as worth getting so upset over.

    I do not have a slacker attitude. Stop accusing me of things I am not
    guilty of.

    And how do you know it wasn't that person's best work? Maybe he was a
    VMS novice. Maybe he was a Unix admin who knew very little VMS. You're
    very quick to make assumptions. And you know the old joke about
    ASSUME, right?

    Are you really surprised that some people do shoddy work? There are
    people who commit crimes! Murder even!!! And you're surprised by an ON
    ERROR THEN CONTINUE in such a screwy way? :-) Is this the first time
    in your life that you've come across shoddy workmanship?

    Millions of people of suffered horribly and/or have been murdered
    because of evil people and this continues to this day. And to you this
    is apparently not a problem. But someone writes some crappy code that
    possibly overwrites a tape and/or fails to make a backup of stuff that
    may be of little importance and suddenly you lose faith in humanity!
    Please, have some perspective.

    > You clearly
    > have a decent grasp on this subject, yet you're trying to argue that
    > it makes a difference whether the tapes get changed daily. WHAT THE
    > HELL DOES THAT MATTER?


    I already answered this in a previous post. The difference is n-1
    tapes, some of which may be offsite. I'd say that's a considerably
    better situation than if the same tape were in the drive all the time.
    Also, if the same tape were in the drive all the time, the problem you
    found in the log file wouldn't have happened!!! :-)

    No, it doesn't make the code any better, but I was curious, so I
    asked. Is that so terrible?

    > It's a command procedure and should be written
    > as best you can, in anticipation of things going wrong, because things
    > *will* go wrong. I'm not talking about wild, extremely unlikely acts.


    Lots of things "should be". Is this the first time you've come across
    something that wasn't as it "should be"? Have you never worked on a
    computer running Windows?

    You do what's appropriate for the job at hand. You don't spend
    millions of dollars to prevent problems that will cost only thousands.
    Everything we do is an economic decision. Is it worth an hour's sleep
    to run out to the store at bedtime and get eggs for breakfast? Is it
    worth taking the car to go only n blocks? Is it worth it to buy an
    extended warranty on this product I just bought (usually not!). Is it
    worth doing more on this code? At some point it won't be, but that
    depends what the purposes of the system, apps, etc., are. You don't
    build a nuclear containment dome for your washing machine.

    > I'm talking about "someone left the wrong tape in" or "someone else is
    > using the drive and in fact allocated it" or "someone else is the
    > operator now and is using the tape drive in a different manner than
    > when this command procedure was coded". I'm upset that someone could
    > have written this correctly but didn't, because there's no excuse.


    How do you know the person could have written it correctly?

    Using the tape drive in what different manner? You have a daily job
    and you change the tapes once a day. If the job is not unloading the
    tape at exit, that's a problem in and of itself.

    > I'm not going to relax. I'm going to educate, if the culprit is
    > willing to learn, or rant, if he is not. I've seen too much sloth
    > and ignorance over the years to be complacent about it.


    I didn't say be complacent. I said not to overreact.

    > >>> Maybe it was written by a BOFH!
    > >> Nah, the Bastard always knows exactly what he's doing.

    > > Sorry, I disagree or missed your point (about BOFH).

    >
    > Then you aren't very familiar with him. His competence is very high.


    Hmmmm. Two jobs ago I worked with an operator and he once screwed
    things up through incompetence and disobedience. His intent was noble:
    He thought that if he just did all the steps quickly enough the job we
    told him not to run that evening would finish by morning before the
    users needed the system. Of course the job ran a few hours over the
    following day's start time, and we just had to wait for it to complete
    before opening the system to the end users (who used the system to
    take orders for products over the phone). I guess that's not a BOFH,
    but that's what I was thinking of. (Normally this job would finish on
    time, but the DBA and I knew that this particular day -- for some
    reason I don't remember -- would without any doubt not finish anywhere
    near on time. We explained this to the evening operator that but he
    didn't listen.)

    > > I find it interesting that you get all upset over this code snippet
    > > yet you can't even tell me if the tape is changed daily! You appear to
    > > know nothing at all about this environment except this code snippet.

    >
    > I fail to see how that matters in regard to the quality of this code.
    > Nothing you can learn about the environment can justify that mistake.


    Because (in addition to what I've already said) *IN GENERAL* it makes
    sense not to greatly exceed the effort really needed for the job.
    Apparently you feel that this code is a catastrophe even if unused.
    OK. I'll accept that.

    Example: You don't use an egg carton to ship 12 screws. You don't put
    a bank-safe-quality combination lock and door on your bathroom -- a
    simple cheap doorknob lock and plain wooden door will suffice.

    My point was that you do what's appropriate for the situation. Are you
    playing stupid video games or running a nuclear power plant? I say
    that makes a difference.

    > > How did you come across this code in the first place? What is your
    > > role at this place that you have access to this code but still don't
    > > know if the tape is ever changed?

    >
    > Because I saw this in the logfile:
    >
    > %SYSTEM-W-DEVALLOC, device already allocated to another user


    Hmmm. Why does this only get a warning? Shouldn't it be fatal, or at
    least a regular error? Where's your outrage over this?!

    > 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..."

    > I certainly hope you do not regard this as an acceptable outcome.


    Nope.

    > I certainly hope you agree that the INIT and BACKUP commands should
    > not have been executed at all.


    Yep.

    But why was someone else's tape in the drive during backup time? Maybe
    he deserves to have his tape overwritten! ;-)

    I certainly hope you agree that there shouldn't have been someone
    else's tape in the drive during backup time.

    > > At my current job no one but me loads tapes. No one but me uses DCL on
    > > the system. The tape drives are in the data center which is locked.
    > > Only people who need access to the room are allowed in. So a command
    > > procedure that would be okay at my site would not be okay at others.

    >
    > Well I think it's safe to say that my site is not as self-contained
    > as yours, because the "impossible" did in fact happen. Good luck to
    > you and your co-workers when it happens to you.


    I've been at my current job for 7 years and have been a VMS admin for
    13 years and have not had any problems like this. I don't write code
    like this. I did inheret some code I wasn't happy with, and I fixed
    what I could with what time I had (what I could get authorized by
    management to do) and things have been okay. My primary problems (with
    my VMS systems and apps) at my current job have been with network hits
    and outages, and hardware failures. I do the best I can given the
    constraints I have to work under (I have a fair amount of non-VMS work
    to do, e.g.)

    I've had plenty of problems with my 4mm DAT drives, none of them due
    to bad code or bad users.

    I don't run code like your example and I don't write code like your
    example. You're clearly not reading my posts very carefully and now
    unfairly accuse me of wrongdoing. If I were in your position I'd fix
    the code. But if no one else put tapes in the drive, your error
    scenario wouldn't have happened.

    So you're there now, you've found a problem, so fix it and be done
    with it!!!

    > > For example, you complained that the code didn't have a DEALLOCATE
    > > command. Why is this a big problem? Could it not be, maybe, that no
    > > one else ever uses this tape drive, in which case the lack of a
    > > DEALLOCATE command is not a problem?

    >
    > Because it's simple decent programming. You allocate a resource, you
    > deallocate it when you're done. You open a file, you close the file.


    When I write code I do exactly these things. I this, I unthis. I that,
    I unthat. Again, maybe the author of your bad code snippet was a
    novice and simply didn't know better.

    > You reserve an event flag, you free the event flag. You release the
    > virtual memory you've grabbed when you're through with it. You don't
    > *rely* on the operating system to do it for you via LOGINOUT.EXE.
    > Why do I have to explain this to you?


    Because you didn't read my posts carefully in which I clearly said I
    don't recommend and don't write code like that. I think this is the
    4th or 5th time I've had to mention this. Why do I have to explain
    this to you over and over again?

    Also, I follow the organized error and control-y handling method given
    in "Writing Real Programs In DCL" which includes clean-up, which I was
    actually drifting towards before I read the book.

    I do what's appropriate for the job at hand. I take all reasonable
    precautions.

    > Nothing personal, since I have no idea who you are, but I wouldn't
    > want you near any code I'm involved in, if you have such a slacker
    > attitude towards cleaning up. You either have good habits or you're
    > going to screw up . . . and from the number of posts I've seen from
    > you
    > arguing this point, I'm afraid it's the latter.


    And I wouldn't want to hire someone who jumps to conclusions like you
    do!

    I'm afraid you're mistaken. If you look at my other posts over the
    years or look at some of my code, you will see.

    Please stop accusing me of wrongdoing I am not guilty of.

    I'm not religious, but I do have a favorite "prayer":

    O Great Spirit, may I not criticize my neighbor until I have walked a
    mile in his moccasins. (Another version says "two weeks in his
    moccasins".)

    > ok
    > dpm


    AEF


  6. Re: despair

    In article <1189821464.805918.183330@50g2000hsm.googlegroups.c om>,
    "David P. Murphy" wrote:

    > On Sep 14, 1:40 pm, AEF wrote:
    >
    > > So the author of this bad code was apparently only worried about show-
    > > stoppers.

    >
    > I beg to differ. Anytime you code
    >
    > $ ON ERROR THEN CONTINUE
    >
    > in front of a ALLOCATE command, that is just plain wrong. No debate.
    > Your arguments seem to hold water only as far as error trapping the
    > outcome of the BACKUP command, but this lies before the INITIALIZE
    > and ALLOCATE as well as the BACKUP. Guilty, guilty, guilty.
    >
    > > I'm not recommending this way of doing things; I'm just
    > > trying to explain what I think the motivating factors were.
    > > Of course incompetence and not-giving-a-s%%% are other possible
    > > reasons!

    >
    > I'm going with "stupidity" here. Truly, a little knowledge can be
    > a very dangerous thing.
    >
    > > Maybe it was written by a BOFH!

    >
    > Nah, the Bastard always knows exactly what he's doing.
    >


    I think the Bastard could think of a way to use it to his advantage
    though. :_)

    --
    Paul Sture

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

  7. Re: despair

    On Sep 14, 8:57 pm, "David P. Murphy" wrote:
    > On Sep 14, 1:40 pm, AEF wrote:
    >
    > > So the author of this bad code was apparently only worried about show-
    > > stoppers.

    >
    > I beg to differ. Anytime you code
    >
    > $ ON ERROR THEN CONTINUE
    >
    > in front of a ALLOCATE command, that is just plain wrong. No debate.
    > Your arguments seem to hold water only as far as error trapping the
    > outcome of the BACKUP command, but this lies before the INITIALIZE
    > and ALLOCATE as well as the BACKUP. Guilty, guilty, guilty.
    >
    > > I'm not recommending this way of doing things; I'm just
    > > trying to explain what I think the motivating factors were.
    > > Of course incompetence and not-giving-a-s%%% are other possible
    > > reasons!

    >
    > I'm going with "stupidity" here. Truly, a little knowledge can be
    > a very dangerous thing.
    >
    > > Maybe it was written by a BOFH!

    >
    > Nah, the Bastard always knows exactly what he's doing.
    >


    Reminds me of one of those quick & dirty little things done for
    testing or for "personal use", or like that program you threw together
    in 10 minutes for some little thing the Comptroller was "just curious
    about" -- everything hard-coded, no error checking, no fancy screen or
    anything -- just a one-shot deal -- you know, that dirty little bit of
    code you'd completely forgotten about and then years later you
    discover it's taken on some name like "projected cash-flow analysis"
    and it's being used to run the company and you get that lurch in the
    pit of your stomach? Or am I the only one something like that's ever
    happened to?


  8. Re: despair

    On Sep 16, 8:39 am, AEF wrote:

    > I've been at my current job for 7 years and have been a VMS admin for
    > 13 years and have not had any problems like this. I don't write code
    > like this. I did inheret some code I wasn't happy with, and I fixed
    > what I could with what time I had (what I could get authorized by
    > management to do) and things have been okay.


    Let me clear this point: I am a little upset that this code was
    written, but I am much more upset that it has been in place for
    over ten years without being corrected.

    ok
    dpm


  9. Re: despair

    On Sep 16, 8:39 am, AEF wrote:

    > So you're there now, you've found a problem, so fix it
    > and be done with it!!!


    I am not authorized to fix code without an Incident Report,
    and no one _with_ authority will sign one, because
    (altogether now) "It works fine the way it is".

    Despair.

    ok
    dpm


  10. Re: despair

    On Sep 16, 8:39 am, AEF wrote:

    > So why don't you ask why the ALLOCATE command
    > only gives a W when it fails?


    In the second place, because Digital ^W Compaq ^W HP
    isn't going to change it. In the third place, even
    if they did, it wouldn't matter to most sites for a
    long time, so you'd still have to check for W anyway.

    And in the *first* place, because W is good enough,
    either an ON WARNING beforehand or testing $STATUS after.

    ok
    dpm


  11. Re: despair

    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


  12. RE: despair



    > -----Original Message-----
    > From: David P. Murphy [mailto:dpm_google@myths.com]
    > Sent: Sunday, September 16, 2007 3:57 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: despair
    >
    > On Sep 16, 8:39 am, AEF wrote:
    >
    > > I've been at my current job for 7 years and have been a VMS admin for
    > > 13 years and have not had any problems like this. I don't write code
    > > like this. I did inheret some code I wasn't happy with, and I fixed
    > > what I could with what time I had (what I could get authorized by
    > > management to do) and things have been okay.

    >
    > Let me clear this point: I am a little upset that this code was
    > written, but I am much more upset that it has been in place for
    > over ten years without being corrected.
    >
    > ok
    > dpm


    It's a little wasteful to expend effort being irritated with that. You
    should see some of the legacy
    stuff from Mainframes. Stuff going back to 1964/1965 in some cases, and with
    the source lost for a
    couple decades or so.

    VMS is nice...

    -Paul



  13. Re: despair

    David P. Murphy wrote:
    > On Sep 16, 8:39 am, AEF wrote:
    >
    >
    >>So you're there now, you've found a problem, so fix it
    >>and be done with it!!!

    >
    >
    > I am not authorized to fix code without an Incident Report,
    > and no one _with_ authority will sign one, because
    > (altogether now) "It works fine the way it is".
    >
    > Despair.
    >
    > ok
    > dpm
    >


    Insist on a letter, signed by the "big wheel" (Manager of Information
    Technology??) stating that you will not be held responsible for the
    correct operation of this code if he will not authorize you to fix it.

    And get your resume up to date in case said "Wheel" refuses to sign such
    a thing. Keep your resume up to date even if he does sign it. It
    sounds as if the people you work for are none too bright. Management is
    seldom as smart as it ought to be but these guys fall far short of even
    that standard.


  14. Re: despair

    Richard B. Gilbert wrote:
    > Insist on a letter, signed by the "big wheel" (Manager of Information
    > Technology??) stating that you will not be held responsible for the
    > correct operation of this code if he will not authorize you to fix it.



    Ok, lets have a reality check here.

    ON ERROR THEN CONTINUE is only good for one error and only applies to DCL.

    In the end, BACKUP will fail even if a preceeding command failed and DCL
    continued onto the next instead of stopping there.

    If Allocate fails because someone else has that device, then chances are
    that INIT will also fail. And BACKUP would fail too.

    If INIT fails due to a bad tape or tape drive, BACKUP will also fail
    when it tries to mount the tape for itself.

    It may not have been good practice to put that ON ERROR there, but
    really, I don't think it would really hurt anyone, and this wouldn't be
    worth losing sleep over.

    If internal politics prevent you from improving the system, this is
    perhaps worth losing sleep over.


    The "on error" would make an important difference prior to destructive
    commands (such as DELETE) since a problem before the DELETE would still
    result in the DELETE being done.

  15. Re: despair

    "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.


    I wouldn't abandon hope just yet. Maybe a forehead slap would be in order,
    though ... or handful of headache pills...

    It's possible, given the way some folks think, that the missing pieces may be
    provided in the (BACKUP) account's LGICMD, or may be acquired through some other
    magic.

    I've seen enough "goofy stuff" that such things make me say, "Uh-oh!" and then
    go hunting for possible sources of the missing pieces.

    Some folks groove to make life interesting...

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

  16. Re: despair

    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.

    #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.

    ok
    dpm


  17. Re: despair

    On Sep 16, 4:56 pm, "David P. Murphy" wrote:
    > On Sep 16, 8:39 am, AEF wrote:
    >
    > > I've been at my current job for 7 years and have been a VMS admin for
    > > 13 years and have not had any problems like this. I don't write code
    > > like this. I did inheret some code I wasn't happy with, and I fixed
    > > what I could with what time I had (what I could get authorized by
    > > management to do) and things have been okay.

    >
    > Let me clear this point: I am a little upset that this code was
    > written, but I am much more upset that it has been in place for
    > over ten years without being corrected.
    >
    > ok
    > dpm


    Management is often hesitant to change anything. "If it ain't broke,
    don't fix it!" Well, you still have to do your periodic oil changes
    and inspections. And of course, sometimes it is "broke" even if things
    have been running smoothly for a while.

    Two jobs ago I was finding problems and struggling for permission to
    fix them. One was a DCL code snippet that one of the handover admins
    added at the last minute thinking he missed an iteration of
    calculating what day monthly reports should be scheduled for. I
    analyzed it and told mgmt that the next time such and such falls on a
    Tuesday (I think such and such was the first of the month) a repeat of
    the near disaster I saved us from from home at the last minute on a
    previous occasion would occur: the flaw would start report jobs before
    the "run commit" had finished or something like that (I don't
    presently recall the details), which would of course corrupt the
    database, resulting in the need to do a shift-long restore from 8mm
    tapes. I was told to leave it alone. Finally, several months later,
    when it was getting close to the "doomsday month", I said such and
    such will do so and so next month. Will you please let me fix it?
    Mgmt. then said yes. Our client was safe again.

    [The handover admins -- who were actually also the previous admins --
    told us that the admins prior to them told them it was too complicated
    to automate the report jobs and Run Commits and such. I guess they
    took this as a challenge and, well, missed a few things here and there
    that would only crop up later at unexpected times. Hence the illusion
    of "working system" I mention below.]

    I remember when starting this same job mgmt told me "You're getting a
    working system. Don't mess with it." (My title _was_ senior operator,
    but I did know _some_ system manager stuff at the time.) Well, I had
    to several times to save the day and prevent other fires. Another time
    the header of INDEXF.SYS filled up on an a certain critical non-
    database non-system disk. I was there at 6:30 in the morning by myself
    and I was able to determine that the system couldn't be opened for the
    end users at 7:00 a.m. because of this. I couldn't reach mgmt or the
    handover admins (who were training us on the system and app). So on my
    own initiative I copied it to tape and back. It took a long time, but
    it worked. While the restore was going, I was told I shouldn't have
    done that. I said I had no choice and I was sure it would fix the
    problem. (Well, I _did_ "cross my fingers"!) The restore completed,
    the app worked fine, and I had saved the day. One of the handover
    admins told me that whenever that happened they would archive some
    invoices. Well, I was very new to the job and didn't know about that
    manual task yet. I didn't know which files were "expendable" or
    archive-able. So I did what I thought was best. The handover admins
    who used to run the system apparently didn't know how to fix the
    dreaded HEADERFULL problem for good. (I've never had a "repacked" disk
    experience a subsequent HEADERFULL event.)

    One job ago I was pretty much given a free hand on most things but the
    boss insisted that the VAX be rebooted every Friday evening before the
    backups were run!!! He was very insistent and must have thought that
    disaster would strike if the VAX wasn't rebooted every week. They had
    always done that, I think, and were afraid to stop (this was before
    Windows took over the desktop at this place). I was told that this was
    something carried over from something with their IBM mainframe. I
    don't recall any more details. In fact, the head operator said once
    that he was worried no one could reboot the machine during Christmas
    week. I said, look, it doesn't matter. It doesn't have to be rebooted.
    I won't tell anyone. No one will know. It'll be fine. I said if the
    operator wants the time off, fine. If he wants to come in to reboot it
    to make some overtime, fine. I forget which happened, but I know at
    least once it didn't get rebooted and I finally had an uptime of over
    7 days. Of course nothing bad happened because of it.

    There are probably more similar stories I can't think of offhand. I
    feel your pain!

    BREAKING NEWS!!! or FOX NEWS ALERT!!! (imagine the FOX Gong here): I
    just thought of another disaster I saved at the two-jobs-ago job!
    Later, I've got to get back to other things. But I'll say at this
    point that it involved tape drives!!! And it was a fascinating time-
    bomb bug!!!

    Before you go blaming me for all these problems: ***I didn't write the
    code. I inherited it!*** OK?

    Back to a Paul Lynde question.

    AEF


  18. Re: despair

    On Sep 16, 5:00 pm, "David P. Murphy" wrote:
    > On Sep 16, 8:39 am, AEF wrote:
    >
    > > So you're there now, you've found a problem, so fix it
    > > and be done with it!!!

    >
    > I am not authorized to fix code without an Incident Report,
    > and no one _with_ authority will sign one, because
    > (altogether now) "It works fine the way it is".


    Been there, done that, more than once, as you can see from my last
    post.

    So please excuse me if I'm a little numb to the phenomenon.

    > Despair.


    Yeah, well...

    >
    > ok
    > dpm


    AEF


  19. Re: despair

    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!!!

    (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?

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

    >
    > #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.


    Your going to miss your train if you don't skip it and the next train
    isn't for three hours. :-)

    >
    > ok
    > dpm


    AEF


  20. Re: despair

    On Sep 16, 5:03 pm, "David P. Murphy" wrote:
    > On Sep 16, 8:39 am, AEF wrote:
    >
    > > So why don't you ask why the ALLOCATE command
    > > only gives a W when it fails?

    >
    > In the second place, because Digital ^W Compaq ^W HP
    > isn't going to change it. In the third place, even


    You're "buddy" isn't going to change your bad code snippet either. And
    now we know even you aren't going to change it due to mgmt.

    > if they did, it wouldn't matter to most sites for a
    > long time, so you'd still have to check for W anyway.
    >
    > And in the *first* place, because W is good enough,
    > either an ON WARNING beforehand or testing $STATUS after.
    >
    > ok
    > dpm


    What about the fact that

    $ DIR/VERS=2 file

    takes long enough to find, but not displya, all n versions, not just
    the first two?

    What about another resource waster:

    $ DIR:==DIR/DATE/SIZE/PROT

    $ DIR/TOTAL blah

    $ DIRECTORY/TOTAL blah

    Assuming DIRECTORY is not a symbol, if you time the two TOTAL
    commands, you'll see that the former takes a lot longer to run than
    the latter.

    Hey, as great as VMS is, it isn't perfect. And I think failure to
    allocate should AT LEAST be an E error. It clearly didn't do what you
    asked at all. How could that not be an error? A warning is for when
    what you asked was done, but something there's something you may not
    have expected that may or may not be a problem happened and you are
    being WARNED about it. I think the line between E and F is somewhat
    blurrier.

    [Maybe some of these were fixed since VMS V6.2.]

    AEF



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