Well, this has been an interesting day.  One of our commands to copy files into production failed to copy a critical file because the output disk was too full to handle the file.

We've been using a "DISKSIZE EXEC" for years (posted to the post a long time ago) to determine the number of blocks a CMS file really uses, including the CMS pointer blocks.  But somewhere along the line, the algorithm seems to have changed.  

The heart of DISKSIZE EXEC computed:
---<snip>---
dblocks = totsize%blocksize /* Total number of data blocks req'd */
If totsize//blocksize > 0 then dblocks = dblocks+1                                              
                                                                   
mapped = blocksize/4     /* # of blks mapped by a single ptr blk */
                                                                   
/* Calculate the number of pointer levels required */              
Do i=0 by 1                                                        
   If mapped**i >= dblocks then Leave                              
End                                                                
                                                                   
/* Calculate the number of level 1 pointer blks required, if any */
pblocks=0                                                          
If i>0 then                                                        
   Do                                                              
     pblocks = dblocks%mapped                                      
     If dblocks//mapped>0 then pblocks = pblocks+1                  
   End                                                              
                                                                   
/* Add the number of pointer blks req'd for level 2 & greater!!! */
If i>1 then                                                        
   Do j=0 to i-2                                                    
     pblocks = pblocks + mapped**j                                  
   End                                                              
                                                                   
tot=dblocks+pblocks      
---<snip>---                                        

That formula no longer works reliably, and I have not (yet) found a recent copy of the old "CMS Diagnosis Guide" which explained the CMS File System overhead.  The file in particular is:
Filename Filetype Fm Format Lrecl    Records     Blocks   Date     Time  
xxxxxxxx xxxxxxxx  B2 V        242      37884       2256  6/19/06  2:22:45

"PIPE < xxxxxxxx xxxxxxxx B | count bytes | cons" displays: 9163140

Running 9163140 through the above formula yields: 2242 or 2243 (Total blocks, depending on of the byte count or the LRECL and number of records is supplied to DISKSIZE).  Rather short of what LISTFILE reports for even data blocks, much less the pointer blocks.

Copying the file to SFS and issuing a "Q BLOCKS xxxxxxxx xxxxxxxx fm" yields: 2256 data blocks (in agreement with LISTFILE) and 8 system (pointer) blocks.

Did something change in CMS since the 20030724 date on my trusty old DISKSIZE EXEC?  

Thanks in advance.

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.


 
The information contained in this e-mail and any accompanying documents 
may contain information that is confidential or otherwise protected 
from disclosure. If you are not the intended recipient of this message, 
or if this message has been addressed to you in error, please 
immediately alert the sender by reply e-mail and then delete this message, 
including any attachments. Any dissemination, distribution or other use of 
the contents of this message by anyone other than the intended recipient 
is strictly prohibited.

Reply via email to