Re: COBOL Transactions? - VMS

This is a discussion on Re: COBOL Transactions? - VMS ; On Aug 23, 9:19 pm, "Paul Raulerson" wrote: >> The only issue with >> the Alpha is that the 4mm tape drive on it does not seem to be recognized. > >Given your inexperience with OpenVMS, perhaps you just don't ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: Re: COBOL Transactions?

  1. Re: COBOL Transactions?

    On Aug 23, 9:19 pm, "Paul Raulerson" wrote:
    >> The only issue with
    >> the Alpha is that the 4mm tape drive on it does not seem to be recognized.

    >
    >Given your inexperience with OpenVMS, perhaps you just don't know
    >where to look for the device name?
    >
    >Have you tried $SHOW DEVICE MK


    Well, it shows up if you do a show dev at the bios prompt, but not in VMS, even with a SHOW DEV /FULL/PAGE and looking pretty carefully for anything tht says "tape" in it.

    As you suggest below, either the tape drive is dead or the Sony 4mm drivein the machine is just not recognized by VMS.

    >Maybe the tape drive is dead? Hardware failures have been known to
    >occur.
    >
    >> off to the UNIX machine which *does* know how to
    >> talk to tape.

    >
    >This is what makes you so annoying. You have admitted to having
    >little experience with OpenVMS and yet you make statements like
    >"OpenVMS can't do X like all those other operating systems". IIRC at
    >every turn you've been shown to be incorrect about OpenVMS'
    >capabilities.


    Boy are you ever sensitive.

    By your statement, what you are saying is that I am incorrect that:
    OpenVMS can be a sucessful replacement for a mainframe platform
    OpenVMS on Itanium is a viable platform for SMB business clients
    OpenVMS has one of the better COBOL compilers I have ever seen
    OpenVMS has a record aware file system
    OpenVMS is well supported by HP, and will probably be around for years

    And so forth and so on.

    What you *seem* to be objecting to is when I say, "Here is what I need todo,
    here is how I would normally do it, what is the facility under VMS that does this?"

    Rather than complaining that someone is comparing and contrasting VMS to other commercial systems, you might want to consider *why*.

    In the partial quote you used as an example above, you left out the part that the hardware the tape is on is an Alpha that I picked up for just about nothing, and I also said I need to move it to a new (or used) supported Itanium machine.

    Why in heavens name would I, or *anyone* for that matter, go chasing around a hunk of hardware that is either not supported or simply broken when the needed capabilty is available on another resource which is working?

    Better yet, why in heavens name would you assume I would NOT backup valuable (at least to me) work on which I have spent much time and effort?


    >Of course OpenVMS can work with tapes. Even file-oriented if that's
    >your desire. Get the hardware working, learn to recognize the device
    >name, and then it'll be trivial to do a backup to tape.


    Why bother? I was talking mostly about hardware.

    >Rather than making statements about what OpenVMS can or can't do,
    >you'd be a lot better served (and earn more respect) by learning to
    >ask questions first. Like, "how do I find my tape drive"


    Gee, I kind of went through that with SCSI controllers; if a device showsup in the bios when you do a SHOW DEV, but not in VMS when you do a SHOWDEV, chances are it is not recognized by VMS.

    I'm willing to hear what you think is wrong with that statement. Are you saying that is probably not true? I do have an old Compaq DTL tape I was thinking of connecting to it, and an old DEC 4mm tape. Just haven't bothered to do so since in reality, backup is going to be an issue for SMB andI don't have the best answer for that. Sure seems like a question to me.



    , "is there
    >an RPG compiler for OpenVMS",


    Kerry sent a link on that the other day. The reason I did not reply is that the website maintains it is an RPG-II compiler. Being first as it was very kind of Kerry to do so, and second, as most people here have probably never ever seen RPG, I did not publicy reply that the current version of RPG is RPGIV, and is based upon an ILE base. A modern RPGIV program would be virutally unrecognizable to an RPG-II programmer, given as most modern programs do *not* use "the cycle", have a ton of built in fuctions, are written in free-form syntax, and so on and so forth. In other words, it is less trouble to convert the RPG to COBOL or even Assembler than it is to try and rewrite it RPG-II.

    Now that everyone is throughly bored by a paragraph talking about something that is not really even relevant in the VMS world...


    "is it RDB or RMS that handles indexed
    >file support"


    Okay, what is the equivalent in RMS of sepcifying the CI intervals to control splits? How large a file can RMS support, and where and when does the indexing start to bog down because of size? Is there an significant impact on the indexing performance with software raid and if so, what is thecost/benefit ratio that determines when it makes sense to move to hardware raid? How easy is it to expand VMS volumes when necessary, and when/where does degration of performance set in? (If you don't understand what Imean by degredation, consider it in light of the CI question above.)

    Okay, I admit to being just a bit annoyed with the level of your complaint. I don't put a lot of that stuff out there because the people here contribute answers out of the goodness of their heart. I have not sent any ofthem a check for their answers (well, outside of HP in general that is) and don't consider it polite to ask questions that I can usually find theanswer to,
    either by experiment or digging though manuals.

    You want a real complaint about VMS? The documentation isn't cross referenced well enough, and when you search through the PDF manual files, the PDF files are not bookmarked. You cannot click on the table of contents entry for a sectoin and have the PDF jump to that section. Nope- you have to SCROLL to page 6-11 or whatever. There - a real honest to goodness complaint about VMS!


    >"how do I convert a status value to text in Cobol",
    >etcetera.


    I know how to convert status values; the real question there should have been "how does the Alpha hold signed COMP values and how is Itanium different?" Obviously that is a question I can go look up myself, and then I might remember it next time I need it.


    In short, VMS, in a very real sense, is in competition with other systems. If you do not compare and contrast everything, a potentional customer *will* do so, and you run the risk of loosing that customer to competitionwho *did* do all their homework.

    Anyone here annoyed by those comparisions, well - I apologize for that. On the other hand, I very much APPRECIATE the people here who are not insulted and who are very very helpful.

    It is a little depressing sometimes to hear the horror stories about non-support for VMS from HP. I do not doubt at all the veracity of those who have those stories, but I have not personally seen that problem.

    Also remember, VMS is *not* a "mainstream" environment any longer, which is in many ways an advantage, but in many other ways, means taking what is common in VMS-land and having to translate it to the equivalent common facilty in Mainstream-land. None of which is a "cut down" to VMS.

    If you want rough and insulting? Look into Windows. If you don't do everything the "Microsoft" way, you are out of date, antiquated, or just incapable of understanding any "advanced" topic. It isn't that way in the mainframe, or VMS, worlds. At least, not very much so.


    -Paul







  2. Re: COBOL Transactions?

    On Fri, 24 Aug 2007 08:15:06 -0700, Paul Raulerson
    wrote:

    >> Have you tried $SHOW DEVICE MK

    > Well, it shows up if you do a show dev at the bios prompt, but not in
    > VMS, even with a SHOW DEV /FULL/PAGE and looking pretty carefully for
    > anything tht says "tape" in it.
    > As you suggest below, either the tape drive is dead or the Sony 4mm
    > drive in the machine is just not recognized by VMS.


    maybe the tape driver isn't loaded, try
    $ mc sysman
    SYSMAN> io auto




    --
    PL/I for OpenVMS
    www.kednos.com

  3. Re: COBOL Transactions?

    On Aug 24, 11:15 am, "Paul Raulerson" wrote:

    >>What you *seem* to be objecting to is when I say, "Here is what I
    >>need to do, here is how I would normally do it, what is the facility
    >>under VMS that does this?"


    Without rereading everything you've ever posted I'd have to say that
    I don't recall ever seeing you pose a question in that form.

    What you have done -- and what disturbs me -- is make statements (or
    implications) about OpenVMS' inability to perform a variety of tasks
    when you have no knowledge of whether or not it can do those things.

    For example, here are some things you have said ...

    >>> The only issue with the Alpha is that the 4mm tape drive on it
    >>> does not seem to be recognized. ... and off to the UNIX machine
    >>> which *does* know how to talk to tape.


    The implication is that OpenVMS *doesn't* "know how to talk to tape"
    so you have to revert to a Unix box to get that done. Well, of course
    OpenVMS does work with tapes, and if it's a working SCSI drive then
    you'd see either an MK or GK device name.

    >>> When I create an indexed file in COBOL, is it using Rdb? If so,
    >>> it quacks a lot like a filesystem to me.


    >>> if they are VSAM (which is the the same as RDB on VMS)


    >>> I looked at Rdb mainly in relation to how it acts as an indexed
    >>> file system, not as a database.


    >>> DB2 has had federated databases for more than a decade, well before
    >>> Oracle. RDB is file based, I'm not sure how it can do that,
    >>> especially over slower global WAN connections.


    You made a lot of statements about RDB's limitations when comparing
    it to DB2. Unfortunately, in your ignorance of OpenVMS, what you
    were really doing was comparing RMS to DB2.

    Applying your new question format (at the top of this posting) then
    what you should have written was something like "DB2 has had
    federated databases for more than a decade, what is the facility
    under VMS that does this?"

    You might have had to explain "federated databases" since it's not
    terminology that's used in the OpenVMS space, but at least asking the
    question rather than making statements about what RDB can't do because
    you think it's similar to VSAM wouldn't make you look so foolish.

    >>> How about little things like really erasing the data on a DASD unit?


    That was a perfect opportunity for the new question format: "z/OS has
    a
    facility for writing erase patterns on disk. What is the method for
    erasing the data on a DASD unit under OpenVMS?"

    Oh, but you didn't do that. Instead you listed a bunch of things you
    felt weren't available in OpenVMS. Sure, you put a question mark
    on the end but your implication was that the facilities weren't
    available
    in OpenVMS at all.

    I can go on and on, and you probably know it.

    >> In the partial quote you used as an example above, you left out the
    >> part that the hardware the tape is on is an Alpha that I picked up
    >> for just about nothing, and I also said I need to move it to a new
    >> (or used) supported Itanium machine.


    Not relevant, as I pointed out above that the issue I had was with
    your
    implication that OpenVMS couldn't handle tapes at all.

    I've bought used systems on eBay as well and never had a problem
    getting
    the hardware to work. Of course, I've got a lot more experience with
    OpenVMS than you do.

    While we're here, though, are you sure that your dirt cheap Alpha was
    qualified by Digital/Compaq/HP to run OpenVMS at all?

    >> Why in heavens name would I, or *anyone* for that matter, go chasing
    >> around a hunk of hardware that is either not supported or simply
    >> broken when the needed capabilty is available on another resource
    >> which is working?


    Because it's your development system and most people I know would like
    their development systems to be fully functional. How will you
    develop
    a backup procedure for your client's on Alpha if you can't get it to
    work at home? How will you back up your ported source code at the
    HP porting event if you haven't practiced it under OpenVMS at home?

    (And, even though you profess to port to Integrity you may come across
    a potential sale of your software at a client that already has Alpha
    and doesn't want to buy new systems. Be prepared.)

    >> Better yet, why in heavens name would you assume I would NOT backup
    >> valuable (at least to me) work on which I have spent much time
    >> and effort?


    Huh? Where did I make that assumption?

    Never mind, don't answer. I suspect you'll go off on a trillion
    tangents like this last posting of yours. The "baffle them with
    bull****" method.

    >> if a device shows up in the bios when you do a SHOW DEV, but not in
    >> VMS when you do a SHOW DEV, chances are it is not recognized by VMS.


    Let's try this in the new question format: "If a device shows up in
    the
    bios when you do a SHOW DEV, but not in VMS when you do a SHOW DEV,
    does
    that mean it is not recognized by VMS?"

    Notice the difference. A question rather than a statement that
    "chances
    are it is not recognized by VMS". What do you base that statement on?
    Your two months of OpenVMS experience? How much do you know about how
    OpenVMS handles unrecognized drive types?



  4. Re: COBOL Transactions?

    In article , "Paul Raulerson" writes:

    >, "is there
    >>an RPG compiler for OpenVMS",

    >
    >Kerry sent a link on that the other day. The reason I did not reply is th=
    >at the website maintains it is an RPG-II compiler. Being first as it was =
    >very kind of Kerry to do so, and second, as most people here have probabl=
    >y never ever seen RPG, I did not publicy reply that the current version o=
    >f RPG is RPGIV, and is based upon an ILE base. A modern RPGIV program wou=
    >ld be virutally unrecognizable to an RPG-II programmer, given as most mod=
    >ern programs do *not* use "the cycle", have a ton of built in fuctions, a=
    >re written in free-form syntax, and so on and so forth. In other words, i=
    >t is less trouble to convert the RPG to COBOL or even Assembler than it i=
    >s to try and rewrite it RPG-II.



    Wow. (I took an RPG-II class in school about 1979. The language you're
    describing really isn't something I'd recognize. I would have thought those
    features (column orientation, easy automatic totals, etc, etc) were the main
    reasons for the language to even *exist*. How did it evolve in this way?

    >
    >Now that everyone is throughly bored by a paragraph talking about somethi=
    >ng that is not really even relevant in the VMS world...
    >


    Well, not everyone.


    >
    >"is it RDB or RMS that handles indexed
    >>file support"

    >
    >Okay, what is the equivalent in RMS of sepcifying the CI intervals to con=
    >trol splits? How large a file can RMS support, and where and when does th=
    >e indexing start to bog down because of size? Is there an significant imp=
    >act on the indexing performance with software raid and if so, what is the=
    > cost/benefit ratio that determines when it makes sense to move to hardwa=
    >re raid?


    I bet Hein can answer those questions for you. (I am _not_ an RMS jock.)

    >How easy is it to expand VMS volumes when necessary, and when/wh=
    >ere does degration of performance set in? (If you don't understand what I=
    > mean by degredation, consider it in light of the CI question above.)
    >


    If volumes means what I think it means (and maybe it doesn't), if you have a
    'disk' on a SAN (so the actualy underlying volume can actually change size when
    you twiddle the SAN bits to allocate more apce to it), life is good if you
    initially did a

    $ SET VOLUME/LIMIT

    when you first set the disk up, since that enables the volume to have its size
    reset up to the VMS limit (1 Terabyte per volume) without having to dismount
    the volume or otherwise take it out of service, just by using the

    $ SET VOLUME/SIZE

    command. (If you neglected to do the $ SET VOLUME /LIMIT while you had the
    disk mounted privately, you have to dismount it and remount it privately to
    issue the command.)

    I guess you could also use this if you did an image backup from a small real
    disk to a large one, but there you could also have done an INIT of the large
    disk with the parameters you wanted and a BACKUP/IMAGE/NOINIT to copy the data
    but keep your new strucutre.

    -- Alan


  5. Re: COBOL Transactions?

    On Aug 24, 5:50 pm, wins...@SSRL.SLAC.STANFORD.EDU (Alan Winston -
    SSRL Central Computing) wrote:
    > In article , "Paul Raulerson" writes:


    > >"is it RDB or RMS that handles indexed file support"


    An important claim to fame for RMS is native support for indexed
    files, available to all OpenVMS languaes, DCL included.

    > >Okay, what is the equivalent in RMS of sepcifying the CI intervals to con trol splits?


    Dunno. A quick google did not enlighten me as to what either might
    mean.

    >> How large a file can RMS support


    It is limited to 1 Terabyte.
    It really should be, and actually might be 2**32 * 512 bytes, but the
    sign bit is not trusted to have been ignored everywhere.

    >> and where and when does the indexing start to bog down because of size?


    Never. It is a simlpe semi-balanced B-tree not known to bog down ever.
    A well designed large index file often only needs 3 index levels, 4
    absolutely worst case. But I've seen poorly designed (NOT designed)
    indexed files with 10 index level where the end users where just
    happy, oblivious to significant performance potential available to
    them. RMS Just keeps on working. A blessing and a problem at the same
    time.

    Last weekend I helped a customer convert a 3-key 100GB indexed file in
    less than 2 hours. That's about as big as they are currently in use.
    On the same box RMS was managing a 150GB fixed length record
    sequential file.

    >> Is there an significant impact on the indexing performance with software raid


    That question does not compute for VMS.
    Raid and indexing are orthogonal, independend technologies.
    Raid and help or hurt indexed file access (it tends to help) but your
    typical, even your sophisticated, indexed file user would only worry
    abot raid as a last recourse.

    >> and if so, what is the cost/benefit ratio that determines when it makes sense to move to hardware raid?


    That still does not compute. At best it is of marginal relevance (less
    than 10% performance potential)

    > I bet Hein can answer those questions for you. (I am _not_ an RMS jock.)


    Was my name called? :-)

    > >How easy is it to expand VMS volumes when necessary,


    Somewhat easy, but best avoided.
    You can MOUNT a second disk to create a bound volume set.

    >> and when/where does degration of performance set in? (If you don't understand what I mean by degredation, consider it in light of the CI question above.)


    ZERO degradation (well, ok, an extra file header access at times).

    > If volumes means what I think it means (and maybe it doesn't), if you have a 'disk' on a SAN (so the actualy underlying volume can actually change size when you twiddle the SAN bits to allocate more apce to it), life is good if you


    Yes. Life is good. (since a few years now)

    The big beauty of RMS perhpas is TRANSPARANCY.
    It isolates program from storage considerations.

    hth,
    Hein


  6. RE: COBOL Transactions?


    >
    > On Aug 24, 11:15 am, "Paul Raulerson" wrote:
    >
    > >>What you *seem* to be objecting to is when I say, "Here is what I
    > >>need to do, here is how I would normally do it, what is the facility
    > >>under VMS that does this?"

    >
    > Without rereading everything you've ever posted I'd have to say that
    > I don't recall ever seeing you pose a question in that form.
    >


    Well, that could well be. Electronic communications often lack the richness
    of face to face or more formal communications. That does not, however,
    imply that there was any malicious, or other intent.

    Or in other words, you are reading far more into a simple statement than
    what is really there.

    > What you have done -- and what disturbs me -- is make statements (or
    > implications) about OpenVMS' inability to perform a variety of tasks
    > when you have no knowledge of whether or not it can do those things.
    >
    > For example, here are some things you have said ...
    >
    > >>> The only issue with the Alpha is that the 4mm tape drive on it
    > >>> does not seem to be recognized. ... and off to the UNIX machine
    > >>> which *does* know how to talk to tape.

    >


    I'll use this one as an example. Perhaps if I had said "talk to *a* tape"
    it would have disturbed you less. But in actual, plain, unassailable fact,
    the ALPHA *machine* does NOT know how to talk to a tape right now.
    The UNIX *machine* does. There is not implication at all regarding
    a comparison to Operating Systems there.


    > >>> When I create an indexed file in COBOL, is it using Rdb? If so,
    > >>> it quacks a lot like a filesystem to me.

    >
    > >>> if they are VSAM (which is the the same as RDB on VMS)


    So ignorance is a crime? Several people pointed out to the that RDB
    is a database, and RMS is a file system. I believe I expressed
    embarrassment at that. On the other hand, how many people here
    might mix up a 3390 and 3990 in the mainframe world? Probably a
    few.

    > >> Why in heavens name would I, or *anyone* for that matter, go chasing
    > >> around a hunk of hardware that is either not supported or simply
    > >> broken when the needed capabilty is available on another resource
    > >> which is working?

    >
    > Because it's your development system and most people I know would like
    > their development systems to be fully functional. How will you
    > develop
    > a backup procedure for your client's on Alpha if you can't get it to
    > work at home? How will you back up your ported source code at the
    > HP porting event if you haven't practiced it under OpenVMS at home?
    >


    I won't be supporting Alphas - only Itanium. There might be some compelling
    reasons to support Alpha's I don't know about. There are probably reasons
    to support Vax's. But, to the best of my knowledge, the compelling business
    case is to support Itanium.

    > (And, even though you profess to port to Integrity you may come across
    > a potential sale of your software at a client that already has Alpha
    > and doesn't want to buy new systems. Be prepared.)
    >
    > >> Better yet, why in heavens name would you assume I would NOT backup
    > >> valuable (at least to me) work on which I have spent much time
    > >> and effort?

    >
    > Huh? Where did I make that assumption?
    >


    When you assumed I was complaining that VMS would not talk to tape of
    course.
    What else could you possibly have meant?

    I do believe again you are reading much more into simple questions,
    sometimes driven by excitement, than is reasonable to assume. I am
    really developing a passion for VMS, but - I don't have time to explore
    all the things I would like to do now. I really really don't have much
    time at all to fight with hardware I intend to replace. In the meantime,
    I intend to use that same resource to best effect.

    By the way, when I bought it, it was just to play with. I had no idea that
    VMS was a viable platform to port our software to, or use for some of the
    things I have learned it is useful for.

    As for my experience level - well- I'll send you a set of mainframe disks if
    you wish. You are welcome to try and get to a comparable level of
    inexperience
    in a few months. The situations are very close.

    If you feel that I am being abrasive in some way, then I feel bad for you
    and
    will try to be more polite to you in the future. If on the other hand, you
    think I have time to waste and should not be able to make decisions about
    hardware and such, then I am truly sorry but I disagree. Especially about
    something as simple as a misbehaving tape drive. (Again note, I am talking
    about hardware - a tape drive - has nothing to do with VMS.)

    By the way, just would your experience tell is the case when a tape device
    shows
    up in the bios SHOW DEV but not in the VMS SHOW DEV?

    -Paul



  7. RE: COBOL Transactions?

    LOL! Well Alan, thank you for that thoughtful answer. I layered a bit of
    sarcasm in there
    which you gallantly and kindly ignored. Comments below...
    -Paul

    > -----Original Message-----
    > From: Alan Winston - SSRL Central Computing
    > [mailto:winston@SSRL.SLAC.STANFORD.EDU]
    > Sent: Friday, August 24, 2007 4:50 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > Wow. (I took an RPG-II class in school about 1979. The language
    > you're
    > describing really isn't something I'd recognize. I would have thought
    > those
    > features (column orientation, easy automatic totals, etc, etc) were the
    > main
    > reasons for the language to even *exist*. How did it evolve in this
    > way?
    >


    (Truth in Posting: I do have a financial interest
    in a commercial RPG Compiler for Windows.)

    It really isn't the same language anymore.
    Here's a snippet of fairly modern RPG code:

    // Loop through replacing FILENAME with the value from the input parameter.


    Read QFTPSRC; // Priming read.
    DoW NOT %eof(QFTPSRC); // Begin main
    processing loop.
    position =%Scan('FILENAME':SRCDTA);
    if position > 0;
    SRCDTA = %Replace(%TrimR(filename):SRCDTAosition:8);
    Update FTPREC;
    endif;
    Read QFTPSRC; // Get next record for
    loop.
    EndDo; // End main processing
    loop.

    The language evolved primarily on the AS/400 systems, because people just
    started doing pretty fantastic things with it. The snippet above, for
    instance
    is working with a programmatic FTP transfer.

    >
    > I bet Hein can answer those questions for you. (I am _not_ an RMS
    > jock.)
    >

    I bet he can too.

    > >How easy is it to expand VMS volumes when necessary, and when/wh=
    > >ere does degration of performance set in? (If you don't understand

    > what I=
    > > mean by degredation, consider it in light of the CI question above.)
    > >

    >
    > If volumes means what I think it means (and maybe it doesn't), if you
    > have a
    > 'disk' on a SAN (so the actualy underlying volume can actually change
    > size when
    > you twiddle the SAN bits to allocate more apce to it), life is good if
    > you
    > initially did a
    >
    > $ SET VOLUME/LIMIT
    >
    > when you first set the disk up, since that enables the volume to have
    > its size
    > reset up to the VMS limit (1 Terabyte per volume) without having to
    > dismount
    > the volume or otherwise take it out of service, just by using the
    >
    > $ SET VOLUME/SIZE
    >


    I think we mean the same things by a "volume."

    Very cool information. The one terabyte limit is not a problem in the
    SMB world I think, though it could grow to be I suppose. Or there are ways
    around it I bet.

    Thanks -Paul



  8. RE: COBOL Transactions?

    Aw gee- now I feel a bit abashed again at the mild sarcasm in the
    referenced message. A few comments below.


    > -----Original Message-----
    > From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com]
    > Sent: Friday, August 24, 2007 8:23 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > On Aug 24, 5:50 pm, wins...@SSRL.SLAC.STANFORD.EDU (Alan Winston -
    > SSRL Central Computing) wrote:
    > > In article , "Paul Raulerson"

    > writes:
    >
    > > >"is it RDB or RMS that handles indexed file support"

    >
    > An important claim to fame for RMS is native support for indexed
    > files, available to all OpenVMS languaes, DCL included.
    >

    Yes, and this is more than just claim to fame, it is *really* good
    stuff. And impressive work. Simple in some ways, but elegant.


    > > >Okay, what is the equivalent in RMS of sepcifying the CI intervals

    > to con trol splits?
    >
    > Dunno. A quick google did not enlighten me as to what either might
    > mean.


    This was really unfair, since it is involved with VSAM tuning, a black art
    if ever there was one. CI is Control-Interval and CA is Control Area. A
    CA is formed by two or more CIs put together, are fixed length, and
    continguous
    on the DASD. They are *usually* the size of the DASD cylinder.

    When a CI is full and there is no room to insert a new record, a CI split
    will
    occur, meaning half the records will be moved to a new CI in the same CA. A
    CI
    split will cause I/O to the index (which can cause splits as well) and to
    several
    other components that I cannot really remember.

    If the CA fills up (or a couple other strange conditions) then a CA split
    will
    occur, which is as you imagine, relatively expensive in terms of I/O. That's
    before
    you look into updating the alternate indicies and such as well.

    VSAM looks at this stuff, and in general, the CI size you pick, especially
    for the
    data component of a VSAM file, can really affect performance. Picking a
    large CI
    in an online environment is usually less than optimal. here... >

    What it boils down to is that on a mainframe, the VSAM performance can be
    highly
    tuned based on hardware knowledge and so forth. VSAM has been optimized for
    many years,
    as I am sure, has RMS, and they are always hunting for more efficient
    strategies. VSAM
    is the underlying technology for DB/2 on the mainframe as well.

    If you are really interested, I can send you plenty of good reading.



    >
    > >> How large a file can RMS support

    >
    > It is limited to 1 Terabyte.
    > It really should be, and actually might be 2**32 * 512 bytes, but the
    > sign bit is not trusted to have been ignored everywhere.
    >

    I think VSAM is currently limited to a couple terabytes per individual file,
    but I have not ran into that limit recently.


    > >> and where and when does the indexing start to bog down because of

    > size?
    >
    > Never. It is a simlpe semi-balanced B-tree not known to bog down ever.
    > A well designed large index file often only needs 3 index levels, 4
    > absolutely worst case.


    That's sweet- I assume it is doing something under the covers like storing
    the block address for the each record in the index(s) and then just
    searching
    the relevant data block for the actual record? (Greatly simplified I am
    sure...


    >But I've seen poorly designed (NOT designed)
    > indexed files with 10 index level where the end users where just
    > happy, oblivious to significant performance potential available to
    > them. RMS Just keeps on working. A blessing and a problem at the same
    > time.
    >


    Yes indeed. Seen that, been guilty of it once myself. I learned.


    > Last weekend I helped a customer convert a 3-key 100GB indexed file in
    > less than 2 hours. That's about as big as they are currently in use.
    > On the same box RMS was managing a 150GB fixed length record
    > sequential file.
    >


    That's quite respectable. I have a project in mind I want to explore
    that would keep a lot of tiny little files on the system, and provide
    them upon request to the web.

    How does RMS handle variable length sequential (and indexed) records?
    Is it very efficient with them, packing them well into data blocks, or
    does it overlay them on fixed length records?


    > >> Is there an significant impact on the indexing performance with

    > software raid
    >
    > That question does not compute for VMS.
    > Raid and indexing are orthogonal, independend technologies.
    > Raid and help or hurt indexed file access (it tends to help) but your
    > typical, even your sophisticated, indexed file user would only worry
    > abot raid as a last recourse.
    >


    I can see that. It would on a mainframe because of the tight tuning
    in terms of hardware. Different DASD, different tuning parameters.

    > >> and if so, what is the cost/benefit ratio that determines when it

    > makes sense to move to hardware raid?
    >
    > That still does not compute. At best it is of marginal relevance (less
    > than 10% performance potential)


    On the mainframe, RAID storage in a SAN is "cheap" compared to just about
    any
    other type of available storage. Cheap is relative - around $15K per
    terabyte used,
    and $48K per terabyte new is average.


    >
    > > I bet Hein can answer those questions for you. (I am _not_ an RMS

    > jock.)
    >
    > Was my name called? :-)
    >
    > > >How easy is it to expand VMS volumes when necessary,

    >
    > Somewhat easy, but best avoided.
    > You can MOUNT a second disk to create a bound volume set.
    >


    Ah- how large can "volume sets" grow? I was thinking of a volume
    as what you have identified as a "volume set."

    > >> and when/where does degration of performance set in? (If you don't

    > understand what I mean by degredation, consider it in light of the CI
    > question above.)
    >
    > ZERO degradation (well, ok, an extra file header access at times).
    >


    I like that, though I am not sure how it can be true. Are there
    any good books about VMS RMS? I just scanned Ebay and Powells, but
    didn't find anything.


    > > If volumes means what I think it means (and maybe it doesn't), if you

    > have a 'disk' on a SAN (so the actualy underlying volume can actually
    > change size when you twiddle the SAN bits to allocate more apce to it),
    > life is good if you
    >
    > Yes. Life is good. (since a few years now)
    >
    > The big beauty of RMS perhpas is TRANSPARANCY.
    > It isolates program from storage considerations.
    >


    Amen- that is a beautiful thing, but also a bit scary in a way.
    Not really anything to worry about in any case.




    > hth,
    > Hein




  9. RE: COBOL Transactions?

    In article <008e01c7e6ba$aeffbe50$0cff3af0$@com>, "Paul Raulerson" writes:

    >LOL! Well Alan, thank you for that thoughtful answer. I layered a bit of
    >sarcasm in there
    >which you gallantly and kindly ignored. Comments below...


    I read you as being involved in making a serious effort to port code that you
    believe will let you sell VMS into the SMB space, which is someplace that I
    have long felt VMS ought to be, and which HP hasn't seemed to be particularly
    interested in. (An OS that, once configured properly, is pretty close to
    bulletproof and doesn't require a full-time system administrator makes a whole
    lot of space, for, eg, the system that runs a video store or a clothing store,
    etc. But HP needs to make it cheap enough and provide entry-level systems.)

    Anyway, your project is something I'm very much in favor of, since I want more
    new/more customers for VMS so that the division remains profitable and I get to
    keep working on it. I don't want this to be an exclusive club.

    That motivates me to ignore sarcasm.

    >> -----Original Message-----
    >> From: Alan Winston - SSRL Central Computing
    >> [mailto:winston@SSRL.SLAC.STANFORD.EDU]
    >> Sent: Friday, August 24, 2007 4:50 PM
    >> To: Info-VAX@Mvb.Saic.Com
    >> Subject: Re: COBOL Transactions?
    >>
    >> Wow. (I took an RPG-II class in school about 1979. The language
    >> you're
    >> describing really isn't something I'd recognize. I would have thought
    >> those
    >> features (column orientation, easy automatic totals, etc, etc) were the
    >> main
    >> reasons for the language to even *exist*. How did it evolve in this
    >> way?
    >>

    >
    >(Truth in Posting: I do have a financial interest
    >in a commercial RPG Compiler for Windows.)
    >
    >It really isn't the same language anymore.
    >Here's a snippet of fairly modern RPG code:
    >
    >// Loop through replacing FILENAME with the value from the input parameter.
    >
    >
    > Read QFTPSRC; // Priming read.
    > DoW NOT %eof(QFTPSRC); // Begin main
    >processing loop.
    > position =%Scan('FILENAME':SRCDTA);
    > if position > 0;
    > SRCDTA = %Replace(%TrimR(filename):SRCDTAosition:8);
    > Update FTPREC;
    > endif;
    > Read QFTPSRC; // Get next record for
    >loop.
    > EndDo; // End main processing
    >loop.
    >
    >The language evolved primarily on the AS/400 systems, because people just
    >started doing pretty fantastic things with it. The snippet above, for
    >instance
    >is working with a programmatic FTP transfer.


    Wow. If you'd just shown me that code and asked me to guess what language it
    was in, RPG would have been below SNOBOL on the list. (I would probably have
    guessed REXX because I don't know Rexx but this looks like a shell script
    or glue language with a wordy-rather-than-terse background.

    -- Alan

  10. Re: COBOL Transactions?

    On 08/24/07 20:36, Paul Raulerson wrote:
    >> On Aug 24, 11:15 am, "Paul Raulerson" wrote:
    >>

    [snip]
    >>
    >> For example, here are some things you have said ...
    >>
    >>>>> The only issue with the Alpha is that the 4mm tape drive on it
    >>>>> does not seem to be recognized. ... and off to the UNIX machine
    >>>>> which *does* know how to talk to tape.

    >
    > I'll use this one as an example. Perhaps if I had said "talk to *a* tape"
    > it would have disturbed you less. But in actual, plain, unassailable fact,
    > the ALPHA *machine* does NOT know how to talk to a tape right now.


    And you'd *still* be blindingly wrong. It's stunningly arrogant of
    you to, in essence, say that since you can't figure it out, it can't
    be done.

    I *GUARANTEE* you that thousands of small VMS sites over the years
    have used 4mm and 8mm DAT drives to backup their data.

    You've *obviously* and *definitely* done something wrong, and are
    too dense to realize that you are making insultingly *stupid* comments.

    > The UNIX *machine* does. There is not implication at all regarding
    > a comparison to Operating Systems there.

    [snip
    >
    > By the way, just would your experience tell is the case when a tape device
    > shows
    > up in the bios SHOW DEV but not in the VMS SHOW DEV?


    Misconfigured SCSI.

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

    Paul Raulerson wrote:
    >>On Aug 24, 11:15 am, "Paul Raulerson" wrote:
    >>
    >>
    >>>>What you *seem* to be objecting to is when I say, "Here is what I
    >>>>need to do, here is how I would normally do it, what is the facility
    >>>>under VMS that does this?"

    >>
    >>Without rereading everything you've ever posted I'd have to say that
    >>I don't recall ever seeing you pose a question in that form.
    >>

    >
    >
    > Well, that could well be. Electronic communications often lack the richness
    > of face to face or more formal communications. That does not, however,
    > imply that there was any malicious, or other intent.
    >
    > Or in other words, you are reading far more into a simple statement than
    > what is really there.
    >
    >
    >>What you have done -- and what disturbs me -- is make statements (or
    >>implications) about OpenVMS' inability to perform a variety of tasks
    >>when you have no knowledge of whether or not it can do those things.
    >>
    >>For example, here are some things you have said ...
    >>
    >>
    >>>>>The only issue with the Alpha is that the 4mm tape drive on it
    >>>>>does not seem to be recognized. ... and off to the UNIX machine
    >>>>>which *does* know how to talk to tape.

    >>

    >
    > I'll use this one as an example. Perhaps if I had said "talk to *a* tape"
    > it would have disturbed you less. But in actual, plain, unassailable fact,
    > the ALPHA *machine* does NOT know how to talk to a tape right now.
    > The UNIX *machine* does. There is not implication at all regarding
    > a comparison to Operating Systems there.
    >
    >
    >
    >>>>>When I create an indexed file in COBOL, is it using Rdb? If so,
    >>>>>it quacks a lot like a filesystem to me.

    >>
    >>>>>if they are VSAM (which is the the same as RDB on VMS)

    >
    >
    > So ignorance is a crime? Several people pointed out to the that RDB
    > is a database, and RMS is a file system. I believe I expressed
    > embarrassment at that. On the other hand, how many people here
    > might mix up a 3390 and 3990 in the mainframe world? Probably a
    > few.
    >
    >
    >>>>Why in heavens name would I, or *anyone* for that matter, go chasing
    >>>>around a hunk of hardware that is either not supported or simply
    >>>>broken when the needed capabilty is available on another resource
    >>>>which is working?

    >>
    >>Because it's your development system and most people I know would like
    >>their development systems to be fully functional. How will you
    >>develop
    >>a backup procedure for your client's on Alpha if you can't get it to
    >>work at home? How will you back up your ported source code at the
    >>HP porting event if you haven't practiced it under OpenVMS at home?
    >>

    >
    >
    > I won't be supporting Alphas - only Itanium. There might be some compelling
    > reasons to support Alpha's I don't know about. There are probably reasons
    > to support Vax's. But, to the best of my knowledge, the compelling business
    > case is to support Itanium.
    >
    >
    >>(And, even though you profess to port to Integrity you may come across
    >>a potential sale of your software at a client that already has Alpha
    >>and doesn't want to buy new systems. Be prepared.)
    >>
    >>
    >>>>Better yet, why in heavens name would you assume I would NOT backup
    >>>>valuable (at least to me) work on which I have spent much time
    >>>>and effort?

    >>
    >>Huh? Where did I make that assumption?
    >>

    >
    >
    > When you assumed I was complaining that VMS would not talk to tape of
    > course.
    > What else could you possibly have meant?
    >
    > I do believe again you are reading much more into simple questions,
    > sometimes driven by excitement, than is reasonable to assume. I am
    > really developing a passion for VMS, but - I don't have time to explore
    > all the things I would like to do now. I really really don't have much
    > time at all to fight with hardware I intend to replace. In the meantime,
    > I intend to use that same resource to best effect.
    >
    > By the way, when I bought it, it was just to play with. I had no idea that
    > VMS was a viable platform to port our software to, or use for some of the
    > things I have learned it is useful for.
    >
    > As for my experience level - well- I'll send you a set of mainframe disks if
    > you wish. You are welcome to try and get to a comparable level of
    > inexperience
    > in a few months. The situations are very close.
    >
    > If you feel that I am being abrasive in some way, then I feel bad for you
    > and
    > will try to be more polite to you in the future. If on the other hand, you
    > think I have time to waste and should not be able to make decisions about
    > hardware and such, then I am truly sorry but I disagree. Especially about
    > something as simple as a misbehaving tape drive. (Again note, I am talking
    > about hardware - a tape drive - has nothing to do with VMS.)
    >
    > By the way, just would your experience tell is the case when a tape device
    > shows
    > up in the bios SHOW DEV but not in the VMS SHOW DEV?
    >
    > -Paul


    4 reasons I can think of:

    1) The tape drive is broken (but usually, a broken tape drive will show
    up; it just won't work.)

    2) It's an unsupported model. (What does srm's SHOW DEV show about it?
    What model number is it? Is there a sticker or label on the back
    (assuming it's an external tape drive that you can look at.)

    3a) Configuration problem. I think it is possible to disable devices
    by messing with sys$system:sys$config.dat or sys$user_config.dat.
    Maybe yours is broken? (If you installed the system yourself, this
    is very unlikely. If you inherited it from someone else, maybe they
    broke it. In this case, booting from the CD drive and picking the
    "Execute DCL commands" option and then doing a SHOW DEVICE from the
    $$$ prompt might be revealing.

    3b) Configuration problem. Maybe there is a problem with the SCSI
    cables (bad cable, bus length) or termination (missing, double) or
    a dip switch, etc. on the drive itself.

    4) Software problem. I think you said you're running V8.3... I
    don't remember too many problems with this stuff in that version,
    but maybe there is a patch (ECO) to the tape driver or system
    routines that would fix this. (I couldn't find anything obvious
    in a brief scan of the ECO release notes.)


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

  12. RE: COBOL Transactions?



    > -----Original Message-----
    > From: Ron Johnson [mailto:ron.l.johnson@cox.net]
    > Sent: Friday, August 24, 2007 10:17 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > On 08/24/07 20:36, Paul Raulerson wrote:
    > >> On Aug 24, 11:15 am, "Paul Raulerson" wrote:
    > >>

    > [snip]
    > >>
    > >> For example, here are some things you have said ...
    > >>
    > >>>>> The only issue with the Alpha is that the 4mm tape drive on it
    > >>>>> does not seem to be recognized. ... and off to the UNIX machine
    > >>>>> which *does* know how to talk to tape.

    > >
    > > I'll use this one as an example. Perhaps if I had said "talk to *a*

    > tape"
    > > it would have disturbed you less. But in actual, plain, unassailable

    > fact,
    > > the ALPHA *machine* does NOT know how to talk to a tape right now.

    >


    Why do you insist on reading anything into this other than the tape
    device is not working? What in the world are you hearing?

    Whatever it is, it is NOT what I am saying.


    > And you'd *still* be blindingly wrong. It's stunningly arrogant of
    > you to, in essence, say that since you can't figure it out, it can't
    > be done.
    >
    > I *GUARANTEE* you that thousands of small VMS sites over the years
    > have used 4mm and 8mm DAT drives to backup their data.
    >


    And what has that go to do with anything?


    > You've *obviously* and *definitely* done something wrong, and are
    > too dense to realize that you are making insultingly *stupid* comments.
    >


    Really? Well, I guess I will just go on being dense then. Please explain
    to me why I should believe I have misconfigured a SCSI bus that everything
    else, disk, CD, etc, *works* on, the device is seen by the BIOS, and oh
    yeah,
    if I pull the drive, like I just did, and put it on another machine, it
    works
    fine.

    I'd say that VMS does not support that device.

    Now if ***you*** want to be silly and associate with the word "device",
    with every tape drive in the world and assume someone else is stupid enough
    to not know the difference, that is *your* problem.



    > > The UNIX *machine* does. There is not implication at all regarding
    > > a comparison to Operating Systems there.

    > [snip
    > >
    > > By the way, just would your experience tell is the case when a tape

    > device
    > > shows
    > > up in the bios SHOW DEV but not in the VMS SHOW DEV?

    >
    > Misconfigured SCSI.
    >


    Just to be thorough, I'm not entirely sure how you could misconfigure
    a single SCSI device and not have any other effects on the bus. People
    whose opinions I really respect have indicated that SCSI drives under VMS
    are pretty about what devices they will accept. I see no reason to doubt or
    question that.

    Perhaps you know more than I do though.

    If you insist on putting silly meanings on this, then you might as well
    assume I said something *totally* silly, like VMS blew up my tape drive
    or something. At least that would be humorous.


    -Paul


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



  13. Re: COBOL Transactions?

    On 08/24/07 22:52, Paul Raulerson wrote:
    >
    >> -----Original Message-----
    >> From: Ron Johnson [mailto:ron.l.johnson@cox.net]
    >> Sent: Friday, August 24, 2007 10:17 PM
    >> To: Info-VAX@Mvb.Saic.Com
    >> Subject: Re: COBOL Transactions?
    >>
    >> On 08/24/07 20:36, Paul Raulerson wrote:
    >>>> On Aug 24, 11:15 am, "Paul Raulerson" wrote:
    >>>>

    >> [snip]
    >>>> For example, here are some things you have said ...
    >>>>
    >>>>>>> The only issue with the Alpha is that the 4mm tape drive on it
    >>>>>>> does not seem to be recognized. ... and off to the UNIX machine
    >>>>>>> which *does* know how to talk to tape.
    >>> I'll use this one as an example. Perhaps if I had said "talk to *a*

    >> tape"
    >>> it would have disturbed you less. But in actual, plain, unassailable

    >> fact,
    >>> the ALPHA *machine* does NOT know how to talk to a tape right now.

    >
    > Why do you insist on reading anything into this other than the tape
    > device is not working? What in the world are you hearing?


    You've developed an "I don't know how to do it, so VMS must not be
    able to do it" reputation.

    > Whatever it is, it is NOT what I am saying.


    In the post that began this threadlet, you wrote:
    UNIX machine which *does* know how to talk to tape.

    Which, given your poor reputation, leads us to read that you think
    that VMS does *not* know how to talk to tape.

    >> And you'd *still* be blindingly wrong. It's stunningly arrogant of
    >> you to, in essence, say that since you can't figure it out, it can't
    >> be done.
    >>
    >> I *GUARANTEE* you that thousands of small VMS sites over the years
    >> have used 4mm and 8mm DAT drives to backup their data.
    >>

    >
    > And what has that go to do with anything?


    Shows that VMS does (and has for ages) recognize 4mm DAT drives.

    >> You've *obviously* and *definitely* done something wrong, and are
    >> too dense to realize that you are making insultingly *stupid* comments.
    >>

    >
    > Really? Well, I guess I will just go on being dense then. Please explain
    > to me why I should believe I have misconfigured a SCSI bus that everything
    > else, disk, CD, etc, *works* on, the device is seen by the BIOS, and oh
    > yeah,
    > if I pull the drive, like I just did, and put it on another machine, it
    > works
    > fine.


    SCSI is finicky and easy to misconfigure.

    > I'd say that VMS does not support that device.
    >
    > Now if ***you*** want to be silly and associate with the word "device",
    > with every tape drive in the world and assume someone else is stupid enough
    > to not know the difference, that is *your* problem.
    >
    >
    >
    >>> The UNIX *machine* does. There is not implication at all regarding
    >>> a comparison to Operating Systems there.

    >> [snip
    >>> By the way, just would your experience tell is the case when a tape

    >> device
    >>> shows
    >>> up in the bios SHOW DEV but not in the VMS SHOW DEV?

    >> Misconfigured SCSI.
    >>

    >
    > Just to be thorough, I'm not entirely sure how you could misconfigure
    > a single SCSI device and not have any other effects on the bus. People


    Forgot to terminate the bus?

    VMS is improperly configured?

    > whose opinions I really respect have indicated that SCSI drives under VMS
    > are pretty about what devices they will accept. I see no reason to doubt or


    Petty?

    > question that.
    >
    > Perhaps you know more than I do though.


    About VMS? Sure. COBOL? No.

    --
    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: COBOL Transactions?

    Paul Raulerson wrote:
    >> On Aug 24, 11:15 am, "Paul Raulerson" wrote:
    >>
    >>>> What you *seem* to be objecting to is when I say, "Here is what I
    >>>> need to do, here is how I would normally do it, what is the facility
    >>>> under VMS that does this?"

    >> Without rereading everything you've ever posted I'd have to say that
    >> I don't recall ever seeing you pose a question in that form.
    >>

    >
    > Well, that could well be. Electronic communications often lack the richness
    > of face to face or more formal communications. That does not, however,
    > imply that there was any malicious, or other intent.
    >
    > Or in other words, you are reading far more into a simple statement than
    > what is really there.
    >
    >> What you have done -- and what disturbs me -- is make statements (or
    >> implications) about OpenVMS' inability to perform a variety of tasks
    >> when you have no knowledge of whether or not it can do those things.
    >>
    >> For example, here are some things you have said ...
    >>
    >>>>> The only issue with the Alpha is that the 4mm tape drive on it
    >>>>> does not seem to be recognized. ... and off to the UNIX machine
    >>>>> which *does* know how to talk to tape.

    >
    > I'll use this one as an example. Perhaps if I had said "talk to *a* tape"
    > it would have disturbed you less. But in actual, plain, unassailable fact,
    > the ALPHA *machine* does NOT know how to talk to a tape right now.
    > The UNIX *machine* does. There is not implication at all regarding
    > a comparison to Operating Systems there.
    >
    >
    >>>>> When I create an indexed file in COBOL, is it using Rdb? If so,
    >>>>> it quacks a lot like a filesystem to me.
    >>>>> if they are VSAM (which is the the same as RDB on VMS)

    >
    > So ignorance is a crime? Several people pointed out to the that RDB
    > is a database, and RMS is a file system. I believe I expressed
    > embarrassment at that. On the other hand, how many people here
    > might mix up a 3390 and 3990 in the mainframe world? Probably a
    > few.
    >
    >>>> Why in heavens name would I, or *anyone* for that matter, go chasing
    >>>> around a hunk of hardware that is either not supported or simply
    >>>> broken when the needed capabilty is available on another resource
    >>>> which is working?

    >> Because it's your development system and most people I know would like
    >> their development systems to be fully functional. How will you
    >> develop
    >> a backup procedure for your client's on Alpha if you can't get it to
    >> work at home? How will you back up your ported source code at the
    >> HP porting event if you haven't practiced it under OpenVMS at home?
    >>

    >
    > I won't be supporting Alphas - only Itanium. There might be some compelling
    > reasons to support Alpha's I don't know about. There are probably reasons
    > to support Vax's. But, to the best of my knowledge, the compelling business
    > case is to support Itanium.
    >
    >> (And, even though you profess to port to Integrity you may come across
    >> a potential sale of your software at a client that already has Alpha
    >> and doesn't want to buy new systems. Be prepared.)
    >>
    >>>> Better yet, why in heavens name would you assume I would NOT backup
    >>>> valuable (at least to me) work on which I have spent much time
    >>>> and effort?

    >> Huh? Where did I make that assumption?
    >>

    >
    > When you assumed I was complaining that VMS would not talk to tape of
    > course.
    > What else could you possibly have meant?
    >
    > I do believe again you are reading much more into simple questions,
    > sometimes driven by excitement, than is reasonable to assume. I am
    > really developing a passion for VMS, but - I don't have time to explore
    > all the things I would like to do now. I really really don't have much
    > time at all to fight with hardware I intend to replace. In the meantime,
    > I intend to use that same resource to best effect.
    >
    > By the way, when I bought it, it was just to play with. I had no idea that
    > VMS was a viable platform to port our software to, or use for some of the
    > things I have learned it is useful for.
    >
    > As for my experience level - well- I'll send you a set of mainframe disks if
    > you wish. You are welcome to try and get to a comparable level of
    > inexperience
    > in a few months. The situations are very close.
    >
    > If you feel that I am being abrasive in some way, then I feel bad for you
    > and
    > will try to be more polite to you in the future. If on the other hand, you
    > think I have time to waste and should not be able to make decisions about
    > hardware and such, then I am truly sorry but I disagree. Especially about
    > something as simple as a misbehaving tape drive. (Again note, I am talking
    > about hardware - a tape drive - has nothing to do with VMS.)
    >
    > By the way, just would your experience tell is the case when a tape device
    > shows
    > up in the bios SHOW DEV but not in the VMS SHOW DEV?
    >
    > -Paul
    >
    >


    Please post the output of the SRM (not BIOS) command

    >>> show config


    First thing that comes to mind is that your tape drive is a wide SCSI
    device and it is connected to a narrow SCSI bus. Most if not all of the
    Alphaserver internal (not PCI card based) SCSI interfaces are narrow.

    Jeff







    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----

  15. Re: COBOL Transactions?

    In article <009401c7e6cb$56d86400$04892c00$@com>,
    "Paul Raulerson" wrote:

    > Please explain
    > to me why I should believe I have misconfigured a SCSI bus that everything
    > else, disk, CD, etc, *works* on, the device is seen by the BIOS,


    I'd say that you are new to SCSI :-)

    Cable lengths matter. Believe or not, I've seen the case where I plugged
    in an extra disk drive for a one-off exercise, then left it switched
    off. Over the next few months my system disk started logging an
    increasing number of errors, eventually not booting at all. The simple
    solution was to unplug the extra cable and disk which had been there for
    several months.

    > if I pull the drive, like I just did, and put it on another machine, it
    > works fine.
    >
    > I'd say that VMS does not support that device.


    Not necessarily. Think about the *combination* of SCSI devices on each
    system. Every removable DAT drive I have come across has had either
    jumpers or a dial on the back to set the SCSI address. If that is set
    incorrectly for the VMS system, it will never work.

    --
    Paul Sture

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

  16. RE: COBOL Transactions?

    (*sigh*)


    > > Why do you insist on reading anything into this other than the tape
    > > device is not working? What in the world are you hearing?

    >
    > You've developed an "I don't know how to do it, so VMS must not be
    > able to do it" reputation.
    >
    > > Whatever it is, it is NOT what I am saying.

    >
    > In the post that began this threadlet, you wrote:
    > UNIX machine which *does* know how to talk to tape.
    >
    > Which, given your poor reputation, leads us to read that you think
    > that VMS does *not* know how to talk to tape.
    >


    (*Sigh*)I was talking about the machines - not the OS.
    If that was not clear to you, I suggest it is because you are
    reading something into what I wrote that just is not there Ron.



    > > Really? Well, I guess I will just go on being dense then. Please

    > explain
    > > to me why I should believe I have misconfigured a SCSI bus that

    > everything
    > > else, disk, CD, etc, *works* on, the device is seen by the BIOS, and

    > oh
    > > yeah,
    > > if I pull the drive, like I just did, and put it on another machine,

    > it
    > > works
    > > fine.

    >
    > SCSI is finicky and easy to misconfigure.
    >


    Try configuring SCSI devices on a Wang VS
    sometime. Have one still running that talks to an EMC
    Symmetrix over SCSI.

    Never have gotten the beastie to talk to an ESS800
    over a SCSI channel, and really just gave up on that
    one. Wasn't worth the time to scope it out, since it
    works with the EMC.

    Just for the record, the SCSI bus on the Alpha machine is
    *not* misconfigured, and a DEC labeled tape drive when installed
    at the same LUN in the same slot with the same cable *does*
    show up and work under VMS. The same DEC labeled tape drive,
    by the way, that works on the UNIX machine.

    I think you are saying you hear me "attacking" VMS when
    I don't know how to do something. I suppose I would be
    annoyed if that is what I heard too.

    What I am saying is that when I run into something like
    this situation, I will make a judgment whether
    it is something I need to chase or not. In the case in
    point:

    I had a need to back up data. Further, the data to
    be backed up has value to me, and I need to
    have confidence in the backup.

    For whatever reason, the tape drive was not working
    on one machine

    Since it appeared to be, and actually is, a device
    support issue, it was not worth the time to
    try and make an unsupported device work. Also,
    I don't want to trust backup operations on
    an "unsupported" device.

    Answer: Use a machine that is already working and
    completely supports the available devices I
    have around.

    Action Item: Figure out workable SMB backup plans
    on Itanium machines


    > > are pretty about what devices they will accept. I see no reason to

    > doubt or
    >
    > Petty?
    >

    Pretty picky.



  17. RE: COBOL Transactions?



    > -----Original Message-----
    > From: P. Sture [mailtoaul.sture.nospam@hispeed.ch]
    > Sent: Saturday, August 25, 2007 9:55 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > In article <009401c7e6cb$56d86400$04892c00$@com>,
    > "Paul Raulerson" wrote:
    >
    > > Please explain
    > > to me why I should believe I have misconfigured a SCSI bus that

    > everything
    > > else, disk, CD, etc, *works* on, the device is seen by the BIOS,

    >
    > I'd say that you are new to SCSI :-)
    >
    > Cable lengths matter. Believe or not, I've seen the case where I
    > plugged
    > in an extra disk drive for a one-off exercise, then left it switched
    > off. Over the next few months my system disk started logging an
    > increasing number of errors, eventually not booting at all. The simple
    > solution was to unplug the extra cable and disk which had been there
    > for
    > several months.
    >
    > > if I pull the drive, like I just did, and put it on another machine,

    > it
    > > works fine.
    > >
    > > I'd say that VMS does not support that device.

    >
    > Not necessarily. Think about the *combination* of SCSI devices on each
    > system. Every removable DAT drive I have come across has had either
    > jumpers or a dial on the back to set the SCSI address. If that is set
    > incorrectly for the VMS system, it will never work.
    >


    Well, yep. That could be the case.

    I've heard of issues like the cable problem you described above, but haven't
    personally
    ran into one. In my day job and as much as possible here, I moved to LVD,
    which eliminates
    an awful lot of those problems.


    -Paul


    > --
    > Paul Sture
    >
    > Sue's OpenVMS bookmarks:
    > http://eisner.encompasserve.org/~stu...bookmarks.html



  18. Re: COBOL Transactions?

    On Aug 24, 11:52 pm, "Paul Raulerson" wrote:
    > > -----Original Message-----
    > > From: Ron Johnson [mailto:ron.l.john...@cox.net]
    > > Sent: Friday, August 24, 2007 10:17 PM
    > > To: Info-...@Mvb.Saic.Com
    > > Subject: Re: COBOL Transactions?

    >
    > > On 08/24/07 20:36, Paul Raulerson wrote:
    > > >> On Aug 24, 11:15 am, "Paul Raulerson" wrote:

    >
    > > [snip]

    >
    > > >> For example, here are some things you have said ...

    >
    > > >>>>> The only issue with the Alpha is that the 4mm tape drive on it
    > > >>>>> does not seem to be recognized. ... and off to the UNIX machine
    > > >>>>> which *does* know how to talk to tape.

    >

    [...]
    > > I *GUARANTEE* you that thousands of small VMS sites over the years
    > > have used 4mm and 8mm DAT drives to backup their data.

    >
    > And what has that go to do with anything?
    >
    > > You've *obviously* and *definitely* done something wrong, and are
    > > too dense to realize that you are making insultingly *stupid* comments.

    >
    > Really? Well, I guess I will just go on being dense then. Please explain
    > to me why I should believe I have misconfigured a SCSI bus that everything
    > else, disk, CD, etc, *works* on, the device is seen by the BIOS, and oh
    > yeah,
    > if I pull the drive, like I just did, and put it on another machine, it
    > works
    > fine.
    >
    > I'd say that VMS does not support that device.


    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!

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

    AEF

    [...]


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

    In article <1188069083.626943.60150@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.

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


  20. Re: 4MM DAT tapes read/write

    Brad Hamilton wrote:
    > In article <1188069083.626943.60150@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. 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. The older drives cannot
    reliably work with new tapes. This has nothing to do with the OS and everything
    to do with the drives. (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!!

    There are in fact relatively few devices that fail with VMS. There are ways to
    write media VMS will not grok (tape with blocksize over 64K for example, unless that
    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.

    Glenn Everhart

+ Reply to Thread
Page 1 of 2 1 2 LastLast