SRT4C.BWR -- Beware file for SORT V4C
June 1981






























COPYRIGHT (C) 1981 BY
DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.


THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND  COPIED
ONLY  IN  ACCORDANCE  WITH  THE  TERMS  OF  SUCH  LICENSE AND WITH THE
INCLUSION OF THE ABOVE COPYRIGHT NOTICE.  THIS SOFTWARE OR  ANY  OTHER
COPIES  THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE  IS  HEREBY
TRANSFERRED.

THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE  WITHOUT  NOTICE
AND  SHOULD  NOT  BE  CONSTRUED  AS  A COMMITMENT BY DIGITAL EQUIPMENT
CORPORATION.

DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR  RELIABILITY  OF  ITS
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.

SRT4C.BWR -- Beware file for SORT V4C                           Page 2


The following is a problem in Release 4.

SORT may be unable to sort VERY large files.

It will fail with ?DEVICE OR DATA ERROR.

This is caused by SORT trying to open 52 large  temporary  files.   If
these  files  are larger than 512 pages then TOPS-20 requires that the
SUPERINDEX page of each large  file  be  resident  in  the  JSB.   The
problem  is  that  the  JSB  is not large enough to hold 52 SUPERINDEX
pages.

We believe that this is a monitor problem that should be  fixed  in  a
future release.  Until then there are three possible solutions:

1. This solution will only work with stand-alone or FORTRAN  SORT,  it
will  not work with COBOL SORT.  Use the new switch /MAX-TEMP-FILES to
limit the number of temporary work files to 15.

2. Rebuild the monitor with a bigger JSB.  This might not be  possible
in all cases.  To do this:

In STG.MAC change the definition of NJSBPG from 50 decimal to  say  75
decimal  and  rebuild.   If  you  have  enough  space there will be no
problem, if not you will get an overlap error during loading.

3. The other solution is to change SORT to use less  temporary  files.
While  this  will always work it will result in worse performance even
for files that do not have this problem.

The fix is:  in SRTPRM.MAC change the definition of MX.TMP from 26  to
15.



[END OF SRT4C.BWR]