Trailing-Edge
-
PDP-10 Archives
-
BB-L014E-BM
-
autopatch/db20v6.d05
There are no other files named db20v6.d05 in the archive.
EDIT DESCRIPTIONS FOR DBMS-20-V6
EDIT 412 FOR DBMS
[SYMPTOM]
When trying to close the database after reading a partial cluster
(at end of area) over a full cluster, exception 0157 occurs.
[DIAGNOSIS]
Only part of the cluster is 'unmapped' by mapping in new pages.
However, DBCS forgets the page numbers of all the cluster pages
in its buffer headers. It later uses the buffer headers to
really unmap any database pages left in core at CLOSE time. Thus
it will unmap the partial cluster, but leave behind those pages
in the previous full cluster that were not overwritten.
[CURE]
Only forget those pages that are actually being overwritten,
leaving behind enough information to actually unmap them during
CLOSE if the need exists.
********************************************************************************
EDIT 415 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 415 *************************
;
;SYMPTOM
; MODIFY fails when a sort key is being modified, and the record
; is declared an optional member of the sorted set in question and
; at the time of the MODIFY is not actually a member.
; ERROR-STATUS = 822, ERROR-DATA = 28009.
;
;DIAGNOSIS
; The member-unlink code in DBSET detects an error if the pointer
; being cleared (unlinked) is already cleared, for all verbs except
; DELETE. However, the MODIFY code in DBMOD expects to get a cleared
; pointer returned as an indication the the record is not a current
; member of the sorted set.
;
;CURE
; Allow the unlink code to accept cleared pointers during the MODIFY
; verb in the same manner as during a DELETE, if treating an optional
; member of a sorted set.
;
;
********************************************************************************
EDIT 416 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 416 *************************
;
;SYMPTOM
; ERROR-STATUS typeout yields bad status after ?DBSXWX message.
;
;DIAGNOSIS
; THe binary value in ERROR-STATUS is correct, but it has not yet been
; translated into ASCII. Since the declared usage of ERROR-STATUS is
; DISPLAY-7, LIBOL attempts to interpret the binary value as ASCII
; bytes, thus the garbage being typed out.
;
;CURE
; Add a small routine in DBLEAV to translate the number to ASCII.
;
;
********************************************************************************
EDIT 417 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 417 *************************
;
;SYMPTOM
; Programs sleeps in 'OPEN JOURNAL' statement while a concurrent
; run-unit has a transaction opened.
;
;DIAGNOSIS
; The 'OPEN JOURNAL' creates a default transaction, which attempts
; to lock all areas for update. If this request is at odds with an
; already granted request, the program will sleep until the request
; can be granted.
;
;CURE
; Since there is no reason why locks should be put on all
; areas, don't do it.
;
;
********************************************************************************
EDIT 420 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 420 *************************
;
;SYMPTOM
; DBMEND gets "INVALID BLOCK DESCRIPTOR" after a MERGE BEFORE
; command. Also, a PA1050 error will occasionally result from an
; ABSTRACT command.
;
;DIAGNOSIS
; When writing a before image (JR.BEF), DBCS will garbage the journal if
; the journal buffers are flushed because they are full, AND there is
; a remnant of the last image in the 'first' page (i.e., the image
; spanned more than one journal page), AND the transaction is terminated
; by a JBTRAN before anything else is placed in the journal buffers.
; Also, if the before image spanned more than two journal pages, the
; page anchor in all pages after the first page will be incorrect.
;
;CURE
; Ensure that JRCOPY flags the journal buffers as modified, and don't
; let JREFILL destroy JR.BIX after flushing the journal buffers. Also
; change the page anchor algorithm to handle an image span of more
; than two journal pages, so that on each journal page after the first,
; the page anchor will be a negative offset to the beginning of the
; data block (i.e., previous anchor - 1000).
;
;NOTE:
; THIS EDIT REPLACES EDIT 367 TO DBMS-20 V.6.
;
********************************************************************************
EDIT 421 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 421 *************************
;
;SYMPTOM
; ERROR-STATUS typeout yields bad status after ?DBSXWX message.
;
;DIAGNOSIS
; The binary value in ERROR-STATUS is correct, but it has not yet been
; translated into ASCII. Since the declared usage of ERROR-STATUS is
; DISPLAY-7, LIBOL attempts to interpret the binary value as ASCII
; bytes, thus the garbage being typed out.
;
;CURE
; Add a small routine in DBLEAV to translate the number to ASCII,
; and make it unique to the DBSXWX situation.
;
;NOTE:
; THIS EDIT REMOVES EDIT 416 TO DBMS V.6.
;
********************************************************************************
EDIT 422 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 422 *************************
;
;SYMPTOM
; Programs sleeps in 'OPEN JOURNAL' statement while a concurrent
; run-unit has a transaction opened.
;
;DIAGNOSIS
; The 'OPEN JOURNAL' creates a default transaction, which attempts
; to lock all areas for update. If this request is at odds with an
; already granted request, the program will sleep until the request
; can be granted.
;
;CURE
; Since there is no reason why locks should be put on all
; areas, don't do it.
;
; NOTE:
; THIS EDIT REPLACES EDIT 417 TO DBMS V.6.
;
********************************************************************************
EDIT 423 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 423A *************************
;
;SYMPTOM
; DBINFO gets "?CORISA - ILLEGAL SIZE ARGUMENT PASSED" during
; execution of the /SS command, when processing a large schema file.
;
;DIAGNOSIS
; When enough areas are included in the schema, DBINFO moves the
; first page of the .SCH file out of its buffers during the area
; walk. When it starts the transaction walk, it takes a count of
; transactions (NTRAN) from what should be the first page. This
; erroneous count is then used to allocate space in the in-core
; subschema block, and the illegal size argument is detected.
;
;CURE
; Get the first page of the .SCH file back into the buffers before
; the transaction walk (and also before the record walk) by calling
; routine FINDR%.
;
********************************************************************************
EDIT 424 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 424 *************************
;
;SYMPTOM
; After successful FIND or STORE, SYSCOM registers AREA-NAME and
; RECORD-NAME are not updated as stated in the DML Reference Manual,
; page 3-5.
;
;DIAGNOSIS
; There is no code in DBLEAV to modify these registers upon exiting
; from a FIND or STORE.
;
;CURE
; Add code to DBLEAV to update these registers, when exiting
; from a successful FIND or STORE.
;
********************************************************************************
EDIT 425 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 425 *************************
;
;SYMPTOM
; When an area is open for RETRIEVAL, DBMS returns
; error status 360, and error data contains 0/19005.
;
;DIAGNOSIS
; DBMS has attempted to read a page in a non-existent section
; in file opened read-only. The monitor returns error LNGFX1
; but there is no code to trap this error properly, nor to
; store the JSYS error code.
;
;CURE
; Change code in DBMIO to retrieve the PMAP error and to
; ignore error LNGFX1. This will cause a 0326 exception
; (nonexistent page), rather than the 0360 (operating system
; error). Handle other errors properly.
;
********************************************************************************
EDIT 426 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 426 *************************
;
;SYMPTOM
; When a lock conflict occurs on OPEN AREA, the JSYS error code
; reported in ERROR-DATA is 777777, and not a valid JSYS error code.
;
;DIAGNOSIS
; The ENQ.IT macro is not assembling code to save the error return
; in the left half of R0.
;
;CURE
; Rebuild the code assembled for ENQ.IT to save the JSYS error return.
;
********************************************************************************
EDIT 427 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 427 *************************
;
;SYMPTOM
; When a COBOL subprogram executes 'ENTER MACRO SETDB USING "ss-name"',
; a memory protection violation occurs.
;
;DIAGNOSIS
; The SETDB$ routine is improperly checking the argument number,
; and as a result attempts to obtain the second argument (lock-name)
; even when it has not been provided.
;
;CURE
; Fix the code in SETDB$ to properly check the argument count.
;
********************************************************************************
EDIT 430 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 430 *************************
;
;SYMPTOM
; Transactions in the journal file that were deleted by DBMEND
; cannot be distinguished from transactions that were actually
; added to the database.
;
;DIAGNOSIS
; DBMS V.6 does not flag the header block of deleted transactions.
; There is no way, as from an application program, to place text
; in the journal via JRTEXT to note a deleted transaction.
;
;CURE
; Install code in DBMEND that will add the text "DELETED COMMAND"
; "DELETED TRANSACTION" to the journal when such an action
; is taken by DBMEND.
;
********************************************************************************
EDIT 431 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 431 *************************
;
;SYMPTOM
; FORDML does not allow CLOSE TRANSACTION or DELETE TRANSACTION without
; a transaction name, which should be optional.
;
;DIAGNOSIS
; Module DMLVER, which drives the DBMS statement translation, has no
; provision for accepting these two statements without the optional
; transaction name.
;
;CURE
; Modify the handling of these two statements to make the transaction
; name an optional token.
;
********************************************************************************
EDIT 432 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 432A *************************
;
;SYMPTOM
; DBMEND occasionally reports 1663 exception during DELETE
; TRANSACTION, or 1463 during ABSTRACT.
;
;DIAGNOSIS
; If the journal has just been rolled over (reached the maximum
; transaction count) or was marked for overwrite (last run-unit
; executed CLOSE JOURNAL), it will legally have no data for an
; ABSTRACT or DELETE TRANSACTION, but DBMEND doesn't account
; for that possibility.
;
;CURE
; Allow DBMEND to sense that the journal has no data, and apprise
; the user of that situation (not an error message).
;
********************************************************************************
EDIT 435 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 435 *************************
;
;SYMPTOM
; Programs sleeps in OPEN JOURNAL statement while a concurrent
; run-unit has a transaction opened.
;
;DIAGNOSIS
; The OPEN JOURNAL creates a default transaction, which attempts
; to lock all areas for update. If this request is at odds with an
; already granted request, the program will sleep until the request
; can be granted.
;
;CURE
; Since there is no reason why locks should be put on all
; areas during OPEN JOURNAL, don't do it.
;
; NOTE:
; THIS EDIT REPLACES EDIT 422 TO DBMS V.6.
;
********************************************************************************
EDIT 436 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 436 *************************
;
;[SYMPTOM]
; A call to JRDATA can produce a ?Memory Protection Violation. This
; problem is exhibited by the UETP test program ORDENT.CBL.
;
;[DIAGNOSIS]
; The first thing JRDATA does is start a default transaction if no
; transaction is active. Execution of the DEFTRAN routine causes the
; argument pointer (AC 16) to be changed, and when JRDATA later tries to
; retrieve the size argument, the fatal error can occur.
;
;[CURE]
; Save the argument pointer around the call to DEFTRN.
;
;
********************************************************************************
EDIT 437 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 437 *************************
;
;SYMPTOM
; FIND rse6 using proper sort key does not do an indexed find,
; but walks sequentially through the set.
;
;DIAGNOSIS
; The set is sorted with no global DUPLICATES clause, so the record
; TID becomes the major sort key. However, the TID is not passed as
; part of the sort key argument list from the calling program, so
; DBCS detects a difference from what the sort key should look like,
; and therefore does not allow the indexed FIND.
;
;CURE
; Detect that situation where the TID is built into the sort key,
; and allow DBCS to check only the key elements provided, skipping
; over the TID. DBCS will still use the proper TID when searching
; the index.
;
********************************************************************************
EDIT 441 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 441 *************************
;
;SYMPTOM
; MODIFY fails when a sort key is being modified, and the record
; is declared an optional member of the sorted set in question and
; at the time of the MODIFY is not actually a member.
; ERROR-STATUS = 822, ERROR-DATA = 28009.
;
;DIAGNOSIS
; The member-unlink code in DBSET detects an error if the pointer
; being cleared (unlinked) is already cleared, for all verbs except
; DELETE. However, the MODIFY code in DBMOD expects to get a cleared
; pointer returned as an indication the the record is not a current
; member of the sorted set.
;
;CURE
; Allow the unlink code to accept cleared pointers during the MODIFY
; verb in the same manner as during a DELETE, if treating an optional
; member of a sorted set.
;
;NOTE
; THIS EIDT REMOVES EDIT 415 TO DBMS-20 V.6.
;
********************************************************************************
EDIT 442 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 442 *************************
;
; [SYMPTOM]
;
; Using FIND PRIOR/LAST with a set that has no prior
; pointers can produce undeserved NRS or ESA exceptions, and
; possibly bad currency values.
;
; [DIAGNOSIS]
;
; The FIND3 processor makes some invalid assumptions
; concerning information returned from the lower level record
; find routines.
;
; 1. When the find primitves determine that prior simulation
; is necessary, the first check made is for a valid
; current-prior-of-set which might have a next pointer to
; the current-of-set (current-prior-of-set is basicly
; maintained while nexting through a set). However the
; record type is not considered, and this check may return
; successfully with the wrong type. In version 6, code at
; the verb level (incorrectly) makes this check, which can
; result in an exception even though a prior record does
; exist in the set which will match.
;
; 2. If the initial check fails, the prior simulation code
; walks the entire set from the owner to either the owner
; (FIND LAST) or current of set (FIND PRIOR) looking for a
; record type match. At termination the code returns the
; DBKEY of either the matched record or the owner, however
; the current record type is that of the last record read.
; This is not expected by the verb routines, nor the
; currency update routines, and can cause various types of
; havoc. Since the verb level code in version 6 checks the
; current record type for a match, an undeserved exception
; is a frequent occurance for multi member sets.
;
; [CURE]
;
; Make the find primitives return with the current record
; matching the DBKEY. This will return a member for a record
; match, or the owner for a failure or when the owner is
; normally encountered. Also make the current-of-prior
; routines check for a record type match, and walk the entire
; set for a non match. Eliminate the checks at the verb level
; for owner-of-current-set-occurance and matching record type,
; and only check for having been returned an owner record.
;
********************************************************************************
EDIT 443 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 443 *************************
;
;SYMPTOM
; When the FFUFP calls in DBMIO detect an error other than FFUFX3,
; error trap code does not capture the proper error value.
;
;DIAGNOSIS
; To test for FFUFX3, that value is subtracted from R1. If the error
; wasn't FFUFX3, the error is trapped with R1 supposedly holding
; the actual error value.
;
;CURE
; Fix the error value in R1, by adding FFUFX3 back in, before trapping
; the error.
;
********************************************************************************
EDIT 444 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 444 *************************
;
; [SYMPTOM]
;
; DELETE TRANSACTION or a call to JBTRAN produces a
; 1402/1602 exception, and a MERGE BEFORE using the same
; journal produces a 1602 exception part way through backing
; out a transaction. Also data base corruption with no error
; indication after either of these operations, with the
; corrupted data base pages appearing with the bottom most
; part of the page shifted up one or two words towards the top
; of the page.
;
; [DIAGNOSIS]
;
; When a transaction includes a before image block that
; spans multiple journal pages, there is the possibility that
; the block may end on a page such that there is insufficient
; room on that page to place another logical block header. In
; this case, the journal routines mark one or two words of
; free space in the journal page anchor, and continue adding
; blocks beginning with the next page (similar to the way in
; which a transaction trailer appears). The previous size and
; code for the subsequent block show the actual size of the
; block minus the free space, which is the correct
; information.
;
; In backing out a transaction, the complete transaction
; is scanned backwards in order to pick out the before images
; and restore them in reverse order. The routines that do so
; construct an entire before image from possibly multiple
; journal pages using a sequence of BLTs. In the situation
; where a journal page contains nothing but the information
; for a single logical block, the code assumes that the entire
; page will need to be BLTed, and forgets to account for the
; possible free space. The BLT will shift the data up one or
; two words, and cause the BLT for the top of the transaction
; to be 'short' by that number of words. Depending on how
; much of the transaction block is left to be shortchanged,
; the shifted data may move into the position of the data base
; page number for the before image (you generally get the
; highest used,,free word, the first calc chain header, or
; first dbkey) which might be out of range causing the
; 1402/1602. This does not always occur, and you get either a
; bad page number and/or corrupted data.
;
; [CURE]
;
; Account for the possible free space in the full page
; BLT setup code.
;
********************************************************************************
EDIT 446 FOR DBMS
[SYMPTOM]
MOVE CURRENCY STATUS can return currency values
(DBKEYs) for areas that are not currently open. This
happens most commonly for current of run-unit, and sets
owned by the SYSTEM record. This behavior conflicts with
the CODASYL specification, which states that when an area is
closed, all currency values pretaining to that area are set
to null.
[DIAGNOSIS]
The SYSTEM record is setup as the current of set for
all sets for which it is owner. This allows usage of
singular sets without having to first explicitly locate the
owner (SYSTEM) record. This setup is accomplished when the
sub-schema BINDs are executed, which effectively produces
currency even before it is possible for any to exist. This
currency is carefully reset and preserved by the area close
code, which otherwise attempts to zero the pertinent
currency values for the area being closed. This SYSTEM
currency is also explicitly set as the initial default when
multiple transactions are being backed out by a single
JBTRAN call.
In addition, the close code mishandles DBKEYs for deleted
records such that they are retained as currency values, sets
up SYSTEM as the current of area in which it exists (if
any), and it forgets to zero the current of run-unit value
when needed.
[CURE]
Eliminate the currency setup for SYSTEM owned singular
sets in the BIND code, and instead do it only when the area
containing the SYSTEM record is opened. Alter the code
which does this setup to make sure that the proper area is
open, and to make sure it does not overwrite existing
currency values that may have been set via area FINDs.
Eliminate all the checks in the area close code which
preserve the SYSTEM record currency, except the one which
preerves it in the SYSTEM record itself.
This will have the effect of substituting xx06/15004 (CNU)
exceptions for xx01/15004 (ANO) exceptions if an attempt is
made to reference a SYSTEM owned set before the area
containing the SYSTEM record is opened.
********************************************************************************
EDIT 447 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 447 *************************
;
; [SYMPTOM]
;
; When a DBS file which may have multiple file sections
; (long file) has been opened for retrieval, DBCS can return
; error xx60, error data 19005. With edit 425 installed, this
; exception will not occur, but exception 0356 can. There are
; also related instances of exception 0157 when closing the
; data base.
;
; [DIAGNOSIS]
;
; If an attempt is made to map in a page from a
; non-existant file section (or sections) while the DBS file
; is opened read-only, the PMAP will fail with error LNGFX1.
; This can occur when specifying a direct or calc key for a
; non-existant page or record, or more commonly when
; clustering (via transactions) such that a cluster starts in
; an existing file section and ends in a non-existing one.
;
; Prior to edit 425, the PMAP failure just produced the xx60
; (OS) exception. Edit 425 attempted to compensate for this
; case by merely removing all the pages that were mapped and
; returning normally, leaving the xx26 (NRS) exceptions to be
; produced by the I/O kernal. This was insufficient for the
; cluster/multi section case, in that it removed valid data
; eventually causing the xx56 (DAT) bad pointer exception.
;
; In a related situation, if the first page of a cluster is
; non-existant, the page is eliminated from the process map,
; and an immediate NRS or UMR exception is generated. However
; this leaves the remaining pages of the cluster mapped with
; no indication in the buffer blocks that they exist. The
; close code will not know that they need to be unmaped, and
; the eventual CLOSF% will fail producing the 0157 (SOF)
; exception.
;
; [CURE]
;
; Supersede edit 425. Add a new routine to deal with the
; LNGFX1 error such that the program will continue normally if
; the first page of the map request is not in a non-existant
; section. In all other cases, generate an immediate NRS or
; UMR exception as appropriate.
;
; Also, if the first page of a cluster is truely non-existant,
; make sure that all pages for that cluster are unmaped before
; generating the NRS/UMR exception.
;
; This edit adds the following new exceptions to DBCS:
;
; SOF/19032 An abortive PMAP failed when erasing cluster pages
; OS/19033 PMAP JSYS read error in .DBS file
; NRS/19034 FIND rse1/rse5 for a record on a non-existant page
; UMR/19035 Non FIND res1/rse5 retrieval from non-existant page
; SOF/19036 An abortive PMAP failed when erasing cluster pages
;
********************************************************************************
EDIT 450 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 450 *************************
;
;SYMPTOM
; If a user gives the following command sequence to DBINFO:
; /OPEN AREA1
; /DISPLAY USAGE
; /CLOSE AREA1
; /OPEN AREA2
; /DISPLAY USAGE
; DBINFO replies that AREA2 is not opened, although the OPEN
; command for AREA2 had no errors.
;
;DIAGNOSIS
; DBINFO is properly opening and closing the areas, but is not properly
; updating a list of available pages based on the open areas. This list
; is generated only once, during the first DISPLAY command, and is not
; checked on subsequent commands to make sure it is current.
;
;CURE
; Force the list to be generated each time it is used, to take into
; account subsequent OPEN and CLOSE commands.
;
********************************************************************************
EDIT 451 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 451 *************************
;
; [SYMPTOM]
;
; Exception xx02 (KIA) from DBMS version 6 when
; attempting to split an index block of a multi area sorted
; set created by version 5A. Exception xx02 can also occur
; when creating a new buoy record for a set with members that
; reside in multiple areas.
;
; [DIAGNOSIS]
;
; DBMS version 5A defaulted to storing the index blocks
; in the same area as the first member of the sorted set.
; Version 6 defaults to storing the index blocks with the
; owner record. If the owner exists in a different area than
; the first member, version 6 returns the KIA (key
; inconsistent with area) exception on an index block split
; when it uses the page number of the last index block (member
; area page range) in conjunction with the target page range
; of the owner area.
;
; The second type of KIA exception is likewise caused
; when the page number of the last member in the old buoy
; chain is used with a different area page range for the new
; record (the one causing the buoy chain split). The code
; purposely attempts to keep the buoy and the new record close
; together to promote compact record distribution and faster
; access.
;
; [CURE]
;
; The solution to both problems is to determine if the
; selected page number is outside the targetted page range,
; and if so, select the best possible page number from the
; desired range.
;
; The best solution for the index block problem is either
; to reload the data base to use the version 6 default, or
; change the schema to assign the index blocks to live with
; the first member record (the ASSIGN INDEX phrase)
; essentially simulating the version 5A behavior. While this
; edit does complete the changes required to allow cross area
; index blocks, using this feature is not recommended as it
; adversely affects performance.
;
; This edit also eliminates the KIA exceptions produced
; when a buoy chain split occurs in cross area fashion as
; described. Again, the usage of multiple areas for the
; members of sorted sets is not recommened, since buoys
; obtained from one area will inevitably point to records in
; another area, causing excessive I/O and degrading
; performance.
;
********************************************************************************
EDIT 452 FOR DBMS
;******************** START OF DBMS20-V6 EDIT 452 *************************
;
;SYMPTOM
; The DDL transaction syntax
; TRANSACTION IS tran-name
; USAGE-MODE IS RETRIEVAL
; USAGE-MODE IS UPDATE FOR area-1.
; should mark all areas except area-1 for retrieval, and area-1 for
; update. However, an update to area-1 yields exception 1209.
;
;DIAGNOSIS
; SCHEMA is not stepping throught the E.K set properly to modify the
; correct TRANSACTION-AREA line. Thus, the in-core description at
; runtime may specify update mode for the wrong area, or there may
; be two TRANSACTION-AREA lines for the same area, the first of which
; is used.
;
;CURE
; Find the beginning of the E.K set when parsing each USAGE-MODE
; statement, and make sure to use the correct area name id when
; updating a TRANSACTION-AREA line.
;
********************************************************************************
EDIT 456 FOR DBMS
[SYMPTOM]
Incomplete transaction in the journal file are not always
backed out successfully by the DBMEND DELETE TRANSACTION command.
[DIAGNOSIS]
DBMEND sometimes lets another run-unit append to the journal
while a DELETE TRANSACTION is in progress. As a result, the
incomplete transaction is buried in the journal and not removed from
the database, and DBMEND may instead back out the transaction
completed by the run-unit that was allowed access to the journal.
[CURE]
Insure the DBMEND holds onto its locks for the entire DELETE
TRANSACTION process. In addition, have DBMEND update the Area-Status
record in each area to account for a dead run-unit, to prevent
intermittent AUS exceptions after a DELETE TRANSACTION.
********************************************************************************
EDIT 457 FOR DBMS
[SYMPTOM]
Numerous problems involving locating records in sorted
sets:
1. FIND6 (and FINS6) can return a record of the wrong type.
This problem also occurs when set occurrence selection is
thru location mode of owner, for via/sorted sets.
2. Range keys do not work as documented. The
range/error-data flag is never set to 0 on an exact
match. A range find on a descending key can fail when
not necessary. Sets in which the TID is the major key
can return the wrong record. And exception NRS is
returned for a range key failure, not ESA as documented.
3. There is the possibility of unnecessary I/O in certain
cases.
[DIAGNOSIS]
For the problems as listed above:
1. No code exists to check for the proper record type.
2. The setup for the search algorithm, and some of the
failure paths, plus the range flag logic are inadequate
or incorrect. And no attempt is made to differentiate
the range key/non range key cases in order to return the
proper exception.
3. Not enough checking is done prior to trying the extra
buoy reads.
[CURE]
Again, as listed above:
1. Compare the record type desired with the record type last
compared/found. The appropriate record types must be
passed to the search/find routines from the callers
(FIND6, FINS6, and STORE) and the key comparison
routines.
2. Generally rewrite the sorted set search routines to
handle range keys and the range flag properly. Pass the
correct range flag back from the key comparison routines,
and correctly store it in ERROR-DATA for range key
searchs. Properly determine when a range key search is
in effect, allowing the search code to always return a
record when the key value(s) is(are) in the proper range.
And add tests to cause an ESA exception to be generated
when the search key value(s) are greater than all record
key value(s) for the specified record type. This last
change corresponds to existing documentation and the
CODASYL specification.
3. Addressed by 2.
Note that the change in the FIND6 range key exception type
from NRS to ESA may be highly significant to existing
applications. Also note that the only change to FINS6 (the
obsolete sorted find entry point) is that it now only
returns a record of the specified type. FINS6 does not
return range flag data in ERROR-DATA, and only returns
exception NRS if the find fails.
Pertinent to this edit, we note the following documentation
changes and clarifications:
1. There are basiclly only two possible outcomes of a
successful range key search; an exact match and a non
exact match. DBMS version 6 offers a variation on the
second case called a partial or generic key match. In
order to select a generic match, the user must provide a
search key (or series of keys) that contain only the data
to be considered for the partial match. All key
positions past those to be considered for matching must
be set to <null>s (<null>= value 0).
In order to set the key data up as required, the user
must know the order of the record keys as expressed in
the schema, wherein the first key listed is the major
(most significant) key, and the last key listed is the
most minor (least significant) key. If one visualizes
all the sort keys concatenated together in their order of
significance, then the data to be considered for the
search must appear in the most significant key positions
(leftmost), and the remainder of the key positions must
be <null>s. While it is possible to end the desired
search data in the middle of a key, the most common usage
is for multi key records, where some of the least
significant keys are set to <null>s, allowing record
selection via some significant subset of the total number
of keys.
The indexed search routines compare each position within
each key, from most significant to least, until either
all keys are exhausted (a match) or a non match occurs.
If the comparison fails, and it fails on a <null> in the
search key, the range flag in ERROR-DATA will be set to a
1, otherwise it will be set to a 2. (DBMS version 6
presently only checks for the first occurrence of a
<null>, however future implementations may require that
all key positions after the first <null> also contain
<null>s).
For example, assume the following sorted set member
description:
ASCENDING RANGE KEY IS STATE,AREA-CODE,PHONE.
and the data:
Record-Id City State Area-code Phone
Rec1 Chicago IL 312 666-4567
Rec2 NY City NY 212 885-9923
Rec3 Utica NY 315 223-4456
Rec4 Utica NY 315 223-5567
Rec5 Utica NY 315 447-9876
Rec6 Albany NY 518 775-9982
Rec7 Austin TE 512 998-1235
To generically search for state NY; key values are
State='NY', Area-code=<null>s, Phone=<null>s. The record
returned is the one with Record-Id = Rec2.
To generically search for state NY, area-code 315; keys
are State='NY', Area-code='315', Phone=<null>s. The
record returned has Record-Id = Rec3.
A generic search for state NY, area-code 315, phone
exchange 223; requires keys State='NY', Area-code='315',
and Phone='223<null><null><null><null><null>'. This will
return Rec3 also.
A search for state='NM', Area-code=<null>s, Phone=<null>s
will return Rec7 and will set the ERROR-DATA value to 2.
2. If a set's order is defined as ORDER IS SORTED,
DUPLICATES...., and it is a multi member set, the sort
keys for each member must agree in size, data type, AND
whether or not they are ascending or descending.
3. If any member key is a range key, the search is
considered to be a range search. This includes sets
defined as ORDER SORTED (no duplicates clause) and ORDER
SORTED WITHIN RECORD-NAME where the major key is record
type (TID).
4. When specifying DUPLICATES ARE ALLOWED at either the set
or member level, the default is DUPLICATES ARE LAST.
5. Exception NRS/28021 has been deleted, and the following
exception added:
ESA/9021 No match on range key for FIND6 using index
********************************************************************************
END OF DBMS-20-V6