ADSM-L

APAR IC36566 for MVS Server 5.1.7???

2003-09-16 15:00:43
Subject: APAR IC36566 for MVS Server 5.1.7???
From: Shannon Bach <SBach AT MGE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 16 Sep 2003 13:44:56 -0500

I have 2 questions I cannot find the answer for and I was hoping someone on the list could lead me in the right direction.
My environment;
TSM Sever 4.2.2    MVS OS/390 2.10
2 TSM NW6 Client's 5.1.6.0

1.  The first is that I have recently started doing Backup Sets on a few clients(listed above) instead of Archive's.  Everything went fine but I started noticing the following error in the TSM Server activity log;
ANR9999D ICVOLHST(4792): ThreadId<280> Error Writing to output File.            
ANR4510E Server could not write sequential volume history information to 'ADSM.PRT.FILE'.    

The 'ADSM.PRT.FILE' is one of 2 volhist files I have defined in the TSM Server Options file.  This one is defined as;
Data Set Name  . . . : ADSM.PRT.FILE
General Data                        
Volume serial . . . : MVSXXX        
Device type . . . . : 3390          
Organization  . . . : PS            
Record format . . . : FBA          
Record length . . . : 133          
Block size  . . . . : 13566  
This is what I use for printing a hard copy of the VOLHIST to take offsite once a week.  Everytime the Volume History file changes, this file automatically gets updated.   I also have another file called ADSM.VOLUME.HIST01defined as;
Data Set Name  . . . : ADSM.VOLUME.HIST01
General Data                        
 Volume serial . . . : MVSXXX        
 Device type . . . . : 3390        
 Organization  . . . : PS              
 Record format . . . : VB              
 Record length . . . : 1028            
 Block size  . . . . : 6144        

This is also a VOLHIST file that gets updated every time there is a change but this one is defined so that MVS would be able to read it in if we were to lose a Disk Volume.  I should mention we do Full Volume Backups of all our MVS Disk Volumes every evening after the TSM client backups are done.   When I looked in the ADSM.PRT.FILE after discovering the above error I find the following;

  2003/09/12 02:53:25  STGNEW              0      0      0 CART3590                       101060                                    
  2003/09/12 02:53:29  STGNEW              0      0      0 CART3590                       101037                                    
  2003/09/12 03:32:57  STGNEW              0      0      0 CART3590                       100778                                    
  2003/09/12 03:47:19  STGNEW              0      0      0 CART3590                       100753                                    
  2003/09/12 04:08:24  STGNEW              0      0      0 CART3590                       100998                                    
 * generate backupset ENGSNDS ENGSNDS_BACKUPSET SCRATCH=YES DEVCLASS=CART3590 RETENTION=9999 DESC="Create Backupset for ENGSNDS to r
**************************************** Bottom of Data**********************************************

For some reason TSM is putting the 'Generate Backupset' command line in the Volume History print file.  The next time the VOLHIST changed it could no longer write ADSM.PRT.FILE.  I deleted the last line and everything was fine again until I issued another Generate Backupset for a different Node client.  Again I noticed the errors and the exact same thing happened, the print VOLHIST file was updated with the command while the disk file was not.  Does anyone know how or what would cause this?  If I continue with Generating Backupsets, I will have to get rid of the ADSM.PRT.FILE and will not be able to print a hard copy for OFFSITE.  Besides that, it is just plain strange!  

2.  This one is for MVS'ers who are at TSM Server 5.1.7.  I cannot get the Mainframe system programmer to upgrade my TSM Server because of one APAR IC36566 in which he got the following email response from his IBM Support person;

"Action taken: Hi Bruce,                                                  
It is Boris, I came back from vacation and will take back the pmr. The update from developer is "IC36566 is ready in 5.1.8 and 5.2.1.  I  will go ahead sysroute it for MVS." I don''t see the APAR is updated or new one opened yet but they are aware that all platforms are effected. I checked when these release will be out for MVS and the timeframe is October.                                      
Let me know if you have more concerns.                                  
Thanks, Boris                                                          
Action plan: Waiting for feedback."                                      

The system programmer will not put in the new version until he gets a fix PTF for MVS, and I haven't even heard of any other MVSer's having problems with this APAR in the first place.  Trying to find something on APAR IC36566 at IBM website is quite a trick, so far I have seen nothing that connects it to the MVS TSM server.  In the meantime our department is getting charged by IBM for having 2 versions of TSM Server for MVS(4.2.2 plus 5.1.7) even though we are still only using 4.2.2, and we are paying maintenance for 5.1.7 even though we aren't supported because we are still on 4.2.2.  I have been ready for months to upgrade, all the clients are at the 5.1.6 level, I even had a small test environment on our OS/390 that I was able to do a small amount of testing on.  Has anyone heard of this APAR affecting an MVS OS/390 TSM Server?  If anyone has any news what-s-ever I would greatly appreciate it if you would let me k now.  The way things are going TSM 5.1 will be off support before we even get there!  

Thank You,
Shannon Bach

Madison Gas & Electric Co.
Operations Analyst - Data Center Services
Office 608-252-7260
Fax 608-252-7098
e-mail sbach AT mge DOT com