Re: COBOL Transactions? - VMS

This is a discussion on Re: COBOL Transactions? - VMS ; 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" ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: COBOL Transactions?

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


    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.



  2. Re: COBOL Transactions?

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

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

  3. Re: COBOL Transactions?

    In article ,
    "Paul Raulerson" 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.

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


    At the risk of going way off topic, I recently discovered that SQLite
    comes with OS X nowadays. One thing I have spotted about it is that the
    use of fork is specifically discouraged, so maybe some hope of porting
    to VMS not running into that little obstacle :-)

    http://www.sqlite.org/

    "About SQLite

    SQLite is a small C library that implements a self-contained,
    embeddable, zero-configuration SQL database engine. Features include:

    * Transactions are atomic, consistent, isolated, and durable (ACID)
    even after system crashes and power failures.
    * Zero-configuration - no setup or administration needed.
    * Implements most of SQL92. (Features not supported)
    * A complete database is stored in a single disk file.
    * Database files can be freely shared between machines with
    different byte orders.
    * Supports terabyte-sized databases and gigabyte-sized strings and
    blobs. (See limits.html.)
    * Small code footprint: less than 250KiB fully configured or less
    than 150KiB with optional features omitted.
    * Faster than popular client/server database engines for most common
    operations.
    * Simple, easy to use API.
    * TCL bindings included. Bindings for many other languages available
    separately.
    * Well-commented source code with over 98% test coverage.
    * Available as a single ANSI-C source-code file that you can easily
    drop into another project.
    * Self-contained: no external dependencies.
    * Sources are in the public domain. Use for any purpose."

    --
    Paul Sture

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

  4. Re: COBOL Transactions?

    On 08/25/07 07:56, P. Sture wrote:
    > In article ,
    > "Paul Raulerson" 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.

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

    >
    > At the risk of going way off topic, I recently discovered that SQLite
    > comes with OS X nowadays. One thing I have spotted about it is that the
    > use of fork is specifically discouraged, so maybe some hope of porting
    > to VMS not running into that little obstacle :-)
    >
    > http://www.sqlite.org/
    >
    > "About SQLite
    >
    > SQLite is a small C library that implements a self-contained,
    > embeddable, zero-configuration SQL database engine. Features include:


    The problem is that SQLite does not enforce datatype definitions.

    (The authors say this is a design decision and feature.)

    [snip]


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

    > he problem is that SQLite does not enforce datatype definitions.
    >
    > (The authors say this is a design decision and feature.)


    Thanks for the heads up.

    --
    Paul Sture

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

  6. Re: COBOL Transactions?

    On 08/25/07 13:11, P. Sture wrote:
    > In article ,
    > Ron Johnson wrote:
    >
    >> he problem is that SQLite does not enforce datatype definitions.
    >>
    >> (The authors say this is a design decision and feature.)

    >
    > Thanks for the heads up.


    Note that I do (enthusiastically) use SQLite as an ISAM replacement
    in Python.

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

+ Reply to Thread