Hi. I have started SMFQ recently in our test systems in order to avoid incidents we had in the past with enqueues between CATALOG address space and TMC/AUDIT while update is done on TMC/AUDIT etc.
I noticed this week that I got a lot of TMSSMF04W messages for different tapes/datasets.
Honestly I can't determine why someone tried to do this, I got hundreds of TMSSMF04W messages, and for my understanding it was basically a tentative to catalog a Nth file on single file tapes
My question is: Is this is related to SMFQ implementation ?
Some of the Messages:
TMSSMF04W FILESEQ > 1 AND NO DSNBS TMSSMF30I VOL=Z07329, FSEQ=00014, DSN=xxxx.xxxxx.xxxxx TMSSMF04W FILESEQ > 1 AND NO DSNBS TMSSMF30I VOL=Z20951, FSEQ=00014, DSN=yyyy.yyyyyy.yyyyy TMSSMF04W FILESEQ > 1 AND NO DSNBS TMSSMF30I VOL=Z21523, FSEQ=00014, DSN=zzzz.zzzzz.zzzzz TMSSMF04W FILESEQ > 1 AND NO DSNBS
Thanks in Advance
The TMSSMF04W message is produced when you try to CATALOG a data set and there is no corresponding DSNB in the TMC for that volume. This could happen if someone uses IDCAMS after the creating job is finished and tries to CATALOG the data sets even though they were not created. It could also happen if you code the JCL incorrectly and CATALOG the data set even if the job abends and has possibly not opened the file. (IE: DISP=(NEW,CATALOG,CATALOG)
Carolyn Ray CA 1 support
This also may occur when you attempt to un-catalog a file and the job doing the un-catalog is not TMSCLEAN itself. Since the attempt to update the TMC is now being done in the SMFQ subtask instead of the CATALOG address space, we can't tell it came from TMSCLEAN without relying on the audit flag (which is not something we can rely upon). However, this is corrected with RO99657. With RO99657 applied, an attempt to un-catalog a secondary file when the volume record has no secondary files and is currently in scratch status will NOT generate the TMSSMF04W and TMSSMF30I messages you are seeing.