Google
 

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