IBM Z System Automation

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Hello,

Sorry, I wasn't able to answer directly the email received, nor by the link included in the email (seems expired).
I got an answer/suggestion from Erdal Ak, I will post here, because I don't see it in this thread. Hope this is OK.

Hi Erdal,

Thanks for responding. Your suggestion is interesting, creating an MONITOR. But in the case of this client, we don't see any HSAL6041E message in the log, neither SYSLOG nor NETLOG). This was my first question: why we don't get those ? Even verified it is OK on the MPF (HSA*,AUTO(YES),SUP(NO)) ... That's why we tried the solution with the AOFEXX02 exit, witch is OK now.

Is it another way to ask about this problem internally ? Maybe I or the client have a CASE opened ?
Thanks again for any thoughts.



Message From: Erdal Ak

Hi Patrick,
define a Monitor resource e.g. YOURMON. 
Monitored object is your YOUR/APG/SYSTEM.
In Message/User Data Processing:
e.g.
IF MSGID = 'HSAL6041E' THEN BEGIN;
IF TOKEN(2) = 'YOUR/APG/SYSTEM' . THEN
EXEC(CMD('INGMON YOURMON,STATUS=WARNING or CRITICAL')ROUTE(ONE %AOFOPGSSOPER%));

In HEALTHSTATE Processing:
State=CRITICAL 
Command Text= "your action" (e.g. send email...)

I hope it is understandable for you.

regards

------------------------------
Erdal Ak
------------------------------

------------------------------
Patrick Georges LEROY
------------------------------

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen
------------------------------

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Original Message:
Sent: 4/22/2022 3:44:00 AM
From: Dietmar Knodel
Subject: RE: Application group status

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen
------------------------------

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Steve,
excellent idea - and as a quick shot I'd recommend using AOFEXINT to drive STOBS registration, too.
To make things 'persistant' you could probably define another notification operator under '38 NFY - Notification Operators' in your PDB and assign the needed (SA) message classes (80/87/88/89) to that operator - but as I already explained to Patrick you might add overhead to your processing by searching for a needle in a haystack.
Another means could be using the 'INGNTFY ADD' command that enables you to assign message classes to and add an operator to the list of notification operators during runtime.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen
------------------------------

Original Message:
Sent: Fri April 22, 2022 09:46 AM
From: Steve Horein
Subject: Application group status

Re: Status Observer (INGSTOBS) –

This topic has me thinking about possibilities of using a general "EXIT" for something like */APG/&SYSNAME resources to extend "PostStart" capabilities to Application Groups, similar to what Patrick wants to do.

Does registration persist through NetView restart? Or through PAM WARM/COLD starts?

My thinking would be to use AOFEXINT to do the INGSTOBS REGISTER for APG (or other?) resources in place of an MTR, but would like to know when to issue the command.

 

Steve Horein

Infrastructure Engineer
Deere & Company

400 19th Street, Moline, IL 61265

 

This transmission may contain Deere & Company information, data, or analysis that is proprietary, privileged, and/or confidential.  If you are not the intended recipient, any disclosure, copying, distribution, or use of the information contained herein is prohibited.

 

 

Public

 

Original Message:
Sent: 4/22/2022 3:44:00 AM
From: Dietmar Knodel
Subject: RE: Application group status

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Original Message:
Sent: 4/25/2022 2:41:00 AM
From: Dietmar Knodel
Subject: RE: Application group status

Steve,
excellent idea - and as a quick shot I'd recommend using AOFEXINT to drive STOBS registration, too.
To make things 'persistant' you could probably define another notification operator under '38 NFY - Notification Operators' in your PDB and assign the needed (SA) message classes (80/87/88/89) to that operator - but as I already explained to Patrick you might add overhead to your processing by searching for a needle in a haystack.
Another means could be using the 'INGNTFY ADD' command that enables you to assign message classes to and add an operator to the list of notification operators during runtime.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen
------------------------------

Original Message:
Sent: Fri April 22, 2022 09:46 AM
From: Steve Horein
Subject: Application group status

Re: Status Observer (INGSTOBS) –

This topic has me thinking about possibilities of using a general "EXIT" for something like */APG/&SYSNAME resources to extend "PostStart" capabilities to Application Groups, similar to what Patrick wants to do.

Does registration persist through NetView restart? Or through PAM WARM/COLD starts?

My thinking would be to use AOFEXINT to do the INGSTOBS REGISTER for APG (or other?) resources in place of an MTR, but would like to know when to issue the command.

 

Steve Horein

Infrastructure Engineer
Deere & Company

400 19th Street, Moline, IL 61265

 

This transmission may contain Deere & Company information, data, or analysis that is proprietary, privileged, and/or confidential.  If you are not the intended recipient, any disclosure, copying, distribution, or use of the information contained herein is prohibited.

 

 

Public

 

Original Message:
Sent: 4/22/2022 3:44:00 AM
From: Dietmar Knodel
Subject: RE: Application group status

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Steve,
to be 'bulletproof' you could just check via 'INGSTOBS LIST...' whether you still have valid registrations or not.
Thus you are independant from any starttype evaluation and could rely on data queried from the runtime at the moment.
If you find the registrations you search for - all fine. If not you could setup STOBS registration as you need.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen
------------------------------

Original Message:
Sent: Mon April 25, 2022 08:05 AM
From: Steve Horein
Subject: Application group status

Thanks Dietmar!

My apologies for not being clear in terms of "...when to issue the command". In AOFEXINT, the start type is passed as an argument:

IPL      - System was IPLed            

RECYCLE  - NetView was restarted       

REFRESH  - SA configuration refreshed  

RELOAD   - ACF COLD was entered        

RESYNC   - AM was COLD/WARM started    

 

I imagine there would not be much (if any) harm issuing INGSTOBS for any type of startup, but I already have a SELECT/WHEN/OTHERWISE structure in place for to perform actions for those types.

If status observation is persistent through RECYCLE or REFRESH, then I could omit issuing the command for those types.

 

Steve Horein

Infrastructure Engineer
Deere & Company

400 19th Street, Moline, IL 61265

 

This transmission may contain Deere & Company information, data, or analysis that is proprietary, privileged, and/or confidential.  If you are not the intended recipient, any disclosure, copying, distribution, or use of the information contained herein is prohibited.

 

 

Public

Original Message:
Sent: 4/25/2022 2:41:00 AM
From: Dietmar Knodel
Subject: RE: Application group status

Steve,
excellent idea - and as a quick shot I'd recommend using AOFEXINT to drive STOBS registration, too.
To make things 'persistant' you could probably define another notification operator under '38 NFY - Notification Operators' in your PDB and assign the needed (SA) message classes (80/87/88/89) to that operator - but as I already explained to Patrick you might add overhead to your processing by searching for a needle in a haystack.
Another means could be using the 'INGNTFY ADD' command that enables you to assign message classes to and add an operator to the list of notification operators during runtime.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Fri April 22, 2022 09:46 AM
From: Steve Horein
Subject: Application group status

Re: Status Observer (INGSTOBS) –

This topic has me thinking about possibilities of using a general "EXIT" for something like */APG/&SYSNAME resources to extend "PostStart" capabilities to Application Groups, similar to what Patrick wants to do.

Does registration persist through NetView restart? Or through PAM WARM/COLD starts?

My thinking would be to use AOFEXINT to do the INGSTOBS REGISTER for APG (or other?) resources in place of an MTR, but would like to know when to issue the command.

 

Steve Horein

Infrastructure Engineer
Deere & Company

400 19th Street, Moline, IL 61265

 

This transmission may contain Deere & Company information, data, or analysis that is proprietary, privileged, and/or confidential.  If you are not the intended recipient, any disclosure, copying, distribution, or use of the information contained herein is prohibited.

 

 

Public

 

Original Message:
Sent: 4/22/2022 3:44:00 AM
From: Dietmar Knodel
Subject: RE: Application group status

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Thanks Dietmar
I will pass this info to the client. We tested initially with the INGREQ ... FDBK(MSG...) but it didn't wait for the completion of the GROUP status change. We'll try that WAIT parm then. Thanks for pointing that.
Any idea why he don't get message indicating the APG status change in NETLOG (HSAL6041E or HSAL6050E...) ? It is a simple BASIC group.
Thanks again for the hints.

------------------------------
Patrick Georges LEROY
------------------------------

Original Message:
Sent: Fri April 22, 2022 03:43 AM
From: Dietmar Knodel
Subject: Application group status

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Patrick,
HSAL6041E is assigned to SA's message classes 80/87, HSAL6050I to message classes 80/88/89.
Depending on the setup in your customer's PDB under '38 NFY - Notification Operators' these message classes might not be presented because they usually are excluded for presentation to the SYSOP (MVS CONSOLE) operator. So if your customer sticks to the provided defaults in that area this might be the cause for the 'missing' messages.

I would take care with changing settings in that area as this might cause a bunge of additional messages being added to the logs. Instead I'd recommend setting up status observers in this case to narrow down additional processing overhead to what your customer really needs to process.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen
------------------------------

Original Message:
Sent: Fri April 22, 2022 11:49 AM
From: Patrick Georges LEROY
Subject: Application group status

Thanks Dietmar
I will pass this info to the client. We tested initially with the INGREQ ... FDBK(MSG...) but it didn't wait for the completion of the GROUP status change. We'll try that WAIT parm then. Thanks for pointing that.
Any idea why he don't get message indicating the APG status change in NETLOG (HSAL6041E or HSAL6050E...) ? It is a simple BASIC group.
Thanks again for the hints.

------------------------------
Patrick Georges LEROY

Original Message:
Sent: Fri April 22, 2022 03:43 AM
From: Dietmar Knodel
Subject: Application group status

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------

Sorry I am late responding :)

Thanks for your input. I have talked to the client and am waiting for his feedback.

I'll post here any additional info.
Thanks again for your help.
Patrick.

------------------------------
Patrick Georges LEROY
------------------------------

Original Message:
Sent: Mon April 25, 2022 02:30 AM
From: Dietmar Knodel
Subject: Application group status

Patrick,
HSAL6041E is assigned to SA's message classes 80/87, HSAL6050I to message classes 80/88/89.
Depending on the setup in your customer's PDB under '38 NFY - Notification Operators' these message classes might not be presented because they usually are excluded for presentation to the SYSOP (MVS CONSOLE) operator. So if your customer sticks to the provided defaults in that area this might be the cause for the 'missing' messages.

I would take care with changing settings in that area as this might cause a bunge of additional messages being added to the logs. Instead I'd recommend setting up status observers in this case to narrow down additional processing overhead to what your customer really needs to process.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Fri April 22, 2022 11:49 AM
From: Patrick Georges LEROY
Subject: Application group status

Thanks Dietmar
I will pass this info to the client. We tested initially with the INGREQ ... FDBK(MSG...) but it didn't wait for the completion of the GROUP status change. We'll try that WAIT parm then. Thanks for pointing that.
Any idea why he don't get message indicating the APG status change in NETLOG (HSAL6041E or HSAL6050E...) ? It is a simple BASIC group.
Thanks again for the hints.

------------------------------
Patrick Georges LEROY

Original Message:
Sent: Fri April 22, 2022 03:43 AM
From: Dietmar Knodel
Subject: Application group status

Patrick,
to clarify some of your questions:

SA processes exits in a NetView PIPE, so every SAY instruction is swallowed up in the PIPE's default SAFE and thus does not make it to the 'outside world', which includes NetLog.

Using the AOFEXX02 exit to search for a needle in the haystack (as every SDF update processing goes through that exit) may cost you performance for little gain.

Regarding how to check for the group's status change and depending on the actions to be conducted there might be several ways to achieve your goals:

1. if ZWS is responsible to send the command to System Automation and for the follow-on actions to be conducted then I'd recommend to use the FDBK=(WAIT...) parameter of the INGREQ command. ZWS will be notified about the (un)successful operation. 
2. if the follow-on actions should be conducted regardless who has stopped/started the APG then you could use a MONITOR resource (MTR). But I would then not tie the MTR triggering to a message being issued, I would use the MTR's 'Activate' policy to establish a status observer routine that is registered for the APG. With that status observer you could then in turn trigger INGMON commands depending on the new status of the APG being posted to the status observer. When the MTR is being stopped you could deregister that status observer routine once again and keep your environment clean.

Regardless which way you choose you should be aware that depending on the nature of the group (BASIC, MOVE, SERVER) and the 'Status Determination' specification (CSONLY or blank) in the APG's Application Info Policy status changes for the group may be posted at different points in time.

Kind regards,
Dietmar

------------------------------
Dietmar Knodel
Software Developer
IBM Deutschland Research & Development GmbH
Böblingen

Original Message:
Sent: Tue April 12, 2022 11:00 AM
From: Patrick Georges LEROY
Subject: Application group status

Hello,

I have been working with a french client about application groups definition, and we have been testing some start/stop at the group level.

I though this would a good place to ask, if not, please advise where I can get some more info. Thanks in advance. 

We have created an APG (ACTIVE) and connected to it several CICS. When we start/stop the group via INGREQ, all CICS start/stop correctly and the group become AVAILABLE or UNAVAILABLE. The problem is that no message indicating the APG has changed status. The client wants to capture this status change and do some stuff.

We tested the INGREQ command with the FDBK=(MSG/userid,timeout...) but this message appears when the request is executed, not at the APG  status change. Don't remember if we tested FDBK=(WAIT,...), maybe it was the solution ?

As this first approach doesn't gave us the needed feedback we activated AOFEXX02 exit, called every time a status change happens in SDF. So we just ask if it it our APG then ...
At this moment we had another problem: a rexx say instruction didn't put any message in Netlog, as it would do from any rexx, don't know why ? Any thoughts ?

We had to use PIPE with LOGTO NETLOG parameter to get it done.

So with this PIPE in the AOFEXX02 exit, the client was able to capture APG status change (capturing this PIPE message in the message table).

Any thoughts about this solution ? Would you implement this differently ?
In reality they want to, from TWS job, send command to SA to start/stop group of CICS, and "wait for the completion (all APG up or down) then let rest of TWS app execute, being sure the CICS group is OK);

Thanks in advance for your thoughts.

Patrick Leroy

------------------------------
Patrick Georges LEROY
------------------------------