Datacom CXXMAINT misses filename error
search cancel

Datacom CXXMAINT misses filename error

book

Article ID: 244947

calendar_today

Updated On:

Products

Datacom Datacom/DB Datacom/AD

Issue/Introduction

We had a problem where our DBA used CXXMAINT OPTION=ALTER to define the dataset name for a database area, but it was done incorrectly with a typo; however, that was successful–return code zero.

We then ran a CXX report on that database with the invalid DSN, and this report also worked. However, the MUF log shows a Top Secret (TSS) security error:

MYMUF001:000:MYMUF001:DB02843I - DATA AREA INFO - 562 ABC  P-ENCR  AREAEV       
TSS7220E 101 J=MYMUF001 A=TMUF001 VOL=SMSXD0 ACC=UPDATE DSN=SYS4.DB.T001.ABC562.VSAM
TSS7221E Dataset Not Accessible - SYS4.DB.T001.ABC562.VSAM    

Should we be concerned that we could rename the CXX entry without a security error?

Environment

Component : DATACOM/DB

Component : DATACOM/AD

Resolution

This is not necessarily an error, and there is a fairly simple explanation.

First, the CXXMAINT command changes the value of a field in the CXX from some text to some other text. There is no validation at this point since the database is not opened along with the change. As an example, if a database file is being renamed, the CXXMAINT could be run to set the new name before the actual z/OS catalog rename. For another example, a MUF could be cloned to a new MUF, and the CXX entries could be renamed this way even if there are no database files yet (they could be defined and initialized in a subsequent job).

As a result, in your situation, you changed the DSN value to the invalid name, and in fact, if the name were totally wrong–such as a node longer than 8 chars–it would still be accepted, as it is a text value change within the DSN length of 44 chars.

Next, the CXX report would also work, as it is issuing a z/OS catalog lookup to get the volume and allocation information. The rest of the info is in the CXX file itself.

Finally, when you opened the file in the MUF, Top Secret got involved to qualify the UPDATE request, and the MUF ACID did not have the appropriate access to this particular file. 

All in all, this is more of an inconvenience than a problem, as you would not learn of the error until you try to use the file, instead of when you ran the CXXMAINT. In this case, you were protected because you were not authorized to open the file. If you were authorized and the file was not there because of the typo, you would have received an error message like "DYNAMIC ALLOCATION FAILED, RC=4, ERROR CODE=X'1708'" with RC 74(081).

Additional Information

As always, please contact Broadcom support for Datacom if you have further questions.