Hello TechXchange!

New territory for us trying to use the ISPF Audit dialog 'Alert configuration: verify alert configuration' described on the 3.1 zSecure Alert User Ref Manual.  On the test system we see some other configuration 'ACT'ive (Y) and we try to modify then verify it.  The VERIFY function always results in CKR0231 RC08 due to the error in one of the statements (someone tried to add a new 'Alert') - as the message id documents.  We make the modification to remove all the statements in error, save the member, then try to 'Re-Verify' the member.  This consistently pulls in another copy somewhere, not knowing where from, and does not use our modified member.  

Q: Why does it keep using an old copy of the member, not our new modified member?  Is it stored in a table or temporary file somewhere?  We tried to create a whole new member and it's various suffixes but it still uses the old 'Act'ive data somehow.  

Thanks for help.  

Lynn

When you use ISPF option SE.A.A to maintain the alert configurations, these actions take place on the C2PCUST data set defined in the CKRPARM(C2R$PARM) member with // SET C2PCUST=dsname.

The skeletons for installation defined alerts are stored in this C2PCUST data set.  IBM standard alert skeletons are in the SCKRSLIB.

In the alert definition for the suspected alert, check the alert skeleton member name field, or enter an E in front of the alert skeleton line.  This member in C2PCUST is the first place the skeleton generator starts generating code.

Hello TechXchange!

New territory for us trying to use the ISPF Audit dialog 'Alert configuration: verify alert configuration' described on the 3.1 zSecure Alert User Ref Manual.  On the test system we see some other configuration 'ACT'ive (Y) and we try to modify then verify it.  The VERIFY function always results in CKR0231 RC08 due to the error in one of the statements (someone tried to add a new 'Alert') - as the message id documents.  We make the modification to remove all the statements in error, save the member, then try to 'Re-Verify' the member.  This consistently pulls in another copy somewhere, not knowing where from, and does not use our modified member.  

Q: Why does it keep using an old copy of the member, not our new modified member?  Is it stored in a table or temporary file somewhere?  We tried to create a whole new member and it's various suffixes but it still uses the old 'Act'ive data somehow.  

Thanks for help.  

Lynn

Bringing up C2POLICE is a matter of configuring C2PCUST, the C2POLICE and C2PCOLL members in PROCLIB, and initializing the CKFREEZE in the right order.

For starters, you need a C2PCUST for your sysplex, and CKFREEZE data set for each LPAR.  As you remember, C2POLICE must run on each LPAR and each C2POLICE has its own CKFREEZE describing the LPAR.  Look at the installation manual on how to use C2PZAIN1 to allocate these data sets and to initialize each CKFREEZE.

Make sure the C2PCUST name and the C2POLICE started task name are reflected in the CKRPARM(C2R$PARM) member (uncomment the  SET commands).

You now have a C2PCUST, it is time to initialize the alert set. 

1. Go to SE.A.A.
2. Create a new alert set by copying C2PDLF, specify a name that reflects the plex that will use the alert set.  You will get pulled through the set options, the destinations and finally you can select the alerts that you will use.
3. Make sure you specify the name of a CKFREEZE data set in the set option panel, this may be a CKFREEZE that you have used for other purposes already, it may be the CKFREEZE that you just created using C2PZAIN1.
4. If this is a new set, you will automatically Verify the set.  This creates members aaaaaVf, where aaaaa is the alert set name, and test the members for syntax failures.  If this is an existing set, you must type the V line command for the set, yourself.
5. If this is a new set, you will be prompted to refresh the started task.  But C2POLICE is not active yet, so you get an error.  Never mind, the previously tested aaaaVf members all get copied to aaaaaf in C2PCUST.  If this was an existing set, you can type the F line command yourself.  In any case, the C2PCUST is ready for use when F (refresh) is completed.

Edit the C2POLICE member in PROCLIB.  You must specify the alert set start-up member in the parameter PPARM, if you don't, the default value is C2PDFLP and this member does not exist.  So

// PPARM=aaaaaP,

Now it is time to S C2POLICE

Once C2POLICE is running, you can go back into SE.A.A, inspect the set, activate more alerts, and do the V and F line commands.  The latter will send a command to the local C2POLICE to read the modified CARLa script, and refresh the configuration.

If you run C2POLICE in more LPARs, from the same C2PCUST members, these LPARs will read the updated members magically within an hour, when their reporting cycle starts again, or you can /RO *ALL,F C2POLICE,REFRESH in SDSF.

PS. if you find that the number of buffers is to small, change the size and number using the E line command on the set.  Use the normal V and F line commands but do not put a / in front of "refresh C2POLICE".  Instead issue /RO *ALL,F C2POLICE,RESTART in SDSF.
------------------------------
Rob van Hoboken
------------------------------