Conference vaxaxp::vmsnotes

    I'm not quite sure about the terms you use I have to admit, but if you
    have no files with more than 7 extents it is difficult to see why you
    are getting *any* window turns at all.
    
    What do you mean by 'with high window turns, some of which can be set
    using the maxfile size / 65000 to determine what the setting should
    be.' ?
    
    The setting of what ? which tool ?

How do you know the window turns are from the system disk?  VMS only 
reports window turns on a system wide basis and not on a per volume basis.  
If you are getting this from a PSPA report then you have misunderstood the 
evidence (which is very easy in the window turn rule).

Jilly

    Window turns do not only occur on fragmented files, they can also
    occur on large contiguous files.
    
    Refer to the following stars article for more details on window turns.
    
    [OpenVMS] Why Are Window Turns Seen on Contiguous Files?    
    
    Mark Lowenberg
    Silver Support/Colorado CSC
    
    

Re .-1

That's only for systems prior to V6.0. And since .0 talks about V6.2 that does 
not seem to be the issue here.

Jur.

    Thanks for your replies on this, yes I have probably misunderstood, but
    I was trying to get it clear in my head.  I will read the article that
    you suggest on contiguous files.  The information I was reading was
    from the daily analysis report from PSPA.  The following is an extract
    
              Window turns may be seen even on contiguous  files,  if
              they  are larger than 458745 blocks (on a disk with the
              default number (7) of mapping pointers per window).  To
              prevent  this,  you  need  to  increase  the  number of
              mapping pointers in the window  (to  the  maximum  file
              size  (in  blocks) divided by 65000), which may be done
              system-wide, on a disk-by-disk basis, or  for  specific
              files.
    
    
    -------------------------------------------------- -------------
    Volume with  VolAvg Proc.                           Split Window    
    Time of
    highest IO/s  IO/s  IO/s   Username     Imagename   IO/s  Turn/s  
    Occurrence
    ------------ ------ ---- ------------ ------------ ------ ------
    ---------------
    VAXVMS062     16.75   25 GA5          SFRUS001       0.36  22.74 24-FEB
    09:24:00
       Top I/O file on volume: VAXCRTL.EXE;13
    
    VAXVMS062      7.38   26 GA5          SFRUS001       3.32  16.04 24-FEB
    09:26:00
       Top I/O file on volume: SETP0.EXE;1
    
    VAXVMS062     11.59   37 GD7          SFRUT021       0.17  16.06 24-FEB
    09:28:00
       Top I/O file on volume: LOGINOUT.EXE;2
    
    VAXVMS062     14.95   42 GD7          SFRUT021       0.22  22.08 24-FEB
    09:30:00
       Top I/O file on volume: VAXCRTL.EXE;13
    VAXVMS062     14.95   42 GD7          SFRUT021       0.22  22.08 24-FEB
    09:30:00
       Top I/O file on volume: VAXCRTL.EXE;13
    
    VAXVMS062     22.03   27 GA5          SFRUS001       0.37  30.72 24-FEB
    09:32:00
       Top I/O file on volume: DNS$CACHE.0000000019;1
    
    VAXVMS062     18.17   27 GA5          SFRUS001       0.17  25.46 24-FEB
    09:34:00
       Top I/O file on volume: No Hot Files
    
    VAXVMS062     11.16   28 GA5          SFRUS001       0.25  24.36 24-FEB
    09:36:00
       Top I/O file on volume: No Hot Files
    
    VAXVMS062      9.47   39 GB7          SFRUT021       0.22  21.34 24-FEB
    09:38:01
       Top I/O file on volume: No Hot Files
    
    VAXVMS062     17.36   25 GA5          SFRUS001       0.36  23.49 24-FEB
    09:56:00
       Top I/O file on volume: No Hot Files
    
    VAXVMS062     12.82   34 GA5          SFRUS001       0.19  13.03 24-FEB
    09:58:00
       Top I/O file on volume: No Hot Files
    
    
    SFRUS001 is a installed image for the application.
                                                      

    hmmmm
    
    I'm not close to a docset or a RESD$, but firstly at .4 says the window
    turn on contiguous files was pre 6.0 so isn't an issue.  I'll let
    others correct me (its been too long), but it is interesting that there
    are a lot of images in this, and that images once activated *never*
    window turn (ditto sections).  Could you just be seeing frequent
    activation and the cathedral window IO$_ACPCNTRL call being registered
    as a window turn ?
    
    SWAG: What happens if you install (say) VAXCRTL/header/share?

Yep you have misunderstood the evidence.  PSPA knows that window turns have 
to be caused by disk IO but it also knows that cannot determine which 
file/disk these are happening on.  So it does the 'next best logical thing' 
and reports the highest disk IO user and the highest IO volume as well as 
the *system wide* window turns and split IO.  You *must* not relate the 
window turns to the user & volume reported, they have no connection.  This 
is a frequent customer call at the CSC but I have no idea how they could 
change the evidence given the restraints of 80 columns.  I always advise 
customers to ignore the highest IO user & volume and just go over all the 
disks looking for files that could cause window turns.

Jilly

    re .0
    
    Note therefore that PSPA is outputting an incorrect message (regarding
    large contiguous files). If we still own PSPA, could the base noter beat
    up the relevant group (formally)?

We do not own PSPA. CA does.  Use their web page at www.cai.com.