Re: COBOL Transactions? - VMS

This is a discussion on Re: COBOL Transactions? - VMS ; In article , Glenn Everhart wrote: > It is true though that DAT is very susceptible to tape damage and drives must > be > handled with much care if you don't want your tape turned into magnetic > confetti. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: Re: COBOL Transactions?

  1. Re: 4MM DAT tapes read/write

    In article <46D0BC4E.4090305@gce.com>,
    Glenn Everhart wrote:

    > It is true though that DAT is very susceptible to tape damage and drives must
    > be
    > handled with much care if you don't want your tape turned into magnetic
    > confetti.


    I've seen that happen to a DAT and "magnetic confetti" is an accurate
    description.

    --
    Paul Sture

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

  2. RE: COBOL Transactions?


    >
    > The only problem I see with VMS not recognizing your 4mm-drive is that
    > it doesn't give the appropriate error message:
    >
    > %CONFIGURE-F-BLEAH, 4mm-tape drive? You've got to be kidding.
    > -SYSTEM-F-COUGHCOUGH, I'm not working with that!
    >


    I somehow would not put it past it to do just exactly that!

    > (Now THAT would be humorous!)
    >
    > The 4mm-DAT format is a write-probably/read-maybe one. So if you care
    > about your data, I'd get something better. Thank your lucky stars that
    > VMS is warning you about this!
    >
    > Tip: I've found that DDS-1 tapes work much better than DDS-2 tapes on
    > TLZ07 and TLZ09 drives (which are 4mm-DAT drives). I have a DLT drive
    > now (TZ88N-VA) and so far it works like a charm!
    >
    > |-: OK, I don't know what the real problem is, but I'd get a better
    > drive regardless. :-|
    >


    I have the same DLT drive you do, and an IBM branded LTO drive.
    I generally run backups to the DLT, mostly because I have more tapes
    for it. Anything like essays or articles, or especially source code, gets
    copied three places as well as to tape, and once a week to DVD.

    -Paul



    > AEF
    >
    > [...]




  3. Re: COBOL Transactions?

    On Aug 25, 11:31 pm, "Paul Raulerson" wrote:
    > > The only problem I see with VMS not recognizing your 4mm-drive is that
    > > it doesn't give the appropriate error message:

    >
    > > %CONFIGURE-F-BLEAH, 4mm-tape drive? You've got to be kidding.
    > > -SYSTEM-F-COUGHCOUGH, I'm not working with that!

    >
    >
    > I somehow would not put it past it to do just exactly that!
    >
    > > (Now THAT would be humorous!)

    >
    > > The 4mm-DAT format is a write-probably/read-maybe one. So if you care
    > > about your data, I'd get something better. Thank your lucky stars that
    > > VMS is warning you about this!

    >
    > > Tip: I've found that DDS-1 tapes work much better than DDS-2 tapes on
    > > TLZ07 and TLZ09 drives (which are 4mm-DAT drives). I have a DLT drive
    > > now (TZ88N-VA) and so far it works like a charm!

    >
    > > |-: OK, I don't know what the real problem is, but I'd get a better
    > > drive regardless. :-|

    >
    > I have the same DLT drive you do, and an IBM branded LTO drive.
    > I generally run backups to the DLT, mostly because I have more tapes
    > for it. Anything like essays or articles, or especially source code, gets
    > copied three places as well as to tape, and once a week to DVD.


    Then why, pray tell, are you f*****' around with a 4mm drive?

    In another post in this thread you wrote...

    "I'm excited about it, and know I need to move this to Itanium, but
    being
    cheap, I think I will do a porting event thing as soon as I have
    enough
    ported, working, and tested on the little Alpha here. The only issue
    with
    the Alpha is that the 4mm tape drive on it does not seem to be
    recognized.
    No big matter - source gets backed up to disk
    3 times per day, and FTP'ed off to the UNIX machine which *does* know
    how to

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    talk to tape. Tapes go into the library, the safe, and my lower left
    hand
    ^^^^^^^^^^^^
    desk drawer at my "day" job! "

    [Pardon me if Google Groups screws up my ^'s. They dropped the preview
    function, for one thing.]

    It sure looks like you're saying that the Alpha doesn't know how to
    talk to tape (ANY tape) to me!

    > -Paul> AEF
    >
    > > [...]


    AEF


  4. Re: 4MM DAT tapes read/write (was:Re: COBOL Transactions?)

    On Aug 25, 6:06 pm, bradhamil...@comcast.net (Brad Hamilton) wrote:
    > In article <1188069083.626943.60...@q5g2000prf.googlegroups.co m>, AEF wrote:
    >
    > [...]
    >
    > >The only problem I see with VMS not recognizing your 4mm-drive is that
    > >it doesn't give the appropriate error message:

    >
    > >%CONFIGURE-F-BLEAH, 4mm-tape drive? You've got to be kidding.
    > >-SYSTEM-F-COUGHCOUGH, I'm not working with that!

    >
    > >(Now THAT would be humorous!)

    >
    > >The 4mm-DAT format is a write-probably/read-maybe one. So if you care
    > >about your data, I'd get something better. Thank your lucky stars that
    > >VMS is warning you about this!

    >
    > My experience with 4mm tapes and drives differs (thank goodness!)
    >
    > Of course, I prefer DLT in term of speed and reliability, but in my last VMS
    > job, I was forced to use 4mm tape drives. We ran BACKUP/IMAGE on or disks
    > every night, and re-used the tapes regularly. I was able to restore
    > (many times over) individual files inadvertantly deleted by our customers, as
    > well as whole disks that had logged hundreds of errors over a short time, and
    > needed to be replaced.


    Were they TLZ07 or TLZ09 drives, or some other models?

    Did you have the luxury of reading the tapes back on the same drive
    they were written with? I had many tapes that were fully readable only
    on the drives they were written on. If the tape were read on a
    different drive, in many cases I'd get parity errors part-way through
    the tape. Now if it's an alignment problem, why doesn't it crap out at
    the beginning? If it's a cleaning problem, why did repeated attempts
    always do the same thing: read up to a certain point and croak? And
    sometimes one drive would get a little farther through the tape than
    another.

    Did you have a catcher's mitt set up in front of each drive to catch
    the tapes as they come flying out during ejection? [OK, this only
    happened with one of my drives a few years ago and I had the pleasure
    of demonstrating this to an HP person. HP replaced it under our
    maintenance contract and they've been very good about replacing drives
    that go bad.]

    I've also had quite a few simply get stuck in drive. I've also had
    tapes come out with the tape hanging out of the cartridge.

    And just to preempt the inevitable: Yes, I cleaned the drives
    regularly according to the manuals instructions.

    > Again, I will say that DLT is vastly superior, but Paul should not be
    > discouraged from using DAT, if that is indeed the only (or most economical)
    > choice for tape backup.
    > [...]


    It depends on how much you value your data!

    AEF


  5. Re: 4MM DAT tapes read/write

    On Aug 25, 7:33 pm, Glenn Everhart wrote:
    > Brad Hamilton wrote:
    > > In article <1188069083.626943.60...@q5g2000prf.googlegroups.co m>, AEF wrote:
    > > [...]
    > >> The only problem I see with VMS not recognizing your 4mm-drive is that
    > >> it doesn't give the appropriate error message:

    >
    > >> %CONFIGURE-F-BLEAH, 4mm-tape drive? You've got to be kidding.
    > >> -SYSTEM-F-COUGHCOUGH, I'm not working with that!

    >
    > >> (Now THAT would be humorous!)

    > [...]
    > > Again, I will say that DLT is vastly superior, but Paul should not be
    > > discouraged from using DAT, if that is indeed the only (or most economical)
    > > choice for tape backup.
    > > [...]

    >
    > I have had no problems with DAT over the years (or for that matter with 8mm)
    > provided the heads were clean and the drive alignment not out. Using ztdriver
    > they work nicely even across DECnet. You do have to be aware of the several
    > flavors of these tapes, though, which are not interchangeable.


    I used the tapes that the drives' manuals say to use. I found that the
    DDS-2 tapes are highly unreliable in the TLZ07's and TLZ09's and
    having switched to DDS-1 has made life a lot better.

    > The oldest DAT tapes hold
    > as I recall about 1.2GB on 60' media. Next gen is 90' media, holds a couple gigs
    > each, the next is 120' and holds 3 or 4 GB and so on.


    That's *meters*: 60 meters, 90 m, and 120 m.

    > The older drives cannot
    > reliably work with new tapes.


    Older drives cannot work reliably with new tapes? Say what? You mean I
    can't buy tapes for my TLZ drives and expect them to work. Say what?!

    > This has nothing to do with the OS and everything
    > to do with the drives.


    I didn't blame the OS in all of this. I blamed the tape drives
    themselves. And I was saying that VMS was actually doing Paul a favor
    by rejecting his 4mm drive.

    > (Same happens with DLT by the way. Doubters can try writing
    > TK50 or TK70 tape in a modern DLT if they dare. Similar size and appearance is
    > NOT everything!!


    So you meant older tapes with newer drives?

    Please clarify.

    > There are in fact relatively few devices that fail with VMS.


    Yes, I believe this is one reason VAX become popular with physicists,
    IIRC.

    > There are ways to
    > write media VMS will not grok (tape with blocksize over 64K for example, unless that


    Will not grok? Say what?

    > has been fixed) and filestructures VMS does not know, but VMS has been historically
    > pretty darn good at handling data processing gadgets, at times needing third party
    > controllers. From very early days, VMS has had tape file structure processors to
    > handle file structured tape. It also has had utilities, as unix has had, but
    > it has been able to treat tape on a par with disk as a file structured device (with
    > limitations derived from the devices and from the shortcomings of the ANSI standards),
    > a feat many OSs never heard of.
    >
    > It is true though that DAT is very susceptible to tape damage and drives must be
    > handled with much care if you don't want your tape turned into magnetic confetti.


    Just to add to the list I started with my response to Brad's post:

    I've also had drives fail on the (BAKCUP/VERIFY) verification pass
    only to succeed with a subsequent BACKUP/COMPARE operation.

    Also, the drives often fail to fully rewind the tapes!

    On our Stratus DDS-1 drive I recently had trouble inserting the tape.
    It would spit the darn thing right back out. In fact, it was a
    cleaning tape and when it finally stayed in the drive rewound it!!! It
    rewound a cleaning tape. ... Nice. ;-)

    At least one TLZ drive (I think it was actually two or three) I had
    would also keep spitting the tape back out immediately after taking it
    in.

    > Glenn Everhart


    AEF


  6. RE: COBOL Transactions?



    >
    >
    > Then why, pray tell, are you f*****' around with a 4mm drive?
    >


    LOL! That was the whole point, I'm *not*. I may need to on an Itanium, but
    as of today, I haven't even figured out which Itanium to order, or if it
    makes
    more sense to attend one of those HP sessions where they *give* you one.

    I do not know what the backup options for a low end Itanium are.

    > In another post in this thread you wrote...
    >
    > "I'm excited about it, and know I need to move this to Itanium, but
    > being
    > cheap, I think I will do a porting event thing as soon as I have
    > enough
    > ported, working, and tested on the little Alpha here. The only issue
    > with
    > the Alpha is that the 4mm tape drive on it does not seem to be
    > recognized.


    Yep.. "the" Alpha sitting in the equipment room upstairs sure doesn't
    know how to talk to the old 4mm that was installed in it.

    > It sure looks like you're saying that the Alpha doesn't know how to
    > talk to tape (ANY tape) to me!
    >


    "The" Alpha - meaning the one machine sitting >>> here <<< doesn't
    know how to talk to that one tape. There is a hardware issue with
    this *one* Alpha.

    I'm dead sure that Alpha machines running VMS have no trouble talking
    to tape drives.

    But to swing this around to a more productive subject, what backup options
    are available on low end Itanimum Integrity systems that would be suitable
    for daily use by non-technical users.

    Hardly any of the very small SMB shops will have the backup capability I
    have here, nor the skill to engineer a disaster recovery situation. I
    need to do that for them, on the cheap, and in such as way as it is not
    too ornerous for them to do every day.

    Stick a tape in and go away will probably be about the level I need to
    get to.

    Given that a very small SMB install might not have all that much data,
    a DVD backup might not be out of the question, but it is more expensive.

    Going along that line of thought, here is what I pretty much envision
    at least attempting to do, none of which will prove out until I put an
    Itanium machine here to test it on.

    (1) Recovery DVD that blows an IPL image onto a disk with both VMS and my
    software.
    Result should be a booting system with software up to date with the last
    recovery
    DVD version I put together. Preferably the DVD is bootable and will start
    the recovery
    procedure after asking the user to okay it.

    (2) Some kind of rewritable or daily storage that contains images of, or
    periodic
    full backups and incremental backups of the critical data and any software
    patches
    installed on the system.

    (3) Recovery/whatever program or DCL or ??? that manages the restore of the
    data.


    So in a worst case disaster recovery situation, the user will receive a new
    machine,
    stick in DVD#1, IPL, follow the prompts and 15 minutes later come out with a
    machine
    that boots into the base software.

    He then loads Tape, DVD#2, whatever it winds up being, and restores his
    application data and
    any patches that may have been put on the system since the DVD version.

    He re-ipls, and zap... he is back in business. I would like the entire
    process to take
    less than an hour, and also be the same or very similar to the process used
    for a new customer.


    Larger SMB shops will of course, be more complex as the system will have to
    be integrated into
    their existing backup/restore and DR situations. That will take consulting
    $$ most likely.

    See the idea though? Everything about the entire process needs to be simple,
    documented, and
    as standardized as possible, otherwise we will drown under a landslide of
    support requests.
    It is also why I am not overly concerned with the Alpha tape drive
    working or not.
    I simply lack the detailed knowledge of the Integrity platform necessary to
    make any
    rational descisions along those lines.

    Advice or suggestions always welcome, as with the recent WASD webserver
    thing.


    -Paul


  7. RE: 4MM DAT tapes read/write (was:Re: COBOL Transactions?)



    > -----Original Message-----
    > From: AEF [mailto:spamsink2001@yahoo.com]
    > Sent: Sunday, August 26, 2007 7:27 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: 4MM DAT tapes read/write (was:Re: COBOL Transactions?)
    >
    > On Aug 25, 6:06 pm, bradhamil...@comcast.net (Brad Hamilton) wrote:
    > > In article <1188069083.626943.60...@q5g2000prf.googlegroups.co m>, AEF

    > wrote:
    > >
    > > [...]
    > >
    > > >The only problem I see with VMS not recognizing your 4mm-drive is

    > that
    > > >it doesn't give the appropriate error message:

    > >
    > > >%CONFIGURE-F-BLEAH, 4mm-tape drive? You've got to be kidding.
    > > >-SYSTEM-F-COUGHCOUGH, I'm not working with that!

    > >
    > > >(Now THAT would be humorous!)

    > >
    > > >The 4mm-DAT format is a write-probably/read-maybe one. So if you

    > care
    > > >about your data, I'd get something better. Thank your lucky stars

    > that
    > > >VMS is warning you about this!

    > >
    > > My experience with 4mm tapes and drives differs (thank goodness!)
    > >
    > > Of course, I prefer DLT in term of speed and reliability, but in my

    > last VMS
    > > job, I was forced to use 4mm tape drives. We ran BACKUP/IMAGE on or

    > disks
    > > every night, and re-used the tapes regularly. I was able to restore
    > > (many times over) individual files inadvertantly deleted by our

    > customers, as
    > > well as whole disks that had logged hundreds of errors over a short

    > time, and
    > > needed to be replaced.

    >
    > Were they TLZ07 or TLZ09 drives, or some other models?
    >
    > Did you have the luxury of reading the tapes back on the same drive
    > they were written with? I had many tapes that were fully readable only
    > on the drives they were written on. If the tape were read on a
    > different drive, in many cases I'd get parity errors part-way through
    > the tape. Now if it's an alignment problem, why doesn't it crap out at
    > the beginning? If it's a cleaning problem, why did repeated attempts
    > always do the same thing: read up to a certain point and croak? And
    > sometimes one drive would get a little farther through the tape than
    > another.
    >
    > Did you have a catcher's mitt set up in front of each drive to catch
    > the tapes as they come flying out during ejection? [OK, this only
    > happened with one of my drives a few years ago and I had the pleasure
    > of demonstrating this to an HP person. HP replaced it under our
    > maintenance contract and they've been very good about replacing drives
    > that go bad.]
    >
    > I've also had quite a few simply get stuck in drive. I've also had
    > tapes come out with the tape hanging out of the cartridge.
    >
    > And just to preempt the inevitable: Yes, I cleaned the drives
    > regularly according to the manuals instructions.
    >
    > > Again, I will say that DLT is vastly superior, but Paul should not be
    > > discouraged from using DAT, if that is indeed the only (or most

    > economical)
    > > choice for tape backup.
    > > [...]

    >
    > It depends on how much you value your data!
    >
    > AEF


    Well, I will say the primary backup on an old P/390 machine is a 4mm tape
    drive, and it is now
    12 years old and reads/writes perfectly well. I have had some issues with
    having to force a block
    size when reading tapes it writes back on another (identical) drive attached
    to a UNIX box.

    However, I also snap the data off that thing regularly as image backups
    using UNIX booted from a CD;
    and *that* goes to LTO. (All the UNIX, Windows, and Mac data tends to go to
    DLT though.

    I also back up anything I consider really important to DVD, and as
    indicated, with multiple copies at
    least one of which is stored offsite.

    I am a little paranoid...

    -Paul


  8. SMB backup "solutions" (was:Re: COBOL Transactions?)

    In article <002b01c7e7ef$b3bc98b0$1b35ca10$@com>, Paul Raulerson wrote:
    [...]
    >But to swing this around to a more productive subject, what backup options
    >are available on low end Itanimum Integrity systems that would be suitable
    >for daily use by non-technical users.
    >
    >Hardly any of the very small SMB shops will have the backup capability I
    >have here, nor the skill to engineer a disaster recovery situation. I
    >need to do that for them, on the cheap, and in such as way as it is not
    >too ornerous for them to do every day.
    >
    >Stick a tape in and go away will probably be about the level I need to
    >get to.

    [...]

    I can't speak to Itaniums, since I don't use them - however, the last VMS job I
    had needed this kind of "stick a tape in and change it every day" solution at
    the customer site(s). 4mm DAT was chosen for its (relative) cheapness, minimal
    footprint for drive and tapes, and relative ease of use (stick the tape in and
    walk away).

    Will 4mm DAT work on an Itanium? Don't know.

    Another option that my company explored involved the following scenario:

    Production data center was colo'd, and the 4mm tape stackers went with the
    production boxes. Development boxes remained on-site, without a tape drive.
    What to do?? Our "solution" was NAS, "served" to the VMS machines via NFS. A
    backup script was crafted to purge "old" backup save-sets, and backup/image
    development disks to NAS. Worked tolerably well, but the backup/restore
    requirements were much less stringent than would have been expected for
    production data. Still, a "bare-metal" install of VMS, followed by a restore
    of a system disk image to a different disk drive, followed by a reboot from
    the restored system disk would have been *possible*.

    Others can speak to some of the other possibilities raised in this thread.
    [...]

  9. RE: COBOL Transactions?

    > -----Original Message-----
    > From: Paul Raulerson [mailtoaul@raulersons.com]
    > Sent: August 26, 2007 10:45 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: RE: COBOL Transactions?
    >
    >
    >


    [snip]

    > But to swing this around to a more productive subject, what backup
    > options
    > are available on low end Itanimum Integrity systems that would be
    > suitable
    > for daily use by non-technical users.
    >


    Whenever the question comes up about "what is supported?", the very first place to look
    Is the OpenVMS V8.3 SPD - "software product description". Reference:
    http://h18000.www1.hp.com/info/XAV12X/XAV12XPF.PDF (pg 38 for your question)

    Integrity rx2660 site:
    http://h20341.www2.hp.com/integrity/...0-225-121.html

    OpenVMS Storage:
    http://h18006.www1.hp.com/storage/osopenvms.html


    > Hardly any of the very small SMB shops will have the backup capability
    > I
    > have here, nor the skill to engineer a disaster recovery situation. I
    > need to do that for them, on the cheap, and in such as way as it is not
    > too ornerous for them to do every day.
    >
    > Stick a tape in and go away will probably be about the level I need to
    > get to.
    >


    I will assume That ideally there is a capability to remotely access the console (even if
    system is at the console prompt) in a safe, secure manner to do remote support and
    troubleshooting as required.

    Something to consider is that it might be more appropriate to suggest a solution that
    charges a small support fee, and a SMB Cust will not have to remember to change tapes,
    unload tapes etc. We all know that for SMB cust's without server operationsexperience,
    this can be a real challenge.

    There are typically 2 primary issues that need to be addressed here.

    1. Local daily backups that provide for quick restore (usually daily full backups are
    much quicker to restore when local drive dies.)
    2. Data Archiving in the event of server room fire/pick favourite disaster.

    Wrt to issue #1 - Backing up to a supplied additional "maint" disk for daily "full" backup
    save-sets which also has a pre-built version of OpenVMS on it as well. In the event of a
    major failure of any of the primary disks, once the failed disk was replaced, you could
    simply boot the maint disk and restore what ever images are required, and then reboot
    the default system disk.

    For greater HA, install local HW RAID or host based volume shadowing for all disks. This
    might be a higher charge option for SMB's that do not want to worry about tapes, and want
    to minimize any dealing with any server issues etc

    Wrt to issue #2 (archiving), I would suggest a small additional support feethat would
    provide the Cust with a service that transferred copies of their daily fullbackup
    files in a safe, encrypted and secure manner to a second site (perhaps yourhome site?).

    The files would then be archived off the second site per some agreement with third party
    archive vendor.

    Course, security and sensitivity of data would have to be big priority.

    [snip]

    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.




  10. Re: 4MM DAT tapes read/write

    On 08/26/07 07:43, AEF wrote:
    > On Aug 25, 7:33 pm, Glenn Everhart wrote:

    [snip]
    >
    >> There are ways to
    >> write media VMS will not grok (tape with blocksize over 64K for example, unless that

    >
    > Will not grok? Say what?


    $ dict grok
    3 definitions found

    From WordNet (r) 2.1 (2005) [wn]:

    grok
    v 1: get the meaning of something; "Do you comprehend the
    meaning of this letter?" [syn: {grok}, {get the picture},
    {comprehend}, {savvy}, {dig}, {grasp}, {compass},
    {apprehend}]

    From The Free On-line Dictionary of Computing (26 May 2007) [foldoc]:

    grok

    /grok/, /grohk/ (From the novel "Stranger in a Strange Land",
    by Robert A. Heinlein, where it is a Martian word meaning
    literally "to drink" and metaphorically "to be one with")

    1. To understand, usually in a global sense. Connotes
    intimate and exhaustive knowledge.

    Contrast {zen}, which is similar supernal understanding
    experienced as a single brief flash. See also {glark}.

    2. Used of programs, may connote merely sufficient
    understanding. "Almost all C compilers grok the "void" type
    these days."

    [{Jargon File}]

    (1995-01-31)


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

  11. Re: COBOL Transactions?


    On Aug 26, 10:45 am, "Paul Raulerson" wrote:
    > > Then why, pray tell, are you f*****' around with a 4mm drive?

    >
    > LOL! That was the whole point, I'm *not*. I may need to on an Itanium, but
    > as of today, I haven't even figured out which Itanium to order, or if it
    > makes
    > more sense to attend one of those HP sessions where they *give* you one.
    >
    > I do not know what the backup options for a low end Itanium are.
    >
    > > In another post in this thread you wrote...

    >
    > > "I'm excited about it, and know I need to move this to Itanium, but
    > > being
    > > cheap, I think I will do a porting event thing as soon as I have
    > > enough
    > > ported, working, and tested on the little Alpha here. The only issue
    > > with
    > > the Alpha is that the 4mm tape drive on it does not seem to be
    > > recognized.

    >
    > Yep.. "the" Alpha sitting in the equipment room upstairs sure doesn't
    > know how to talk to the old 4mm that was installed in it.
    >
    > > It sure looks like you're saying that the Alpha doesn't know how to
    > > talk to tape (ANY tape) to me!

    >
    > "The" Alpha - meaning the one machine sitting >>> here <<< doesn't
    > know how to talk to that one tape. There is a hardware issue with
    > this *one* Alpha.


    You, uh, mmmmm, forgot one very important part of your self-quoting.
    Let's see that again in slow motion, shall we?

    On Aug 23, 9:19 pm, "Paul Raulerson" wrote:
    > > -----Original Message-----
    > > From: Richard Maher [mailto:maher...@hotspamnotmail.com]
    > > Sent: Thursday, August 23, 2007 6:04 AM
    > > To: Info-...@Mvb.Saic.Com
    > > Subject: Re: COBOL Transa


    [...]

    > I'm excited about it, and know I need to move this to Itanium, but being
    > cheap, I think I will do a porting event thing as soon as I have enough
    > ported, working, and tested on the little Alpha here. The only issue with
    > the Alpha is that the 4mm tape drive on it does not seem to be recognized.


    OK. Here's where you conveniently snipped a little too much. Here's
    the continuation of the above quote:

    > No big matter - source gets backed up to disk
    > 3 times per day, and FTP'ed off to the UNIX machine which *does* know how to
    > talk to tape. Tapes go into the library, the safe, and my lower left hand
    > desk drawer at my "day" job!


    WOAH! Hold it! Look right there. Right above. It says:

    > No big matter - source gets backed up to disk
    > 3 times per day, and FTP'ed off to the UNIX machine which *does* know how to
    > talk to tape.


    Did you see that? Shall I replay it again? A little slower maybe?

    The clear implication is that you're saying that the Alpha (OK, maybe
    just *your* Alpha), does not know how to talk to tape. Not just your
    4mm drive, but just plain old TAPE.

    QED.

    > I'm dead sure that Alpha machines running VMS have no trouble talking
    > to tape drives.


    OK, maybe you wrote a little carelessly the first time. But please
    don't try to make it look like you wrote something else.

    Actually I'm very happy your porting stuff to Alpha and possibly
    Itanium. Best of luck on your endeavor.

    [...]

    > -Paul


    AEF


  12. RE: COBOL Transactions?

    > You, uh, mmmmm, forgot one very important part of your self-quoting.
    > Let's see that again in slow motion, shall we?
    >
    > On Aug 23, 9:19 pm, "Paul Raulerson" wrote:
    > > > -----Original Message-----
    > > > From: Richard Maher [mailto:maher...@hotspamnotmail.com]
    > > > Sent: Thursday, August 23, 2007 6:04 AM
    > > > To: Info-...@Mvb.Saic.Com
    > > > Subject: Re: COBOL Transa

    >
    > [...]
    >
    > > I'm excited about it, and know I need to move this to Itanium, but

    > being
    > > cheap, I think I will do a porting event thing as soon as I have

    > enough
    > > ported, working, and tested on the little Alpha here. The only issue

    > with
    > > the Alpha is that the 4mm tape drive on it does not seem to be

    > recognized.
    >
    > OK. Here's where you conveniently snipped a little too much. Here's
    > the continuation of the above quote:
    >
    > > No big matter - source gets backed up to disk
    > > 3 times per day, and FTP'ed off to the UNIX machine which *does* know

    > how to
    > > talk to tape. Tapes go into the library, the safe, and my lower left

    > hand
    > > desk drawer at my "day" job!

    >
    > WOAH! Hold it! Look right there. Right above. It says:
    >
    > > No big matter - source gets backed up to disk
    > > 3 times per day, and FTP'ed off to the UNIX machine which *does* know

    > how to
    > > talk to tape.

    >
    > Did you see that? Shall I replay it again? A little slower maybe?
    >
    > The clear implication is that you're saying that the Alpha (OK, maybe
    > just *your* Alpha), does not know how to talk to tape. Not just your
    > 4mm drive, but just plain old TAPE.
    >


    Let me be clear and edit it back to the original:


    I'm excited about it, and know I need to move this to Itanium, but being
    cheap, I think I will do a porting event thing as soon as I have enough
    ported, working, and tested on the little Alpha here. The only issue
    with the Alpha is that the 4mm tape drive on it does not seem to be
    recognized.

    No big matter - source gets backed up to disk 3 times per day,
    and FTP'ed off to the UNIX machine which *does* know how to
    talk to tape. Tapes go into the library, the safe, and my lower left hand
    desk drawer at my "day" job!


    There is nothing in there that implies I ever said all Alpha's
    could not talk to tape in any way shape manner or form. Nor does
    it explicty state that the information from a half dozen other
    machines is backed up to the same UNIX machine and the same set
    of tape drives attached to it. (That's UNIX, Linux, Mac, as well
    as Windows stuff.)

    So no, I understand that what you may have heard is not what
    I said, but what I said was clear. I'll slow it down for you...


    "The only issue with the Alpha is that the 4mm tape drive on it does not
    seem to be
    recognized."

    I'm really not going to apologize yet >> again << on this; what I wrote, at
    least
    as pertains to the tape drive, was clear and definite and should not have
    been
    insulting to anyone.

    There is *nothing* more too it.

    -Paul







  13. Re: SMB backup "solutions" (was:Re: COBOL Transactions?)

    In article , bradhamilton@comcast.net (Brad Hamilton) writes:
    >
    >
    >In article <002b01c7e7ef$b3bc98b0$1b35ca10$@com>, Paul Raulerson wrote:
    >[...]
    >>But to swing this around to a more productive subject, what backup options
    >>are available on low end Itanimum Integrity systems that would be suitable
    >>for daily use by non-technical users.
    >>
    >>Hardly any of the very small SMB shops will have the backup capability I
    >>have here, nor the skill to engineer a disaster recovery situation. I
    >>need to do that for them, on the cheap, and in such as way as it is not
    >>too ornerous for them to do every day.
    >>
    >>Stick a tape in and go away will probably be about the level I need to
    >>get to.

    >[...]
    >
    >I can't speak to Itaniums, since I don't use them - however, the last VMS job I
    >had needed this kind of "stick a tape in and change it every day" solution at
    >the customer site(s). 4mm DAT was chosen for its (relative) cheapness, minimal
    >footprint for drive and tapes, and relative ease of use (stick the tape in and
    >walk away).
    >
    >Will 4mm DAT work on an Itanium? Don't know.


    Why not. I've connected my ol' d|i|g|i|t|a|l TLZ07 to the Itanium and it
    seemed perfectly happy to talk to it.

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

  14. Re: COBOL Transactions?

    Paul Raulerson wrote:
    >
    >>
    >>Then why, pray tell, are you f*****' around with a 4mm drive?
    >>

    >
    >
    > LOL! That was the whole point, I'm *not*. I may need to on an Itanium, but
    > as of today, I haven't even figured out which Itanium to order, or if it
    > makes
    > more sense to attend one of those HP sessions where they *give* you one.
    >
    > I do not know what the backup options for a low end Itanium are.
    >
    >


    My rx2620 from the HP porting workshop came with an NEC DVD+/-RW drive,
    but I haven't used if for backing anything up... (I think someone else
    wrote a CD on it once.)

    What we are currently using for backup is a pair (or 3?) of USB external
    drives, once a week a batch job does backup/image of all the drives on
    our cluster, a random assortment of internal SCSI, storageworks, and
    even several DSSI disks on our VAX, to one of the external USB disks.
    Next day, someone brings it home and returns with the other one. We
    also do nightly incremental backups to a save set on an NFS-served Sun,
    which then gets backed up to a DLT drive on the Sun. (Not saying this
    scheme makes perfect sense, but just that there's an infinite number of
    ways to skin a cat, and we have been able to restore disks, more or less,
    in earnest.) This is purely a development system, so losing a bunch of
    edits would be a pain but not a disaster.

    >>In another post in this thread you wrote...
    >>
    >>"I'm excited about it, and know I need to move this to Itanium, but
    >>being
    >>cheap, I think I will do a porting event thing as soon as I have
    >>enough
    >>ported, working, and tested on the little Alpha here. The only issue
    >>with
    >>the Alpha is that the 4mm tape drive on it does not seem to be
    >>recognized.

    >
    >
    > Yep.. "the" Alpha sitting in the equipment room upstairs sure doesn't
    > know how to talk to the old 4mm that was installed in it.
    >
    >
    >>It sure looks like you're saying that the Alpha doesn't know how to
    >>talk to tape (ANY tape) to me!
    >>

    >
    >
    > "The" Alpha - meaning the one machine sitting >>> here <<< doesn't
    > know how to talk to that one tape. There is a hardware issue with
    > this *one* Alpha.
    >
    > I'm dead sure that Alpha machines running VMS have no trouble talking
    > to tape drives.
    >
    > But to swing this around to a more productive subject, what backup options
    > are available on low end Itanimum Integrity systems that would be suitable
    > for daily use by non-technical users.
    >
    > Hardly any of the very small SMB shops will have the backup capability I
    > have here, nor the skill to engineer a disaster recovery situation. I
    > need to do that for them, on the cheap, and in such as way as it is not
    > too ornerous for them to do every day.
    >
    > Stick a tape in and go away will probably be about the level I need to
    > get to.
    >
    > Given that a very small SMB install might not have all that much data,
    > a DVD backup might not be out of the question, but it is more expensive.
    >
    > Going along that line of thought, here is what I pretty much envision
    > at least attempting to do, none of which will prove out until I put an
    > Itanium machine here to test it on.
    >
    > (1) Recovery DVD that blows an IPL image onto a disk with both VMS and my
    > software.
    > Result should be a booting system with software up to date with the last
    > recovery
    > DVD version I put together. Preferably the DVD is bootable and will start
    > the recovery
    > procedure after asking the user to okay it.
    >
    > (2) Some kind of rewritable or daily storage that contains images of, or
    > periodic
    > full backups and incremental backups of the critical data and any software
    > patches
    > installed on the system.
    >
    > (3) Recovery/whatever program or DCL or ??? that manages the restore of the
    > data.
    >
    >
    > So in a worst case disaster recovery situation, the user will receive a new
    > machine,
    > stick in DVD#1, IPL, follow the prompts and 15 minutes later come out with a
    > machine
    > that boots into the base software.
    >
    > He then loads Tape, DVD#2, whatever it winds up being, and restores his
    > application data and
    > any patches that may have been put on the system since the DVD version.
    >
    > He re-ipls, and zap... he is back in business. I would like the entire
    > process to take
    > less than an hour, and also be the same or very similar to the process used
    > for a new customer.
    >
    >
    > Larger SMB shops will of course, be more complex as the system will have to
    > be integrated into
    > their existing backup/restore and DR situations. That will take consulting
    > $$ most likely.
    >
    > See the idea though? Everything about the entire process needs to be simple,
    > documented, and
    > as standardized as possible, otherwise we will drown under a landslide of
    > support requests.
    > It is also why I am not overly concerned with the Alpha tape drive
    > working or not.
    > I simply lack the detailed knowledge of the Integrity platform necessary to
    > make any
    > rational descisions along those lines.
    >
    > Advice or suggestions always welcome, as with the recent WASD webserver
    > thing.
    >
    >
    > -Paul
    >



    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  15. Re: COBOL Transactions?


    "Main, Kerry" wrote in message
    news:C72D63EB292C9E49AED23F705C61957BDE935D97FC@G1 W0487.americas.hpqcorp.net...



    For greater HA, install local HW RAID or host based volume shadowing for all
    disks. This
    might be a higher charge option for SMB's that do not want to worry about
    tapes, and want
    to minimize any dealing with any server issues etc



    I'm a bit late to this particlar party, but doesn't there seem to be some
    opportunity for confusion here between the not-all-that-related topics of
    backups vs RAID/data availability? Backups+journals serve quite different
    purposes than RAID. IE what happens when human error or application error
    causes the data on disk to be readable but invalid ? A RAID array on its own
    gives you a highly available but worthless set of data. Proper procedures
    based on tape-style backups (and hopefully some kind of journalling)
    hopefully provide a copy of the "last known good" data (as at the most
    recent backup/snapshot) and combined with suitable journalling can be quite
    handy in restoring the data to a usable state. Obviously tape-style backups
    don't actually have to go to tape either these days; disk (real or USB) may
    be equally useful.

    The end user might not be the one to do the restore in the case of a data
    corruption, but without a proper backup how is that restore going to be
    possible at all? It's been my experience that user/application error is at
    least as likely as hardware failure, but maybe I've just been lucky with
    hardware.

    Regards
    John




  16. RE: COBOL Transactions?


    > -----Original Message-----
    > From: John Wallace [mailto:johnwallace4@yahoo.spam.co.uk]
    > Sent: September 2, 2007 6:26 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    >
    > "Main, Kerry" wrote in message
    > news:C72D63EB292C9E49AED23F705C61957BDE935D97FC@G1 W0487.americas.hpqcor
    > p.net...
    >
    >
    >
    > For greater HA, install local HW RAID or host based volume shadowing
    > for all
    > disks. This
    > might be a higher charge option for SMB's that do not want to worry
    > about
    > tapes, and want
    > to minimize any dealing with any server issues etc
    >
    >
    >
    > I'm a bit late to this particlar party, but doesn't there seem to be
    > some
    > opportunity for confusion here between the not-all-that-related topics
    > of
    > backups vs RAID/data availability? Backups+journals serve quite
    > different
    > purposes than RAID. IE what happens when human error or application
    > error
    > causes the data on disk to be readable but invalid ? A RAID array on
    > its own
    > gives you a highly available but worthless set of data. Proper
    > procedures
    > based on tape-style backups (and hopefully some kind of journalling)
    > hopefully provide a copy of the "last known good" data (as at the most
    > recent backup/snapshot) and combined with suitable journalling can be
    > quite
    > handy in restoring the data to a usable state. Obviously tape-style
    > backups
    > don't actually have to go to tape either these days; disk (real or USB)
    > may
    > be equally useful.
    >
    > The end user might not be the one to do the restore in the case of a
    > data
    > corruption, but without a proper backup how is that restore going to be
    > possible at all? It's been my experience that user/application error
    > is at
    > least as likely as hardware failure, but maybe I've just been lucky
    > with
    > hardware.
    >
    > Regards
    > John


    John,

    I was not promoting not doing backups, but rather still doing backups to a designated
    Maint disk locally with regular off-site backups copied to a remote site, then a DVD/tape
    is created & shipped to a company that handles media archiving. This then provides the
    capability for someone remotely to restore the files from the online disk backups on the
    "maint" disk and also do a DR restore if required.

    To ensure a lights-out environment as much as possible, one option is to build HA Features
    using either HBVS or HW RAID into the overall solution.

    The issue with tapes locally in any environment where there are only secretaries or office
    admin staff is that they are constantly forgetting to change tapes or put the wrong one in
    or the person responsible goes on vacation and hence the backup process is constantly at
    risk. Even SMB customers can no longer afford to have a DC fire or DB corruption or
    accidental critical file deletion where they can not recover. Hence, even if it does cost
    a bit more (additional fee perhaps?), imho, a SMB solution should be considering these
    "lights-out" options.

    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 2 of 2 FirstFirst 1 2