I think I have the answer since I have seen and addressed this before.

The problem is the physical size/allocation of the file on the MVS system.
I bet if you check the logs of the ADSM/TSM started task around the time
of the failure, you will see an SB37/D37 abend due to the size of the
VOLHIST (in your case - ADSM.PRT.FILE) file either being too small, no extents 
defined or already at
16-extents.

What I did was to pre-allocate the file, much much larger then what is at
when the failure occured.

Also, after doing some RTFM, I realize I wasn't doing any pruning of
STGDEL/ADD/etc and had entries that went back to 1996. Deleted over 15000
entries and the file is much smaller now.





Shannon Bach <SBach AT MGE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/16/2003 02:44 PM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        APAR IC36566 for MVS Server 5.1.7???



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