Recommended HP COBOL way to exit a paragraph or perform early? - VMS

This is a discussion on Recommended HP COBOL way to exit a paragraph or perform early? - VMS ; I'm a little puzzled what the recommended method here is for this case (see sample code snippet below)... use a goto? Some System call? Embed everything in a deep nesting of Ifs? In this sample, the code is being ran ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Recommended HP COBOL way to exit a paragraph or perform early?

  1. Recommended HP COBOL way to exit a paragraph or perform early?

    I'm a little puzzled what the recommended method here is for this case (see
    sample code snippet below)... use a goto? Some System call? Embed everything
    in a deep nesting of Ifs?


    In this sample, the code is being ran from a performed paragraph. There are
    three file writes necessary for this transaction to succeed, with this being
    one of the sequence. If this one fails, the transaction is aborted (rolled
    back I believe and the processing should return to the parent calling
    process. In a previous life, I would have stuffed a GOBACK in there right
    after the END-WRITE, or even just before the END-WRITE.

    In this life, I do not know the best or most preferred way to do that.

    -Paul

    WRITE DC00-RECORD
    INVALID KEY
    CALL "SYS$ABORT_TRANSW" USING BY VALUE EFN
    BY VALUE 0
    BY REFERENCE IOSB
    BY VALUE 0
    BY VALUE 0
    BY REFERENCE TID
    DISPLAY '>>> DC00 WRITE FAILED WITH INVALID KEY'
    LINE 21 ERASE LINE
    ACCEPT WS-USER-CHOICE
    END-WRITE
    ----> I want to GOBACK here


  2. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    Hi Paul,

    I don't know what HP recommend but, to answer your specific question, I
    would have a label "fini" as the last thing in a section and "go to fini.".

    But then I would also check the statii returned from all system calls and
    call "lib$stop" if they contain any value I wasn't prepared to handle. I
    also wouldn't attempt to do everything as part of the "invalid key" clause
    but rather perform a rollback section or paragraph. If you are not using
    sections but rather as you say a "performed paragraph" then yes I would use
    nested IFs. If it was a sub-program then some would use numerous "exit
    program"s but I don't. (Be aware that EXIT does nothing in DEC COBOL
    sections; don't know if that is the case with IBM COBOL)

    Also the passing mechanism for COBOL is defaulted to that of the last
    parameter (or BY REFERENCE if it is the first) so

    > BY VALUE 0
    > BY VALUE 0
    > BY REFERENCE TID


    could also be represented as "by value 0, 0 by reference TID".

    Maybe something like: -

    perform my_trans.
    if abort_it = "n"
    perform commit_trans
    else
    perform abort_trans.

    stop run.

    my_trans section.
    move "N" to abort_it.
    do write-1 invalid key go to fini.
    do write-2 invalid key go to fini.
    do rewrite-1 invalid key go to fini.
    fini.
    if rms-sts of current-file not = rms$_normal
    move "Y" to abort_it
    call "sys$putmsg" using rms-sts of . . . .

    next_sect.

    Cheers Richard Maher

    PS. I also would NOT USE UPPERCASE :-)

    "Paul Raulerson" wrote in message
    news:001601c7ece9$ad796e20$086c4a60$@com...
    > I'm a little puzzled what the recommended method here is for this case

    (see
    > sample code snippet below)... use a goto? Some System call? Embed

    everything
    > in a deep nesting of Ifs?
    >
    >
    > In this sample, the code is being ran from a performed paragraph. There

    are
    > three file writes necessary for this transaction to succeed, with this

    being
    > one of the sequence. If this one fails, the transaction is aborted (rolled
    > back I believe and the processing should return to the parent calling
    > process. In a previous life, I would have stuffed a GOBACK in there right
    > after the END-WRITE, or even just before the END-WRITE.
    >
    > In this life, I do not know the best or most preferred way to do that.
    >
    > -Paul
    >
    > WRITE DC00-RECORD
    > INVALID KEY
    > CALL "SYS$ABORT_TRANSW" USING BY VALUE EFN
    > BY VALUE 0
    > BY REFERENCE IOSB
    > BY VALUE 0
    > BY VALUE 0
    > BY REFERENCE TID
    > DISPLAY '>>> DC00 WRITE FAILED WITH INVALID KEY'
    > LINE 21 ERASE LINE
    > ACCEPT WS-USER-CHOICE
    > END-WRITE
    > ----> I want to GOBACK here
    >




  3. RE: Recommended HP COBOL way to exit a paragraph or perform early?



    > -----Original Message-----
    > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > Sent: Saturday, September 01, 2007 6:16 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Recommended HP COBOL way to exit a paragraph or perform
    > early?
    >
    > Hi Paul,
    >
    > I don't know what HP recommend but, to answer your specific question, I
    > would have a label "fini" as the last thing in a section and "go to
    > fini.".
    >


    This is essentially the same thought I came up with, though I admit to being
    a little
    unhappy with it. If anyplace, error processing like this is the place for a
    GO TO.

    > But then I would also check the statii returned from all system calls
    > and


    I do, but I stripped it out to make the example smaller and clearer.

    > call "lib$stop" if they contain any value I wasn't prepared to handle.


    What the heck is lib$stop???

    > I
    > also wouldn't attempt to do everything as part of the "invalid key"
    > clause
    > but rather perform a rollback section or paragraph. If you are not
    > using
    > sections but rather as you say a "performed paragraph" then yes I would
    > use
    > nested IFs.


    I tend to not use sections in executable code very often, but that is just
    coding
    style. I have some code I maintain that is - well - almost comical in how
    they used
    sections to excess. Ah well, one day they will pay me to rewrite it.

    IBM code is structured differently internally, so a GOBACK in the INVALID
    KEY sequence
    acts for all intents and purposes, like the GO TO FINI idea.

    >If it was a sub-program then some would use numerous "exit
    > program"s but I don't. (Be aware that EXIT does nothing in DEC COBOL
    > sections; don't know if that is the case with IBM COBOL)
    >


    Yeah, its different. It was an eye opening discovery when I read that in
    the manual
    a few weeks ago.

    > Also the passing mechanism for COBOL is defaulted to that of the last
    > parameter (or BY REFERENCE if it is the first) so
    >
    > > BY VALUE 0
    > > BY VALUE 0
    > > BY REFERENCE TID

    >
    > could also be represented as "by value 0, 0 by reference TID".
    >
    > Maybe something like: -
    >
    > perform my_trans.
    > if abort_it = "n"
    > perform commit_trans
    > else
    > perform abort_trans.
    >
    > stop run.
    >
    > my_trans section.
    > move "N" to abort_it.
    > do write-1 invalid key go to fini.
    > do write-2 invalid key go to fini.
    > do rewrite-1 invalid key go to fini.
    > fini.
    > if rms-sts of current-file not = rms$_normal
    > move "Y" to abort_it
    > call "sys$putmsg" using rms-sts of . . . .
    >


    This is for all intents and purposes, the code I came out with too.
    Except for the use of the rms specific stuff. Still studying on that.


    > next_sect.
    >
    > Cheers Richard Maher
    >
    > PS. I also would NOT USE UPPERCASE :-)


    LOL! Well, it is a bit of a bad habit, but COBOL and ASSEMBLER
    just look strange to me in lower case. I'm still adjusting to this
    Terminal format, which I like. One step at a time.

    BTW: Converting code to terminal format does have a nasty little drawback;
    it makes it quite incompatible with legacy code on the IBM. The REFORMAT
    utility is not usable in this case, because it insists on putting the
    sequence numbers in 1-6. Moving to terminal format was a big commitment to
    me, even if the compile will handle ANSI format. The 2002 standard pretty
    much
    makes "terminal" format mandatory to support for all COBOL compilers though.

    -Paul

    >
    > "Paul Raulerson" wrote in message
    > news:001601c7ece9$ad796e20$086c4a60$@com...
    > > I'm a little puzzled what the recommended method here is for this

    > case
    > (see
    > > sample code snippet below)... use a goto? Some System call? Embed

    > everything
    > > in a deep nesting of Ifs?
    > >
    > >
    > > In this sample, the code is being ran from a performed paragraph.

    > There
    > are
    > > three file writes necessary for this transaction to succeed, with

    > this
    > being
    > > one of the sequence. If this one fails, the transaction is aborted

    > (rolled
    > > back I believe and the processing should return to the parent

    > calling
    > > process. In a previous life, I would have stuffed a GOBACK in there

    > right
    > > after the END-WRITE, or even just before the END-WRITE.
    > >
    > > In this life, I do not know the best or most preferred way to do

    > that.
    > >
    > > -Paul
    > >
    > > WRITE DC00-RECORD
    > > INVALID KEY
    > > CALL "SYS$ABORT_TRANSW" USING BY VALUE EFN
    > > BY VALUE 0
    > > BY REFERENCE IOSB
    > > BY VALUE 0
    > > BY VALUE 0
    > > BY REFERENCE TID
    > > DISPLAY '>>> DC00 WRITE FAILED WITH INVALID KEY'
    > > LINE 21 ERASE LINE
    > > ACCEPT WS-USER-CHOICE
    > > END-WRITE
    > > ----> I want to GOBACK here
    > >

    >




  4. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    On Sat, 01 Sep 2007 15:44:37 -0700, Paul Raulerson
    wrote:

    > I'm a little puzzled what the recommended method here is for this case
    > (see
    > sample code snippet below)... use a goto? Some System call? Embed
    > everything
    > in a deep nesting of Ifs?
    >
    >
    > In this sample, the code is being ran from a performed paragraph. There
    > are
    > three file writes necessary for this transaction to succeed, with this
    > being
    > one of the sequence. If this one fails, the transaction is aborted
    > (rolled
    > back I believe and the processing should return to the parent calling
    > process. In a previous life, I would have stuffed a GOBACK in there right
    > after the END-WRITE, or even just before the END-WRITE.
    >
    > In this life, I do not know the best or most preferred way to do that.
    >
    > -Paul
    >
    > WRITE DC00-RECORD
    > INVALID KEY
    > CALL "SYS$ABORT_TRANSW" USING BY VALUE EFN
    > BY VALUE 0
    > BY REFERENCE IOSB
    > BY VALUE 0
    > BY VALUE 0
    > BY REFERENCE TID
    > DISPLAY '>>> DC00 WRITE FAILED WITH INVALID KEY'
    > LINE 21 ERASE LINE
    > ACCEPT WS-USER-CHOICE
    > END-WRITE
    > ----> I want to GOBACK here
    >


    You could always write it in PL/I and use ON-conditions. Never understood
    why
    talented people waste their time using crappy languages.

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

  5. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    On Sep 1, 6:44 pm, "Paul Raulerson" wrote:
    > I'm a little puzzled what the recommended method here is for this case (see
    > sample code snippet below)... use a goto? Some System call? Embed everything
    > in a deep nesting of Ifs?


    How you write your code is up to you. Uppercase, lowercase, terminal
    format, ANSI format, structured, unstructured.

    I'm a firm believer in the single-point-of-entry, single-point-of-exit
    style of programming (among others). It might require more IFs than
    other methods, but it makes it easier (IMHO) to follow the code flow.

    My version of your sample problem would be something like this:

    DATA DIVISION.
    WORKING-STORAGE SECTION.
    77 TRX_RESULT PIC X(1).
    88 TRX_FAIL VALUE 'F'.
    88 TRX_SUCCESS VALUE 'S'.

    PROCEDURE DIVISION.
    MAIN-PROGRAM SECTION.
    WRITE-EM.
    SET TRX_SUCCESS TO TRUE.

    WRITE DC00-RECORD
    INVALID KEY
    PERFORM REPORT-TRX-FAIL
    END-WRITE.

    IF (TRX_SUCCESS)
    WRITE DC01-RECORD
    INVALID KEY
    PERFORM REPORT-TRX-FAIL
    END-WRITE
    END-IF.

    IF (TRX_SUCCESS)
    WRITE DC02-RECORD
    INVALID KEY
    PERFORM REPORT-TRX-FAIL
    END-WRITE
    END-IF.

    STOP RUN.

    REPORT-TRX-FAIL.
    SET TRX_FAIL TO TRUE.

    CALL "SYS$ABORT_TRANSW" ...

    CALL "SYS$PUTMSG" ...

    DISPLAY whatever.

    etcetera.


  6. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    On Sep 1, 9:03 pm, "Tom Linden" wrote:
    > You could always write it in PL/I and use ON-conditions. Never understood
    > why talented people waste their time using crappy languages.


    When I was in high school (a gazillion years ago it seems) I was among
    the snobs that looked down on the COBOL and RPG programmers. I wrote,
    back then, in BASIC, FORTRAN, and Assembler. In college I took every
    programming language elective available -- PL/I, Pascal, Snobol, LISP,
    C, and others. (I used PL/I for my class project in compiler design,
    if it makes you feel better Tom.) My first paying job while in
    college was using FORTRAN (under RSX-11). Then we got a project which
    was more suited to COBOL, and then another COBOL project after that
    (on a VAX 11/750).

    I can say from experience that every language has its good and bad
    points. Some languages are more suited to certain tasks than others.
    COBOL -- despite my deep teenage contempt towards it, and perhaps in a
    fitting twist of karma -- is really good at what it does, particularly
    in the "back-end" business applications that have paid me so nicely
    over the years. When COBOL becomes too bulky I write utility routines
    in BASIC or C, depending on which other licenses the client has
    available.

    Don't be such a PL/I snob, Tom. It's not the be-all-end-all
    programming language any more than Java, C, C++, or any other.


  7. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    On 09/01/07 21:20, FrankS wrote:
    [snip]
    >
    > Don't be such a PL/I snob, Tom. It's not the be-all-end-all
    > programming language any more than Java, C, C++, or any other.


    His company only(?) sells PL/I compilers. If he wasn't a PL/1 snob,
    I'd be surprised.

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

  8. RE: Recommended HP COBOL way to exit a paragraph or perform early?



    > -----Original Message-----
    > From: Tom Linden [mailto:tom@kednos.company]
    > Sent: Saturday, September 01, 2007 8:03 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Recommended HP COBOL way to exit a paragraph or perform
    > early?

    [snip]
    >
    > You could always write it in PL/I and use ON-conditions. Never
    > understood
    > why
    > talented people waste their time using crappy languages.
    >

    LOL! I don't have a PL/I compiler available for Alpha, though I do
    for Windows and I have your compiler available on a VAX hobby system.

    How would you write this for PL/I, and, all this good natured joshing
    aside, what do you think makes it better? Inquiring minds want to know...
    even if it is "topic drift" of a high order.

    Fair warning, I am a bit of a COBOL bigot, a C instructor, and somewhat
    enamored of Algol derived languages from my school and early career days.
    (Blame it on Wirth!) Ada for instance, is a beautiful language with every
    component being well designed, that blends the best of Pascal/Modula, C, and

    old style HOL's like CMS-2 ad Jovial all together.

    -Paul


  9. RE: Recommended HP COBOL way to exit a paragraph or perform early?



    > -----Original Message-----
    > From: FrankS [mailto:sapienza@noesys.com]
    > Sent: Saturday, September 01, 2007 8:47 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Recommended HP COBOL way to exit a paragraph or perform
    > early?
    >
    > On Sep 1, 6:44 pm, "Paul Raulerson" wrote:
    > > I'm a little puzzled what the recommended method here is for this

    > case (see
    > > sample code snippet below)... use a goto? Some System call? Embed

    > everything
    > > in a deep nesting of Ifs?

    >
    > How you write your code is up to you. Uppercase, lowercase, terminal
    > format, ANSI format, structured, unstructured.
    >
    > I'm a firm believer in the single-point-of-entry, single-point-of-exit
    > style of programming (among others). It might require more IFs than
    > other methods, but it makes it easier (IMHO) to follow the code flow.
    >


    This is quite a good way to solve the issue, and has many good points.
    The assembler programmer in me hates to do all the tests though, which
    is why I looked at the GO TO solution.

    I think they are both reasonable ways to solve the issue and both have
    strong good points.

    I still miss GOBACK though.

    -Paul


    > My version of your sample problem would be something like this:
    >
    > DATA DIVISION.
    > WORKING-STORAGE SECTION.
    > 77 TRX_RESULT PIC X(1).
    > 88 TRX_FAIL VALUE 'F'.
    > 88 TRX_SUCCESS VALUE 'S'.
    >
    > PROCEDURE DIVISION.
    > MAIN-PROGRAM SECTION.
    > WRITE-EM.
    > SET TRX_SUCCESS TO TRUE.
    >
    > WRITE DC00-RECORD
    > INVALID KEY
    > PERFORM REPORT-TRX-FAIL
    > END-WRITE.
    >
    > IF (TRX_SUCCESS)
    > WRITE DC01-RECORD
    > INVALID KEY
    > PERFORM REPORT-TRX-FAIL
    > END-WRITE
    > END-IF.
    >
    > IF (TRX_SUCCESS)
    > WRITE DC02-RECORD
    > INVALID KEY
    > PERFORM REPORT-TRX-FAIL
    > END-WRITE
    > END-IF.
    >
    > STOP RUN.
    >
    > REPORT-TRX-FAIL.
    > SET TRX_FAIL TO TRUE.
    >
    > CALL "SYS$ABORT_TRANSW" ...
    >
    > CALL "SYS$PUTMSG" ...
    >
    > DISPLAY whatever.
    >
    > etcetera.




  10. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    On Sat, 01 Sep 2007 19:20:15 -0700, FrankS wrote:

    > On Sep 1, 9:03 pm, "Tom Linden" wrote:
    >> You could always write it in PL/I and use ON-conditions. Never
    >> understood
    >> why talented people waste their time using crappy languages.

    >
    > When I was in high school (a gazillion years ago it seems) I was among
    > the snobs that looked down on the COBOL and RPG programmers. I wrote,
    > back then, in BASIC, FORTRAN, and Assembler. In college I took every
    > programming language elective available -- PL/I, Pascal, Snobol, LISP,
    > C, and others. (I used PL/I for my class project in compiler design,
    > if it makes you feel better Tom.) My first paying job while in
    > college was using FORTRAN (under RSX-11). Then we got a project which
    > was more suited to COBOL, and then another COBOL project after that
    > (on a VAX 11/750).
    >
    > I can say from experience that every language has its good and bad
    > points. Some languages are more suited to certain tasks than others.
    > COBOL -- despite my deep teenage contempt towards it, and perhaps in a
    > fitting twist of karma -- is really good at what it does, particularly
    > in the "back-end" business applications that have paid me so nicely
    > over the years. When COBOL becomes too bulky I write utility routines
    > in BASIC or C, depending on which other licenses the client has
    > available.
    >
    > Don't be such a PL/I snob, Tom. It's not the be-all-end-all
    > programming language any more than Java, C, C++, or any other.
    >

    I have coded in the languages you mention and some you didn't, and if I
    am going to write a piece of code, it is my experience that it is quicker
    in PL/I, is more error-free, more robust wrt error handling and
    easier/cheaper
    to maintain. Of course, a lot of this may be coding standards, but because
    the language has a higher level of abstraction, than say C, you don't have
    to
    write numerous utility routines (each of which needs testing) since it is
    likely
    semantically included in the language. In the late 80's Sun engaged me to
    write
    a multichannel IMS frontend multiplexor in C basing it on one written in
    PL/I and
    Cobol on a Stratus machine. I would say half the effort went into writing
    utilities,
    and you certainly don't feel very productive reinventing the wheel. Most
    of the
    extensions to Fortran and C are constructs that you will find in the PL/I
    standard.
    Gnu C long ago added, e.g., lexical scoping (i.e., permitting inheritance
    of
    declarations to contained procedures). As for Cobol, I can't think of
    anything that
    is better with it. Ditto for C, Ditto for Fortran. I think that this is
    generally
    true for algorithmic languages (didn't include Algol, Burroughs was the
    last hold-out)
    Lisp is certainly better for string handling. So am I a snob, yes.
    Experience
    allows one to be discriminatory.




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

  11. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    Hi All,

    If Hein and or John Regan are around could they just clear up exactly how
    COBOL and RMS conspire to know that the subsequent I/O is to be part of a
    distributed transaction?

    > > my_trans section.
    > > move "N" to abort_it.
    > > do write-1 invalid key go to fini.
    > > do write-2 invalid key go to fini.
    > > do rewrite-1 invalid key go to fini.
    > > fini.
    > > if rms-sts of current-file not = rms$_normal
    > > move "Y" to abort_it
    > > call "sys$putmsg" using rms-sts of . . . .


    I'm guessing that when you $set_file/ru then RMS knows that i/o to the file
    (must?) be part of a distributed transaction and if one is not explicitly
    declared via some XAB then the "default" transaction is used. Does this
    sound about right? Does COBOL have any syntax that let's you specify a TID
    that belongs to other than the default transaction? Can an RU enabled file
    not be excluded from a specific transaction?

    I suppose the thing I'm more interested in (and Paul may wish to explore) is
    the [I]solation part of ACID and how the presence of a 2PC must implicitly
    instruct RMS to effect a: -

    i-o-control.
    apply lock-holding on file_1, file_2, file_3.

    I mean what stops another process from seeing (and using) the results of
    "write-1" before the transaction is ultimately rollbacked? Does RMS not
    update the target record but only the RUJ and then commit them all in one
    foul swoop? (But then surely Invalid Key conditions may arise that
    previously did not exists in the first pass? Hidden updates?)

    Would all this be asking too much of the firmware and "it stands to reason"
    that you must explicitly lock all files in transactions with your own APPLY
    LOCK-HOLDING in which case Paul must be instructed to supply the various
    ALLOWING options on all his i/o statements and to subsequently includde the
    UNLOCKs.

    BTW. The lock timeout for COBOL is "just for show" as well :-( There is no
    way (short of messing with the FAB/RAB) to tell COBOL to wait for a record
    to be released rather than to return a failure status.

    Cheers Richard Maher

    "Paul Raulerson" wrote in message
    news:000001c7ecf1$8ef4f480$acdedd80$@com...
    >
    >
    > > -----Original Message-----
    > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > Sent: Saturday, September 01, 2007 6:16 PM
    > > To: Info-VAX@Mvb.Saic.Com
    > > Subject: Re: Recommended HP COBOL way to exit a paragraph or perform
    > > early?
    > >
    > > Hi Paul,
    > >
    > > I don't know what HP recommend but, to answer your specific question, I
    > > would have a label "fini" as the last thing in a section and "go to
    > > fini.".
    > >

    >
    > This is essentially the same thought I came up with, though I admit to

    being
    > a little
    > unhappy with it. If anyplace, error processing like this is the place for

    a
    > GO TO.
    >
    > > But then I would also check the statii returned from all system calls
    > > and

    >
    > I do, but I stripped it out to make the example smaller and clearer.
    >
    > > call "lib$stop" if they contain any value I wasn't prepared to handle.

    >
    > What the heck is lib$stop???
    >
    > > I
    > > also wouldn't attempt to do everything as part of the "invalid key"
    > > clause
    > > but rather perform a rollback section or paragraph. If you are not
    > > using
    > > sections but rather as you say a "performed paragraph" then yes I would
    > > use
    > > nested IFs.

    >
    > I tend to not use sections in executable code very often, but that is just
    > coding
    > style. I have some code I maintain that is - well - almost comical in how
    > they used
    > sections to excess. Ah well, one day they will pay me to rewrite it.
    >
    > IBM code is structured differently internally, so a GOBACK in the INVALID
    > KEY sequence
    > acts for all intents and purposes, like the GO TO FINI idea.
    >
    > >If it was a sub-program then some would use numerous "exit
    > > program"s but I don't. (Be aware that EXIT does nothing in DEC COBOL
    > > sections; don't know if that is the case with IBM COBOL)
    > >

    >
    > Yeah, its different. It was an eye opening discovery when I read that

    in
    > the manual
    > a few weeks ago.
    >
    > > Also the passing mechanism for COBOL is defaulted to that of the last
    > > parameter (or BY REFERENCE if it is the first) so
    > >
    > > > BY VALUE 0
    > > > BY VALUE 0
    > > > BY REFERENCE TID

    > >
    > > could also be represented as "by value 0, 0 by reference TID".
    > >
    > > Maybe something like: -
    > >
    > > perform my_trans.
    > > if abort_it = "n"
    > > perform commit_trans
    > > else
    > > perform abort_trans.
    > >
    > > stop run.
    > >
    > > my_trans section.
    > > move "N" to abort_it.
    > > do write-1 invalid key go to fini.
    > > do write-2 invalid key go to fini.
    > > do rewrite-1 invalid key go to fini.
    > > fini.
    > > if rms-sts of current-file not = rms$_normal
    > > move "Y" to abort_it
    > > call "sys$putmsg" using rms-sts of . . . .
    > >

    >
    > This is for all intents and purposes, the code I came out with too.
    > Except for the use of the rms specific stuff. Still studying on that.
    >
    >
    > > next_sect.
    > >
    > > Cheers Richard Maher
    > >
    > > PS. I also would NOT USE UPPERCASE :-)

    >
    > LOL! Well, it is a bit of a bad habit, but COBOL and ASSEMBLER
    > just look strange to me in lower case. I'm still adjusting to this
    > Terminal format, which I like. One step at a time.
    >
    > BTW: Converting code to terminal format does have a nasty little drawback;
    > it makes it quite incompatible with legacy code on the IBM. The REFORMAT
    > utility is not usable in this case, because it insists on putting the
    > sequence numbers in 1-6. Moving to terminal format was a big commitment

    to
    > me, even if the compile will handle ANSI format. The 2002 standard pretty
    > much
    > makes "terminal" format mandatory to support for all COBOL compilers

    though.
    >
    > -Paul
    >
    > >
    > > "Paul Raulerson" wrote in message
    > > news:001601c7ece9$ad796e20$086c4a60$@com...
    > > > I'm a little puzzled what the recommended method here is for this

    > > case
    > > (see
    > > > sample code snippet below)... use a goto? Some System call? Embed

    > > everything
    > > > in a deep nesting of Ifs?
    > > >
    > > >
    > > > In this sample, the code is being ran from a performed paragraph.

    > > There
    > > are
    > > > three file writes necessary for this transaction to succeed, with

    > > this
    > > being
    > > > one of the sequence. If this one fails, the transaction is aborted

    > > (rolled
    > > > back I believe and the processing should return to the parent

    > > calling
    > > > process. In a previous life, I would have stuffed a GOBACK in there

    > > right
    > > > after the END-WRITE, or even just before the END-WRITE.
    > > >
    > > > In this life, I do not know the best or most preferred way to do

    > > that.
    > > >
    > > > -Paul
    > > >
    > > > WRITE DC00-RECORD
    > > > INVALID KEY
    > > > CALL "SYS$ABORT_TRANSW" USING BY VALUE EFN
    > > > BY VALUE 0
    > > > BY REFERENCE IOSB
    > > > BY VALUE 0
    > > > BY VALUE 0
    > > > BY REFERENCE TID
    > > > DISPLAY '>>> DC00 WRITE FAILED WITH INVALID KEY'
    > > > LINE 21 ERASE LINE
    > > > ACCEPT WS-USER-CHOICE
    > > > END-WRITE
    > > > ----> I want to GOBACK here
    > > >

    > >

    >
    >




  12. RE: Recommended HP COBOL way to exit a paragraph or perform early?



    > -----Original Message-----
    > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > Sent: Sunday, September 02, 2007 6:02 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Recommended HP COBOL way to exit a paragraph or perform
    > early?
    >
    > Hi All,
    >
    > If Hein and or John Regan are around could they just clear up exactly
    > how
    > COBOL and RMS conspire to know that the subsequent I/O is to be part of
    > a
    > distributed transaction?
    >
    > > > my_trans section.
    > > > move "N" to abort_it.
    > > > do write-1 invalid key go to fini.
    > > > do write-2 invalid key go to fini.
    > > > do rewrite-1 invalid key go to fini.
    > > > fini.
    > > > if rms-sts of current-file not = rms$_normal
    > > > move "Y" to abort_it
    > > > call "sys$putmsg" using rms-sts of . . . .

    >
    > I'm guessing that when you $set_file/ru then RMS knows that i/o to the
    > file
    > (must?) be part of a distributed transaction and if one is not
    > explicitly
    > declared via some XAB then the "default" transaction is used. Does this
    > sound about right? Does COBOL have any syntax that let's you specify a
    > TID
    > that belongs to other than the default transaction? Can an RU enabled
    > file
    > not be excluded from a specific transaction?
    >
    > I suppose the thing I'm more interested in (and Paul may wish to
    > explore) is
    > the [I]solation part of ACID and how the presence of a 2PC must
    > implicitly
    > instruct RMS to effect a: -
    >
    > i-o-control.
    > apply lock-holding on file_1, file_2, file_3.
    >

    Right now I am using a lock mode is manual with lock on multiple records

    and doing a read with lock for rewrites. I did have a with lock is automatic
    on there, but naturally ran into sharing conflicts with open records.

    I'm actually trying to devise some tests to ensure that transaction
    processing
    is working the way I *think* it is working. I believe it is.

    > I mean what stops another process from seeing (and using) the results
    > of
    > "write-1" before the transaction is ultimately rollbacked? Does RMS not
    > update the target record but only the RUJ and then commit them all in
    > one
    > foul swoop? (But then surely Invalid Key conditions may arise that
    > previously did not exists in the first pass? Hidden updates?)
    >
    > Would all this be asking too much of the firmware and "it stands to
    > reason"
    > that you must explicitly lock all files in transactions with your own
    > APPLY
    > LOCK-HOLDING in which case Paul must be instructed to supply the
    > various
    > ALLOWING options on all his i/o statements and to subsequently includde
    > the
    > UNLOCKs.


    This may turn out to be the case, but it doesn't seem to be at this point. A
    write to file one
    gets rolled back if I abort on file two.



    >
    > BTW. The lock timeout for COBOL is "just for show" as well :-( There is
    > no
    > way (short of messing with the FAB/RAB) to tell COBOL to wait for a
    > record
    > to be released rather than to return a failure status.
    >
    > Cheers Richard Maher
    >
    > "Paul Raulerson" wrote in message
    > news:000001c7ecf1$8ef4f480$acdedd80$@com...
    > >
    > >
    > > > -----Original Message-----
    > > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > > Sent: Saturday, September 01, 2007 6:16 PM
    > > > To: Info-VAX@Mvb.Saic.Com
    > > > Subject: Re: Recommended HP COBOL way to exit a paragraph or

    > perform
    > > > early?
    > > >
    > > > Hi Paul,
    > > >
    > > > I don't know what HP recommend but, to answer your specific

    > question, I
    > > > would have a label "fini" as the last thing in a section and "go to
    > > > fini.".
    > > >

    > >
    > > This is essentially the same thought I came up with, though I admit

    > to
    > being
    > > a little
    > > unhappy with it. If anyplace, error processing like this is the place

    > for
    > a
    > > GO TO.
    > >
    > > > But then I would also check the statii returned from all system

    > calls
    > > > and

    > >
    > > I do, but I stripped it out to make the example smaller and clearer.
    > >
    > > > call "lib$stop" if they contain any value I wasn't prepared to

    > handle.
    > >
    > > What the heck is lib$stop???
    > >
    > > > I
    > > > also wouldn't attempt to do everything as part of the "invalid key"
    > > > clause
    > > > but rather perform a rollback section or paragraph. If you are not
    > > > using
    > > > sections but rather as you say a "performed paragraph" then yes I

    > would
    > > > use
    > > > nested IFs.

    > >
    > > I tend to not use sections in executable code very often, but that is

    > just
    > > coding
    > > style. I have some code I maintain that is - well - almost comical in

    > how
    > > they used
    > > sections to excess. Ah well, one day they will pay me to rewrite it.

    >
    > >
    > > IBM code is structured differently internally, so a GOBACK in the

    > INVALID
    > > KEY sequence
    > > acts for all intents and purposes, like the GO TO FINI idea.
    > >
    > > >If it was a sub-program then some would use numerous "exit
    > > > program"s but I don't. (Be aware that EXIT does nothing in DEC

    > COBOL
    > > > sections; don't know if that is the case with IBM COBOL)
    > > >

    > >
    > > Yeah, its different. It was an eye opening discovery when I read

    > that
    > in
    > > the manual
    > > a few weeks ago.
    > >
    > > > Also the passing mechanism for COBOL is defaulted to that of the

    > last
    > > > parameter (or BY REFERENCE if it is the first) so
    > > >
    > > > > BY VALUE 0
    > > > > BY VALUE 0
    > > > > BY REFERENCE TID
    > > >
    > > > could also be represented as "by value 0, 0 by reference TID".
    > > >
    > > > Maybe something like: -
    > > >
    > > > perform my_trans.
    > > > if abort_it = "n"
    > > > perform commit_trans
    > > > else
    > > > perform abort_trans.
    > > >
    > > > stop run.
    > > >
    > > > my_trans section.
    > > > move "N" to abort_it.
    > > > do write-1 invalid key go to fini.
    > > > do write-2 invalid key go to fini.
    > > > do rewrite-1 invalid key go to fini.
    > > > fini.
    > > > if rms-sts of current-file not = rms$_normal
    > > > move "Y" to abort_it
    > > > call "sys$putmsg" using rms-sts of . . . .
    > > >

    > >
    > > This is for all intents and purposes, the code I came out with too.
    > > Except for the use of the rms specific stuff. Still studying on that.

    >
    > >
    > >
    > > > next_sect.
    > > >
    > > > Cheers Richard Maher
    > > >
    > > > PS. I also would NOT USE UPPERCASE :-)

    > >
    > > LOL! Well, it is a bit of a bad habit, but COBOL and ASSEMBLER
    > > just look strange to me in lower case. I'm still adjusting to this
    > > Terminal format, which I like. One step at a time.
    > >
    > > BTW: Converting code to terminal format does have a nasty little

    > drawback;
    > > it makes it quite incompatible with legacy code on the IBM. The

    > REFORMAT
    > > utility is not usable in this case, because it insists on putting the
    > > sequence numbers in 1-6. Moving to terminal format was a big

    > commitment
    > to
    > > me, even if the compile will handle ANSI format. The 2002 standard

    > pretty
    > > much
    > > makes "terminal" format mandatory to support for all COBOL compilers

    > though.
    > >
    > > -Paul
    > >
    > > >
    > > > "Paul Raulerson" wrote in message
    > > > news:001601c7ece9$ad796e20$086c4a60$@com...
    > > > > I'm a little puzzled what the recommended method here is for this
    > > > case
    > > > (see
    > > > > sample code snippet below)... use a goto? Some System call? Embed
    > > > everything
    > > > > in a deep nesting of Ifs?
    > > > >
    > > > >
    > > > > In this sample, the code is being ran from a performed paragraph.
    > > > There
    > > > are
    > > > > three file writes necessary for this transaction to succeed, with
    > > > this
    > > > being
    > > > > one of the sequence. If this one fails, the transaction is

    > aborted
    > > > (rolled
    > > > > back I believe and the processing should return to the parent
    > > > calling
    > > > > process. In a previous life, I would have stuffed a GOBACK in

    > there
    > > > right
    > > > > after the END-WRITE, or even just before the END-WRITE.
    > > > >
    > > > > In this life, I do not know the best or most preferred way to do
    > > > that.
    > > > >
    > > > > -Paul
    > > > >
    > > > > WRITE DC00-RECORD
    > > > > INVALID KEY
    > > > > CALL "SYS$ABORT_TRANSW" USING BY VALUE EFN
    > > > > BY VALUE 0
    > > > > BY REFERENCE IOSB
    > > > > BY VALUE 0
    > > > > BY VALUE 0
    > > > > BY REFERENCE TID
    > > > > DISPLAY '>>> DC00 WRITE FAILED WITH INVALID KEY'
    > > > > LINE 21 ERASE LINE
    > > > > ACCEPT WS-USER-CHOICE
    > > > > END-WRITE
    > > > > ----> I want to GOBACK here
    > > > >
    > > >

    > >
    > >

    >




  13. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    Hi Paul,

    > This may turn out to be the case, but it doesn't seem to be at this point.

    A
    > write to file one
    > gets rolled back if I abort on file two.


    No, I wasn't questioning the Atomicity of your updates just the Isolation
    (well maybe the Durability as well). You look to be doing manual locking and
    unlocking already so it's probably not going to be an issue, but I didn't
    think RMS was as smart as a full-blown DBMS, such as Rdb, was when it came
    to Isolation Levels for a transaction, and the problem is that I believe
    that it has to be to get the job done.

    For example, (if you were not using manual locking) if you updated
    stock-on-hand in a record in file_1 from 20 to 18 and then went on to do
    other work/updates but before you committed your transaction, another
    process subtracted 5 from the same stock-on-hand and committed its txn, then
    you ROLLBACKed *your* txn, what's the stock-on-hand say?

    Does RMS Journalling come with a Monitor (a la mode de Rdb) to "freeze"
    access to the interesting records when your process dies? Does it then fire
    up a recovery process on another node in the cluster if your node died?

    Cheers Richard Maher

    "Paul Raulerson" wrote in message
    news:002d01c7edc5$cf3844a0$6da8cde0$@com...
    >
    >
    > > -----Original Message-----
    > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > Sent: Sunday, September 02, 2007 6:02 PM
    > > To: Info-VAX@Mvb.Saic.Com
    > > Subject: Re: Recommended HP COBOL way to exit a paragraph or perform
    > > early?
    > >
    > > Hi All,
    > >
    > > If Hein and or John Regan are around could they just clear up exactly
    > > how
    > > COBOL and RMS conspire to know that the subsequent I/O is to be part of
    > > a
    > > distributed transaction?
    > >
    > > > > my_trans section.
    > > > > move "N" to abort_it.
    > > > > do write-1 invalid key go to fini.
    > > > > do write-2 invalid key go to fini.
    > > > > do rewrite-1 invalid key go to fini.
    > > > > fini.
    > > > > if rms-sts of current-file not = rms$_normal
    > > > > move "Y" to abort_it
    > > > > call "sys$putmsg" using rms-sts of . . . .

    > >
    > > I'm guessing that when you $set_file/ru then RMS knows that i/o to the
    > > file
    > > (must?) be part of a distributed transaction and if one is not
    > > explicitly
    > > declared via some XAB then the "default" transaction is used. Does this
    > > sound about right? Does COBOL have any syntax that let's you specify a
    > > TID
    > > that belongs to other than the default transaction? Can an RU enabled
    > > file
    > > not be excluded from a specific transaction?
    > >
    > > I suppose the thing I'm more interested in (and Paul may wish to
    > > explore) is
    > > the [I]solation part of ACID and how the presence of a 2PC must
    > > implicitly
    > > instruct RMS to effect a: -
    > >
    > > i-o-control.
    > > apply lock-holding on file_1, file_2, file_3.
    > >

    > Right now I am using a lock mode is manual with lock on multiple

    records
    >
    > and doing a read with lock for rewrites. I did have a with lock is

    automatic
    > on there, but naturally ran into sharing conflicts with open records.
    >
    > I'm actually trying to devise some tests to ensure that transaction
    > processing
    > is working the way I *think* it is working. I believe it is.
    >
    > > I mean what stops another process from seeing (and using) the results
    > > of
    > > "write-1" before the transaction is ultimately rollbacked? Does RMS not
    > > update the target record but only the RUJ and then commit them all in
    > > one
    > > foul swoop? (But then surely Invalid Key conditions may arise that
    > > previously did not exists in the first pass? Hidden updates?)
    > >
    > > Would all this be asking too much of the firmware and "it stands to
    > > reason"
    > > that you must explicitly lock all files in transactions with your own
    > > APPLY
    > > LOCK-HOLDING in which case Paul must be instructed to supply the
    > > various
    > > ALLOWING options on all his i/o statements and to subsequently includde
    > > the
    > > UNLOCKs.

    >
    > This may turn out to be the case, but it doesn't seem to be at this point.

    A
    > write to file one
    > gets rolled back if I abort on file two.
    >
    >
    >
    > >
    > > BTW. The lock timeout for COBOL is "just for show" as well :-( There is
    > > no
    > > way (short of messing with the FAB/RAB) to tell COBOL to wait for a
    > > record
    > > to be released rather than to return a failure status.
    > >
    > > Cheers Richard Maher
    > >
    > > "Paul Raulerson" wrote in message
    > > news:000001c7ecf1$8ef4f480$acdedd80$@com...
    > > >
    > > >
    > > > > -----Original Message-----
    > > > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > > > Sent: Saturday, September 01, 2007 6:16 PM
    > > > > To: Info-VAX@Mvb.Saic.Com
    > > > > Subject: Re: Recommended HP COBOL way to exit a paragraph or

    > > perform
    > > > > early?
    > > > >
    > > > > Hi Paul,
    > > > >
    > > > > I don't know what HP recommend but, to answer your specific

    > > question, I
    > > > > would have a label "fini" as the last thing in a section and "go to
    > > > > fini.".
    > > > >
    > > >
    > > > This is essentially the same thought I came up with, though I admit

    > > to
    > > being
    > > > a little
    > > > unhappy with it. If anyplace, error processing like this is the place

    > > for
    > > a
    > > > GO TO.
    > > >
    > > > > But then I would also check the statii returned from all system

    > > calls
    > > > > and
    > > >
    > > > I do, but I stripped it out to make the example smaller and clearer.
    > > >
    > > > > call "lib$stop" if they contain any value I wasn't prepared to

    > > handle.
    > > >
    > > > What the heck is lib$stop???
    > > >
    > > > > I
    > > > > also wouldn't attempt to do everything as part of the "invalid key"
    > > > > clause
    > > > > but rather perform a rollback section or paragraph. If you are not
    > > > > using
    > > > > sections but rather as you say a "performed paragraph" then yes I

    > > would
    > > > > use
    > > > > nested IFs.
    > > >
    > > > I tend to not use sections in executable code very often, but that is

    > > just
    > > > coding
    > > > style. I have some code I maintain that is - well - almost comical in

    > > how
    > > > they used
    > > > sections to excess. Ah well, one day they will pay me to rewrite it.

    > >
    > > >
    > > > IBM code is structured differently internally, so a GOBACK in the

    > > INVALID
    > > > KEY sequence
    > > > acts for all intents and purposes, like the GO TO FINI idea.
    > > >
    > > > >If it was a sub-program then some would use numerous "exit
    > > > > program"s but I don't. (Be aware that EXIT does nothing in DEC

    > > COBOL
    > > > > sections; don't know if that is the case with IBM COBOL)
    > > > >
    > > >
    > > > Yeah, its different. It was an eye opening discovery when I read

    > > that
    > > in
    > > > the manual
    > > > a few weeks ago.
    > > >
    > > > > Also the passing mechanism for COBOL is defaulted to that of the

    > > last
    > > > > parameter (or BY REFERENCE if it is the first) so
    > > > >
    > > > > > BY VALUE 0
    > > > > > BY VALUE 0
    > > > > > BY REFERENCE TID
    > > > >
    > > > > could also be represented as "by value 0, 0 by reference TID".
    > > > >
    > > > > Maybe something like: -
    > > > >
    > > > > perform my_trans.
    > > > > if abort_it = "n"
    > > > > perform commit_trans
    > > > > else
    > > > > perform abort_trans.
    > > > >
    > > > > stop run.
    > > > >
    > > > > my_trans section.
    > > > > move "N" to abort_it.
    > > > > do write-1 invalid key go to fini.
    > > > > do write-2 invalid key go to fini.
    > > > > do rewrite-1 invalid key go to fini.
    > > > > fini.
    > > > > if rms-sts of current-file not = rms$_normal
    > > > > move "Y" to abort_it
    > > > > call "sys$putmsg" using rms-sts of . . . .
    > > > >
    > > >
    > > > This is for all intents and purposes, the code I came out with too.
    > > > Except for the use of the rms specific stuff. Still studying on that.

    > >
    > > >
    > > >
    > > > > next_sect.
    > > > >
    > > > > Cheers Richard Maher
    > > > >
    > > > > PS. I also would NOT USE UPPERCASE :-)
    > > >
    > > > LOL! Well, it is a bit of a bad habit, but COBOL and ASSEMBLER
    > > > just look strange to me in lower case. I'm still adjusting to this
    > > > Terminal format, which I like. One step at a time.
    > > >
    > > > BTW: Converting code to terminal format does have a nasty little

    > > drawback;
    > > > it makes it quite incompatible with legacy code on the IBM. The

    > > REFORMAT
    > > > utility is not usable in this case, because it insists on putting the
    > > > sequence numbers in 1-6. Moving to terminal format was a big

    > > commitment
    > > to
    > > > me, even if the compile will handle ANSI format. The 2002 standard

    > > pretty
    > > > much
    > > > makes "terminal" format mandatory to support for all COBOL compilers

    > > though.
    > > >
    > > > -Paul
    > > >
    > > > >
    > > > > "Paul Raulerson" wrote in message
    > > > > news:001601c7ece9$ad796e20$086c4a60$@com...
    > > > > > I'm a little puzzled what the recommended method here is for this
    > > > > case
    > > > > (see
    > > > > > sample code snippet below)... use a goto? Some System call? Embed
    > > > > everything
    > > > > > in a deep nesting of Ifs?
    > > > > >
    > > > > >
    > > > > > In this sample, the code is being ran from a performed paragraph.
    > > > > There
    > > > > are
    > > > > > three file writes necessary for this transaction to succeed, with
    > > > > this
    > > > > being
    > > > > > one of the sequence. If this one fails, the transaction is

    > > aborted
    > > > > (rolled
    > > > > > back I believe and the processing should return to the parent
    > > > > calling
    > > > > > process. In a previous life, I would have stuffed a GOBACK in

    > > there
    > > > > right
    > > > > > after the END-WRITE, or even just before the END-WRITE.
    > > > > >
    > > > > > In this life, I do not know the best or most preferred way to do
    > > > > that.
    > > > > >
    > > > > > -Paul
    > > > > >
    > > > > > WRITE DC00-RECORD
    > > > > > INVALID KEY
    > > > > > CALL "SYS$ABORT_TRANSW" USING BY VALUE EFN
    > > > > > BY VALUE 0
    > > > > > BY REFERENCE IOSB
    > > > > > BY VALUE 0
    > > > > > BY VALUE 0
    > > > > > BY REFERENCE TID
    > > > > > DISPLAY '>>> DC00 WRITE FAILED WITH INVALID KEY'
    > > > > > LINE 21 ERASE LINE
    > > > > > ACCEPT WS-USER-CHOICE
    > > > > > END-WRITE
    > > > > > ----> I want to GOBACK here
    > > > > >
    > > > >
    > > >
    > > >

    > >

    >
    >




  14. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    On Sep 3, 6:57 pm, "Richard Maher"
    wrote:
    > Hi Paul,



    > For example, (if you were not using manual locking) if you updated
    > stock-on-hand in a record in file_1 from 20 to 18 and then went on to do
    > other work/updates but before you committed your transaction, another
    > process subtracted 5 from the same stock-on-hand and committed its txn, then


    It couldn't. RMS journalling simply keeps all records touched until
    commit or rollback. Safe but expensive. Much like manual locking.


    > you ROLLBACKed *your* txn, what's the stock-on-hand say?


    20

    > Does it then fire up a recovery process on another node in the cluster if your node died?


    Yes, On finding an ACE on the file on subsequent file access.

    Hein.


  15. RE: Recommended HP COBOL way to exit a paragraph or perform early?

    In article <000001c7ecf1$8ef4f480$acdedd80$@com>, "Paul Raulerson" writes:
    >
    >
    >> -----Original Message-----
    >> From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]

    [...]
    >> call "lib$stop" if they contain any value I wasn't prepared to handle.

    >
    > What the heck is lib$stop???


    I don't see that anyone else has answered this yet.

    You can get a brief answer from $ HELP RTL LIB$ LIB$STOP

    LIB$STOP is a VMS run time library call (or was under the VAX
    architecture -- I believe it is a language-supplied pseudo-call
    under Alpha and Itanium). It is fairly similar to LIB$SIGNAL and
    raises an exception that will be passed to any enabled exception
    handlers.

    With LIB$SIGNAL, exception handlers have the ability to handle the
    exception and allow normal execution to resume or to handle the
    exception, unwind the call stack and allow execution to resume at
    some higher level. Either way, execution resumes and exception
    handlers farther up the call stack are not invoked.

    With LIB$STOP, exception handlers lose the ability to resume
    normal execution. Any attempt to resume or unwind will be ignored,
    the signal will remain active and all higher level handlers will
    be invoked in turn. Image exit is ultimately assured (*)

    From a naive programmer's point of view, the key features of LIB$STOP are

    1. It aborts the running image
    2. It generates a traceback stack dump on SYS$OUTPUT and,
    if different, SYS$ERROR

    If you're trying to debug code that has encountered an unanticipated
    error condition, that stack dump can be invaluable. So some programmers
    will routinely use LIB$STOP when they write code to deal with such
    situations.


    (*) A sufficiently clever programmer can still use a condition
    handler, an exit handler or a user rundown handler to avoid image
    exit. And, of course, any fool can create an infinite loop in a
    handler by accident.

  16. Re: Recommended HP COBOL way to exit a paragraph or perform early?

    On Sun, 02 Sep 2007 06:35:07 -0700, Paul Raulerson
    wrote:

    > How would you write this for PL/I, and, all this good natured joshing
    > aside, what do you think makes it better? Inquiring minds want to know...
    > even if it is "topic drift" of a high order.


    I have forgotten what the original problem was and is long since deleted.
    Signal
    handling is an integral part of the language at the semantic level of the
    language
    allowing you, e.g. create custom signal handling without having to make
    library calls
    as required in other languages. CONDITION is a data type in PL/I
    http://www.kednos.com/pli/docs/REFER...1.html#data_81
    and there are a number ways to handle conditions
    http://www.kednos.com/pli/docs/REFER...3.html#prog_31

    Condition handlers inherit declaration from their containing scopes and
    have their
    own stack frame, but know they from where they were called so upon
    processing the
    condition, if correcdtable, execution may continue from which the conditon
    occurred,
    was signalled or resignalled.

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

  17. Re: Hein has left the building?

    On Sep 6, 10:27 am, "Richard Maher"
    wrote:
    > Hi,
    >
    > Soooo? Does the user on another node get ss$_lvbnotvalid and look to
    > rollback the other guys transaction?


    'The right things will happen'... we hope.

    It's been 15 years since I left OpenVMS (RMS) Engineering and I we had
    an other person focussing on Journalling (Tom S). Too much work to dig
    into all that without proper cause ( $$$ ).

    > Does the user on another node get ss$_lvbnotvalid


    No.

    >> What I can't see happening is

    RMS preventing other processes on other nodes (who had previously
    opened the
    file before the dodgy node died) from seeing the "partial" updates of
    the
    now dead process and *incorrectly* acting on their contents.

    If buckets with update records are writtine out, then those records
    are marked in the flag byte with RU_UPDATED/RU_DELETED. A new reader
    who managed to get to the record without a lock will trigger recovery
    as need be. Local/Remote matters not.

    >> Is it all crap and Hein did a runner ...


    And your score today is...
    Social skills... 0, Humor... Low, Annoyance... High, Technique...
    Somehwat intesting.
    .... much like other days.


    > PS. RIP big guy. La Scala was for you and VMS engineering; the only
    > difference is that you knew how to finish a performance!


    71. Not that old. I put on an album of his today.
    I picked one with popular tunes: 'Mamma' (Vivere, Non ti scordar di
    me,..)

    >
    > PPS. So you know all this then Paul, do you?


    No need. Mushroom theory... keep 'm in the dark, feed then **** and
    good things come out!

    >> Or even Serializable, where if I've previously touched index

    nodes for (all records where key(2) Surname starting with "SM") does
    RMS
    lock out all other processes/streams from inserting/writing another
    "SMITH"?

    RMS does not do 'index' nodes.
    If there was no SMITH when a process in an RU read SMART, but SMITH
    did get inserted (commited) before the process issued a read next then
    it will not get SMUG, but best I know it will find Smith even though
    that did not exist before the transaction started. Try it?!

    Hein.



  18. Re: Hein has left the building?

    Hi Hein,

    Thanks for the reply.

    > It's been 15 years since I left OpenVMS (RMS) Engineering and I we had
    > an other person focussing on Journalling (Tom S). Too much work to dig
    > into all that without proper cause ( $$$ ).


    Fair enough. (Wow, 15 years already!)

    > If buckets with update records are writtine out, then those records
    > are marked in the flag byte with RU_UPDATED/RU_DELETED. A new reader
    > who managed to get to the record without a lock will trigger recovery
    > as need be. Local/Remote matters not.


    Cool! I imagine that flag was being checked on every read already anyway so
    there's no additional o/head? (I'm still confused about what if ownership of
    the dead processes locks get split between numerous new processes. The first
    does the rollback, the others give up there newly aquired locks and wait for
    the rollback lock? Anyway 'The right things will happen' I'm convinced.)

    > And your score today is...
    > Social skills... 0, Humor... Low, Annoyance... High, Technique...
    > Somehwat intesting.
    > ... much like other days.


    Sure beats the usual religious bigotry, global warming, and scintillating
    political repartee? Oh well, maybe not. Hey, at least I'm consistent.

    > Try it?!


    I was only curious. I thinks it's amazing that a flat file system can do all
    this (and that it's bundled with Itanium?) But if this stuff is really
    important to people then I still think they should go the full-blown DBMS
    route.

    Cheers Richard Maher

    "Hein RMS van den Heuvel" wrote in message
    news:1189110463.079198.294630@g4g2000hsf.googlegro ups.com...
    > On Sep 6, 10:27 am, "Richard Maher"
    > wrote:
    > > Hi,
    > >
    > > Soooo? Does the user on another node get ss$_lvbnotvalid and look to
    > > rollback the other guys transaction?

    >
    > 'The right things will happen'... we hope.
    >
    > It's been 15 years since I left OpenVMS (RMS) Engineering and I we had
    > an other person focussing on Journalling (Tom S). Too much work to dig
    > into all that without proper cause ( $$$ ).
    >
    > > Does the user on another node get ss$_lvbnotvalid

    >
    > No.
    >
    > >> What I can't see happening is

    > RMS preventing other processes on other nodes (who had previously
    > opened the
    > file before the dodgy node died) from seeing the "partial" updates of
    > the
    > now dead process and *incorrectly* acting on their contents.
    >
    > If buckets with update records are writtine out, then those records
    > are marked in the flag byte with RU_UPDATED/RU_DELETED. A new reader
    > who managed to get to the record without a lock will trigger recovery
    > as need be. Local/Remote matters not.
    >
    > >> Is it all crap and Hein did a runner ...

    >
    > And your score today is...
    > Social skills... 0, Humor... Low, Annoyance... High, Technique...
    > Somehwat intesting.
    > ... much like other days.
    >
    >
    > > PS. RIP big guy. La Scala was for you and VMS engineering; the only
    > > difference is that you knew how to finish a performance!

    >
    > 71. Not that old. I put on an album of his today.
    > I picked one with popular tunes: 'Mamma' (Vivere, Non ti scordar di
    > me,..)
    >
    > >
    > > PPS. So you know all this then Paul, do you?

    >
    > No need. Mushroom theory... keep 'm in the dark, feed then **** and
    > good things come out!
    >
    > >> Or even Serializable, where if I've previously touched index

    > nodes for (all records where key(2) Surname starting with "SM") does
    > RMS
    > lock out all other processes/streams from inserting/writing another
    > "SMITH"?
    >
    > RMS does not do 'index' nodes.
    > If there was no SMITH when a process in an RU read SMART, but SMITH
    > did get inserted (commited) before the process issued a read next then
    > it will not get SMUG, but best I know it will find Smith even though
    > that did not exist before the transaction started. Try it?!
    >
    > Hein.
    >
    >




+ Reply to Thread