I've come across a few issues:

Firstly, I put together a CICS tagging file (not previously implemented), mainly because I wanted to turn off a few CICS health checker checks that annoyed me.

1a) I kept getting error message DFHPA2214 until I deleted extraneous blanks from the end of the first line (the schemaVersion specification):

DFHPA2214 E CICSST  
11/06/2023 11:15:22 CICSST A regiontags label has not been found on
line 0 in the cicstags.yaml file. Without this label, the file is not
valid.

I'm wondering if the solution to APAR PH44801 has been incorporated into CICS 6.2 beta code.

1b) Trying to disable of a number of different CICS health checks via the cicsts-ExcludedHealthChecks array causes a parse error with message DFHPA2204. For example:

DFHPA2204 E CICSST  
11/24/2023 11:16:59 CICSST The specification of Check DFHH0004 on
line 426 of the cicstags.yaml file is not valid.

The message that is produced by the CICS_REGION_CONFIGURATION health check triggering is actually DFHH0004E, which was what I had specified. I tried DFHH0004 (without the ending 'E', since that was what the error message said), but same result.

I then decided to specify all the CICS health check error messages as documented here:  https://www.ibm.com/docs/en/cics-ts/beta?topic=reference-health-checker-zos-dfhhnnnn-messages , in my cicsts-ExcludedHealthChecks array, commenting out each one as they caused DFHHPA2204 parse error. I find that the following error check messages all result in the parse error message: DFHH0001E to DFHF0008E, DFHH0200E, DFHH301I to DFH0303I, DFHH0304 to DFHH0308, DFHH0408, DFHH0801 to DFHH0810, and DFHH0957.

1c) A suggestion: it would be nice if CEMT could do a SET TAGS REFRESH. I just use CECI to issue the SP command. Other sites may have CECI and SP commnds tied down more tightly tha we do.

2) Somewhat associated with above, the health checks CICS_RESOURCE_SECURITY and CICS_CAT3_CONFIGURATION do not produce DFHH0007E and DFHH0008E respectively as documented. Instead they issue DFHH0007 and DFHH0008 (minus the 'E' suffix):

HZS0001I CHECK(IBMCICS,CICS_RESOURCE_SECURITY):
DFHH0007 One or more resource security related SIT parameters are
not optimally set.

HZS0001I CHECK(IBMCICS,CICS_CAT3_CONFIGURATION):
DFHH0008 One or more category 3 transactions have been modified so as
to specify incorrect initial programs.

These are the two that I've noticed, there may be others for health checks that don't trigger in our environment.

3) I inadvertantly left my test 6.2 test region up after leaving work. At midnight it non-fatally dumped its guts. It does this consistently and repeatably.

+DFHIC0801 CICSST CICS time altered from 24.00.000 to 00.00.052 - date 11/24/23
+DFHTI0100 CICSST This is the Beta version of CICS TS which expires on 03/31/20 - relative day 001
+DFHLM0001 CICSST An abend (code 0C4/AKEA) has occurred at offset X'12C4' in module DFHLMLM.
+DFHME0116 CICSST  
 (Module:DFHMEME) CICS symptom string for message DFHLM0001 is
 PIDS/5655BTA00 LVLS/750 MS/DFHLM0001 RIDS/DFHLMLM PTFS/BETA17
 AB/S00C4 AB/UAKEA ADRS/000012C4
+DFHDU0201 CICSST   ABOUT TO TAKE SDUMP. DUMPCODE: LM0001  , DUMPID: 1/0002
IEA794I SVC DUMP HAS CAPTURED:  
DUMPID=009 REQUESTED BY JOB (CICSST  )
DUMP TITLE=CICS DUMP: SYSTEM=CICSST   CODE=LM0001   ID=1/0002

DUMP CAPTURED USING OPTIMIZE=YES
+DFHDU0202 CICSST   SDUMPX COMPLETE. SDUMPX RETURN CODE X'00'
+DFHDD0002 CICSST A severe error (code X'0408') has occurred in module DFHDDBR.
+DFHME0116 CICSST  
 (Module:DFHMEME) CICS symptom string for message DFHDD0002 is
 PIDS/5655BTA00 LVLS/750 MS/DFHDD0002 RIDS/DFHDDBR PTFS/BETA17
 PRCS/00000408
+DFHDU0201 CICSST   ABOUT TO TAKE SDUMP. DUMPCODE: DD0002  , DUMPID: 1/0003
IEA794I SVC DUMP HAS CAPTURED:  
DUMPID=010 REQUESTED BY JOB (CICSST  )
DUMP TITLE=CICS DUMP: SYSTEM=CICSST   CODE=DD0002   ID=1/0003

DUMP CAPTURED USING OPTIMIZE=YES
+DFHDU0202 CICSST   SDUMPX COMPLETE. SDUMPX RETURN CODE X'00'
+DFHDD0002 CICSST A severe error (code X'0407') has occurred in module DFHDDBR.
+DFHME0116 CICSST  
 (Module:DFHMEME) CICS symptom string for message DFHDD0002 is
 PIDS/5655BTA00 LVLS/750 MS/DFHDD0002 RIDS/DFHDDBR PTFS/BETA17
 PRCS/00000407
+DFHDU0201 CICSST   ABOUT TO TAKE SDUMP. DUMPCODE: DD0002  , DUMPID: 1/0004
IEA794I SVC DUMP HAS CAPTURED: 
DUMPID=011 REQUESTED BY JOB (CICSST  )
DUMP TITLE=CICS DUMP: SYSTEM=CICSST   CODE=DD0002   ID=1/0004

DUMP CAPTURED USING OPTIMIZE=YES
+DFHDU0202 CICSST   SDUMPX COMPLETE. SDUMPX RETURN CODE X'00'
+DFHDD0002 CICSST A severe error (code X'0406') has occurred in module DFHDDBR.
+DFHME0116 CICSST 
 (Module:DFHMEME) CICS symptom string for message DFHDD0002 is
 PIDS/5655BTA00 LVLS/750 MS/DFHDD0002 RIDS/DFHDDBR PTFS/BETA17
 PRCS/00000406
+DFHDU0201 CICSST   ABOUT TO TAKE SDUMP. DUMPCODE: DD0002  , DUMPID: 1/0005
IEA794I SVC DUMP HAS CAPTURED: 
DUMPID=012 REQUESTED BY JOB (CICSST  )
DUMP TITLE=CICS DUMP: SYSTEM=CICSST   CODE=DD0002   ID=1/0005

A brief look at the first dump shows an instance of the CSSY transaction is the task flagged in error.

I can supply a copy of my cicstags.yaml file and/or the dumps if Hursley House desires.

Cheers, Ant.   

------------------------------
Ant. Thompson
Northern Territory Government of Australia
------------------------------

Hi Ant,

First of all, thanks for trying out the beta!

We're looking into the issues you raise and will aim to resolve them for upcoming betas or releases. And we'll contact you privately if we need more information.

------------------------------
Ben Cox
Software Designer
IBM
------------------------------

Hi Ant, 

I have had a look at the points you raised concerning the CICS tagging file and the z/OS Health Checker. 

Point 1a. The parsing of the schemaVersion and the regiontags lines is sensitive to training blanks. Extraneous blanks will cause the parse to fail, as you saw, with a DFHPA2214 message. I will see if there is anything I can do about this for a future beta. Any other lines in the CICS tagging file should not be affected by trailing extraneous blanks. 

Point 1b. This is where you attempted to suppress all of the health checker messages by using the CICS tagging file. As you found, several of these are not able to be suppressed via the tagging file and cause a parse error if you attempt to do so. Let me go through the messages and explain why. 

DFHH0001E to DFHH0008E. These are all general messages which appear at the top of the relevant check output, in s.ck for example. The messages explain what the checks are doing and are for general information about the test rather than being specific to one particular CICS region. They are only issued if one or more checks fail, so this information was thought to be useful in these circumstances. Because of this, suppression was not thought to be either useful or required for these messages. 

DFHH0200E is a severe error message which would be issued if the CICS health checks cannot run due to a problem. We would not want to suppress this message. 

DFHH0301I to DFHH0308. These messages are only issued if no CICS regions fail the relevant tests. These messages are useful to confirm that the checks have in fact been run and that no problems have been found. Without them, it would not be clear whether the checks had been run if the rest of the output was empty. Because of this, these messages cannot be suppressed. 

DFHH0408 is not a valid message number. DFHH0407 and DFHH0409 are, but not DFHH0408. 

DFHH0801 to DFHH0810. These messages concern abuse of CICS category 3 transactions. It is intentional that these important messages not be capable of suppression via a tagging file. 

DFHH0957 reports that something went wrong within a suite of tests. One of more tests have failed. Since it is important to know this, the message cannot be suppressed. 

The sample CICS tagging file in the cicsts-ExcludedHealthChecks section lists all of the messages which can be suppressed by using a tagging file. Copying the syntax and adding in other messages will result in a parsing error.

Point 2. The DFHH0007 and DFHH0008 messages should both have the "E" suffix. Can you ensure that you have an up to date version of DFHHZMGT on your system? 

I hope that this explains what you saw with your attempted message suppressions. 

Best regards

------------------------------
Darren Beard
------------------------------

Thanks for the reply Darren.

The version of DFHHZMGT we have would be the one supplied in the pax file of the October 23 drop of the CICSTS 6.2 beta.

SMP/e just says that the LASTUPD for the LMOD is HCI7500.

An AMBLIST LISTLOAD,OUTPUT =XREF returns:

                 CONTROL SECTION
                  LMOD LOC     NAME      LENGTH  TYPE  RMODE
                       00    HZSMSDFH      3799   SD    31
LENGTH OF LOAD MODULE    37A0

An AMBLIST LISTIDR returns:

CSECT        TRANSLATOR               VR.MD                            YR/DY
HZSMSDFH     569623400             01.06                          2023/282   <--- That's 9th October.

Cheers, Ant.

------------------------------
Ant Thompson
------------------------------

Original Message:
Sent: Tue November 28, 2023 10:51 AM
From: Darren Beard
Subject: CICS 6.2 beta (Oct 23) feedback

Hi Ant, 

I have had a look at the points you raised concerning the CICS tagging file and the z/OS Health Checker. 

Point 1a. The parsing of the schemaVersion and the regiontags lines is sensitive to training blanks. Extraneous blanks will cause the parse to fail, as you saw, with a DFHPA2214 message. I will see if there is anything I can do about this for a future beta. Any other lines in the CICS tagging file should not be affected by trailing extraneous blanks. 

Point 1b. This is where you attempted to suppress all of the health checker messages by using the CICS tagging file. As you found, several of these are not able to be suppressed via the tagging file and cause a parse error if you attempt to do so. Let me go through the messages and explain why. 

DFHH0001E to DFHH0008E. These are all general messages which appear at the top of the relevant check output, in s.ck for example. The messages explain what the checks are doing and are for general information about the test rather than being specific to one particular CICS region. They are only issued if one or more checks fail, so this information was thought to be useful in these circumstances. Because of this, suppression was not thought to be either useful or required for these messages. 

DFHH0200E is a severe error message which would be issued if the CICS health checks cannot run due to a problem. We would not want to suppress this message. 

DFHH0301I to DFHH0308. These messages are only issued if no CICS regions fail the relevant tests. These messages are useful to confirm that the checks have in fact been run and that no problems have been found. Without them, it would not be clear whether the checks had been run if the rest of the output was empty. Because of this, these messages cannot be suppressed. 

DFHH0408 is not a valid message number. DFHH0407 and DFHH0409 are, but not DFHH0408. 

DFHH0801 to DFHH0810. These messages concern abuse of CICS category 3 transactions. It is intentional that these important messages not be capable of suppression via a tagging file. 

DFHH0957 reports that something went wrong within a suite of tests. One of more tests have failed. Since it is important to know this, the message cannot be suppressed. 

The sample CICS tagging file in the cicsts-ExcludedHealthChecks section lists all of the messages which can be suppressed by using a tagging file. Copying the syntax and adding in other messages will result in a parsing error.

Point 2. The DFHH0007 and DFHH0008 messages should both have the "E" suffix. Can you ensure that you have an up to date version of DFHHZMGT on your system? 

I hope that this explains what you saw with your attempted message suppressions. 

Best regards

------------------------------
Darren Beard
------------------------------