Help needed with / confused by AST routine (VAX,COBOL) - VMS

This is a discussion on Help needed with / confused by AST routine (VAX,COBOL) - VMS ; This is on VAX/VMS 7.3, COBOL 5.7-63 I need to extend some program's functionality and came up with an idea to let an AST routine do periodic reporting. I was brutally ACCVIO'd by the program, and made a small reproducer. ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: Help needed with / confused by AST routine (VAX,COBOL)

  1. Help needed with / confused by AST routine (VAX,COBOL)

    This is on VAX/VMS 7.3, COBOL 5.7-63

    I need to extend some program's functionality and came up with an idea
    to let an AST routine do periodic reporting. I was brutally ACCVIO'd by
    the program, and made a small reproducer. I'm sure I don't understand
    all about AST programming (it's relatively new to me), but why it would
    fail in exactly this manner baffles me.

    The real program will have a network listener instead of a
    DISPLAY/ACCEPT loop, but you'll get the general idea. Also, the MIS area
    will have really useful data, trust me.

    The reproducer ACCVIO's in the compute statement marked with two
    asterisks (**) below.
    Two questions:
    - can you reproduce the error?
    - if yes, can you tell me why it ACCVIOs, and how to avoid it?

    TIA,
    Wilm
    *-------------------------------------------- cut here -----------
    identification division.
    program-id. TESTIMR initial.

    data division.
    working-storage section.
    01 SS$_NORMAL pic S9(9) comp value external SS$_NORMAL.
    01 ASTSERV pic S9(9) comp value external ASTSERV.
    01 SYSTAT pic S9(9) comp.

    01 TELLER pic 9.

    01 MIS external.
    02 SOM pic 9(6) occurs 10 times.

    procedure division.
    TEST-TIMER section.
    00.
    move zeroes to TELLER, SOM(8).

    * fire the AST routine once:
    call "SYS$DCLAST" using
    by value ASTSERV,
    omitted, omitted
    giving SYSTAT
    if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    using by value SYSTAT.

    * schedule the AST routine after defined interval:
    call "ASTFIRE".
    01.
    display "Getal: " with no advancing
    accept TELLER
    if TELLER = zero then go to 02.

    * suspend AST delivery while adding:
    call "SYS$SETAST" using
    by value 0
    giving SYSTAT
    if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    using by value SYSTAT.

    compute SOM(8) = SOM(8) + TELLER. (**)

    * resume AST delivery:
    call "SYS$SETAST" using
    by value 1
    giving SYSTAT
    if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    using by value SYSTAT.

    go to 01.
    02.
    exit program.
    end program TESTIMR.
    /
    identification division.
    program-id. ASTFIRE.

    data division.
    working-storage section.
    01 AMINUTE pic X(13) value "0 00:00:10.00".
    01 BMINUTE pic S9(11) comp.
    01 SYSTAT pic S9(9) comp.

    01 SS$_NORMAL pic S9(9) comp value external SS$_NORMAL.
    01 ASTSERV pic S9(9) comp value external ASTSERV.

    procedure division.
    AST-FIRE section.
    00.
    call "SYS$BINTIM" using
    by descriptor AMINUTE,
    by reference BMINUTE
    giving SYSTAT
    if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    using by value SYSTAT.

    call "SYS$SETIMR" using
    omitted,
    by reference BMINUTE,
    by value ASTSERV,
    omitted, omitted
    giving SYSTAT
    if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    using by value SYSTAT.

    end program ASTFIRE.
    /
    identification division.
    program-id. ASTSERV.

    data division.
    working-storage section.

    01 MIS external.
    02 SOM pic 9(6) occurs 10 times.

    procedure division.
    AST-SERV section.
    00.
    display "Som = ", SOM(8)
    move zeroes to SOM(8).

    * reschedule AST
    call "ASTFIRE".

    end program ASTSERV.

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  2. Re: Help needed with / confused by AST routine (VAX,COBOL)

    Wilm Boerhout wrote:
    > This is on VAX/VMS 7.3, COBOL 5.7-63
    >
    > I need to extend some program's functionality and came up with an idea
    > to let an AST routine do periodic reporting. I was brutally ACCVIO'd by
    > the program, and made a small reproducer. I'm sure I don't understand
    > all about AST programming (it's relatively new to me), but why it would
    > fail in exactly this manner baffles me.
    >
    > The real program will have a network listener instead of a
    > DISPLAY/ACCEPT loop, but you'll get the general idea. Also, the MIS area
    > will have really useful data, trust me.
    >
    > The reproducer ACCVIO's in the compute statement marked with two
    > asterisks (**) below.
    > Two questions:
    > - can you reproduce the error?
    > - if yes, can you tell me why it ACCVIOs, and how to avoid it?
    >
    > TIA,
    > Wilm

    [COBOL program text snipped]

    I am not familiar with the VAX COBOL run-time library, but I had a
    similar experience with the VAX BASIC run-time library. I found that
    doing I/O in an AST routine would cause an ACCVIO. Fortunately, I was
    developing the VAX BASIC run-time library at the time, so I was able to
    fix the problems.

    I speculate that the VAX COBOL run-time library is not AST-reentrant.

    That said, however, I don't see how your program is getting an access
    violation on the compute statement. Perhaps the reporting of the access
    violation is mangled, and the error was actually happening somewhere
    else, such as in the display statement being executed as AST level, and
    not reported until the compute statement executed. Can you provide more
    information about the error message? Does the problem still happen when
    you run the program under the debugger? If so, can you pinpoint the
    failing VAX instruction?
    John Sauter (John_Sauter@systemeyescomputerstore.com)

  3. Re: Help needed with / confused by AST routine (VAX,COBOL)

    Wilm,

    Main problems:

    1) Testing for SS$_NORMAL when a simple "IF FAILURE" should be used.


    2) SYS$SETAST does NOT return a status, but a flag setting SS$_WASCLR
    (1) or SS$_WASSET (9)

    Fix:
    call "SYS$SETAST" using by value 0 giving SYSTAT.
    display "set ast returned : ", SYSTAT with conversion.

    3) Trusting a line number when compiled with optimizer.

    Fix:
    $COBOL/NOOPT [/DEBUG]
    This will report line 45 as the offending line.

    4) Using a pic s9(9) to hold an address, when cobol has a 'usage
    POINTER'

    Met vriendelijke groetjes,

    Hein

  4. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 14-8-2008 20:10 Hein RMS van den Heuvel wrote...
    > Wilm,
    >
    > Main problems:
    >
    > 1) Testing for SS$_NORMAL when a simple "IF FAILURE" should be used.


    Programming practice carried over from my Fortran days. Not sure whether
    fixing this would help.

    >
    > 2) SYS$SETAST does NOT return a status, but a flag setting SS$_WASCLR
    > (1) or SS$_WASSET (9)
    >
    > Fix:
    > call "SYS$SETAST" using by value 0 giving SYSTAT.
    > display "set ast returned : ", SYSTAT with conversion.


    Ah, I missed that one.
    > 3) Trusting a line number when compiled with optimizer.
    >
    > Fix:
    > $COBOL/NOOPT [/DEBUG]
    > This will report line 45 as the offending line.


    I would never have guessed this one. Since optimizing is carried out
    entirely by the compiler, I would have thought it could count.

    > 4) Using a pic s9(9) to hold an address, when cobol has a 'usage
    > POINTER'


    This is in all the examples I found in respectable places, including HP
    docs.

    > Met vriendelijke groetjes,
    >
    > Hein


    Ook zo! En bedankt...
    Wilm

    (It must be a combination of 2 above and trying to DISPLAY in the AST
    routine)

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  5. Re: Help needed with / confused by AST routine (VAX,COBOL)

    On Aug 14, 1:27 pm, Wilm Boerhout
    wrote:
    > on 14-8-2008 20:10 Hein RMS van den Heuvel wrote...
    >
    > > Wilm,

    >
    > > Main problems:

    >
    > > 1) Testing for SS$_NORMAL when a simple "IF FAILURE" should be used.

    >
    > Programming practice carried over from my Fortran days. Not sure whether
    > fixing this would help.
    >
    >
    >
    > > 2) SYS$SETAST does NOT return a status, but a flag setting SS$_WASCLR
    > > (1) or SS$_WASSET (9)

    >
    > > Fix:
    > > call "SYS$SETAST" using by value 0 giving SYSTAT.
    > > display "set ast returned : ", SYSTAT with conversion.

    >
    > Ah, I missed that one.
    >
    > > 3) Trusting a line number when compiled with optimizer.

    >
    > > Fix:
    > > $COBOL/NOOPT [/DEBUG]
    > > This will report line 45 as the offending line.

    >
    > I would never have guessed this one. Since optimizing is carried out
    > entirely by the compiler, I would have thought it could count.
    >
    > > 4) Using a pic s9(9) to hold an address, when cobol has a 'usage
    > > POINTER'

    >
    > This is in all the examples I found in respectable places, including HP
    > docs.
    >
    > > Met vriendelijke groetjes,

    >
    > > Hein

    >
    > Ook zo! En bedankt...
    > Wilm
    >
    > (It must be a combination of 2 above and trying to DISPLAY in the AST
    > routine)
    >
    > --
    > Wilm Boerhout Zwolle, NL
    > remove OLD PAINT from return address to reply



    Wilm,

    I have not had a chance to digest your sample, but you may find my
    DECUS presentation on "Introduction to AST Programming" (slides
    available at http://www.rlgsc.com/cets/2000/435.html ).

    - Bob Gezelter, http://www.rlgsc.com

  6. Re: Help needed with / confused by AST routine (VAX,COBOL)

    On Aug 14, 2:27*pm, Wilm Boerhout
    wrote:
    > on 14-8-2008 20:10 Hein RMS van den Heuvel wrote...
    >
    > > Wilm,

    >
    > > Main problems:

    >
    > > 1) Testing for SS$_NORMAL when a simple "IF FAILURE" should be used.

    >
    > Programming practice carried over from my Fortran days. Not sure whether
    > fixing this would help.


    OpenVMS Cobol (and pascal , and...) have a nice 'IF SUCCES/FAILURE'
    test which just looks for the low bit to be set. The WASSET and WASCLR
    values both have those set (no conicidence).

    > > 3) Trusting a line number when compiled with optimizer.

    >
    > > Fix:
    > > * * * $COBOL/NOOPT [/DEBUG]
    > > This will report line 45 as the offending line.

    >
    > I would never have guessed this one. Since optimizing is carried out
    > entirely by the compiler, I would have thought it could count.


    It can count, but it can not decide...
    Check it out with COBOL/LIST/MACHINE and look for 00049 with the
    editor.
    You'll see it being partly executed in many places.
    Too many to keep a full inventory for runtime usage.

    > > 4) Using a pic s9(9) to hold an address, when cobol has a 'usage
    > > POINTER'

    >
    > This is in all the examples I found in respectable places, including HP docs.


    I realize that. I should have listed is as a recommendation, not a
    problem.
    My own example for cobol AST's, published in 'Ask the Wizard' (amongst
    others) uses the COMP S9(9) hack.
    That's what we all used to do,
    http://h71000.www7.hp.com/wizard/wiz_8137.html

    Hein.

  7. Re: Help needed with / confused by AST routine (VAX,COBOL)

    On Aug 14, 1:27 pm, Wilm Boerhout
    wrote:
    > on 14-8-2008 20:10 Hein RMS van den Heuvel wrote...
    >
    > > Wilm,

    >
    > > Main problems:

    >
    > > 1) Testing for SS$_NORMAL when a simple "IF FAILURE" should be used.

    >
    > Programming practice carried over from my Fortran days. Not sure whether
    > fixing this would help.
    >
    >
    >
    > > 2) SYS$SETAST does NOT return a status, but a flag setting SS$_WASCLR
    > > (1) or SS$_WASSET (9)

    >
    > > Fix:
    > > call "SYS$SETAST" using by value 0 giving SYSTAT.
    > > display "set ast returned : ", SYSTAT with conversion.

    >
    > Ah, I missed that one.
    >
    > > 3) Trusting a line number when compiled with optimizer.

    >
    > > Fix:
    > > $COBOL/NOOPT [/DEBUG]
    > > This will report line 45 as the offending line.

    >
    > I would never have guessed this one. Since optimizing is carried out
    > entirely by the compiler, I would have thought it could count.
    >
    > > 4) Using a pic s9(9) to hold an address, when cobol has a 'usage
    > > POINTER'

    >
    > This is in all the examples I found in respectable places, including HP
    > docs.
    >
    > > Met vriendelijke groetjes,

    >
    > > Hein

    >
    > Ook zo! En bedankt...
    > Wilm
    >
    > (It must be a combination of 2 above and trying to DISPLAY in the AST
    > routine)
    >
    > --
    > Wilm Boerhout Zwolle, NL
    > remove OLD PAINT from return address to reply



    Wimn,

    It is also generally not safe to call RTL routines from both AST/
    regular threads, unless one has specific knowledge that the RTL
    routine does not have any static data areas).

    - Bob Gezelter, http://www.rlgsc.com

  8. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 14-8-2008 21:04 Bob Gezelter wrote...
    [snip]

    > It is also generally not safe to call RTL routines from both AST/
    > regular threads, unless one has specific knowledge that the RTL
    > routine does not have any static data areas).


    That is why I avoid it. The $DCLAST system service is used for that
    purpose. I'm under the impression that this is the recommended way to
    "run" an AST routine immediately.

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  9. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 14-8-2008 21:02 Bob Gezelter wrote...
    [snip]

    > I have not had a chance to digest your sample, but you may find my
    > DECUS presentation on "Introduction to AST Programming" (slides
    > available at http://www.rlgsc.com/cets/2000/435.html ).


    Thanks. This is good stuff.

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  10. Re: Help needed with / confused by AST routine (VAX,COBOL)

    Hi Wilm,

    > - if yes, can you tell me why it ACCVIOs, and how to avoid it?


    As Hein pointed out, it's the ss$_wasset/ss$_wasclr i.e. LIB$STOPping with
    ss$_wasset will look like an accvio.

    You should check "not = ss$_wasset and ss$_wasclr." also you probably don't
    want to turn it back on again if it was clear in the first place.

    Apart from that, feel free to keep checking your status values for known
    results (especially if you're interested in warning statii such as data
    truncations), lower-case is really good, and "add" can often beat compute in
    many areas.

    Cheers Richard Maher

    PS. You can use a small MACRO file to achieve compile-time initialization of
    MIS if you're into that?

    "Wilm Boerhout" wrote in message
    news:48a465f3$0$6003$ba620dc5@text.nova.planet.nl. ..
    > This is on VAX/VMS 7.3, COBOL 5.7-63
    >
    > I need to extend some program's functionality and came up with an idea
    > to let an AST routine do periodic reporting. I was brutally ACCVIO'd by
    > the program, and made a small reproducer. I'm sure I don't understand
    > all about AST programming (it's relatively new to me), but why it would
    > fail in exactly this manner baffles me.
    >
    > The real program will have a network listener instead of a
    > DISPLAY/ACCEPT loop, but you'll get the general idea. Also, the MIS area
    > will have really useful data, trust me.
    >
    > The reproducer ACCVIO's in the compute statement marked with two
    > asterisks (**) below.
    > Two questions:
    > - can you reproduce the error?
    > - if yes, can you tell me why it ACCVIOs, and how to avoid it?
    >
    > TIA,
    > Wilm
    > *-------------------------------------------- cut here -----------
    > identification division.
    > program-id. TESTIMR initial.
    >
    > data division.
    > working-storage section.
    > 01 SS$_NORMAL pic S9(9) comp value external SS$_NORMAL.
    > 01 ASTSERV pic S9(9) comp value external ASTSERV.
    > 01 SYSTAT pic S9(9) comp.
    >
    > 01 TELLER pic 9.
    >
    > 01 MIS external.
    > 02 SOM pic 9(6) occurs 10 times.
    >
    > procedure division.
    > TEST-TIMER section.
    > 00.
    > move zeroes to TELLER, SOM(8).
    >
    > * fire the AST routine once:
    > call "SYS$DCLAST" using
    > by value ASTSERV,
    > omitted, omitted
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > * schedule the AST routine after defined interval:
    > call "ASTFIRE".
    > 01.
    > display "Getal: " with no advancing
    > accept TELLER
    > if TELLER = zero then go to 02.
    >
    > * suspend AST delivery while adding:
    > call "SYS$SETAST" using
    > by value 0
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > compute SOM(8) = SOM(8) + TELLER. (**)
    >
    > * resume AST delivery:
    > call "SYS$SETAST" using
    > by value 1
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > go to 01.
    > 02.
    > exit program.
    > end program TESTIMR.
    > /
    > identification division.
    > program-id. ASTFIRE.
    >
    > data division.
    > working-storage section.
    > 01 AMINUTE pic X(13) value "0 00:00:10.00".
    > 01 BMINUTE pic S9(11) comp.
    > 01 SYSTAT pic S9(9) comp.
    >
    > 01 SS$_NORMAL pic S9(9) comp value external SS$_NORMAL.
    > 01 ASTSERV pic S9(9) comp value external ASTSERV.
    >
    > procedure division.
    > AST-FIRE section.
    > 00.
    > call "SYS$BINTIM" using
    > by descriptor AMINUTE,
    > by reference BMINUTE
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > call "SYS$SETIMR" using
    > omitted,
    > by reference BMINUTE,
    > by value ASTSERV,
    > omitted, omitted
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > end program ASTFIRE.
    > /
    > identification division.
    > program-id. ASTSERV.
    >
    > data division.
    > working-storage section.
    >
    > 01 MIS external.
    > 02 SOM pic 9(6) occurs 10 times.
    >
    > procedure division.
    > AST-SERV section.
    > 00.
    > display "Som = ", SOM(8)
    > move zeroes to SOM(8).
    >
    > * reschedule AST
    > call "ASTFIRE".
    >
    > end program ASTSERV.
    >
    > --
    > Wilm Boerhout Zwolle, NL
    > remove OLD PAINT from return address to reply




  11. Re: Help needed with / confused by AST routine (VAX,COBOL)

    Wilm Boerhout wrote:
    > This is on VAX/VMS 7.3, COBOL 5.7-63
    >
    > I need to extend some program's functionality and came up with an idea
    > to let an AST routine do periodic reporting. I was brutally ACCVIO'd by
    > the program, and made a small reproducer. I'm sure I don't understand
    > all about AST programming (it's relatively new to me), but why it would
    > fail in exactly this manner baffles me.
    >
    > The real program will have a network listener instead of a
    > DISPLAY/ACCEPT loop, but you'll get the general idea. Also, the MIS area
    > will have really useful data, trust me.
    >
    > The reproducer ACCVIO's in the compute statement marked with two
    > asterisks (**) below.
    > Two questions:
    > - can you reproduce the error?
    > - if yes, can you tell me why it ACCVIOs, and how to avoid it?
    >
    > TIA,
    > Wilm
    > *-------------------------------------------- cut here -----------
    > identification division.
    > program-id. TESTIMR initial.
    >
    > data division.
    > working-storage section.
    > 01 SS$_NORMAL pic S9(9) comp value external SS$_NORMAL.
    > 01 ASTSERV pic S9(9) comp value external ASTSERV.
    > 01 SYSTAT pic S9(9) comp.
    >
    > 01 TELLER pic 9.
    >
    > 01 MIS external.
    > 02 SOM pic 9(6) occurs 10 times.
    >
    > procedure division.
    > TEST-TIMER section.
    > 00.
    > move zeroes to TELLER, SOM(8).
    >
    > * fire the AST routine once:
    > call "SYS$DCLAST" using
    > by value ASTSERV,
    > omitted, omitted
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > * schedule the AST routine after defined interval:
    > call "ASTFIRE".
    > 01.
    > display "Getal: " with no advancing
    > accept TELLER
    > if TELLER = zero then go to 02.
    >
    > * suspend AST delivery while adding:
    > call "SYS$SETAST" using
    > by value 0
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > compute SOM(8) = SOM(8) + TELLER. (**)
    >
    > * resume AST delivery:
    > call "SYS$SETAST" using
    > by value 1
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > go to 01.
    > 02.
    > exit program.
    > end program TESTIMR.
    > /
    > identification division.
    > program-id. ASTFIRE.
    >
    > data division.
    > working-storage section.
    > 01 AMINUTE pic X(13) value "0 00:00:10.00".
    > 01 BMINUTE pic S9(11) comp.
    > 01 SYSTAT pic S9(9) comp.
    >
    > 01 SS$_NORMAL pic S9(9) comp value external SS$_NORMAL.
    > 01 ASTSERV pic S9(9) comp value external ASTSERV.
    >
    > procedure division.
    > AST-FIRE section.
    > 00.
    > call "SYS$BINTIM" using
    > by descriptor AMINUTE,
    > by reference BMINUTE
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > call "SYS$SETIMR" using
    > omitted,
    > by reference BMINUTE,
    > by value ASTSERV,
    > omitted, omitted
    > giving SYSTAT
    > if SYSTAT not = SS$_NORMAL call "LIB$STOP"
    > using by value SYSTAT.
    >
    > end program ASTFIRE.
    > /
    > identification division.
    > program-id. ASTSERV.
    >
    > data division.
    > working-storage section.
    >
    > 01 MIS external.
    > 02 SOM pic 9(6) occurs 10 times.
    >
    > procedure division.
    > AST-SERV section.
    > 00.
    > display "Som = ", SOM(8)
    > move zeroes to SOM(8).
    >
    > * reschedule AST
    > call "ASTFIRE".
    >
    > end program ASTSERV.
    >


    Here is a different example, which does nothing 8-) , of
    using an AST in COBOL.

    ------------------------------------------

    identification division.
    program-id. x.

    environment division.
    data division.
    working-storage section.
    01 ast-proc-addr pointer value external ast_routine.

    01 delta-time pic s9(9) comp value -50000000.

    01 return-value pic s9(9) comp.

    * the SYS$SETIMR call returns these condition values:
    88 ss$_accvio value external ss$_accvio.
    88 ss$_exquota value external ss$_exquota.
    88 ss$_illefc value external ss$_illefc.
    88 ss$_insfmem value external ss$_insfmem.
    88 ss$_normal value external ss$_normal.
    88 ss$_unasefc value external ss$_unasefc.

    procedure division.
    call-set-timer-service.

    call "sys$setimr"
    using
    omitted
    by reference delta-time
    by value ast-proc-addr
    omitted
    omitted
    giving
    return-value
    end-call

    if ss$_normal
    display "Sleeping for 5 seconds"

    call "sys$hiber"
    giving return-value

    end-call

    display "Awakened!"

    else
    evaluate true
    when ss$_accvio
    display "Expiration time not readable"

    when ss$_exquota
    display "Process AST or timer quota exceeded"

    when ss$_illefc
    display "Illegal event flag number specified"

    when ss$_insfmem
    display "Not enough dynamic memory to allocate timer
    element"

    when ss$_unasefc
    display "Process does not have the specified event flag"

    end-evaluate

    end-if

    stop run


  12. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 14-8-2008 23:23 Richard Maher wrote...

    [snip]

    > PS. You can use a small MACRO file to achieve compile-time initialization of
    > MIS if you're into that?


    Thanks for joining Richard. I inherited this COBOL program recently
    (it's 20 years old now) and am still struggling with the finer details
    of the language. Apparently, an EXTERNAL data area cannnot be
    initialized by VALUE clauses. What would your macro look like?

    /Wilm

  13. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 15-8-2008 2:48 Jeff Campbell wrote...
    [snip]

    > evaluate true
    > when ss$_accvio
    > display "Expiration time not readable"


    Jeff, I learn something new every day. Please explain the "evaluate
    true" construction. How can comapring "true" with the condition codes do
    the switching? COBOL never ceases to amaze me.

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  14. Re: Help needed with / confused by AST routine (VAX,COBOL)

    On Thu, 14 Aug 2008 22:14:31 -0700, Wilm Boerhout
    wrote:

    > on 14-8-2008 23:23 Richard Maher wrote...
    >
    > [snip]
    >
    >> PS. You can use a small MACRO file to achieve compile-time
    >> initialization of
    >> MIS if you're into that?

    >
    > Thanks for joining Richard. I inherited this COBOL program recently
    > (it's 20 years old now) and am still struggling with the finer details
    > of the language. Apparently, an EXTERNAL data area cannnot be
    > initialized by VALUE clauses. What would your macro look like?


    Why do you need macro? You could certainly do it with a small PL/I program
    without any executable statements using the INITIAL attribute on the
    declaration

    External implies static, of course, which precludes reentrancy. If that
    is an
    issue you may need to rethink the design.


    > /Wilm




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

  15. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 15-8-2008 17:45 Tom Linden wrote...

    [snip]

    > Why do you need macro? You could certainly do it with a small PL/I program
    > without any executable statements using the INITIAL attribute on the
    > declaration


    No compiler licenses other than COBOL on the system. It's not hobbyist.

    > External implies static, of course, which precludes reentrancy. If that
    > is an
    > issue you may need to rethink the design.


    This one static area holds variables filled at random time intervals,
    initiated by external events, by the main program. Every minute, the AST
    routine collects the variables from the static area and sends them away
    to a {screen/application/webserver, tbd} and zeroes the variables. No
    other agents work on the static area. Zeroing is done in the AST
    routine, and thus cannot be interrupted in user mode. Putting the
    variables into the area by the main program is shielded by a $SETAST
    (off,on) pair.

    If you can think of any other design for a main progam that runs
    synchronously since its inception, let me know. I've learned a lot in
    the past 48 hours, and am willing to learn more.

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  16. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 14-8-2008 23:23 Richard Maher wrote...

    [snip]

    Reproducer program now works fine, with changes suggested by Richard &
    Hein &al.:

    - communication between main program and AST server routine is done via
    common AST area
    - condition value testing done via "is failure" construct. This removes
    my $SETAST error, cause of the ACCVIO
    - I/O from AST server routine not via DISPLAY (COB$xxx routines), but
    via separate channel to terminal and $QIO.

    Now on to build this into the original program!

    Thanks all.

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  17. Re: Help needed with / confused by AST routine (VAX,COBOL)

    Wilm Boerhout wrote:

    > If you can think of any other design for a main progam that runs
    > synchronously since its inception, let me know. I've learned a lot in
    > the past 48 hours, and am willing to learn more.



    You can do a lot within an AST. But any IO should be done with $QIO and
    not higher level RTL. ($QIO does what it says: it queues an IO and does
    not wait).

    $QIOW in an AST is a no-no because if the IO doesn't complete, your
    program freezes and no other ASTs (such as important ASTs) can be delivered.

    If you want total freedom in code, then you AST can simply set some flag
    (variable = 1), then wake the mainline program. Mainline program then
    checks that variable, if it is set to 1, it performs the "execute every
    minute" code and sets the variable to 0, otherwise, it just performs the
    normal work.

  18. Re: Help needed with / confused by AST routine (VAX,COBOL)

    on 15-8-2008 22:07 JF Mezei wrote...
    > Wilm Boerhout wrote:
    >
    >> If you can think of any other design for a main progam that runs
    >> synchronously since its inception, let me know. I've learned a lot in
    >> the past 48 hours, and am willing to learn more.

    >
    >
    > You can do a lot within an AST. But any IO should be done with $QIO and
    > not higher level RTL. ($QIO does what it says: it queues an IO and does
    > not wait).
    >
    > $QIOW in an AST is a no-no because if the IO doesn't complete, your
    > program freezes and no other ASTs (such as important ASTs) can be delivered.
    >
    > If you want total freedom in code, then you AST can simply set some flag
    > (variable = 1), then wake the mainline program. Mainline program then
    > checks that variable, if it is set to 1, it performs the "execute every
    > minute" code and sets the variable to 0, otherwise, it just performs the
    > normal work.


    This is useful JF. Hadn't thought about the QIOW not completing -as I
    said, AST's are new to me. But you said "wake the mainline program". It
    never hibernates, and sometime waits longer than a minute for an
    external event (mailbox reads, synchronously). It is important howver
    for the AST to report on minutes that have no activity (no counters
    accumulated). I have to think this through.

    --
    Wilm Boerhout Zwolle, NL
    remove OLD PAINT from return address to reply

  19. Re: Help needed with / confused by AST routine (VAX,COBOL)

    Wilm Boerhout wrote:

    > This is useful JF. Hadn't thought about the QIOW not completing -as I
    > said, AST's are new to me. But you said "wake the mainline program". It
    > never hibernates, and sometime waits longer than a minute for an
    > external event (mailbox reads, synchronously). It is important howver
    > for the AST to report on minutes that have no activity (no counters
    > accumulated). I have to think this through.



    If your mainline can be stuck in an IO, then you'll need to do the "each
    minute" logic all inside the AST. In this case, you need to be careful
    how you do this.

    If this is to be done with TCPIP, I would recommend you use the $QIO
    interface. Not as pretty but will be better suited to AST driven logic.

    Note however, that one possible problem when you don't wait for
    completion is that if the pipe gets clogged (reader at other end is
    stuck or whatever), you will continue to send QIO and at one point, your
    QIO queue (BUFCNT) will be full and your QIO will either fail or get
    stuck waiting for space on the queue. In practice, this may or may not
    be a serious enough problem, but something to be aware of.

    Another possibility would be to have multi threaded approach. But not
    sure you'd want to do that in COBOL :-)

    There is a LOT of stuff that can be done inside an AST. Just remember
    that it will interrupt whatever code was executing in the mainline.

    There are some RTL routines that may not be re-entrant (aka: only one
    instance of that routine can execute in a process at a time). So if you
    can LIB$DO_SOMETHING in your mainline, you might not be able to call
    LIB$DO_SOMETHING in your AST.

    (the issue here is that you may not know exactly what COBOL does behind
    the scenes).

    Stuff like SYS$BINTIM , SYS$QIO etc are all pretty basic and work well
    inside ASTs.


  20. Re: Help needed with / confused by AST routine (VAX,COBOL)

    Wilm Boerhout wrote:
    > on 15-8-2008 2:48 Jeff Campbell wrote...
    > [snip]
    >
    >> evaluate true
    >> when ss$_accvio
    >> display "Expiration time not readable"

    >
    > Jeff, I learn something new every day. Please explain the "evaluate
    > true" construction. How can comapring "true" with the condition codes do
    > the switching? COBOL never ceases to amaze me.
    >


    EVALUATE TRUE will check the state of the variable the 88 condition
    values are defined against. It's a shorthand way of saying:

    if return-status = ss$accvio then ....




    Jeff


    ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= - Total Privacy via Encryption =---

+ Reply to Thread
Page 1 of 2 1 2 LastLast