Re: COBOL Transactions? - VMS

This is a discussion on Re: COBOL Transactions? - VMS ; On 08/22/07 23:37, Paul Raulerson wrote: > >> Not so. > >You've got two (three?) months of VMS experience, and you're telling >*us* how VMS languages are?> > >Slightly arrogant and foolish. Not at all - I did not specify ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Re: COBOL Transactions?

  1. Re: COBOL Transactions?

    On 08/22/07 23:37, Paul Raulerson wrote:
    >
    >> Not so.

    >
    >You've got two (three?) months of VMS experience, and you're telling
    >*us* how VMS languages are?>
    >
    >Slightly arrogant and foolish.


    Not at all - I did not specify the HP COBOL compiler, and I do have around
    27 years of experience with COBOL now, in a very wide variety of environments. Ranging from Honeywell DPS-7 machines through Sperry Rand and Burroughs machines, through mainframes to UNIX, and even (ugh!) PC's.

    COBOL I know. VMS I am learning. I try at least, to be particularly careful around here not insult anyone with ignorance, but I also am not very afraid to speak up about subjects I do know about.


    > COBOL is not COBOL unless it supplies certain indexed file handling
    > capabilities, something that is NOT true of other languages. Part of the
    > normal COBOL thing
    >
    >Normal in the VS/COBOL world, maybe...


    No, it is an inherent part of the language defnition. The definition doesNOT speak as to how the underlying system is implemented, so you have itimplemented with "RMS" under VMS, VISION or a descendant under AcuCOBOL,VSAM under z/OS, z/VM, z/VSE. and z/TPM, and so forth and so on for eachdifferent COBOL vendor.


    >> is to supply the BEGIN TRANSACTION keywords, though it is
    >> not required in the language spec for COBOL 85.

    >
    >"CALL DTM$START_TRANSACTION()." isn't that complicated of a change
    >to your code.


    Not once you know it there, and how all the pieces to make it work fit together, no, it isn't.

    [snip]

    Yours,
    -Paul



  2. Re: COBOL Transactions?

    In article , "Paul Raulerson" writes:
    >
    > No, it is an inherent part of the language defnition. The definition does=
    > NOT speak as to how the underlying system is implemented, so you have it=
    > implemented with "RMS" under VMS, VISION or a descendant under AcuCOBOL,=
    > VSAM under z/OS, z/VM, z/VSE. and z/TPM, and so forth and so on for each=
    > different COBOL vendor.


    Must be a PITA to implement on an OS without a file system, like
    UNIX or DOS. But if Solaris and HP-UX can have "VAX compatable
    Fortran" with indexed file operations, I guess it can be done.


  3. Re: COBOL Transactions?

    In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    > In article , "Paul Raulerson" writes:
    >>
    >> No, it is an inherent part of the language defnition. The definition does=
    >> NOT speak as to how the underlying system is implemented, so you have it=
    >> implemented with "RMS" under VMS, VISION or a descendant under AcuCOBOL,=
    >> VSAM under z/OS, z/VM, z/VSE. and z/TPM, and so forth and so on for each=
    >> different COBOL vendor.

    >
    > Must be a PITA to implement on an OS without a file system, like
    > UNIX or DOS. But if Solaris and HP-UX can have "VAX compatable
    > Fortran" with indexed file operations, I guess it can be done.


    If I were implementing a COBOL compiler, I wouldn't think the
    difference between using RMS calls or Berkely DB calls or VISION calls
    or whatever would be all that big a deal.

    If you're after cross-language support on a single operating system
    then RMS under VMS has some nice advantages.

    If you're after cross-platform support on a single programming language
    then something like VISION and AcuCOBOL might be of interest (if I
    understand things properly).

  4. Re: COBOL Transactions?

    On 08/23/07 12:19, Bob Koehler wrote:
    > In article , "Paul Raulerson" writes:
    >> No, it is an inherent part of the language defnition. The definition does=
    >> NOT speak as to how the underlying system is implemented, so you have it=
    >> implemented with "RMS" under VMS, VISION or a descendant under AcuCOBOL,=
    >> VSAM under z/OS, z/VM, z/VSE. and z/TPM, and so forth and so on for each=
    >> different COBOL vendor.

    >
    > Must be a PITA to implement on an OS without a file system, like
    > UNIX or DOS. But if Solaris and HP-UX can have "VAX compatable
    > Fortran" with indexed file operations, I guess it can be done.


    Not at all. You just have to bring in your own file and transaction
    code. Get something like BDB, write your own, modify/extend BDB to
    suit your own purposes etc.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  5. Re: COBOL Transactions?

    In article , Ron Johnson writes:
    >
    > Not at all. You just have to bring in your own file and transaction
    > code. Get something like BDB, write your own, modify/extend BDB to
    > suit your own purposes etc.


    Hm. Sounds like a PITA to me. Something the OS writers should
    have done. As a matter of fact, they may even work for the same
    company. And the work might be needed by Fortran, Ada, COBOL, ...


  6. Re: COBOL Transactions?

    On 08/23/07 16:02, Bob Koehler wrote:
    > In article , Ron Johnson writes:
    >> Not at all. You just have to bring in your own file and transaction
    >> code. Get something like BDB, write your own, modify/extend BDB to
    >> suit your own purposes etc.

    >
    > Hm. Sounds like a PITA to me. Something the OS writers should
    > have done. As a matter of fact, they may even work for the same
    > company. And the work might be needed by Fortran, Ada, COBOL, ...


    Well sure, that's the *optimum*.

    And actually, the (Linux) world, though, is heading in that
    direction with the GCC (which now means "GNU Compiler Collection"
    instead of GNU C Compiler). It's now simple to create language
    bindings for any shared library compiled with a GCC compiler.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  7. Re: COBOL Transactions?

    In article , Ron Johnson writes:
    >
    > And actually, the (Linux) world, though, is heading in that
    > direction with the GCC (which now means "GNU Compiler Collection"
    > instead of GNU C Compiler). It's now simple to create language
    > bindings for any shared library compiled with a GCC compiler.


    It is not actually the compiler that is so much work, it is the
    record processing level of code.

    Years ago TOPS-20 folks determined that they were foolishly doing
    different RMS for their Fortran, COBOL, and other language libraries.
    They gave it up and wrote one RMS for all, even documented it so
    others could use it.

    VMS and other OS were there from day 1.

    UNIX and DOS weren't there. POSIX selecting C-ISAM as part of its
    standard probably helped, but I've not seen anything that shipped
    with most of them. (I remember when ULTRIX-32 added some Ingress
    routines as part of its standard libraries to provide this.)



  8. Re: COBOL Transactions?

    In article ,
    "Paul Raulerson" wrote:

    > No, it is an inherent part of the language defnition. The definition does NOT
    > speak as to how the underlying system is implemented, so you have it
    > implemented with "RMS" under VMS, VISION or a descendant under AcuCOBOL, VSAM
    > under z/OS, z/VM, z/VSE. and z/TPM, and so forth and so on for each different
    > COBOL vendor.


    The COBOL standard also defines what kind of indexed keys are allowable.
    This could be a real swine with early versions of VAX-COBOL when wanting
    to access files populated by non-COBOL languages.

    From Page 6-7 of the COBOL User Guide:

    "When you open a file, you must specify the same number and type of keys
    that were specified when the file was created. (This situation is
    subject to modification by the check duplicate keys and relax key
    checking options, as well as a duplicate key specification on an FD.) If
    the number or type of keys does not match, the system will issue a
    run-time diagnostic when you try to open the file."

    The ability to relax key checking didn't exist at one time.

    --
    Paul Sture

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

  9. Re: COBOL Transactions?

    In article ,
    koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

    > In article , "Paul Raulerson"
    > writes:
    > >
    > > No, it is an inherent part of the language defnition. The definition does
    > > NOT speak as to how the underlying system is implemented, so you have it
    > > implemented with "RMS" under VMS, VISION or a descendant under AcuCOBOL,
    > > VSAM under z/OS, z/VM, z/VSE. and z/TPM, and so forth and so on for each
    > > different COBOL vendor.

    >
    > Must be a PITA to implement on an OS without a file system, like
    > UNIX or DOS. But if Solaris and HP-UX can have "VAX compatable
    > Fortran" with indexed file operations, I guess it can be done.


    In my quick dip into the COBOL User Guide for my previous post, I
    noticed that it is scattered with Tru64 references.

    Does that imply that they ported RMS to Tru64?

    --
    Paul Sture

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

  10. Re: COBOL Transactions?

    In article , "P. Sture" writes:
    >
    > Does that imply that they ported RMS to Tru64?


    If left to themselves DEC engineers might have eventually figured
    out that separate and not completely compatable RMS were in the
    COBOL and other language libraries, and like they did for TOPS-20
    replace those with a single common RMS.

    But I think DEC died while digital UNIX was just an updated BSD with
    whatever was inheritted from OSF in this area. After renaming it
    Tru64, Compaq showed no real initiative along UNIX lines until Curly
    decided he'd rather sell HP-UX.


+ Reply to Thread