*COMDECK,HISTORY *L470*    ************************************************************* *L470* 
 AM2A096  AAM 2.0                                                        AM2A096
          CODE INTRODUCED AT I6J TO HANDLE SPECIAL RECORD TYPE IS        AM2A096
          INCOMPLETE AND INACCURATE.  CODE IS NOW ADDED TO CORRECT THIS  AM2A096
          PROBLEM.                                                       AM2A096
          RPN    1/6/78      AAMDCTL                                     AM2A096
 AM2A077A AAM 2.0                                                        AM2A077
          MORE IMS CHANGES.                                              AM2A077
          JJJ    12/20/77    AAMDAA,OPENDAA,ISDIS,ISDRARE                AM2A077
                             MIPDMIP,MPGNDMP,SEEKDIS,SEEKDMP,AAMDCTL     AM2A077
                             CMPRD01,CRA1DAA,MISCDAA,OPNMDAA             AM2A077
                                                                         AM2A077
 AM2A094  AAM 2.0                                                        AM2A094
          UNDO PSR AM2A081 - MAKE REL IN FIT EFFECTIVE ONLY ON STARTS.   AM2A094
          AFRB   01/04/78          MIPDMIP                               AM2A094
                                                                         AM2A094
 AM2A099  AAM 2.0                                                        AM2A099
          FLUSH CAN ALTER THE LEVEL AT WHICH A MIP FILE IS               AM2A099
          POSITIONED FROM 2 OR 3 BACK TO 1, AND THIS INVALIDATES THE     AM2A099
          PARTIAL POSITIONING THAT MAY HAVE BEEN DONE BY SEEK(ALTKEY)    AM2A099
          OR GETNR(ALTKEY). WE MUST SET FAALTPOS = 1 WHEN FLUSHING A     AM2A099
          MIP FILE TO FORCE THOSE OPERATIONS TO START AFRESH FROM THE    AM2A099
          SAVED KEY VALUES.                                              AM2A099
          AFRB   1/11/78     AAMDAA                                      AM2A099
                                                                         AM2A099
 AM2A088  AAM 2.0                                                        AM2A088
          A GETNEXT-WITHOUT-RECALL, BY PRIMARY OR ALTERNATE KEY, MAY     AM2A088
          IF IT DOES NOT COMPLETE, LEAVE THE PTREE IN A STATE SUCH       AM2A088
          THAT A FOLLOWING GETNEXT WITH RECALL WOULD ERR BY USING        AM2A088
          IT. GETNEXT-WITHOUT-RECALL MUST SET THE FASKLAST FLAG IN THE   AM2A088
          FIAT TO 1 BEFORE DOING THIS, AND RESET IT TO 0 AFTER THE       AM2A088
          PTREE IS ONCE MORE IN A RELIABLE STATE.                        AM2A088
          AFRB   1/16/78     AAMDAA,SEEKDIS,SEEKDMP                      AM2A088
                                                                         AM2A088
 AM2A089  AAM 2.0                                                        AM2A089
          THE FOLLOWING SECTION OF CODE ADDRESSES THE GENERAL AAM 2.0    AM2A089
          PERFORMANCE PROBLEM.                                           AM2A089
          SUBROUTINE DNLV$MP DESCENDS FROM A RECORD IN A LEVEL-2         AM2A089
          SUBFILE TO THE FIRST RECORD OF THE DEPENDENT LEVEL-3           AM2A089
          SUBFILE. SOMETIMES THIS IS A GREAT WASTE OF TIME -- WHEN THE   AM2A089
          NEXT ACTION WILL BE TO LOCATE BY KEY IN THE LEVEL-3            AM2A089
          SUBFILE, IT IS ENOUGH TO GO TO LEVEL 3 WITHOUT CALLING         AM2A089
          GOSTARTFILE TO MAKE THE FIRST RECORD CURRENT. SO WE            AM2A089
          INTRODUCE HERE A PARAMETER FOR DNLV$MP, SO THAT IT CAN         AM2A089
          BE CALLED EITHER WAY, AND MODIFY ALL THE DNLV$MP               AM2A089
          CALLS ACCORDINGLY.                                             AM2A089
          AFRB   01/25/78    MIPDMIP,NRODMIP,SEEKDMP                     AM2A089
                                                                         AM2A089
          CURRENTLY IN MIPGEN, AFTER THE OPENM CALLS, THERE ARE NO       AM2A089
          OTHER CRM CALLS THAT WILL TRIGGER THE UNLOADING OF AAM OPEN    AM2A089
          AND KEYDEF CAPSULES.  THIS TIES UP A LOT OF CM, RESULTING      AM2A089
          IN POORER PERFORMANCE BY SORT.  A REWIND CALL IS NOW INCLUDED  AM2A089
          AFTER THE OPEN CALLS TO CORRECT THIS PROBLEM.                  AM2A089
          RPN    1/27/78     MIPGEN                                      AM2A089
                                                                         AM2A089
          AN AREA OF HIGH CP USAGE IN AAM 2.0 IS THE BINARY SEARCH       AM2A089
          ROUTINE.  THIS ROUTINE IS CURRENTLY CODED IN SYMPL.  BY        AM2A089
          RECODING IT IN COMPASS, AND DOING SOME OF THE COMPARE WORK     AM2A089
          IN LINE RATHER THAN CALLING THE KEY COMPARE MODULE,  CP TIME   AM2A089
          IS REDUCED BY ABOUT 10 PERCENT.                                AM2A089
          AFBROWN  01/20/78  MISCDAA,ISDIS,MIPDMIP,NRODMIP               AM2A089
                                                                         AM2A089
 AM2A091  AAM 2.0                                                        AM2A091
          DURING REPRIEVE, AAM 2.0 WILL ATTEMPT TO FLUSH ALL THE AAM     AM2A091
          EXTENDED FILES THAT ARE IN THE LIST OF FILES.  IT TREATS ALL   AM2A091
          THE ENTRIES IN THAT LIST AS FIT ENTRIES.  THIS IS NOT CORRECT  AM2A091
          AS THE LIST OF FILES WERE INTENED FOR LIST OF FETS, ALTHOUGH   AM2A091
          CRM HAS TAKEN ADVANTAGE OF THE LIST.  A CHECK SHOULD BE MADE   AM2A091
          TO ENSURE THAT THE ENTRY BEING EXAMINED IS INDEED AN FIT       AM2A091
          BEFORE FLUSH PROCEEDS, OR MODE ERRORS WILL RESULT.             AM2A091
          RPN    01/18/78    AAMDAA,AAMDEFS,AAMFITDCL                    AM2A091
                                                                         AM2A091
 AM2A095  AAM 2.0                                                        AM2A095
          A CLOSE ACTION DOES NOT CAUSE OUR CMM SPACE TARGET TO          AM2A095
          BE RECALCULATED UNLESS IT CLOSES THE ONLY REMAINING FIT        AM2A095
          FOR THE GIVEN FILE. THIS MUST BE CHANGED, BECAUSE              AM2A095
          LOADING THE CLOSE CAPSULE MAY PUSH THE TARGET AWAY DOWN,       AM2A095
          AND IF THERE IS NO RECALCULATION OF TARGET AT THE END OF       AM2A095
          THE CLOSE, WE USE VERY FEW BUFFERS EVEN WHEN THERE IS FREE     AM2A095
          SPACE.                                                         AM2A095
          AFRB   01/12/78    OPENDAA                                     AM2A095
                                                                         AM2A095
          ALSO AS AN EXTENSION TO AM2A095                                AM2A095
          A BLOCK IMAGE MAY CONTAIN A POINTER TO A PTREE WORD, AND       AM2A095
          IF THE BLOCK IS TO BE KICKED OUT WE MUST MAKE SURE THE PTREE   AM2A095
          WORD NO LONGER POINTS TO THE BLOCK. BUT THE PTREE MAY          AM2A095
          HAVE ALREADY BEEN DISCARDED, AND ITS ADDRESS MAY LIE           AM2A095
          BEYOND FL. SO IN SUBROUTINE UNPTREE, IN AAM$AA, WE HAVE        AM2A095
          TO FIND FL. RA+65 CONTAINS THE NEGATIVE OF THE ADDRESS         AM2A095
          OF A WORD CONTAINING THE CURRENT FL, PROVIDED CMM IS           AM2A095
          PRESENT. IF NO CMM, WE NEED NOT KNOW FL BECAUSE THE FILE       AM2A095
          STUFF MUST ALL BE IN ((UBS)) SPACE, WHICH MEANS ONLY ONE       AM2A095
          FIT AND HENCE ONE PTREE TO A FILE, AND IF THE FIT AND PTREE    AM2A095
          HAD PREVIOUSLY BEEN DROPPED, ALL BLOCKS OF THE FILE WOULD      AM2A095
          HAVE BEEN DROPPED AS WELL.                                     AM2A095
          AFRB   01/12/78    AAMDAA                                      AM2A095
 AM2A098  (AAM 2.0 PL)                                                   AM2A098
          REPLACE "SA1 -1" BY "ABORT" MACRO CALL IN FLBLOK.              AM2A098
          GAG    01/31/78    FLBLOCKK                                    AM2A098
                                                                         AM2A098
 *L477*    **************************************************** 
 AM2A119  AAM 2.0 
          THE INSTRUCTION MODIFICATION CODE INVOLVED IN AAM 2.0 TO
          HANDLE CONDITIONAL JUMPS BASED ON WHETHER CAPSULE IS LOADED 
          FAILS ON CY 176 AND 76 MACHINES DUE TO THE INSTRUCTION STACK
          NOT BEING CLEARED BY JP.  DUMMY RJS ARE NEEDED TO ENSURE
          CODE WORKING PROPERLY.
          RPN    02/08/78          AAMDCTL,EXECDIS,MISCDAA
 AM2A107  (AAM 2 PL)
          CURRENTLY, AFTER A DATA BLOCK HAS BEEN WRITTEN WITHOUT RECALL,
          THE BLOCK IS TAGGED ON TOWARDS THE END OF THE BUFFER KICKOUT
          CHAIN, SINCE IT IS LIKELY THAT THIS BLOCK IS NOT GOING TO BE
          REFERENCED AGAIN.  IT IS, HOWEVER, INSERTED BEFORE THE RARE 
          CAPSULES THAT ARE ON THE KICKOUT CHAIN.  THIS CAUSED THE
          CAPSULES TO BE DROPPED TOO RAPIDLY.  CODE IS NOW CORRECTED
          SO THE DATA BLOCK WILL BE INSERTED INTO THE CHAIN AFTER THE 
          CAPSULES. 
          AFB    02/03/78    AAMDAA 
 AM2A108  (AAM 2 PL)
          A WRITE WITHOUT RECALL IS ISSUED ON A DATA BLOCK WHICH HAS
          BEEN MODIFIED, WHENEVER WE MOVE ON TO SOME OTHER DATA BLOCK.
          (THE MODIFIED BLOCK IS NO LONGER CURRENT).  WHEN THE OPERATION
          ON THE FILE IS CLUSTERED (HOPPING BACK AND FORTH BETWEEN TWO
          BLOCKS), THIS SCHEME FALLS APART.  TO AVOID REWRITING BLOCKS
          OVER TOO MANY TIMES, A FLAG IS SET IN THE BLOCK FRAME TO
          INDICATE THAT THE BLOCK HAS BEEN WRITTEN OUT ONCE.  THIS
          PROHIBITS FURTHER WRITES WITHOUT RECALL ON THE SAME BLOCK.
          (UNLESS THE BLOCK IS KICKED OUT DUE TO SPACE CONSIDERATIONS 
          AND THEN RE-READ BACK IN.)
          AFB    02/14/78    AAMBLOK,AAMDAA 
 AM2A109  (AAM 2 PL)
          IF A DATA FILE IS OPENED WITH MIP, THE PROJECTED CMM USAGE
          (TARGET) IS NOT REACTING TO THE NUMBER OF ALTERNATE KEYS
          DEFINED.  THIS RESULTS IN A POOR SPACE USAGE FOR CREATION 
          JOBS WHERE MANY ALTERNATE KEYS ARE INVOLVED.  THE PROBLEM 
          IS NOW CORRECTED. 
          AFB    02/21/78          NRODIS,OPENDAA 
 AM2A118  (AAM 2 PL)
          A SLIP IN THE ORIGIN CODE CAUSED AN INCORRECT BLOCK SEARCH ON 
          A MIP SUBFILE CONTAINING A FIFO KEY LIST.  NO KEYS IN THIS
          SUBFILE CAN BE LOCATED.  PROBLEM DOES NOT OCCUR IF THE KEY
          LIST IS IN A SUB-BLOCK FOLDED BACK IN AT LEVEL 2. 
          RPN    03/14/78          MIPDMIP
 AM2A123  AAM 2.0 
          WHEN AN IS FILE IS CHANGED FOR THE FIRST TIME, FSOPENFLG IS SE
          TO INDICATE THAT THE FILE IS NO LONGER IN A STABLE STATE. 
          THIS FLAG SHOULD BE RESET AT CLOSE TIME.  BUT CLOSE IS
          GEARING OF THE FSALTFLG, WHICH GET CLEAR WHEN THE FSTT IS 
          WRITTEN OUT.  THE PROBLEM IS NOW CORRECTED BY ALWAYS
          WORKING OFF THE FSOPENFLG.
          RPN    03/25/78          OPENDAA,AAMDAA,ISDRARE,MISCDAA.
 AM2A124  (AAM 2 PL)
          WHEN DOING A DELETE, AAM 2.0 CURRENTLY WILL CALL THE SPECIAL
          RECORD TYPE HANDLING ROUTINE TO COMPUTE THE EFFECTIVE RL EVEN 
          THOUGH IT IS NOT NEEDED.  IF THE WSA IS NOT SET UP WITH GOOD
          INFORMATION (WHICH DELETE DOES NOT NEED), THE CALL CAN FAIL 
          WITH AN RM ERROR 167.  THE PROBELM IS CORRECTED BY CODE 
          GENERATED UNDER THIS PSR IDENT. 
          RPN    03/31/78          AAMDCTL
 AM2A126  (AAM 2 PL)
          GETNEXT WITHOUT RECALL HAS NOT BEEN TAKING ADVANTAGE
          OF THE FACT THAT IF THE FILE AND THE PTREE HAVE NOT 
          BEEN DISTURBED, AND THE CURRENT RECORD IS NOT THE LAST
          IN ITS BLOCK, AND WE ARE GETNEXTING BY PRIMARY KEY, 
          A STRAIGHT GETNEXT WILL GET THE NEXT RECORD WITHOUT AN
          I-O BEING REQUIRED. TO PREVENT THIS WASTE OF CP TIME, 
          THIS NEW CODE DETECTS THE FAVORABLE SITUATION AND LETS
          GETN$IS BE CALLED WHEN POSSIBLE.
          AFRB   04/17/78    SEEKDIS
  
 AM2A128  (AAM 2 PL)
          DURING SEQUENTIAL CREATION, AAM 2.0 WILL ATTEMPT TO INITIALIZE
          WRITE BEHIND ON THE LAST DATA BLOCK THAT HAS BEEN FILLED. 
          THIS PROCESS WILL PROVIDE A HIGH CP/IO OVERLAP, EXCEPT THAT IT
          HAS TO BE INTERRUPTED OCCASIONALLY IF AN INDEX BLOCK HAS TO 
          BE CREATED.  TO SMOOTH OUT THIS TRANSIENT, WE NOW INTRODUCE 
          CODE THAT WILL DO SOME MORE BOOKKEEPING TO ENABLE US TO 
          EXTEND A FILE LOGICALLY BY TWO BLOKS (WE ARE PHYSICALLY 
          CONSTRAINED BY OS TO EXTEND OUR FILE ONE BLOCK AT A TIME).
          THIS CODE WILL HELP OUR GENERAL IMPROVEMENT.
          AFRB   04/18/78    AAMFSTT,AAMDAA,AAMDNRO,OPENDAA,ISDRARE,
                             ISDIS,NRODIS 
 *L485*    *****************************************************
 AM2A130  AAM2.0
          WHEN AND HOW MUCH TO FLUSH A FILE. WHEN A USER CALLS FLUSH
          DIRECTLY, OR EXPLICITLY CLOSES A HEALTHY FILE, FLUSH
          COMPLETELY. BUT WHEN A FATAL ERROR IS FOUND, IT MAY NOT BE
          DESIRABLE TO FLUSH, SINCE THE GOODNESS OF WHAT IS IN CORE IS
          DOUBTFUL. THIS NEW CODE MAKES IT POSSIBLE TO PREVENT ALL
          FLUSHING, BY SETTING A NEW FLAG (FSRUFSTT) IN THE FSTT, OR TO 
          PREVENT ALL FLUSHING EXCEPT THAT OF THE FSTT, BY SETTING
          FSRUINFLG.
          WHEN A USER IS APPARENTLY DOING A CLOSE, BUT THE FATAL
          ERROR FLAG IS SET, WE SHOULDNT FLUSH, BECAUSE THE FILE
          MAY BE CRIPPLED. (A REGULAR CLOSE WITH THE FLAG SET IS
          FORESTALLED BY BAM, BUT WE ARE GOING TO CREATE AN 
          ((ENVIRONMENTAL CALL)) TO AN ENTRY POINT CALLED 
          DRAN$AA, WHICH WILL HAVE THE EFFECT OF CLOSING ONE FILE 
          AS FAR AS RELEASING CM SPACE IS CONCERNED.) SO THIS CODE
          PREVENTS CLOSE FROM FLUSHING IF THE FATAL FLAG IS ON. 
  
          WHEN A FILE PRODUCES A FATAL ERROR, FLUSHING IF ANY 
          SHOULD BE DONE AT THE END OF MSGF$AA, AND NOT BY ANY
          ROUTINE AFTERWARDS. THIS ALLOWS THE DEGREE OF FLUSHING
          TO BE PROPORTIONED TO THE SICKNESS FOUND IN THE FILE. 
          THIS CODE SETS FSRUFSTT BEFORE CALLING MSGF, IF THE ERROR SEEM
          TOO BAD TO ALLOW EVEN THE FSTT TO BE FLUSHED, OR FSRUINFLG, IF
          IT SEEMS TO ALLOW ONLY THE FSTT TO BE FLUSHED SAFELY. 
  
          IF TWO OR MORE FITS ARE ADDRESSING A SINGLE FILE, AND 
          ONE OF THE FITS GETS A FATAL ERROR, ANY LATER CALL
          THROUGH ANOTHER FIT TO THE SAME FILE SHOULD GET A 
          FATAL ERROR. THIS CODE DEFINES A NEW ERROR NUMBER,
          371B, FOR WHICH THE MESSAGE WILL BE ((ANOTHER FIT 
          HAD A FATAL ERROR)). MSGF$AA WILL STORE THIS NUMBER IN
          A NEWLY-DEFINED WORD OF THE FSTT (FSFTERR), HITHERTO
          ZERO. THEN WHENEVER WE BEGIN TO DO AN OPERATION, IN 
          AAM$CTL, THIS WORD IS TESTED FIRST OF ALL, AND IF IT
          IS NON-ZERO THERE IS AN IMMEDIATE EXIT WITH A FATAL 
          ERROR.
          A SIMILAR PROVISION IS MADE FOR THE FACT THAT AN
          UNCORRECTABLE WRITE ERROR MAY OCCUR ON ONE FILE, WHILE
          AN OPERATION ON A DIFFERENT FILE IS BEING PROCESSED. THEREFORE
          SUCH A WRITE ERROR CANT BE ALLOWED TO ABORT THE CURRENT 
          OPERATION AUTOMATICALLY. INSTEAD OF CALLING MSGF$AA RIGHT 
          AWAY, THIS NEW CODE STORES THE ERROR NUMBER IN WORD FSFTERR 
          OF THE FSTT, AND SETS FSRUINFLG.
          IF THE FILE IS THE SAME ONE AS THE CURRENT
          OPERATION IS WORKING ON, MSGF$AA IS CALLED AFTER ALL. IF NOT, 
          THEN MSGF$AA IS CALLED THE FIRST TIME AN OPERATION ON THE 
          GUILTY FILE BEGINS. FSRUINFLG IS CHECKED AT THE BEGINNING 
          OF EVERY CALL TO IOWR$AA TO COVER THE FOLLOWING SORT OF 
          POSSIBILITY -- DURING AN OPERATION ON FILE A, A FATAL WRITE 
          ERROR IS FOUND ON FILE B, WHILE FREEING SPACE. THOUGH NO
          OPERATION ON FILE B TAKES PLACE, THE SAME OR A LATER
          OPERATION ON FILE A OR SOME OTHER FILE MAY TRY TO DO SOME 
          MORE WRITING ON FILE B, STILL FREEING SPACE. THE WRITE ON 
          FILE B SHOULD NOT BE ALLOWED TO HAPPEN IF FSRUINFLG IS NOT 0. 
          INSTEAD, IOWR$AA JUST CLEARS THE ALTERED FLAG ON THE BLOCK
          IMAGE SO THAT THE SPACE CAN BE FREED. 
  
          AFRB   05/04/78    AAMDEFS,AAMFSTT,AAMDAA,AAMDNRO,OPENDAA 
                             SEEKDMP,SEEKDIS,AAMDCTL
 AM2A135  AAM2.0
          OPEN$IS CALLS CMM$FRF TO RETURN SPACE TO CMM. IN 8 PLACES 
          IT MAKES THE CALL FOR AN FSTT SPACE, WITHOUT FIRST ASCERTAININ
          THAT THE SPACE ACTUALLY CAME FROM CMM IN THE FIRST PLACE. 
          AS IT HAPPENS, ALL THESE 8 CALLS TO CMM$FRF ARE NEEDLESS AND
          POSSIBLY HARMFUL, BECAUSE THEY IMMEDIATELY PRECEDE 8 CALLS TO 
          FATERR, AND FATERR ITSELF PROVIDES FOR DROPPING THE FSTT
          SPACE, IF AND ONLY IF THE SPACE CAME FROM CMM.
          AN OBSTACLE TO THE RATIONAL FUNCTIONING OF THE FSTT-
          DROPPING IS THAT THE USERCOUNT (FSUSRCNT) MAY NOT 
          LOOK LIKE 0 WHEN THE FSTT IS FIRST READ IN, BECAUSE IT
          IS NOT CLEARED BEFORE WRITING OUT AN FSTT.
          WE OVERCOME THIS BY MOVING THE FSUSRCNT FIELD TO THE PREFIX 
          OUT OF THE BLOCK PROPER, SO THAT IT IS NEVER WRITTEN TO DISK
          AND CAN BE DEPENDABLY INITIALIZED AT 0. 
          AFRB   05/16/78    OPENDAA,AAMFSTT
  
 AM2A111  (AAM2 PL) 
          UPDATE THE NUMBER OF CIO CALLS IN THE FSTT. 
          KLS    78/06/20    OPENDAA,AAMDAA 
  
          ENSURE FLSTAT PROVIDES INFORMATION REGARDING THE NUMBER OF
          CIO    CALLS MADE.
          THIS CODE IS DEPENDENT OF AM2A111 
          KLS    78/06/20    FLSTAT 
  
 AM2A132  AAM2.0
          FOR PF PERMISSION,WE HAVE BEEN TESTING THE RELEVANT 
          FIELD OF THE FET, WHICH IS PART OF THE FIT. BUT THIS
          REFERS ONLY TO THE DATA FILE, NOT TO ITS POSSIBLE MIP 
          FILE PARTNER. IF BOTH FILES ARE PRESENT, THE PERMISSION 
          REALLY HAS TO BE THE LOGICAL PRODUCT OF THE PERMISSIONS 
          FOR THE TWO FILES.
  
          AFRB   05/01/78    AAMDEFS,OPENDAA
 AM2A137  AAM2.0
          SUBROUTINE STUP$IS COMMITS AN ABSURDITY WHEN STEPPING UP TO TH
          PRIMARY INDEX BLOCK, IF THE BLOCK WE START FROM HAS A BAD 
          PARENT NUMBER. HAVING FOUND THAT THAT IS THE WRONG BLOCK, THE 
          CODE MAY FAIL TO BRING IN THE PRIMARY INDEX BLOCK INSTEAD.
          THIS NEW CODE PREVENTS THAT FAILURE.
          AFRB   08/18/78    ISDIS
  
          ENSURE THE FLBLOK UTILITY PROPERLY HANDLES THE NL,BF,PI,
          AND PD PARAMETERS WHEN SPECIFIED ON THE FLBLOK CONTROL STMT.
          KLS    78/07/31    FLBLOK 
  
 AM2A147  (AAM 2 PL)
          THIS MOD PREVENTS PROCESSING OF ANY -FILE- CONTROL CARD THAT
          MAY BE PRESENT FOR THE CRM FILE.
          KLS    78/08/22    FLSTAT 
  
 AM2A148  (AAM 2 PL)                                                     GAG1103
          RATIONALIZES THE TREATMENT OF SPARSE KEYS IN MIP FILES.        GAG1103
          AFRB   03/09/78    MIPDMIP,MPGNDMP,NRODMIP,UPDTMP,KDEFDMP      GAG1103
                             MIPGEN                                      GAG1103
                                                                         GAG1103
 AM2A151  (AAM 2 PL)                                                     GAG1103
          CORRECT TEXT IN ERROR MSG ISSUED FOR AN ATTEMPTED ALT KEY      GAG1103
          ACCESS WITHOUT MIP FILE SPECIFIED.                             GAG1103
          KLS    78/09/27    LISTCOM                                     GAG1103
                                                                         GAG1103
 AM2A155   AAM 2.0                                                       GAG1103
          SUBROUTINE RLSP$AA ASSUMES DANGEROUSLY THAT P<FSTT$AA>         GAG1103
          POINTS TO THE FSTT OF THE DATA FILE. BUT WE MAY COME TO        GAG1103
          RLSP$AA WITH IT POINTING TO THE FSTT OF THE MIP FILE, FOR      GAG1103
          EXAMPLE WHEN THE MIP FSTT CANT BE READ IN OR IS GARBAGE.       GAG1103
          IN SUCH A CASE, BOTH CALLS TO SUBROUTINE RELEASE ACT ON THE    GAG1103
          MIP FILE, INSTEAD OF ONE BEING FOR THE MIP FILE AND THE        GAG1103
          OTHER FOR THE DATA FILE. THIS MEANS CMM IS CALLED ON TWICE     GAG1103
          TO RELEASE THE SAME PARCEL (THE ONE CONTAINING THE MIP FSTT    GAG1103
          SPACE) AND ALL KINDS OF THINGS HAPPEN WHEN CMM IS ASKED        GAG1103
          TO RELEASE A SPACE THAT IS NOT ASSIGNED.                       GAG1103
               THIS CORRECTION MAKES RLSP$AA INDEPENDENT OF THE          GAG1103
          VALUE THAT HAPPENS TO BE IN P<FSTT$AA>, THOUGH                 GAG1103
          FTMIPFS[0] AND FTFSTT[0] MUST STILL BE EITHER VALID OR 0.      GAG1103
                                                                         GAG1103
          AFRB   10/19/78  OPENDAA                                       GAG1103
 AM20002  (AAM 2 PL)                                                     GAG1103
          WHEN BF NOT SPECIFIED ON FLBLOK CARD, ENSURE THE DEFAULT       GAG1103
          VALUE IS STORED IN "BF".                                       GAG1103
          KLS    78/10/10    FLBLOCKC                                    GAG1103
                                                                         GAG1103
 AM20003  (AAM 2 PL)                                                     GAG1103
          WHEN A GETNEXT IS ACHIEVED BY A SERIES OF GETNEXTS-WITHOUT-    GAG1103
          RECALL, THE GETNEXT COUNT IN THE FSTT SHOULD BE ADVANCED BY    GAG1103
          1, SINCE THE ACTION IS MEANT TO BE LOGICALLY THE SAME AS IF    GAG1103
          A SINGLE GETNEXT OPERATION HAD DONE IT. THIS COUNTING WAS      GAG1103
          OMITTED, AND THE ATTACHED CODE REPAIRS THE OMISSION.           GAG1103
          AFRB   11/1/78       SEEKDIS                                   GAG1103
                                                                         GAG1103
 AM2A157  AAM 2.0                                                        GAG1121
          BLANK FILLING OF LINES WHEN RT=Z IS NOT HANDLED QUITE RIGHT.   GAG1121
          THIS CODE REPAIRS IT. WHEN THE RECORD IS EXACTLY RL CHARACTERS GAG1121
          LONG BUT MRL IS GREATER, EXACTLY MRL-RL BLANKS SHOULD BE ADDED GAG1121
          AT THE END OF THE RECORD IN THE WSA AREA.                      GAG1121
          NOTE HOWEVER THAT IF MRL IS NOT DIVISIBLE BY 10, WE ROUND IT   GAG1121
          UP TO A WORD BOUNDARY. I.E. WE USE ((MRL+9)/10)*10. THIS IS    GAG1121
          IN ACCORDANCE WITH WHAT IS DONE FOR Z RECORDS IN SQ FILES.     GAG1121
          AFRB   11/20/78    AAM$CTL                                     GAG1121
                                                                         GAG1121
 AM2A156  AAM2.0                                                         GAG1129
          IF DABL$AA IS CALLED TO LOCATE A BLOCK THAT IS ALREADY         GAG1129
          IN CORE, AND A READ-AHEAD IS ATTEMPTED BY CALLING              GAG1129
          LOCB$AA(FWD,0), BUT THE FET IS ALREADY BUSY BECAUSE OF A       GAG1129
          SEEK SOMEWHERE ELSE IN THE FILE, LOCB$AA SETS P<BLOK$AA>=0,    GAG1129
          INDICATING NOTHING DONE. THEN IF SUBROUTINE AGE IS CALLED,     GAG1129
          TO MOVE THE LOOK-AHEAD BLOCK TO THE TAIL OF THE KICKOUT        GAG1129
          CHAIN, THE BLOCK POINTER OF 0 CAUSES MODE OUT.                 GAG1129
          AFRB   78/11/14    AAMDAA                                      GAG1129
                                                                         GAG1129
 *L498*    ************************************************ 
 AM2*79   (AAM 2 PL)
          INSERT 1979 COPYRIGHT CODE INTO THE CONTROLLER. 
          GAG    12/27/78    AAMDCTL
  
 AM2A161  (AAM2 PL) 
          RM ERROR 552 (START INVALID FOR AK/DA) IS REDUNDANT.  ISSUE RM
          ERROR 245 (FUNCTION NOT VALID FOR THIS FO) INSTEAD. 
          GAG    12/14/78    AAMDEFS,AKDAK
  
 AM2A162  (AAM2PL)
          MODIFICATIONS TO FLBLOK UTILITY CORRECTING THE FOLLOWING -
               1) OUT OF DATE TITLES AND MESSAGES.
               2) A NEW DEFAULT FOR INDEX PADDING WAS NOT REFLECTED 
                   BY THE UTILITY.
               3) FORMAT PROBLEMS THROUGHOUT. 
          RJC    12/20/78    FLBLOCKF, FLBLOCKC, FLBLOCKK 
  
 AM2A163  AAM2PL
          THE ROUTINE THAT TRANSFERS THE PRIMARY KEYLIST, DURING
          A MIP INDEX-ONLY GETNEXT, HAS TO CHECK FOR THE END OF RANGE 
          BEFORE IT BEGINS TO TRANSFER KEYS.
          AFRB   12/22/78    MWSADMP
  
 AM2A164  (AAM 2 PL)
          WARNING MESSAGE IN CRA1DAA DUE TO ABSENCE OF * FOR COMMENT. 
          GAG    1/2/79      CRA1DAA
  
 AM2A166  (AAM2 PL) 
          THIS IS THE REWRITE OF THE FLBLOK UTILITY - NOTE THAT 
          THAT DECKS FLBLOCKC AND FLBLOCKK WERE PURGED
          RJC   01/23/79
  
 AM2A167  AAM2PL
          A DA OR AK REWIND MAY LEAVE AN EOI FLAG STILL SET, CAUSING
          A FOLLOWING GETNEXT TO FAIL TO GET THE FIRST RECORD.
          THIS CODE CURES IT. 
          AFRB    1/17/79    AKDAK,DADDA,SEEKDIS,SEEKDMP
  
AM2A169    AAM2PL 
          IN ORDER TO DETERMINE WHETHER OR NOT WE ARE LOOKING AT A
          PRIMARY KEY, QUMP$AA MUST BE PASSED A 0 IN ITS PARAMETER IN 
          3 PLACES
          RJC  01/30/78    AKDAK
  
 AM2A171  AAM2PL
          IF MBL IS NOT SPECIFIED WHEN AN AK FILE IS CREATED, THE PLAN
          FOR CHOOSING A BLOCK SIZE NEVER CHOOSES LESS THAN DFTAKBLKSZ=4
          PRUS. IF THE BLOCKING FACTOR AND RECORD SIZE ARE SPECIFIED, 
          THEIR PRODUCT MAY BE MUCH LESS THAN 4 PRUS, AND IF SO, SPACE
          IS WASTED IN EVERY BLOCK. THIS PROBLEM IS PECULIAR TO AK, 
          BECAUSE ONLY IN AK DOES RB, THE BLOCKING FACTOR, HAVE A 
          DEFINITE AND RESTRICTIVE MEANING. 
          THIS NEW CODE PROVIDES THAT --
          (A) IF MBL IS GIVEN BUT RB IS NOT, THEN RB IS SET SO
          THAT RB AVERAGE RECORDS WILL FILL A BLOCK OF THE GIVEN SIZE.
          (B) IF NEITHER MBL NOR RB IS GIVEN, THEN RB IS SET TO THE 
          DEFAULT DFTAKRB=8, UNLESS 8 AVERAGE RECORDS WOULD NOT FILL
          A BLOCK OF 4 PRUS. IN THE LATTER CASE, RB IS SET TO THE 
          NUMBER OF AVERAGE RECORDS NEEDED TO FILL 4 PRUS.
          (C) IF RB IS GIVEN BUT MBL IS NOT, THEN MBL IS SET JUST BIG 
          ENOUGH TO CONTAIN RB AVERAGE RECORDS, SO THAT IT IS POSSIBLE
          FOR THE BLOCK SIZE TO BE SET AS LOW AS 1 PRU. 
          AFRB   02/14/79    OPENDAA
  
 AM2A174  AAM2PL
          IF THE HOME BLOCK COUNT IS SPECIFIED AS 0, WHEN A DA FILE 
          IS BEING CREATED, IT SHOULD BE A FATAL ERROR. 
          AFRB   02/16/79    OPENDAA
  
 AM20005  (AAM 2.0) 
          THE FLSTAT UTILITY TRUNCATES VARIOUS NUMBERS IN ITS PRINTOUT. 
          THIS CODE ENLARGES FIELDS TO PREVENT THAT.
          AFRB   12/1/78     FLSTAT 
  
 AM20007  AAM2PL
          THIS CODE GENERATES AN EXTRA MESSAGE, WHENEVER A PUT OR 
          REPLACE IN AN AAM EXTENDED FILE FAILS BECAUSE OF A DUPLICATE
          PRIMARY OR ALTERNATE KEY VALUE. BEFORE ISSUING THE REGULAR
          ERROR MESSAGE (446 FOR PRIMARY KEY, 503 FOR ALTERNATE KEY), 
          NOTE 1027 IS ISSUED, WITH THE KEY VALUE INSERTED. 
          AFRB   1/3/79     AAMDNRO,NRODIS,NRODDA,NRODAK,MPGNDMP
                            NRODMIP,AAMFSTT 
  
 *L505*    ************************************************ 
 F2950AE  (AAM 2 PL)
          ENSURE THAT IN THE CASE OF CODE PLUGGING THAT THE 
          INSTRUCTION STACK IS CLEARED
          KLS    79/03/1     EXECDAK,EXECDIS,EXECDDA
  
 AM2A176  (AAM 2 PL)
          INFO$AA WAS SIMULATING A FILINFO CALL. THIS MOD CAUSES
          A FILINFO CALL INSTEAD. (FILINFO WAS JUST IMPLIMENTED)
          RJC   02/22/79    OPNMDAA 
  
 AM2A184  (AAM 2 PL)
          WE OFTEN WANT A MEMORY DUMP AFTER A FATAL ERROR IN AAM, 
          BUT REPRIVE USUALLY DESTROYES THE EVIDENCE BEFORE A DMP 
          CARD CAN WORK. TO ELIMINATE THE REPRIEV CALL CAN BE A BIG 
          JOB. THIS CODE PROVIDES THAT IF THE CM BIT OF THE FIT IS 1
          WHEN A FATAL ERROR IS MET IN AAM 2.0, A DUMP OF THE WHOLE 
          FIELD LENGTH IS CALLED FOR BEFORE CALLING THE ERROR ROUTINE 
          IN BAM, AND THE BIT IS CLEARED TO 0 TO PREVENT SUCH A DUMP
          FROM HAPPENING REPEATEDLY IN ONE RUN. THIS BIT OF THE FIT 
          (BIT 35 OF THE WORD AT FIT+9) IS NEVER USED OTHERWISE IN AAM. 
          IT HAS A SIGNIFICANCE IN BAM FILES, BUT AS BAM IS NOT PLAGUED 
          WITH AUTOMATIC REPRIEVE, THIS NEW DEVICE IS NOT NEEDED IN BAM.
          THE BIT CAN BE SET BY A FILE CARD (FILE,LFN,CM=YES.)
          AFRB   04/10/79    AAMDAA,CRA1DAA 
  
 AM2A185  (AAM 2 PL)
          AT OPEN TIME, THE FLM FIELD OF THE FIT IS SET TO 100000 
          IF THE USER LEFT IT 0. 100000 IS OK AS A BASIS FOR CALCUL-
          ATING DEFAULT SIZES OF THIS AND THAT, BUT THE DOCUMENTATION 
          SAYS THAT FLM=0 IS SUPPOSED TO MEAN NO LIMIT ON THE NUMBER
          OF RECORDS IN THE FILE. SO THIS CODE SETS FLM TO THE HIGHEST
          POSSIBLE VALUE (2**30-1) IF THE USER LEFT IT 0, IN EFFECT 
          MAKING THE LIMIT INFINITE,BUT STILL USES 100000 AS BASIS FOR
          CALCULATING DEFAULT SIZES.
          AFRB   04/10/79    OPENDAA
  
 AM2A188  (AAM 2 PL)
          CORRECT THE INCONSISTENCY IN AM2 DIRECTORY SIZE BETWEEN BAM 
          AND AAM AND PREVENT IT FROM HAPPENING AGAIN.
          REQUIRES THE INSTALLATION OF SW1A389
          GAG    04/18/79    AAMDCTL
  
AM2A189   (AAM 2 PL)
          THIS IS THE TEXTUALIZATION CODE TO PLACE COMMON SYMPL CODE IN 
          ONCE-COMPILED COMMON TEXTS. NOTE THAT WHILE COMDECKS ARE
          NOT -AFFECTED-, MANY ARE USED VIA *CALLS IN COMTEXT, AND
          *CALLS ARE DELETED FROM MANY DECKS. 
  
                 NEW COMDECK - COMUSETXT
                 NEW DECKS - COMTEXT, CWEOR0
                 DECKS AFFECTED - AAMDAA, AAMDNRO, AKDAK, AKDRARE,
                             DADDA, DADRARE, ISDIS, ISDRARE, KDEFDMP, 
                             MIPDMIP, MPGNDMP, MWSADMP, NRODAK, NRODDA, 
                             NRODIS, NRODMIP, OPENDAA, SEEKDIS, SEEKDMP,
          RJC    03/15/79 
  
 AM2A193  AAM2PL
          THERE IS A BUG IN ADRC$AA, WHICH IS CALLED TO INSERT OR 
          REPLACE A RECORD IN A BLOCK. IF THE BLOCK HAD UNIFORM RECORDS 
          WITH UR=1, AND THE NEW RECORD DESTROYS UNIFORMITY, IT MAY BE
          THAT THERE IS ROOM FOR THE NEW RECORD POINTERS (RC-1 OF THEM) 
          ONLY BECAUSE THE OPERATION IS A REPLACEMENT OF A LARGE RECORD 
          BY A SMALL ONE. IN SUCH A CASE, IT IS NECESSARY TO ((SQUEEZE
          OUT)) MOST OF THE OLD RECORD BEFORE CALLING XXUR$AA TO MAKE 
          THE FULL SET OF RECORD POINTERS. UNFORTUNATELY, ADRC$AA ALWAYS
          CALLS XXUR$AA FIRST, AND DOES THE SQUEEZING AFTERWARDS, 
          WHICH WORKS IN EVERY CASE EXCEPT THE RARE ONE JUST
          DESCRIBED. WHEN THAT RARE CASE OCCURS, XXUR$AA GIVES A FATAL
          507 ERROR, BECAUSE IT DOES NOT FIND ENOUGH FREE SPACE IN THE
          BLOCK FOR THE NEW RECORD POINTERS. THE NEW CODE DETECTS THE 
          RARE CASE, AND DELAYS THE CALL TO XXUR$AA UNTIL AFTER THE 
          SQUEEZING HAS BEEN DONE.
          AFRB   06/11/79    AAMDNRO
  
 AM20017  (AAM 2 PL)
          THE AAM CHARACTER MOVE ROUTINE (MOVC$AA) SOMETIMES PICKS UP 
          AND PUTS DOWN A WORD BEYOND THE END OF THE REAL DESTINATION 
          AREA.  THIS IS DISASTROUS IF THE OPERATING SYSTEM HAPPENS 
          TO ALTER THAT VERY WORD JUST BEFORE MOVC$AA REPLACES IT.
          OTHERWISE IT DOES NO HARM, SO THAT THE BUG IS VERY INTERMITT- 
          ENT. THE ENCLOSED CODE REPLACES THE BODY OF MOVC$AA WITH
          A ROUTINE THAT IS FREE FROM THIS DEFECT.
          AFTB   04/19/79    MISCDAA
  
 AM20020  (AAM 2 PL)
          THE RECORD COUNT LIMIT IN THE FLM FIELD OF THE FIT IS NOT 
          BEING RESPECTED FOR DA AND AK FILES, THE WAY IT IS FOR IS 
          FILES. THIS CODE BRINGS AK AND DA INTO LINE WITH IS.
          AFRB   03/30/79    NRODAK,NRODDA
  
 AM20030  (AAM 2 PL)
          THE RDRC ROUTINE WAS USING THE IS COLLATION TABLE INSTEAD OF
          THE MIP TABLE. THIS CAUSED PROBLEMS IN RETURNING AN ALTERNATE 
          KEY IN AK AND DA WHERE THERE IS NO IS COLLATING TABLE EXCEPT
          IN MIP. 
          RJC    04/24/79    AAMDAA 
  
 AM20032  (AAM 2 PL)
          MIPGEN CALLS OPEN OLD FOR THE DATA FILE, BUT SETS THE O/N 
          FLAG TO NEW WHEN OPENING THE MIP FILE. THE SYSTEM COMPRESSION 
          ROUTINE ISNT LOADED TILL AFTER THIS. MIPGEN,LIKE OPEN OLD,
          SHOULD DECIDE WHETHER TO LOAD IT ON THE BASIS OF THE FSTT 
          OF THE EXISTING DATA FILE. BUT THE O/N FLAG NOW SAYS NEW, AND 
          THIS IS NEGLECTED. THE ENCLOSED CODE CHECKS THE MIPGN BIT 
          IN THE FIT, SO THAT EVEN IF THE O/N FLAG SAYS NEW, WE SHALL 
          BEHAVE AS FOR OPEN OLD IN DECIDING ON COMPRESSION DURING
          MIPGEN. 
          THIS BRINGS TO LIGHT A DEFECT IN MPGN$MP. WHEN A RECORD 
          OF THE DATA FILE IS READ AND DECOMPRESSED, IT IS NECESSARY
          TO DECOLLATE THE PRIMARY KEY (IF A CHARACTER KEY) AFTER 
          COPYING IT TO THE PRIMARY KEY AREA AND BEFORE STARTING TO 
          EXTRACT ALTERNATE KEY VALUES. THE EXISTING CODE DOES
          THIS DECOLLATION IN THE ORIGINAL RECORD IMAGE INSIDE ITS
          BLOCK, EVEN IF THERE HAS BEEN DECOMPRESSION. NEW CODE 
          MAKES THE DECOLLATION HAPPEN WHERE MRQFWA POINTS, WHICH IS
          INSIDE THE BLOCK IMAGE IF THERE WAS NO DECOMPRESSION, OR IN 
          THE DECOMPRESSION BUFFER IF THERE WAS.
          AFRB   04/25/79    OPENDAA,MPGNDMP
  
 *L508*    ************************************************ 
 AM2A192  AAM2PL
          UNTIL NOW, AAM HAS NOT WORRIED ABOUT WHAT KIND OF INFORMA-
          TION MIGHT BE IN THE UNUSED PORTION OF A BLOCK. THIS WORRIES
          THE SECURITY-MINDED.
          THIS NEW CODE CLEARS TO ZERO EACH BLOCK IMAGE THE FIRST 
          TIME IT IS CREATED TO EXTEND THE FILE. THEREAFTER, ANY
          GARBAGE IN THE UNUSED AREA OF A BLOCK WILL BE INFORMATION 
          FROM THE SAME FILE, AND SO PRESUMABLY NO RISK TO THE OWNER. 
          THE ZEROING IS NOT DONE IF THE BLOCK IMAGE IS IN A BUFFER 
          SUPPLIED BY THE USER PROGRAM, BECAUSE HE CONTROLS THE CONTENT 
          OF THE SPACE AND NO OTHER FILE COULD BE READ INTO IT BY AAM.
          AFRB   05/30/79    AAMDNRO
  
 AM2A200  (AAM2 PL) 
          CONCURRENT MIP ON AN IS FILE COULD NOT OPEN THE MIP FILE
          THE SECOND TIME.  THE CAUSE WAS THE CIO OPEN CALL FOR THE 
          MIP FILE WITH AN UNINITIALIZED FIT.  THE CALL WAS UNNECESSARY 
          IN THE CONCURRENT CASE, SO IT HAS BEEN MOVED. 
          RJC    09/10/79    OPENDAA
  
 AM20031  AAM2PL
          WHENEVER     A SEEK POSITION INVOLVING MIP IS TAKEN OVER BY A 
          GET OPERATION, MPOMEGA MUST BE ZEROED. OTHERWISE THE GET MIGHT
          BE MISLED INTO GOING INTO A SUBBLOCK, WHERAS A SEEK POSITION
          CANT INVOLVE ANYTHING IN A SUBBLOCK, AS IT CANT INVOLVE 
          A PRIMARY KEY VALUE IN MIP. 
          AFRB   05/31/79    MIPDMIP
  
 *L518*    ************************************************ 
 AM2*80   AAM2 PL 
          UPDATE COPYRIGHT INFORMATION REFLECTING 1980
          KLS    79/10/15    AAMDCTL
  
 AM2A195 AAM2PL 
          IF A MIP FILE IS ORGANIZED SO THAT THE PRIMARY KEYS FOR A 
          SINGLE ALTERNATE KEY VALUE ARE TO BE LISTED FIFO, RATHER
          THAN INDEX-SEQUENTIAL, AND IF SUCH A FIFO SUB-FILE GOES 
          BEYOND ONE BLOCK IN LENGTH, AAM MAY GIVE UP WITH A 507
          ERROR. SUBROUTINE RCKN$AA IS SOMEWHAT SIMPLIFIED FOR FIFO 
          FILES, AND IF IT HAPPENS TO YIELD SPLTFLG=1, THIS IS TAKEN
          BY SUBROUTINE PTRP$IS TO MEAN THAT AFTER THE NEW BLOCK HAS
          BEEN FORMED (BY A DEGENERATE CASE OF BLOCK-SPLITTING), THE NEW
          RECORD SHOULD GO ON THE OLD BLOCK. THIS IS IMPOSSIBLE, AND
          IS DETECTED BEFORE THE BLOCK IS RUINED. THE NEW CODE MAKES
          SURE THAT FOR A FIFO FILE, ANY NON-ZERO SPLTFLG WILL BE 3,
          INDICATING THAT THE NEW RECORD MUST GO AT THE BEGINNING 
          OF THE NEW BLOCK, AFTER THE SPLIT. THAT IS WHAT IS ALWAYS 
          NEEDED FOR FIFO. RCKN$AA IS ALSO CALLED FOR DA FILES, BUT AS
          PTRP$IS IS NOT CALLED FOR DA, IT HAS NOT MATTERED THAT RCKN$AA
          MIGHT SET SPLTFLG = 1 OR 2. 
          AFRB   10/08/79    AAMDNRO
  
  
AM2A196   AM2PL 
          WHEN A BLOCK IS DISAPPEARING IN VANB WE SOMETIMES COPY THE
          NEXT BLOCK INTO IT AND MOVE THAT NEXT BLOCK TO THE EMPTY
          CHAIN.  IN THE SPECIAL CASE WHERE THAT NEXT BLOCK WAS THE 
          LAST DATA BLOCK, THE LAST DATA BLOCK PRU NUMBER FIELD IN THE
          FSTT WAS NOT BEING UPDATED. 
          RJC    10/03/79    ISDRARE
  
 AM2A198  AAM2PL
          A GET BY ALTERNATE KEY ON AN AK FILE ALWAYS SETS FP=20, 
          EVEN WHEN THE ALTERNATE KEY VALUE IS UNIQUE, SO THAT FP SHOULD
          BE 10. ACTUALLY, FP IS BEING CORRECTLY SET BY THE MIP CODE
          IN THESE CASES, BUT AN AK ROUTINE IS SETTING FP TO 20 AT THE
          END OF EVERY GET. TO CORRECT THIS, WE JUST OMIT THE CALL TO 
          FILP$AK IF THE GET IS BY ALTERNATE KEY, AS SHOWN BY FAPOSKEY1.
          AFRB   10/08/79    AKDAK
  
 AM2A202  (AM2 PL)
          AK EXTENDED WAS NOT ALIGNING THE PRIMARY KEY WHEN IT CROSSED
          WORD BOUNDS, EFFECTIVELY. 
          THE MOVC$AA CALL IN DECK AKDAK WAS NOT BEING CALLED CORRECTLY.
          ALTHOUGH THE KEY WAS BEING ALIGNED, THE STORE OF THE ALIGNED
          KEY WAS OCCURING AT WORD RA+0, NOT AT CKEY, WHICH WAS 
          EXPECTED. 
          GAG    09/28/79    AKDAK
  
 AM2A203 AAM2PL 
          TWO PROBLEMS CONNECTED WITH KEY COMPARISON. IN SUBROUTINE 
          CPCH$AA, WE NEGLECT THE POSSIBILITY OF COMPARING +0 AND -0 AS 
          UNCOLLATED CHARACTER KEYS. IN SUBROUTINE BNCH$AA, WE NEGLECT
          THE POSSIBILITY THAT WHEN ONE INTEGER KEY IS SUBTRACTED FROM
          ANOTHER, THE RESULT MAY BE FALSIFIED BY OVERFLOW. THIS CODE 
          IS INTENDED TO REMEDY BOTH. 
          AFRB   10/08/79    MISCDAA
  
 AM2A204 AAM2PL 
          AN ALTERNATE KEY OF TYPE INTEGER MAY GET DECOLLATED BEFORE
          BEING DELIVERED TO THE USER, BECAUSE THE KEY TYPE FIELD 
          IN FAPOSKEY1 HAS BEEN SET TO ZERO BY MISTAKE. TO MAKE THIS
          HAPPEN, THE UNLIKELY SEQUENCE OF A REWIND BY ALTERNATE
          KEY, FOLLOWED BY A GET AND A GETNEXT BY THE SAME KIND OF
          ALTERNATE KEY ARE NEEDED. FAPOSKEY1 IS SET PROPERLY BY THE
          REWIND. THEN GET CALLS KPTR$MP, WHICH CALLS POSONKD, WHICH
          SETS UP A NEW WORD ACCORDING TO RKW, RKP, AND KL, 
          THEN FINDS THE NEW WORD MATCHES FAPOSKEY1 IN THOSE THREE
          DIMENSIONS, THEN REPLACES FAPOSKEY1 BY THAT WORD, THUS
          CLEARING THE KEY TYPE FIELD. THIS CODE, IN SUCH A CASE, REFRE-
          SHES FAPOSKEY1 FROM MPAKD AND PRESERVES THE TYPE FIELD. 
          AFRB   10/08/79    MIPDMIP
  
 AM2A205 AAM2PL 
          GETNEXT-WITHOUT-RECALL BY ALTERNATE KEY SHOULD, IF PKA
          IN THE FIT IS NOT 0, RETURN THE PRIMARY KEY VALUE WHERE PKA 
          POINTS, ONCE THE GETNEXT IS COMPLETE.A CHANGE TO SUBROUTINE 
          RDRC$AA HAS STOPPED THIS. THIS NEW CODE RESTORES THE ACTION,
          THOUGH THE CODE FOR IT IS NOW IN MIP$MIP INSTEAD OF AAM$AA. 
          AFRB   10/08/79    MIPDMIP,SEEKDIS
  
AM20037   AAM2PL
          FLSTAT WAS NOT USING THE PROPER DESCRIPTIONS FOR THE VALUES 
          IT PUT OUT. 
          RJC    10/25/79    FLSTAT 
  
 AM20038  AAM2PL
          TWO PROBLEMS. (1) ROUTINE CONS$AA SQUEEZES DEAD RECORDS OUT OF
          BLOCK PREPARATORY TO A PUT OR REPLACE, AND ADJUSTS THE RECORD 
          NUMBER IN RNO IF THE RECORD THAT WAS IN SLOT RNO IS MOVED TO
          A LOWER-NUMBERED SLOT. HOWEVER IT IS POSSIBLE THAT RNO =
          1 MORE THAN THE NUMBER OF RECORDS IN THE BLOCK, WHICH MEANS 
          WE ARE GETTING READY TO INSERT A NEW RECORD AFTER THE LAST
          RECORD IN THE BLOCK. SUCH A VALUE OF RNO DOES NOT GET ADJUSTED
          BY CONS$AA, BECAUSE IT DOES NOT LIE BETWEEN 1 AND RC. THIS NEW
          CODE FOR AAM$NRO CAUSES SUCH AN RNO TO BE ADJUSTED. 
          (2) SUBROUTINE VANB$IS IN IS$RARE IS LIKE SPLT$IS IN THAT IT
          ASSIGNS A NEW PRU NUMBER TO A BLOCK IMAGE IN CORE, SOMETIMES, 
          TO SAVE THE LABOR OF COPYING THE CONTENTS OF THE BLOCK IMAGE. 
          BUT THERE ARE TWO POINTERS IN THE FSTT, FSUNWR1 AND FSUNWR2,
          WHICH IF NON-ZERO POINT TO IMAGES OF BLOCKS THAT HAVE BEEN
          LOGICALLY CREATED TO EXTEND THE FILE, BUT HAVE NOT ACTUALLY 
          BEEN WRITTEN ON DISK AS YET. IF EITHER OF THESE POINTS TO 
          A BLOCK IMAGE WHOSE PRU NUMBER IS BEING CHANGED, THE FILE 
          BECOMES FATALLY DISORDERED. SPLT$IS CONTAINS CODE TO UPDATE 
          FSUNWR1 AND/OR FSUNWR2 AS NECESSARY, BUT VANB$IS, THROUGH 
          OVERSIGHT, DOES NOT. THE NEW CODE FOR VANB$IS, RATHER THAN
          TRYING TO UPDATE THE TWO POINTERS IN THE FSTT, CLEARS THEM
          IF NECESSARY BY WRITING OUT THE BLOCK IMAGES THEY POINT 
          TO. THIS IS DONE, INSTEAD OF ADJUSTING THE POINTERS, BECAUSE
          THE WAY BLOCKS ARE RE-NUMBERED IS NOT AS CLEAR-CUT IN VANB$IS 
          AS IN SPLT$IS.
          AFRB   10/26/79    AAMDNRO ISDRARE
  
 *L528*    ************************************************ 
 AM2A208  AAM2PL
          THE SEQUENCE (1) GET BY ALTERNATE KEY (2) PUT (3) GETNEXT 
          WITHOUT RECALL --- MAY GIVE A WRONG ANSWER IF THERE ARE MORE
          THAN ONE ALT KEYS. THE GETNEXT-WITHOUT-RECALL-BY-ALTKEY 
          ROUTINE (GTNR$MP) THINKS KRAK$MP WILL RESTORE THE STATUS QUO
          IF AN UPDATE HAS TAKEN PLACE SINCE THE OPERATION THAT DEFINED 
          THE CURRENT KEY TYPE AND POSITION FOR GETNEXTS. BUT THIS IS 
          NOT SO AS KRAK$MP USES THE KEY DEFINITION IN MPAKD, WHICH WILL
          ESSENTIALLY BE THE DEFINITION OF THE RIGHTMOST ALTERNATE KEY
          IN EACH RECORD, AFTER EACH UPDATE IS COMPLETE. WHAT IS NEEDED 
          IS TO COPY THE KEY DEFINITION CONTAINED BY FAPOSKEY1 (WHICH 
          IS THE ONE THAT REGULATES GETNEXTS AND GETNEXTS WITHOUT 
          RECALL) INTO MPAKD AND THEN CALL KRAK$MP. THE NEW CODE DOES SO
          ALONG THE LINES OF WHAT IS DONE IN SUBROUTINE POSONKD FOR A 
          GETNEXT BY ALTERNATE KEY. 
          AFRB   11/15/79    SEEKDMP
  
 AM2A209  AAM2PL
          THE VARIABLE CMPREC IS SUPPOSED TO TELL WHETHER A RECORD
          ABOUT TO BE PUT INTO A FILE IS COMPRESSED OR NOT. BUT WHEN
          MIP IS INVOLVED THERE MAY BE CONFUSION BECAUSE THE SAME 
          SUBROUTINE PUTS RECORDS IN BOTH MIP AND DATA FILES, AND MAY 
          SEE CMPREC=1 WHEN THIS IS RELEVANT ONLY TO SOME DATA RECORD.
          THIS CODE CAUSES THINGS TO WORK AS IF CMPREC WERE 0, REGARD-
          LESS OF ITS ACTUAL VALUE, WHEN THE BLOCK IS IN A MIP FILE.
          AFRB   11/16/79    AAMDNRO
  
 AM2A210  AAM2PL
          CDCS NEEDS A WAY TO PUT A CEILING ON THE AMOUNT OF SPACE
          AAM ALLOWS ITSELF TO REQUEST FROM CMM FOR FILE BUFFERS. 
          AAM CONTROLS ITSELF BY ADJUSTING A TARGET EVERY TIME AN OPEN
          OR CLOSE TAKES PLACE, BUT IF THERE ARE MANY FILES OPEN AT 
          ONCE THE TARGET IS THE SUM OF THE TARGETS FOR ALL THE FILES.
          CDCS WANTS TO CUT THIS DOWN BECAUSE MANY ARE OPEN BUT 
          FEW BE ACTIVE, AND A SMALLER AMOUNT OF SPACE WILL BE ENOUGH 
          FOR THE ACTIVE ONES. THIS CODE REFERENCES  AN ENTRY POINT 
          AAM$BL IN CTRL$AA. IT IS ASSEMBLED AS A WORD CONTAINING 
          THE LARGEST CONCEIVABLE VALUE OF THE TARGET. A PROGRAM THAT 
          CALLS AAM BUT WANTS TO RESTRICT TARGET NEED ONLY STORE
          WHATEVER NUMBER IT LIKES INTO AAM$BL. AT ALL LATER OPENS
          AND CLOSES, TARGET WILL BE KEPT AT OR BELOW THIS NUMBER OF
          WORDS -- EXCEPT IF AAM$BL HAS BEEN SET BELOW THE MINIMUM
          POSSIBLE TARGET, WHICH AAM CALCULATES ALONG WITH TARGET,
          EACH TIME. AAM$BL CAN BE VARIED DURING THE RUN IF THE USER
          WISHES
          AFRB   11/16/79    OPENDAA
  
 AM2A211  AAM2PL
          CDCS WANTS TWO CHANGES IN FATAL ERROR HANDLING. 
          (1) WHEN A FATAL ERROR IS CAUSED BY SOMETHING BAD IN THE
          FILE, RATHER THAN A MERE ERROR IN FIT SETUP AT OPEN TIME, 
          A BIT IN THE FIT (BFF) IS SET TO 1. 
          (2) INSTEAD OF ALWAYS SETTING FSFTERR IN THE FSTT TO 215B,
          DO SO ONLY WHEN THE FATAL ERROR IS CAUSED BY SOMETHING BAD
          IN THE FILE. THUS A FIT SETUP WITH A WRONG FILE ORGANIZATION, 
          FOR EXAMPLE, AT OPEN OLD TIME, WOULD NOT CAUSE OTHER FITS 
          THAT WERE ALREADY ACCESSING THE SAME FILE SUCCESSFULLY TO GET 
          FATAL ERRORS SOON AFTER. THE FATAL ERRORS THAT ARE CONSIDERED 
          TO INDICATE REALLY BAD FILE ARE DISTINGUISHED BY MESSAGE
          NUMBER, THE BAD ONES BEING LISTED IN ARRAY BADFILE, IN
          THIS CODE.
          AFRB   11/20/79    AAMDAA 
  
AM2A212   AAM2PL
          AFTER A REWIND ON A DA FILE, GETN WAS USING THE QEI FLAG
          INSTEAD OF THE REWOUND POSITION.  HERE WE RESET QEI AFTER 
          DISCOVERING A REWOUND SITUATION.  THIS IS ONLY RELEVANT IN THE
          SPECIAL CASE OF - PROCESS TO EOI - REWIND - GETN. 
          RJC    11/27/79    DADDA
 AM2A214  AAM2PL
          REW$DA, FOR REWINDING A DA FILE, CALLS FILP$AA TO SET FP
          IN THE FIT TO 20B (EOR). UNFORTUNATELY FILP$AA TRIES TO STORE 
          THE CURRENT KEY VALUE. THAT IS APPROPRIATE TO IS FILES BUT
          NOT TO DA FILES, BECAUSE A DA REWIND CONSISTS MERELY OF 
          CLEARING A CELL IN THE PTREE, NOT OF LOOKING AT THE FIRST 
          RECORD IN THE FIRST BLOCK. THE POINTER TO THE CURRENT KEY 
          (TEMPLOC) MAY CONTAIN AN OUT-OF-RANGE ADDRESS AT THIS POINT.
          THIS CORRECTIVE CODE MODIFIES FILP$AA SO THAT IT DOES NOT 
          TRY TO STORE A KEY DURING A DA REWIND. NOTE THAT THE PROBLEM
          DOES NOT ARISE FOR AK FILES, AS THE AK ROUTINES DO NOT CALL 
          FILP$AA.
          AFRB   12/19/79    AAMDAA 
  
 AM2A217  AAM2PL
          WHEN AN OVERFLOW RECORD IS DELETED FROM A BLOCK IN AN 
          AK FILE, ONE WORD TOO LITTLE IS ADDED TO THE EMPTY COUNT
          IN THE 2ND WORD OF THE BLOCK. THIS CAN CAUSE A FATAL
          ERROR, BECAUSE A SPACE-FINDING ROUTINE MAY MAKE A CORRECT 
          ESTIMATE OF WHETHER A NEW RECORD COULD BE FITTED IN AFTER 
          DELETING OR MOVING ELSEWHERE THAT OVERFLOW RECORD. IF THE 
          CORRECT ANSWER IS YES, BUT THE EMPTY COUNT IS NOT RAISED
          ENOUGH WHEN THE OVERFLOW RECORD IS GOT RID OF, IT MAY THEN
          LOOK INEXPLICABLY IMPOSSIBLE TO INSERT THE NEW RECORD.
          THE ERROR ARISES BECAUSE WHEN AN OVERFLOW RECORD IS ACCESSED, 
          RECFWA AND RECLNG ARE SET UP 1 AND DOWN 1, TO GET OVER THE
          FIRST WORD, WHICH IS JUST A POINTER BACK TO THE MOTHER
          RECORD. RECFWA AND RECLNG ARE LIKE THIS FOR THE SAKE OF MIP 
          ROUTINES THAT MIGHT HAVE TO SCAN AN EXISTING RECORD BEFORE IT 
          IS DELETED OR REPLACED. BUT FROM A SPACE POINT OF VIEW, RECLNG
          IS 1 LESS THAN THE NUMBER OF WORDS OF SPACE TO BE GAINED BY 
          REMOVING THE RECORD.    TO REMEDY THIS, LET RECFWA AND RECLNG 
          ALWAYS BE GIVEN THEIR TRUE VALUES, INCLUDING THE PREFIX WORD, 
          BY THE SUBROUTINE THAT SETS THEM FOR UPDATE OPERATIONS, NAMELY
          INUP$AK. BUT PROVIDE FOR THE ADJUSTMENT NEEDED BY MIP ROUTINES
          BY SETTING OUTKEY = 1 JUST BEFORE CALLING DLT$MP OR REPL$MP,
          IF THE CURRENT RECORD IS AN ALIEN.
              A SECOND DIFFICULTY, THOUGH A MINOR ONE, IS CLEARED UP BY 
          NEVER USING THE ((ANYDEAD)) FLAG IN AK FILES. SUBROUTINE
          DELL$AK IS THE ONLY ONE THAT SETS THE FLAG IN AK, BUT DOESNT
          ALWAYS DO IT RIGHT. FORTUNATELY THE FLAG IS USED VERY LITTLE
          AND BY SIMPLY NOT USING IT AT ALL, THE ONLY CHANGE WE MAKE IS 
          TO CALL CONS$AA UNNECESSARILY ON A FEW OCCASIONS. 
              THE DIFFERENCE BETWEEN AK AND THE OTHER TWO FILE ORGANIZA-
          TIONS IS THAT DEAD RECORDS HAVE TO BE KEPT AROUND AS PLACE- 
          HOLDERS IN AN AK BLOCK, WHILE IN DA AND IS WE ALWAYS SQUEEZE
          OUT DEAD RECORDS BEFORE ADDING OR REPLACING A RECORD. 
          AFRB   1/28/80     NRODAK,AKDRARE 
  
 AM2A218  AAM2PL
          IN AAM2, A WRITE PARITY ERROR, WHERE POSSIBLE, IS REMEDIED
          BY RE-WRITING THE BLOCK AT EOI AND MAKING AN ENTRY IN A 
          TABLE IN THE FSTT (FSBADBLK) GIVING THE PRU NUMBER AT WHICH 
          THE BLOCK OUGHT TO BE, AND THE PRU NUMBER WHERE IT ACTUALLY 
          IS. HOWEVER, THE USER GETS NO INDICATION OF THIS WHEN IT
          HAPPENS. THIS NEW CODE PROVIDES A DAYFILE MESSAGE WHENEVER
          A FILE IS CLOSED, IN WHICH TABLE FSBADBLK IS NOT EMPTY. THE 
          MESSAGE SAYS THAT THE FILE HAS HAD AT LEAST ONE WRITE PARITY
          ERROR, BUT NO INFORMATION HAS BEEN LOST IN THE BAD BLOCK(S).
          AFRB   01/30/80    OPENDAA,OPNMDAA
  
 AM2A220  AAM2PL
          USE OF THE FLUSHM MACRO DOES NOT LEAVE B1=1 AFTERWARDS. THE 
          NEW CODE SETS B1=1 JUST BEFORE RETURNING TO THE USER. 
          AFRB   03/03/80    AAMDCTL
  
 AM2A221  AAM2PL
          A SERIES OF SEEKS, INTENDED TO BE PRELIMINARY TO A START
          BY ALTERNATE KEY WITH REL=GT, CAN ACTUALLY CAUSE THE START TO 
          BEHAVE AS THOUGH REL=EQ. SEEKS ALWAYS BEHAVE AS IF REL=EQ. IF 
          THE SERIES OF SEEKS HAS FOUND THE GIVEN KEY IN THE MIP FILE,
          AND EXTRACTED THE CORRESPONDING PRIMARY KEY VALUE, WHICH
          MUST BE LOCATED IN THE DATA FILE, A SUBSEQUENT START WITH 
          REL=GT MUST NOT PICK UP WHERE THE SEEKS LEFT OFF, BUT MUST
          START FROM SCRATCH. NEIGHBORING ALTERNATE KEY VALUES DONT 
          NECESSARILY GO WITH NEIGHBORING PRIMARY KEY VALUES. IN THIS 
          CONTEXT, REL=GT MEANS WE MUST STEP AHEAD IN THE MIP FILE, 
          NOT IN THE DATA FILE. BUT IF SEEKS HAVE ALREADY CARRIED US
          FROM THE MIP FILE TO THE DATA FILE, THIS CAN NO LONGER BE 
          DONE. THE CORRECTION CODE FORCES A START BY ALTERNATE KEY 
          TO IGNORE THE WORK OF PRECEDING GETS, IF REL IS NOT EQ. 
          THE CHANGE DOES NOT APPLY TO START BY PRIMARY KEY IN AN 
          IS FILE, BECAUSE WITH PRIMARY KEY, WE CAN LET SEEK AND START
          TAKE US TO THE SPECIFIED KEY, AND FULFIL REL=GT AT THE
          VERY END, WITH SUCCESS. 
          AFRB  03/03/80    SEEKDMP 
  
 AM2A223  AAM2 PL 
          THE OPEN$AA CAPSULE WILL NOT BE UNLOADED IF THE LOCK FLAG 
          HAS BEEN SET. 
          KLS  03/14/80  AAMDCTL
  
 AM2A224  AAM2PL
          IN CRM 2.0 AAM, IT IS POSSIBLE FOR A JOB TO ABORT IF AN 
          OVER-LONG BLOCK IS READ. THIS HAPPENS EXTREMELY RARELY, 
          BECAUSE AAM CHECKS THE FSTT AT THE BEGINNING OF THE FILE
          BEFORE EXPOSING ITSELF TO THIS PERIL, AND ANYWAY IT IS MORE 
          LIKELY TO RUN INTO A SHORT BLOCK THAN A LONG ONE. SUPPOSE 
          BLOCKS ARE KNOWN TO BE 76B WORDS LONG, AND WE WANT TO READ
          A BLOCK INTO 1000B THROUGH 1075B. THEN BEFORE READING WE SET
          FIRST=775B,IN=OUT=1000B,LIMIT=1077B. IF THE BLOCK TURNS OUT 
          TO BE 77B WORDS LONG, 1076B GETS READ INTO, WHICH IS THE
          CMM CONTROL WORD OF THE NEXT PARCEL. IF 100B WORDS LONG,
          775B GETS READ INTO, WHICH IS AN AAM CONTROL WORD FOR THE 
          BLOCK. TO ELIMINATE THIS POSSIBILITY, WE SHOULD SET 
          FIRST=IN=OUT=1000B,LIMIT=1077B. BUT THIS WOULD PREVENT A
          CIO READ FROM READING THE LAST 76B WORDS OF ANY BLOCK 
          (BLOCKS ARE 76B, OR 176B, OR 276B....WORDS LONG) BECAUSE IT 
          WILL NEVER START READING THE NEXT PRU UNLESS THERE ARE
          AT LEAST 101B WORDS FREE IN THE BUFFER. TO OVERCOME THIS, 
          IT IS NECESSARY TO CALL FOR READSKP, IN EVERY CASE, 
          INSTEAD OF READ.
          ONCE THIS IS DONE, ANOTHER BUG APPEARS. IF FIRST= THE FWA 
          OF THE BUFFER, THEN SUBROUTINE WTIO$AA IN AAM$AA HAS TO SET 
          P<BLOK$AA>=FIRST-3, RATHER THAN FIRST. THERE IS ONE PLACE IN
          AAM WHERE WTIO$AA FINDS FIRST=0, WHICH LEADS TO DISASTER WHEN 
          P<BLOK$AA> IS SET TO FIRST-3. THIS IS IN THE MIDDLE OF SUB- 
          ROUTINE CLSF$AA, WHERE AT CLOSE TIME WE RESTORE FWB IN THE FIT
          TO WHAT IT WAS AT OPEN TIME. FWB IS THE POINTER TO THE USER-
          SUPPLIED BUFFER, AND IS MOST COMMONLY 0. WE HAVE TO RESTORE 
          IT AT CLOSE TIME, BECAUSE IT OCCUPIES THE SAME SPACE AS THE 
          FIRST POINTER. HENCE, MOST OFTEN,WE SET FIRST=0 AT THIS POINT.
          FOUR LINES LATER, WE CALL WTIO$AA. THIS CAUSES DISASTER WHEN
          WTIO$AA SETS P<BLOK$AA>= -3 AND TRIES TO LOOK AT THE BLOCK. 
          TO PREVENT THIS, WE FIRST MOVE THE RESTORATION OF FWB TO A
          LATER POINT IN CLSF$AA, WHEN NO FURTHER CALL TO WTIO$AA NEED
          BE FEARED. BUT THIS EXPOSES ANOTHER WEAK SPOT.
          IF WE HAVE CALLED SUBROUTINE CLOSFIL TO DO A CIO CLOSE ON THE 
          FILE, THE FET POINTERS HAVE BEEN SET ARBITRARILY TO 200,200,
          200,300 (CIO CLOSE DOESNT REALLY USE THE BUFFER POINTERS, BUT 
          THEY DO HAVE TO BE SET TO SOMETHING WITHIN THE FIELD LENGTH), 
          AND THIS MIGHT CAUSE WTIO$AA TO SET P<BLOK$AA> TO 175B, WITH
          DEPLORABLE CONSEQUENCES.
          TO AVOID THIS, WE CONSIDER THAT CLSF$AA IS CALLED TO CLOSE A
          FIT WHICH MAY OR MAY NOT BE THE ONLY FIT THAT IS NOW CONNECTED
          WITH THE FILE IT NAMES. CLOSFIL IS CALLED IF THIS IS THE ONLY 
          FIT; OTHERWISE WE WOULD NOT WANT TO DO A CIO CLOSE. WTIO$AA IS
          CALLED IN BOTH CASES, BUT THIS IS REALLY UNNECESSARY. IF THIS 
          IS THE ONLY FIT, AND A CIO CLOSE HAS BEEN DONE, THEN OBVIOUSLY
          WTIO$AA NEED NOT BE CALLED TO COMPLETE LOGICALLY ANY PENDING
          I-O ON THAT FILE. SO WE ADD (FSUSRCNT NQ 0), I.E. THAT
          SOME FIT IS STILL OPEN ON THE FILE AFTER THIS ONE IS
          CLOSED, TO THE CONDITIONS FOR CALLING WTIO$AA.
          ACTUALLY, IT WOULD SEEM THAT IT IS NEVER NECESSARY TO 
          CALL WTIO$AA HERE, BECAUSE FLSH$AA HAS BEEN CALLED
          BY CLSF$AA, AND FLSH$AA NECESSARILY COMPLETES ALL 
          PENDING I-O, PHYSICALLY AND LOGICALLY. BUT OUT OF 
          CAUTION, WE RETAIN THE WTIO$AA CALL.
  
          AFRB   03/19/80    AAMDAA,OPENDAA 
  
 AM2A225  AAM2PL
          THERE IS A PLACE IN PROGRAM AK$RARE, AND ONE IN 
          PROGRAM KDEF$MP, AT WHICH A READ ERROR
          MAY NOT BE NOTICED, AND THEREFORE GENERATE MORE SERIOUS 
          TROUBLE LATER ON. SUBROUTINE LOCB$AA ALWAYS SETS
          P<BLOK$AA> TO THE FWA OF THE BLOCK READ, INDICATING A 
          GOOD READ, OR TO MINUS THAT ADDRESS, INDICATING A BAD 
          READ (PARITY, CHECKSUM, OR BLOCK LENGTH ERROR), OR TO 
          ZERO, INDICATING READ INCOMPLETE. WHEREVER IN AAM 
          LOCB$AA IS CALLED, WE SHOULD IMMEDIATELY AFTERWARDS 
          CHECK P<BLOK$AA>, AND IF IT IS NEGATIVE, GO TO EXRP$AA
          TO ABANDON THE OPERATION WITH A READ ERROR MESSAGE. 
          OR AS IN KDEF$MP, BECAUSE WE KNOW WE ARE DOING
          UPDATES AND NOT MERELY READS, ISSUE A FATAL 
          ERROR MESSAGE DIRECTLY. 
          AFRB   03/14/80    AKDRARE,KDEFDMP
  
 AM2A227  AAM2PL
          AM2A185 ALLOWS A USER WHO IS ABOUT TO OPEN A FILE 
          THROUGH A SECOND FIT, WHEN IT IS ALREADY OPEN THROUGH 
          A FIRST FIT, TO COPY THE FSTT POINTER FROM THE FIRST
          FIT TO THE SECOND ONE, BEFORE ACTUALLY CALLING CRM. 
          THIS LETS CRM-AAM SKIP A FILINFO CALL, WHICH COULD BE 
          DANGEROUS UNDER NOS OPERATING SYSTEM. HOWEVER,  THE 
          FSTT POINTER IN THE SECOND FIT MAY CAUSE TROUBLE IF 
          THE OPEN THROUGH THE SECOND FIT IS NOT COMPLETED
          SUCCESSFULLY. THEREFORE, THE FSTT POINTER IN THE
          SECOND FIT MUST BE ZEROED AFTER IT HAS DONE ITS JOB,
          AND BEFORE ANY POSSIBILITY OF FAILURE HAS ARISEN. 
          AFRB   04/03/80    OPENDAA
  
 AM20044  AAM2PL
          A FILE CARD WITH ((USE)) CAN GENERATE CALLS TO ENTRY POINTS 
          THAT DO NOT EXIST, NAMELY OPEN$AK,OPEN$DA,OPEN$IS,CLSF$AK,
          CLSF$DA,CLSF$IS. BUT IT DOES NOT GENERATE CALLS TO THE ENTRY
          POINTS THAT DO EXIST, NAMELY OPEN$AA AND CLSF$AA. THIS CODE 
          CREATES THE MISSING ENTRY POINTS, MAKING THEM SYNONYMS OF THE 
          CORRESPONDING EXISTING ENTRY POINTS. WHEN STATIC LOADING HAS
          BEEN ENABLED TO BRING IN THE OPEN CAPSULE, BY THIS ADDITION 
          OF ENTRY POINTS, IT TURNS OUT THAT IT BRINGS IN TWO DA
          CAPSULES AND TWO MIP CAPSULES NEEDLESSLY. THIS IS BECAUSE 
          THE OPEN CAPSULE HAS A HARD CALL TO A DA ENTRY POINT, WHICH 
          MUST BE SOFT, THE DA READ-ONLY CAPSULE HAS HARD CALLS TO
          MIP AND A HARD CALL TO DA-UPDATE, ALL OF WHICH MUST BE
          SOFT, AND THE DA-UPDATE CAPSULE HAS HARD CALLS TO MIP, WHICH
          MUST BE SOFT. THE NEEDED SOFTENINGS ARE PROVIDED IN THIS
          CORRECTIVE CODE.
          TO COMPLETE THE SET OF STATIC POSSIBILITIES, WE ARE 
          LACKING ALTOGETHER THE ENTRY POINTS SKFL$DA,
          SKFL$AK, SKBL$AK, STRT$DA, REPL$DA, 
          STRT$AK. ALSO, SEVERAL EXISTING ENTRY POINTS HAVE TO
          BE FORCED TO BE CAPSULE ENTRY POINTS -- GET$DA, GETN$DA,
          GTNR$AK,GTNR$DA, REW$DA, REW$AK, SEEK$DA, SEEK$AK. THE
          CORRECTIVE CODE SUPPLIES THESE LACKS. AT FIRST SIGHT, 
          THE FIRST LIST SHOULD ALSO INCLUDE SKFL$IS, SKBL$IS, AND
          STRT$IS, WHILE THE SECOND SHOULD ALSO INCLUDE REW$IS. 
          BUT THESE FOUR NAMES ARE TAKEN CARE OF IN TWO COMPASS 
          PROGRAMS CALLED IS$STAT AND IS$SKST, WHOSE TEXTS ARE
          DECK STATDUM ON THE OLDPL. THESE TWO PROGRAMS CONTAIN 
          NOTHING THAT OCCUPIES SPACE AT LOAD TIME. THEY ONLY 
          CONTAIN THE ENTRY POINTS, PLUS LDSET DIRECTIVES 
          USE=GET$IS (GOING WITH ENTRY POINTS REW$IS AND STRT$IS) 
          AND USE=SKIP$IS (GOING WITH SKBL$IS AND SKFL$IS). 
  
          IN ADDITION, WE LACK A HARD EXTERNAL CALL FROM CAPSULE
          UPDT$AK TO OVFM$AK. (THIS IS NOT NEEDED FOR NORMAL
          DYNAMIC LOADING, ONLY FOR STATIC.) THE NATURAL PLACE
          TO PUT IT WOULD BE IN COMPASS PROGRAM UPDT$AK, BY 
          ANALOGY WITH THE CALL FROM UPDT$DA TO OVFM$DA. LO AND 
          BEHOLD, COMPASS PROGRAM UPDT$AK REALLY DOES NOT EXIST.
          BY CHANCE, ITS ABSENCE DOES NOT PREVENT AK EXTENDED 
          FROM WORKING PROPERLY, UNDER ALMOST ALL CIRCUMSTANCES 
          OF DYNAMIC LOADING. OTHERWISE, THE LACUNA WOULD HAVE
          BEEN NOTICED AND FILLED LONG AGO. THE CORRECTIVE
          CODE SUPPLIES UPDT$AK.
          ONE MORE BUG IN THE SAME AREA. IN TABLE CAPN$AA OF
          COMPASS PROGRAM AAM$CTL, THE ENTRY POINTS NAMED FOR 
          CAPSULES UPDT$DA AND UPDT$AK ARE, NOT UPDT$DA AND 
          UPDT$AK (COMPARE THE TABLE ENTRY FOR UPDT$IS), BUT
          PUT$DA AND PUT$AK. THIS CAUSES THE COUNT OF HOW MANY
          TIMES WE HAVE WANTED TO LOAD OR UNLOAD THE CAPSULE
          TO BE MAINTAINED (BY RM$LDC) IN THE WRONG WORD OF THE 
          CAPSULE. IT DOESNT CAUSE A HANG, BUT IT DOES PREVENT THE
          COUNT FROM EVER GETTING DOWN TO 0. SO ONCE UPDT$DA OR 
          UPDT$AK HAS BEEN LOADED, DURING DYNAMIC LOADING, IT CAN NEVER 
          GET UNLOADED UNTIL THE VERY LAST AAM FILE HAS BEEN CLOSED.
          HERE ARE THE CORRECTIONS TO THE TABLE IN AAM$CTL. 
          AFB    02/20/80    OPNMDAA,OPENDAA,DADDA,NRODDA,AAMDCTL,UPDTAK
                             EXECDDA,UPDTDDA,EXECDAK
  
 AM20053  AAM2PL
          ERROR 507 IS INTENDED TO MEAN THAT THE PROGRAM APPEARS TO 
          HAVE GONE HAYWIRE, AND THE MOST PRUDENT THING IS FOR AAM TO 
          STOP PROCESSING ANYTHING. SO WHEN SUCH AN ERROR IS FOUND, WE
          CALL IMPR$AA, WHICH ISSUES THE 507 FATAL ERROR, AND ALSO SETS 
          A LOCATION CALLED IMPERR TO NON-ZERO. NOW WHENEVER AAM$CTL IS 
          ENTERED AT THE BEGINNING OF AN OPERATION, IT CHECKS IMPERR, 
          AND IF NON-ZERO IS FOUND, THE PROGRAM JUMPS TO KILLAAM TO 
          ISSUE A 507 FATAL ERROR INSTEAD OF DOING THE OPERATION. SO IF 
          ALL GOES PROPERLY, AFTER THE FIRST 507 ERROR IS FOUND, THE
          USER PROGRAM DOES NOT ADDRESS THAT FILE ANY MORE, BECAUSE IT
          CHECKS FNF AFTER EVERY OPERATION. THEN IF THE USER PROGRAM HAS
          OTHER AAM FILES TO WORK ON, THE FIRST ATTEMPT TO ADDRESS ANY
          OF THEM RESULTS IN ANOTHER 507 ERROR, AND FINALLY, ALL THE
          FILES HAVE BEEN CLOSED. HOWEVER, THE RUIN FLAG IS ONLY SET
          IN THE FILE THAT THE ORIGINAL 507 REFERRED TO.
          THIS IS NOT SUPPOSED TO HAPPEN OFTEN -- IT IS FOR ((IMPOS-
          SIBLE)) ERRORS. PROVIDED THE USER PROGRAM ALWAYS CHECKS THE 
          FNF FLAG, AND NEVER ATTEMPTS TO OPERATE ON A FILE THAT HAS
          HAD A FATAL ERROR, THERE SHOULD BE NO ABORT.
          HOWEVER, ONE PARAMETER IS MISSING FROM THE CRMEI MACRO AT 
          KILLAAM, AND THIS CAUSES AN ABORT WHEN WE BRANCH TO KILLAAM.
          THUS A REAL FATAL ERROR IN ONE FILE APPEARS TO CAUSE, WITHOUT 
          APPARENT MOTIVE, NOT MERELY A BOGUS FATAL ERROR ON A SECOND 
          FILE, BUT A MODE OUT. THE BOGUS FATAL ERROR IS WANTED, AS A 
          DEVICE TO STOP AAM FROM DOING POSSIBLE FURTHER HARM, BUT OF 
          COURSE THE MODE OUT IS NOT WANTED.
          THE CORRECTIVE CODE SUPPLIES THIS PARAMETER.
          AFRB   03/10/80    AAMDCTL
  
 AM20054  AAM2PL
          A GET-NEXT-WITHOUT-RECALL BY ALTERNATE KEY MAY CAUSE A 546
         ERROR (A PRIMARY KEY FOUND IN THE MIP FILE COULD NOT BE
         FOUND IN THE DATA FILE - PRESUMABLY THE FILES DO NOT CORRES- 
         POND EXACTLY) IF THERE HAS BEEN A DELETION THAT CAUSES THE 
         FIRST RECORD IN A NON-UNIFORM BLOCK OF A LEVEL-2 SUBFILE 
         OF THE MIP FILE TO HAVE BEEN DELETED. THE RECORD WILL STILL
         BE IN THE BLOCK, AS A DEAD RECORD.   SUBROUTINE BELL$MP, 
         IN PROGRAM SEEK$MP, OFTEN GETS THE FIRST LOOK AT SUCH A BLOCK
         WHEN IT HAS JUST BEEN READ INTO CORE. IT USES LOCR$AA TO 
         LOCATE WHICHEVER RECORD IS NOTED AS CURRENT IN THE PTREE 
         WORD. BUT THIS MAY BE 1, SET SO WHEN WE FOUND WE HAD TO STEP 
         OVER FROM THE PRECEDING BLOCK. WE SET THE PTREE WORD TO
         RECORD 1 OF THE NEXT BLOCK IN LINE, WITHOUT REALLY  KNOWING
         WHETHER RECORD 1 IS LIVE. THE ROUTINE THAT CALLS BELL$MP 
         ASSUMES ON RETURN THAT IF COND=0 EVERYTHING POINTS TO
         A GOOD LIVE RECORD IN CORE. IN ORDER TO JUSTIFY THIS FAITH 
         BELL$MP MUST TAKE THE ADDED STEP OF CHECKING THE CURRENT 
         RECORD FOR DEADNESS, AND IF SO, CALLING STPF$AA TO STEP TO THE 
         NEXT LIVE RECORD IN THE BLOCK. (THERE MUST BE AT LEAST 1,
         BECAUSE BY CONVENTION THE LAST RECORD OF A BLOCK CANNOT
         BE DEAD.)
         AFRB   02/07/80    SEEKDMP 
  
 AM20055  AAM2PL
          IT IS POSSIBLE, WHEN PROCESSING AN AAM EXTENDED FILE, FOR A 
          READ ERROR, SUCH AS AN ERROR IN PARITY, BLOCK LENGTH, OR
          CHECKSUM, TO PASS UNNOTICED, SO THAT FALSE DATA CAN BRING 
          DISASTER.THE POSSIBILITY IS IN SUBROUTINE SEBL$AA, IN 
          PROGRAM AAM$AA. WHEN SEBL$AA IS CALLED WITH RECALL=0, AND 
          THE WANTED BLOCK HAS PREVIOUSLY BEGUN TO BE READ WITHOUT
          RECALL, AND THE READ HAS ACTUALLY COMPLETED, SO THAT THE
          COMPLETION BIT IN THE FET IS 1, BUT THE FET HAS NOT BEEN
          USED FOR ANYTHING ELSE SINCE THEN,SEBL$AA CALLS WTIO$AA 
          TO DO THE LOGICAL COMPLETION OF THE READ, BUT DOES NOT
          BOTHER TO CHECK FOR POSSIBLE READ ERRORS. 
          THE CORRECTIVE CODE ESTABLISHES AN ALTERNATE ENTRY POINT TO 
          SUBROUTINE LOCB$AA, SO THAT JUST THE FINAL CHECKING FOR 
          READ ERRORS CAN BE DONE, AND THEN MAKES SEBL$AA CALL THAT 
          CHECKING IN THE CASE DESCRIBED ABOVE, AND ABANDON THE 
          OPERATION IF THERE IS AN ERROR. 
          IN THE NEW CODE FOR SEBL$AA, THE BLWIP FLAG IS USED TO EXCLUDE
          THE CASE WHERE THE LAST OPERATION ON THE BLOCK WAS A WRITE
          WITHOUT RECALL. WHEN A WRITE IS LOGICALLY COMPLETED, BLWIP AND
          BLCODSTAT ARE BOTH ZEROED AT ONCE (IN CHECKWRT), SO TESTING 
          BLWIP IS A SUFFICIENT PRECAUTION AGAINST TREATING A WRITE WITH
          NO RECALL AS IF IT HAD BEEN A READ WITH NO RECALL. IF THE LAST
          OP WAS WRITE WITHOUT RECALL, THIS HAS NO EFFECT ON THE DATA IN
          THE BLOCK IMAGE AND SO IS OF NO INTEREST TO SEBL$AA.
          AFRB   03/10/80    AAMDAA 
  
 AM20056  AAM2PL
          THERE IS A BUG IN THE AK SPACE SEARCH ROUTINE WHOSE MOST
          NOTABLE RESULT IS THAT WHEN A FILE IS BEING CREATED BY A
          LONG SERIES OF PUTS-WITHOUT-KEY, A LOT OF READING IS
          MYSTERIOUSLY DONE. THERE IS AN 11-ITEM TABLE IN THE FSTT, 
          FSPCEMTAB, TELLING HOW MANY BLOCKS ARE 0-9.99 PCT. EMPTY, 
          HOW MANY 10-19.99 PCT. EMPTY....90-99.99 PCT. EMPTY, AND
          100 PCT. EMPTY. SUPPOSE EACH RECORD OCCUPIES 6 PCT. OF A
          BLOCK. THEN EACH BLOCK IS EFFECTIVELY FULL WHEN 16 RECORDS
          HAVE BEEN INSERTED, OCCUPYING 96 PCT. AND LEAVING 4 PCT.
          EMPTY. THEN THE BLOCK IS COUNTED IN FSPCEMTAB[0], ALONG WITH
          ALL THE PRECEDING BLOCKS. ON THE NEXT PUT, THE SPACE SEARCH 
          IS LOOKING FOR A BLOCK WITH AT LEAST 6 PCT. EMPTINESS. THIS 
          IS IN THE RANGE COUNTED IN FSPCEMTAB[0], SO THE ROUTINE COUNTS
          ALL THE BLOCKS COUNTED IN FSPCEMTAB[0] AND ALL FOLLOWING WORDS
          IN THE TABLE, IN EFFECT ALL THE BLOCKS IN THE FILE. THAT
          MAKES IT APPEAR WORTH WHILE TO TAKE A FEW SHOTS AT READING
          OLD BLOCKS, HOPING TO FIND ONE THAT IS EMPTY ENOUGH. IN 
          REALITY, A PURE WASTE OF TIME. THE REMEDY IS TO START 
          COUNTING ONLY WITH FSPCEMTAB[1], IN A CASE LIKE THIS. IF
          THE NEW RECORD IS EXACTLY 10 PCT. OF A BLOCK, THEN OBVIOUSLY
          IT IS LOGICAL TO START WITH FSTPCEMTAB[1], BUT IF IT IS 
          10.01 PCT., BETTER START WITH FSPCEMTAB[2]. THIS APPROACH 
          SOLVES THE PROBLEM NICELY FOR A CREATION RUN. ON THE OTHER
          HAND IT WILL CAUSE A WASTE OF SPACE IN CASE THERE ARE A LOT 
          OF BLOCKS WITH 6 PCT. FREE SPACE, AND A LOT OF RECORDS TO 
          BE ADDED TO THE FILE, THAT ARE 4 PCT. LONG. OR 16 PCT. AND
          14 PCT. RESPECTIVELY. THE WHOLE SYSTEM OF TABULATING EMPTY
          SPACE IN TABLE FSPCEMTAB IS VERY APPROXIMATE, AND WE TRY TO 
          BALANCE BETWEEN WASTING EMPTY SPACE, AND WASTING TIME 
          SEARCHING FOR AN EMPTY SPACE. AT ANY RATE, IT SEEMS GOOD TO 
          BIAS THE SYSTEM AWAY FROM WASTING SUCH A LOT OF TIME DURING 
          A CREATION RUN. 
          AFRB   02/07/80    AKDRARE
  
 *L538*    ************************************************ 
 AM2*81   AAM2 PL 
          UPDATE COPYRIGHT INFORMATION REFLECTING 1981
          CKA    80/09/11    AAMDCTL
 AM2A230  AAM2PL
          DISCRIMINATION BETWEEN 554 AND 555 ERROR CONDITIONS SHOULD
          BE MADE.
          GAG    06/23/80    OPENDAA
  
 AM2A232  AAM2PL
          CRM FATAL ERROR 532 OCCURS WHEN YOU ATTEMPT TO OPEN-NEW A FILE
          THAT ALREADY EXISTS. BUT WHEN THE FIT CALLS FOR OPENING-NEW A 
          DATA FILE AND ITS PARTNER MIP FILE, AND A FILE WITH THE SAME
          NAME AS THE MIP FILE ALREADY EXISTS, BUT NOT ONE WITH THE SAME
          NAME AS THE DATA FILE, THE ERROR MESSAGE INCLUDES THE NAME OF 
          THE DATA FILE NEVERTHELESS, BECAUSE THE FILE NAME IS ALWAYS 
          COPIED TO A MESSAGE FROM THE FIRST WORD OF THE FIT. 
             TO REMEDY THIS, THE NEW CODE ALTERS SUBROUTINE FATERR IN 
          PROGRAM OPEN$AA SO THAT THE ERROR NUMBER PASSED TO FATERR MAY 
          BE EITHER POSITIVE, INDICATING THAT THE DATA FILE NAME IS TO
          BE USED, OR NEGATIVE, INDICATING THAT THE MIP FILE NAME IS TO 
          BE USED. IN EITHER CASE, FATERR PASSES THE ABSOLUTE VALUE OF
          THE ERROR NUMBER TO THE ERROR MESSAGE ROUTINE. BUT IF THE 
          NUMBER IS NEGATIVE, FATERR SWITCHES THE TWO FILE NAMES
          WITHIN THE FIT BEFORE CALLING THE ERROR ROUTINE, AND SWITCHES 
          THEM BACK IMMEDIATELY AFTER. AT THE POINT IN OPEN$AA WHERE
          IT IS DISCOVERED THAT THE MIP FILE ALREADY EXISTS, SO THAT
          OPEN-NEW MUST FAIL, THE ERROR NUMBER PASSED TO FATERR IS
          CHANGED FROM 532B TO -532B. 
          AFRB   08/18/80    OPENDAA
  
 AM2A233  AAM2PL
          IF A DA EXTENDED FILE IS CREATED WITH NON-EMBEDDED KEYS, ALL
          OPENS AFTER THE CREATION FAIL WITH A 171 ERROR. 
          OPEN-OLD CHECKS THE HASHING ROUTINE, BUT THE KEY POINTERS 
          USED IN THIS CHECK ARE CORRECT ONLY FOR EMBEDDED KEYS, NOT
          NON-EMBEDDED KEYS. THE CORRECTIVE CODE CHANGES THOSE KEY
          POINTERS TO THE ONES THAT ARE SET BY SUBROUTINE STMD$AA,
          CORRECT FOR EITHER EMBEDDED OR NON-EMBEDDED.
          AFRB   07/10/80    OPENDAA
  
 AM2A235 AAM2PL 
          AM2A205 FIXED A PROBLEM FOR IS/MIP ONLY, NOT FOR DA/MIP AND 
          AK/MIP. (THE PROBLEM WAS THAT, BECAUSE OF ANOTHER FIX, THE
          PRIMARY KEY VALUE WAS NO LONGER BEING RETURNED WHERE PKA
          POINTED, AFTER A GETNR BY ALTERNATE KEY COMPLETED.) THIS NEW
          CODE MAKES DA AND AK BENEFIT FROM THE CORRECTION. 
          AFRB   07/28/80    AKDAK,DADDA
  
 AM2A236  AAM2PL
          A PUT OR REPLACE ON A MIPPED FILE, IF IT FAILS BECAUSE OF A 
          DUPLICATE KEY ERROR, LEAVES BEHIND RHO=1. A LATER PUT OR
          REPLACE WILL CLEAR RHO BEFORE ITS SERIOUS WORK, BUT A DELETE, 
          THINKING RHO IS NO CONCERN OF ITS OWN, WILL NOT. THE TEST IN
          WHICH RHO=1 CAUSES A 530 ERROR, HOWEVER, IS COMMON TO ALL 
          3 FUNCTIONS. SO A DELETE, IF IT FOLLOWS A PUT OR RPLC THAT HAD
          A 530 ERROR, CAN ALSO APPEAR TO HAVE A 530 ERROR, AND FAIL. 
          THE CORRECTIVE CODE ZEROS RHO AT THE BEGINNING OF THE MIP 
          WORK FOR ALL THREE FUNCTIONS. AS DELETE DOESNT TOUCH RHO, 
          THEREAFTER, THE 530 ERROR CANT HAPPEN.
          AFRB   07/31/80    NRODMIP
  
AM2A238   AAM 2.0 
          THE FLBLOCK UTILITY NEEDS TO GIVE A MORE DEFINITIVE RESULT FOR
          USABLITY.  A PRABABLE BEST RESULT MESSAGE HAS BEEN ADDED. 
          RJC    09/10/80 
 AM20065  AAM2PL
          WHEN A RECORD IS REPLACED IN A MIPPED FILE, THE CHANGES 
          ON THE MIP FILE ARE DONE BY SUBROUTINE DLT$MP IN
          MODULE NRO$MIP. THIS CALLS SUBROUTINE BIGDEL TO DELETE
          ALTERNATE KEY VALUES FROM THE OLD RECORD, AND BIGPUT
          TO ADD THOSE FROM THE NEW RECORD. BIGDEL SETS DELCOUNT
          TO THE NUMBER OF KEY VALUES IT HAS ACTUALLY DELETED, AND
          IF THIS IS 0, BIGPUT USED NOT TO HAVE TO BE CALLED. 
          BIGDEL REFRAINS FROM DELETING WHENEVER CORRESPONDING ALT
          KEY VALUES IN THE TWO RECORDS ARE THE SAME, SO WHEN ALL 
          THE ALT KEY VALUES ARE TO REMAIN UNCHANGED BY THE RECORD
          REPLACEMENT, DELCOUNT WILL BE LEFT 0 BY BIGDEL, AND BIGPUT
          WILL NOT BE CALLED (UNLESS THE TWO RECORDS DIFFER IN LENGTH). 
          BUT WHEN THE SPARSE KEY AND NULL KEY FEATURE WAS ADDED
          TO MIP, THIS BROUGHT ANOTHER REASON WHY BIGDEL MIGHT NOT
          DELETE AN OLD KEY -- THAT THIS KEY HAD NEVER BEEN ADDED 
          TO THE MIP FILE IN THE FIRST PLACE, BECAUSE IT WAS NULL 
          (SEE THE REFERENCE MANUAL ON THE TENTH PARAMETER IN AN
          RMKDEF STATEMENT.) IF THE NEW KEY IS NOT NULL, BIGPUT IS
          GOING TO HAVE TO BE CALLED, BUT DELCOUNT HAS NOT BEEN 
          STEPPED AND SO BIGPUT MAY NOT GET CALLED. 
          TO REMEDY THIS, THIS NEW CODE ADDS A NEW GLOBAL VARIABLE
          TO NRO$MIP, CALLED NULLKEY. IT IS SET TO 1 BY SUBROUTINE
          NEXSECKEY WHENEVER IT FINDS THAT A PAIR OF CORRESPONDING
          ALTERNATE KEY VALUES ARE UNLIKE EACH OTHER, BUT NO DELETE 
          IS NECESSARY BECAUSE THE OLD VALUE IS NULL. DLT$MP SETS 
          NULLKEY=0 BEFORE THE ORDINARY CALL TO BIGDEL. THEN, IN
          CASE OF A REPLACE, IT TESTS NULLKEY AFTER BIGDEL, BEFORE
          CALLING BIGPUT, AS ONE OF THE GROUNDS FOR DECIDING
          WHETHER BIGPUT NEEDS TO BE CALLED.
          AFRB   05/20/80    NRODMIP
  
 AM20070  AAM2PL
          WHEN A USER OPENS A NEW IS,DA,OR AK FILE WITHOUT SPECIFYING 
          MBL (BLOCK SIZE), A VALUE IS WORKED OUT IN SUBROUTINE MBLCOMP 
          OF MODULE OPEN$AA. HOWEVER, ACCOUNT IS NOT TAKEN OF THE GIVEN 
          VALUE OF DP (DATA BLOCK PADDING PERCENTAGE). LATER, A CHECK IS
          MADE TO SEE THAT AT LEAST ONE MAXIMUM-SIZE RECORD COULD FIT 
          INTO THE CHOSEN SIZE OF BLOCK WITHOUT VIOLATING THE GIVEN DP. 
          IF THIS CHECK FAILS, IT IS A FATAL ERROR, AND A USER WHO
          SPECIFIED DP BUT NOT MBL WOULD BE ANNOYED.
          THE CORRECTIVE CODE ADDS A FEW LINES TO MBLCOMP TO ENSURE THAT
          WHEN MBL IS CHOSEN BY THE SYSTEM RATHER THAN THE USER, IT WILL
          BE BIG ENOUGH TO SATISFY DP AS WELL AS MRL. THESE LINES ARE 
          PLACED SO AS TO BE EXECUTED IN THE CASE WHEN MBL IS SET BY
          THE USER, AS WELL AS THE CASE WHEN THE SYSTEM CHOOSES IT, 
          BECAUSE THEN THE EXISTING CHECK ON WHETHER THE USER-SPECIFIED 
          MBL IS BIG ENOUGH FOR MRL BECOMES REDUNDANT AND CAN BE
          REMOVED.
          AFRB   06/30/80    OPENDAA
  
AM2A239  AAM 2.0
          FLBLOK NEEDS TO REFLECT THE 844-41 DISK DRIVE WHICH HAS BECOME
          MORE COMMON IN THE FIELD. 
          RJC    09/19/80    FLBLOCKF 
 AM2A241  AAM2PL
          AT VARIOUS POINTS IN THE AK-EXTENDED CODE, WE TRY TO START
          READING THE BEGINNING OF THE FILE AT PRU 3. BUT IF THE FILE 
          HAS NEVER HAD A SINGLE RECORD PUT INTO IT, PRU 3 IS EOI AND 
          WE GET A FATAL ERROR. TO CURE THIS, THE CORRECTION CODE CHECKS
          IN ADVANCE OF THOSE POINTS WHETHER THE PUT    COUNT IS 0, AND 
          IF SO, AVOIDS READING THE FILE AT ALL.
          AFRB   10/22/80    AKDAK
 AM2A242  AAM2PL
          THE OPEN-NEW ROUTINES DO NOT CHECK AGAINST VALUES GREATER THAN
          99 IN THE DP AND IP (DATA AND INDEX BLOCK PADDING PERCENTAGE) 
          FIELDS OF THE FIT.
          AFRB   10/17/80    OPENDAA
  
 AM20078  AAM2PL
          THERE ARE 3 FLAGS CALLED CHANGE[1..3] IN MIP$MIP, REFERRING TO
          THE 3 POSSIBLE SUB-FILE LEVELS IN A MIP FILE, THAT REALLY 
          OUGHT TO BE A SEPARATE SET FOR EACH FIAT, BUT IN FACT ARE 
          GLOBAL TO ALL OPEN MIP FILES. THE ERROR INTRODUCED BY THIS
          GLOBALITY IS AN ERROR IN THE DIRECTION OF CAUTION, HOWEVER. 
          IT CAN HAPPEN THAT WHEN ONE MIP FILE IS ALTERED, THE PROGRAM
          THINKS AS A RESULT THAT ANOTHER MIP FILE IS ALSO ALTERED, 
          AND TRIES TO WRITE OUT A SUPPOSEDLY ALTERED BLOCK OF THE FILE 
          THAT HAS NOT BEEN ALTERED. THIS DOES NO HARM, BEYOND
          WASTING TIME, UNLESS THE FILE DOES NOT HAVE WRITE 
          PERMISSION, IN WHICH CASE UNNECESSARY ERROR MESSAGES ARE
          GENERATED.
  
          TO CURE THIS, WE IGNORE THESE CHANGE FLAGS WHEN DEALING WITH
          A MIP FILE THAT DOES NOT HAVE WRITE PERMISSION. WE KNOW THE 
          FILE CANNOT REALLY HAVE BEEN ALTERED, BECAUSE ANY UPDATE
          OPERATION BEGINS BY TESTING THE PERMISSIONS, AND IF NO WRITE
          PERMISSION, THE OPERATION CHANGES NOTHING.
          AFRB   10/15/80    MIPDMIP
  
 *L552*    ************************************************ 
 AM2A246  AAM2PL
          WHEN A FILE IS BEING CREATED, RKP=10 IN THE FIT, INSTEAD OF 
          BEING AN ERROR, IS TAKEN TO MEAN EMK=NO, AND WILL OVERRIDE AN 
          ACTUAL EMK=YES. THIS CORRECTIVE CODE MAKES RKP=10 AN ERROR IF 
          EMK=YES. (IF EMK=NO, RKP IS SOMEWHAT IRRELEVANT, AND IN FACT
          AAM INTERNALLY USES RKP=10 TO MEAN NON-EMBEDDED KEY.) 
          HOWEVER, RKP=10 CONTINUES TO HAVE A LEGAL AND NECESSARY 
          MEANING WHEN DEALING WITH A MIPPED FILE WHOSE PRIMARY KEY 
          IS NON-EMBEDDED. RKP=10 IS THEN THE WAY OF SIGNALLING 
          AAM TO SWITCH FROM ANY ALTERNATE KEY, BACK TO THE PRIMARY 
          KEY.
          AFRB   11/19/80    OPENDAA
  
 AM2A248  AAM2 PL 
          CHANGES FLBLOCK REFERENCE FROM CONTROL CARD TO
          CONTROL STATEMENT.
          JRL  12/18/80  FLBLOCKF 
  
 AM2A251  AAM2PL
          THERE IS A FLAW IN THE LOGIC OF AK THAT ALLOWS PUT
          WITHOUT KEY TO USE A SLOT IN THE LAST BLOCK WHOSE 
          KEY IS JUST ABOVE THE LIMIT SET BY KEY SIZE. THIS 
          CODE CORRECTS IT BY FORBIDDING THE LAST BLOCK, IF IT WOULD
          CONTAIN FORBIDDEN SLOTS. THE MAXIMUM KEY VALUE IS DIVIDED BY
          THE BLOCKING FACTOR, GIVING A QUOTIENT AND A REMAINDER. THE 
          QUOTIENT IS THE MAXIMUM NUMBER OF DATA BLOCKS THAT WILL BE
          ALLOWED, WHILE THE REMAINDER (WHICH DOES NOT BECOME EXPLICIT
          IN THIS PROGRAM) IS THE NUMBER OF KEY VALUES AT THE TOP OF THE
          RANGE THAT WILL NOT BE ACCEPTED FOR PUT-WITH-KEY, EVEN THOUGH 
          THE KEY LENGTH CAN ACCOMMODATE THEM. HOWEVER, IN THE EXTREME
          CASE THAT THE BLOCKING FACTOR IS ABOVE THE MAXIMUM POSSIBLE 
          KEY, APPARENTLY FORBIDDING ALL KEY VALUES, WE JUST REDUCE THE 
          BLOCKING FACTOR TO THE MAXIMUM KEY VALUE, AND ALLOW ONE DATA
          BLOCK.
          AFRB   02/12/81    OPENDAA,NRODAK 
  
 AM2A255  AAM2PL
          FATAL ERROR 202, WHICH CAN OCCUR DURING THE OPENING OF AN AAM 
          FILE, DOES NOT SET THE BFF BIT IN THE FIT, EVEN THOUGH THIS 
          ERROR INDICATES THAT THERE IS A GOOD PROBABILITY THAT THE 
          FILE IS BAD IN SOME WAY. THE CORRECTIVE CODE CAUSES 202 TO
          SET THE FLAG, WHICH WILL BE USEFUL TO CDCS. 
  
 AM2A256  AAM2PL
          IF A START OPERATION IS DONE,BY PRIMARY KEY, ON AN I-S FILE,
          WITH 0 IN THE REL FIELD OF THE FIT, AND A MATCHING KEY IS 
          NOT FOUND IN THE FILE, THE FILE IS LEFT POSITIONED ON THE 
          NEXT HIGHER RECORD, BUT THE ES FIELD OF THE FIT IS USUALLY
          LEFT 0, NOT 445 AS ONE MIGHT EXPECT.
  
          THE 445 (KEY-NOT-FOUND ERROR) WILL OCCUR IF, JUST BEFORE
          THE START WAS DONE, THE FILE WAS ALREADY POSITIONED AT
          SOME RECORD IN THE SAME DATA BLOCK AS THE RECORD WHERE
          IT WILL BE POSITIONED AFTER THE START.
  
          WHEN THE ES FIELD IS 0, THIS IS BECAUSE THE 0 IN THE REL
          FIELD OF THE FIT HAS BEEN TREATED AS IF IT WERE THE CODE
          FOR GREATER-OR-EQUAL INSTEAD OF EQUAL -- IT IS NOT 1 (EQ) 
          AND NOT 6 (GT) SO IT ((MUST)) BE 3 (GE). THE 0 POSSIBILITY
          WAS FORGOTTEN AT THIS POINT IN THE CODE. MIP START IS ALL 
          RIGHT, AND GET IS ALL RIGHT, BECAUSE IT USES EQ ANYWAY, 
          THE FILE POSITION IS ALL RIGHT EVEN THOUGH THE 445 ERROR
          IS NOT ISSUED IN THE BAD CASE, SO THIS BUG HAS TAKEN A
          LONG TIME TO SURFACE. THE REMEDY IS TO MAKE SURE THAT 
          SUBROUTINE KPTR$IS, IN PROGRAM IS$IS, TREATS REL=0 AS IF
          REL=1.
          AFRB   04/01/81    ISDIS
  
 AM20079  AAM2PL
          SOME USERS WOULD LIKE TO BE ABLE TO CHECK THEIR RMKDEF
          STATEMENTS, BEFORE ACTUALLY CALLING MIPGEN, TO SEE THAT 
          THE ALTERNATE KEY FIELDS WILL BE DEFINED WHERE THEY 
          EXPECT. THIS CODE PROVIDES A SIMPLE CHECK, WHICH CAN BE 
          CALLED THROUGH FLSTAT.
          AFRB   10/30/80    FLSTAT,FLSTATC 
 AM20082  AAM2PL
          IN PROGRAM IS$IS, WHEN SUBROUTINE EZKY$IS IS CALLED TO
          LOCATE WHERE TO PUT A NEW RECORD IN AN IS FILE, IT TAKES A
          SHORT CUT THAT DEPENDS ON ALL THE WORDS IN THE PTREE BEING
          CORRECTLY FILLED IN. BUT IT NEGLECTS TO CHECK WHETHER THE 
          WORDS OF THE PTREE, ABOVE THE CURRENT LEVEL, ARE VALID. 
          THE PROPER CHECK IS TO SEE THAT THE RECORD NUMBER AT LEVEL
          0 OF THE PTREE IS NOT ZERO, FOR THIS NUMBER IS ZEROED 
          WHENEVER WE TAKE A POSITION IN THE FILE WITHOUT COMPLETELY
          FILLING IN THE PTREE (BY CROSSING FROM THE END OF ONE DATA
          BLOCK TO THE BEGINNING OF THE NEXT ONE, USING THE FORWARD 
          POINTER IN THE FORMER DATA BLOCK, RATHER THAN USING INDEX 
          RECORDS.) 
          AFRB   02/03/81    ISDIS
  
 AM20085  AAM2PL
          WHEN AN IS EXTENDED FILE USES COMPRESSION, IS MIPPED, AND 
          HAS COLLATED KEYS, DELETE DOES NOT WORK PROPERLY. WHENEVER
          A RECORD IS DELETED MERELY BY HAVING ITS RECORD POINTER 
          FLAGGED AS DEAD, THE KEY OF THE RECORD IS LEFT IN UNCOLLATED
          FORM INSTEAD OF COLLATED AS IT SHOULD BE. THIS CAN DISRUPT
          ANY ROUTINE THAT IS LATER DOING A BINARY SEARCH OF THE
          BLOCK LOOKING FOR SOME OTHER KEY. 
  
          THE TROUBLE IS THAT IN SUBROUTINE DLT$MP OF PROGRAM NRO$MIP,
          MPRECAF IS SET TO THE FWA OF THE RECORD AS IT SITS IN THE 
          BLOCK IMAGE. THE KEY OF THE RECORD IS DECOLLATED TEMPORARILY
          FOR CONVENIENCE, AND GOOGOO IS SET NON-ZERO TO SHOW THIS HAS
          HAPPENED. AT THE END OF THE SUBROUTINE, IF GOOGOO IS NON- 
          ZERO, THE KEY IS RE-COLLATED BEFORE THE BLOCK IMAGE IS
          RELEASED. IF COMPRESSION WAS NOT INVOLVED, MPRECAF IS 
          UNCHANGED AND ALL IS WELL. BUT IF THERE WAS COMPRESSION,
          MPRECAF HAS BEEN ALTERED TO POINT TO A DECOMPRESSED VERSION 
          OF THE RECORD, AND THE KEY IN THIS VERSION, NOT IN THE BLOCK, 
          GETS RE-COLLATED. 
  
          THE REMEDY IS, IF GOOGOO IS SET NON-ZERO, TO USE IT AS AN 
          EXTRA POINTER WHICH GOES THROUGH THE SUBROUTINE UNCHANGED,
          AND CAN BE USED TO SHOW WHERE TO RE-COLLATE AT THE END. 
          AFRB   03/14/81    NRODMIP
  
 AM20087  AAM2PL
          THIS SURFACED AS A MIP BUG, BUT IS REALLY IN THE IS EXTENDED
          PROCESSOR, IN SUBROUTINE EZKY$IS OF MODULE IS$IS. SUPPOSE THE FILE
          IS CURRENTLY POSITIONED ON A RECORD IN THE MIDDLE OF A BLOCK THAT 
          DOES NOT HAVE UNIFORM RECORDS, IN WHICH THE FIRST RECORD IS DEAD
          (PREVIOUSLY DELETED). NOW SUPPOSE WE DO A RANDOM GET, USING THE 
          KEY OF THAT FIRST, DEAD, RECORD. IF THERE IS NO APPARENT
          REASON FOR MAKING A FRESH START AT THE PRIMARY INDEX BLOCK, THE 
          PROGRAM WILL POSITION THE FILE AT THE FIRST LIVE RECORD IN
          THAT DATA BLOCK, AND DECLARE THAT THERE IS NO RECORD IN THE 
          FILE MATCHING THE GIVEN KEY. THIS NEGLECTS THE POSSIBILITY
          THAT THE PRECEDING DATA BLOCK MAY CONTAIN A MATCHING RECORD,
          ADDED SOME TIME AFTER THE DEAD RECORD WAS DELETED.
              THE CORRECTIVE CODE FORCES A FRESH START IN SUCH A CASE,
          AND SO ALLOWS A MATCHING RECORD IN THE PRECEDING BLOCK TO 
          BE FOUND. 
          AFRB   03/24/81    ISDIS
  
 AM20090  AAM2PL
          PROGRAM OPEN$AA HAS SEVERAL CALLS TO CMM ROUTINES, WHICH WILL 
          BE UNSATISFIED IF CMM IS NOT LOADED. ALL BUT ONE ARE PROTECTED
          FROM BEING EXECUTED BY ((IF NOT NOCMM)) OR BY A CHECK THAT
          A BLOCK IS NOT IN USER SPACE, SO THAT IT MUST BE IN CMM SPACE.
          (NOCMM IS A BIT THAT IS SET AT THE BEGINNING OF OPENDAA IF
          CMM IS FOUND NOT TO BE LOADED.) THE ONE UNPROTECTED CALL IS 
          TO CMM$GOS (INTERFACE TO CMM.GOS) IN SUBROUTINE STRG$AA.
          TO PROTECT THIS CALL, CORRECTIVE CODE MAKES STRG$AA 
          EXIT WITHOUT DOING ANYTHING IF NOCMM IS TRUE. 
          AFRB   04/13/81    OPENDAA
  
 AM20094  AAM2PL
          SUBROUTINE SPAC$AK, IN MODULE NRO$AK, SCANS THE BLOCKS IN CORE
          TO SEE IF ANY HAS ROOM FOR A GIVEN NEW RECORD. IT NEGLECTS TO 
          CHECK THE READ-IN-PROGRESS IN THE PREAMBLE TO EACH BLOCK, SO
          THAT OCCASIONALLY IT LOOKS AT WHAT IS IN FACT THE IMAGE OF
          A DISCARDED BLOCK, AND DECIDES THAT A BLOCK THAT HAS NOT
          REALLY BEEN READ IN YET HAS A FREE SLOT AND ENOUGH SPACE. 
          A RE-CHECK IS DONE LATER ON THE EMPTY SPACE NUMBER, BUT 
          NOT ON THE FREE SLOT COUNT, SO THIS CAN RESULT IN 11 RECORDS
          BEING PUT INTO A BLOCK WHEN THE BLOCKING FACTOR IS 10.
          THE REMEDY IS TO ADD A CHECK FOR THE READ-IN-PROGRESS BIT,
          AND IF IT IS SET, NOT TO CONSIDER THAT BLOCK AS A 
          POSSIBILITY.
          AFRB   05/28/81    NRODAK 
  
 *L564*    ************************************************ 
 AM2*82   AAM2 PL 
           UPDATE COPYRIGHT INFORMATION REFLECTING 1982 
          KLS    81/09/08    AAMDCTL
  
 AM2A257  AAM2PL
          THERE IS A PIECE OF CODE IN SUBROUTINE MALR$AK, IN MODULE 
          AK$RARE, WHICH IS PROBABLY NEVER EXECUTED. IF IT WERE EXECUTED
          IT MIGHT RUIN THE FILE. SO THIS CORRECTIVE CODE REMOVES IT, 
          ALSO REMOVES A SUBROUTINE CALLED CYCL$AK, IN MODULE OVFM$AK,
          WHICH IS CALLED ONLY FROM THE CODE BEING REMOVED FROM MALR$AK.
          IF THE CODE IN QUESTION WORKED PROPERLY, IT WOULD BE CALLED 
          ONLY DURING A PUT-WITH-KEY, WHEN THE DESTINATION SLOT TURNS 
          OUT TO CONTAIN AN OVERFLOW RECORD. FIRST WE TRY TO MOVE THE 
          OVERFLOW RECORD BACK TO ITS HOME BLOCK. BUT IF THERE IS NO
          ROOM THERE, THE SECOND CHOICE IS TO MOVE THE OVERFLOW 
          RECORD TO A DIFFERENT SLOT IN THE BLOCK THAT ALREADY
          CONTAINS IT. THE THIRD CHOICE IS TO MOVE IT TO SOME 
          DIFFERENT BLOCK. THE SECOND CHOICE IS NEVER MADE, BECAUSE 
          THE PROGRAM LOOKS AT THE HOME BLOCK OF THE OVERFLOW 
          RECORD WHEN IT SHOULD BE LOOKING AT THE BLOCK THAT
          CONTAINS IT, AND THE HOME BLOCK IS NOT LIKELY TO HAVE 
          ENOUGH EMPTY SPACE TO PASS THE TEST WHICH THE PROGRAM 
          THINKS IT IS APPLYING TO THE OTHER BLOCK. 
          AFRB   05/27/81    NRODAK,OVFMDAK 
  
 AM2A258  AAM2PL
          MODULE AK$AK LACKS CODE FOR HANDLING SITUATIONS IN SKIP OR
          GETNEXT, WHEN THE FILE  HAS BEEN
          SET AT EOI BY AN ATTEMPT TO GET BY A KEY THAT POINTS
          BEYOND THE LAST EXISTING BLOCK. 
          AFRB   05/29/81    AKDAK
  
 AM2A262  AAM2PL
          THE MODIFICATION TO FLSTAT, ENABLING A  USER TO CHECK RMKDEF
          STATEMENTS BEFORE INVESTING TIME IN MIPGEN, CONTAINS A BUG
          THAT DECLARES AN ERROR FALSELY, IF THE FILE NAME IS LESS THAN 
          3 CHARACTERS LONG, OR IF THE LAST DIGIT OF AN ALTERNATE KEY 
          LENGTH PARAMETER FALLS TO THE RIGHT OF THE 19TH CHARACTER IN
          AN RMKDEF STATEMENT. THIS NEW CODE CORRECTS IT. 
          AFRB   09/10/81    FLSTATC
  
 AM2A263  AAM2PL
          AAM CAN EXPERIENCE, IN TWO WAYS, A REFUSAL BY CMM TO GRANT A BLOCK
          OF MEMORY. (1) WHILE TRYING TO LOAD A CAPSULE (2) WHEN ASKING 
          FOR A BUFFER TO HOLD A FILE BLOCK. AAM ITSELF IS NOT IN A POSITION
          TO RESPOND TO THIS REFUSAL, BECAUSE OF THE PECULIAR WAY CMM WORKS.
          IT IS NOT THE CASE THAT CMM RETURNS TO THE CALLER WITH SOME FLAG
          INDICATING REFUSAL. INSTEAD, AFTER ALL THE POSSIBLE OVERFLOW
          ACTION ROUTINES HAVE BEEN CALLED WITHOUT ENOUGH SUCCESS, CMM
          CALLS AN OWNCODE ROUTINE THAT HAS PREVIOUSLY BEEN INDICATED TO IT 
          AS THE FINAL FAILURE ROUTINE. THERE CAN ONLY BE ONE OF THESE AT 
          A TIME, SO AAM, THE HELPER OF MANY, SHOULD NOT PRE-EMPT THIS SLOT 
          WITH ITS OWN FINAL FAILURE ROUTINE. INSTEAD, THE HOST PROGRAM 
          (IN PRACTICE CDCS) SHOULD SUPPLY THE FINAL FAILURE ROUTINE, AND 
          DECIDE, WHEN THAT ROUTINE IS CALLED, WHERE THE UNSATISFIED CMM
          CALL CAME FROM. IF IT CAME FROM AAM, THE HOST PROGRAM SHOULD
          CALL THE AAM SUBROUTINE CMMX$AA, WHICH WE ARE NOW FURNISHING, AND 
          THEN CLOSE THE FILE (CLOSE ALL THE FITS ACCESSING IT.) THE FILE 
          MAY THEN HAVE ITS ((RUINED)) FLAG SET, BUT AT LEAST THE DAMAGE
          WILL BE CONFINED TO THAT ONE FILE.
  
          SUBROUTINE CMMX$AA MAKES SURE THAT NO BLOCKS OR RARE CAPSULES 
          ARE LEFT UN-LINKED TO THE KICK-OUT CHAIN, SO THAT THE BLOCKS CAN
          BE RELEASED BY CLOSING THE FILE, AND A RARE CAPSULE WILL NOT
          APPEAR TO BE IN AN ANOMALOUS STATE. (IN THE RUN THAT CAUSED THIS
          PSR, CMM REFUSED A BLOCK TO AAM, NO OVERFLOW ACTION WAS ENOUGH, 
          AND THE CDCS LAST-RESORT ROUTINE WAS FINALLY CALLED BY CMM. 
          CDCS TRIED TO CLOSE THE FILE AND GO ON, BUT THE RARE$IS CAPSULE 
          HAD BEEN LEFT UNLINKED, AND THE NEXT TIME IT WAS CALLED FOR IT
          CAUSED AN ABORT.) 
  
          WE DO NOT ATTEMPT TO DO ANYTHING FOR THE LOADING OF NON-RARE
          CAPSULES. THEY ARE LOADED IN RESPONSE TO AN OPEN, AND IF
          THERE IS A CMM REFUSAL AND CDCS GETS CONTROL, NO BLOCKS OR RARE 
          CAPSULES CAN BE EXPECTED TO BE LEFT UNLINKED. IF THE CDCS LAST- 
          RESORT ROUTINE GETS CONTROL, IT SHOULD JUST RECOGNIZE THAT THE
          OPEN IS IMPOSSIBLE, AND GIVE IT UP. 
  
          WHENEVER A RARE CAPSULE IS CALLED (SUCH A CAPSULE HAS ONLY ONE
          ENTRY POINT) WE SET CALCODE TO AN INTEGER BETWEEN 0 AND 7 OR SO,
          AND CALL CCAL$AA IN AAM$CTL. CCAL$AA DECIDES WHETHER THE CAPSULE
          INDICATED BY THE NUMBER IS LOADED OR NOT. IF NOT, IT LOADS IT.
          IF ALREADY LOADED, CCAL$AA DE-LINKS IT FROM THE KICK-OUT CHAIN, 
          SO THAT AAM MEMORY MANAGEMENT WILL NOT KICK IT OUT WHILE
          EXECUTING IT. THEN CCAL$AA DOES A RETURN JUMP TO THE ENTRY POINT. 
          ON RETURN FROM THE CAPSULE, CCAL$AA RE-LINKS IT IN THE CHAIN. 
  
          THE VARIABLE CALCODE IS NOT USED ANYWHERE ELSE, SO THIS NEW CODE
          EXTENDS THE WAY CCAL$AA USES IT. ONCE THE CAPSULE IS READY TO BE
          RETURN-JUMPED TO, WE SET CALCODE NEGATIVE, AS A SIGNAL THAT THERE 
          IS A DE-LINKED RARE CAPSULE IN MEMORY. WHEN THE RETURN JUMP IS
          MADE, AND CONTROL COMES BACK TO CCAL$AA, WE RESTORE CALCODE TO
          ITS PREVIOUS POSITIVE VALUE.
  
          IF CALCODE IS NEGATIVE WHEN CCAL$AA IS ENTERED (WHICH WOULD NEVER 
          HAPPEN ORDINARILY) CCAL$AA WILL NOW JUMP STRAIGHT TO THE POINT
          TO WHICH CONTROL WOULD HAVE RETURNED IF THE CAPSULE HAD BEEN
          SUCCESSFULLY EXECUTED, SO THAT THE CAPSULE WILL BE RE-LINKED
          INTO THE KICK-OUT CHAIN.
  
          IF THE NEW ROUTINE CMMX$AA IS CALLED BY THE CDCS LAST-RESORT
          ROUTINE, IT SHOULD BE BECAUSE CMM REFUSED TO PROVIDE SPACE
          FOR EITHER A BLOCK OR A RARE CAPSULE. IF A RARE CAPSULE,
          CALCODE WILL BE POSITIVE, AND WE DO NOT HAVE TO DO ANYTHING 
          ABOUT THE CAPSULE. ALL WE WORRY ABOUT IS A RARE CAPSULE THAT
          WAS ACTUALLY BEING EXECUTED WHEN THE REFUSAL TOOK PLACE,
          AND ONLY ONE RARE CAPSULE AT A TIME IS ACTUALLY WORKED WITH 
          (OTHERS MAY BE LYING AROUND IN MEMORY IN CASE THEY WILL BE
          WANTED, BUT THEY ARE ALL LINKED UP AND CAUSE NO TROUBLE.) 
          IF CMM REFUSED SPACE FOR A BLOCK, CALCODE IS NEGATIVE IFF 
          A RARE CAPSULE IS NOW BEING EXECUTED, SO WE LEAVE CALCODE 
          NEGATIVE IN THAT CASE, AND CALL CCAL$AA JUST TO RE-LINK 
          THE CAPSULE.
  
          NOW FOR ANY BLOCKS THAT MAY BE UNLINKED. AAM HAS AN ARRAY 
          OF 4 SLOTS CALLED FIXHOLD, WHICH HOLD POINTERS TO ANY 
          BLOCKS THAT MAY BE CURRENTLY UNLINKED (THEY ARE DELINKED
          TO KEEP THEM FROM BEING MOVED.) SUBROUTINE UNFX$AA IS 
          CALLED WITH PARAMETERS 0 THROUGH 3, TO LOOK AT THESE 4
          SLOTS, AND WHENEVER A SLOT CONTAINS NON-ZERO, TO RE-LINK
          THE BLOCK POINTED TO, AND ZERO THE SLOT.
  
          THIS LEAVES AAM IN A POSITION TO CLOSE THE FILE ON
          REQUEST, BECAUSE EVERYTHING IS LINKED INTO THE KICK-OUT 
          CHAIN THAT WOULD HAVE BEEN SO LINKED IF THE FAILED
          AAM REQUEST HAD BEEN COMPLETED. 
  
          AFRB   09/23/81    AAMDCTL,AAMDAA 
  
 AM2A264  AAM2PL
          PROBLEM - WHEN A FATAL ERROR OCCURS ON AN AAM FILE, AND 
          THE CM FIELD IN THE FIT IS SET TO 1, AAM INTERNALLY TAKES 
          A DMP-TYPE DUMP OF ONLY THE FIRST 200000 WORDS OF THE 
          FIELD LENGTH. 
          SOLUTION - CHANGE THE DUMP REQUEST TO REQUEST A DUMP OF 
          THE FIRST 377777 WORDS OF THE FIELD LENGTH (I.E., THE 
          ENTIRE FIELD LENGTH), AND TO USE A DMD-TYPE DUMP REQUEST
          ON NOS. 
          CFR    81/10/06    CRA1DAA
  
 AM2A267  AAM2PL
          AT THE BEGINNING OF THE ROUTINE THAT WRITES A BLOCK,
          MODULE AAM$AA LOOKS AT THE FSTT TO WHICH THE BLOCK
          BELONGS. BUT INSTEAD OF GETTING THE FSTT ADDRESS
          FROM THE PREFIX OF THE BLOCK, IT JUST ASSUMES THE 
          CURRENT FSTT POINTER IS CORRECT. OCCASIONALLY,
          DURING A CLOSE OPERATION, THE POINTER WILL NOT
          BE CORRECT (IT WILL REFER TO THE FILE THAT HAS
          BEEN CLOSED) AND IT MAY EVEN POINT BEYOND  THE
          FIELD LENGTH. 
          THIS CORRECTIVE CODE GETS THE PROPER FSTT 
          ADDRESS AT THIS TIME. 
          AFRB   11/12/81    AAMDAA 
  
 AM2A273  AAM2PL
          FOR PERFORMANCE REASONS, TAF WANTS TO BE ABLE TO FLUSH THE
          ALTERED BLOCK IMAGES OF A FILE, WITHOUT WRITING ITS FSTT. 
          THIS CODE DEFINES A HITHERTO UNUSED BIT IN THE FIT, BIT 32
          OF THE 14TH WORD OF THE FIT. FLSH$AA IS CALLED WITH, AS 
          PARAMETER, A LIST OF FIT POINTERS. IF THIS LIST IS NOT
          EMPTY, AND THE FIRST FIT IT POINTS TO HAS THE NEW BIT SET 
          TO 1, THEN ALL THE FILES IN THE LIST WILL BE FLUSHED, 
          EXCEPT THAT THEIR FSTT-S WILL NOT BE WRITTEN OUT. IN
          PRACTICE, THE BIT WILL PROBABLY BE SET ONLY IN CASES WHEN 
          THE LIST OF FIT POINTERS CONTAINS JUST ONE POINTER, AND 
          JUST ONE FILE IS BEING FLUSHED, AFTER AN UPDATE OPERATION.
          AFRB   12/23/81    AAMDAA,AAMFITDCL 
  
 AM20058  AAM2PL
**********  THIS MOD IS NOT EFFECTIVE UNLESS THE MOD WITH IDENT 
*         ((RECOVR)) HAS BEEN APPLIED TO THE BAM OLDPL .
* 
          WHEN THE AAM CONTROLLER SETS UP A REPRIEVE ROUTINE BY CALLING 
          SETUP., THE MASK LACKS THE BIT FOR TERMINAL INTERRUPT UNDER 
          NOS. THIS CORRECTIVE CODE ADDS THE BIT TO THE MASK. IT ALSO 
          CHANGES THE REPRIEVE ROUTINE ITSELF SO THAT ITS ENTRY POINT 
          WORD WILL ALWAYS (EXCEPT IMMEDIATELY AFTER IT HAS BEEN
          RETURN-JUMPED TO) CONTAIN THE CHARACTERS ((AAMFLUSH  )).
          THIS ENABLES ANY SYSTEM PROGRAM THAT KNOWS HOW TO FIND THE
          REPRIEVE STACK TO SCAN THAT STACK, FIND THE AAM REPRIEVE
          ROUTINE IF IT IS ON THE STACK, AND EXECUTE THE AAM REPRIEVE 
          ROUTINE WITHOUT LETTING THE NORMAL REPRIEVE MECHANISM 
          OPERATE. IN PRACTICE, IT IS ONLY THE CYBER INTERACTIVE
          DEBUG THAT NEEDS THIS, IN ORDER TO FLUSH AAM FILES WHEN A 
          USER TYPES ((QUIT)).
          AFRB   10/14/81    OPNMDAA MISCDAA
  
 AAM 2.0 PL 
          ENSURE THE SDAENDH ENTRY POINT IS PROPERLY DEFINED SO AS
          NOT TO CLOBBER THE FIRST WORD OF CODE ON A RETURN JUMP CALL.
          KLS    81/07/27    KEYA 
  
 AM20100  AAM2PL
          WITH AN AK FILE, A GET-NEXT-WITHOUT-RECALL, IF IT DOES NOT
          COMPLETE, MAY LEAVE BEHIND A NON-ZERO IN PTREEWRD[4]. THIS
          IS A VALID HELP TO A FOLLOWING GET-NEXT OR GET-NEXT-WITHOUT-
          RECALL, BUT A FOLLOWING GET-BY-KEY IS MEANT TO DISREGARD
          AND CANCEL IT. UNFORTUNATELY, SUBROUTINE FOLLOW IN PROGRAM
          AK$AK, IF CALLED BY GET$AK UNDER THESE CONDITIONS, IS 
          CONFUSED BY NON-ZERO IN PTREEWRD[4], AND FATAL ERROR 553
          IS PRODUCED. THE CORRECTIVE CODE NEUTRALIZES THIS DANGER
          BY ZEROING PTREEWRD[4] AT THE BEGINNING OF EVERY GET-BY-KEY 
          IN AN AK FILE.
          AFRB   09/24/81    AKDAK
  
 AM20104  AAM2PL
          AM20078 CONCERNED A CASE WHERE A JOB ABORTED BY TRYING TO WRITE 
          OUT A BLOCK IN A MIP FILE THAT DID NOT HAVE WRITE PERMISSION. 
          WRITING OUT THE BLOCK WOULD NOT INJURE THE FILE, AND THE CASE 
          DID NOT HAPPEN FREQUENTLY, SO WE CORRECTED IT BY BY-PASSING 
          THE CODE THAT LED TO THE WRITE, IF THE FILE DID NOT HAVE ALL
          PERMISSIONS.
  
          IT TURNS OUT THAT THERE IS STILL A WAY TO FALL INTO THAT TRAP.
          THE FILE MAY HAVE ALL THE PERMISSIONS, BUT BE OPEN FOR INPUT
          ONLY. FOR THE BAD CASE TO ARISE, THERE MUST BE SOME MIP FILE
          THAT HAS BEEN ALTERED BY THE CURRENT JOB STEP, BUT IT MAY HAVE
          BEEN CLOSED, AND THIS MAY HAVE LED TO THE UNLOADING OF THE
          CAPSULES THAT ARE NEEDED ONLY FOR UPDATING. SO THE TEST FOR 
          ALL PERMISSIONS PASSES, BUT THE JOB ABORTS CALLING AN UNLOADED
          SUBROUTINE. 
  
          TO CORRECT THIS, WE COULD ADD TO THE TEST IN AM20078 EITHER 
          A TEST OF THE PROCESSING DIRECTION OF THE CURRENT FILE
          (MUST NOT BE INPUT) OR A TEST FOR WHETHER THE MIP-UPDATE
          CAPSULE IS NOW LOADED. TO AVOID CONFUSION IF THERE ARE TWO
          OPEN FITS FOR THE SAME MIP FILE, ONE OPEN FOR READ-ONLY 
          (PD=INPUT) AND THE OTHER OPEN FOR READ AND UPDATE, THE
          FOLLOWING CORRECTION CODE TESTS FOR THE PRESENCE OF THE 
          CAPSULE, RATHER THAN THE PD OF THE CURRENT FIT. 
          AFRB   10/06/81    MIPDMIP
  
 AM20106  AAM2PL
          THIS IS AN EXTENSION TO AM20087. IN SUBROUTINE EZKY$IS, MODULE
          IS$IS, TRYING TO LOCATE A RECORD BY KEY IN AN IS FILE, WE 
          FIRST LOOK AT THE CURRENT DATA BLOCK, BEFORE RESTARTING AT
          THE TOP OF THE INDEX TREE. THE ORIGINAL CODE NEGLECTED THE
          CASE WHERE THE KEY MATCHED THE FIRST RECORD OF THE CURRENT
          BLOCK, BUT THAT RECORD HAD ALREADY BEEN DELETED. AM20087
          SAID THAT IN THAT CASE AAM THOUGHT THERE WAS NO MATCHING
          RECORD, WHEREAS THERE MIGHT BE ONE IN A LOGICALLY PRECEDING 
          BLOCK. THIS WOULD BE A LATER VERSION OF THE RECORD THAN 
          THE DEAD RECORD IN THE CURRENT BLOCK. 
  
          THOUGH THAT WAS CORRECTED, WE DID NOT CONSIDER THE CASE 
          WHERE, LET US SAY, THE FIRST 3 RECORDS IN THE CURRENT BLOCK 
          ARE DEAD, AND THE KEY MATCHES THE 3RD OF THEM. THIS WILL
          PRODUCE A NO-MATCH ERROR, ALTHOUGH A MATCHING RECORD MIGHT
          EXIST IN A LOGICALLY PRECEDING BLOCK. 
  
          THE CORRECTIVE CODE REPLACES THE CORRECTIVE CODE OF AM20087 
          WITH A MORE GENERAL PROVISION -- IF RECORD 1 OF THE CURRENT 
          BLOCK IS DEAD, DONT TRY THE SHORT CUT, BUT CALL SUBROUTINE
          GOKY$AA AND LOOK DOWN FROM THE TOP OF THE INDEX TREE. 
          AFRB   10/12/81    ISDIS
  
 *L577*    ************************************************ 
 AM2A266  AAM2PL
          IF ONE OPENS A MIPPED FILE, THEN DOES A GET-BY-KEY WITH 
          A NON-EXISTENT ALTERNATE KEY TYPE (I.E. RKW, RKP, KL
          DONT CORRESPOND TO ANY EXISTING ALTERNATE KEY), ONE GETS
          A TRIVIAL ERROR 502. IF ONE THEN DOES A GET-NEXT, ONE 
          GETS FATAL ERROR 547, WHICH IS ABSURD.
  
          THE REASON IS THAT THE OPEN DOES NOT SET UP A REAL PTREE, 
          BUT SETS PTOF TO 1, INDICATING B.O.I., AND LEAVES THE 
          REST OF THE PTREE 0. THE GET-BY-KEY BEGINS BY ZEROING 
          PTOF, ON THE ASSUMPTION THAT A REAL POSITION WILL SURELY
          BE SET UP IN THE PTREE. ANY KIND OF TRIVIAL ERROR EXCEPT
          502 WOULD LEAVE A POSITION IN THE PTREE, BUT 502 LEAVES 
          THE INDICATION THAT POSITION IS ACCORDING TO PRIMARY KEY
          (SINCE NO ALTERNATE KEY HAS BEEN SUCCESSFULLY SPECIFIED)
          AND YET NEVER LOOKS INTO THE PRIMARY FILE OR SETS A 
          POSITION IN THE PRIMARY PTREE. SO THE FOLLOWING GET-NEXT
          THINKS IT HAS TO WORK FROM THE POSITION IN THE PRIMARY
          PTREE, AND AS THAT PTREE IS FULL OF ZERO, WE TRY TO 
          LOOK AT BLOCK 0, WHICH CAUSES A FATAL ERROR.
  
          THE CORRECTIVE CODE DOES THIS AFTER A 502 ERROR --
          (1) SET FAPOSKEY1 IN THE FIAT TO 0, INDICATING POSITION 
          BY PRIMARY KEY. 
          (2) CALL STMD$AA(0) TO MAKE ALL THE POINTERS REFER
          TO THE DATA FILE, NOT THE MIP FILE. 
          (3) SET PTOF IN THE DATA FILE PTREE TO 1 (B.O.I.) 
          THIS IS A WAY OF ESTABLISHING A LEGAL POSITION WITHOUT
          ACTUALLY HANDLING THE FILES. A FOLLOWING GET-NEXT WILL
          JUST GET THE FIRST RECORD IN THE FILE BY PRIMARY KEY. 
          THIS DOES NO PARTICULAR GOOD, BUT NO HARM. THE IDEAL
          MIGHT BE TO INVENT A NEW TRIVIAL ERROR ((GET-NEXT 
          IMPOSSIBLE AFTER IMPOSSIBLE GET BY ALTERNATE KEY)). 
          HOWEVER, THE CASE DOES NOT SEEM TO ARISE IN REAL LIFE.
          AFRB   10/28/81    MIPDMIP
  
 AM2A268  AAM2PL
          IF A DA-EXTENDED FILE HAS NON-EMBEDDED KEYS, AND
          OVERFLOWS TO THE POINT WHERE A MEMBER BLOCK IS CREATED
          IN ADDITION TO TERMINAL BLOCKS, THEN WHEN A RECORD
          IS COPIED FROM A TERMINAL BLOCK TO A MEMBER BLOCK,
          THE KEY WILL BE PREFIXED TO THE RECORD AS IF IT 
          WERE PART OF THE BODY OF THE RECORD. AND IF THAT
          RECORD IS LATER ACCESSED BY A GET OR GETN, IT WILL
          APPEAR LONGER THAN IT SHOULD, BY THE LENGTH 
          OF THE KEY. 
  
          THE CORRECTIVE CODE ENSURES THAT THE BODY OF A
          RECORD KEEPS ITS PROPER SIZE AND CONTENTS WHEN
          MOVED FROM A TERMINAL BLOCK TO A MEMBER BLOCK.
          AFRB   11/12/81    DADRARE
  
 AM2A269  AAM2PL
          IN A DA EXTENDED FILE, WHEN A HOME BLOCK OVERFLOWS AND WE 
          ARE LOOKING FOR A TERMINAL BLOCK THAT IT CAN OVERFLOW 
          INTO, THE FIRST CHOICE WILL BE THE EMPTIEST OF ANY
          TERMINAL BLOCKS THAT ARE NOW IN CORE. BUT IF THE BLOCK AT 
          THE TAIL END OF THE EMPTY CHAIN HAPPENS TO BE IN CORE, IT 
          WILL GET CHOSEN. THAT BLOCK WILL THEN BE IN BOTH THE EMPTY
          CHAIN AND AN OVERFLOW CHAIN, AND ULTIMATELY IT WILL BE
          CHAINED TO ITSELF IN A VICIOUS CIRCLE.
  
          THE REMEDY IS FOR THE CODE THAT SEEKS A TERMINAL BLOCK IN 
          CORE TO REFUSE AN EMPTY BLOCK (WITH RC=0). A BLOCK IN THE 
          EMPTY CHAIN IS ALWAYS EMPTY, WHILE A TERMINAL BLOCK IS
          NEVER EMPTY. THIS CRITERION WAS NEGLECTED WHEN EXTENDED 
          DA WAS WRITTEN. 
          AFRB   11/13/81    DADRARE
  
 AM2A270  AAM2PL
          IN THE TWO MODULES THAT ARE SPECIAL TO UPDATING A DA
          FILE, NRO$DA AND RARE$DA, THERE ARE THREE PLACES WHERE
          WE CONSIDER THE SIZE OF A NEW RECORD WITHOUT STOPPING 
          FOR THE POSSIBILITY THAT KEYS ARE NON-EMBEDDED, AND 
          IF SO THE KEY LENGTH MUST BE ADDED TO THE NEW 
          RECORD LENGTH AT THESE POINTS. THE CORRECTIVE CODE
          REPAIRS THESE THREE OMISSIONS.
          AFRB   11/19/81    NRODDA DADRARE 
  
 AM2A275  AAM2PL
          IN THE FSTT OF AN AK FILE, THERE IS A TABLE CALLED FSPCEMTAB, 
          RECORDING APPROXIMATELY HOW MANY BLOCKS THERE ARE IN EACH 
          DECILE OF EMPTINESS. HOWEVER, THE ROUTINE THAT MAINTAINS
          THIS TABLE NEGLECTS TO CONSIDER THE FACT THAT A BLOCK MAY 
          HAVE NO EMPTY SLOTS. IF IT HAS NO EMPTY SLOTS, ITS
          EMPTY SPACE IS USELESS FOR THE TIME BEING, SO IT SHOULD BE
          RECORDED AS HAVING NONE. IN A BADLY-DESIGNED FILE, IT CAN 
          HAPPEN THAT TABLE FSPCEMTAB SHOWS PLENTY OF BLOCKS WITH 
          LOTS OF SPACE, WHEN NONE OF THEM HAS A SINGLE EMPTY SLOT. 
          THEN THE PROGRAM WASTES A LOT OF TIME SCANNING THESE
          DISAPPOINTING BLOCKS EACH TIME IT DOES A PUT, BEFORE TAKING 
          THE INEVITABLE STEP OF CREATING A NEW BLOCK AT EOI. 
  
          THE CORRECTIVE CODE ENSURES THAT WHENEVER A BLOCK HAS NO
          VACANT SLOTS, IT IS COUNTED IN FSPCEMTAB AS HAVING NO 
          EMPTY SPACE AT ALL. AS LONG AS IT HAS AT LEASTS ONE VACANT
          SLOT, IT IS COUNTED EXACTLY AS BEFORE.
          AFRB   03/02/82    NRODAK 
  
 AM2A276  AAM2PL
          A HITHERTO-UNUSED BIT IN THE FSTT SHOULD BE RESERVED FOR
          TAB/AAMI USE. THIS IS THE BIT IMMEDIATELY TO THE RIGHT OF 
          FS2BLOX. IF AAMI SEES FS2BLOX SET, IT WILL SET THE NEW BIT, 
          FS2BLOXH, IN ORDER TO HAVE A NOTE OF THE FACT THAT WILL 
          NOT DISAPPEAR, AS FS2BLOX DOES, WHEN THE FILE IS CLOSED 
          OR OTHERWISE FLUSHED. FS2BLOX WAS NOT ORIGINALLY DESIGNED 
          AS A BAD CONDITION INDICATOR, BUT AS A CONVENIENT PLACE 
          TO KEEP INFORMATION THAT MIGHT BE PASSED ON WHENEVER A
          LOGGING ROUTINE IS CALLED. BUT TAF/AAMI FINDS IT USEFUL 
          AS AN INCONSISTENT-FILE INDICATOR AFTER A CRASH.
          AFRB   03/04/82    AAMFSTT
  
AM2A277  AAM2.0 
          FLBLOK NEEDS TO REFLECT THE 844-41 IN THE HEADING.
          CKA    03/12/82    FLBLOCKF 
 AM2A278  AAM2PL
          THIS IS AN EXTENSION OF AM20079. SOMEBODY WANTS FLSTAT TO 
          BE ABLE TO SURVEY A SET OF RMKDEF STATEMENTS THAT ARE ON
          SOME FILE OTHER THAN -INPUT-. WE ADD ONE MORE OPTIONAL
          PARAMETER, SO THAT ((FLSTAT,MYFILE,XYZ,RMKDEF,WICK)) WILL 
          TAKE THE RMKDEF STATEMENTS FROM FILE WICK, WHILE
          ((FLSTAT,MYFILE,XYZ,RMKDEF)) WILL TAKE THEM FROM INPUT. 
          IN EITHER CASE, OUTPUT GOES TO FILE XYZ, OR TO OUTPUT 
          IF THE SECOND PARAMETER IS NULL.
          AFRB   03/18/82    FLSTATC
  
 AM2A281  WHEN AAM CLOSES THE LAST AAM FILE, IT DOES NOT
          RESET THE NOTFRST FLAG.  THIS BEING THE CASE, PROPER
          INITIALIZATION DOES NOT OCCUR DURING A SUCCEEDING 
          OPEN REQUEST.  THIS CORRECTIVE CODE SET WILL SET THE
          NOTFRST FLAG TO ZERO. 
          AFB    05/07/82    AAMDCTL
  
 AM20111  AAM2PL
          WHEN DOING A DELETE OR REPLACE ON A MIPPED IS-EXTENDED
          FILE WITH EMBEDDED COLLATED KEY, THERE IS A TIME WHEN 
          THE KEY OF THE AFFECTED OLD RECORD, IN ITS BLOCK IMAGE, 
          IS LEFT DECOLLATED WHILE WE SEEK THE OLD VALUES OF THE
          ALTERNATE KEYS IN THE RECORD IMAGE. IF THE JOB ABORTS 
          DURING THIS TIME, THE FUNNY RECORD MAY GET PRESERVED
          ON THE DISK VERSION OF THE FILE, WITHOUT ANY ERROR
          FLAG BEING SET IN THE FSTT. OR IT MAY NOT. IF THE 
          ALTER FLAG HAS NOT ALREADY BEEN SET IN THE BLOCK IMAGE, 
          WE DO NOT CALL ALTR$AA TO SET IT BEFORE DECOLLATING 
          THE KEY, PRECISELY BECAUSE WE WOULD NOT WANT THE ALTERED
          BLOCK TO BE FLUSHED TO DISK IN CASE OF AN ABORT. BUT IF 
          THE ALTER FLAG IS ALREADY SET, SAY BECAUSE ANOTHER RECORD 
          IN THE SAME BLOCK HAS JUST BEEN DELETED, THEN THE BLOCK 
          WILL BE FLUSHED ON THAT ACCOUNT, AND THE BAD RECORD 
          WILL GO TO DISK.
  
          IN ORDER THAT WE SHOULD AT LEAST GET AN ERROR THE NEXT
          TIME THE FILE IS OPENED AFTER THIS PARTICULAR DISASTER, 
          THE CORRECTIVE CODE USES THE BLCIP (CHANGE-IN-PROGRESS) 
          FLAG IN THE FRAME OF THE BLOCK IMAGE. THIS FLAG IS SET
          BY ALTR$AA, AS A SIGN THAT THE BLOCK IMAGE IS ABOUT TO
          BE INCOMPLETELY MODIFIED. THEN IT IS RESET AS SOON AS 
          POSSIBLE BY WHATEVER ROUTINE CALLED ALTR$AA, ONCE THE 
          BLOCK MODIFICATION IS COMPLETE. THE PURPOSE OF THE FLAG 
          IS TO PREVENT A HALF-MODIFIED BLOCK FROM BEING FLUSHED. 
          (EVEN WHEN THE C-I-P FLAG IS CLEARED, THE ALTER FLAG, 
          WHICH ALTR$AA ALSO SET, AS A SIGN THAT THE BLOCK MUST,
          IN THE NORMAL COURSE, BE WRITTEN TO DISK, IS LEFT SET.
          THE BLOCK STILL NEEDS TO BE WRITTEN. IT IS JUST THAT
          IT IS NO LONGER UNFIT TO WRITE.) IF WE SET BLCIP BEFORE 
          DECOLLATING THE KEY IN THE BLOCK IMAGE, AND RESET IT
          AFTER RECOLLATING IT, THEN THE POSSIBILITIES IN CASE
          OF AN ABORT BETWEEN THESE TWO TIMES ARE --
          (1) THE ALTER FLAG IN THE BLOCK IMAGE IS NOT SET, 
          AND SO FLUSH DOES NOT TRY TO FLUSH THE BLOCK, AND 
          THE FILE ON DISK IS NOT POLLUTED. 
          (2) THE ALTER FLAG IS SET, AND FLUSH TRIES TO FLUSH 
          THE BLOCK, BUT SEES THE C-I-P FLAG. THIS PREVENTS 
          IT FROM WRITING THE BLOCK IMAGE TO DISK, AND CAUSES 
          THE ((RUINED)) FLAG IN THE FSTT TO BE SET. AT LEAST 
          THERE WILL BE A WARNING THE NEXT TIME THE FILE IS 
          OPENED. 
          AFRB   11/23/81    NRODMIP
  
 AM20113  AAM2PL
          IF, ON A DCREATE RUN, BOTH THE INPUT AND OUTPUT FILES 
          ARE DA, AND BOTH HAVE ORG=NEW OR BOTH ORG=OLD, THE
          CAPSULE LOADING DOES NOT WORK PROPERLY AND THE RUN FAILS. 
  
          THE CORRECTIVE CODE MOVES THE PASSLOC TABLE ENTRIES IN
          DCREATE BACK INTO CTRL$AA.
  
          ***** IT IS ESSENTIAL THAT PSR SW1A595
          ***** IN CTRL$AA, WHICH IS IN BAMLIB, SHOULD BE 
          ***** INSTALLED AT THE SAME TIME AS THIS ONE IN AAMLIB. 
          AFRB   11/24/81    CRT
  
 AM20120 AAM2PL 
          SORT-4 CLEARS UP ITS SCRATCH FILES NOT INITIALLY, BUT FINALLY.
          MIPGEN INTERFACES WITH SORT-4 IN SUCH A WAY THAT IT NEGLECTS
          TO RETURN CONTROL TO SORT-4 AT THE VERY END, SO THE SCRATCH 
          FILES DO NOT GET EVICTED. IF ANOTHER MIPGEN IS DONE WHILE THE 
          SORT SCRATCH FILES ARE LYING AROUND, IT SOMETIMES FAILS.
          THIS CORRECTIVE CODE MAKES MIPGEN GIVE SORT-4 THE OPPORTUNITY 
          TO DO ITS FINAL CLEANUP.
          THE INTERFACE WITH SORT-5 IS NOT AFFECTED.
          AFRB   04/14/82    MIPGEN 
  
 AM20123  AAM2PL
          WHEN DEALING WITH A FIFO SUB-FILE IN A MIP FILE, AAM EXTENDED 
          DOESNT HANDLE BLOCK DELETION PROPERLY. IT GOES AHEAD AS IF THE
          SUB-FILE WERE I-S, WHICH LEADS TO A 507 ERROR. THIS CORRECTIVE
          CODE DOES THE NECESSARY SPECIAL CASING FOR FIFO AS OPPOSED TO 
          I-S 
          AFRB   04/19/82    AAMDAA NRODIS ISDRARE
  
 AM20126  AAM2PL
          THERE IS A WEAKNESS IN THE WAY SUBROUTINE STUP$IS, IN 
          MODULE IS$IS, USES THE ((PARENT)) FIELD OF A BLOCK. WHEN
          ONE NEEDS TO FIND THE PARENT RECORD OF A GIVEN BLOCK IN AN
          IS FILE (OR AN IS SUB-FILE OF A MIP FILE), AND THE GIVEN
          BLOCK CONTAINS THE CURRENT RECORD IN THE PTREE, 
          (1) IF THE RECORD NUMBER IN THE TOP WORD OF THE PTREE IS
          NOT 0, THE WHOLE PTREE IS SUPPOSED TO BE VALID, AND WE NEED 
          ONLY MOVE UP ONE WORD FROM THE CURRENT LEVEL IN THE PTREE.
          (2) ELSE, LOOK AT THE PARENT FIELD IN THE CURRENT BLOCK 
          (BLPARENT). PROBABLY, BUT NOT CERTAINLY, IT CONTAINS THE
          PRU NUMBER OF THE PARENT BLOCK. THIS HAS TO BE TESTED BY
          LOOKING AT ALL THE RECORDS IN THE PUTATIVE PARENT BLOCK 
          AND SEEING WHETHER ONE OF THEM POINTS BACK TO THE BLOCK 
          FROM WHICH WE ARE TRYING TO MOVE UP IN THE PTREE. 
          (3) IF (2) FAILS, TAKE THE KEY OF THE CURRENT RECORD
          AND START FROM THE PRIMARY INDEX BLOCK, WORKING DOWN, 
          LOOKING FOR THE MATCHING OR NEXT-LOWER KEY AT EACH LEVEL
          UNTIL THE LEVEL NEXT ABOVE THE CURRENT LEVEL IS REACHED.
          THIS MAKES THE PTREE VALID FROM THE TOP DOWN TO THE CURRENT LEVEL,
          SO THAT FURTHER CALLS OF STUP$IS CAN USE (1). 
  
          THIS IS ALL RIGHT IF THE FILE IS NOT BEING CHANGED BY 
          THE CURRENT OPERATION. IN PRACTICE THIS MEANS A BACKSPACE.
          BUT DURING AN UPDATE, THE FOLLOWING CAN HAPPEN. A RECORD IS 
          ADDED AT THE BEGINNING OF A DATA BLOCK, REQUIRING A CHANGE IN 
          THE KEY OF ITS PARENT INDEX RECORD. IF THE BLPARENT FIELD OF
          THE DATA BLOCK IS CORRECT, WE FIND THE PARENT BLOCK, MAKE THE 
          PARENT RECORD IN THAT PARENT BLOCK CURRENT IN THE PTREE, AND
          ALTER THE KEY IN THAT PARENT RECORD. BUT SUPPOSE THE PARENT 
          RECORD IS THE FIRST IN ITS BLOCK. IF IT IS NOT THE PRIMARY
          INDEX BLOCK, WE MUST REPEAT THE CYCLE AND CHANGE THE KEY IN 
          ITS PARENT RECORD. IF ITS BLPARENT FIELD IS CORRECT, STUP$IS
          WILL FIND ITS PARENT RECORD CORRECTLY. BUT IF ITS BLPARENT
          FIELD IS NOT CORRECT, STUP$IS NOW HAS TO TAKE THE KEY OF
          THE CURRENT RECORD AND COME DOWN AGAIN FROM THE TOP OF THE
          TREE, LOOKING FOR THAT KEY --- ONLY IT-S THE WRONG KEY. 
          THE KEY THAT SHOULD HAVE BEEN USED IS THE KEY THAT WAS IN 
          THE FIRST RECORD OF THIS INDEX BLOCK BEFORE THE CHANGE THAT 
          WAS JUST MADE.
  
          THE CORRECTIVE CODE DOES THIS:  
          (1) IF THE CURRENT OPERATION IS SKB, STUP$IS BEHAVES
          AS NOW. 
          (2) OTHERWISE, WE ALMOST CERTAINLY HAVE AN UPDATE 
          OPERATION, AND THERE IS A CHANCE THAT IF WE FOLLOW
          THE UPWARD CHAIN OF PARENT POINTERS WHILE CHANGING
          RECORDS, THAT CHAIN MAY BREAK WHEN THE ORIGINAL 
          KEY IS NO LONGER HANDY. SO IF THE PTREE IS NOT ALREADY
          FULLY VALID, IGNORE THE PARENT POINTER, TAKE THE KEY
          OF THE CURRENT RECORD, AND MAKE THE PTREE VALID FROM
          THE TOP LEVEL DOWN TO THE CURRENT RECORD. 
          AFRB   05/12/82    ISDIS
  
 *L587*    ************************************************ 
 AM2A280  AAM2PL
          FLSTAT-RMKDEF SHOULD READ THE INPUT FILE THROUGH CRM RATHER 
          THAN THE READIN MACRO. IF THE INPUT FILE IS CONNECTED (ASSIGNED 
          TO KEYBOARD) NOS INSERTS AN E-O-R AFTER EVERY LINE READ BY THE
          READIN MACRO, SO THAT ONLY ONE LINE IS ACCEPTED BY THE PROGRAM. 
          CRM ALLOWS US TO HAVE A LOGICAL END OF RECORD (LIKE A 7-8-9 
          CARD) REPRESENTED BY A CARRIAGE RETURN WITH NOTHING BEFORE IT,
          SO THAT FLSTAT SWALLOWS AS MANY INPUT LINES AS THE USER LIKES.
          AFRB   05/13/82    FLSTATC
  
 AM2A282  AAM2PL
          WHEN AN IS FILE IS BEING ADDRESSED THROUGH MORE THAN
          ON FIT, EVERY TIME THE FILE IS UPDATED THROUGH ONE FIT, 
          THE FAALTPOS BIT IN EVERY OTHER FIT IS SET, AS A WARNING
          AGAINST TRUSTING THE PTREES ASSOCIATED WITH THOSE OTHER FITS. 
          THIS WARNING IS NOT SUFFICIENTLY HEEDED. SUBROUTINE EZKY$IS,
          THE MAIN TOOL FOR LOCATING A RECORD BY KEY, MUST CHECK THAT 
          FLAG AT THE BEGINNING, AND IF IT IS SET, ZERO THE RECORD
          NUMBER IN THE TOP WORD OF THE PTREE, TO INDICATE THAT AT
          MOST THE BOTTOM WORD OF THE PTREE IS VALID. THE BOTTOM WORD 
          NEED NOT BE ASSUMED INVALID, BECAUSE THE NEXT THING EZKY$IS 
          DOES IN ANY CASE IS TO EXAMINE WHAT IT POINTS TO. 
          AFRB   06/09/82    ISDIS
  
 AM2A284  AAM2PL
          WHEN MIPGEN IS USED TO PURGE AN ALTKEY DEFINITION,
          THIS SHOULD REDUCE BY 1 THE COUNT OF HOW MANY ALTKEYS 
          THERE ARE IN THE CATEGORY UNIQUE/INDEXED/FIFO.
          IT DOESNT ALWAYS WORK, BECAUSE THE CATEGORY IS TAKEN
          FROM THE RMKDEF STATEMENT. BUT AN RMKDEF STATEMENT
          FOR A PURGE NEED NOT INCLUDE THIS CATEGORY, AND 
          PROBABLY DOESNT, SO THE CATEGORY APPEARS TO DEFAULT 
          TO UNIQUE, AND THE COUNT OF UNIQUE ALTKEYS IS THE 
          ONE THAT GETS DECREMENTED. SO IN CASE OF A PURGE
          RMKDEF, WE HAVE TO LOOK AT THE RECORD IN THE MIP FILE 
          THAT CORRESPONDS TO THIS RMKDEF, AND GET THE
          CATEGORY OUT OF THAT RECORD, IN ORDER TO DECIDE 
          WHICH OF THE THREE COUNTS TO DECREMENT. 
          AFRB   06/24/82    KDEFDMP
  
 AM2A287  AAM2PL
          WHEN MIPGEN ENCOUNTERS A BAD RMKDEF CARD, IT GIVES AN ERROR 
          MESSAGE AND DOES AN IMMEDIATE ENDRUN. 
          SOME USERS WOULD LIKE IT TO ABORT IN THIS CASE. 
          THIS CODE MAKES THE ABORT POSSIBLE. 
          TO GET THE ABORT, INSTEAD OF ENDRUN, IN CASE OF A BAD RMKDEF
          CARD, THE CALLER MUST USE 4 PARAMETERS IN THE MIPGEN CONTROL
          STATEMENT, OF WHICH THE 4TH IS ((ABT)). THE 2ND AND 3RD PARAMETERS
          WILL NOT DEFAULT. SO WHERE ((MIPGEN,SIPFILE.)) WOULD CAUSE
          ENDRUN IN CASE OF BAD RMKDEF CARD,
          ((MIPGEN,SIPFILE,INPUT,OUTPUT,ABT.)) WOULD BE NEEDED TO GET AN
          ABORT IN THE SAME CASE. 
          AFRB   10/12/82    MIPGEN 
  
 AM20127  AAM2PL
          CLOSEM OF A MIPPED FILE WITH CF=RET OR CF=U RETURNS THE DATA FILE 
          BUT NOT THE MIP FILE. THE DATA FILE IS RETURNED BY BAM, BUT THE 
          MIP FILE IS LEFT TO AAM. SO THE CORRECTIVE CODE IS ADDED TO THE 
          SUBROUTINE IN AAM THAT DOES A CIO CLOSE FOR DATA AND MIP FILES. 
          IT USES THE STRONGER CIO FUNCTION IF THE FILE IS THE MIP FILE 
          AND THE CF FIELD OF THE FIT IS 3 OR 4 (RET OR U). 
          AFRB   05/13/82    OPENDAA
  
 AM20148  AAM2PL
          A VERY SPECIAL COMBINATION OF CIRCUMSTANCES CAN OCCUR --
          (1) A RARE CAPSULE (RARE$IS, OVFM$AK OR OVFM$DA) IS STILL 
          LOADED ALTHOUGH THE LAST FILE OF ITS TYPE HAS BEEN CLOSED.
          NORMALLY IT SHOULD GET UNLOADED VIA THE KICK-OUT CHAIN
          MECHANISM, QUITE SOON AFTER.
          (2) WE NEED TO LOAD A DIFFERENT RARE CAPSULE FOR A FILE 
          THAT IS OPEN. SPACE HAS TO BE FOUND FOR THIS. 
          (3) THERE ARE NOT ENOUGH BUFFERS IN CORE THAT CAN BE
          KICKED OUT TO MAKE ROOM FOR THE CAPSULE.
          (4) THE LEFTOVER RARE CAPSULE THAT IS IN CORE WAS 
          EXECUTED JUST BEFORE THE CLOSE OF ITS LAST FILE, AND
          STILL HAS 2 OR 3 ((LIVES)). 
  
          WHAT OUGHT TO HAPPEN IS FOR THE LEFTOVER CAPSULE TO BE
          UNLOADED TO MAKE ROOM FOR THE NEEDED RARE CAPSULE.
          BUT AT MOST, IN SUBROUTINE RESP$AA, WHICH KICKS THINGS
          OUT TO MAKE SPACE, WE GET 2 CALLS OF RESPA, ONE WITH
          PARAMETER 0, AND THEN ONE WITH PARAMETER 1 IF THE FIRST 
          HAS NOT MADE ENOUGH SPACE. WHEN THE PARAMETER IS 1, 
          RESPA WILL KICK OUT BLOCKS EVEN IF THEY NEED TO BE
          WRITTEN OUT TO DISK. IN THE WORST CASE, EACH TIME 
          RESPA IS CALLED IT TRIES TO KICK OUT THE LEFTOVER 
          CAPSULE, BUT ONLY SUCCEEDS IN REDUCING ITS ((LIVES))
          BY 1. AT THE END, THE CAPSULE HAS NO LIVES LEFT,
          BUT IT WOULD TAKE ONE MORE CALL TO RESPA TO GET 
          ACTUALLY RID OF THE CAPSULE. SO IT APPEARS IMPOSSIBLE 
          TO MAKE ROOM FOR THE NEW CAPSULE, AND WE GET A 507
          ERROR -- THIS IS SOMETHING THAT ((CANT)) HAPPEN.
  
          THE CORRECTIVE CODE SAYS THAT IF RESPA IS CALLED
          WITH A PARAMETER OF 1, A RARE CAPSULE CAN BE KICKED 
          OUT EVEN IF IT HAS A ((LIFE)) LEFT. SINCE THIS MUST 
          BE THE SECOND TIME RESPA IS CALLED IN QUICK 
          SUCCESSION, WE ARE NOT COMPLETELY DISREGARDING THE
          PRIVILEGE OF THE CAPSULE, BUT AT WORST REDUCING ITS 
          TOTAL OF TRIPS THROUGH THE EMPTY CHAIN TO 2.
          AFRB   12/17/82    AAMDAA 
  
 *L601*    ************************************************ 
 AM2A290  AAM2PL
          IN AN A-K FILE THAT HAS ALTERNATE KEYS, A PUT-WITHOUT-KEY MAY 
          NOT WORK CORRECTLY IF THE KEY IS NOT EMBEDDED, AND THE PUT USES 
          A KA FIELD POINTING INTO THE BODY OF THE RECORD, AND ONE OF 
          THE ALTERNATE KEY FIELDS OVERLAPS THE FIELD INTO WHICH KA 
          POINTS. SINCE THERE IS NOT MUCH POINT IN SPECIFYING NON-
          EMBEDDED KEY AND THEN MAKING KA POINT INTO THE RECORD, SO THAT
          A COPY OF THE KEY IS FOUND IN THE RECORD AFTER ALL, THIS WOULD
          NOT AT FIRST SIGHT BE A PRACTICAL PROBLEM. BUT IN AAM 1.5,
          AN A-K FILE HAD TO HAVE A NON-EMBEDDED PRIMARY KEY, AND YET 
          IF MIP WAS USED, A COPY OF THE PRIMARY KEY HAD TO BE FOUND IN 
          THE BODY OF THE RECORD AFTER ALL. HENCE THERE ARE A GOOD MANY 
          USER PROCEDURES THAT HAVE EXACTLY THESE FEATURES, EVEN THOUGH 
          THEY NOW RUN WITH AAM 2.0. BUT AS IT IS RARE FOR AN ALTERNATE 
          KEY FIELD TO OVERLAP THE PRIMARY KEY FIELD OF A RECORD, THERE 
          ARE PROBABLY VERY FEW CASES WHERE THIS BUG OCCURS.
  
          THE PROBLEM IS THAT THIS FIELD OF THE RECORD SHOULD BE 0 WHEN THE PUT 
          OPERATION BEGINS, IN ORDER TO CAUSE A PUT-WITHOUT-KEY, AND IT SHOULD
          BE 0 IN THE COPY OF THE RECORD THAT IS STORED IN THE A-K FILE ITSELF
          SINCE LOGICALLY WE SHOULD STORE THE RECORD AS THE USER FIRST SENT IT
          TO US, AND IT SHOULD BE 0 WHEN WE ARE EXTRACTING ALTERNATE KEY VALUES 
          FROM THE RECORD, FOR AFTER ALL 0 IS ITS TRUE VALUE IN THE RECORD. 
          (FOR BETTER OR WORSE, THIS CONFLICTS WITH THE WAY IT WAS IN AAM 1.5,
          BECAUSE IN AAM 1.5 A COPY OF THE PRIMARY KEY HAD TO BE INSIDE THE 
          RECORD FOR MIP TO USE. WE CHANGED THIS TO WHAT SEEMS MORE LOGICAL,
          IN AAM 2.0, BUT FOR REASONS ALREADY DISCUSSED, FEW OR NO USER 
          JOBS SHOULD SUFFER.)
  
          HOWEVER, IN PROCEDURE PUT$AK OF MODULE NRO$AK, WE COPY THE KEY VALUE
          INTO THE RECORD, IF THAT IS WHERE KA POINTS, IN THE CASE OF A NON-
          EMBEDDED KEY, BEFORE CALLING PROCEDURE ZIPMIP, WHICH EXTRACTS 
          ALTERNATE KEY VALUES AND STORES THEM AWAY.
  
          THE CORRECTIVE CODE MAKES SURE THAT ZIPMIP IS CALLED WHILE THE
          FIELD IN THE RECORD IS STILL 0. THUS ALL STORING IS DONE WITH 0 
          IN THAT FIELD OF THE RECORD, THEN THE KEY VALUE IS COPIED INTO
          FOR THE USER PROGRAM TO SEE WHEN CONTROL RETURNS TO IT. 
          AFRB   02/03/83    NRODAK 
  
 AM2A294 AAM2PL 
          SUBROUTINE KRAK$MP IN MODULE MIP$MIP IS SUPPOSED TO SET BB=1
          ONLY DURING A REPLACE, ONLY IF EITHER THERE ARE NO REPEATING
          GROUPS, OR THE REPEATING GROUP OCCURS JUST ONCE IN THE OLD
          AND ONCE IN THE NEW RECORD. BUT IN FACT IT MAY NEGLECT TO 
          TEST WHETHER THE OLD AND NEW RECORDS BOTH SATISFY THE TEST, 
          AND DURING ONE OF THE TWO TIMES IT IS CALLED DURING A 
          REPLACE, KRAK$MP MAY SET BB=1 ERRONEOUSLY.
  
          THE CORRECTIVE CODE MAKES SURE THAT BB=0 ON A REPLACE 
          WITH REPEATING GROUPS, IF THE OLD AND NEW RECORDS HAVE
          DIFFERENT LENGTHS.
          AFRB   04/15/83    MIPDMIP
  
 AM20136  AAM2PL
          AAM SETS A FLAG IN THE FSTT (FSMODFLG) WHENEVER ANY BLOCK IN A
          FILE IS ALTERED, AND RESETS IT AT THE END OF ANY PUT/REPLACE/ 
          DELETE OPERATION. SO FINDING THE FLAG SET MEANS THAT AN UPDATE
          IS NOW IN PROGRESS AND PROBABLY INCOMPLETE, OR WAS SO AT THE
          MOMENT WHEN THE FILE WAS LAST FLUSHED. UNFORTUNATELY THIS FLAG
          IS NOT CHECKED WHEN A FILE IS OPENED. THE ONLY USE NOW MADE OF
          IT IS IN THE RARE EVENT OF A READ ERROR -- IF SOMETHING HAS 
          ALREADY BEEN CHANGED IN THE FILE, BUT THE OPERATION CANT BE 
          COMPLETED BECAUSE OF A READ ERROR, THE ERROR IS FATAL.
  
          THE CORRECTIVE CODE CHECKS FOR THIS FLAG DURING OPEN, AND IF
          THE FLAG IS SET, GIVES A FATAL ERROR THE SAME AS IF THE 
          RUINED FLAG HAD BEEN FOUND SET. THE CORRECTIVE CODE ALSO
          ENSURES THAT FOR A DATA FILE/MIP FILE PAIR, THE FLAG IS ALWAYS
          SET IN THE DATA FILE, NOT THE MIP FILE. 
  
          THE CORRECTIVE CODE ALSO SUPPRESSES SETTING THIS FLAG DURING
          A MIPGEN RUN. EVEN IF MIPGEN IS UNSUCCESSFUL FOR SOME REASON, 
          THE DATA FILE IS NOT BEING ALTERED AND THEREFORE IS NOT 
          RUINED. 
  
          THE CORRECTIVE CODE ALSO RESETS THE FLAG AT THE END OF
          PROGRAM KDEF$MP. THIS PROGRAM IS CALLED FOR AN RMKDEF.
          IT MAY MODIFY THE MIP FILE, WHICH CAUSES THE FLAG TO
          BE SET, BUT AS IT DOES NOT RETURN THROUGH EXEC$AK,
          EXEC$DA, OR EXEC$IS, THE WAY AN ORDINARY PUT OR DELETE
          WOULD RETURN, IT LEAVES THE FLAG SET. IF THERE IS A 
          CLOSE AFTER THE RMKDEF, AND BEFORE ANY UPDATE, THIS 
          WOULD LEAVE THE FLAG ERRONEOUSLY SET IF KDEF$MP DID 
          NOT RESET IT. 
  
          THE CORRECTIVE CODE REFRAINS FROM CHECKING THE
          FLAG AT OPEN TIME, IF THE SIGN BIT OF THE 30TH WORD OF
          THE FIT IS SET. THIS ALLOWS CDCS TO PREVENT THE NEW CHECK,
          BY SETTING THAT BIT BEFORE OPENING. THE BIT IS NEVER
          OTHERWISE USED BY AAM, AND IS IN A WORD DESIGNATED
          ((RESERVED FOR CRM)). 
          AFRB   07/21/82    AAMDAA OPENDAA 
  
 AM20139  AAM2PL
          AAM ALLOWS AN IS FILE, OR A SUB-FILE IN A MIP FILE, TO GROW BY ONLY 
          TWO LEVELS OF INDEX BETWEEN ANY OPEN AND THE NEXT FOLLOWING CLOSE.
          THIS WAS ORIGINALLY THOUGHT ADEQUATE, AND SAVES A LITTLE ROOM IN
          PTREES. HOWEVER, SOME USERS OFTEN EXCEED THIS LIMIT WHEN CREATING 
          A NEW FILE, AND FIND IT ANNOYING TO GET A 335 ERROR, AFTER WHICH
          THEY HAVE TO CLOSE AND RE-OPEN. (NOTE THAT THIS DIFFICULTY WOULD
          NOT ARISE IF THEY DID OPEN-NEW AND THEN IMMEDIATELY PUT ALL THE 
          RECORDS. BUT THEY OPEN-NEW, CLOSE IMMEDIATELY, OPEN-OLD, AND
          THEN BEGIN PUTTING IN RECORDS. THAT PATTERN IS WHAT WAS NOT 
          FORESEEN BY THE DESIGN.)
  
          THE CORRECTION CODE CHANGES THE LIMIT ON NEW LEVELS OF INDEXING FROM
          2 TO 4. THIS MAKES A 335 ERROR VERY MUCH LESS PROBABLE. THE COST IS 
          THAT A JOB WITH 100 FIT-S OPEN AT THE SAME TIME, CONTROLLING
          MIPPED FILES, WILL FIND ITS FIELD LENGTH INCREASED BY SEVERAL HUNDRED 
          WORDS.
          AFRB   02/02/83    OPENDAA
  
 AM20145  AAM2PL
          WHEN IS FILES GROW BETWEEN AN OPEN AND THE NEXT CLOSE, INDEX
          LEVELS ARE ADDED AS NEEDED. THE SAME IS TRUE OF MIP FILES. AFTER
          A LARGE AMOUNT OF GROWTH IT IS NECESSARY TO CLOSE AND REOPEN AN 
          IS FILE SO THAT CERTAIN IN-CORE TABLES ARE REGENERATED TO 
          ACCOMMODATE THE ADDED INDEX LEVELS. 
              AAM HAS BEEN FAILING TO DETECT THIS NECESSITY TO CLOSE WHEN 
          IT HAPPENS IN A MIP FILE. THE CORRECTIVE CODE MAKES AAM DETECT
          IT IN MIP FILES AS WELL AS IS DATA FILES. 
          AFRB   03/09/83    NRODIS 
  
 AM20149  AAM2PL
          AM2A273 PROVIDES A WAY TO AVOID HAVING FSTTS FLUSHED DURING 
          A FLUSH CALL, BY SETTING A NEW BIT IN THE FIT POINTED 
          TO BY THE FIRST WORD IN THE LIST OF FITS. UNFORTUNATELY THE 
          NEW CODE NEGLECTED TWO POSSIBILITIES -- THE FIRST WORD IN 
          THE FIT LIST IS INACTIVE, WITH THE SIGN BIT =1, OR THE
          FIT IT POINTS TO IS TOO SHORT TO CONTAIN THE NEW FLAG, SO 
          THAT A RANDOM BIT IN MEMORY IS BEING TESTED.
  
          THE CORRECTIVE CODE IN AM20149 ADDS TWO  MORE CONDITIONS
          THAT MUST BE SATISFIED IN ORDER NOT TO FLUSH FSTTS -- 
          THE FIRST WORD IN THE FIT LIST MUST BE POSITIVE, AND
          THE FIT IT POINTS TO MUST BE AT LEAST 14 WORDS LONG.
          AFRB   03/30/83    AAMDAA 
  
 AM20150  AAM2PL
          AFTER A GET OR GET-NEXT, IF RECORD TYPE IS Z, AAM PADS WITH BLANKS
          IF THE FILE STATUS IS EOR. THIS NEGLECTS THE POSSIBILITY THAT THE 
          GET MAY HAVE BEEN BY ALTERNATE KEY, LEAVING A STATUS OF EOK.
          THE CORRECTIVE CODE CAUSES THE PADDING TO TAKE PLACE WHEN THE 
          STATUS IS NOT EOI, RATHER THAN WHEN IT IS EOR.
          AFRB   03/21/83    AAMDCTL
  
 AM20152  AAM2PL
          WHEN A FILE IS BEING CLOSED, AND CMM IS NOT BEING USED, SUBROUTINE
          RLSP$AA IN MODULE OPEN$AA IS SKIPPED COMPLETELY. BUT THREE ACTIONS
          IN THAT SUBROUTINE OUGHT NOT TO BE SKIPPED, NAMELY THE ZEROING OF 
          THE FIELDS IN THE FIT THAT POINT TO THE FIAT, THE FSTT OF THE 
          FILE, AND THE FSTT OF ITS ASSOCIATED MIP FILE. A LATER OPEN,
          USING THE SAME FIT, CAN FIND THE FSTT POINTER NON-ZERO AND
          BEHAVE AS THOUGH THE FILE HAD ALREADY BEEN OPENED.
          THE CORRECTIVE CODE AMENDS RLSP$AA SO THAT THE THREE POINTERS 
          ARE ZEROED EVEN IF CMM IS NOT IN USE. 
          AFRB   03/17/83    OPENDAA
  
 AM20153  AAM2PL
          WITH STATIC LOADING, SETTING CPA=1 IN AN AAM FILE FIT TO GET
          COMPRESSION JUST YIELDS A 666 FATAL ERROR. THIS ERROR IS
          UNNECESSARY, AND THE CORRECTIVE CODE REMOVES THE ERROR. 
          HOWEVER, IT IS NECESSARY FOR THE JOB THAT WANTS COMPRESSION 
          WITH STATIC LOADING TO INCLUDE
            LDSET(USE=$CMPR$$01$) 
          CPA=2 THROUGH CPA=10 ARE ALSO POSSIBLE, AND WOULD REQUIRE 
            LDSET(USE=$CMPR$$02$) OR WHATEVER.
          HOWEVER, COMPRESSION ROUTINES CMPR$02 THROUGH CMPR$10 ARE NOT 
          PROVIDED IN THE AAM LIBRARY, AND WOULD HAVE TO BE CODED,
          TURNED INTO CAPSULES, AND ADDED TO THE LIBRARY BY THE USER. 
          AFRB   03/10/83    OPENDAA
  
 AM20159  AAM2PL
          WHEN A FILE IS CLOSED THROUGH ONE FIT BUT REMAINS OPEN
          THROUGH ONE OR MORE OTHERS, THE LOGGING FIELDS IN THE 
          FSTT ARE ZEROED, AND THEN RESET TO THE FIRST NON-ZERO 
          VALUES, IF ANY, THAT CAN BE FOUND IN THE FITS THAT REMAIN 
          OPEN. BUT WHEN THE FILE HAS A COMPANION MIP FILE, THE LOG 
          ADDRESS IN THE MIP FILE FSTT IS NOT ALWAYS SET AT THIS
          TIME. THE CORRECTIVE CODE FIXES THIS. 
          AFRB   04/25/83    OPENDAA
  
 AM20160  WHEN AAM IS OPERATING IN A TAF-LIKE ENVIRONMENT (I.E., RM$TSYS
          HAS BEEN SUBSTITUTED FOR RM$SYS=), A FATAL ERROR ON A FILE
          WHICH HAS CM=YES SET IN THE FIT WILL CAUSE A CM OUT OF
          RANGE ERROR IN RM$TSYS.  THIS IS BECAUSE RM$TSYS TRIES TO 
          ISSUE THE REQUEST WITHOUT RECALL AND THEN CHECK FOR THE 
          COMPLETION OF THE REQUEST BY LOOKING AT THE COMPLETE BIT.  ON 
          NOS, THIS RESULTS IN A MODE ERROR SINCE THERE IS NO WORD THAT 
          HAS A COMPLETE BIT FOR THE DUMP REQUEST.
          THIS CODE CHANGES THE ISSUANCE OF THE DUMP REQUEST SO IT USES 
          SYS= INSTEAD OF RM$SYS=, THUS AVOIDING THE PROBLEM. 
          CFR    83/04/01    CRA1DAA
  
          BX6    X1 
 AM20161  AAM2PL
          WHEN AN AAM FILE IS OPENED, IF FWB IN THE FIT IS NOT 0, IT IS 
          THE STARTING ADDRESS OF A BUFFER AREA INTO WHICH BUFFERS FOR
          THIS FILE SHOULD BE ALLOCATED, AND BFS IN THE FIT IS ITS LENGTH 
          IN WORDS. AS PART OF THE OPEN PROCEDURE, BUFFERS ARE ALLOCATED
          UNTIL THIS SPACE IS EXHAUSTED. THE REMAINING LENGTH OF THIS 
          SPACE IS HELD IN VARIABLE UBSL. SUBROUTINE ORGUBS THINKS THERE
          IS ROOM FOR ANOTHER BUFFER IF UBSL IS NOT LESS THAN THE SIZE
          OF A BUFFER, AND CALLS FUNCTION GETSPACE. FUNCTION GETSPACE 
          THINKS THERE IS ROOM ONLY IF UBSL IS GREATER THAN THE LENGTH
          OF A BUFFER. THE DISCREPANCY CAN CAUSE AN ERROR WHEN BFS = 145
          PLUS AN EXACT MULTIPLE OF A BLOCK BUFFER SIZE. ORGUBS IS RIGHT
          AND GETSPACE IS WRONG. WE DO NOT WANT TO ALLOCATE THE VERY LAST 
          WORD OF THE BUFFER AREA, BUT THIS IS SAFEGUARDED BY SUBTRACTING 
          1 FROM UBSL AT THE VERY BEGINNING OF THE PROCESS. 
  
          THE CORRECTIVE CODE MAKES GETSPACE ALLOCATE ANOTHER BUFFER
          IF UBSL IS NOT LESS THAN THE SIZE OF A BUFFER.
          AFRB   05/04/83    OPENDAA
  
 AM20164  AAM2PL
          WHEN A Z-TYPE RECORD IS PUT INTO AN AAM FILE, BLANK SUPPRESSION 
          MUST NOT REDUCE THE RECORD LENGTH BELOW MINIMUM-RECORD-LENGTH,
          WHICH IS AN ATTRIBUTE FOR THE FILE. THERE WAS A PROTECTION
          AGAINST THIS IN AAM$CTL, BUT WHEN PSR AM2A096 CORRECTED A 
          MISTAKE IN HANDLING THE LENGTH OF T-TYPE RECORDS, THE NEW 
          CODE MISTAKENLY WIPED OUT THE Z-RECORD PROTECTION.
  
          THIS NEW CORRECTIVE CODE RESTORES THE Z-RECORD PROTECTION.
          AFRB   07/15/83    AAMDCTL
  
 *L617*    ************************************************ 
 AM20165  AAM2PL
          WHEN AN I-S FILE IS CREATED, FLAG FACREATE IN THE FIAT IS SET =1. 
          AN OPEN-OLD SETS THE FLAG 0. AFTER CREATION, THE FLAG REMAINS 1 
          ONLY AS LONG AS THE OPERATIONS ARE PUTS, WITH INCREASING PRIMARY
          KEY VALUES. WHEN THE FLAG IS 1, SHORT CUTS ARE TAKEN IN MODIFYING 
          THE FILE. 
  
          IF, WHILE FACREATE IS 1, THE SAME FILE IS OPENED THROUGH A SECOND 
          FIT, AND A RECORD IS PUT THROUGH THE SECOND FIT, WITH A PRIMARY KEY 
          THAT IS NOT HIGHER THAN THE HIGHEST EXISTING ONE, THE SHORT CUTS
          IMMEDIATELY BECOME DANGEROUS. 
  
          THE CORRECTIVE CODE PROVIDES THAT WHEN A FILE IS OPENED, AND IT IS
          FOUND THAT A FIT ALREADY EXISTS, FACREATE IS ZEROED IN THE FIAT THAT
          BELONGS TO THE EXISTING FIT. AS FACREATE COULD ONLY BE SET TO 1 IN AN 
          OPEN NEW, WHEN ONLY ONE OPEN FIT CAN EXIST, A LATER OPEN THROUGH A
          SECOND FIT WILL CLEAR FACREATE IN THE FIRST FIT. IN ALL OTHER CASES,
          THE CLEARING ACTION IS SUPERFLUOUS BUT HARMLESS.
          AFRB   08/08/83    OPENDAA
  
 *L628*    ************************************************ 
 AM2A298 AAM2PL 
          AM20078 AND AM20104, WHICH BOTH AFFECT THE SAME SPOT IN MODULE
          MIP$MIP, BOTH TRY TO PREVENT USELESS AND FATAL ATTEMPTS TO
          WRITE A MIP FILE. BUT THEY DONT PREVENT THE USELESS SETTING OF
          FSMODFLG BY CALLING ALTR$AA. THIS FLAG, IN THE FSTT, IS SET BY
          ALTR$AA, AND RESET AT THE CONCLUSION OF AN ENTIRE UPDATE
          OPERATION -- PUT, REPLACE, OR DELETE. SO WHEN IT IS SET, IT IS
          SUPPOSED TO MEAN THAT AN UPDATE IS IN PROGRESS. IF IT IS FOUND
          TO BE SET WHEN A FILE IS OPENED, IT IS SUPPOSED TO MEAN THAT
          THE LAST TIME THE FILE WAS OPEN, AN UPDATE WAS BEGUN BUT NEVER
          COMPLETED. ALTR$AA IS CALLED, IN GENERAL, JUST BEFORE CALLING 
          ANY SUBROUTINE THAT MAKES A MAJOR CHANGE TO A BLOCK.
          IT IS ALSO CALLED IN SUBROUTINE LEVL$MP, IN MODULE MIP$MIP, 
          IN A WAY THAT IS DISCUSSED IN PSRS AM20078 AND AM20104. 
  
          HOWEVER, FSMODFLG WAS NOT ACTUALLY TESTED AT OPEN TIME, 
          UNTIL THIS NEGLECT WAS CORRECTED IN AM20136. WHEN THAT
          CORRECTIVE CODE WAS ADOPTED, IT MADE A SPURIOUS 
          ((FILE RUINED)) POSSIBLE AT OPEN TIME, DUE TO THE CALL
          TO ALTR$AA IN SUBROUTINE LEVL$MP. IT IS POSSIBLE FOR A
          FILE TO HAVE FSMODFLG SET WITHOUT ACTUALLY BEING ALTERED
          AT ALL, PROVIDED THAT THE FILE HAS WRITE PERMISSION ETC.
          AND FSMODLG NEVER GETS RESET, BECAUSE THAT ONLY HAPPENS 
          AT THE END OF AN UPDATE OPERATION, AND THERE WAS NO UPDATE
          OPERATION. THE LOGICAL WEAKNESS IN LEVL$MP AT THIS POINT IS 
          DESCRIBED FURTHER IN PSRS AM20078 AND AM20104.
  
          WHAT WE REALLY NEEDED, IN THOSE TWO PSRS, WAS A FIX THAT
          WOULD PREVENT ALTR$AA FROM BEING CALLED AT THAT POINT,
          UNLESS AN ACTUAL ALTERATION WAS ABOUT TO TAKE PLACE IN THE
          CURRENT FILE. THE NEW CORRECTIVE CODE LETS US ABSTAIN FROM
          CALLING ALTR$AA IF THE TWO WORDS TO BE STORED INTO THE
          RECORD WOULD NOT IN FACT CHANGE IT. THIS SAFEGUARD
          PROBABLY OBVIATES THE TESTS THAT THE OLD PSRS INSERTED IN 
          3 LINES JUST BEFORE MIPDMIP.1328, BUT THOSE TESTS DO NO 
          HARM, SO WE LEAVE THEM IN.
          AFRB   06/21/84    MIPDMIP
  
 AM20175  AAM2PL
          IN AN AK FILE, A PUT-WITH-KEY SHOULD NOT WORK IF IT WOULD 
          REQUIRE THE FILE TO BE EXTENDED BY MORE THAN ONE BLOCK. 
          AT PRESENT, THIS PROTECTION IS NOT WORKING RIGHT, AND A 
          PUT-WITH-KEY USING AN EXCESSIVELY LARGE KEY USUALLY JUST
          EXTENDS THE FILE ONE BLOCK AND PUTS THE NEW RECORD IN 
          THE NEW BLOCK. (THIS HAS TURNED UP IN A COBOL PROGRAM,
          WHERE A KEY IS ACCIDENTALLY SET TO 3333333333333333B
          INSTEAD OF 0, AND A PUT-WITHOUT-KEY TURNS INTO A PUT
          WITH THAT KEY.) 
  
          THE CORRECTIVE CODE MAKES AN EXCESSIVELY-LARGE KEY
          PRODUCE A 442 ERROR.
          AFRB   06/04/84    AKDAK
  
 AM20176  AAM2PL
          IN OPEN$AA, VARIABLE CMPLFSTT NEEDS TO BE INITIALIZED TO 0. 
          SUBROUTINES SRCHFSTT AND FINDFSTT INITIALIZE IT, BUT IN 
          OPEN NEW WITH ALTERNATE KEY, SUBROUTINE MIP$OPN 
          TESTS CMPLFSTT, ALTHOUGH CMPLFSTT HAS NOT YET BEEN SET. 
          THIS CAN CAUSE A 203 OR 555 ERROR IF UNINITIALIZED MEMORY WAS 
          PRESET TO SOMETHING OTHER THAN 0. IT MIGHT CAUSE AN ERROR EVEN
          WHEN THE PRESET WAS TO 0, IF TWO OPENS ARE DONE IN SUCCESSION,
          LEAVING THE SECOND ONE TO SEE WHATEVER WAS LEFT IN CMPLFSTT 
          BY THE FIRST ONE. 
          THE CORRECTIVE CODE SETS CMPLFSTT TO 0 AT THE RELEVANT POINT
          IN MIP$OPN. 
          AFRB   05/07/84    OPENDAA
  
 AM20179  AAM2PL
          A REPLACE IN A DA FILE WITH ALTERNATE KEYS MISBEHAVES IF
          THERE IS COMPRESSION. THE NEW RECORD IS COMPRESSED BEFORE 
          THE MIP PROCESSING IS DONE, FOR REASONS PECULIAR TO DA FILES. 
          BUT THE MIP ROUTINES DECOMPRESS THE OLD RECORD BEFORE THE 
          COMPRESSED NEW RECORD IS PUT INTO THE FILE. AND THERE IS ONLY 
          ONE COMPRESSION/DECOMPRESSION BUFFER. SO THE COMPRESSED NEW 
          RECORD IS REPLACED BY THE DECOMPRESSED OLD RECORD IN THIS 
          BUFFER, AND THE LATTER IS WHAT IS STUCK INTO THE FILE.
          THE CORRECTIVE CODE CAUSES THE COMPRESSION ROUTINE TO BE CALLED 
          AGAIN, AFTER THE MIP PROCESSING, IN ORDER TO RESTORE THE
          CONTENTS OF THE COMPRESSION BUFFER. 
          AFRB   03/29/84    NRODDA 
  
 AM20182  AAM2PL
          WHEN VANB$IS DELETES A BLOCK, IT UPDATES THE CURRENT PTREE
          TO POINT TO THE NEXT BLOCK, BUT NEVER CHECKS TO SEE IF
          ANOTHER PTREE WAS ALREADY POINTING TO THE NEXT BLOCK. IF THE
          BLOCK IS LATER RELEASED FROM THE KICK-OUT CHAIN, THE OTHER
          PTREE WILL BE LEFT POINTING TO A BUFFER THAT NO LONGER
          EXISTS. SUBROUTINE UNPTREE, IN AAM$AA, IS PROVIDED AS A 
          SAFEGUARD FOR THIS SITUATION, BUT IT IS NOT AN ENTRY POINT. 
          RATHER THAN MAKING UNPTREE AN ENTRY POINT, THE CORRECTIVE 
          CODE LETS VANB$IS CALL SEBL$IS FOR THE NEW BLOCK. THIS
          IN TURN CALLS UNPTREE. A LITTLE TIME IS WASTED, BUT VANB$IS 
          IS NOT EXECUTED OFTEN.
          AFRB   05/02/84    ISDRARE
  
 AM20184  AAM2PL
          A LINE OF CODE SOMEHOW WAS LOST FROM THE CORRECTIVE CODE IN 
          AM20160. THIS CORRECTIVE CODE SUPPLIES THAT MISSING LINE. 
          AFRB   06/14/84    CRA1DAA
  
 *L642*    ************************************************ 
 AM2A302  AAM2PL
          WHEN AN UPDATE OF AN ACTUAL-KEY FILE WITH ALTERNATE KEYS FAILS
          BECAUSE OF A DUPLICATE-ALTERNATE-KEY ERROR, SUBROUTINE ZIPMIP 
          IN MODULE NRO$AK RETURNS DIRECT TO EXIT$AA, AFTER THE ERROR 
          MESSAGE HAS BEEN ISSUED, INSTEAD OF LETTING A NORMAL RETURN FROM
          MODULE NRO$AK TO EXEC$AK HAPPEN. THIS MEANS THAT IF FSMODFLG IN 
          THE AK-FILE FSTT HAS BEEN SET BY ROUTINE ALTR$AA, IT DOES NOT 
          GET RESET AT THE CONCLUSION OF THE OPERATION, IN EXEC$AK. 
  
          IF THE FILE IS THEN CLOSED, WITHOUT A SUCCESSFUL UPDATE OPERATION 
          INTERVENING, FSMODFLG REMAINS SET, AND CAUSES A 202 ERROR THE NEXT
          TIME THE FILE IS OPENED. ONLY RECENTLY DID THE OPEN ROUTINE BEGIN 
          TO CHECK FSMODFLG, WHICH IS WHY THE BUG ONLY RECENTLY TURNED UP.
          (IT APPEARED THAT THE BUG WAS CAUSED BY AM2A290, BUT I THINK THAT 
          ONLY UNMASKED IT, BY CAUSING A TEST CASE TO GET THE 503 ERRORS THAT 
          IT HAD LONG DESERVED BUT NEVER BEFORE RECEIVED.)
  
          THE CORRECTIVE CODE LETS ZIPMIP RETURN, INSTEAD OF JUMPING TO 
          EXIT$AA. THE CALLER OF ZIPMIP MUST THEN TEST RHO, WHICH WILL BE 
          NON-ZERO IF AND ONLY IF ZIPMIP FAILED, AND RETURN TO EXEC$AK
          IF IT IS NON-ZERO. THE 503 ERROR HAS ALREADY BEEN ISSUED BY 
          A ROUTINE IN MODULE UPDT$MP.
  
          THERE ARE SOME OTHER PLACES WHERE SUBROUTINE PUT$AK AND REPL$AK JUMP
          TO EXIT$AA INSTEAD OF EXITING, THUS CAUSING A RISK OF LEAVING FSMODFLG
          SET. THESE ARE CHANGED TO RETURNS.
  
          IN MODULE AK$RARE, SIMILARLY, THERE ARE JUMPS TO EXIT$AA THAT REALLY
          SHOULD NOT BE THERE. IT IS NOT QUITE SO SIMPLE TO REPLACE THEM WITH 
          SIMPLE RETURNS. THERE IS NO OBVIOUS SIGNAL (LIKE RHO NOT ZERO IN
          ZIPMIP) TO INDICATE THAT THIS IS AN ERROR RETURN, SO THAT PUT$AK OR 
          REPL$AK WILL EXIT WITHOUT DOING ANY MORE. WE USE NEWBNUM = -1 FOR 
          THIS SIGNAL. THEN WE SET NEWBNUM = 0 AT THE BEGINNING OF REPL$AK AND
          PUT$AK, TO MAKE SURE -1 WILL NOT TURN UP ACCIDENTALLY.
  
          A JUMP TO EXIT$AA ALSO OCCURS IN SUBROUTINE ZIPMIP OF MODUL NRO$DA. 
          THIS IS REPLACED BY A RETURN, FOR THE SAME REASON AS IN ZIPMIP IN 
          NRO$AK, AND THE CALLS TO ZIPMIP HAVE TESTS FOR RHO NON-ZERO RIGHT 
          AFTER THEM. THERE ARE NO JUMPS TO EXIT$AA IN MODULES NRO$IS AND 
          IS$RARE.
          AFRB   02/13/85    NRODAK 
  
 AM2A304  AAM2PL
          THE STANDARD SYSTEM COMPRESSION ROUTINE, IN MODULE CMPR$01, DOES
          NOTHING WHEN THE COMPRESSIBLE PART OF THE RECORD IS LESS THAN 
          10 CHARACTERS LONG. IT DOESNT EVEN RETURN THE PASSWORD, AND THIS
          MAY CAUSE A 536 ERROR TO APPEAR, ALTHOUGH THE RECORD IS STILL 
          PUT INTO THE FILE ALL RIGHT -- SUCH AN ERROR MEANS THE RECORD 
          IS PUT INTO THE FILE UNCOMPRESSED.
  
          THE CORRECTIVE CODE, IN CMPR$01, CAUSES THE PASSWORD TO BE
          RETURNED BEFORE THE TEST OF RECORD LENGTH IS MADE, SO THAT
          EVEN IF THE RECORD IS TOO SHORT TO COMPRESS, THE PASSWORD 
          ERROR WILL NOT OCCUR. 
          AFRB   02/21/85    CMPRD01
  
 AM20185  AAM2PL
          AM20127 ADJUSTED THE CLOSE ROUTINE SO THAT CLOSE-UNLOAD WOULD 
          UNLOAD THE MIP FILE, IF PRESENT, AS WELL AS THE DATA FILE. BUT
          IT FAILS TO CATCH THE CASE WHEN ONLY THE MIP FILE IS PRESENT, 
          FOR INDEX-ONLY ACCESS. THIS IS BECAUSE IN MODULE OPEN$AA, 
          PROCEDURE CLOSFIL, THE PARAMETER ((WHICH)) IS EXPECTED TO BE
          NON-ZERO FOR THE MIP FILE, AND ZERO FOR THE DATA FILE. BUT
          WHEN ONLY THE MIP FILE IS PRESENT (NDX=1), THIS PARAMETER 
          TURNS OUT TO BE ZERO ANYWAY. SO INSTEAD OF USING THIS PARAMETER 
          TO DECIDE WHETHER IT IS ACTING ON THE MIP FILE, CLOSFIL 
          WILL TEST WHETHER THE FILE NAME IN THE FET IS THE SAME AS 
          THE FILE NAME IN THE FIT -- THEY ARE THE SAME FOR THE DATA
          FILE, BUT DIFFERENT FOR THE MIP FILE, REGARDLESS OF 
          WHETHER THE DATA FILE IS REALLY PRESENT.
          AFRB   08/10/84    OPENDAA
  
 AM20199  AAM2PL
          THE STANDARD D-A KEY-HASHING ROUTINE WAS MIS-COPIED FROM AAM 1.5
          TO AAM 2.0. IT IS TOO LATE TO RECTIFY THIS, BECAUSE OF COMPATIBILITY
          PROBLEMS. AS THE KYAN UTILITY CONTAINS A SEPARATE COPY OF THE 
          ROUTINE, THE CORRECTIVE CODE ALTERS THIS TO MAKE IT THE SAME AS 
          WHAT AAM 2.0 ACTUALLY USES AS THE STANDARD D-A HASH ROUTINE.
          AFRB   10/03/84    SDAHASH IN KEYA
  
 AM20201  AAM2PL
          THERE IS AN ARRAY OF THREE WORDS CALLED CHANGE[1..3] USED TO
          NOTE CHANGES AT THE THREE LEVELS OF A MIP FILE. IN A PERFECT
          WORLD, THERE WOULD BE A SEPARATE ARRAY FOR EVERY INSTANCE OF
          OPEN, OR AT LEAST FOR EVERY MIP FILE, BUT IN FACT THERE IS
          ONLY ONE FOR EVERYBODY. BECAUSE OF THE LOW DEGREE OF OVERLAP
          AND CONCURRENCY, IT LOOKED, AFTER LONG CONSIDERATION, AS IF 
          THIS WAS ALL RIGHT. UPDATES AND GETS WOULD NOT INTERFERE
          WITH EACH OTHER. AT WORST, GETS WERE NOT BEING TRULY SPOILED
          BUT THEY WERE BEING SPURIOUSLY TOLD TO FLUSH BLOCKS, THOUGH 
          THE BLOCKS HAD NOT REALLY BEEN ALTERED, AND THIS CAUSED ABORTS
          WHEN FILE PERMISSION WAS WRONG. THREE PSR-S WERE CONCERNED WITH 
          AVOIDING THAT. A REAL KILLER HAS FINALLY BEEN UNMASKED. 
          ON A CLOSE OR A GET THAT FOLLOWS AN UPDATE BY A DIFFERENT 
          INSTANCE OF OPEN, AN OLD VERSION OF A SUB-FILE HEADER MAY 
          GET COPIED INTO A RECORD, OVERWRITING THE NEW VERSION.
  
          IT LOOKS AS THOUGH CLEARING A CHANGE WORD TO 0 AFTER
          RESPONDING TO IT WOULD BE A SUFFICIENT FIX, BUT THE USER WHO
          HEROICALLY TRACKED DOWN THIS BUG HAS MADE THAT IMPROVEMENT
          IN HIS OWN REMEDIAL CODE, WHICH SEEMS TO CURE EVERYTHING, 
          AND ALSO PROVIDED A SEPARATE CHANGE ARRAY FOR EACH MIP
          FILE, USING UNUSED WORDS IN THE MIP FSTT. 
  
          THIS CORRECTIVE CODE REPLACES REFERENCES TO THE CHANGE
          ARRAY WITH REFERENCES TO A SET OF 3 UNUSED BITS IN THE
          MPAT$AA STRUCTURE IN THE FIAT, REFERENCING THEM BY A
          MACRO CALLED ((VARIANCE)). SO A SEPARATE SET OF CHANGE FLAGS
          IS PROVIDED FOR EVERY INSTANCE OF OPEN. IT IS PROBABLY NO SAFER 
          THAN ONE SET PER MIP FILE, BUT IT AVOIDS MESSING WITH THE FSTT. 
          THESE FLAGS, WHATEVER THEY ARE, ARE ONLY SET TO 1 DURING
          UPDATE OPERATIONS. AN UPDATE OPERATION ALWAYS GOES TO COMPLETION
          BEFORE ((GIVING UP THE CP)), AND IT SHOULD NOW SET THE FLAGS
          BACK TO ZERO BEFORE ANY OTHER OPERATION GETS TO SEE THEM. 
          AS THE FLAGS ARE NOT FOR COMMUNICATION BETWEEN INSTANCES OF OPEN, 
          IT CAN AT LEAST DO NO HARM TO HAVE A SEPARATE SET FOR EACH
          INSTANCE OF OPEN. 
  
          THE CHANGE FROM ((CHANGE)) TO ((VARIANCE)) IS MADE BECAUSE
          THE AFORESAID USER MADE A SIMILAR CHANGE, AS WELL AS CLEARING 
          THE CHANGE FLAG, AND FOUND IT WORKED WELL. THE CORRECTIVE CODE
          CLEARS THE CHANGE FLAG AT THE RIGHT TIME, UNDER ITS NEW NAME, 
          AND PROVIDES A SET OF (RENAMED) CHANGE FLAGS FOR EVERY INSTANCE 
          OF OPEN.
          AFRB   11/07/84    MIPDMIP NRODMIP
  
 AM20207  AAM2PL
          IF AN ACTUAL-KEY FILE HAS AN ALTERNATE KEY WITH FIFO DUPLICATES,
          AND ONE DOES A GET-NEXT-WITHOUT-RECALL WHILE POSITIONED BY THAT 
          ALTERNATE KEY, PROCEDURE GTNR$AK IN MODULE AK$AK IN EFFECT
          CONVERTS THE ACTION INTO A PLAIN GET-NEXT, AND CALLS GETN$AK. 
          GETN$AK EXPECTS P<FSTT$AA> TO POINT TO THE FSTT OF THE DATA 
          FILE, BUT IN THE CASE JUST DESCRIBED, GETN$AK IS CALLED WITH
          P<FSTT$AA> POINTING TO THE FSTT OF THE MIP FILE. FSPUTCNT 
          IS A FIELD IN THE FSTT OF A DATA FILE THAT COUNTS THE NUMBER OF 
          PUT OPERATIONS THAT HAVE TAKEN PLACE IN THE LIFE OF THE FILE. 
          IN A MIP FILE, THE SAME FIELD IS ALWAYS 0. CALLING GETN$AK WITH 
          P<FSTT$AA> POINTING TO THE MIP FILE CAUSES US TO LOOK AT THE
          FSPUTCNT IN THE MIP FILE, WHICH IS 0, AND CONCLUDE WRONGLY
          THAT THE DATA FILE IS EMPTY, AND SO END-OF-INFORMATION
          STATUS IS WRONGLY RETURNED. 
  
          THE CORRECTIVE CODE RESETS P<FSTT$AA> BEFORE CALLING GETN$AK
          IN THIS PARTICULAR CASE.
  
          THE CORRESPONDING ERROR DOES NOT OCCUR FOR I-S OR D-A DATA FILES
          WITH ALTERNATE KEYS, BECAUSE THERE IS NO NEED, WITH THEM, TO
          USE FSPUTCNT THIS WAY.
          AFRB   02/28/85    AKDAK
  
 *L650*    ************************************************ 
 AM2A305  SOME USERS COMPLAIN THAT AAM DOES NOT KEEP ENOUGH DATA BLOCKS 
          AVAILABLE IN MEMORY -- THE INDEX BLOCKS ARE CONSIDERED LESS 
          VALUABLE THAN DATA BLOCKS.  THIS MAY IN GENERAL BE TRUE, BUT
          FOR SOME APPLICATIONS THAT DO CLUSTERED RANDOM ACCESSES, THE
          OLDER INDEX BLOCKS ARE NOT AS VALUABLE AS RECENT DATA BLOCKS. 
  
          THIS CREATES AN ITEM, AAM$PBC (PRIORITY BLOCK COUNT), THAT IS 
          THE MAXIMUM NUMBER OF INDEX BLOCKS (OR CAPSULES) TO KEEP IN THE 
          PRIORITY PART OF THE KICKOUT CHAIN, AND OTHER INDEX BLOCKS
          WOULD THEN AGE OUT AT THE SAME RATE AS DATA BLOCKS.  THIS 
          ITEM IS PRESET TO A LARGE NUMBER SO AAM WILL FUNCTION AS IT 
          ALWAYS HAS.  IF THE USER SETS IT TO A LOWER VALUE, THEN THIS
          CODE WILL BE ACTIVATED.  THE VALUE IS DYNAMIC -- IT IS CHECKED
          FOR EACH BLOCK AGED.
  
          THIS CODE REQUIRES INSTALLATION OF SW1A649 IN BAM.
  
          CFR    85/09/04    AAMDAA 
  
 AM20209  AAM2PL
          THERE IS A CASE IN WHICH PRODEDURE SKIP$IS, IN MODULE SEEK$IS,
          FAILS TO SET THE QFR (FIRST RECORD) FLAG IN THE PTREE THOUGH
          IT SHOULD. THIS LEADS TO TROUBLE DURING LATER BACKSPACE ACTIONS,
          WHICH RELY ON THE QFR FLAG. 
          IT IS AN UNUSUAL CASE, BECAUSE IT HAPPENS ONLY DURING BACKSPACE 
          ON A ONE-RECORD FILE. IF THE BACKSPACE IS FROM EOI POSITION, WE 
          CLEAR THE EOI FLAG AND STAND ON THE LAST RECORD, WHICH COUNTS AS
          ONE BACKWARD STEP. BUT WE NEGLECT TO CHECK WHETHER THE FIRST- 
          RECORD FLAG SHOULD BE SET. THE CORRECTIVE CODE DOES THIS. 
          AFRB  03/25/85    SEEKDIS 
  
 AM20211  AAM2PL
          AM20207 TRIES TO FIX A PROBLEM WITH FIFO ALTERNATE KEYS TO
          AN A-K FILE BY MAKING SURE, AT A CERTAIN POINT, THAT THE
          FSTT POINTER POINTS TO THE MAIN FILE AND NOT THE MIP FILE.
          IT NEGLECTS THE DETAIL THAT MIPMODE SHOULD = 0 WHEN THE 
          FSTT POINTER POINTS TO THE MAIN FILE, AND NOT = 0 WHEN THE
          FSTT POINTER POINTS TO THE MIP FILE. NORMALLY, MIPMODE AND
          THE POINTER ARE SET AT THE SAME TIME BY SUBROUTINE STMD$AA
          IN MODULE AAM$AA. AM20207 CHANGES THE FSTT POINTER AND JUMPS
          TO NOHOPE, WHERE GETN$AK IS CALLED. GETN$AK CALLS GETN$MP 
          IN MODULE MIP$MIP, WHICH CALLS KRAK$MP. IF KRAK$MP FINDS
          MIPMODE IS NOT 0, IT ASSUMES THE FSTT POINTER POINTS TO THE 
          MIP FILE, WHICH IS AN INCORRECT ASSUMPTION IF AM20207 HAS 
          COME INTO PLAY. SO WE NEED TO MODIFY THE AM20207 CODE TO
          MAKE IT ZERO MIPMODE. 
          AFRB   05/02/85   AKDAK 
  
 AM20212  AAM2PL
               FLBLOK MAY GIVE DIFFERENT ((PROBABLE BEST MBL)) VALUES 
          FOR THE SAME INPUTS, DEPENDING ON WHETHER THE OUTPUT IS ON
          THE TERMINAL OR ON A PRINTABLE OUTPUT FILE. ON THE TERMINAL,
          THE CHOICE IS THE BLOCK SIZE WITH THE BEST RANDOM-GET 
          PREDICTED SPEED. ON A PRINTABLE FILE, THE CHOICE IS OFTEN A 
          MUCH LARGER BLOCK SIZE, PROBABLY UNREASONABLY LARGE.
               THE CORRECTIVE CODE MAKES THE SAME SUGGESTED MBL COME
          OUT IN BOTH CASES. THIS IS THE LARGEST BLOCK SIZE THAT HAS A
          PREDICTED RANDOM-GET SPEED AT LEAST 10/11 OF THE BEST 
          PREDICTED RANDOM-GET SPEED. IN OTHER WORDS, THE BLOCK SIZE
          WITH THE BEST RANDOM-GET SPEED, ALLOWING A 10 PERCENT 
          CONCESSION IN FAVOR OF BIGGER BLOCKS, WHICH OFFER BETTER
          CONSECUTIVE-GET SPEED.
               ALSO, THE CORRECTIVE CODE PROVIDES THAT, WHEN OUTPUT IS
          ON THE TERMINAL, EVERY BLOCK SIZE THAT IS CONSIDERED WILL 
          HAVE A ROW OF NUMBERS DISPLAYED FOR IT. HITHERTO, ONLY ONE
          BLOCK SIZE FOR EACH POSSIBLE NUMBER OF INDEX LEVELS HAS BEEN
          DISPLAYED, NAMELY THE SMALLEST BLOCK SIZE WITHIN THE GROUP, 
          WHICH WOULD HAVE THE BEST RANDOM-GET SPEED WITHIN THE GROUP.
          TERMINALS ARE FASTER NOWADAYS THAN WHEN FLBLOK WAS WRITTEN, 
          AND IT SEEMS TOLERABLE TO DISPLAY A LINE FOR EACH OF, SAY,
          25 POSSIBLE BLOCK SIZES, INSTEAD OF ONLY 3 SELECTED SIZES.
          A SECOND FLAW IN FLBLOK IS THAT THE CHECK FOR WHETHER A GIVEN 
          BLOCK SIZE WILL CONTAIN AT LEAST ONE MAXIMUM-LENGTH RECORD, 
          WITHIN THE PADDING RESTRICTION, NEGLECTS THE SPACE NEEDED FOR 
          A RECORD POINTER. THIS MEANS THAT A SUGGESTED BLOCK SIZE
          CAN LATER BE REJECTED BY AAM OPEN. THE CORRECTIVE CODE BRINGS 
          THE FLBLOK TEST INTO LINE WITH THE TEST IN THE OPEN MODULE. 
          NOR DOES FLBLOK TEST WHETHER, WITH THE GIVEN INDEX PADDING, 
          A GIVEN BLOCK SIZE WOULD ALLOW AT LEAST TWO INDEX RECORDS.
          THIS TEST IS ALSO ADDED IN THE CORRECTIVE CODE. 
               FINALLY, AAM OPEN ISSUES A 530 ERROR IF MBL IS TOO 
          SMALL. THIS IS AN OVERSIGHT, AS A 544 ERROR WAS INTENDED. 
          THE CORRECTIVE CODE INCLUDES A CHANGE TO OPEN$AA. 
          THE ERROR EXPLANATION IN THE REFERENCE MANUAL WILL BE 
          ALTERED TO SAY THAT EITHER MBL NEEDS TO BE BIGGER, OR MAYBE 
          A PADDING PERCENTAGE NEEDS TO BE SMALLER. 
          AFRB   05/28/85    FLBLOCKF,OPENDAA 
  
 AM20217  AAM2PL
          WHEN A SERIES OF SEEKS BY ALTERNATE KEY IS COMPLETED BY 
          A GET, THE GET MUST SET FILE POSITION TO EOR OR EOK --
          EOK IF THE PRIMARY-KEY VALUE IS THE ONLY, HENCE LAST, ONE 
          FOR THE GIVEN ALTERNATE-KEY VALUE, OR EOR OTHERWISE. BUT
          THE QUESTION HAS TO BE DECIDED WHILE ONE OF THE SEEKS IS
          LOOKING AT THE MIP FILE, NOT WHILE THE FINAL GET IS LOOKING 
          AT THE DATA FILE. A FLAG CALLED MPSOK IS PROVIDED FOR 
          SAVING THE INFORMATION, BUT IT IS NOT BEING SET CORRECTLY.
          FUNCTION EOKS$MP IS BEING CALLED TO DETERMINE ITS VALUE.
          THIS FUNCTION IS APPROPRIATE FOR SETTING A SIMILAR FLAG,
          MPEOK, WHEN A POSITION IN THE FILE IS BEING SET BY
          ALTERNATE-KEY AND PRIMARY-KEY VALUES, BUT IT DOES NOT HAVE
          ALL THE NEEDED INFORMATION WHEN A SEEK IS BEING DONE. 
          HOWEVER, ALL WE NEED TO KNOW, TO SET MPSOK, IS WHETHER
          THERE IS A SUB-FILE OR SUB-BLOCK DEPENDENT ON THE CURRENT 
          LEVEL-2 RECORD IN THE MIP FILE, AND A FLAG IN THE CURRENT 
          RECORD POINTER IS IMMEDIATELY AVAILABLE. THE CORRECTIVE 
          CODE SETS MPSOK TO THE CONVERSE OF THIS FLAG. 
  
          DURING SEQUENTIAL READING OF A CDCS RELATION, THIS
          OCCASIONALLY CAUSES OMISSION OF AN OCCURRENCE OF THE RELATION.
          AFRB   06/14/85    SEEKDMP
  
 AM20220   AAM2PL 
          THE LOGGING MECHANISM IS NOT GETTING BEFORE-IMAGES OF THE 
          FSTT WRITTEN TO THE LOG FILE. THEY NEED TO BE WRITTEN OUT 
          JUST BEFORE THE FILE BEGINS TO BE CHANGED, AFTER AN OPEN
          OR A FLUSH. THERE IS A FLAG FOR THIS, FSALTFLG, BUT IT IS 
          NOT BEING PROPERLY USED.
               THE CORRECTIVE CODE PROVIDES THAT THIS FLAG BE CLEARED 
          BY OPEN OR FLUSH, AND SET (OR LEFT=1) WHENEVER SUBROUTINE 
          ALTR$AA IS CALLED FOR ANY BLOCK. WHEN THE FLAG IS CHANGED 
          FROM 0 TO 1, IF LOGGING IS IN EFFECT, THE FSTT IS LOGGED
          JUST THE WAY AN ORDINARY BLOCK WOULD BE LOGGED, WHEN
          ITS FLAG BLALTFLG IS CHANGED FROM 0 TO 1. DURING THE COURSE 
          OF AN UPDATE OPERATION, NO IMPORTANT CHANGE IS MADE TO THE
          FSTT UNTIL ONE OF THE ORDINARY BLOCKS HAS BEEN CHANGED, 
          SO THE FACT THAT THE FSTT WILL BE LOGGED, THROUGH ALTR$AA,
          BEFORE ANY CHANGE IS MADE TO AN ORDINARY BLOCK MEANS IT 
          WILL BE LOGGED BEFORE ITSELF, THE FSTT, HAS BEEN CHANGED. 
          AFRB   07/01/85    AAMDAA,AAMDNRO,OPENDAA 
  
 *L670*    ************************************************ 
 AM2A307  AAM2PL
          WHEN REPLACING A RECORD IN A FILE FOR WHICH ALTERNATE KEYS ARE
          DEFINED, FOR EVERY ALT KEY THAT DOES NOT HAVE REPEATING GROUPS
          WE COMPARE THE OLD AND NEW VALUES OF THAT ALT KEY, AND IF THEY
          ARE THE SAME WE CAN LEAVE THE EXISTING VALUE UNDISTURBED. 
          HOWEVER, THIS DOES NOT PROVIDE ENTIRELY FOR SPARSE KEYS. THE
          VALUES CAN BE THE SAME IN THE TWO RECORDS, AND YET THE SPARSE 
          CONTROL CHARACTER IN ONE RECORD CAN PROVIDE FOR ACCEPTANCE, 
          WHILE THE SPARSE CONTROL IN THE OTHER RECORD CAN PROVIDE FOR
          REJECTION. IN SUCH A CASE THE IDENTITY OF KEY VALUES DOES NOT 
          MEAN THAT NOTHING SHOULD BE DONE, BUT AT PRESENT NOTHING IS 
          DONE. 
  
          THE CORRECTIVE CODE INSERTS A TEST JUST BEFORE THE TWO KEY
          VALUES ARE COMPARED IN ROUTINE NEXSECKEY. THE NEW TEST
          DECIDES IF THE KEY VALUES IN THE OLD AND NEW RECORDS ARE BOTH 
          INCLUDED OR BOTH EXCLUDED BY SPARSE CONTROL, AND IF NOT,
          MAKES NEXSECKEY BEHAVE AS IF THE TWO VALUES ARE UNLIKE. 
  
          A SECOND PROBLEM WITH SPARSE KEYS IS SIMILAR TO THE 
          NULL-VALUE PROBLEM IN AM20065. IF THE KEY VALUE IN THE
          OLD RECORD IS EXCLUDED BY NULLNESS, WE HAVE TO SET A
          VARIABLE ((NULLKEY)) TO 1, TO FORCE BIGPUT TO BE
          CALLED, DURING A REPLACE, BY REPL$MP. BUT THE SAME IS 
          TRUE WHEN THE VALUE IN THE OLD RECORD IS EXCLUDED BY
          THE SPARSE CONTROL CHARACTER. CORRECTIVE CODE WILL NOW
          SET NULLKEY=1 IN THE LATTER CASE. 
          AFRB   01/10/85    NRODMIP
  
 AM2A309 AAM2PL 
         IN AN AK FILE, WHEN A NEW RECORD IS ADDED AFTER THE LAST 
         RECORD IN A BLOCK, THE LOGGING ROUTINE IS NOT CALLED SOON
         ENOUGH. THE RECORD COUNT IS LIKELY THE FIRST THING IN THE
         BLOCK TO BE CHANGED, AND THIS IS DONE BEFORE ALTR$AA IS
         CALLED, AND SO BEFORE ANY POSSIBILITY OF LOGGING.
         THE CORRECTIVE CODE PUTS A CALL TO ALTR$AA INTO
         SUBROUTINE SETR$AK OF MODULE NRO$AK. 
         AFRB   04/16/86    NRODAK
  
 AM20228  AAM2PL
          AT THE BEGINNING OF EACH OPERATION, SUBROUTINE AAM$CTL CHECKS 
          THE FSTT OF AN AAM DATA FILE, AND ITS COMPANION MIP FILE IF ANY,
          TO SEE IF FIELD FSFTERR IS NON-ZERO, MEANING A PREVIOUS ERROR 
          FORBIDS ACCESS TO THE FILE. THE ADDRESSES OF THE 2 FSTT-S ARE 
          IN FIELDS FTFSTT AND FTMIPFS OF THE FIT, AND IF EITHER ADDRESS
          IS 0, THERE IS NO CORRESPONDING FSTT TO BE CHECKED. 
  
          AN EXCEPTION IS MADE WHEN THE CURRENT OPERATION IS AN OPEN. 
          THE CHECK IS NOT MADE, BECAUSE OBVIOUSLY THE FSTT-S ARE NOT 
          AVAILABLE TO BE CHECKED YET. THE SAME EXCEPTION SHOULD BE 
          MADE ON A SETFIT OPERATION, BUT IT IS NOT. IT IS A LITTLE 
          STRANGE THAT THIS BUG HAS NOT APPEARED MUCH OFTENER.
          USUALLY AT THIS TIME, FIELD FTFSTT IS 0 ANYWAY, AS THERE IS 
          NO REASON FOR IT TO BE PRESET. BUT FIELD FTMIPFS IS ALSO USED 
          AS FIELD FTXBS, GIVING THE BLOCK SIZE FOR A FUTURE MIP FILE.
          IF FTXBS IS UNSET AND 0, NOTHING BAD HAPPENS. 
  
          BUT IF FTXBS IS NON-ZERO, AAM$CTL TREATS IT AS THE ADDRESS OF 
          AN FSTT, AND LOOKS IN BITS 0-8 OF THE WORD AT FTXBS+174B FOR
          AN ERROR CODE. AGAIN, IF THAT FIELD OF THAT WORD HAPPENS TO 
          BE 0, WHICH APPARENTLY IS USUALLY THE CASE, NO HARM IS DONE.
          IN THIS CASE, HOWEVER, THE FIELD CONTAINS 17B, WHICH IS 
          ERRONEOUSLY TREATED AS A FATAL ERROR CODE.
  
          THE CORRECTIVE CODE SKIPS THE CHECKS ON A SETFIT AS WELL
          AS AN OPEN. 
          AFRB   05/12/86    AAMDCTL
  
 *L688*    ************************************************ 
 AM2A311  AAM2PL
          AN INTEGER NAMED CKEY IS USED IN AK$AK AND NRO$AK TO HOLD THE 
          VALUE OF THE CURRENT PRIMARY KEY. CKEY IS DEFINED AS KEYHOLE[0],
          WHICH IS UNFORTUNATE. SUBROUTINE ZIPMIP, IN NRO$AK, CALLS 
          PUT$MP, WHICH CALLS BIGPUT, WHICH CALLS PTRP$MP, WHICH CALLS
          PTRP$IS, WHICH CALLS KYSV$IS, WHICH WRITES INTO KEYHOLE[0] AND
          THUS DESTROYS CKEY. FORTUNATELY, WHEN ZIPMIP IS CALLED, WE ARE
          ALREADY THROUGH WITH CKEY, EXCEPT IN ONE CASE -- IF KEYS ARE
          NON-EMBEDDED, AND THE USER IS PUTTING-WITHOUT-KEY.
  
          IN SHORT, IF A USER PUTS INTO AN AK FILE WITH ALTERNATE KEYS
          AND NON-EMBEDDED PRIMARY KEY, GIVING A PRIMARY KEY VALUE OF 
          ZERO, EXPECTING AAM TO CHOOSE A CONVENIENT PRIMARY KEY VALUE
          AND RETURN IT AT KA, A WRONG VALUE WILL BE RETURNED AT KA 
          IF A NEW BLOCK IS CREATED IN THE MIP FILE. HOWEVER, WHAT IS 
          STORED IN THE MIP FILE AND THE DATA FILE WILL BE CORRECT -- 
          ONLY WHAT IS RETURNED AT KA WILL BE WRONG.
  
          THE CORRECTIVE CODE COPIES CKEY, IN THE BAD CASE, INTO AN 
          INTEGER CALLED SVCKEY, WHICH WILL NOT BE WRITTEN INTO BY
          ANY OTHER PIECE OF CODE, AND RETURNS SVCKEY RATHER THAN CKEY
          TO THE USER AT KA.
          AFRB   09/17/86    NRODAK 
  
 AM2A312  PROBLEM  - CDCS USERS GET CRM ERROR 052 FOLLOWING A CDCS
                     RECOVERY.
                     THIS OCCURS BECAUSE THE INITIAL IMAGE OF THE FSTT
                     IS NOT LOGGED ON THE QUICK RECOVERY FILE.
                     THE FIRST FSTT IMAGE THAT IS RECORDED HAS THE
                     OPEN FLAG SET, INDICATING THAT THE FILE HAS NOT
                     BEEN FLUSHED OR CLOSED SINCE IT WAS ALTERED. 
          SOLUTION - AAM$NRO ATTEMPTED TO ENHANCE PERFORMANCE BY NOT
                     CALLING THE LOGGING ROUTINE UNDER SOME CONDITIONS. 
                     IT WILL NOW RISK LOGGING TOO FREQUENTLY TO BE SURE 
                     THAT LOGGING IS DONE WHEN REQUIRED.
          AFRB/RLM 87/03/11   AAMDNRO 
  
 AM2A313  AAM2PL
          IT IS POSSIBLE FOR THE PC FIELD OF A FIT TO BE NON-ZERO 
          AFTER AN AAM OPEN. (PADDING CHARACTER). AS THIS FIELD 
          OVERLAPS WITH THE MKL FIELD (MAJOR KEY LENGTH), IT
          MIGHT CAUSE AN ABSURDLY LARGE VALUE TO BE USED AS MAJOR 
          KEY LENGTH BY THE FIRST OPERATION AFTER THE OPEN, AND 
          ANY SORT OF ERROR COULD OCCUR. NOTE THAT ANY OPERATION
          THAT USES THE MKL FIELD ZEROES IT, SO IF THE FIRST SUCH 
          OPERATION DOESNT ABORT THE JOB, LATER OPERATIONS WORK 
          NORMALLY. THEREFORE, OPEN SHOULD ZERO THE MKL FIELD AS
          PART OF ITS INITIALIZATION. 
  
          IN GENERAL, A USER IS RESPONSIBLE FOR NOT KILLING HIMSELF 
          BY PUTTING GARBAGE IN THE FIT. BUT WE HAVE JUST SEEN AN 
          ODD CASE OF A PRODUCT THAT SETS UP A FIT AS IF FOR A
          SEQUENTIAL FILE, WITH A DEFAULT VALUE OF 76(8) IN THE 
          PC FIELD, THEN CHANGES TO INDEXED-SEQUENTIAL WITH A FILE
          CARD, WITHOUT CLEARING THE PC FIELD, THEN OPENS THE I-S 
          FILE, THEN DOES A GET. THE GET SEES A SPURIOUS VALUE OF 
          600(8) IN THE MKL FIELD, USES IT, AND ABORTS THE JOB. 
  
          THE CORRECTIVE CODE, IN OPEN$AA, ZEROS THE MKL FIELD AT 
          THE VERY BEGINNING OF THE OPEN PROCESS. 
          AFRB   03/18/87    OPENDAA
 AM20231  AAM2PL
          IN FLSTAT, IF ((*DEFINE STATS)) DOES NOT APPEAR IN THE
          UPDATE INPUT, ((DEF STATS #0#;)) IS GENERATED IN THE
          COMPILE FILE. IF IT DOES APPEAR, ((DEF STATS #1#;)) IS
          GENERATED, BUT TWICE. TO GET RID OF THE SUPERFLUOUS 
          OCCURRENCE OF THE LATTER, *DELETE FLSTAT.67 
          AFRB   08/21/86    FLSTAT 
  
 *L716*    ************************************************ 
 *L739*    ************************************************ 
 *L780*    ************************************************ 
 AM20247  PROBLEM  - CRM ERROR 135 -- BLOCK LENGTH ERROR. 
  
                     WHEN AN INVALID AK KEY IS PROVIDED THAT IS SO
                     LARGE THAT THE COMPUTED PRU NUMBER EXCEEDS 24 BITS,
                     BUT THE LOW ORDER 24 BITS OF THAT NUMBER HAPPEN TO 
                     FALL WITHIN THE LIMITS OF THE FILE,  AAM READS THIS
                     RANDOMLY SELECTED PRU. 
                     IF IT DOES NOT HAPPEN TO BE THE FIRST PRU OF THE 
                     BLOCK, THE BLOCK LENGTH ERROR RESULTS. 
          SOLUTION - CHECK IF THE PRU NUMBER EXCEEDS 24 BITS. 
          AFB/RLM 91/06/17   NRODAK, AKDAK
  
 *L797*    ************************************************ 
 *L803*    ************************************************ 
 *L826*    ************************************************ 
 AM2*94   PROBLEM -  COPYRIGHT STATEMENTS NEED TO BE UPDATED. 
  
          SOLUTION - UPDATE ALL COPYRIGHTS TO 1994 AND CHANGE ANY REFERENCES
                     TO CONTROL DATA CORPORATION TO CONTROL DATA SYSTEMS INC. 
  
          BAO    04/20/94  AAMDCTL,FLSTATC
 *L840*    ************************************************ 
 *L847*    ************************************************ 
 *L851*    ************************************************ 
 *L859*    ************************************************ 
 *L871*    ************************************************ 
  
  
