Page 1 of 1

Waiting/Pausing a CList

PostPosted: Fri Oct 18, 2013 12:22 am
by yodish
In using Netview to trap a message and send to a CList, I am having difficulty creating the logic that will execute a command the first time this message is trapped; THEN wait 15 minutes (even if that message is issued 10,20,etc. more times) before executing that command again.
The Netview REXX documentation describes a WAIT statement.

The closest i'm getting, once the message is trapped, is issuing the command then Waiting (60 seconds for testing purposes). The problem is, after 60 seconds, any subsequent times the message has been trapped, the command is executed...

This is what i have so far in the CList member (that is called once the message is trapped via the automation table)

(the message is parsed into variables)

SELECT
WHEN V1 = 'IEEXXXX' THEN DO
'WTOH 'V1 V2 V3
WAIT 60
END
OTHERWISE
END


Like I described, the above code simply waits 60 seconds, then issues any WTOH that has happened in the meantime. I need a way to simply disregard the IEEXXXX message until 60 seconds is up.

Thanks in advance.

Re: Waiting/Pausing a CList

PostPosted: Fri Oct 18, 2013 12:47 am
by Akatsukami
Rexx is not CLIST. Please tattoo that on the back of your hand.

Assume there are a number of IEEXXXX messages in the automation table. You read the first one, parse it, issue the WTOH, wait 60 seconds, and...what about the other IEEXXXX message that were in the table and have been added to it?

Re: Waiting/Pausing a CList

PostPosted: Fri Oct 18, 2013 12:55 am
by yodish
Understood, i'm using 'CList' loosely in this situation.

I'm also using IEEXXX as a generic, I am actually trapping a specific IEE* message, along with others.
I'm using a SELECT statement for each individual message that is to be trapped.

I suspect I need a way to code a NOP inside of the select statement until the 60 seconds is up, but I'm obviously not getting it quite right...

Re: Waiting/Pausing a CList

PostPosted: Fri Oct 18, 2013 2:36 am
by Pedro
Sorry, I am not familiar with the environment. Is this exec one instance that is running continuously? Or is it an exec that gets invoked repeatedly (many instances of the same exec)?

My suggestion is to have an array of message numbers along with a timestamp of the last_time it was processed. If the current time is not greater than last_time + 60, then do a NOP. That is, do not wait for an interval of time, but rather perform one of two choices: 1. process message, or 2. ignore message.

Re: Waiting/Pausing a CList

PostPosted: Fri Oct 18, 2013 6:20 pm
by yodish
Thank you Pedro, i've been playing with using a timestamp
SUBSTR(TIME(),4,2) to get the minutes, hours, seconds, etc. but haven't had luck putting it all together yet.

The initial message is trapped by an application that is continuously running, which then calls an exec (as many times as the given message is trapped).

I'd rather not fiddle with trying to add time-logic to the application. So, my problem is figuring out how to add it to the EXEC that is repeatedly called.

Re: Waiting/Pausing a CList

PostPosted: Sat Oct 19, 2013 12:36 am
by Pedro
The initial message is trapped by an application that is continuously running

It sounds like this is the place to manage a variable that keeps track of last time the subroutine was called.

If you cannot update the parent exec, perhaps Netview has a way to save variables outside of the execution of an instance of a program.

| update: chapter 4 of 'Programming: REXX and the NetView Command List Language', SC31-8862-03, describes global variables. I am not familiar with it, but sounds like what you need.

Or you could save the status to a dataset. There may be performance implications to using a dataset.

Re: Waiting/Pausing a CList

PostPosted: Sat Oct 19, 2013 12:48 am
by Pedro
| update: 'Programming: REXX and the NetView Command List Language', SC31-8862-03, describes the GLOBALV function which allows you to save and retrieve variables. I am not familiar with it, but sounds like what you need.

Re: Waiting/Pausing a CList

PostPosted: Sat Oct 19, 2013 12:59 am
by yodish
Thanks for looking that manual up for me Pedro, I've scoured it many a time....it can be maddening. :)
I'll keep working on it...