COBOL Transactions? - VMS

This is a discussion on COBOL Transactions? - VMS ; Paul Raulerson wrote: > Drat -which is of course why Hoff suggested mySQL. > $20K/processor is just too much additional overhead > for the majority of the market I want to target. One need to know the "history". Not long ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 52

Thread: COBOL Transactions?

  1. Re: COBOL Transactions?

    Paul Raulerson wrote:

    > Drat -which is of course why Hoff suggested mySQL.
    > $20K/processor is just too much additional overhead
    > for the majority of the market I want to target.


    One need to know the "history". Not long ago (before
    Oracle bought Rdb) the *runt-time* version of Rdb was
    free/included on VMS. So one could distrubute Rdb based
    applications to any numner of client sites without any
    additional costs.

    Jan-Erik.

  2. Re: COBOL Transactions?

    Hi Paul,

    "933B" looks strange. As someone else already suggested, you need to create
    a log file with $MC LMCP. The other thing you need to do is look for this
    logical: - DECDTM$INHIBIT and if it's set to true then set it to false and
    re-run the startup. You won't need the XG startup as that's for the XA
    Gateway which is only of interest if you want your RMS updates controlled by
    some sort of XA monitor like Tuxedo. (The XA Veneer on the other hand (that
    doesn't need a seperate process) is useful if you want to update Orrible
    Oracle on VMS in the same 2PC as your Rdb, RMS (and possibly Windows SQL
    Server) databases.

    I still don't know why people persist in saying that VAX COBOL does not
    support commit/rollback verbs when the pointer to the docs that I posted
    previous seems to show that it does? No matter; now that I know what you're
    doing I'm intrigued!

    I love VMS (always will) I love seeing stuff ported to VMS; the more the
    better! Having said that, who the hell is giving you funding for this crap?
    Keep it on IBM and just change the incontinence nappies every now and then
    (works for VMS engineering :-)

    OK we are where we are: - What database exactly was the COBOL talking to on
    IBM? DB2? Or a Codasyl compliant database? VISAM? I thought (not knowing
    anything at all about IBM) that all the CICS stuff used precompilers and had
    EXEC-SQL in the code everywhere.

    What about all the JCL? How do you intend to backup your data? You may have
    RUJ functionality but what about AIJ functionality and roll forward to point
    in time? Does it get distributed anywhere? Data wharehouses?

    Look I'm sure you thought all this through and I wish you well, but if you
    want cheap, leave it on IBM. If you want to do it right then re-write it on
    VMS. Me? I'd go Rdb *every* time, despite the poisonous, self-serving ,
    oligarchic gravy-train that is currently running it into the buffers.

    Cheers Richard Maher

    PS. Here's a web site where you can often hear from Jim Johnson if you miss
    him, and can also reminisce about what it was like to be in a living
    development environment: -

    http://forums.microsoft.com/MSDN/Sho...D=388&SiteID=1

    Digital had it way back when :-(

    PPS> There used to be an RPG II compiler on PDPs don't know if it ever made
    it to VMS.

    "Paul Raulerson" wrote in message
    news:000301c7e532$25d7be90$71873bb0$@com...
    >
    > [SNIP SNIP SNIP]
    > > -----Original Message-----
    > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > Sent: Wednesday, August 22, 2007 6:11 PM
    > > To: Info-VAX@Mvb.Saic.Com
    > > Subject: Re: COBOL Transactions?
    > >

    > [SNIP]
    >
    > Hey Richard, do you have a pointer to how to turn this DDTM *on*?
    > I have found:
    > DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1
    > DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1
    > DECDTM$STARTUP.COM;1
    >
    > and ran the DECDTM$STARTUP.com script, which seems to have succeeded. Also
    > ran the DDTM$XG_START_SERVER.com
    > script, and they *seem* to be running.
    >
    > Marked a test file with SET FILE/RU_JOURNAL and it seems to report itself
    > correctly.
    >
    > Constantly get back a failure code, 933B.
    >
    > Ran the example script, created the files and still get the same error

    code.
    > I do not know if it is a license thing or not. Show license finds the
    > following lines, so I think it is licensed.
    >
    > DTM DEC 0 0 100 0.0 (none)
    > 31-JUL-2008
    > RMSJNL DEC 0 0 100 0.0 (none)
    > 31-JUL-2008
    >
    > I cannot find any startup files or stuff with *RMS* in the name to run or
    > whatever.
    >
    > I did scan through the manuals I could find, and the RMS Journal manual

    was
    > clear that DECdtm has to be
    > running first, but ... not really working. Advice? Pointers?

    Thanks -Paul
    >
    >




  3. Re: COBOL Transactions?

    On 08/22/07 23:37, Paul Raulerson wrote:
    >
    >> -----Original Message-----
    >> From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com]
    >> Sent: Wednesday, August 22, 2007 10:50 PM
    >> To: Info-VAX@Mvb.Saic.Com
    >> Subject: Re: COBOL Transactions?

    [snip]
    >> Hmm, those remarks suggest very limited understanding of how OpenVMS
    >> works.
    >> Languages do NOT roll their own stuff. They are all just dialects to
    >> do the same thing using core functions from the kernel or run time
    >> libraries.
    >> If Pascal had 'free' transaction management, then Cobol and Fortran
    >> and Basic would also have it. Period. That's how it's done for
    >> OpenVMS.
    >>

    >
    > Not so.


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

    Slightly arrogant and foolish.

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

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

    > I believe it is for the new
    > spec coming out...


    Then if VMS COBOL 3.0 decides to follow the latest standard, it'll
    have BEGIN TRANSACTION.

    > Of course, high end transaction systems handle this very well, usually by
    > serializing
    > access to file resources, and by providing true transaction. They cost
    > though-
    > CICS for example runs anywhere from just under a thousand dollars per month
    > *up*.


    ACMS serves the same purpose in VMS.

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

  4. Re: COBOL Transactions?

    On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    wrote:

    > Not so. 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 is to supply the BEGIN TRANSACTION keywords, though
    > it is
    > not required in the language spec for COBOL 85. I believe it is for the
    > new
    > spec coming out...


    Indexed file handling is in the PL/I semantics.


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

  5. Re: COBOL Transactions?

    On 08/23/07 08:25, Tom Linden wrote:
    > On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    > wrote:
    >
    >> Not so. 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 is to supply the BEGIN TRANSACTION keywords, though
    >> it is
    >> not required in the language spec for COBOL 85. I believe it is for
    >> the new
    >> spec coming out...

    >
    > Indexed file handling is in the PL/I semantics.


    Yeah, but anyone in his right mind knows that PL/1 sucks.

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

  6. Re: COBOL Transactions?

    On Aug 22, 11:03 pm, "Paul Raulerson" wrote:
    > [SNIP SNIP SNIP]>
    >
    > Constantly get back a failure code, 933B.


    That's not a failure code in OpenVMS, but it is a bad informational.
    It should possibly translate to '%SYSTEM-I-NEWBIE, Beginner in action"

    'get back' FROM WHAT? In which field?

    The Cobol should look like:

    START-TRANS.
    CALL "SYS$START_TRANSW" USING omitted, omitted, BY REFERENCE
    IOSB,
    omitted, omitted, omitted, omitted, omitted, omitted
    GIVING STS.
    :

    The other place to check for status is after the open of a file marked
    for RU.
    Typically that would involve something like

    DECLARATIVES.
    ERROR-HANDLER SECTION.
    USE AFTER STANDARD EXCEPTION PROCEDURE ON THE-FILE.
    HERE-WE-GO.
    MOVE RMS-STS TO STS.
    MOVE RMS-STV TO STV.
    DISPLAY "File status ", FILE-STATUS, " STS=", STS, " STV=",
    STV.
    END DECLARATIVES.

    hth,
    Hein.



    >
    > Ran the example script, created the files and still get the same error code.
    > I do not know if it is a license thing or not. Show license finds the
    > following lines, so I think it is licensed.
    >
    > DTM DEC 0 0 100 0.0 (none)
    > 31-JUL-2008
    > RMSJNL DEC 0 0 100 0.0 (none)
    > 31-JUL-2008
    >
    > I cannot find any startup files or stuff with *RMS* in the name to run or
    > whatever.
    >
    > I did scan through the manuals I could find, and the RMS Journal manual was
    > clear that DECdtm has to be
    > running first, but ... not really working. Advice? Pointers? Thanks -Paul




  7. Re: COBOL Transactions?

    In article <1187840978.421774.183940@z24g2000prh.googlegroups. com>, Hein RMS van den Heuvel writes:
    > On Aug 22, 1:53 pm, "Paul Raulerson" wrote:
    >> I posted this question in another, but I figured someone here might
    >> have a good idea they were willing to share.
    >>
    >> Most COBOL implementations provide a
    >> BEGIN TRANSACTION
    >> COMMIT/ROLLBACK
    >> construct.


    >> Or if John R. is reading this - any plans to add transaction management directly into the compiler? Or is there transaction management built into Pascal or Fortran that I can use to manage this?

    >
    > Hmm, those remarks suggest very limited understanding of how OpenVMS
    > works.
    > Languages do NOT roll their own stuff. They are all just dialects to
    > do the same thing using core functions from the kernel or run time
    > libraries.
    > If Pascal had 'free' transaction management, then Cobol and Fortran
    > and Basic would also have it. Period. That's how it's done for
    > OpenVMS.


    If that Cobol syntax is standardized (a question not answered to date
    in this discussion), VMS Cobol should support it by calling RMS Journaling
    from the generated code.

    This is analogous to HP Ada automatically calling DECthreads to support
    Ada tasking.

  8. Re: COBOL Transactions?

    Hi Paul,

    Anyone know what this is good for: -
    http://h71000.www7.hp.com/doc/82fina...0.html#ref_661

    And here's one that inserts a row into the Rdb MF_PERSONNEL database in the
    same ACID-proof 2PC as a client that is inserting a row into the
    NORTHWIND.employee table on Windows2000, Commit them all or roll them all
    back! (You might find the error handling useful, and you would use
    start_trans instead of start_branch)

    Cheers Richard Maher

    PS. The caps-lock key is on the left.

    ************************************************** **************************
    ********
    *
    *
    * COPYRIGHT (c) TIER3 SOFTWARE LTD. ALL RIGHTS RESERVED.
    *
    *
    *
    * THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
    ONLY *
    * IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF SUCH LICENSE AND WITH
    THE *
    * THE INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY
    OTHER *
    * COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO
    ANY *
    * OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS
    HEREBY *
    * TRANSFERRED.
    *
    *
    *
    * THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
    AND *
    * SHOULD NOT BE CONSTRUED AS A COMMITMENT BY TIER3 SOFTWARE LTD.
    *
    *
    *
    ************************************************** **************************
    ********
    identification division.
    program-id. tip_init.
    data division.
    working-storage section.
    01 ss$_debug pic s9(9) comp value external
    ss$_debug.
    01 ss$_abort pic s9(9) comp value external
    ss$_abort.
    01 ss$_normal pic s9(9) comp value external
    ss$_normal.
    01 sys_status pic s9(9) comp value external
    ss$_normal.
    *
    01 syi_item_list.
    03 item_nodename.
    05 pic s9(4) comp value 6.
    05 pic s9(4) comp value external
    syi$_nodename.
    05 pointer value
    reference local_node.
    05 pointer value
    reference local_node_len.
    03 pic s9(9) comp.
    *
    01 syi_iosb.
    03 syi_cond pic s9(9) comp.
    03 pic x(4).
    *
    01 demo_context.
    03 system_name pic x(8).
    03 buffer_size pic 9(9) comp.
    03 local_node pic x(6).
    03 local_node_len pic 9(4) comp.
    03 session_user pic x(12).
    03 persona_context pic 9(9) comp.
    *
    01 debug_on pic x(1).
    01 debug_commands.
    03 cmd_len pic x(1) value x"25".
    03 pic x(37) value "set
    language cobol; show process/full".
    *
    01 sqlcode pic s9(9) comp.
    01 db_spec.
    03 pic x(20) value "alias
    pers filename".
    03 db_filename pic x(30) value
    "mf_personnel".
    *
    01 rdb$message_vector external.
    03 rdb$lu_num_arguments pic s9(9) comp.
    03 rdb$lu_status pic s9(9) comp.
    03 rdb$alu_arguments occurs 18 times.
    05 rdb$lu_arguments pic s9(9) comp.
    *
    linkage section.
    01 t3_system_name pic x(8).
    01 t3_buffer_size pic 9(9) comp.
    procedure division using t3_system_name, t3_buffer_size giving sys_status.
    00.
    *+
    * To assist a run-time decision as to whether or not to invoke debug
    * TIER3 has defined a local DCL symbol T3$DEBUG. This symbol is set
    * to the value specified by the system manager in the Tier3 Configuration
    * file ie: "Y" or "N".
    *-
    call "lib$get_symbol" using by descriptor "T3$DEBUG", debug_on giving
    sys_status.
    if sys_status not = ss$_normal call "lib$stop" using by value
    sys_status.

    if debug_on = "Y"
    call "lib$signal"
    using by value ss$_debug, 1
    by reference debug_commands.

    move t3_system_name to system_name.
    move t3_buffer_size to buffer_size.

    call "sys$getsyiw"
    using by value 0, 0, 0
    by reference syi_item_list, syi_iosb
    by value 0, 0
    giving sys_status.
    if sys_status = ss$_normal move syi_cond to sys_status.
    if sys_status not = ss$_normal call "lib$stop" using by value
    sys_status.
    *+
    * Connect to the database to make sure it's there and for 1st query
    performance.
    *-
    call "declare_connection_name" using sqlcode, db_spec.
    if sqlcode not = zeros
    call "sys$putmsg" using rdb$message_vector
    call "lib$stop" using by value ss$_abort.

    call "t3$setctx" using demo_context giving sys_status.
    if sys_status not = ss$_normal go to fini.
    *
    fini.
    exit program.
    *
    end program tip_init.
    identification division.
    program-id. tip_logon.
    data division.
    working-storage section.
    01 t3$k_decnet pic s9(9) comp value external
    t3$k_decnet.
    01 t3$k_tcp_ip pic s9(9) comp value external
    t3$k_tcp_ip.
    01 lib$_strtru pic s9(9) comp value external
    lib$_strtru.
    01 ss$_normal pic s9(9) comp value external
    ss$_normal.
    01 sys_status pic s9(9) comp value external
    ss$_normal.
    *
    01 remote_node_name pic x(31).
    01 remote_user_name pic x(12).
    01 remote_user_socket redefines remote_user_name.
    03 remote_host_addr.
    05 rha_1 pic x.
    05 rha_2 pic x.
    05 rha_3 pic x.
    05 rha_4 pic x.
    03 remote_port_num pic 9(9) comp.
    *
    01 tcpip_rem_user_len pic 9(4) comp.
    01 tcpip_rem_user pic x(21).
    *
    linkage section.
    *
    01 demo_context.
    03 system_name pic x(8).
    03 buffer_size pic 9(9) comp.
    03 local_node pic x(6).
    03 local_node_len pic 9(4) comp.
    03 session_user pic x(12).
    03 persona_context pic 9(9) comp.
    *
    01 transport_type pic 9(4) comp.
    *
    01 remote_node_desc pic x(8).
    *
    01 remote_user_desc pic x(8).
    *
    01 local_user_desc.
    03 lud_class_len.
    05 lud_len pic 9(4) comp.
    05 lud_class pic 9(4) comp.
    03 lud_addr pic 9(9) comp.
    *
    01 local_persona pic 9(9) comp.
    *
    procedure division using demo_context,
    transport_type,
    remote_node_desc,
    remote_user_desc,
    local_user_desc,
    local_persona giving sys_status.
    00.
    call "lib$scopy_dxdx"
    using by reference remote_node_desc
    by descriptor remote_node_name
    giving sys_status.
    if sys_status not = ss$_normal and lib$_strtru go to fini.

    call "lib$scopy_dxdx"
    using by reference remote_user_desc
    by descriptor remote_user_name
    giving sys_status.
    if sys_status not = ss$_normal and lib$_strtru go to fini.

    call "lib$scopy_dxdx"
    using by reference local_user_desc
    by descriptor session_user
    giving sys_status.
    if sys_status not = ss$_normal go to fini.
    *+
    * Report the client association in the execution server's log file.
    *-
    display "Association with ", session_user(1:lud_len), " established".
    display "Transport = " transport_type with conversion.
    display "Rem node = " remote_node_name.
    display "Rem user = " no advancing.

    evaluate transport_type
    when t3$k_decnet display remote_user_name
    when t3$k_tcp_ip call "sys$fao"
    using by descriptor
    "!@UB.!@UB.!@UB.!@UB:!ZL"
    by reference
    tcpip_rem_user_len
    by descriptor
    tcpip_rem_user
    by reference rha_1,
    rha_2, rha_3, rha_4
    by value
    remote_port_num
    giving sys_status
    if sys_status not = ss$_normal go to fini
    end-if
    display tcpip_rem_user(1:tcpip_rem_user_len)
    end-evaluate.

    call "t3$persona_assume" giving sys_status.
    *
    fini.
    exit program.
    *
    end program tip_logon.
    identification division.
    program-id. tip_recv.
    data division.
    working-storage section.
    01 out_msg pointer value external
    out_msg.
    01 ddtm$m_nowait pic 9(9) comp value external
    ddtm$m_nowait.
    01 ddtm$_aborted pic 9(9) comp value external
    ddtm$_aborted.
    01 t3$m_close pic 9(9) comp value external
    t3$m_close.
    01 t3$m_now pic 9(9) comp value external
    t3$m_now.
    01 t3$m_more pic 9(9) comp value external
    t3$m_more.
    01 t3$m_oob pic 9(9) comp value external
    t3$m_oob.
    01 t3$_chanclose pic 9(9) comp value external
    t3$_chanclose.
    01 ss$_abort pic 9(9) comp value external
    ss$_abort.
    01 ss$_normal pic 9(9) comp value external
    ss$_normal.
    01 sys_status pic 9(9) comp.
    *
    01 sqlcode pic 9(9) comp.
    01 rdb$message_vector external.
    03 rdb$lu_num_arguments pic 9(9) comp.
    03 rdb$lu_status pic 9(9) comp.
    03 rdb$alu_arguments occurs 18 times.
    05 rdb$lu_arguments pic 9(9) comp.
    *
    01 sql_ctx.
    03 pic 9(9) comp value 1.
    03 pic 9(9) comp value 1.
    03 pic 9(9) comp value 16.
    03 db_tid pic x(16).
    03 pic 9(9) comp.
    *
    01 tip_tid pic x(16).
    01 tip_bid pic x(16).
    *
    01 dtm_iosb.
    03 dtm_iosb_status pic 9(4) comp.
    03 pic x(2).
    03 reason_code pic 9(9) comp.
    *
    01 tip_tm_url_rec.
    03 pic xx value "11".
    03 tip_tm_url_len pic 9(4) comp.
    03 tip_tm_url pic x(128).
    *
    01 abort_msg pic x(255).
    01 out_len pic 9(4) comp.
    01 comp_status.
    03 pic x(2) value "22".
    03 commit_flag pic x(1).
    *
    linkage section.
    *
    01 demo_context.
    03 system_name pic x(8).
    03 buffer_size pic 9(9) comp.
    03 local_node pic x(6).
    03 local_node_len pic 9(4) comp.
    03 session_user pic x(12).
    03 persona_context pic 9(9) comp.
    *
    01 msg_buff.
    03 msg_type pic x(2).
    03 pic x(508).

    01 update_bal_msg redefines msg_buff.
    03 pic x(2).
    03 dept_name pic x(30).
    03 tip_txn_url pic x(256).
    *
    01 msg_size pic s9(9) comp.
    *
    01 msg_flags pic s9(9) comp.
    *
    procedure division
    using demo_context,
    msg_buff,
    msg_size,
    msg_flags
    giving sys_status.
    kick_off section.
    00.
    evaluate msg_type
    when "10" perform get_tm_url
    when "20" perform update_account_bal_push
    when other move ss$_abort to sys_status
    end-evaluate.

    if sys_status = t3$_chanclose move ss$_normal to sys_status.

    exit program.
    *
    get_tm_url section.
    00.
    call "t3$tip_get_tm_url"
    using by descriptor tip_tm_url
    by reference tip_tm_url_len
    giving sys_status.
    if sys_status not = ss$_normal call "lib$stop" using by value
    sys_status.

    add 4 to tip_tm_url_len giving out_len.
    call "t3$send"
    using by reference tip_tm_url_rec
    by value out_len, t3$m_close
    giving sys_status.
    *
    update_account_bal_push section.
    00.
    call "t3$tip_url_to_tid"
    using by descriptor tip_txn_url of update_bal_msg(1msg_size -
    32))
    by reference tip_tid, tip_bid
    giving sys_status.
    if sys_status not = ss$_normal call "lib$stop" using by value
    sys_status.

    call "sys$start_branchw"
    using by value 0, 0
    by reference dtm_iosb
    by value 0, 0
    by reference tip_tid
    by descriptor local_node(1:local_node_len)
    by reference tip_bid
    giving sys_status.
    if sys_status = ss$_normal move dtm_iosb_status to sys_status.
    if sys_status not = ss$_normal call "lib$stop" using by value
    sys_status.
    *
    move tip_tid to db_tid.
    perform the_update.
    *
    call "t3$send"
    using by reference comp_status
    by value 3, t3$m_close
    giving sys_status.
    if sys_status = t3$_chanclose
    move "N" to commit_flag
    else
    if sys_status not = ss$_normal
    call "lib$stop" using by value sys_status.

    if commit_flag = "Y"
    perform commit_trans
    else perform abort_trans.
    *
    fini.
    *
    the_update section.
    00.
    call "set_trans_rw" using sqlcode, sql_ctx.
    if rdb$lu_status not = ss$_normal
    call "sys$putmsg" using rdb$message_vector
    call "lib$stop" using by value ss$_abort.

    call "update_dept" using sqlcode, dept_name, sql_ctx.
    if rdb$lu_status not = ss$_normal
    move "N" to commit_flag
    call "sys$putmsg"
    using by reference rdb$message_vector
    by value out_msg, 0, 0
    giving sys_status
    if sys_status not = ss$_normal
    call "lib$stop" using by value sys_status
    end-if
    else
    move "Y" to commit_flag.
    *
    fini.
    *
    commit_trans section.
    00.
    call "sys$end_branchw"
    using by value 0, 0
    by reference dtm_iosb
    by value 0, 0
    by reference tip_tid, tip_bid
    giving sys_status.
    if sys_status not = ss$_normal call "lib$stop" using by value
    sys_status.
    *
    if dtm_iosb_status = ss$_abort
    if reason_code not = zeros
    call "sys$getmsg"
    using by value reason_code
    by reference out_len
    by descriptor abort_msg
    by value 0,0
    giving sys_status
    if sys_status not = ss$_normal
    call "lib$stop" using by value sys_status
    end-if
    display "Couldn't commit - " abort_msg (1ut_len)
    end-if
    else
    if dtm_iosb_status not = ss$_normal
    call "lib$stop" using by value dtm_iosb_status.
    *
    abort_trans section.
    00.
    call "sys$abort_transw"
    using by value 0, ddtm$m_nowait
    by reference dtm_iosb
    by value 0, 0
    by reference tip_tid
    by value ddtm$_aborted
    by reference tip_bid
    giving sys_status.
    if sys_status = ss$_normal move dtm_iosb_status to sys_status.
    if sys_status not = ss$_normal call "lib$stop" using by value
    sys_status.
    *
    end program tip_recv.
    identification division.
    program-id. tip_logoff.
    data division.
    working-storage section.
    01 iss$c_id_natural pic 9(9) comp value external
    iss$c_id_natural.
    01 ss$_normal pic s9(9) comp value external
    ss$_normal.
    01 sys_status pic s9(9) comp.
    *
    linkage section.
    *
    01 demo_context.
    03 system_name pic x(8).
    03 buffer_size pic 9(9) comp.
    03 local_node pic x(6).
    03 local_node_len pic 9(4) comp.
    03 session_user pic x(12).
    03 persona_context pic 9(9) comp.
    *
    procedure division using demo_context giving sys_status.
    00.
    display "Session completed with user ", session_user.
    move spaces to session_user.

    call "sys$persona_assume" using iss$c_id_natural, omitted giving
    sys_status.
    *
    fini.
    exit program.
    *
    end program tip_logoff.
    identification division.
    program-id. tip_fini.
    data division.
    working-storage section.
    01 ss$_abort pic s9(9) comp value external
    ss$_abort.
    01 ss$_normal pic s9(9) comp value external
    ss$_normal.
    *
    01 sqlcode pic s9(9) comp.
    *
    01 rdb$message_vector external.
    03 rdb$lu_num_arguments pic s9(9) comp.
    03 rdb$lu_status pic s9(9) comp.
    03 rdb$alu_arguments occurs 18 times.
    05 rdb$lu_arguments pic s9(9) comp.
    *
    linkage section.
    *
    01 demo_context.
    03 system_name pic x(8).
    03 buffer_size pic 9(9) comp.
    03 local_node pic x(6).
    03 local_node_len pic 9(4) comp.
    03 session_user pic x(12).
    03 persona_context pic 9(9) comp.
    *
    procedure division using demo_context giving ss$_normal.
    00.
    display "Execution server shutting down".

    call "disconnect_db" using sqlcode
    if sqlcode not = zeros
    call "sys$putmsg" using rdb$message_vector
    call "lib$stop" using by value ss$_abort.

    exit program.
    *
    end program tip_fini.
    identification division.
    program-id. tip_int.
    data division.
    working-storage section.
    01 ss$_normal pic s9(9) comp value external
    ss$_normal.
    01 link_lost pic x(1) value x"01".
    *
    linkage section.
    *
    01 demo_context.
    03 system_name pic x(8).
    03 buffer_size pic 9(9) comp.
    03 local_node pic x(6).
    03 local_node_len pic 9(4) comp.
    03 session_user pic x(12).
    03 persona_context pic 9(9) comp.
    *
    01 interrupt_msg pic x(16).
    *
    01 interrupt_type pic 9(9) comp.
    88 system_msg value external
    t3$k_system.
    88 user_msg value external
    t3$k_user.
    *
    procedure division
    using demo_context,
    interrupt_msg,
    interrupt_type
    giving ss$_normal.
    00.
    if (system_msg and interrupt_msg(1:1) = link_lost)
    display "Link to client has been lost".

    exit program.
    *
    end program tip_int.
    identification division.
    program-id. out_msg.
    *+
    * Send Rdb error messages back for output in VB-Net message window.
    *-
    data division.
    working-storage section.
    *+
    * If you're using DECnet you can initialize send_flags =

    * TIER3 will tell DECnet to group your messages so that your client
    application
    * receives a single record. (TCP/IP is obviously stream oriented)
    *-
    01 send_flags pic 9(9) comp value external send_flags.
    01 t3$m_now pic 9(9) comp value external t3$m_now.
    01 t3$_chanclose pic 9(9) comp value external
    t3$_chanclose.
    01 ss$_abort pic 9(9) comp value external ss$_abort.
    01 ss$_normal pic 9(9) comp value external ss$_normal.
    01 sys_status pic 9(9) comp.
    *+
    * Intel and Alpha are same endian so just send it as an integer.
    *-
    01 reply_hdr.
    03 error_id pic xx value "88".
    03 error_len pic 9(4) comp.
    *
    linkage section.
    *
    01 msg_desc.
    03 msg_len pic 9(4) comp.
    03 msg_class pic 9(4) comp.
    03 msg_addr pointer.
    *
    procedure division using msg_desc giving ss$_abort.
    00.
    move msg_len to error_len.

    call "t3$send" using reply_hdr by value 4, send_flags giving sys_status.
    if sys_status = ss$_normal
    call "t3$send"
    using by value msg_addr, msg_len, t3$m_now
    giving sys_status.

    if sys_status not = t3$_chanclose and ss$_normal
    call "lib$stop" using by value sys_status.
    *
    fini.
    exit program.
    *
    end program out_msg.

    "Richard Maher" wrote in message
    news:fajppt$4g0$1@news-01.bur.connect.com.au...
    > Hi Paul,
    >
    > "933B" looks strange. As someone else already suggested, you need to

    create
    > a log file with $MC LMCP. The other thing you need to do is look for this
    > logical: - DECDTM$INHIBIT and if it's set to true then set it to false and
    > re-run the startup. You won't need the XG startup as that's for the XA
    > Gateway which is only of interest if you want your RMS updates controlled

    by
    > some sort of XA monitor like Tuxedo. (The XA Veneer on the other hand

    (that
    > doesn't need a seperate process) is useful if you want to update Orrible
    > Oracle on VMS in the same 2PC as your Rdb, RMS (and possibly Windows SQL
    > Server) databases.
    >
    > I still don't know why people persist in saying that VAX COBOL does not
    > support commit/rollback verbs when the pointer to the docs that I posted
    > previous seems to show that it does? No matter; now that I know what

    you're
    > doing I'm intrigued!
    >
    > I love VMS (always will) I love seeing stuff ported to VMS; the more the
    > better! Having said that, who the hell is giving you funding for this

    crap?
    > Keep it on IBM and just change the incontinence nappies every now and then
    > (works for VMS engineering :-)
    >
    > OK we are where we are: - What database exactly was the COBOL talking to

    on
    > IBM? DB2? Or a Codasyl compliant database? VISAM? I thought (not knowing
    > anything at all about IBM) that all the CICS stuff used precompilers and

    had
    > EXEC-SQL in the code everywhere.
    >
    > What about all the JCL? How do you intend to backup your data? You may

    have
    > RUJ functionality but what about AIJ functionality and roll forward to

    point
    > in time? Does it get distributed anywhere? Data wharehouses?
    >
    > Look I'm sure you thought all this through and I wish you well, but if you
    > want cheap, leave it on IBM. If you want to do it right then re-write it

    on
    > VMS. Me? I'd go Rdb *every* time, despite the poisonous, self-serving ,
    > oligarchic gravy-train that is currently running it into the buffers.
    >
    > Cheers Richard Maher
    >
    > PS. Here's a web site where you can often hear from Jim Johnson if you

    miss
    > him, and can also reminisce about what it was like to be in a living
    > development environment: -
    >
    > http://forums.microsoft.com/MSDN/Sho...D=388&SiteID=1
    >
    > Digital had it way back when :-(
    >
    > PPS> There used to be an RPG II compiler on PDPs don't know if it ever

    made
    > it to VMS.
    >
    > "Paul Raulerson" wrote in message
    > news:000301c7e532$25d7be90$71873bb0$@com...
    > >
    > > [SNIP SNIP SNIP]
    > > > -----Original Message-----
    > > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > > Sent: Wednesday, August 22, 2007 6:11 PM
    > > > To: Info-VAX@Mvb.Saic.Com
    > > > Subject: Re: COBOL Transactions?
    > > >

    > > [SNIP]
    > >
    > > Hey Richard, do you have a pointer to how to turn this DDTM *on*?
    > > I have found:
    > > DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1
    > > DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1
    > > DECDTM$STARTUP.COM;1
    > >
    > > and ran the DECDTM$STARTUP.com script, which seems to have succeeded.

    Also
    > > ran the DDTM$XG_START_SERVER.com
    > > script, and they *seem* to be running.
    > >
    > > Marked a test file with SET FILE/RU_JOURNAL and it seems to report

    itself
    > > correctly.
    > >
    > > Constantly get back a failure code, 933B.
    > >
    > > Ran the example script, created the files and still get the same error

    > code.
    > > I do not know if it is a license thing or not. Show license finds the
    > > following lines, so I think it is licensed.
    > >
    > > DTM DEC 0 0 100 0.0 (none)
    > > 31-JUL-2008
    > > RMSJNL DEC 0 0 100 0.0 (none)
    > > 31-JUL-2008
    > >
    > > I cannot find any startup files or stuff with *RMS* in the name to run

    or
    > > whatever.
    > >
    > > I did scan through the manuals I could find, and the RMS Journal manual

    > was
    > > clear that DECdtm has to be
    > > running first, but ... not really working. Advice? Pointers?

    > Thanks -Paul
    > >
    > >

    >
    >




  9. Re: COBOL Transactions?

    On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
    wrote:

    > On 08/23/07 08:25, Tom Linden wrote:
    >> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    >> wrote:
    >>
    >>> Not so. 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 is to supply the BEGIN TRANSACTION keywords, though
    >>> it is
    >>> not required in the language spec for COBOL 85. I believe it is for
    >>> the new
    >>> spec coming out...

    >>
    >> Indexed file handling is in the PL/I semantics.

    >
    > Yeah, but anyone in his right mind knows that PL/1 sucks.
    >

    That would be PL/I BTW, you obviously know little about programming
    languages.


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

  10. RE: COBOL Transactions?



    > -----Original Message-----
    > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > Sent: Thursday, August 23, 2007 6:04 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > Hi Paul,
    >

    Thanks, between you and Alex that absolutely targeted the problem. Works
    great right now.

    > I still don't know why people persist in saying that VAX COBOL does not
    > support commit/rollback verbs when the pointer to the docs that I
    > posted
    > previous seems to show that it does? No matter; now that I know what
    > you're
    > doing I'm intrigued!
    >
    > I love VMS (always will) I love seeing stuff ported to VMS; the more
    > the
    > better! Having said that, who the hell is giving you funding for this
    > crap?
    > Keep it on IBM and just change the incontinence nappies every now and
    > then
    > (works for VMS engineering :-)
    >


    Funding is from me, myself, and my wife. One reason why I need to
    make sure it will work on the cheap.
    We do have some alternatives, but none of them are quite as cool as the
    small Itanium packages available from HP, and well - VMS is pretty nice.
    Different, but nice.



    > OK we are where we are: - What database exactly was the COBOL talking
    > to on
    > IBM? DB2? Or a Codasyl compliant database? VISAM? I thought (not
    > knowing
    > anything at all about IBM) that all the CICS stuff used precompilers
    > and had
    > EXEC-SQL in the code everywhere.
    >


    Depends on the customer of course, it can be DB/2, Oracle, AdaBASE, or a few
    others. I tend to prefer CICS and VSAM files for most things, and DB/2 for
    everything else. DB/2 is built for performance on the mainframe, and it
    shows. CICS does use a precompiler, but if you use the database, you are
    just using the database; little or no
    recourse to CICS.

    VSAM access, on the other hand, is serialized in CICS and can cross regions
    easily. EXEC CICS READ etc. CICS (or Transaction Server, to use it's now 10
    year old "new" name... is really how you run interactive programs on
    z/OS, since z/OS itself is not the worlds most interactive environment.
    Foreground compiles are frowned upon, to say the least. VMS is so
    interaction it seems almost chaotic at times, or perhaps just libertarian?


    > What about all the JCL? How do you intend to backup your data? You may
    > have
    > RUJ functionality but what about AIJ functionality and roll forward to
    > point
    > in time? Does it get distributed anywhere? Data wharehouses?
    >


    The (so far very small) Data Warehouse and business intelligence processing
    takes advantage of DB/2 almost entirely. It is not a terribly important part
    to port immediately, and is scheduled for porting after I have gotten much
    further through than I have right now.

    JCL isn't so much of a big deal in an interactive environment; it looks like
    an awful lot of that can be setup for interactive sessions via DCL, and what
    little cannot, can be handled with standalone DCL programs (.COM files?)

    Backup and so forth are issues I have to address. In the very lowest end
    market, it ain't much of a problem. Stick a DVD in there once a week or so,
    and a tape per day. At the high end, the local system programmers will take
    care of it. But in the middle regions, from the modest little small business
    up to the midsize companies, it can become an issue. I am thinking of taking
    an appliance approach, or selling remote services for backup, or something.

    I don't have a good plan there. Open to ideas!


    > Look I'm sure you thought all this through and I wish you well, but if
    > you
    > want cheap, leave it on IBM. If you want to do it right then re-write
    > it on
    > VMS. Me? I'd go Rdb *every* time, despite the poisonous, self-serving
    > ,
    > oligarchic gravy-train that is currently running it into the buffers.
    >


    It ain't cheap on the IBM. Just to run zSeries today, you have to spend
    close to $700K, and that's usually before software costs. Would you believe
    that 5 years ago, you could entry level for a mere $60K? Or even less.
    (*sigh*)
    If you move everything to iSeries (AS/400) or pSeries (RS/6000) yeah, it
    gets cheaper. $14K - $18K entry on the iSeries, and 4K to 9K entry on the
    RS/6000. But - iSeries programs are very different, and mainframe style
    programs do *not* port all that well. (Well, the screens do...) On the
    RS/6000, you spend more time building the tools to build the tools to build
    the tools than you do getting anything done, unless of course, you are
    willing to mortgage your future to MicroFocus or some other $400/user
    solution. Yuck.

    VMS has the unique distinction of being available on Tiny machines all the
    way up to near mainframe class machines. And is a rich operating systems
    with a very high class, if wordy when you make an error, COBOL compiler.

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

    Thanks again for the advice and help!

    _Paul

    > Cheers Richard Maher
    >
    > PS. Here's a web site where you can often hear from Jim Johnson if you
    > miss
    > him, and can also reminisce about what it was like to be in a living
    > development environment: -
    >
    > http://forums.microsoft.com/MSDN/Sho...D=388&SiteID=1
    >
    > Digital had it way back when :-(
    >
    > PPS> There used to be an RPG II compiler on PDPs don't know if it ever
    > made
    > it to VMS.
    >
    > "Paul Raulerson" wrote in message
    > news:000301c7e532$25d7be90$71873bb0$@com...
    > >
    > > [SNIP SNIP SNIP]
    > > > -----Original Message-----
    > > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > > Sent: Wednesday, August 22, 2007 6:11 PM
    > > > To: Info-VAX@Mvb.Saic.Com
    > > > Subject: Re: COBOL Transactions?
    > > >

    > > [SNIP]
    > >
    > > Hey Richard, do you have a pointer to how to turn this DDTM *on*?
    > > I have found:
    > > DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1
    > > DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1
    > > DECDTM$STARTUP.COM;1
    > >
    > > and ran the DECDTM$STARTUP.com script, which seems to have succeeded.

    > Also
    > > ran the DDTM$XG_START_SERVER.com
    > > script, and they *seem* to be running.
    > >
    > > Marked a test file with SET FILE/RU_JOURNAL and it seems to report

    > itself
    > > correctly.
    > >
    > > Constantly get back a failure code, 933B.
    > >
    > > Ran the example script, created the files and still get the same

    > error
    > code.
    > > I do not know if it is a license thing or not. Show license finds the
    > > following lines, so I think it is licensed.
    > >
    > > DTM DEC 0 0 100 0.0 (none)
    > > 31-JUL-2008
    > > RMSJNL DEC 0 0 100 0.0 (none)
    > > 31-JUL-2008
    > >
    > > I cannot find any startup files or stuff with *RMS* in the name to

    > run or
    > > whatever.
    > >
    > > I did scan through the manuals I could find, and the RMS Journal

    > manual
    > was
    > > clear that DECdtm has to be
    > > running first, but ... not really working. Advice? Pointers?

    > Thanks -Paul
    > >
    > >

    >




  11. RE: COBOL Transactions?

    Wow - I freely admit to ignorance on this - I've always (in the IBM world)
    seen it written as PL/1, with an arabic "1" instead of a Roman Numeral "I".
    They *are* the same language are they not, or are they different?

    -Paul


    > -----Original Message-----
    > From: Tom Linden [mailto:tom@kednos.company]
    > Sent: Thursday, August 23, 2007 8:03 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
    > wrote:
    >
    > > On 08/23/07 08:25, Tom Linden wrote:
    > >> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson

    >
    > >> wrote:
    > >>
    > >>> Not so. 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 is to supply the BEGIN TRANSACTION keywords,

    > though
    > >>> it is
    > >>> not required in the language spec for COBOL 85. I believe it is for
    > >>> the new
    > >>> spec coming out...
    > >>
    > >> Indexed file handling is in the PL/I semantics.

    > >
    > > Yeah, but anyone in his right mind knows that PL/1 sucks.
    > >

    > That would be PL/I BTW, you obviously know little about programming
    > languages.
    >
    >
    > --
    > PL/I for OpenVMS
    > www.kednos.com



  12. Re: COBOL Transactions?

    On Thu, 23 Aug 2007 18:31:56 -0700, Paul Raulerson
    wrote:

    > Wow - I freely admit to ignorance on this - I've always (in the IBM
    > world)
    > seen it written as PL/1, with an arabic "1" instead of a Roman Numeral
    > "I".
    > They *are* the same language are they not, or are they different?
    >

    Yes. Even on IBM gear it is the Roman numeral.


    > -Paul
    >
    >
    >> -----Original Message-----
    >> From: Tom Linden [mailto:tom@kednos.company]
    >> Sent: Thursday, August 23, 2007 8:03 PM
    >> To: Info-VAX@Mvb.Saic.Com
    >> Subject: Re: COBOL Transactions?
    >>
    >> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
    >> wrote:
    >>
    >> > On 08/23/07 08:25, Tom Linden wrote:
    >> >> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson

    >>
    >> >> wrote:
    >> >>
    >> >>> Not so. 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 is to supply the BEGIN TRANSACTION keywords,

    >> though
    >> >>> it is
    >> >>> not required in the language spec for COBOL 85. I believe it is for
    >> >>> the new
    >> >>> spec coming out...
    >> >>
    >> >> Indexed file handling is in the PL/I semantics.
    >> >
    >> > Yeah, but anyone in his right mind knows that PL/1 sucks.
    >> >

    >> That would be PL/I BTW, you obviously know little about programming
    >> languages.
    >>
    >>
    >> --
    >> PL/I for OpenVMS
    >> www.kednos.com

    >




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

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

    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.

    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.

    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", "is there
    an RPG compiler for OpenVMS", "is it RDB or RMS that handles indexed
    file support", "how do I convert a status value to text in Cobol",
    etcetera.


  14. Re: COBOL Transactions?

    Ron Johnson wrote:
    > On 08/23/07 08:25, Tom Linden wrote:
    >> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    >> wrote:
    >>
    >>> Not so. 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 is to supply the BEGIN TRANSACTION keywords, though
    >>> it is
    >>> not required in the language spec for COBOL 85. I believe it is for
    >>> the new
    >>> spec coming out...

    >> Indexed file handling is in the PL/I semantics.

    >
    > Yeah, but anyone in his right mind knows that PL/1 sucks.
    >


    It had (has?) all the best features of cobol and fortran (and C)
    combined into a single package.

  15. Re: COBOL Transactions?

    In article ,
    "Tom Linden" writes:
    > On Thu, 23 Aug 2007 18:31:56 -0700, Paul Raulerson
    > wrote:
    >
    >> Wow - I freely admit to ignorance on this - I've always (in the IBM
    >> world)
    >> seen it written as PL/1, with an arabic "1" instead of a Roman Numeral
    >> "I".
    >> They *are* the same language are they not, or are they different?
    >>

    > Yes. Even on IBM gear it is the Roman numeral.


    I don't want to start a flame war over something as trivial as this, but
    it was definitely a "1" on the Primes I worked on and I have numerous
    books in my library (sadly, packed up at this point so I can't get any
    actual titles) that use the logo "PL/1".

    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

  16. Re: COBOL Transactions?

    On 08/23/07 20:02, Tom Linden wrote:
    > On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
    > wrote:
    >
    >> On 08/23/07 08:25, Tom Linden wrote:
    >>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    >>> wrote:
    >>>
    >>>> Not so. 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 is to supply the BEGIN TRANSACTION keywords, though
    >>>> it is
    >>>> not required in the language spec for COBOL 85. I believe it is for
    >>>> the new
    >>>> spec coming out...
    >>>
    >>> Indexed file handling is in the PL/I semantics.

    >>
    >> Yeah, but anyone in his right mind knows that PL/1 sucks.
    >>

    > That would be PL/I BTW, you obviously know little about programming
    > languages.


    So you also say that PL/I sucks?

    (Just jerking your chain, Tom, since you are such a big booster of a
    not-so-popular-anymore language. Was it ever very popular outside
    the mainframe?)

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

  17. Re: COBOL Transactions?

    In article ,
    Ron Johnson writes:
    > On 08/23/07 20:02, Tom Linden wrote:
    >> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
    >> wrote:
    >>
    >>> On 08/23/07 08:25, Tom Linden wrote:
    >>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    >>>> wrote:
    >>>>
    >>>>> Not so. 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 is to supply the BEGIN TRANSACTION keywords, though
    >>>>> it is
    >>>>> not required in the language spec for COBOL 85. I believe it is for
    >>>>> the new
    >>>>> spec coming out...
    >>>>
    >>>> Indexed file handling is in the PL/I semantics.
    >>>
    >>> Yeah, but anyone in his right mind knows that PL/1 sucks.
    >>>

    >> That would be PL/I BTW, you obviously know little about programming
    >> languages.

    >
    > So you also say that PL/I sucks?
    >
    > (Just jerking your chain, Tom, since you are such a big booster of a
    > not-so-popular-anymore language. Was it ever very popular outside
    > the mainframe?)


    Minicomputers. Prime used it and much of the OS and utilites was written
    in PL/1 :-) and various subset dialects.

    Microcomputers. PL/M (well, it may not be PL/1, but I think it qualifies
    as a dialect.)

    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

  18. Re: COBOL Transactions?

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

    > In article ,
    > "Tom Linden" writes:
    >> On Thu, 23 Aug 2007 18:31:56 -0700, Paul Raulerson
    >> wrote:
    >>
    >>> Wow - I freely admit to ignorance on this - I've always (in the IBM
    >>> world)
    >>> seen it written as PL/1, with an arabic "1" instead of a Roman Numeral
    >>> "I".
    >>> They *are* the same language are they not, or are they different?
    >>>

    >> Yes. Even on IBM gear it is the Roman numeral.

    >
    > I don't want to start a flame war over something as trivial as this, but
    > it was definitely a "1" on the Primes I worked on and I have numerous
    > books in my library (sadly, packed up at this point so I can't get any
    > actual titles) that use the logo "PL/1".

    Well that was my compiler, and the command was
    pli
    >
    > bill
    >




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

  19. Re: COBOL Transactions?

    On Fri, 24 Aug 2007 05:31:18 -0700, Ron Johnson
    wrote:

    > On 08/23/07 20:02, Tom Linden wrote:
    >> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
    >> wrote:
    >>
    >>> On 08/23/07 08:25, Tom Linden wrote:
    >>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    >>>>
    >>>> wrote:
    >>>>
    >>>>> Not so. 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 is to supply the BEGIN TRANSACTION keywords,
    >>>>> though
    >>>>> it is
    >>>>> not required in the language spec for COBOL 85. I believe it is for
    >>>>> the new
    >>>>> spec coming out...
    >>>>
    >>>> Indexed file handling is in the PL/I semantics.
    >>>
    >>> Yeah, but anyone in his right mind knows that PL/1 sucks.
    >>>

    >> That would be PL/I BTW, you obviously know little about programming
    >> languages.

    >
    > So you also say that PL/I sucks?
    >
    > (Just jerking your chain, Tom, since you are such a big booster of a
    > not-so-popular-anymore language. Was it ever very popular outside
    > the mainframe?)

    And I yours:-) It sold pretty well on the VAX, and was/is used by many of
    the
    three letter agencies both here and abroad. Did/does very well in
    Aerospace (used
    both at NASA and ESA) and Automotive, Steel, Insurance, Banking
    >

    Here is a good piece of propoganda
    http://www.kednos.com/pli/king.pdf


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

  20. Re: COBOL Transactions?

    On 08/24/07 08:18, Bill Gunshannon wrote:
    > In article ,
    > Ron Johnson writes:
    >> On 08/23/07 20:02, Tom Linden wrote:
    >>> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
    >>> wrote:
    >>>
    >>>> On 08/23/07 08:25, Tom Linden wrote:
    >>>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
    >>>>> wrote:
    >>>>>
    >>>>>> Not so. 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 is to supply the BEGIN TRANSACTION keywords, though
    >>>>>> it is
    >>>>>> not required in the language spec for COBOL 85. I believe it is for
    >>>>>> the new
    >>>>>> spec coming out...
    >>>>> Indexed file handling is in the PL/I semantics.
    >>>> Yeah, but anyone in his right mind knows that PL/1 sucks.
    >>>>
    >>> That would be PL/I BTW, you obviously know little about programming
    >>> languages.

    >> So you also say that PL/I sucks?
    >>
    >> (Just jerking your chain, Tom, since you are such a big booster of a
    >> not-so-popular-anymore language. Was it ever very popular outside
    >> the mainframe?)

    >
    > Minicomputers. Prime used it and much of the OS and utilites was written
    > in PL/1 :-) and various subset dialects.


    Prime has been dead for how many years now? 15?

    > Microcomputers. PL/M (well, it may not be PL/1, but I think it qualifies
    > as a dialect.)


    Who used PL/M besides DRI?

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