despair - VMS

This is a discussion on despair - VMS ; 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. ...

+ Reply to Thread
Page 1 of 11 1 2 3 ... LastLast
Results 1 to 20 of 219

Thread: despair

  1. despair

    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


  2. Re: despair

    On 09/13/07 17:19, 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.


    Looks like a perfectly efficient way of making sure the backup
    happens...

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

    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


    wtf !? ( Worse Than Failure :^)

    Thanks David.

    not the same, but also about backups and mostly working, specifically
    while testing, todays entry on the wtf website:

    http://worsethanfailure.com/Articles...rver-Room.aspx

    Hein.



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


    It does seem a little simplistic!!!!!!!!!!!





  5. Re: despair

    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?


    AEF


  6. Re: despair

    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.

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

  7. Re: despair

    Hein RMS van den Heuvel writes:

    >not the same, but also about backups and mostly working, specifically
    >while testing, todays entry on the wtf website:


    >http://worsethanfailure.com/Articles...rver-Room.aspx


    Hah! I once had a bunch of similar stories of that type, ranging from
    'janitor-with-a-floor-buffer-unplugs-server' to real mysteries like that.
    That one was pretty good.


  8. Re: despair

    On Sep 14, 3:45 am, Ron Johnson wrote:
    > On 09/13/07 23:26, AEF wrote:


    > > Is the same tape in the drive every day?


    Don't know.

    > > Are there any more BACKUP commands in the rest of the procedure?


    No. In fact there is no DEALLOCATE command.
    Obviously the author is comfortable with letting
    the end of the job deal with cleaning up.

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


    I find it painfully ironic that the author took the mechanism
    intended for error TRAPPING and used it instead for
    error GENERATION. What the hell was he thinking?
    I'll never know.

    P.S. Excellent poster, Brian!

    ok
    dpm


  9. Re: despair

    On Sep 14, 12:46 pm, "David P. Murphy" wrote:
    > On Sep 14, 3:45 am, Ron Johnson wrote:
    >
    > > On 09/13/07 23:26, AEF wrote:
    > > > Is the same tape in the drive every day?

    >
    > Don't know.
    >
    > > > Are there any more BACKUP commands in the rest of the procedure?

    >
    > No. In fact there is no DEALLOCATE command.
    > Obviously the author is comfortable with letting
    > the end of the job deal with cleaning up.
    >
    > > Does it matter? Defensive programming says you defend against
    > > hardware glitches other people's mistakes.\


    Yes. If the tape is never changed, you only have one backup at any
    given time and it's on-site. If n tapes are rotated, you have n
    backups, some of which may be offsite. What's the difference? n-1, of
    course! :-)

    > I find it painfully ironic that the author took the mechanism
    > intended for error TRAPPING and used it instead for
    > error GENERATION. What the hell was he thinking?
    > I'll never know.


    I find that BACKUP is very good at assigning W, E, and F to various
    errors.

    W is for errors like warning about files open for write that are being
    saved anyway because of use of /IGNORE=INTERLOCK. Of course these
    would be ignored by the default DCL error handler, (but I usually use
    ON WARNING THEN GOTO _ERROR and make exceptions where needed).

    E is for errors like files open for write and not saved, and
    verification errors. (If you have to do a hot backup, you will likely
    get a few spurious verification errors. The result is that the save
    set is most likely okay. Of course, depending on this code snippet
    (if /VERIFY were added to it) to ignore it is very risky as you might
    get much more than the few verification errors expected on a hot
    backup which may truly mean the save set you just made is truly
    corrupted. Of course there's still some risk even with just a few
    errors -- what to do depends on the situation. Someone needs to
    inspect the log files in this case.

    F is for truly fatal errors that are usually real show-stoppers.
    Examples: not being able to write to tape, not being able to read the
    tape during a verify pass, controller errors, parity errors, not being
    able to write a file mark on tape, etc.

    So the author of this bad code was apparently only worried about show-
    stoppers. Probably he experienced errors due to files open for write
    access and wanted the rest of the procedure to continue anyway (either
    because he didn't realize the files weren't being saved or because
    those files were not important to save), and this was the most
    expedient way to deal with it. 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! Maybe it was written by a BOFH!

    >
    > P.S. Excellent poster, Brian!
    >
    > ok
    > dpm


    AEF


  10. Re: despair

    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.

    ok
    dpm


  11. Re: despair

    On Sep 14, 9: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.


    Please forgive me if I'm being obtuse on this. That said...

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

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


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

    Relax, dude! The world is not going to end because of this command
    procedure. Besides, that's only two "guilty"s. :-)

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


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

    >
    > ok
    > dpm


    All right. First: Never say never! OK. Next...

    Only once did I ever have a problem from "misuse" (actually, in this
    case, non-use) of ALLOCATE. It was in 1988 when I was a (rather
    inexperienced -- well let's say, non-expert -- certainly not system
    manager level) user at IUCF. I was in the terminal room where the TU77
    (or TU78 or similar tall vacuum) drives were located. I mounted a tape
    and was unable to MOUNT it. After trying some things, someone came
    down and said he had ALLOCATED the drive I had my tape on. I was only
    visiting there for a week or so to do an experiment, and back at my U.
    of Md. physics group (much smaller) we never had people ALLOCATE
    drives and then come down to mount a tape. But this was a bigger place
    and I didn't know that that's how they do things there. The guy was
    nice and let me do my tape job.

    OK. Something went wrong with misuse (non-used) of ALLOCATE. The world
    didn't come to an end! What's the big deal? (If they're going to have
    this ALLOCATE policy, they should have told me!)

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

    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.

    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? (OK, if the process hangs, the
    drive will stay allocated, but isn't there someone checking the system
    at least daily to take care of any problems that may arise? And if it
    does hang, someone will have to take care of it anyway.)

    AEF


  12. Re: despair

    >> $ ON ERROR THEN CONTINUE
    >> in front of a ALLOCATE command, that is just plain wrong. No debate.


    You are perfectly right. One should use $ SET NOON instead. This would
    ensure the command procedure always completes succesfully. :-) :-) :-)


    AEF wrote:


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



    Say this runs on the SYSTEM account (with allmighty privileges). Someone
    else has allocated the drive but is otherwise not being used. The
    allocate will fail, but other commands may succeed due to the fact that
    this account has all mighty privileges.

    Of course, the command would then write the backup to whatever tape was
    physically in the drive, and it could be someone else's tape.

    OR, the system manager has decided to have a process permanently
    allocate the tape drive so that nobody else can use it.


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


    $HELP ON PARA

    2.$ ON ERROR THEN GOTO BYPASS
    $ RUN A
    $ RUN B

  13. Re: despair

    On 09/15/07 11:59, JF Mezei wrote:
    >>> $ ON ERROR THEN CONTINUE
    >>> in front of a ALLOCATE command, that is just plain wrong. No debate.

    >
    > You are perfectly right. One should use $ SET NOON instead. This would
    > ensure the command procedure always completes succesfully. :-) :-) :-)


    Or allow the DCL writer to grab $STATUS and handle it as he sees fit.

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

    >
    >
    > Say this runs on the SYSTEM account (with allmighty privileges). Someone
    > else has allocated the drive but is otherwise not being used. The
    > allocate will fail, but other commands may succeed due to the fact that
    > this account has all mighty privileges.
    >
    > Of course, the command would then write the backup to whatever tape was
    > physically in the drive, and it could be someone else's tape.


    Really? It won't hang on the ALLOCATE?

    Even if it didn't, how could it INIT a tape loaded by another process?

    Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it
    isn't necessary) and the job would have to hang there, sending
    occasion OPCOM messages.

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

  14. Re: despair

    On Sep 15, 1:35 pm, Ron Johnson wrote:
    > On 09/15/07 11:59, JF Mezei wrote:
    >
    > >>> $ ON ERROR THEN CONTINUE
    > >>> in front of a ALLOCATE command, that is just plain wrong. No debate.

    >
    > > You are perfectly right. One should use $ SET NOON instead. This would
    > > ensure the command procedure always completes succesfully. :-) :-) :-)

    >
    > Or allow the DCL writer to grab $STATUS and handle it as he sees fit.
    >
    > > AEF wrote:

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

    >
    > > Say this runs on the SYSTEM account (with allmighty privileges). Someone
    > > else has allocated the drive but is otherwise not being used. The
    > > allocate will fail, but other commands may succeed due to the fact that
    > > this account has all mighty privileges.


    First of all, maybe it's not run under the SYSTEM account.

    If ALLOCATE fails, then either INIT or BACKUP will fail and the code
    will exit.

    Additionally, ALLOCATEing a non-existent drive is a warning ($SEVERITY
    == "0"), not an error, and the code would continue even without the ON
    ERROR THEN CONTINUE.

    > > Of course, the command would then write the backup to whatever tape was
    > > physically in the drive, and it could be someone else's tape.


    Could it be that at this site no one else uses the tape drive? If
    that's the case, this won't happen and is therefore not a problem.

    >
    > Really? It won't hang on the ALLOCATE?
    >
    > Even if it didn't, how could it INIT a tape loaded by another process?


    What do you mean? A process does not load a tape. A human or robot
    does. But this gets back to my point that the devil is in the details.
    Could it be that at this site no one else loads tapes? If so, this is
    nothing to worry about.

    >
    > Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it
    > isn't necessary) and the job would have to hang there, sending
    > occasion OPCOM messages.
    >
    > --
    > Ron Johnson, Jr.
    > Jefferson LA USA
    >

    [same old sig omitted]

    AEF


  15. Re: despair

    On 09/15/07 13:14, AEF wrote:
    > On Sep 15, 1:35 pm, Ron Johnson wrote:
    >> On 09/15/07 11:59, JF Mezei wrote:
    >>
    >>>>> $ ON ERROR THEN CONTINUE
    >>>>> in front of a ALLOCATE command, that is just plain wrong. No debate.
    >>> You are perfectly right. One should use $ SET NOON instead. This would
    >>> ensure the command procedure always completes succesfully. :-) :-) :-)

    >> Or allow the DCL writer to grab $STATUS and handle it as he sees fit.
    >>
    >>> AEF wrote:
    >>>> Please tell me what error from the ALLOCATE command would screw things
    >>>> up and how.
    >>> Say this runs on the SYSTEM account (with allmighty privileges). Someone
    >>> else has allocated the drive but is otherwise not being used. The
    >>> allocate will fail, but other commands may succeed due to the fact that
    >>> this account has all mighty privileges.

    >
    > First of all, maybe it's not run under the SYSTEM account.
    >
    > If ALLOCATE fails, then either INIT or BACKUP will fail and the code
    > will exit.
    >
    > Additionally, ALLOCATEing a non-existent drive is a warning ($SEVERITY
    > == "0"), not an error, and the code would continue even without the ON
    > ERROR THEN CONTINUE.
    >
    >>> Of course, the command would then write the backup to whatever tape was
    >>> physically in the drive, and it could be someone else's tape.

    >
    > Could it be that at this site no one else uses the tape drive? If
    > that's the case, this won't happen and is therefore not a problem.


    Assuming that the system will be the same two years after you've
    left is irresponsible. Those Who Remain will curse you, your
    children and your children's children.

    Besides, it's just plain Bad Programming.

    >> Really? It won't hang on the ALLOCATE?
    >>
    >> Even if it didn't, how could it INIT a tape loaded by another process?

    >
    > What do you mean? A process does not load a tape. A human or robot


    Sloppy terminology. I meant "mounted".

    > does. But this gets back to my point that the devil is in the details.
    > Could it be that at this site no one else loads tapes? If so, this is
    > nothing to worry about.
    >
    >> Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it
    >> isn't necessary) and the job would have to hang there, sending
    >> occasion OPCOM messages.


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

  16. Re: despair

    On Sep 15, 3:32 pm, Ron Johnson wrote:
    > On 09/15/07 13:14, AEF wrote:
    >
    > > On Sep 15, 1:35 pm, Ron Johnson wrote:
    > >> On 09/15/07 11:59, JF Mezei wrote:

    >
    > >>>>> $ ON ERROR THEN CONTINUE
    > >>>>> in front of a ALLOCATE command, that is just plain wrong. No debate.
    > >>> You are perfectly right. One should use $ SET NOON instead. This would
    > >>> ensure the command procedure always completes succesfully. :-) :-) :-)
    > >> Or allow the DCL writer to grab $STATUS and handle it as he sees fit.

    >
    > >>> AEF wrote:
    > >>>> Please tell me what error from the ALLOCATE command would screw things
    > >>>> up and how.
    > >>> Say this runs on the SYSTEM account (with allmighty privileges). Someone
    > >>> else has allocated the drive but is otherwise not being used. The
    > >>> allocate will fail, but other commands may succeed due to the fact that
    > >>> this account has all mighty privileges.

    >
    > > First of all, maybe it's not run under the SYSTEM account.


    Second of all, that would be a bad practice in and of itself!

    > > If ALLOCATE fails, then either INIT or BACKUP will fail and the code
    > > will exit.

    >
    > > Additionally, ALLOCATEing a non-existent drive is a warning ($SEVERITY
    > > == "0"), not an error, and the code would continue even without the ON
    > > ERROR THEN CONTINUE.

    >
    > >>> Of course, the command would then write the backup to whatever tape was
    > >>> physically in the drive, and it could be someone else's tape.

    >
    > > Could it be that at this site no one else uses the tape drive? If
    > > that's the case, this won't happen and is therefore not a problem.

    >
    > Assuming that the system will be the same two years after you've
    > left is irresponsible. Those Who Remain will curse you, your
    > children and your children's children.


    So I should assume that while it's currently being used to back up
    recipes, I should pretend that its next mission will be to run a
    nuclear power plant? C'mon. You do what's appropriate for the job and
    add some safety factor. If the mission of the system changes, it's up
    to the crew converting the system to take care of these things. You
    don't put your food in a safe because there might be a famine tomorrow
    and hoodlums will be stealing everyone's food.

    > Besides, it's just plain Bad Programming.


    I said I didn't recommend it. Yes, it's not a good example of
    programming. But it's not as bad as the OP is making it out to be,
    especially since he can't tell us anything else about the site. Maybe
    it's backing up vital data. Maybe it's backing up a scratch disk.

    > >> Really? It won't hang on the ALLOCATE?

    >
    > >> Even if it didn't, how could it INIT a tape loaded by another process?

    >
    > > What do you mean? A process does not load a tape. A human or robot

    >
    > Sloppy terminology. I meant "mounted".


    Fine. Then the person who MOUNTed the tape should have ALLOCATEd the
    drive first, no? And set the write-protect feature if no writing was
    to be done to the tape.

    > > does. But this gets back to my point that the devil is in the details.
    > > Could it be that at this site no one else loads tapes? If so, this is
    > > nothing to worry about.

    >
    > >> Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it
    > >> isn't necessary) and the job would have to hang there, sending
    > >> occasion OPCOM messages.


    > --
    > Ron Johnson, Jr.
    > Jefferson LA USA
    >

    [...same old sig omitted again...]

    AEF


  17. Re: despair

    On Sep 15, 4:45 pm, AEF wrote:
    > On Sep 15, 3:32 pm, Ron Johnson wrote:
    >
    > > On 09/15/07 13:14, AEF wrote:

    >
    > > > On Sep 15, 1:35 pm, Ron Johnson wrote:
    > > >> On 09/15/07 11:59, JF Mezei wrote:

    >
    > > >>>>> $ ON ERROR THEN CONTINUE
    > > >>>>> in front of a ALLOCATE command, that is just plain wrong. No debate.
    > > >>> You are perfectly right. One should use $ SET NOON instead. This would
    > > >>> ensure the command procedure always completes succesfully. :-) :-) :-)
    > > >> Or allow the DCL writer to grab $STATUS and handle it as he sees fit.

    >
    > > >>> AEF wrote:
    > > >>>> Please tell me what error from the ALLOCATE command would screw things
    > > >>>> up and how.
    > > >>> Say this runs on the SYSTEM account (with allmighty privileges). Someone
    > > >>> else has allocated the drive but is otherwise not being used. The
    > > >>> allocate will fail, but other commands may succeed due to the fact that
    > > >>> this account has all mighty privileges.

    >

    [...]
    > > >> Really? It won't hang on the ALLOCATE?

    >
    > > >> Even if it didn't, how could it INIT a tape loaded by another process?

    >
    > > > What do you mean? A process does not load a tape. A human or robot

    >
    > > Sloppy terminology. I meant "mounted".

    >
    > Fine. Then the person who MOUNTed the tape should have ALLOCATEd the
    > drive first, no? And set the write-protect feature if no writing was
    > to be done to the tape.


    And second: What kind of place is allowing users to mount tapes on
    drives used for system backups? I find it a bit odd to find fault with
    one thing by saying that some other stupid thing could happen, which
    in and of itself has its own problems. We're not going to get system
    backups done if users are using the same drive, regardless of the
    dopiness of the DCL code snippet, are we now?

    By the same logic: Building a house is a bad idea because it might
    burn down! :-)

    > > > does. But this gets back to my point that the devil is in the details.
    > > > Could it be that at this site no one else loads tapes? If so, this is
    > > > nothing to worry about.

    >
    > > >> Anyway, we do explicit MOUNT/FOREIGN before BACKUP (even though it
    > > >> isn't necessary) and the job would have to hang there, sending
    > > >> occasion OPCOM messages.

    > > --
    > > Ron Johnson, Jr.
    > > Jefferson LA USA

    >
    > [...same old sig omitted again...]
    >
    > AEF




  18. RE: despair


    > And second: What kind of place is allowing users to mount tapes on
    > drives used for system backups? I find it a bit odd to find fault with
    > one thing by saying that some other stupid thing could happen, which
    > in and of itself has its own problems. We're not going to get system
    > backups done if users are using the same drive, regardless of the
    > dopiness of the DCL code snippet, are we now?
    >


    Well, I don't know about VMS, but it certainly isn't a problem in the
    mainframe world.
    That is what tape libraries and enterprise backups systems like (grrrrr)
    Tivoli are for.

    Doesn't VMS have equivalent tape management and backup systems? I haven't
    looked because it
    is way overkill for what I need, but surely it exists?

    Not that the issue under discussion is using one, mind you...

    -Paul



  19. Re: despair

    On 09/15/07 16:26, Paul Raulerson wrote:
    >> And second: What kind of place is allowing users to mount tapes on
    >> drives used for system backups? I find it a bit odd to find fault with
    >> one thing by saying that some other stupid thing could happen, which
    >> in and of itself has its own problems. We're not going to get system
    >> backups done if users are using the same drive, regardless of the
    >> dopiness of the DCL code snippet, are we now?
    >>

    >
    > Well, I don't know about VMS, but it certainly isn't a problem in the
    > mainframe world.
    > That is what tape libraries and enterprise backups systems like (grrrrr)
    > Tivoli are for.
    >
    > Doesn't VMS have equivalent tape management and backup systems? I haven't
    > looked because it
    > is way overkill for what I need, but surely it exists?


    Sure. ABS and (my favorite, because ABS hasn't supported Rdb in
    many years) SLS. MRU for direct robot control.

    There is also a Veritas(?) client for VMS.

    Sadly, SLS was not ported to Itanium.

    > Not that the issue under discussion is using one, mind you...


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

  20. RE: despair

    > -----Original Message-----
    > From: Ron Johnson [mailto:ron.l.johnson@cox.net]
    > Sent: September 15, 2007 6:56 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: despair
    >
    > On 09/15/07 16:26, Paul Raulerson wrote:
    > >> And second: What kind of place is allowing users to mount tapes on
    > >> drives used for system backups? I find it a bit odd to find fault

    > with
    > >> one thing by saying that some other stupid thing could happen, which
    > >> in and of itself has its own problems. We're not going to get system
    > >> backups done if users are using the same drive, regardless of the
    > >> dopiness of the DCL code snippet, are we now?
    > >>

    > >
    > > Well, I don't know about VMS, but it certainly isn't a problem in the
    > > mainframe world.
    > > That is what tape libraries and enterprise backups systems like

    > (grrrrr)
    > > Tivoli are for.
    > >
    > > Doesn't VMS have equivalent tape management and backup systems? I

    > haven't
    > > looked because it
    > > is way overkill for what I need, but surely it exists?

    >
    > Sure. ABS and (my favorite, because ABS hasn't supported Rdb in
    > many years) SLS. MRU for direct robot control.
    >
    > There is also a Veritas(?) client for VMS.
    >
    > Sadly, SLS was not ported to Itanium.
    >
    > > Not that the issue under discussion is using one, mind you...

    >


    A few examples of other backup alternatives:

    ISE Enterprise backup (OpenVMS):
    http://www.i-s-e.com/Products/Enterp...KUP/index.html

    TapeSys for OpenVMS:
    http://www.softwarepartners.com/products/

    Netbackup V6 client for OpenVMS:
    ftp://ftp.emea.support.veritas.com/p...Backup_OpenVMS

    HP Data Protector for OpenVMS:
    http://h18006.www1.hp.com/products/s...tor/index.html

    Tivoli Backup option for OpenVMS:
    http://storsol.com/main.cfm?menu=3&s...bcoverview.cfm

    Legato (EMC) Networker for OpenVMS:
    http://software.emc.com/products/sof...er.htm?hlnav=T

    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.




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