PDP-10 Archive: autopatch/db20v6.d04 from BB-L014E-BM

Trailing-Edge - PDP-10 Archives - BB-L014E-BM - autopatch/db20v6.d04
There are no other files named db20v6.d04 in the archive.
                 EDIT DESCRIPTIONS FOR DBMS-20-V6                               
  
  
                             EDIT 364    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 364 *************************
; 
;SYMPTOM
;	ERROR 357 SHOWS UP WHILE RUNNING 8 COPIES OF DECU SIMULTANEOUSLY.
; 
;DIAGNOSIS
;	NEX.BUOY ATTEMPTS TO LOAD THE OWNER POINTER INTO THE NEW BUOY FROM
;	OB.COWN(SETBLK).  IT DOES NOT ALWAYS HAVE THE OWNER POINTER.
; 
;CURE
;	GET THE OWNER POINTER FROM OWNDBK(X).
; 
; 
********************************************************************************
  
  
                             EDIT 365    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 365 *************************
; 
;SYMPTOM
;	DBMEND GETS "INVALID BLOCK DESCRIPTOR..." ON /MERGE BEFORE
; 
;DIAGNOSIS
;	TYPO IN JRFEOJ IN DBJOUR (DBMEND ONLY CODE)
; 
;CURE
;	CHANGE COPY JP.NEED(JP),JB.PREV(JP)
;	    TO COPY JP.NEED(JP),JB.PREV(R1)
; 
; 
********************************************************************************
  
  
                             EDIT 366    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 366 *************************
; 
;SYMPTOM
;	COBOL DBMS-20 V6 PROGRAMS MAY GET "ILL MEM REF" FROM COBFUN (FREE-PG)
;	OR DBMEND MAY GET "?CORBOV. FREE BLOCKS OVERLAP" DOING A /CLOSE ALL
;	AFTER A /MERGE BEFORE.
; 
;DIAGNOSIS
;	IF THE DBCS PAGE IS FULL, THE BEFORE IMAGE IS A FULL PAGE PLUS ROOM
;	FOR THE LOGICAL BLOCK (IMAGE) HEADER  (IN THIS INSTANCE 1003 WORDS
;	LONG).  DBOPEN ONLY ALLOCATES ONE PAGE FOR THE IMAGE; JR.SPLIT USES
;	ONE PAGE PLUS SPACE FOR THE LOGICAL BLOCK HEADER.  THIS RESULTS IN
;	THE FREE LIST GETTING ZAPPED (A DBMEND CORBOV) OR IN THE CASE WHERE
;	THE SPACE WAS ALLOCATED AN "ILL MEM REF".
; 
;CURE
;	HAVE DBOPEN ALLOCATE 3 EXTRA WORDS.
; 
; 
********************************************************************************
  
  
                             EDIT 367    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 367 *************************
; 
;SYMPTOM
;	DBMEND GETS "INVALID BLOCK DESCRIPTOR ON JOURNAL PAGE 2" AFTER A
;	/MERGE BEFORE COMMAND.
; 
;DIAGNOSIS
;	DBCS WHEN WRITING A BEFORE IMAGE (JR.BEF) WILL GARBAGE THE JOURNAL IF
;	1. THE JOURNAL BUFFERS ARE FLUSHED BECAUSE THE JRN BUFFERS ARE FULL
;	2. THERE IS A REMANENT OF THE LAST IMAGE IN THE "FIRST" JRNL BUFFER
;	3. THE TRANSACTION IS TERMINATED WITH A JBTRAN BEFORE ANYTHING ELSE
;	   IS PLACED IN THE JRNL BUFFERS.
;	JBTRAN DOES NOT RECOGNIZE THAT THERE IS DATA IN THE JRNL BUFFERS AND
;	DOES NOT FLUSH THE PARTIAL IMAGE; DOES NOT WRITE OUT BEFORE IMAGES
;	AND DOES NOT WRITE OUT A TRANSACTION TRAILER.
; 
;CURE
;	ENSURE THAT JRCOPY FLAGS THE JRNL BUFFER AS MODIFIED (JR.BFM) AND
;	DONT LET JREFILL DESTROY JR.BIX AFTER FLUSHING THE JRNL BUFFERS.
; 
; 
********************************************************************************
  
  
                             EDIT 373    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 373 *************************
; 
;SYMPTOM
;	Consecutive CALC FINDs to the same nonexistent database page
;	generate "MEMORY PROTECTION VIOLATION".
; 
;DIAGNOSIS
;	The page number is put into the buffer header block as an argument
;	for the SETLOK routine, which should then delete the number if the
;	page is not valid. In some situations, SETLOK is not clearing the
;	page number, so for a subsequent FIND, DBCS thinks that the page is
;	in the buffer, and tries to access it.
; 
;CURE
;	Move the code that clears the page number to an earlier section
;	of the SETLOK routine, where it will be in a common stream and
;	not sensitive to exception trapping.
; 
; 
********************************************************************************
  
  
                             EDIT 401    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 401 *************************
; 
;SYMPTOM
;	Error status 1559 during SBIND, code 15001, when trying to
;	open many data base areas.
; 
;DIAGNOSIS
;	Bad argument sent to ACM.M during transaction walk. Area walk
;	refilled the buffer because of large number of areas, but
;	transaction walk thinks correct schema page is in the buffer.
; 
;CURE
;	Use FINDR% to get correct page back in buffer before doing
;	transaction walk.
; 
; 
********************************************************************************
  
  
                             EDIT 405    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 405 *************************
; 
;SYMPTOM
;	During a DELETE TRANSACTION, DBMEND is clobbering areas that are
;	sharing buffers.
; 
;DIAGNOSIS
;	After the shared buffer information is set up (DBBIND), MNDIDB
;	should modify the area block for each area, so
;	that in reality all areas get their own buffers. However, the
;	routine to do this, SBI.LP, is trashing LISTPT, an AOBJN pointer
;	to all area blocks. As a result, only the first area in the list
;	is getting its shared buffer information cleared.
; 
;CURE
;	Move the area list pointer to a safe AC, so that it doesn't get
;	trashed. This will allow the shared buffer information to be
;	cleared from all areas.
; 
; 
********************************************************************************
  
  
                             EDIT 407    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 407 *************************
; 
;SYMPTOM
;	Consecutive CALC FINDs to the same nonexistent database page
;	generate "MEMORY PROTECTION VIOLATION".
; 
;DIAGNOSIS
;	The page number is put into the buffer header block as an argument
;	for the SETLOK routine, which should then delete the number if the
;	page is not valid. In some situations, SETLOK is not clearing the
;	page number, so for a subsequent FIND, DBCS thinks that the page is
;	in the buffer, and tries to access it.
; 
;CURE
;	Remove previous edit 373, which attempted to fix the problem by
;	moving the code that clears the page number to an earlier section
;	of the SETLOK routine, where it would be in a common stream and
;	not sensitive to exception trapping. Edit 373 caused the page
;	number to be cleared before it could be used as an argument
;	in setting a page lock. Instead, replicate the code that
;	clears the page number at all possible exit points in SETLOK.
; 
; 
********************************************************************************
  
  
                             EDIT 410    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 410 *************************
; 
;SYMPTOM
;	Possible ILLEGAL MEMORY REFERENCE when lock routine checks
;	lock page for shared locks.
; 
;DIAGNOSIS
;	The checking code can step off the end of the lock page, if the
;	particular lock entry was one part and occurred at the end of the
;	page.
; 
;CURE
;	Add code to verify that there is more space in the lock page
;	before trying to access the second part of a two part entry.
; 
; 
********************************************************************************
  
  
                             EDIT 411    FOR DBMS
  
;******************** START OF DBMS20-V6 EDIT 411 *************************
; 
;SYMPTOM
;	When trying to close a data base area after referencing a
;	nonexistent page, exception 0157 occurs with error data
;	601151 21009.
; 
;DIAGNOSIS
;	The routine ABT.PAG makes a check to see if a page was nonexistent,
;	and if it was, the routine does not unmap it. However, the page
;	is still mapped as far as the monitor is concerned, and so when
;	closing the area, the CLOSF JSYS fails.
; 
;CURE
;	Unmap all pages, even if they were nonexistent.
; 
; 
********************************************************************************
  
  
  
END OF  DBMS-20-V6