Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
srtv4c.d05
There is 1 other file named srtv4c.d05 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR SORT-10-V4C
EDIT 472 FOR SORT
*DUMMY TEXT*
********************************************************************************
EDIT 473 FOR SORT
*DUMMY TEXT*
********************************************************************************
EDIT 474 FOR SORT
*DUMMY TEXT*
********************************************************************************
EDIT 475 FOR SORT
*DUMMY TEXT*
********************************************************************************
EDIT 476 FOR SORT
*DUMMY TEXT*
********************************************************************************
EDIT 477 FOR SORT
*DUMMY TEXT*
********************************************************************************
EDIT 500 FOR SORT
*DUMMY TEXT*
********************************************************************************
EDIT 501 FOR SORT
[SYMPTOM]
SORT gets an Illegal memory reference when outputing to a blocked
sixbit file.
[DIAGNOSIS]
A test to determine if a BLT is necessary to clear some memory
locations was erroneous. This sometimes resulted in an attempt to
clear locations in a non-existant page.
[CURE]
Correct the test to determine if the BLT is necessary by changing
the CAML to a CAMLE in the routine CLRBLK in SORT.MAC.
********************************************************************************
EDIT 502 FOR SORT
[SYMPTOM]
The "QUOTA EXCEEDED OR DISK FULL" message given from BADMAP has a
severity character of "%" for interactive users and "$" for batch
users.
[DIAGNOSIS]
The change above was made for the users convience so that a long
running batch job could be continued by the operator instead of
being canceled. Apparently, this was not desired by the users.
[CURE]
Take the code to allow the operator to continue the job out and
make the error fatal (but continuable) again.
********************************************************************************
EDIT 503 FOR SORT
[SYMPTOM]
SORT V4C doesn't seem to respect physical memory limits when called
from FORTRAN V6. A program which SORTs a large file goes virtual
when it shouldn't.
[DIAGNOSIS]
FOROTS V6 allocates some area above the OTS. When SORT calculates
the amount of memory in use, this area is not reflected in .JBHRL
because FOROTS garbages this location. This causes the calculation
to be incorrect and thus results in the behavior described above.
[CURE]
Have SORT calculate the amount of memory in use by looping through
memory doing a PAGE. UUO to determine if each page exists. This
is necessary because of the way in which FORTRAN's memory
management was changed. Also, clean up the code in SORT.
********************************************************************************
EDIT 504 FOR SORT
[SYMPTOM]
If a long command is given in a FORTRAN SORT(FSORT) call which uses
a "/COLLATE:FILE:file" switch, one can get the message:
"?SCNUOP Unmatched open parenthesis".
[DIAGNOSIS]
In routine COLEFS, in module SRTSCN.MAC, where the just parsed
"/COLLATE:FILE:file-spec" is moved from SCAN's internal buffer to
SORT's internal buffer, the EXCHange loop is too long resulting in
SCAN's confusion.
[CURE]
Specify the correct length for the EXCHange.
********************************************************************************
EDIT 505 FOR SORT
[SYMPTOM]
When the error message at VLDERR("Quota exceeded or disk full") is
given, the user may not know which area and structure is causing
the problem.
[DIAGNOSIS]
The user should be told which area and structure is causing the
problem.
[CURE]
Make the error message include the full file specification of the
file that was being output. Also, make the error message a sort
error message. Document the message "?SRTQEF".
********************************************************************************
EDIT 506 FOR SORT
[SYMPTOM]
When several keys of different types are specified in the command
line to SORT, you can get ?SCNDSI error.
[DIAGNOSIS]
SORT correctly clears the bits in the value word, MODE, however it
does not clear the bits in the mask word, MODEM.
[CURE]
Clear the offending bits.
********************************************************************************
EDIT 507 FOR SORT
[SYMPTOM]
When more than one SORT is done during an invocation of the
utility, it is possible that some bit 35's can be on in an ASCII
output file.
[DIAGNOSIS]
SORT writes .TMP files that include count words. It is possible
that when a subsequent SORT is done, some of the memory that was
used for the .TMP files will be allocated for the buffer which will
hold records of the current file being SORTed. This memory has not
been cleared. However, this is a problem only if the conditions
listed above have occurred, and the current buffer happens to
overlap a location that contains an odd number in a count word for
the previous .TMP files. Under these circumstances, the last
bit(35) would be left on and would be written to the output file
because the data is transfered to that location by an EXTEND MOVSLJ
instruction which zero fills bytes. However, since this
instruction deals with seven-bit bytes, and bit 35 does not fall in
a byte, it will not be zeroed.
[CURE]
Clear the buffers for data records when they are allocated.
********************************************************************************
EDIT 510 FOR SORT
[SYMPTOM]
On TOPS-10, SORT can create output files with strange attributes.
[DIAGNOSIS]
The problem is that some locations in the extended ENTER block for
the output file are not set for each SORT unless they reflect
non-default status.
[CURE]
Correctly set the locations in the ENTER block for the output file.
********************************************************************************
EDIT 511 FOR SORT
[SYMPTOM]
Various bugs with /KEY:m,n,FORMAT:nPaw.d. 1) Unsigned is allowed
but does not work. 2) If last part of record is nnn.nnE+1<null>,
in fixed format, rather than E+01, the result is wrong. 3) If the
middle part of the record is E+1<blank><blank>, the result may be
wrong. 4) On TOPS-20, e+01 is rejected. 5) Fixed size (i.e.
D12.3) does not give an error if an illegal character is
encountered in the 12 characters.
[DIAGNOSIS]
1) Unsigned FORTRAN format is not implemented. 2) Null becomes an
illegal character. No warning is given (see error 5), and the
result is set to zero. 3) In fixed format, a blank is treated as a
zero except for the final one which, by error, is treated like a
null in free format. 4) There is no test for lower case. 5) There
is no error message generated.
[CURE]
1) Implement UNSIGNED. Set a flag before calling FLIRT and do not
convert to negative if a minus sign is seen. 2) and 3) Implement
FORTRAN BZ and BN formats. Syntax is FORMAT:BZD12.3 or BND12.3
etc. BZ is the default and treats all spaces as zeroes. BN treats
all spaces as nulls which end the format just as if free format.
FORTRAN V6 does this. Warning now, E+1<blank> is not equal to E+01
unless BN is set. 4)Test for lower case before converting to
SIXBIT. 5) Give a warning if an illegal character (not a null) is
seen.
********************************************************************************
EDIT 512 FOR SORT
[SYMPTOM]
When the /COLLATE:FILE:file-spec switch is specified, you can get
strange SCAN error messages.
[DIAGNOSIS]
The procedure in SORT which handles the /COLLATE:FILE:file-name
switch, COLEFS, stores the block of information pertaining to the
collating file incorrectly. When storing this information, the
routine starts at the wrong location and goes past the bounds of
the block. This results in the trashing of some of SCAN's flags.
These errors cause SCAN to become confused and produce erroneous
errors.
[CURE]
Apply Edit 504 which sets the correct length of the blocks to be
swapped. Apply this edit (512) which fixes off by one bugs in the
loop which swaps the information from SCAN's F.xxx block to SORT's
S.xxx block.
********************************************************************************
END OF SORT-10-V4C