Limiting delay with GETMSG

Clayton Westphal · Posted: Fri May 19, 2023 3:30 am

Hello, all.

I am trying to find a way to quickly identify the number of messages captured within the CART from a CONSOLE command. I am looping through using GETMSG and exiting once the RC is not zero. However, I am trying to avoid the delay in the GETMSG. Is there a way to know the number of messages in the CART outside using GETMSG in a loop?

Thanks!
Clayton

hankoerlemans · New User Joined: 25 Jan 2018 Posts: 61 Location: Australia

I tend to go for some kind of delay and capture into a STEM.

Joerg.Findeisen · Posted: Fri May 19, 2023 9:56 am

Tip: Check also the use of SDSF for issuing commands. It may be more flexible for your needs.

Clayton Westphal · Posted: Sat May 20, 2023 5:41 pm

Thanks, Joerg, for the option.

In this case I have been challenged not to build any code that is dependent on other applications - with the exception of the CONSOLE.

Clayton Westphal · Posted: Sat May 20, 2023 5:49 pm

hankoerlemans - in this case I’m stacking multiple commands that can be targeted to other DB2 members within the SYSPLEX. Also the timing of the results is required to write to SMF within a specific minute.

So what is happening is if certain commands don’t return, or depending on the number of environments that need to be checked, a long delay (such as 10 seconds) will push the process past a minute. If I use a lower wait value I may miss the results if the command doesn’t return in time.

If there was a way to know the number of messages in the cart I could loop to that count and avoid the GETMSG delay.

Thanks for the engagement!

Pedro · Posted: Sun May 21, 2023 9:13 am

re: "a long delay (such as 10 seconds) will push the process past a minute"

It is not clear from your post, but I think you have a misconception. The time you specify is not the exact time that it will wait... It is the max time that it will wait. If the response is returned at 2 seconds (way before the 10 seconds in the example), GETMSG will return the response at 2 seconds rather than the 10 specified.

Pedro · Posted: Sun May 21, 2023 9:16 am

Your program logic is not clear. Are you using the same CARTID for multiple commands? Or are you getting piecemeal responses from a single command?

My suggestion is to use a unique CARTID for each command that you issue. Submit all of the commands first then check each individual response.

Clayton Westphal · Posted: Sun May 21, 2023 11:02 am

The concept is something like this.
1) Multiple commands are fired through an STC that uses REXX and the CONSOLE command.
2) Because the code is an STC it is using the same CART as it loops through the code.
3) Each command issued has the ability to store more than one message in the CART, so there is a need to ensure it is emptied.
4) To accomplish this I am looping through using GETMSG until there are no messages left.
5) In the last loop, when there are no messages left, it will pause the amount of seconds the wait is coded for in GETMSG.
6) If I could find a way to know the number messages that are in the CART I could avoid using GETMSG to determine when the CART is empty, thus avoiding the delay.

Thanks,
Clayton

Pedro · Posted: Sun May 21, 2023 11:13 pm

Can you elaborate on this:
"Because the code is an STC it is using the same CART as it loops through the code."

It seems like an STC can create a CART id dynamically. They do not all have to be the same.

Clayton Westphal · Posted: Sun May 21, 2023 11:33 pm

The started task (STC) will be active for about a month without any restarts, with the code firing thousands of times. My preference would be to reuse the same memory spaces.

My question is if there is a way to know the number of messages that are within a CART.

Thanks,
Clayton

Pedro · Posted: Mon May 22, 2023 10:12 pm

re: "is a way to know the number of messages that are within a CART."

I do not have a good answer for you. Except that I have this observation: CART stands for 'Command And Response Token' (singular). You use the token so that you can match a command to its response. I think it was intended for one command and one response.

You can also use the same token for multiple commands, but in a single thread manner. That is, wait for the response before issuing the next command.

It seems like you are interleaving multiple commands with the same token and then getting mixed responses and not knowing if you got every response. I do not think it was designed for that and the results are not satisfactory.

Perhaps submit a requirement to IBM to enhance the function.

Clayton Westphal · Posted: Mon May 22, 2023 10:15 pm

Thanks, Pedro. I would agree the requirements set forth is making atypical use of the CONSOLE command. I will explore working with IBM to see if they can provide a solution.

I appreciate your time and engagement.

Clayton