CA 1 Flexible Storage

 View Only
  • 1.  CTS and TMSSMF04W messages

    Posted Apr 03, 2018 03:09 PM

    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



  • 2.  Re: CTS and TMSSMF04W messages
    Best Answer

    Posted Apr 03, 2018 04:02 PM

    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



  • 3.  Re: CTS and TMSSMF04W messages

    Posted Apr 03, 2018 06:14 PM

    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.