[Info-vax] Returning data from Cobol AST routine.

Jan-Erik Söderholm jan-erik.soderholm at telia.com
Tue Sep 21 03:15:16 EDT 2021


Den 2021-09-21 kl. 03:27, skrev Arne Vajhøj:
> On 9/20/2021 6:55 PM, Jan-Erik Söderholm wrote:
>> I have been looking at the Cobol AST example here:
>> http://computer-programming-forum.com/48-cobol/b75d8c5fdd43048e.htm
>>
>> This does work fine as an example. But what are the options to get
>> some data back to the main program (called "x" in the example)
>> from the ast program (called "ast_routine" in the example)?
>>
>> I have tried different versions of global, external and so on, but
>> no luck so far. How to get "x" and "ast_routine" to share some data?
>> Anything similar to an COMMON area in Fortran?
>>
>> The idea is to have an AST routine that will read from a mailbox when
>> something is written to it. My idea was that the read of the mailbox
>> would be using an AST to avoid polling the mailbox.
>>
>> This is to have a command input to detached processes to get them to
>> reload the config, repoen the log file, close and exit and so on.
>>
>> Are there more options if not everything is done in Cobol?
>> We can easily add some C if that helps...
> 
> external works for me.
> 
> identification division.
> program-id. x.
> environment division.
> data division.
> working-storage section.
> 01  magic-value         pic 9(10)  display external.
> 01  ast-proc-addr       pointer           value external ast_routine.
> 01  delta-time          pic s9(18)  comp  value -50000000.
> 01  return-value        pic s9(18)  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
>      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
>      display magic-value
>      stop run
>      .
> end program x.
> identification division.
> program-id. ast_routine.
> environment division.
> data division.
> working-storage section.
> 01  magic-value         pic s9(10)  display external.
> 01  return-value        pic s9(18)  comp.
> procedure division.
> ast-fired.
>      call "sys$wake"
>          using
>              omitted
>              omitted
>          giving
>              return-value
>      end-call
>      move 123 to magic-value
>      exit program
>      .
> end program ast_routine.
> 
> $ cobol x
> $ link x
> $ run x
> sleeping for 5 seconds
> 000000012C
> 
> Arne


Ah, OK! that will be tested. Hm, is this limited to numeric variables?
My test was using a x(3) variable...

Hm, if this would had been a read-AST on a mailbos instead of a timer,
maybe the ast_routine can just awake the main code and the mailbox
been read in the main code. The ast_routine could set a variable that
just signals the reason fo the wakeup.

Good input anyway!

Jan-Erik.



More information about the Info-vax mailing list