Re: COBOL Transactions? - VMS

This is a discussion on Re: COBOL Transactions? - VMS ; >> Boy, you can say *that* again! It is also one of the reasons that >> COBOL is so darn expensive on UNIX or non-VMS/non-Mainframe platforms. >> > >By "UNIX or non-VMS/non-Mainframe" i assume you mean that they don't >have ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 44

Thread: Re: COBOL Transactions?

  1. Re: COBOL Transactions?

    >> Boy, you can say *that* again! It is also one of the reasons that
    >> COBOL is so darn expensive on UNIX or non-VMS/non-Mainframe platforms.
    >>

    >
    >By "UNIX or non-VMS/non-Mainframe" i assume you mean that they don't
    >have indexed key access data files built into the system.


    Pretty much. UNIX filesystems have no idea about record oriented files, or rather, all the files on a UNIX file size have a record size of 1 byte.

    COBOL (and I assume PL/I running under UNIX has to supply a record oriented file system layered over the UNIX filesystem. Or they can use a empty DASD partition and roll their own filesystem, still has the same problem. Or they can use a RDMS, which internally has to solve exactly
    the same problem.

    System that normally deal with record based file systems have a great advantage in terms of support for COBOL (and PL/I).

    -Paul





  2. Re: COBOL Transactions?

    On Fri, 24 Aug 2007 08:22:48 -0700, Paul Raulerson
    wrote:

    >>> Boy, you can say *that* again! It is also one of the reasons that
    >>> COBOL is so darn expensive on UNIX or non-VMS/non-Mainframe platforms.
    >>>

    >>
    >> By "UNIX or non-VMS/non-Mainframe" i assume you mean that they don't
    >> have indexed key access data files built into the system.

    >
    > Pretty much. UNIX filesystems have no idea about record oriented files,
    > or rather, all the files on a UNIX file size have a record size of 1
    > byte.
    >
    > COBOL (and I assume PL/I running under UNIX has to supply a record
    > oriented file system layered over the UNIX filesystem. Or they can use a
    > empty DASD partition and roll their own filesystem, still has the same
    > problem. Or they can use a RDMS, which internally has to solve exactly
    > the same problem.


    Yes, basically it is an ISAM package. On Ultrix PL/I it was sold as a
    separate
    product that could be bundled with applications.

    >
    > System that normally deal with record based file systems have a great
    > advantage in terms of support for COBOL (and PL/I).
    >
    > -Paul
    >
    >
    >




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

  3. Re: COBOL Transactions?

    In article , "Paul Raulerson" writes:

    > COBOL (and I assume PL/I running under UNIX has to supply a record ori=
    > ented file system layered over the UNIX filesystem.


    As do Ada implementations.

    There is a distinct problem with an operating system written by folks
    who think the lowest common denominator programming language is the
    only one.

  4. Re: COBOL Transactions?

    In article ,
    Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    > In article , "Paul Raulerson" writes:
    >
    >> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
    >> ented file system layered over the UNIX filesystem.

    >
    > As do Ada implementations.
    >
    > There is a distinct problem with an operating system written by folks
    > who think the lowest common denominator programming language is the
    > only one.


    Once again, don't assume your worldview is the only one. The entire
    paradigm underlying Unix was "The Software Tools" paradigm in which
    things are reduced to their simplest form and complexity is created
    by adding layers. Thus the "pipe" concept as used by things like
    troff which required other utilities like col, eqn, greek and tbl
    in order to create more complex documents.

    C-ISAM was around and available for Unix since at least the early to
    mid 80's. I first used a database and COBOL on Unix in the mid 80's.
    One advantage to the Unix paradigm is you don't end out paying for
    features you neither need nor want. I have never used RMS on VMS.
    explicitly. I can't think of anything I have done that actually
    needed it. And don't say "you don't pay for it because it is
    bundled in" because you pay for everything that comes with the system
    wether it is listed on the invoice or not.

    bill

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

  5. Re: COBOL Transactions?

    In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    > In article ,
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >> In article , "Paul Raulerson" writes:
    >>
    >>> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
    >>> ented file system layered over the UNIX filesystem.

    >>
    >> As do Ada implementations.
    >>
    >> There is a distinct problem with an operating system written by folks
    >> who think the lowest common denominator programming language is the
    >> only one.


    > C-ISAM was around and available for Unix since at least the early to
    > mid 80's.


    But never something one could always count on being there ?

    > One advantage to the Unix paradigm is you don't end out paying for
    > features you neither need nor want. I have never used RMS on VMS.
    > explicitly. I can't think of anything I have done that actually
    > needed it.


    If you write all your programs with a "stream of bytes" language,
    that may be the case. In my experience programs written with a
    "stream of bytes" mentality are a major source of lousy software.

  6. Re: COBOL Transactions?

    In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >
    > I have never used RMS on VMS.
    > explicitly. I can't think of anything I have done that actually
    > needed it.


    You only program in C,C++,Java and you never view your files on a
    terminal (type or edit) or printer? You never perused a directory?

    Yes, those can be done without RMS, UNIX and DOS are examples. As
    long as someone provided the missing component somewhere. Your
    terminal and printer didn't come out of the box thinking LF implied
    CR, although some hardware is settable to provide that.


  7. Re: COBOL Transactions?

    On Fri, 24 Aug 2007 11:05:48 -0700, Bill Gunshannon
    wrote:

    > In article ,
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >> In article , "Paul Raulerson"
    >> writes:
    >>
    >>> COBOL (and I assume PL/I running under UNIX has to supply a record
    >>> ori=
    >>> ented file system layered over the UNIX filesystem.

    >>
    >> As do Ada implementations.
    >>
    >> There is a distinct problem with an operating system written by folks
    >> who think the lowest common denominator programming language is the
    >> only one.

    >
    > Once again, don't assume your worldview is the only one. The entire
    > paradigm underlying Unix was "The Software Tools" paradigm in which
    > things are reduced to their simplest form and complexity is created
    > by adding layers. Thus the "pipe" concept as used by things like
    > troff which required other utilities like col, eqn, greek and tbl
    > in order to create more complex documents.
    >
    > C-ISAM was around and available for Unix since at least the early to
    > mid 80's. I first used a database and COBOL on Unix in the mid 80's.
    > One advantage to the Unix paradigm is you don't end out paying for
    > features you neither need nor want. I have never used RMS on VMS.
    > explicitly. I can't think of anything I have done that actually
    > needed it. And don't say "you don't pay for it because it is
    > bundled in" because you pay for everything that comes with the system
    > wether it is listed on the invoice or not.
    >

    C-ISAM which was written by Roger Sippl, was a pretty limited implentation
    without secondary keys, for example, and this later morphed into Informix
    IIRC.

    > bill
    >




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

  8. Re: COBOL Transactions?

    Bob Koehler wrote:
    > In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >
    >>I have never used RMS on VMS.
    >>explicitly. I can't think of anything I have done that actually
    >>needed it.

    >
    >
    > You only program in C,C++,Java and you never view your files on a
    > terminal (type or edit) or printer? You never perused a directory?
    >
    > Yes, those can be done without RMS, UNIX and DOS are examples. As
    > long as someone provided the missing component somewhere. Your
    > terminal and printer didn't come out of the box thinking LF implied
    > CR, although some hardware is settable to provide that.
    >


    Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)


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

  9. Re: COBOL Transactions?

    On 08/24/07 14:41, Larry Kilgallen wrote:
    [snip]
    >
    > If you write all your programs with a "stream of bytes" language,
    > that may be the case. In my experience programs written with a
    > "stream of bytes" mentality are a major source of lousy software.


    More importantly, the data that is needed to generate my paycheck
    isn't is "stream of bytes" format.

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

  10. Re: COBOL Transactions?

    On 08/24/07 16:11, John Santos wrote:
    [snip]
    >
    > Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)


    I was delighted the first time I opened SYSUAF in EDT, and learned
    the interesting lesson (*not* on SYSUAF!) that saving an indexed
    file converts it into a flat file...

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

    In article ,
    Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    > In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >> In article ,
    >> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >>> In article , "Paul Raulerson" writes:
    >>>
    >>>> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
    >>>> ented file system layered over the UNIX filesystem.
    >>>
    >>> As do Ada implementations.
    >>>
    >>> There is a distinct problem with an operating system written by folks
    >>> who think the lowest common denominator programming language is the
    >>> only one.

    >
    >> C-ISAM was around and available for Unix since at least the early to
    >> mid 80's.

    >
    > But never something one could always count on being there ?


    Because the majority of users didn't need or want it. So, why should
    they have to pay for it?

    >
    >> One advantage to the Unix paradigm is you don't end out paying for
    >> features you neither need nor want. I have never used RMS on VMS.
    >> explicitly. I can't think of anything I have done that actually
    >> needed it.

    >
    > If you write all your programs with a "stream of bytes" language,
    > that may be the case. In my experience programs written with a
    > "stream of bytes" mentality are a major source of lousy software.


    I have written programs on Unix systems in COBOL, Fortran, Pascal, Ada,
    Algol, PL/I, BASIC, Modula2, various assemblers and I am sure a few
    languages I have forgotten. Just because the underlying systems doesn't
    have your favorite file type on it doesn't mean all programs are written
    with a "stream of bytes" mentality. Part of real Software Engineering
    is picking the right tools for the job. It's nice to know that some
    tool is not being forced down my throat when I know it is the wrong
    answer to a problem.

    bill


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

  12. Re: COBOL Transactions?

    In article ,
    Ron Johnson writes:
    > On 08/24/07 14:41, Larry Kilgallen wrote:
    > [snip]
    >>
    >> If you write all your programs with a "stream of bytes" language,
    >> that may be the case. In my experience programs written with a
    >> "stream of bytes" mentality are a major source of lousy software.

    >
    > More importantly, the data that is needed to generate my paycheck
    > isn't is "stream of bytes" format.


    Only because the machine doing the work has imposed a format on the
    raw data, wethere it is necessary or not. What exactly is needed
    to generate a paycheck that can not be done with data stored as a
    stream of bytes? (Hint: at the lowest level all data is stored as
    a stream of bytes even on VMS!!)

    bill

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

  13. Re: COBOL Transactions?

    In article ,
    koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    > In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >>
    >> I have never used RMS on VMS.
    >> explicitly. I can't think of anything I have done that actually
    >> needed it.

    >
    > You only program in C,C++,Java and you never view your files on a
    > terminal (type or edit) or printer? You never perused a directory?


    I didn't say that. I know VMS is using RMS for all that. But I do the
    same taskes quite well on machines without it so I guess it really isn't
    necessary. It is just forced on me. Kind of like the common rant, "Bill
    Gates knows what's best for you." Apparently DEC/Compaq/HP have pretty
    much the same attitude.

    >
    > Yes, those can be done without RMS, UNIX and DOS are examples. As
    > long as someone provided the missing component somewhere. Your
    > terminal and printer didn't come out of the box thinking LF implied
    > CR, although some hardware is settable to provide that.


    At one time, almost every printer I had ever seen knew that. Today, they
    all do postscript which means without a "missing component somewhere" you
    couldn't print any of your RMS based files either. And don't even try
    saying that you can view raw RMS files on a terminal or edit them without
    a "missing component somewhere" to convert them from RMS format to juat
    another pile of bytes.

    bill

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

  14. Re: COBOL Transactions?

    In article ,
    John Santos writes:
    > Bob Koehler wrote:
    >> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >>
    >>>I have never used RMS on VMS.
    >>>explicitly. I can't think of anything I have done that actually
    >>>needed it.

    >>
    >>
    >> You only program in C,C++,Java and you never view your files on a
    >> terminal (type or edit) or printer? You never perused a directory?
    >>
    >> Yes, those can be done without RMS, UNIX and DOS are examples. As
    >> long as someone provided the missing component somewhere. Your
    >> terminal and printer didn't come out of the box thinking LF implied
    >> CR, although some hardware is settable to provide that.
    >>

    >
    > Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)


    I login to lots of systems everyday without the help of RMS. Tell me again
    why it is "needed" for this task?

    RMS may be great at what it does but for a very large number of tasks
    it is just overhead.

    bill

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

  15. Re: COBOL Transactions?

    In article , Ron Johnson writes:
    > On 08/24/07 14:41, Larry Kilgallen wrote:
    > [snip]
    >>
    >> If you write all your programs with a "stream of bytes" language,
    >> that may be the case. In my experience programs written with a
    >> "stream of bytes" mentality are a major source of lousy software.

    >
    > More importantly, the data that is needed to generate my paycheck
    > isn't is "stream of bytes" format.


    Banks are slow to cash checks made out in an amount of \/.

  16. Re: COBOL Transactions?

    In article , Ron Johnson writes:
    > On 08/24/07 16:11, John Santos wrote:
    > [snip]
    >>
    >> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)

    >
    > I was delighted the first time I opened SYSUAF in EDT, and learned
    > the interesting lesson (*not* on SYSUAF!) that saving an indexed
    > file converts it into a flat file...


    I know of at least six sites where privileged users did that to
    SYSALF.DAT and then exited, meaning even their existing entries
    no longer worked.

    One of the best security measures a site can institute is mandatory
    competency testing for those who want privileges on their username.

  17. Re: COBOL Transactions?

    In article <5j93nfF3sloleU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    > In article ,
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >>> In article ,
    >>> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    >>>> In article , "Paul Raulerson" writes:
    >>>>
    >>>>> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
    >>>>> ented file system layered over the UNIX filesystem.
    >>>>
    >>>> As do Ada implementations.
    >>>>
    >>>> There is a distinct problem with an operating system written by folks
    >>>> who think the lowest common denominator programming language is the
    >>>> only one.

    >>
    >>> C-ISAM was around and available for Unix since at least the early to
    >>> mid 80's.

    >>
    >> But never something one could always count on being there ?

    >
    > Because the majority of users didn't need or want it. So, why should
    > they have to pay for it?


    Good idea. Can you help me get HP to remove the "stream of bytes"
    support from VMS ?

  18. Re: COBOL Transactions?

    In article <5j93skF3sloleU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    > In article ,
    > Ron Johnson writes:
    >> On 08/24/07 14:41, Larry Kilgallen wrote:
    >> [snip]
    >>>
    >>> If you write all your programs with a "stream of bytes" language,
    >>> that may be the case. In my experience programs written with a
    >>> "stream of bytes" mentality are a major source of lousy software.

    >>
    >> More importantly, the data that is needed to generate my paycheck
    >> isn't is "stream of bytes" format.

    >
    > Only because the machine doing the work has imposed a format on the
    > raw data, wethere it is necessary or not. What exactly is needed
    > to generate a paycheck that can not be done with data stored as a
    > stream of bytes? (Hint: at the lowest level all data is stored as
    > a stream of bytes even on VMS!!)


    No, it is organized as a series of extents containing blocks containing
    records. Implicit in that for most file formats is some implicit
    carriage control format specified in the file header.

  19. Re: COBOL Transactions?

    Larry Kilgallen wrote:
    > In article , Ron Johnson
    > writes:
    >> On 08/24/07 16:11, John Santos wrote:
    >> [snip]
    >>>
    >>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed
    >>> file. :-)

    >>
    >> I was delighted the first time I opened SYSUAF in EDT, and learned
    >> the interesting lesson (*not* on SYSUAF!) that saving an indexed
    >> file converts it into a flat file...

    >
    > I know of at least six sites where privileged users did that to
    > SYSALF.DAT and then exited, meaning even their existing entries
    > no longer worked.
    >


    File versioning to the rescue ?

    > One of the best security measures a site can institute is mandatory
    > competency testing for those who want privileges on their username.




  20. Re: COBOL Transactions?

    Bill Gunshannon wrote:
    > RMS may be great at what it does but for a very large number of tasks
    > it is just overhead.


    Before you declare RMS "overhead", you would need to look into the code
    that allows you to read "lines" of text in Unix (fgets for instance).

    VMS doesn't need to scan the data for cr/lfs, it looks at the 2 byte
    record header and knows exactly how many bytes of data are in that record.


    And when you look at the many Unix/windows applications that work only
    on sequential files, many end up reading the whole file in memory and
    the scanning in memory (but that in the end results in a lot of paging
    to the pagefile). Also, whenever you change a preference, it has to
    rewrite the whole config file instead of just changing one record. And
    this has interesting consequences in a multi-user system due to file
    locking and other processes that may have the cofig file already in
    memory when when they update their configs, they will overwrite
    previously modified files without the changes that had been made by
    other processes.

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