Hello,

we have a monitor product that has loaded a new SVC in our systems.  This causes the Alert 1603 to fire.  I now how the problem where every hour this alert is triggering.  Originally, this was on all 4 systems in the SYSPLEX but after restarting C2POLICE on all 4 systems, the alert is now only coming on 2 systems.  The monitor is active on all 4 systems still.  What can I do to stop the alert being erroneously triggered?

Many thanks!

Hi peter

Alert 1603 is an extended monitoring alert. Effectively it reports on changes to the system and specifcally to changes to SVC's. I am a bit puzzled why that alert keeps on being triggered every hour (Or did i misunderstood that). A new mini CKFREEZE is created at the start of a new stage1 interval so i'dd expect these alerts to stop because it shouldnt find changes anymore after a while. 

So what is the alert actually reporting. Is it add or delete or both. That might shed some light on what is happening,

cheers

rene

Hello,

we have a monitor product that has loaded a new SVC in our systems.  This causes the Alert 1603 to fire.  I now how the problem where every hour this alert is triggering.  Originally, this was on all 4 systems in the SYSPLEX but after restarting C2POLICE on all 4 systems, the alert is now only coming on 2 systems.  The monitor is active on all 4 systems still.  What can I do to stop the alert being erroneously triggered?

Many thanks!

Hi Rene,

you have understood correctly. The alart is being triggered hourly on 2 of the 4 z/OS Systems in the SYSPLEX.

The alert ist saying:

A change in the definition of an SVC has been detected

Alert id 1603
Date and time 8Jan25 09:07:18
SVC/ESR number 95/
Address 128E9000
APF No

The Alert from an hour earlier is very similar:

A change in the definition of an SVC has been detected
Alert id 1603
Date and time 8Jan25 08:07:18
SVC/ESR number 95/
Address 128E9000
APF No

For the record, we are at z/OS 2.5 and z/Secure 3.1 (we wanted the CIS Audit functionality)..

Hi peter

Alert 1603 is an extended monitoring alert. Effectively it reports on changes to the system and specifcally to changes to SVC's. I am a bit puzzled why that alert keeps on being triggered every hour (Or did i misunderstood that). A new mini CKFREEZE is created at the start of a new stage1 interval so i'dd expect these alerts to stop because it shouldnt find changes anymore after a while. 

So what is the alert actually reporting. Is it add or delete or both. That might shed some light on what is happening,

cheers

rene

Hello,

we have a monitor product that has loaded a new SVC in our systems.  This causes the Alert 1603 to fire.  I now how the problem where every hour this alert is triggering.  Originally, this was on all 4 systems in the SYSPLEX but after restarting C2POLICE on all 4 systems, the alert is now only coming on 2 systems.  The monitor is active on all 4 systems still.  What can I do to stop the alert being erroneously triggered?

Many thanks!

Hi peter,

that looks odd. As it says there is a difference, the first thing i would have a look at is the creating of the mini CKFREEZE's is going as it should. You can check via ISPF 3.4 if all the CKFREEZE's for time you specified as "Snapshot retention" are actually there. It kinda looks like its using the same base CKFREEZE over and over again.

cheers

rene

Hi Rene,

you have understood correctly. The alart is being triggered hourly on 2 of the 4 z/OS Systems in the SYSPLEX.

The alert ist saying:

A change in the definition of an SVC has been detected

Alert id 1603
Date and time 8Jan25 09:07:18
SVC/ESR number 95/
Address 128E9000
APF No

The Alert from an hour earlier is very similar:

A change in the definition of an SVC has been detected
Alert id 1603
Date and time 8Jan25 08:07:18
SVC/ESR number 95/
Address 128E9000
APF No

For the record, we are at z/OS 2.5 and z/Secure 3.1 (we wanted the CIS Audit functionality)..

Hi peter

Alert 1603 is an extended monitoring alert. Effectively it reports on changes to the system and specifcally to changes to SVC's. I am a bit puzzled why that alert keeps on being triggered every hour (Or did i misunderstood that). A new mini CKFREEZE is created at the start of a new stage1 interval so i'dd expect these alerts to stop because it shouldnt find changes anymore after a while. 

So what is the alert actually reporting. Is it add or delete or both. That might shed some light on what is happening,

cheers

rene

Hello,

we have a monitor product that has loaded a new SVC in our systems.  This causes the Alert 1603 to fire.  I now how the problem where every hour this alert is triggering.  Originally, this was on all 4 systems in the SYSPLEX but after restarting C2POLICE on all 4 systems, the alert is now only coming on 2 systems.  The monitor is active on all 4 systems still.  What can I do to stop the alert being erroneously triggered?

Many thanks!

Hi Rene,

I also thought that it could be something like that.  There are 24 hours worth of the CKFREEZE Datasets - the timestamps match.  The Daily CKFREEZE for C2POLICE is also being created each day (based on the date in the file).

Hi peter,

that looks odd. As it says there is a difference, the first thing i would have a look at is the creating of the mini CKFREEZE's is going as it should. You can check via ISPF 3.4 if all the CKFREEZE's for time you specified as "Snapshot retention" are actually there. It kinda looks like its using the same base CKFREEZE over and over again.

cheers

rene

Hi Rene,

you have understood correctly. The alart is being triggered hourly on 2 of the 4 z/OS Systems in the SYSPLEX.

The alert ist saying:

A change in the definition of an SVC has been detected

Alert id 1603
Date and time 8Jan25 09:07:18
SVC/ESR number 95/
Address 128E9000
APF No

The Alert from an hour earlier is very similar:

A change in the definition of an SVC has been detected
Alert id 1603
Date and time 8Jan25 08:07:18
SVC/ESR number 95/
Address 128E9000
APF No

For the record, we are at z/OS 2.5 and z/Secure 3.1 (we wanted the CIS Audit functionality)..

Hi peter

Alert 1603 is an extended monitoring alert. Effectively it reports on changes to the system and specifcally to changes to SVC's. I am a bit puzzled why that alert keeps on being triggered every hour (Or did i misunderstood that). A new mini CKFREEZE is created at the start of a new stage1 interval so i'dd expect these alerts to stop because it shouldnt find changes anymore after a while. 

So what is the alert actually reporting. Is it add or delete or both. That might shed some light on what is happening,

cheers

rene

Hello,

we have a monitor product that has loaded a new SVC in our systems.  This causes the Alert 1603 to fire.  I now how the problem where every hour this alert is triggering.  Originally, this was on all 4 systems in the SYSPLEX but after restarting C2POLICE on all 4 systems, the alert is now only coming on 2 systems.  The monitor is active on all 4 systems still.  What can I do to stop the alert being erroneously triggered?

Many thanks!

Hi peter

can you issue a "F C2POLICE,DEBUG EXTMON" . That should produce something like this in log of the started task.

C2P0418I Extended monitor snapshot has been taken                                                  
C2P0445I Saved baseline data set is ALERT.TVT6089.CKFREEZE.D250108.T1501                           
C2P0538I Prepare ALLOC statements for ExtMon                                                       
C2P0539I ALLOC TYPE=CKFREEZE ASAPFREE COMPLEX=BASE DSN=ALERT.TVT6089.CKFREEZE.D250108.T1501        
C2P0539I ALLOC TYPE=CKFREEZE ASAPFREE COMPLEX=CURRENT DSN=ALERT.TVT6089.CKFREEZE.D250108.T1511     
C2P0567I Update baseline data set to ALERT.TVT6089.CKFREEZE.D250108.T1511                          

so we can rule out that its using an old CKFREEZE as base. If it is using the correct one then last thing I can come up with is having an actual look at the values this query shows. You can use both the mini CKFREEZE's that alert created. Easiest way to compare is to create 2 input sets. It should list the old and new values below each other. 

n type=svc  

select svcno=xx                                  
sortlist svcno esrno curr_content curr_apf / ,    
         curr_content(dump) / ,                   
         curr_apf(dump)                             

cheers

rene

Hi Rene,

I also thought that it could be something like that.  There are 24 hours worth of the CKFREEZE Datasets - the timestamps match.  The Daily CKFREEZE for C2POLICE is also being created each day (based on the date in the file).

Hi peter,

that looks odd. As it says there is a difference, the first thing i would have a look at is the creating of the mini CKFREEZE's is going as it should. You can check via ISPF 3.4 if all the CKFREEZE's for time you specified as "Snapshot retention" are actually there. It kinda looks like its using the same base CKFREEZE over and over again.

cheers

rene

Hi Rene,

you have understood correctly. The alart is being triggered hourly on 2 of the 4 z/OS Systems in the SYSPLEX.

The alert ist saying:

A change in the definition of an SVC has been detected

Alert id 1603
Date and time 8Jan25 09:07:18
SVC/ESR number 95/
Address 128E9000
APF No

The Alert from an hour earlier is very similar:

A change in the definition of an SVC has been detected
Alert id 1603
Date and time 8Jan25 08:07:18
SVC/ESR number 95/
Address 128E9000
APF No

For the record, we are at z/OS 2.5 and z/Secure 3.1 (we wanted the CIS Audit functionality)..

Hi peter

Alert 1603 is an extended monitoring alert. Effectively it reports on changes to the system and specifcally to changes to SVC's. I am a bit puzzled why that alert keeps on being triggered every hour (Or did i misunderstood that). A new mini CKFREEZE is created at the start of a new stage1 interval so i'dd expect these alerts to stop because it shouldnt find changes anymore after a while. 

So what is the alert actually reporting. Is it add or delete or both. That might shed some light on what is happening,

cheers

rene

Hello,

we have a monitor product that has loaded a new SVC in our systems.  This causes the Alert 1603 to fire.  I now how the problem where every hour this alert is triggering.  Originally, this was on all 4 systems in the SYSPLEX but after restarting C2POLICE on all 4 systems, the alert is now only coming on 2 systems.  The monitor is active on all 4 systems still.  What can I do to stop the alert being erroneously triggered?

Many thanks!

Hi Rene,

well that has helped.  The good news is that the Extended Monitoring is OK.  The Baseline is always the previous CKFREEZE.  The SVC is changing!  There seems to be a counter or some such that is stored in an area at the beginning of the SVC and as this is continually changing, the alert is being triggered. 

Does the alert just look at the first 256 bytes of the SVC to detect changes?

I will be asking the vendor what they are doing ...

Thanks for your help!

Hi peter

can you issue a "F C2POLICE,DEBUG EXTMON" . That should produce something like this in log of the started task.

C2P0418I Extended monitor snapshot has been taken                                                  
C2P0445I Saved baseline data set is ALERT.TVT6089.CKFREEZE.D250108.T1501                           
C2P0538I Prepare ALLOC statements for ExtMon                                                       
C2P0539I ALLOC TYPE=CKFREEZE ASAPFREE COMPLEX=BASE DSN=ALERT.TVT6089.CKFREEZE.D250108.T1501        
C2P0539I ALLOC TYPE=CKFREEZE ASAPFREE COMPLEX=CURRENT DSN=ALERT.TVT6089.CKFREEZE.D250108.T1511     
C2P0567I Update baseline data set to ALERT.TVT6089.CKFREEZE.D250108.T1511                          

so we can rule out that its using an old CKFREEZE as base. If it is using the correct one then last thing I can come up with is having an actual look at the values this query shows. You can use both the mini CKFREEZE's that alert created. Easiest way to compare is to create 2 input sets. It should list the old and new values below each other. 

n type=svc  

select svcno=xx                                  
sortlist svcno esrno curr_content curr_apf / ,    
         curr_content(dump) / ,                   
         curr_apf(dump)                             

cheers

rene

Hi Rene,

I also thought that it could be something like that.  There are 24 hours worth of the CKFREEZE Datasets - the timestamps match.  The Daily CKFREEZE for C2POLICE is also being created each day (based on the date in the file).

Hi peter,

that looks odd. As it says there is a difference, the first thing i would have a look at is the creating of the mini CKFREEZE's is going as it should. You can check via ISPF 3.4 if all the CKFREEZE's for time you specified as "Snapshot retention" are actually there. It kinda looks like its using the same base CKFREEZE over and over again.

cheers

rene

Hi Rene,

you have understood correctly. The alart is being triggered hourly on 2 of the 4 z/OS Systems in the SYSPLEX.

The alert ist saying:

A change in the definition of an SVC has been detected

Alert id 1603
Date and time 8Jan25 09:07:18
SVC/ESR number 95/
Address 128E9000
APF No

The Alert from an hour earlier is very similar:

A change in the definition of an SVC has been detected
Alert id 1603
Date and time 8Jan25 08:07:18
SVC/ESR number 95/
Address 128E9000
APF No

For the record, we are at z/OS 2.5 and z/Secure 3.1 (we wanted the CIS Audit functionality)..

Hi peter

Alert 1603 is an extended monitoring alert. Effectively it reports on changes to the system and specifcally to changes to SVC's. I am a bit puzzled why that alert keeps on being triggered every hour (Or did i misunderstood that). A new mini CKFREEZE is created at the start of a new stage1 interval so i'dd expect these alerts to stop because it shouldnt find changes anymore after a while. 

So what is the alert actually reporting. Is it add or delete or both. That might shed some light on what is happening,

cheers

rene

Hello,

we have a monitor product that has loaded a new SVC in our systems.  This causes the Alert 1603 to fire.  I now how the problem where every hour this alert is triggering.  Originally, this was on all 4 systems in the SYSPLEX but after restarting C2POLICE on all 4 systems, the alert is now only coming on 2 systems.  The monitor is active on all 4 systems still.  What can I do to stop the alert being erroneously triggered?

Many thanks!