Trailing-Edge
-
PDP-10 Archives
-
BB-4148D-BM_1980
-
dbms-v5a/source/dbms5.rnd
There are 2 other files named dbms5.rnd in the archive. Click here to see a list.
.LM 0;.RM70;.F;.J;.SP1;.TS5
.FLAG CAP
\\
^^DBMS.DOC\\ -- ^CHANGES FROM ^^V3\\ TO ^^V5\\
.BR
^JUNE 1977
.FG30
^COPYRIGHT (^C) 1976,1977
.BR
^DIGITAL ^EQUIPMENT ^CORPORATION, ^MAYNARD, ^MASS.
.B2
^THIS SOFTWARE IS FURNISHED UNDER A LICENSE FOR USE ONLY ON A SINGLE
COMPUTER SYSTEM AND MAY BE COPIED ONLY WITH THE INCLUSION OF THE ABOVE
COPYRIGHT NOTICE. ^THIS SOFTWARE, OR ANY OTHER COPIES THEREOF, MAY NOT
BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY OTHER PERSON EXCEPT FOR
USE ON SUCH SYSTEM AND TO ONE WHO AGREES TO THESE LICENSE TERMS.
^TITLE TO AND OWNERSHIP OF THE SOFTWARE SHALL AT ALL TIMES REMAIN IN
^^DEC\\.
.B1
^THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY ^DIGITAL ^EQUIPMENT
^CORPORATION.
.B1
^^DEC\\ ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY ^^DEC\\.
.T ^^DBMS5.DOC\\
.PG
<DBMS.DOC -- ^CHANGES FROM ^V3 TO ^V5
.BR
^JUNE 1977
.B3.LM0
1.0##^^SUMMARY\\
.B1
^^DBMS-V5(240)\\ REPLACES ^^DBMS-V3\\ AND ^^DBMS-V4\\.
.B1
^^DBMS-V5\\ CAN CO-EXIST WITH, AND HAS BEEN TESTED WITH, VERSION 6.02 (AND 6.03) OF ^^TOPS-10\\, VERSION 1^B (AND 2) OF ^^TOPS-20\\,
VERSION 11 OF ^^COBOL/LIBOL\\, AND VERSION 5 OF ^^FOROTS\\.
.B1
^BECAUSE BOTH ^V3 AND ^V4 USERS WILL BE READING THIS DOCUMENT,
THE CHANGES FROM ^V3 TOWARDS ^V5 HAVE BEEN PARTITIONED INTO SECTION
2.1 AND SECTION 2.2 (^V4 CHANGES) AND INTO SECTION 2.3 (^V5 CHANGES) AS MUCH AS IS FEASIBLE.
^V5 IS A COMPATIBLE UPGRADE OF ^V4; HOWEVER EXISTING
^^DBMS-V3\\ APPLICATIONS MUST RELOAD THEIR DATA BASES IN ORDER TO USE ^^DBMS-V5\\.
^THIS CONVERSION PROCEDURE, AND THE OTHER INSTALLATION INSTRUCTIONS, ARE DISCUSSED IN SECTION 4.0.
.B1
^THE PRIMARY ENHANCEMENTS TO ^^DBMS-V5\\ ARE THE FOLLOWING:
.B1.LM9.I-4
1.##^SUPPORT OF SORTED SETS VIA INDEXED SEQUENTIAL ACCESS
.B1.I-4
2.##^GREATLY IMPROVED PERFORMANCE IN ^^SCHEMA\\ AND ^^DBCS\\
.B1.I-4
3.##^THE ^^OWNER IS SYSTEM\\ CLAUSE
.B1.I-4
4.##^^DBINFO\\ AS A REPLACEMENT FOR ^^DBSDMP\\ AND ^^DBUTIL\\
.B1.I-4
5.##^USE OF ^^ENQ/DEQ\\ TO CONTROL ACCESS TO AREAS
.B1.I-4
6.##^MUCH MORE COMPREHENSIVE ^^DMCL\\
.B1.I-4
7.##^THE ^^OCCURS\\ PHRASE AND ADDITIONAL DATA TYPES
.B1.I-6
^V5 ^^ONLY\\:
.B1.I-4
8.##^SIMULTANEOUS UPDATE OF DATA BASES
.B1.I-4
9.##^VARIOUS JOURNALING ENHANCEMENTS
.B1.LM0
^THESE AND THE OTHER ENHANCEMENTS ARE DISCUSSED IN SECTION 2. ^WHERE RELEVANT,
INCOMPATIBILITIES ARE PRESENTED IN ORDER OF DECREASING IMPORTANCE. ^HOWEVER THE
INCOMPATIBILITIES PRESENTED IN SECTION 5.0 ARE ALL "BENIGN" IN THE
SENSE THAT THEY ARE TRANSPARENT TO APPLICATIONS THAT USE THE SUPPORTED
FUNCTIONALITY OF ^^DBMS-V5\\ AS DEFINED IN THE DOCUMENTATION. ^THEY ARE
PRESENTED ONLY IN THE INTEREST OF THOROUGHNESS.
.PG.B3.LM0
2.0##^^EXTERNAL CHANGES\\
.B1
^^SUMMARY\\ - ^^FUNCTIONAL DEFINITION\\ OF ^^DBMS-V4\\
.B1
^THE PRIMARY ENHANCEMENTS TO ^^DBMS-10/20\\ ARE THE FOLLOWING:
.B1.LM9.I-4
1.##^SUPPORT OF SORTED SETS VIA INDEXED SEQUENTIAL ACCESS
.B1.I-4
2.##^GREATLY IMPROVED PERFORMANCE IN ^^SCHEMA\\ AND ^^DBCS\\
.B1.I-4
3.##^THE ^^OWNER IS SYSTEM\\ CLAUSE
.B1.I-4
4.##^^DBINFO\\ AS A REPLACEMENT FOR ^^DBSDMP\\ AND ^^DBUTIL\\
.B1.I-4
5.##^USE OF ^^ENQ/DEQ\\ TO CONTROL ACCESS TO AREAS
.B1.I-4
6.##^MUCH MORE COMPREHENSIVE ^^DMCL\\
.B1.I-4
7.##^THE ^^OCCURS\\ PHRASE AND ADDITIONAL DATA TYPES
.B1.LM0
^THESE AND THE OTHER ENHANCEMENTS ARE DISCUSSED IN SECTION 2.1.
.B2.LM0
2.1##^FUNCTIONAL ^ENHANCEMENTS AND ^DIFFERENCES
.B2
2.1.1##^THE ^^DMCL\\
.B1
^THE GENERAL FORM OF THE ^^DMCL\\ IS:
AT MOST ONE ^^RECORDS-PER-PAGE\\, ^^JOURNAL\\, ^^IMAGES\\, ^^INTERCEPT\\, AND ^^NOTE\\ STATEMENT, IN ANY ORDER...
FOLLOWED BY ONE OR MORE ^^ASSIGN\\ STATEMENTS.
.B1
^INCIDENTAL CHANGE: ^^RPP\\ IS NOW A LEGAL ABBREVIATION FOR ^^RECORDS-PER-PAGE\\.
.B2
2.1.1.1 ^FILE ^SPECIFICATION
.B1
^^TOPS-10\\
.B1
^A FILE SPEC WHICH APPEARS IN THE ^^DMCL\\ MUST COMFORM TO THE FOLLOWING RULES. ^BLANKS, COMMAS, AND SEMI-COLONS ARE IGNORED AS ELSEWHERE. ^THE ALLOWED COMPONENTS MAY APPEAR IN ANY ORDER AND ARE A DEVICE-NAME,
A FILE-NAME, AND A PROJECT-PROGRAMMER NUMBER. ^THE FORM OF A DEVICE-NAME
IS AN ALPHANUMERIC FOLLOWED BY COLON (:); THE FORM OF A FILE-NAME IS SIMPLY AN ALPHANUMERIC; AND THE FORM
OF A ^^PPN\\ IS [_<OCTAL NUMBER> _<OCTAL NUMBER>].
^THE DEFAULT DEVICE IS ^^DSK:\\. ^THE DEFAULT ^^PPN\\ IS THE CURRENT PATH. ^THE FILE-NAME COMPONENT HAS NO DEFAULT VALUE , BEING ALWAYS REQUIRED.
.B1
^FOR EXAMPLE, ^^DSK:FILE\\[1,1].
.PG.B1
^^TOPS-20\\
.B1
^ALL COMPONENTS EXCEPT THE FILE-NAME ARE OPTIONAL. ^THE COMPONENTS
WHICH ARE PRESENT MUST CONFORM TO THE FOLLOWING ORDER AND FORMATTING:
"DEVICE: _<DIRECTORY> FILENAME ^AACCOUNT ^PPROTECTION". ^THE ENTIRE SPEC
MUST NOT EXCEED 100 CHARACTERS.
^THE DEFAULT DEVICE IS ^^DSK:\\. ^THE DEFAULT DIRECTORY IS THE
CONNECTED DIRECTORY.
.B1
^FOR EXAMPLE, _<ALLMYDBS>FILE.
.B2
2.1.1.2 ^^JOURNAL\\ ^STATEMENT#-#
^WHEN PRESENT, THIS STATEMENT SPECIFIES THE FILE SPEC THAT
THIS SCHEMA'S JOURNAL FILE WILL HAVE. ^IF IT IS ABSENT, ^^SCHEMA\\ SIMULATES A ^^JOURNAL\\ STATEMENT IN WHICH THE DEVICE IS ^^JRN\\ AND
THE FILE NAME IS THE SCHEMA-NAME. ^THE SYNTAX OF THE STATEMENT IS:
.C
^^JOURNAL\\ [^I^S] FILE-SPEC.
.B2
2.1.1.3 ^^IMAGES\\ ^STATEMENT#-#
^THIS STATEMENT SERVES TO DELINEATE THE GRANULARITY OF JOURNALING THAT WILL
OCCUR IN AN APPLICATION.
^THE SYNTAX OF THIS STATEMENT IS:
.C
^^IMAGES [NOT] [IN ORDER] BY COMMAND.\\
.B1
^THE DEFAULT IS FOR IMAGES TO BE ORDERED BY COMMAND.
^WHEN IMAGES ARE ORDERED BY COMMAND, THE BUFFERS OF EACH OPEN AREA ARE IN EFFECT CHECKPOINTED AFTER EXECUTION OF EACH ^^DML\\ UPDATING-VERB.
^THIS MEANS THAT "MORE" WRITING IS DONE TO THE DATA BASE AND TO THE JOURNAL--BUT CONVERSELY THAT THE DATA BASE CAN BE BACKED UP
IN INCREMENTS OF SINGLE UPDATING-VERBS...IN ^^DBMEND\\ AND AT RUN-TIME.
.B1
^WHEN ONE REQUESTS IMAGES TO NOT BE ORDERED BY COMMAND,
CHECKPOINTING OCCURS ONLY AFTER EACH USER-SPECIFIED TRANSACTION
(IE. DURING A CALL TO ^^JETRAN\\). ^THUS "LESS" WRITING IS DONE
TO THE DATA BASE AND TO THE JOURNAL--BUT CONVERSELY THE DATA BASE CAN BE BACKED UP ONLY IN INCREMENTS OF USER TRANSACTIONS...IN ^^DBMEND\\ AND
AS IMPORTANTLY AT RUN-TIME.
^THE MECHANISM OF PER-TRANSACTION DATABASE BACKUP, THE ^^JBTRAN\\ CALL, IS PRESENTED IN SUBSECTION 2.1.6.4.
.B1
(^THE ^^CODASYL DBMS\\ SPECIFICATION STATES THAT, WHEN AN EXCEPTION OCCURS DURING
EXECUTION OF A ^^DML\\ UPDATING-VERB, THE ^^DBCS\\ MUST RETURN THE DATA BASE TO THE STATE IT WAS IN AT THE BEGINNING OF THE VERB. ^HOWEVER THIS
IS SOMEWHAT EXPENSIVE AS IMPLIED ABOVE. ^CONSEQUENTLY, WHAT WE ARE DOING IS ALLOWING
THE PROGRAMMER TO DECIDE. ^BY SPECIFYING
THAT IMAGES ARE NOT ORDERED BY COMMAND, THE PROGRAMMER WILL BE SAYING, "^IT BENEFITS ME TO DECREASE THE COST OF JOURNALING EVEN THOUGH THAT
REDUCES THE CONTROL WITH WHICH ^I CAN BACKUP MY DATA BASE AND EVEN THOUGH
THAT REDUCES EXCEPTION TRANSPARENCY WITH RESPECT TO THE VALIDITY OF
A DATA BASE".)
.B1
^THERE ARE CERTAIN APPLICATIONS WHICH HAVE TO BACKUP COMPLETELY IF THE APPLICATION ABORTS FOR ANY REASON.
^SUCH AN APPLICATION SHOULD SPECIFY THAT IMAGES ARE NOT ORDERED BY COMMAND SINCE, EVEN IF THERE ARE NO USER TRANSACTIONS OR COMMAND-ORDERING,
^^DBMEND\\ ALWAYS ALLOWS TOTAL BACKUP VIA: "^^START\\_<<CRLF>... ^^END\\_<<CRLF>... ^^MERGE BEFORE\\".
.B2
2.1.1.4 ^^INTERCEPT/NOTE\\ ^STATEMENT#-#
^THESE RELATED STATEMENTS ALLOW A USER TO TELL ^^DBCS\\ THE CLASSES OF
EXCEPTIONS FOR WHICH IT SHOULD TYPE A MESSAGE AND EXIT, OR JUST
TYPE A MESSAGE, RESPECTIVELY. ^IN OTHER WORDS THE FACILITY CONSTITUTES
A DEBUGGING TOOL, EXCEPTION TRACE, OR MEANS OF REDUCING THE NUMBER OF
^^ERROR-STATUS\\ CHECKS IN AN APPLICATION--DEPENDING ON HOW IT IS USED.
^THE SYNTAX OF THESE STATEMENTS IS:
.B1
^^INTERCEPT!NOTE (SYSTEM BIND CALL UPDATE)!ALL [EXCEPTIONS]\\.
.B1
^THAT IS, EITHER ^^ALL\\ OR ONE OR MORE OF THE OTHERS MAY BE SPECIFIED.
^WHEN A DESIGNATED EXCEPTION OCCURS, THE MESSAGE PRINTED IS OF THE FORM:
.B1
[^^STATUS/AREA/RECORD/SET\\=STATUS/AREA-NAME/OTHERS IF KNOWN]
.B1
^IF INTERCEPTION WAS SPECIFIED, AN ^^EXIT\\ 1 IS THEN
DONE...WHICH MEANS THE USER CAN STILL TYPE ^^CONTINUE\\ IF HE WISHES.
^THE EXCEPTION-PARTITIONING IMPLIED HERE IS DESCRIBED IN 2.1.5.2.
.B2
2.1.1.5 ^^ASSIGN\\ ^STATEMENT#-#
^THE SYNTAX OF THE THIS STATEMENT IS NOW:
.B1.TS5.NF.NJ
^^ASSIGN [SYSTEM AREA]\\ AREA-NAME ^T^O FILE-SPEC
^^[RECORDS-PER-PAGE [IS]\\ INTEGER]
^^[BACKUP (BEFORE AFTER) [IMAGES]]\\
^^[BUFFER [COUNT IS]\\ INTEGER]
^^[CALC [AT MOST]\\ INTEGER ^^RECORDS-PER-PAGE\\]
^^FIRST PAGE [IS]\\ INTEGER
^^LAST PAGE [IS] \\ INTEGER
^^PAGE SIZE [IS]\\ INTEGER ^^WORDS\\
^^[RANGE [OF]\\ NAME ^^[IS PAGE]\\ INTEGER ^^[TO PAGE]\\ INTEGER]
[MORE ^^RANGE\\ PHRASES].
.B1.LM0.F.J
^EXCEPT FOR THE ^^RANGE\\ CLAUSE, EACH CLAUSE CAN APPEAR AT MOST ONCE.
^ORDERING IS AS PRESENTED EXCEPT THAT THE ^^RPP, BACKUP, BUFFER\\ AND ^^CALC\\ OPTIONAL CLAUSES ARE INTERCHANGABLE.
.B1
^THE ^^SYSTEM AREA\\ PHRASE SERVES TO SUPPORT THE ^^OWNER IS SYSTEM\\
CLAUSE ADDED TO THE ^^SET\\ STATEMENT, SEE 2.1.2.3. ^ITS EFFECT IS
TO CAUSE THE SYSTEM RECORD (IF THERE IS NEED FOR ONE) TO BE STORED IN THIS AREA
(ALONG WITH ANY OTHER RECORD TYPES ALLOWED IN THIS AREA). ^IF THERE IS A NON-NULL SYSTEM RECORD AND NO AREA CONTAINS THIS
PHRASE, THE FIRST AREA ASSIGNED WILL BECOME THE SYSTEM AREA.
.PG.B1
^THE ^^RECORDS-PER-PAGE\\ CLAUSE IS USED TO SPECIFY THE MAXIMUM NUMBER OF RECORDS THAT CAN BE ON A PAGE OF THIS AREA.
(^IT OVERRIDES A ^^RECORDS-PER-PAGE\\ STATEMENT IF ONE IS PRESENT).
^IF THIS CLAUSE IS ABSENT,
A ^^RECORDS-PER-PAGE\\ STATEMENT MUST HAVE APPEARED EARLIER--AND THE VALUE SPECIFIED THERE WILL BE USED.
^IN OTHER WORDS, A ^^RECORDS-PER-PAGE\\ STATEMENT IS NECESSARY UNLESS EACH AREA SPECIFIED HAS ITS OWN ^^RECORDS-PER-PAGE\\ CLAUSE.
^WHETHER A GLOBAL OR LOCAL ^^RPP\\ APPLIES TO THIS ^^ASSIGN\\ STATEMENT,
IT MUST SPECIFY AT LEAST 2 AND LESS THAN 512 RECORDS PER PAGE.
.B1
^THE ^^BUFFER\\ CLAUSE IS USED TO SPECIFY HOW MANY PAGE-BUFFERS THIS AREA WILL HAVE.
^A BUFFER COUNT OF 2 IS THE MINIMUM ALLOWED.
^IF THE CLAUSE IS ABSENT, 3 BUFFERS WILL BE CREATED.
.B1
^THE ^^CALC\\ CLAUSE ALLOWS ONE TO TRADE OFF THE AMOUNT OF PER-AREA
OVERHEAD ASSOCIATED WITH CALC RECORDS WITH THE AVERAGE TIME TO ACCESS/STORE A CALC RECORD.
^IN EARLIER VERSIONS, THERE WAS ALWAYS PRECISELY ONE CALC-CHAIN PER PAGE (ONE LIST==ONE WORD OF OVERHEAD).
^THUS IF ONE EXPECTED 500 CALC RECORDS IN AN AREA THAT HAD 100 PAGES, THE AVERAGE CALC-CHAIN WOULD UNAVOIDABLY HAVE 5 RECORDS IN IT.
^BUT IN ^V4 ONE COULD SPECIFY ^^CALC 5 RPP\\ AND THEREBY REDUCE THE AVERAGE CALC-CHAIN LENGTH TO 1. ^CONVERSELY IF THERE ARE NO CALC
RECORD TYPES IN A PARTICULAR AREA, ONE CAN NOW SAY ^^CALC 0 RPP\\.
.B1
^EACH ^^RANGE\\ CLAUSE CONTROLS WHERE IN THIS AREA A PARTICULAR
RECORD TYPE CAN BE ^^STORE\\D.
^IF A RECORD TYPE CAN BE ^^WITHIN\\ THIS AREA, IT MAY HAVE A ^^RANGE\\
CLAUSE FOR
THIS AREA. ^IF A RECORD TYPE THAT CAN BE ^^STORE\\D IN THIS AREA HAS NO ^^RANGE\\ CLAUSE FOR THIS AREA,
EACH PAGE OF THE AREA WILL CONSTITUTE ITS RANGE. ^THIS CLAUSE HAS TWO PURPOSES. ^ITS OBVIOUS PURPOSE IS TO ENABLE THE ADMINISTRATOR TO CLUSTER RECORDS BASED UPON
RECORD TYPE. ^ITS OTHER PURPOSE IS TO MAKE CALC RECORDS INSENSITIVE TO
A CHANGE IN THE NUMBER OF PAGES IN AN AREA. ^PREVIOUSLY THE NUMBER OF PAGES
IN AN AREA (THAT CONTAINED CALC RECORDS) COULD NEVER BE INCREASED SINCE
THAT WOULD "THROW THE CALC ALGORITHM OFF".
.B2.LM0
2.1.2##^THE ^SCHEMA ^^DDL\\
.B2
2.1.2.1 ^^AREA PRIVACY\\ ^CLAUSE#-#
^BECAUSE ^V4 SUPPORTS A WIDER SET OF AREA USAGE-MODES, THIS CLAUSE HAS BEEN EXPANDED. ^THERE IS NO CHANGE IN THE SYNTAX FOR SPECIFYING THAT
AN AREA'S LOCKS ARE ALL THE SAME, BUT THE SEPARATE-LOCKS SYNTAX IS NOW:
.B1
^^PRIVACY [LOCK FOR] [EXCLUSIVE!PROTECTED] RETRIEVAL!UPDATE [IS]\\ LOCK
.B1
^A DESCRIPTION OF THE SIX USAGE-MODES IS IN SUBSECTION 2.1.6.1.
.B2
2.1.2.2 ^THE ^DATA-NAME ^ENTRY#-#
^THIS STATEMENT HAS BEEN EXPANDED AND MADE MORE HOST-LANGUAGE INDEPENDENT. ^THE NATURE OF THE INCOMPATIBILITY SO INDUCED IS DESCRIBED IN 2.2, NOTES 1 AND 2. ^THE NEW SYNTAX IS:
.PG.B1.NF.NJ
02 DATA-NAME PICTURE!SIZE!TYPE [^^OCCURS\\ INTEGER [^^TIMES\\]].
##PICTURE-->^^PICTURE [IS]\\ SAME-AS-V3 [USAGE]
##SIZE-->###^^SIZE [IS]\\ INTEGER [^^WORDS\\!USAGE]
##TYPE-->###^^TYPE [IS]\\ NUMERIC!^^DBKEY\\
###USAGE-->#^^USAGE [IS] DISPLAY[-6]!DISPLAY-7!DISPLAY-9\\
###NUMERIC->^^FLOAT [DECIMAL!BINARY] [REAL!COMPLEX]\\ [INTEGER]
#####-->^^[FIXED] [DEC!BIN] [REAL!COMPLEX]\\ [INTEGER [INTEGER]]
.B1.F.J
^THE ^^OCCURS\\ CLAUSE IS OF COURSE USED TO DEFINE AN ARRAY AND DESCRIBE ITS LENGTH. (^THIS DOES NOT AFFECT ^^GET\\ AND
^^MODIFY\\; EACH WILL STILL PROCESS ENTIRE 02-DATA-NAMES: IF 02 ^A ^^OCCURS 3\\ APPEARED IN A SCHEMA, ^^GET A\\ WOULD GET THE WHOLE ARRAY AND ^^GET A(2)\\ WOULD BE FLAGGED AS A SYNTAX ERROR).
.B1
^THE ^^PICTURE\\ CLAUSE IS USED TO DESCRIBE ELEMENTARY STRING DATA;
THE ^^SIZE\\ CLAUSE IS USED TO DESCRIBE DATA STRUCTURES; AND THE ^^TYPE\\ CLAUSE IS
USED TO DESCRIBE NUMERIC DATA (AND ^^DBKEYS\\).
^THUS THE ^^USAGE\\ PHRASE CAN NO LONGER BE USED TO DESCRIBED NUMERIC DATA.
^THE ^^USAGE\\ PHRASE'S SOLE PURPOSE NOW IS TO STATE WHAT TYPE OF STRING DATA IS BEING ALLOCATED: RESPECTIVELY ^^SIXBIT, ASCII,\\ OR ^^EBCDIC\\.
^NOTE ALSO THAT THE PROGRAMMER NOW HAS COMPLETE CONTROL OF THE UNIT OF STORAGE
ALLOCATION IN THE ^^SIZE\\ CLAUSE: WHOLE WORDS AS WELL AS ANY OF THE THREE STRING REPRESENTATIONS.
^THE STRING HOST-LANGUAGE MAPPINGS ARE,
WHERE !X! =SMALLEST INTEGER>=X:
.B1.LM5.TS17,33,49.NF.NJ
^^KEYWORDS LENGTH FORTRAN COBOL
-----------------------------------------------------
.TS18,33,49
DISPLAY-6 N INTEGER(!N/5!) AS IN DDL
DISPLAY-7 N INTEGER(!N/5!) AS IN DDL
DISPLAY-9 N INTEGER(!N/4!) AS IN DDL\\
.B1.LM0.F.J
^THE ^^NUMERIC\\ PHRASE IN THE ^^TYPE\\ CLAUSE ALLOWS SIX TYPES OF NUMERIC ENCODING; THE DEFAULTS FOR EACH PAIR ARE RESPECTIVELY ^^FIXED\\, ^^BINARY\\ AND ^^REAL\\.
^THE FIRST OPTIONAL INTEGER AT THE
END OF THE ^^NUMERIC\\ PHRASE IS THE DATA-NAME'S PRECISION (IN BINARY OR DECIMAL DIGITS ACCORDING TO THE 2ND KEYWORD PAIR).
^THE SECOND INTEGER, IF APPLICABLE, IS ITS SCALE FACTOR.
^A SCALE FACTOR INDICATES THAT THE INTERNAL FORM OF A FIXED-POINT NUMBER
IS SOME NUMBER OF POWERS-OF-10 DIFFERENT THAN THE EXTERNAL FORM. ^THE
DEFAULT IS OF COURSE 0 (IE. NO DIFFERENCE); -1 MEANS EXTERNAL IS 10 TIMES AS LARGE; 1 MEANS EXTERNAL IS 1/10 AS LARGE.
.B1
^IF NO SUPPORTED HOST-LANGUAGE INTRINSICALLY SUPPORTS A PARTICULAR COMBINATION OF
^^NUMERIC\\ KEYWORDS AND THE CHOSEN PRECISION, A SYNTAX ERROR WILL BE SIGNALLED DURING TRANSLATION OF THE ^^TYPE\\ CLAUSE.
^THE DEFAULT PRECISIONS FOR ^^FIXED BIN, FLOAT BIN,\\ AND ^^FIXED DEC\\ ARE RESPECTIVELY 35,27, AND 10.
^THE LEGAL COMBINATIONS AND THE HOST-LANGUAGE MAPPINGS ARE AS FOLLOWS:
.PG.B1.LM5.TS24,36,52.NF.NJ
^^KEYWORDS PRECISION FORTRAN COBOL
-----------------------------------------------------------
.TS26,36,52
FIXED BIN REAL _< 36 INTEGER COMP S9(X2)
FIXED BIN REAL 36-71 INTEGER(2) COMP S9(X3)
FLOAT BIN REAL _< 28 REAL COMP-1
FLOAT BIN REAL 28-62 REAL*8 COMP S9(18)
FLOAT BIN COMPLEX _< 28 COMPLEX COMP S9(18)
FIXED DEC REAL _< 19 INTEGER(X1) COMP-3 S9(\\PREC)
.B1.LM0.F.J
^NOTE THAT WHERE ONLY ONE HOST-LANGUAGE SUPPORTS THE KEYWORD COMBINATION INTRINSICALLY, THE
OTHER DECLARES IT AS "BEST IT CAN".
^FOR EXAMPLE, FOR ^^FIXED DEC REAL\\, ^^FORDML\\ SIMPLY ALLOCATES
4 DECIMAL DIGITS/WORD (IE. ^X1=PREC/4), IN TERMS OF A "REASONABLE" DATA TYPE--^^INTEGER\\.
.B1
^THE VALUES ^X2 AND ^X3 ARE COMPUTED ACCORDING TO THE FOLLOWING MAPPING.
^HOWEVER IT IS SUGGESTED THAT ONE USE EITHER ^^FIXED BIN\\ (35=THE DEFAULT)-- OR
^^FIXED BIN\\ 71 FOR DOUBLE PRECISION--UNLESS THERE IS A SPECIFIC NEED TO CAUSE
NUMERIC TRUNCATION AT RUN-TIME. ^CONSISTENTLY USING FULL-WORD PRECISION
LEADS TO ^^COBOL\\ GENERATING BETTER OBJECT CODE.
.B1.LM5.TS9,41.NF.NJ
^^BINARY PRECISION _<= P\\ MAPS TO ^^DECIMAL PRECISION X2/3\\
----------------------------------------------------
4 1
7 2
10 3
14 4
17 5
20 6
24 7
27 8
30 9
35 10
(SWITCH TO DOUBLE PRECISION)
38 11
41 12
44 13
48 14
51 15
54 16
58 17
>58 18
.B2.LM0.F.J
2.1.2.3 ^THE ^^SET\\ ^ENTRY#-#
^THERE ARE SEVERAL SMALL CHANGES TO THE ^^SET\\ ENTRY.
.B1
^THE OWNER OF A SET CAN NOW BE THE SYSTEM. ^IN OTHER WORDS,
THE PROGRAMMER NEED NO LONGER CREATE A DUMMY RECORD TYPE WHEN HE WISHES TO HAVE A SINGULAR SET. ^THIS AFFECTS THE ^^OWNER\\ CLAUSE, AND ITS NEW SYNTAX IS:
.B1.C
^^OWNER [IS]\\ RECORD-NAME!^^SYSTEM\\
.PG.B1
^THE FEW SPECIAL RULES GOVERNING SINGULAR SETS ARE:
.B1
^THE SYSTEM AREA MUST BE PLACED IN ALL SUB-SCHEMAS, BUT IT
NEED BE OPEN ONLY IF THE SYSTEM RECORD WILL BE REFERENCED (SEE 2.1.1.5 ON HOW TO ALLOCATE AREA SPACE TO THE SYSTEM RECORD).
.B1
^NO MEMBER CLAUSE IN THE SET ENTRY OF A SINGULAR SET MAY HAVE
A ^^SET SELECTION\\ PHRASE. ^THE REASON
FOR THIS IS INTUITIVELY REASONABLE: SINCE THE ^^DBCS\\ KNOWS THE SET IS
SINGULAR, IT CAN ALWAYS CORRECTLY (AND QUICKLY) LOCATE THE "PROPER" SET
OCCURRENCE.
.B1
^^FIND OWNER\\ WILL BE ALLOWED RELATIVE TO SINGULAR SETS SO THAT A ^^FIND NEXT\\ LOOP FOR A SINGULAR SET
CAN BE CODED AS IT WOULD BE FOR ANY OTHER SET.
^HOWEVER THE MEANING OF A SUCCEEDING ^^GET, MODIFY, INSERT, REMOVE, ^O^R DELETE\\ IS OF COURSE ILL-DEFINED AND WILL
RETURN EXCEPTION XX20.
.B1
^THE ^^SET\\ ENTRY MAY OPTIONALLY BE SEPARATED FROM ITS ^^MEMBER\\ ENTRIES
BY A PERIOD. ^MULTIPLE ^^MEMBER\\ ENTRIES CAN ALSO BE OPTIONALLY SEPARATED BY PERIODS.
.B1
^WHEN ^^ORDER SORTED\\ OR ^^ORDER SORTED WITHIN\\ IS SPECIFIED AS A SET'S ^^ORDER\\,
THE RECORD-NAME OF EACH MEMBER RECORD IS EACH'S MAJOR SORT KEY.
^IN ORDER TO SPEED PROCESSING AND DECREASE THE AMOUNT
OF DATA BASE SPACE REQUIRED, ^^DBMS-10/20\\ USES THE
RECORD'S TYPE ^^ID\\ RATHER THAN THE RECORD-NAME ITSELF.
^TYPE ^^ID\\'S ARE ASSIGNED IN INCREASING SEQUENCE AS EACH ^^RECORD\\ ENTRY IS PROCESSED. ^THIS HAS TWO EFFECTS. ^ONE IS THAT
THE MEMBER RECORD TYPES WILL NOT BE SORTED IN ALPHABETIC
SEQUENCE UNLESS THEY APPEAR IN ALPHABETIC SEQUENCE; AND
TWO, THAT THE USER NOW HAS COMPLETE CONTROL AND CAN SPECIFICALLY
CAUSE NON-ALPHABETIC SEQUENCES.
.B1
^SIGNED ^^RANGE KEY\\S WILL BE SUPPORTED IN ^V4.
^ALSO ALL KEYS TO THE RIGHT OF THE FIRST ^^RANGE\\ WILL
BE TREATED AS ^^RANGE KEY\\S. ^ABSENCE OR PRESENCE OF THE
KEYWORD ^^RANGE\\, AFTER ITS FIRST APPEARANCE, WILL BE TRANSPARENT TO THE ^^SCHEMA\\ PROCESSOR.
^FINALLY, THE EXISTING SYNTACTIC DESCRIPTION IS SOMEWHAT VAGUE, THE
ACTUAL SYNTAX IS:
.B1.TS5,13.NF.NJ
KEY-PHRASE [KEY-PHRASE ...] [DUPLICATES-PHRASE]
^^WHERE\\...
KEY-PHRASE --> KEY-TYPE [^^KEY IS\\] DATA-NAME-1, [DN-2,...]
KEY-TYPE --> ^^ASC!DESC!ASC RANGE!DESC RANGE\\
DUPLICATES-PHRASE -->
^^DUPLICATES [ARE] [FIRST!LAST!NOT] [ALLOWED\\]
.B1.LM0.F.J
^WHEN SORT/CALC KEYS CONSIST OF MORE THAN ONE DATA ITEM,
IT IS ALLOWABLE TO NOT ^^ALIAS\\ ALL OF THE ITEMS. ^PRESUMABLY THIS
WOULD BE OF USE WHEN ONE WISHED TO ALIAS THE MINOR KEY(S) AND
NOT THE MAJOR KEY. ^IN ANY EVENT, THESE EXAMPLES PORTRAY EACH OF THE POSSIBLE CASES:
.B1.LM9.I-4
1.##^^ALIAS FOR DN1 IS ALIAS1
.B1.I-4
2.##ALIAS FOR DN1 IS ALIAS1 ALIAS FOR DN2 IS ALIAS2
.B1.I-4
3.##ALIAS FOR DN1 IS DN1 ALIAS FOR DN2 IS ALIAS2\\
.PG.B2.LM0
2.1.2.4 ^GUARANTEEING ^SOURCE ^PROGRAM ^CONSISTENCY#-#
^EARLIER VERSIONS OF ^^SCHEMA\\ WERE SOMEWHAT LAX IN DETECTING IF THE
SUBTLER REQUIREMENTS OF THE ^^DDL\\ WERE BEING SATISFIED. ^VERSION 4 ATTEMPTS TO
GUARANTEE THAT NO INVALID PROGRAM WILL TRANSLATE ERROR-FREE. (^THERE IS OF COURSE A ^^CATCH\\-22 INCOMPATIBILITY IN THIS SINCE SOME EXISTING ^^.DDL\\
PROGRAMS WILL DISPLAY ERRORS WHEN TRANSLATED WITH ^V4).
^THE MORE INTERESTING CHECKS ARE AS FOLLOWS:
.B1.LM9.I-4
1.##^TABLE 4-1 ON P. 4-17 IN THE ^ADMINISTRATOR'S ^MANUAL WILL BE ENFORCED.
.B1.I-4
2.##^WHEN ^^SET SELECTION\\ IS THRU ^^LOCATION MODE OF OWNER\\, ANY KEY SO REFERENCED MUST HAVE BEEN DECLARED SUCH THAT ^^DUPLICATES ARE NOT ALLOWED\\ FOR THE KEY.
.B1.I-4
3.##^IF AN ^^ALIAS ^O^R USING\\ ARGUMENT IS NOT VALID, AN ERROR IS REPORTED.
.B1.I-4
4.##^FOR EACH ^^RECORD\\ ENTRY IN WHICH THERE IS A ^^LOCATION MODE IS VIA\\ CLAUSE, THERE MUST BE A CORRESPONDING ^^SET\\.
.B1.I-4
5.##^FOR EACH ^^RANGE\\ CLAUSE, THE CORRESPONDING ^^WITHIN\\ CLAUSE MUST APPEAR.
.B1.I-4
6.##^IF A RECORD IS DECLARED IN THE SAME SET MORE THAN ONCE, AN ERROR IS REPORTED.
.B1.I-4
7.##^IF A ^^RECORD\\ ENTRY CONTAINS A ^^LOCATION MODE VIA\\ CLAUSE AND IS A MEMBER
OF A SORTED SET IN WHICH (ONE OF) THE SORT KEY(S) IS THE RECORD'S DBKEY, AN ERROR IS REPORTED. ^THIS IS BECAUSE SUCH A SITUATION IS
A DEADLOCK: ^^VIA\\ SAYS STORE THE RECORD PHYSICALLY NEAR ITS
LOGICAL NEIGHBORS, WHILE SORTED-ON-DBKEYS SAYS LOGICALLY PLACE THE RECORD ON
THE BASIS OF WHERE IT IS PHYSICALLY.
.B2.LM0
2.1.3##^THE ^SUB-SCHEMA ^^DDL\\
.B1
^CONCEPTUALLY THERE HAS BEEN ONLY ONE CHANGE TO THE SUB-SCHEMA
^^DDL\\; ANY TEXT (EG. 03 DATA-NAME...) THAT THE PROGRAMMER WISHES
TO ASSOCIATE WITH AN 02-DATA-NAME WILL BE SO ASSOCIATED IN THE SUB-SCHEMA ^^DDL\\. ^THE REASONS FOR MAKING THIS
CHANGE ARE TWOFOLD: TO ISOLATE ^^COBOL\\ DEPENDENCIES IN SUB-SCHEMAS INTENDED
FOR USE BY ^^COBOL\\ APPLICATIONS AND TO ALLOW A PROGRAMMER TO ASSOCIATE ^^FORTRAN\\ INFORMATION
WITH AN 02-DATA-NAME.
.B2.LM0
2.1.3.1 ^GENERAL ^TEXT-SPECIFYING ^RULES#-#
^TEXT IS SPECIFIED ON A LINE BASIS; THE PRESENCE OR ABSENCE OF
A TERMINATING PERIOD IS IRRELEVANT. ^THE LINE(S) FOLLOWING A
SUB-SCHEMA ^^DATA\\ ENTRY WILL BE TREATED AS TEXT UNLESS ITS FIRST WORD IS
^^COPY\\, 02, 01, OR ^^SET\\. ^IF ONE WISHES TO HAVE A LINE OF TEXT THAT
STARTS WITH ONE OF THESE SYMBOLS, THE LINE MUST BE PREFIXED BY A PLUS (+). (^NOTE THAT THE MEANS OF EXPLICITLY ENTERING NULL TEXT IS A
LINE CONSISTING OF +_<<CRLF>.)
.PG.B1
^SINCE IT IS LIKELY THAT A DATA-NAME WILL HAVE THE SAME USAGE IN DIFFERENT SUB-SCHEMAS,
THERE MUST BE A WAY TO ASSOCIATE A DATA-NAME WITH THE SAME TEXT
IN MORE THAN ONE SUB-SCHEMA.
^THE MECHANISM FOR DOING THIS EXPLICITLY IS DESCRIBED IN 2.1.3.3,
BUT THE DEFAULT MECHANISM IS AS FOLLOWS.
^LET DATA-NAME-1 BE ASSOCIATED WITH TEXT-A IN THE (I)TH SUB-SCHEMA
IN THE PROGRAM, AND LET THE NEXT SUB-SCHEMA IN WHICH DATA-NAME-1 IS
DECLARED BE THE (J)TH. ^THEN TEXT-A WILL AGAIN BE ASSOCIATED WITH DATA-NAME-1 UNLESS TEXT-B IS ACTUALLY PRESENT
WITH DATA-NAME-1(J)--IN WHICH CASE TEXT-B WILL BECOME
THE DEFAULT FOR DATA-NAME-1 IN LATER SUB-SCHEMAS.
.
.
.B2
2.1.3.2 ^THE ^^COPY OTHERS\\ ^STATEMENT#-#
^THIS STATEMENT IS USED TO PLACE THE "REMAINING" ^^DATA\\ ENTRIES OF A ^^RECORD\\ ENTRY IN A SUB-SCHEMA.
^FOR EXAMPLE, IF ^^REC\\1'S ^^DATA\\ ENTRIES WERE ^^A1, A2, A3, A4\\ AND ^A5, SAYING:
.B1.I5
01#<REC1.
.B1
WOULD BE EQUIVALENT TO:
.B1.LM5.NF.NJ
01#<REC1.
02#<A2.
02#<A4.
<COPY <OTHERS.
.B1.LM0.F.J
^HOWEVER THE USUAL USAGE OF ^^COPY OTHERS\\ WOULD BE SOMETHING ANALOGOUS TO:
.B1.LM5.NF.NJ
^^01#REC1.
02#A2.
THIS IS ARBITRARY TEXT
02#A4.
SO IS THIS
COPY OTHERS.\\
.B2.LM0.F.J
2.1.3.3 ^THE ^^COPY TEXT\\ ^STATEMENT#-#
^TO ASSOCIATE DATA-NAME-1(J) WITH THE TEXT
ASSOCIATED WITH DATA-NAME-1 IN AN EARLIER SUB-SCHEMA, ONE MAY TYPE THE FOLLOWING,
RATHER THAN THE ACTUAL TEXT:
.B1.C
^^COPY\\ SUB-SCHEMA-NAME [^^TEXT\\].
.B1.LM0
^EXAMPLE:
.B1.LM5.NF.NJ
^^RECORD NAME IS R1
:
:
02 D1 SIZE 4 WORDS.
02 D2 TYPE FLOAT BIN.
02 D3 PIC X(5) OCCURS 4.
:
:
SUBSCHEMA NAME IS SS1.
:
:
01 R1.
02 D1.
03 DD1 PIC X(12).
03 DD2 PIC S9(18) USAGE COMP.
COPY OTHERS.
:
:
SUBSCHEMA NAME IS SS2.
:
:
01 R1.
:
:
SUBSCHEMA NAME IS SS3.
01 R1.
02 D1.
EQUIVALENCE (D1(1),D6BIT), (D1(3),DPINT)
02 D2.
:
:
SUBSCHEMA NAME IS SS4.
01 R1.
02 D1.
COPY SS1.
COPY OTHERS.\\
.B1.LM0.F.J
^SUB-SCHEMAS ^^SS1, SS2,\\ AND ^^SS4\\ LEAD TO EXACTLY THE SAME RECORD DESCRIPTION BEING PLACED IN THE ^^COBOL\\
HOST PROGRAM. ^SUB-SCHEMA ^^SS\\3 PLACES ^^INTEGER D1(4) AND
^^REAL D2\\, AS WELL AS THE ^^EQUIVALENCE\\ STATEMENT, IN THE ^^FORTRAN\\ HOST PROGRAM.
.B2
2.1.4##^THE ^^SCHEMA\\ ^PROGRAM ^INTERFACE
.B1
^THE ^V4 COMMAND LINE PROCESSOR UTILIZES ^^SCAN\\ AND ^^WILD\\. ^THE GENERAL FORM OF THE COMMAND LINE IS AS FOLLOWS:
.B1.C
[FILE-SPEC=] FILE-SPEC [SWITCHES]
.B1
^IF ALL OR PART OF THE OUTPUT FILE SPEC IS ABSENT, THE MISSING PARTS
ARE DERIVED FROM THE INPUT FILE SPEC. ^THE DEFAULT EXTENSION FOR INPUT FILES IS ^^.DDL\\. ^ANY EXTENSION IN THE OUTPUT FILE SPEC IS IGNORED. ^THE EXTENSION OF THE OUTPUT FILE IS ALWAYS FORCED TO ^^.SCH\\.
.B1
^IN ^V4 THERE IS JUST ONE CLASS OF SWITCH, THE
/^^CREATE\\ SWITCH. ^IT CONTROLS WHETHER THE ^^.DBS\\ FILES ARE
(RE)CREATED OR LEFT AS THEY ARE:
.B1.LM9.I-4
1.##^IF NO SWITCH IS PRESENT, A ^^.DBS\\ FILE IS CREATED ONLY IF IT DOES NOT EXIST ALREADY.
.B1.I-4
2.##^IF ^^/CREATE\\ IS PRESENT, THE ^^.DBS\\ FILES ARE ALWAYS CREATED.
.B1.I-4
3.##^IF /^^NOCREATE\\ IS PRESENT, THE ^^.DBS\\ FILES ARE NEVER CREATED.
.PG.B1.LM0
^THERE HAS BEEN A SLIGHT CHANGE OF PHILOSOPHY IN HOW AREAS ARE ADDRESSED.
^AREAS GENERALLY HAVE THE PROPERTY THAT THEY STAY PUT: ONCE THEY CONTAIN
LIVE DATA THEIR NAME AND DIRECTORY SELDOM CHANGE. ^CONSEQUENTLY
WHEN ^^SCHEMA\\ INITIALIZES AN AREA, THE AREA IS ASSOCIATED TO ITS
DIRECTORY OF CREATION PERMANENTLY. ^IN OTHER WORDS, IF DURING THE
RUNNING OF ^^SCHEMA\\ ^^AREA1\\ IS ^^ASSIGN\\ED TO ^^FILE1\\, IT
IS ALSO ^^ASSIGN\\ED TO THE DIRECTORY WHICH CONSTITUTED THE
CURRENT DIRECTORY PATH.
.B1
^AS NOTED EARLIER, THE ERROR DETECTING CAPABILITY OF ^^SCHEMA\\ HAS
BEEN EXPANDED. ^ADDITIONALLY THE ERROR MESSAGES ARE NOW IN
STANDARD FORM (IE. PRECEDED BY ^^?DDL\\XXX OR %^^DDL\\XXX).
^LASTLY AN ERROR MESSAGE IS ACCOMPANIED BY
THE FIRST (AND LAST) LINE OF THE OFFENDING
SOURCE STATEMENT, IF APPLICABLE.
.B1
^IMPORTANT: THE DISTINCTION BETWEEN WARNINGS (%) AND ERRORS (?) IS FUNCTIONAL AS
WELL AS DESCRIPTIVE. ^IF THE ERROR COUNT IS GREATER THAN 0, THE
^^.SCH\\ FILE (AND ^^.DBS\\ FILES) WILL NOT BE
(RE)CREATED. ^IF THE WARNING COUNT IS GREATER THAN 0 AND THE ERROR COUNT
IS 0, PROCESSING WILL NOT BE CURTAILED.
.B2
2.1.5##^EXCEPTION ^HANDLING
.B2
2.1.5.1 ^THE ^^ERROR\\ ^SPECIAL ^REGISTERS#-#
^EACH TIME A ^^DML\\ VERB IS EXECUTED, ^^ERROR-STATUS\\ AND ^^ERROR-COUNT\\ ARE SET TO WELL-DEFINED VALUES.
^IF NO EXCEPTION OCCURRED,
^^ERROR-STATUS\\ EQUALS THE NULL-STRING (IE. IT IS A 0-WORD) AND ^^ERROR-COUNT\\ EQUALS 0. ^THE OTHER THREE ^^ERROR\\ SPECIAL REGISTERS
HAVE THE SAME VALUE AS BEFORE THE VERB WAS EXECUTED.
.B1
^IF AN EXCEPTION DID OCCUR, ^^ERROR-STATUS\\
EQUALS " XXYY" AND ^^ERROR-COUNT\\ EQUALS 1, WHERE "XX" IS A STATEMENT CODE (SEE 2.1.5.2) AND "YY" IS AN EXCEPTION CODE (SEE 2.1.5.4).
.B1
^^ERROR-AREA\\ WILL ALWAYS EQUAL THE LAST AREA ACTUALLY REFERENCED.
.B1
^EXCEPT FOR ^^OPEN\\ AND ^^CLOSE\\, ^^ERROR-RECORD\\
WILL BE BLANKS ONLY IF THE EXCEPTION OCCURRED WHILE ^^DBCS\\
WAS STILL PROCESSING THE VERB'S ARGUMENT LIST. ^OTHERWISE IT WILL BE THE OBJECT RECORD'S TYPE UNLESS THE VERB "TRAVERSES" THE DATA BASE. ^A QUALIFIED ^^DELETE\\ RECURSIVELY TRAVERSES
THE DATA BASE, ^^FIND NEXT\\ WITH A NON-NULL RECORD-NAME TRAVERSES THE DATA BASE,
AND ^^FIND OWNER\\ TRAVERSES THE DATA BASE. ^IN THESE CASES, ^^ERROR-RECORD\\ WILL BE THE RECORD TYPE OF THE
LAST RECORD OPERATED UPON.
.B1
^^ERROR-SET\\ WILL BE BLANKS UNLESS AT LEAST ONE SET OPERATION HAS BEEN
STARTED AT THE TIME OF THE EXCEPTION. ^EACH OF THE FOLLOWING CONSTITUTES A SET OPERATION:
^^FIND NEXT/PRIOR/OWNER OF SET\\, EACH AUTO-INSERT DURING A ^^STORE\\, EACH ACTUAL
INSERT DURING AN ^^INSERT\\, EACH REMOVE IN A ^^REMOVE\\ AND EACH AUTO-REMOVE IN A ^^DELETE\\, AND EACH RESORTING OF A SET OCCURRENCE DURING A ^^MODIFY\\.
.PG.B2
2.1.5.2 ^CLASSES OF ^EXCEPTIONS#-#
^THERE ARE SEVERAL CLASSES OF EXCEPTIONS EXPLICITLY DEFINED. ^^ALL\\ IS OF COURSE ALL THE VALID STATEMENT-CODE/EXCEPTION-CODE COMBINATIONS, ^^SYSTEM\\ IS ALL THE EXCEPTIONS WITH A CODE
GREATER THAN OR EQUAL TO 55. ^THE ^^SYSTEM\\ EXCEPTIONS ARE DISCUSSED IN SOME DETAIL IN THE NEXT SUBSECTION, ^FAILSOFTING.
^THE OTHER DEFINED CLASSES ARE PARTITIONS OF THE STATEMENT-CODES,
WHICH ARE:
.B1.LM5.TS29.NF.NJ
^^STATEMENT CODE\\
----------------------------
.LM5.TS30
^^HOST 00
CLOSE 01
DELETE 02
FIND 03
UNUSED 04
GET 05
UNUSED 06
INSERT 07
MODIFY 08
OPEN 09
UNUSED 10
REMOVE 11
STORE 12
RESERVED 13
RESERVED 14
BIND 15
CALL 16\\
.B1.LM0.F.J
^THE ^^HOST\\ STATEMENT-CODE IS ASSOCIATED WITH THE ^I^F PREDICATES AND THE ^^MOVE STATUS\\ COMMAND. ^THE ^^BIND\\ STATEMENT-CODE IS
ASSOCIATED WITH THE ^^SBIND, BIND, EBIND,\\ AND ^^SETUSE\\ ENTRY POINTS. ^ALSO NOTE THAT EXCEPTIONS 31 THRU 36 CAN ONLY BE GENERATED DURING BINDING. ^THE ^^CALL\\ STATEMENT-CODE IS ASSOCIATED WITH
ALL OF THE ^^DBCS\\ ENTRY POINTS THAT ARE EXPLICITLY CALLED (IE. THE JOURNALING ENTRY POINTS ^JXXXXX AND ^^SETDB\\ AND ^^UNSET\\).
^THE ^^UPDATE\\ CLASS OF EXCEPTIONS REFERS TO ANY EXCEPTION THAT HAPPENS
DURING EXECUTION OF ^^DELETE, INSERT, MODIFY, REMOVE\\ OR ^^STORE\\.
.B2.LM0
2.1.5.3 ^FAILSOFTING#-#
^V4 OF ^^DBCS\\ ATTEMPTS TO GUARANTEE TWO THINGS AS REGARDS THE EXECUTION OF A RUN-UNIT.
.B1
^FIRST IT OPERATES ON THE ASSUMPTION THAT A CRITICAL APPLICATION MAY WANT TO MAINTAIN COMPLETE CONTROL AND NEVER BE RETURNED
TO MONITOR LEVEL AGAINST ITS WILL. ^^DBCS\\ SERVES THIS GOAL BY ASSOCIATING AN EXCEPTION CODE WITH ALL THE EXCEPTIONAL CONDITIONS THAT IT
DETECTS--IT NEVER DOES AN ^^EXIT\\ THAT THE USER DID NOT REQUEST (THE
^^INTERCEPT\\ FACILITY IS A MEANS OF REQUESTING ^^EXIT\\S). ^THIS RULE IS
BROKEN PRECISELY ONCE: TO PLACE A VALUE IN ^^ERROR-STATUS\\, ^^DBCS\\ MUST HAVE BEEN ASSOCIATED WITH
A SUB-SCHEMA--CONSEQUENTLY IF THE FIRST CALL TO ^^DBCS\\ IS AT OTHER THAN ^^SBIND\\, IT TYPES THE ?^^DBSSNI\\ MESSAGE AND EXITS.
.B1
^SECONDLY IT ATTEMPTS TO GUARANTEE THAT NO ONE ACCESSES A DATA BASE WHILE IT OR ^^DBCS\\ IS IN AN UNDEFINED STATE.
.PG.B1
^ONE ASPECT OF THIS CONTROL IS THE AREA-STATUS-RECORD (^^ASR\\), WHICH
IS CREATED THE FIRST TIME AN AREA IS ^^OPEN\\ED (AND ALWAYS HAS A DBKEY
EQUAL TO FIRST-PAGE/1). ^WHEN
AN AREA IS ^^OPEN\\ED FOR UPDATE, ^^DBCS\\ DECREMENTS BY 1 ^^FH.STAT\\ IN THE
^^ASR\\ TO INDICATE THAT THE AREA IS IN A STATE OF FLUX.
^^FH.STAT\\ IS NOT INCREMENTED BY 1 UNTIL THE PROGRAMMER CLOSES THE AREA.
^IF THE RUN-UNIT ABORTS FOR ANY REASON, ^^DBMEND\\ MUST BE USED TO REVALIDATE THE
AREA (AND RESET ^^FH.STAT\\ TO 0) BEFORE IT CAN BE ^^OPEN\\ED FOR NORMAL USAGE AGAIN.
.B1
^THE OTHER MAJOR ASPECT OF CONTROL IS ^^DBCS\\'S STATUS WORD (ONE FOR EACH
SUB-SCHEMA ^^INVOKE\\D).
^THE TWO USER-RELEVANT FLAGS ARE THE SYSTEM-IN-UNDEFINED-STATE (^^SUS\\) FLAG AND CANNOT-BACKUP-UPDATES (^^CBUU\\) FLAG.
^^^CBUU\\ IS TURNED ON IN THE FOLLOWING CIRCUMSTANCES: DURING EXCEPTIONS
61 AND 63, DURING ^^OPEN\\ IF THE JOURNAL DEVICE IS ^^MTA\\, DURING THE ^^OPEN\\ING OF AN AREA FOR UPDATE WHEN ^^BEFORE IMAGES\\ ARE NOT REQUESTED,
AND IN CONJUNCTION WITH
THE ^^SUS\\ FLAG IF AN EXCEPTION OCCURS DURING BINDING OR WHILE AN EXCEPTION IS BEING PROCESSED
(THIS ALSO CAUSES TYPING OF THE ?^^DBSXWX\\ MESSAGE).
^THE ^^SUS\\ FLAG GETS TURNED ON FOR ONLY ONE OTHER REASON, WHEN AN EXCEPTION
OCCURS AFTER AN UPDATING VERB HAS ALTERED ONE OR MORE DATA BASE PAGES.
.B1
^THE EFFECT OF THE ^^SUS\\ FLAG IS AS FOLLOWS.
^IF ONE TRIES TO ENTER ^^DBCS\\ WHILE THE ^^SUS\\ FLAG IS SET
(AT OTHER THAN ^^JBTRAN\\ OR A SUB-SCHEMA CHANGING ENTRY POINT), ^^DBCS\\ WILL
RETURN IMMEDIATELY WITH ^^ERROR-STATUS\\ SET TO " XX62".
^HOWEVER, IF ^^CBUU\\ IS NOT SET, THERE IS ONE OF TWO WAYS IN WHICH
THE ^^SUS\\ FLAG MAY GET TURNED OFF.
.B1
^IF IMAGES ARE ORDERED BY COMMAND, ^^DBCS\\ WILL AUTOMATICALLY RESTORE THE DATA BASE TO
THE STATE IT WAS IN BEFORE THE VERB WAS ENTERED AND TURN THE ^^SUS\\ BIT
OFF. ^BUT IF FOR SOME EXCEPTIONAL REASON THE RESTORATION CANNOT
BE COMPLETED, THE ?^^DBSUCR\\ MESSAGE IS TYPED AND ^^CBUU\\ IS ALSO TURNED ON.
.B1
^IF IMAGES ARE NOT ORDERED BY COMMAND
THE PROGRAM WILL BE ABLE TO EXPLICITLY RESTORE THE DATA BASE
TO ITS PROPER STATE EVEN THOUGH ^^DBCS\\ WILL HAVE RETURNED WITH THE ^^SUS\\ BIT STILL SET.
^IT CAN DO THIS VIA THE ^^JBTRAN\\ ENTRY POINT.
^CALLING ^^JBTRAN\\ AFTER AN UPDATING-EXCEPTION WILL RESTORE THE DATA BASE TO THE BEGINNING OF THE IN-DOUBT
TRANSACTION, TURN THE ^^SUS\\ BIT OFF, AND (^^IMPORTANT\\!) LEAVE ALL CURRENCY INDICATORS 0 (TO ELIMINATE
THE POSSIBILITY OF REFERENCE TO NOW NON-EXISTENT RECORDS). ^IF,
FOR SOME EXCEPTIONAL REASON ^^JBTRAN\\ FAILS, ^^ERROR-STATUS\\ WILL BE SET TO " 1663" AND ^^CBUU\\ TURNED ON.
.B1
^IN SUMMARY, THERE IS NO WAY FOR THE PROGRAMMER TO TURN OFF THE
^^CBUU\\ FLAG. ^IN AND OF ITSELF THIS IS NO PROBLEM SINCE THE ^^CBUU\\ FLAG IS
TRANSPARENT TO THE APPLICATION UNLESS THE ^^SUS\\ FLAG IS ALSO
TURNED ON.
^IN THIS LATTER STATE HOWEVER, THE RUN-UNIT CAN ESSENTIALLY DO NOTHING WITH THE SUB-SCHEMA... AND
IN EFFECT ^^DBCS\\ NO LONGER TRUSTS ITSELF.
.PG.B2.LM0
2.1.5.4 ^THE ^EXCEPTION ^CODES
.B1.LM16.TS16.I-16
^^EXCEPTION DESCRIPTION\\
.I-16
---------------------------------------------------------------
.I-12
00 ^A ^^WARNING\\: THE COMPILE-TIME AND RUN-TIME VERSIONS OF THE ^^.SCH\\ FILE DIFFER.
^HOWEVER IF A "REAL" EXCEPTION OCCURS DURING BINDING ^^DBCS\\ ALWAYS RETURNS THE CODE OF THAT EXCEPTION...
BUT TO INDICATE THAT EXCEPTION 00 HAS OCCURRED AS WELL, ^^DBCS\\
TYPES THE %^^DBSCED\\ MESSAGE.
^HOWEVER, AS A GENERAL RULE, THE "REAL" EXCEPTION WILL NOT PERSIST AFTER THE PROGRAM-UNIT IS RECOMPILED WITH THE UP-TO-DATE .^^SCH\\ FILE.
.B1.I-12
01 ^AREA NOT OPEN
.B1.I-12
02 ^DBKEY INCONSISTENT WITH AREA-NAME.
^CAN ALSO INDICATE THAT A REFERENCED PAGE NUMBER IS IN AN AREA THAT IS NOT IN THE SUB-SCHEMA.
.B1.I-12
03 ^RECORD AFFECTED BY CONCURRENT APPLICATION--^V5 ONLY
.B1.I-12
04 ^DATA-NAME INVALID OR INCONSISTENT (IE. DURING ^^GET\\ OR ^^MODIFY\\ WITH DATA-NAME LIST)
.B1.I-12
05 ^VIOLATION OF ^^DUPLICATES NOT ALLOWED\\ PHRASE
.B1.I-12
06 ^CURRENT OF (SET/RECORD/AREA) NOT KNOWN
.B1.I-12
07 ^END OF SET OR AREA
.B1.I-12
08 ^REFERENCED NAME NOT IN SUB-SCHEMA.
^THIS CAN OCCUR FOR MANY REASONS: (1) ^IN TRAVERSING A SET, IF A RECORD TYPE NOT IN THE SUB-SCHEMA IS ENCOUNTERED.
(2) ^DURING ^^STORE ^O^R DELETE\\, IF SET TYPE OWNED BY THE OBJECT RECORD TYPE IS NOT IN THE SUB-SCHEMA.
(3) ^DURING SET OCCURRENCE SELECTION IF THE ^^VIA\\ SET IS NOT IN THE SUB-SCHEMA.
(4) ^DURING CALC PROCESSING OR IN SEARCHING A SORTED SET, IF NOT ALL SUBKEYS ARE IN THE SUB-SCHEMA.
(5) ^DURING ^^MODIFY\\, IF THE SORT KEY OF A SET NOT IN THE SUB-SCHEMA IS MODIFIED.
.B1
^THE SOLUTION TO THIS PROBLEM IS OF COURSE TO PLACE THE OFFENDING NAME IN THE SUB-SCHEMA.
.B1.I-12
09 ^AN UPDATE USAGE MODE REQUIRED (EG. ATTEMPT TO ^^STORE\\ A RECORD WHILE THE AREA IS ^^OPEN\\ FOR ^^RETRIEVAL\\)
.B1.I-12
10 ^PRIVACY BREACH ATTEMPTED
.B1.I-12
11 ^DATA SPACE EXHAUSTED (IE. NO MORE ROOM TO ^^STORE\\ A RECORD).
^NOTE THAT THIS CAN OCCUR WHILE ^^DBCS\\ IS TRYING TO STORE AN INTERNAL RECORD TYPE: IN PARTICULAR, THE INDEX BLOCKS IN A SORTED SET.
.B1.I-12
12 ^UNUSED
.PG.B1.I-12
13 ^NO CURRENT RECORD OF THE RUN-UNIT
.B1.I-12
14 ^OBJECT RECORD IS MANDATORY AUTOMATIC MEMBER OF THE SET.
.B1.I-12
15 ^ATTEMPT TO ^^REMOVE\\ A RECORD WHICH IS EITHER A ^^MANDATORY\\ MEMBER OR NOT A MEMBER TYPE AT ALL.
.B1.I-12
16 ^RECORD IS ALREADY MEMBER OF SET.
.B1.I-12
17 ^NEED A RECORD WHICH IS CURRENT OF "-----", BUT IT HAS BEEN DELETED
(EG. CAN OCCUR DURING ^^FIND CURRENT OF "-----"\\; OR DURING ^^GET\\, IF THE RECORD WAS DELETED BY A CONCURRENT RUN-UNIT).
.B1.I-12
18 ^UNUSED
.B1.I-12
19 ^DATA CONVERSION UNSUCCESSFUL--UNUSED FOR NOW
.B1.I-12
20 ^CURRENT RECORD OF RUN-UNIT NOT OF RIGHT RECORD TYPE
.B1.I-12
21 ^UNUSED
.B1.I-12
22 ^RECORD NOT CURRENTLY MEMBER OF SET, ANALOGOUS TO XX17.
.B1.I-12
23 ^ILLEGAL AREA-NAME WAS PASSED IN AN ^^AREA-ID\\.
.B1.I-12
24 ^TEMPORARY AND PERMANENT AREAS REFERENCED IN SAME ^^DML\\ VERB.
.B1.I-12
25 ^NO SET OCCURENCE SATISFIES ARGUMENT VALUES (EG. CALC VALUE IN ^^UWA\\ MATCHED NO OWNER RECORD)
.B1.I-12
26 ^NO RECORD SATISFIED ^^RSE\\, CATCH-ALL EXCEPTION FOR ^^FIND\\ VERB.
.B1.I-12
27 ^UNUSED
.B1.I-12
28 ^AREA ALREADY OPEN
.B1.I-12
29 ^UNUSED
.B1.I-12
30 ^UNQUALIFIED ^^DELETE\\ ATTEMPTED ON NON-EMPTY SET
.B1.I-12
^^NON-CODASYL EXCEPTION CODES\\
.B1.I-12
31 ^UNABLE TO OPEN THE .SCH FILE
.B1.I-12
32 ^INSUFFICIENT SPACE ALLOCATED (EG. ^^SIZE\\ CLAUSE SPECIFIED LESS SPACE THAT WHAT THE COMPILER ACTUALLY NEEDED)
.B1.I-12
33 ^NONE OF THE AREAS A RECORD TYPE CAN BE ^^WITHIN\\ ARE IN THE SUB-SCHEMA.
.PG.B1.I-12
34 ^A SET IS IN THE SUB-SCHEMA, BUT ITS OWNER RECORD TYPE IS NOT.
.B1.I-12
35 ^DYNAMIC USE-VECTOR FULL
.B1.I-12
36 ^ATTEMPT TO ^^INVOKE\\ TOO MANY SUB-SCHEMAS (CURRENTLY MORE THAN 8),
ATTEMPT TO ^^UNSET\\ AN EMPTY SUB-SCHEMA STACK OR ^^SETDB\\ A FULL STACK.
.B1.I-12
37 ^ARGUMENT TO ^^SETDB\\ IS NOT AN ALREADY-^^INVOKE\\D SUB-SCHEMA.
.B1.I-12
38 ^DUPLICATE OPERATION ON RESOURCE: YOU HAVE ATTEMPTED TO OPEN THE JOURNAL TWICE;
YOU HAVE OPENED IT ^^EXCLUSIVE\\ AND ARE NOW OPENING AN
AREA WITH ^^USAGE-MODE UPDATE\\;
YOU ARE CALLING ^^JSTRAN\\ WHILE A TRANSACTION IS ALREADY ACTIVE;
OR YOU HAVE MULTIPLE ^^INVOKE\\S AND HAVE ATTEMPTED TO OPEN THE SAME AREA TWICE.
.B1.I-12
39 ^^DBS\\ FILE NOT FOUND
.B1.I-12
40 ^REQUESTED ACCESS CONFLICTS WITH EXISTING ACCESS. ^IN OTHER
WORDS, THE RESOURCE IS NOT AVAILABLE: (1) YOU ATTEMPT TO OPEN AN AREA
IN A ^^USAGE-MODE\\ INCOMPATIBLE WITH ANOTHER RUN-UNIT'S CONTROL (EG. YOU
TRY ^^EXCL RETRIEVAL\\ AND HE ALREADY HAS IT OPEN WITH
^^PROT UPDATE\\) (2) YOU ATTEMPT TO OPEN THE JOURNAL AND A ^^USAGE-MODE\\ CONFLICT
RESULTS.
(3) YOU ATTEMPT TO DELETE A RECORD RETAINED BY ANOTHER RUN-UNIT.
(4) YOU ATTEMPT TO OPEN AN AREA (OR THE JOURNAL) AND THE FILE-SYSTEM
SIGNALS A FILE PROTECTION ERROR.
.B1.I-12
41 ^NO CHANNEL AVAILABLE...ATTEMPT TO OPEN TOO MANY AREAS
.B1.I-12
42 ^AREA IN UNDEFINED STATE (EG. AFTER CRASH).
^INTERNALLY THIS MEANS THAT ^^FH.STAT\\ IN THE ^^ASR\\ IS LESS THAN 0. ^^DBMEND\\
SHOULD BE USED TO ^^FORCEOPEN\\ THE AREA AND RETURN IT TO A VALID STATE.
.B1.I-12
43 ^AREA IN CREATION STATE.
^THIS CAN HAPPEN TO THE SYSTEM AREA ONLY.
^IT WILL HAPPEN IF THE RUN-UNIT ABORTS AT JUST THE RIGHT TIME DURING
THE VERY FIRST ^^OPEN\\ING OF THE SYSTEM AREA.
^^DBCS\\ RECOGNIZES THIS STATE BY LEAVING ^^FH.STAT\\ EQUAL TO 1
UNTIL INITIALIZATION OF THE SYSTEM AREA IS COMPLETED.
.B1
^IF THIS EXCEPTION IS RETURNED, THE PROGRAMMER SHOULD EITHER RERUN ^^SCHEMA\\ OR, MORE SIMPLY, JUST CREATE A 0-LENGTH FILE WITH ONE OF THE TEXT EDITORS.
.B1.I-12
44 ^ATTEMPT TO CALL A JOURNAL-PROCESSING ENTRY POINT BEFORE THE
JOURNALING SYSTEM HAS BEEN INITIALIZED (BY THE FIRST ^^OPEN\\
THAT REQUIRES JOURNALING).
.PG.B1.I-12
45 ^ATTEMPT TO BACKUP THE DATA BASE WITH ^^JBTRAN\\ WHILE ^^DBCS\\'S ^^CBUU\\ BIT IS SET (SEE 2.1.5.3) OR
WHEN A FILE (IE. JOURNAL OR AREA)
IS SHARED FOR UPDATE IN COMMAND MODE OR FOR ^^JBTRAN(\\GTR 0) WHEN
IT IS SHARED FOR UPDATE IN TRANSACTION MODE.
.B1.I-12
46 ^MAGTAPE SERVICE IS UNAVAILABLE--^^DAEMDB\\ RETURNED A FAILURE CODE.
.B1.I-12
47 ^RESERVED
.B1.I-12
48 ^RESERVED
.B1.I-12
49 ^RESERVED
.B1.I-12
50 ^UNUSED
.B1.I-12
51 ^UNUSED
.B1.I-12
52 ^UNUSED
.B1.I-12
53 ^UNUSED
.B1.I-12
54 ^UNUSED
.B1
^^SYSTEM EXCEPTIONS\\
.B1.I-12
55 ^PSEUDO-EXCEPTION: ^^DBCS\\ TYPES MESSAGE THAT NO SUB-SCHEMA HAS BEEN INITIALIZED YET
.B1.I-12
56 ^INCONSISTENT DATA IN .^^DBS\\ FILE.
^^DBMEND\\ SHOULD BE USED TO RESTORE THE DATA BASE TO A VALID STATE.
^IF THE PROBLEM CAN BE REPRODUCED, IT PROBABLY INDICATES THE PRESENCE OF A ^^DBCS\\ SOFTWARE ERROR.
.B1.I-12
57 ^^DBCS\\ SOFTWARE ERROR PROBABLY
.B1.I-12
58 ^ILLEGAL ARGUMENT WAS PASSED BY USER (OR SETUP BY HOST INTERFACE).
.B1.I-12
59 ^NO MORE CORE-MEMORY AVAILABLE
.B1.I-12
60 ^I/^O ERROR ATTEMPTING TO ACCESS A .^^DBS\\ FILE -- IS
^^DBCS\\ BUG, IS SPURIOUS, OR IS DISK QUOTA EXCEEDED OR FILE PROTECTION FAILURE.
.B1.I-12
61 ^UNABLE TO APPEND TO JOURNAL EITHER IN NORMAL OPERATION OR IN TRYING TO OPEN A JOURNAL FOR APPENDING
(IE. JOURNAL IN AN ABORTED-STATE BUT NOT DESIGNATED AS DONE WITH).
^THIS EXCEPTION TURNS ON ^^CBUU\\ AS WELL AS ^^SUS\\ (SEE 2.1.5.3).
.B1.I-12
62 ^ATTEMPT TO ENTER ^^DBCS\\ AT OTHER THAN ^^JBTRAN\\, ^^SBIND\\, ^^SETDB\\, OR ^^UNSET\\ WHILE THE ^^SUS\\ BIT IS ON (SEE 2.1.5.3).
.PG.B1.I-12
63 ^UNABLE TO COMPLETE RESTORATION OF THE PROPER DATA BASE STATE--EITHER IN ^^JBTRAN\\ OR WHEN INITIALIZING A RUN-UNIT AT THE START OF AN INTERLEAVING-UNIT.
^THIS EXCEPTION TURNS ON ^^CBUU\\ AS WELL AS ^^SUS\\ (SEE 2.1.5.3).
.B1.I-12
64 ^INTERNAL USE ONLY
.B1.I-12
65 ^MONITOR SPACE FOR ^^ENQ\\ ENTRIES EXHAUSTED OR ^^ENQ\\ QUOTA EXCEEDED
.B1.I-12
66 ^^ENQ/DEQ/ENQC\\ FAILURE: USER DOES NOT HAVE ^^ENQ\\ CAPABILITIES SET OR
SOME ^^DBCS\\ PROBLEM
.B1.I-12
67 ^UNABLE TO INITIALIZE MAGTAPE SERVICE--AS OPPOSED TO IT BEING UNAVAILABLE
(EG. ^^SYS INFO\\ NOT RUNNING, ^^DAEMDB\\ NOT RUNNING, OR SOME ^^DBCS\\ PROBLEM)
.B1.I-12
68-99 ^RESERVED
.B2.LM0.F.J
2.1.6##^THE ^DATA ^MANIPULATION ^LANGUAGE
.B2
2.1.6.1 ^THE ^^OPEN\\ ^STATEMENT#-#
^THE ONLY PART OF THE ^^OPEN\\ STATEMENT THAT HAS CHANGED
IS THE ^^USAGE-MODE\\ CLAUSE.
^THE SYNTAX IS NOW:
.B1.C
^^USAGE-MODE [IS] [PROTECTED!EXCLUSIVE] RETRIEVAL!UPDATE\\
.B1
^ALTHOUGH THE SYNTACTIC CHANGE IS SMALL, THREE ^^USAGE-MODE\\S
WILL HAVE BEEN ADDED (THE LAST IN ^V5), AND THE MEANING OF EACH ^^USAGE-MODE\\
HAS BEEN BROUGHT INTO ALIGNMENT WITH THE ^^CODASYL\\ SPEC.
.B1
^^EXCLUSIVE RETRIEVAL\\ MEANS THAT NO ONE ELSE WILL BE ABLE TO ACCESS THE AREA WHILE
YOU HAVE IT ^^OPEN\\ AND THAT YOU WILL NOT BE ABLE TO
^^STORE\\, ^^DELETE\\, ^^MODIFY\\, ^^INSERT\\ OR ^^REMOVE\\.
^CONVERSELY IF ANYONE HAS THE AREA ^^OPEN\\ FOR ANY REASON, YOU WILL
BE DENIED ACCESS.
.B1
^^EXCLUSIVE UPDATE\\ MEANS THAT NO ONE ELSE WILL BE ABLE TO ACCESS THE
AREA WHILE YOU HAVE IT ^^OPEN\\ AND THAT YOU WILL BE ABLE TO EXECUTE ANY VERB.
^CONVERSELY IF ANYONE HAS THE AREA ^^OPEN\\ FOR ANY REASON, YOU
WILL BE DENIED ACCESS.
.B1
^^PROTECTED RETRIEVAL\\ MEANS THAT NO ONE ELSE WILL BE ABLE TO
UPDATE THE AREA WHILE YOU HAVE IT ^^OPEN\\ AND THAT YOU WILL NOT
BE ABLE TO CALL THE UPDATING VERBS LISTED ABOVE.
^CONVERSELY IF ANYONE HAS THE AREA ^^OPEN\\ FOR ^^EXCLUSIVE\\ ACCESS OR ^^PROTECTED UPDATE\\ OR ^^UPDATE\\, YOU WILL BE DENIED
ACCESS.
.B1
^^PROTECTED UPDATE\\ MEANS THAT NO ONE ELSE WILL BE ABLE TO UPDATE THE
AREA WHILE YOU HAVE IT ^^OPEN\\ AND THAT YOU WILL BE ABLE TO EXECUTE
ANY VERB.
^CONVERSELY IF ANYONE HAS THE AREA ^^OPEN\\ FOR ^^EXCLUSIVE\\ ACCESS OR ^^PROTECTED UPDATE\\ OR ^^UPDATE\\, YOU WILL BE DENIED
ACCESS.
.PG.B1
^^RETRIEVAL\\ MEANS THAT ANYONE ELSE WILL BE ABLE TO ACCESS/UPDATE
THE AREA WHILE YOU HAVE IT ^^OPEN\\
AND THAT YOU WILL NOT BE ABLE TO EXECUTE THE UPDATING VERBS
LISTED ABOVE. ^CONVERSELY IF ANYONE HAS THE AREA ^^OPEN\\ FOR ^^EXCLUSIVE\\ ACCESS, YOU WILL BE DENIED ACCESS.
.B1
^^UPDATE\\ MEANS THAT ANYONE ELSE WILL BE ABLE TO ACCESS/UPDATE THE
DATA BASE WHILE YOU HAVE IT ^^OPEN\\ AND THAT YOU WILL BE ABLE TO EXECUTE ANY VERB. ^CONVERSELY IF
ANYONE HAS THE AREA ^^OPEN\\ FOR ^^EXCLUSIVE\\ OR ^^PROTECTED\\ ACCESS,
YOU WILL BE DENIED ACCESS.
.B1
^SOME GENERAL COMMENTS:
.B1
^ALL UPDATE ^^USAGE-MODE\\S ACTUALLY
MODIFY THE ^^.DBS\\ FILE WHEN A BUFFER IS WRITTEN TO DISK. ^A TEMPORARY AREA IS THE ONLY CIRCUMSTANCE
IN WHICH THERE IS AN AFTER-IMAGE DIRECTORY,
IN WHICH CASE A FILE BY THE NAME OF ^^ASSIGN\\ED-NAME.^^TMP\\
IS CREATED.
^SEE SECTION 2.4 NOTE 7, FOR A DESCRIPTION OF THE ORGANIZATION
OF AN AREA ^^.TMP\\ FILE.
.B1
^THE IDEA THAT DIFFERENT ^^USAGE-MODE\\S WERE SYNONYMOUS WITH DIFFERENT
ACCESSING ALGORITHMS WAS A CORRUPTION OF THE ^^USAGE-MODE\\ CONCEPT.
^THE CONCEPT OF ^^USAGE-MODE\\ HAS JUST TWO COMPONENTS:
THE LEVEL OF SHARED ACCESS TO BE ALLOWED AND WHETHER MODIFICATION OF THE
AREA IS TO BE ALLOWED.
.B2
2.1.6.2 ^THE ^^MOVE\\ ^STATEMENT#-#
^THE SYNTAX OF THIS STATEMENT HAS NOT BEEN CHANGED. ^THE CHANGE IS THAT IT WILL NOW ALTER
THE SPECIAL REGISTERS ^^AREA-NAME\\ AND ^^RECORD-NAME\\ TO DESCRIBE THE CURRENCY INDICATOR BEING ^^MOVE\\\D.
^ALSO SEE SUBSECTION 2.2, NOTE 3.
.B2
2.1.6.3 ^^DELET\\ING OR ^^REMOV\\ING ^CURRENT OF "-----"#-#
^THE MEANING OF ^^FIND NEXT\\ OF ^^SET\\
WHEN CURRENT OF SET HAS BEEN ^^REMOVE\\D OR ^^DELETE\\D IS APRIORI
SOMEWHAT AMBIGUOUS. ^CONSEQUENTLY, TO ALLOW THIS AND THE OTHER CURRENCY-BASED OPERATIONS IN THIS SITUATION, SOME CONVENTION MUST BE ESTABLISHED. ^THE
CONVENTION EMPLOYED BY ^^DBMS-10/20\\ ^V4 IS AS FOLLOWS.
.B1
^THE RECORD
WHICH WAS ^^NEXT\\ OF THE ELIMINATED RECORD
BECOMES THE CANONICAL ^^NEXT\\ OF
^^SET\\. ^WHAT THIS MEANS IS THAT,
NO MATTER WHAT HAPPENS TO THE SET (SHORT OF ESTABLISHING A NEW CURRENT OF SET), THIS RECORD
IS ^^NEXT\\ OF ^^SET\\ AND THE RECORD WHICH IS ^^PRIOR\\ TO IT AT ANY POINT
IN TIME IS ^^PRIOR\\ OF ^^SET\\.
.B1
^^DELET\\ING CURRENT OF AREA HAS NO EFFECT ON THE OPERATION OF ^^FIND NEXT\\ OF ^^AREA\\. ^THIS IS THE CASE BECAUSE ^^DBKEY+1\\ AND ^^DBKEY-1\\ ARE INHERENTLY ^^NEXT\\ AND ^^PRIOR\\ OF THE DBKEY BEING DEASSIGNED--WHEREAS
THE IDENTITIES OF ^^NEXT\\ AND ^^PRIOR\\ OF A SET DEPEND ON VALUES IN THE RECORD BEING ELIMINATED.
.PG.B2
2.1.6.4 ^THE ^^JBTRAN\\ ^ROUTINE#-#
^THE TOPIC OF THE ^^JBTRAN\\ ROUTINE HAS BEEN BROACHED IN SUBSECTIONS 2.1.1.3 AND 2.1.5.3 AS WELL. ^TO REITERATE, THE PRIMARY REASON TO CALL
^^JBTRAN\\ IS TO TURN OFF THE ^^SUS\\ FLAG (TURNED ON BY AN UPDATING-EXCEPTION)
BY BACKING UP THE DATA BASE TO THE MOST RECENT TRANSACTION-HEADER.
^TO USE ^^JBTRAN\\ FOR THIS PURPOSE, THE CALLING SEQUENCE IS:
.B1.I8
^^COBOL:#####ENTER MACRO JBTRAN USING 0.
.I8
FORTRAN:###CALL JBTRAN(0)\\
.B1
^THERE IS POTENTIALLY A SECOND REASON TO CALL ^^JBTRAN\\. ^IF AN APPLICATION, FOR ITS OWN REASON, WANTS
TO WIPE OUT ONE OR MORE TRANSACTIONS, IT CAN DO THIS (EVEN THOUGH ^^SUS\\ IS OFF) BY GIVING THE NUMBER
OF TRANSACTIONS IT WISHES TO BACKUP AS THE ARGUMENT TO ^^JBTRAN\\.
(^THUS ^^CALL JBTRAN(1)\\ CAN BE USED IN PLACE OF ^^CALL JBTRAN(0)\\,
BUT THE REVERSE IS NOT TRUE BECAUSE ^^CALL JBTRAN(0)\\ WILL DO NOTHING IF THE ^^SUS\\ BIT WAS ALREADY OFF.)
.B1
^IT IS UNNECESSARY TO DO A ^^JETRAN\\ AFTER CLEANING UP AN ABORTED TRANSACTION
WITH ^^JBTRAN\\ BECAUSE ^^JBTRAN\\ SIMULATES A ^^JETRAN\\ OF THE FOLLOWING
FORM: ^^JETRAN\\ ("^^JBTRAN\\", NUMBER BACKED UP).
.B2
2.1.6.5 ^THE ^^STATS\\ ^ROUTINE#-#
^THERE HAVE BEEN SOME CHANGES TO THE INFORMATION THAT IS OUTPUT WHEN
^^STATS\\ IS CALLED. ^MOST OF THE ^V4 OUTPUT IS SELF-EXPLANATORY,
BUT A COUPLE OF THINGS DO REQUIRE COMMENT.
.B1
^SOME OF THE SIMPLER
ROUTINES IN ^^DBCS\\ HAVE A ^^CPU\\ DURATION WHICH IS AT THE BORDER-LINE OF
RESOLUTION
OF THE ^^RUNTIM UUO\\. ^THIS MEANS THAT THE STATISTICS FOR THESE ENTRY
POINTS MAY BE ERRATIC.
^ALSO THE COST OF GENERATING DETAILED TIMINGS IS RATHER LARGE. ^CONSEQUENTLY
DETAILED TIMING STATISTICS WILL NOT BE GENERATED UNLESS THE
USER SPECIFICALLY REQUESTS THEM. ^HE DOES THIS BY SETTING THE GLOBAL
SYMBOL "^^STATS.\\" NON-0. ^THE SIMPLEST WAY TO ACCOMPLISH THIS IS:
.B1.I5
^^.R LINK\\
.I5
*USER-PROG,^^/DEFINE:STATS.:1\\,ETC/^G
.B1
^THE ^^STATS\\ INFORMATION IS OUTPUT ON A SUB-SCHEMA BASIS. ^IN OTHER WORDS, IF ONE HAS INVOKED TWO SUB-SCHEMAS, ONE
WILL GET TWO SUBSECTIONS OF OUTPUT. ^ALSO EACH FIGURE FOR SUB-SCHEMA RUN-TIME
IS THE RESULT OF SUBTRACTING THE VALUE OF ^^RUNTIM\\ AT THE TIME
EACH SUB-SCHEMA WAS ^^SBIND\\ED FROM ITS CURRENT VALUE.
.B1
"^SAME-PAGE DATA BASE ACCESSES" IS A MEASURE
OF INTRA-PAGE LOCALIZATION. ^IT IS INCREMENTED BY 1 EACH TIME THE PAGE
ACCESSED IS THE SAME PAGE AS WAS ACCESSED THE PRECEDING TIME.
.B1
^LASTLY, READS OF A TEMPORARY AREA'S DIRECTORY PAGE ARE INCLUDED
IN THE COUNT OF PAGES ACTUALLY READ FROM DISK.
.PG.B2
2.1.6.6 ^PASSING ^STRINGS TO ^^DBCS\\#-#
^THERE ARE SEVERAL ENTRY POINTS WHICH TAKE STRING ARGUMENTS (EG. ^^JSTRAN, JRTEXT\\). ^PARTICULARLY FOR THE BENEFIT OF ^^FORTRAN\\ USERS, THE CONVENTION
FOR HOW TO INTERPRET STRING ARGUMENTS
HAS BEEN EXPANDED.
^IN PARTICULAR, ^V3 ALLOWED JUST TWO WAYS FOR ^^COBOL\\ (EG. ^^ENTER MACRO JSTRAN USING "MYTRAN",TCOUNT\\ OR ^^ENTER MACRO
JSTRAN USING TRAN-NAME,TCOUNT\\ WHERE ^^TRAN-NAME\\ APPEARED IN
THE ^^DATA DIVISION\\ WITH ^^PIC X(30)\\)
AND ONLY ONE WAY FOR ^^FORTRAN\\ (EG. ^^CALL JSTRAN('MYTRAN',I)\\).
^IN ^V4, THESE PLUS SEVERAL OTHER WAYS WILL BE POSSIBLE (SEE EXAMPLE
BELOW).
.B1.LM5.TS35.NF.NJ
^^DATA TYPE\\(^^ARG\\ WORD,BITS 9-12) ^^INTERPRETATION\\
------------------------------------------------
UNSPECIFIED (IE. 0) STRING POINTER
^^FORTRAN LOGICAL\\ DATA-VARYING
^^INTEGER/COMP\\ 5 CHARACTERS
UNDEFINED
^^REAL/COMP-1\\ 5 CHARACTERS
UNDEFINED
UNDEFINED
UNDEFINED
^^REAL*8\\ 10 CHARACTERS
^^DOUBLE COMP\\ STRING POINTER
UNDEFINED
UNDEFINED
^^COMPLEX\\ STRING POINTER
^^COBOL\\ STRING STRING POINTER
UNDEFINED
^^FORTRAN\\ LITERAL ^^ASCIZ\\
.B1.LM0.F.J
^A STRING POINTER IS A TWO-WORD QUANTITY:
ITS FIRST WORD IS A BYTE POINTER, AND THE RIGHT HALF OF THE SECOND WORD IS THE NUMBER OF CHARACTERS IN THE STRING.
^A DATA-VARYING STRING IS AN ACTUAL STRING IN WHICH THE LENGTH IS STORED IN
THE WORD PRECEDING THE STRING. ^AN ^^ASCIZ\\ STRING
IS A STRING THAT IS TERMINATED BY A 0 BYTE.
.B1
^FOR EXAMPLE, LET A DATA-VARYING STRING BE USED AS FOLLOWS:
.B1.LM5.TS5.NF.NJ
^^LOGICAL DUMARR(7)
EQUIVALENCE (DUMARR(1),DVLEN),(DUMARR(2),TRNAME)
DATA DVLEN/30/
TYPE 101
.I-4
101 FORMAT(' ENTER TRANSACTION NAME')
ACCEPT 102,TRNAME
.I-4
102 FORMAT(6A5)
.I8
:
.I8
:
CALL JSTRAN(TRNAME,I)\\
.PG.B2.LM0.F.J
2.1.7##^THE ^HOST-LANGUAGE ^INTERFACE
.B2
2.1.7.1 ^COMPILE-TIME/RUN-TIME ^^.SCH\\ ^FILE ^COMPATIBILITY#-#
^THE POSSIBILITY OF COMPILE-TIME/RUN-TIME ^^.SCH\\ FILE
INCOMPATIBILITY WILL BE MADE EXPLICIT. ^THIS WILL BE DONE
BY INCREMENTING AN EDIT NUMBER WITHIN THE ^^.SCH\\ FILE
EACH TIME ^^SCHEMA\\ IS RUN AND BY HAVING ^^FORDML/COBOL\\ PLACE THE VALUE THAT THEY SEE IN THE ARGUMENT LIST
OF ^^SBIND\\.
^THEN AT RUN-TIME, ^^SBIND\\ WILL COMPARE THE EDIT-NUMBER PASSED
TO IT AND THE ACTUAL EDIT NUMBER OF THE ^^.SCH\\ FILE.
^IF THESE TWO NUMBERS DIFFER, ^^ERROR-STATUS\\ WILL BE SET TO
"#1500" (USUALLY... SEE SUBSECTION 2.1.5.4, EXCEPTION 00 FOR DETAILS).
.B1
(^NOTE THAT ^^INTERCEPT/NOTE\\ CAN BE USED TO DETECT THIS CONDITION, IF THAT IS DESIRED).
.B2
2.1.7.2 ^RECORD/DATA ^FORMATS IN THE ^HOST-LANGUAGE#-#
^THE ORDER OF THE DATA-NAMES IN THE ^^UWA\\ WILL
ALWAYS BE THE SAME AS IT IS IN THE SCHEMA ^^DDL\\. ^IN OTHER
WORDS, THE CALC KEYS WILL NOT BE MOVED TO THE FRONT OF A RECORD. ^ALSO ^^AREA-ID\\S, ^^DIRECT\\ KEYS, AND ^^ALIAS\\ES
WILL NOT INCORRECTLY BE MADE PART OF THE RECORD WITH WHICH THEY ARE ASSOCIATED. ^ALSO SEE SUBSECTION 2.2, NOTES 4 AND 5.
.B2
2.1.7.3 ^^DBCS\\ SYMBOLS THAT ARE USER-REFERENCABLE#-#
^THIS SET OF NAMES IS IMPORTANT FOR TWO REASONS. ^IT IDENTIFIES
THE ROUTINES FOR USE IN EXPLICIT CALLS, AND IT IDENTIFIES WHICH
NAMES THE PROGRAMMER CANNOT USE FOR NAMING HIS OWN ROUTINES.
.B1
^A STARRED (*) NAME IDENTIFIES A SYNONYM FOR THE IMMEDIATELY
PRECEDING ENTRY POINT NAME.
^^KEY X\\ IDENTIFIES THE NEGATIVE NUMBER ASSOCIATED WITH A KEYWORD, AS DESCRIBED IN SECTION 2.4, NOTE 2. ^A DATA BASE WORD (IE.
AREA, SET, RECORD, DATA) REFERS TO THE NAME ^^ID\\ (SEE SECTION 2.4, NOTE 1) FOR THE PARTICULAR DATA-BASE-NAME OR THE STRING THAT WOULD
REPRESENT THAT NAME (IE. ^^"REC1"\\ FOR ^^REC1\\).
.B1.LM18.TS18.I-13
^^CLOSED (KEY ALL)
.I-13
CLOSED (KEY AREA\\, AREA-LIST)
.I-13
^^DELETR (0!KEY SELECT!KEY ALL!KEY ONLY)\\
.I-13
^^FIND1 (\\RECORD!0, ^^USING\\-VALUE)
.I-13
^^FIND2 (\\SET!0, CURRENCY, ^^KEY\\ CURRENCY-KEYWORD)
.I-13
^^FIND3 (KEY\\ RELATIVE, RECORD!0, AREA!SET, ^^KEY AREA!KEY SET\\)
.I-13
^^FINDO\\ (INTEGER, RECORD!0, AREA!SET, ^^KEY AREA!KEY SET\\)
.I-13
^^FIND4 (\\SET)
.I-13
^^FIND5 (KEY DUPLICATES\\!0, RECORD)
.I-13
^^GETS\\ (RECORD [,DATA-LIST]) ! (0)
.I-13
^^*GET\\
.I-13
^^INSERT\\ (RECORD!0, SET-LIST)
.I-13
^^*INSRT\\
.I-13
^^MODIF\\ (SAME-AS-^^GET\\)
.I-13
^^*MODIFY\\
.I-13
^^MOVEC\\ (CURRENCY, ^^KEY\\ CURRENCY-KEYWORD, RESULT)
.I-13
^^OPEND (KEY RETR!KEY UPDATE, 0!KEY PROT!KEY EXCL\\, PRIVACY-KEY, ^^KEY ALL\\!AREA-LIST)
.I-13
^^REMOVE\\ (SAME-AS-^^INSERT\\)
.I-13
^^*REMOV\\
.I-13
^^STORE\\ (RECORD)
.I-13
^^*STORED\\
.I-13
^^SBIND\\ (SCHEMA,EDIT, SUBSCHEMA,SS-MASK, ^^SYSCOM\\-ADDRESS)
.I-13
^^BIND\\ (RECORD,DATA-ADDRESS-LIST)
.I-13
^^EBIND\\ (0,^^DBMS-NULL\\)
.B1.LM0.F.J
^ADDITIONALLY, THE ^^FIND\\S AND ^^STORE\\ CAN HAVE APPENDED A
^^SUPPRESS\\ LIST: ^^KEY ALL!KEY AREA!KEY RECORD!KEY SET\\!SET,...
.B1
^THE OTHER UNDOTTED NAMES ARE:^^
.B1.LM5.TS16,28,39.NF.NJ
SETDB UNSET SAVESS JMNAME
JMAFT JMBEF JMBOTH JMNONE
JBTRAN JSTRAN JETRAN JRSYNC
EMPTY *SETCON MEMBER *RECMEM
OWNER *RECOWN TENANT *RECMO
STATS\\
.B2.LM0.F.J
2.1.7.4 ^VALIDATING DATA AGGREGATES#-#
^WHEN THE ^^SIZE\\ CLAUSE IS USED IN A DATA-NAME ENTRY, THE PROGRAMMER
HAS TO TELL ^^SCHEMA\\ HOW MUCH SPACE TO RESERVE
IN THE HOST-LANGUAGE'S ^^UWA\\.
^THERE ARE NO SERIOUS PITFALLS ASSOCIATED WITH PROVIDING EXTRA SPACE, BUT TO PROTECT THE PROGRAMMER
FROM LOSING DATA, ^^DBCS\\ WILL SIGNAL EXCEPTION
32 WHEN INSUFFICIENT SPACE IS PROVIDED.
.B1
(^HOWEVER
THERE IS NO INTRINSIC WAY TO DETERMINE THE SIZE OF A DATA-NAME AT RUN-TIME (WITHOUT PASSING A PROHIBITIVE ADDITIONAL AMOUNT OF INFORMATION DURING BINDING).
^THE BEST ^^DBCS\\ CAN DO IS CALCULATE HOW FAR APART TWO CONSECUTIVE DATA-NAMES ARE.
^UNFORTUNATELY, WHEN A REFERENCED NAME (EG. ^^DIRECT\\ KEY) IS SHARED BETWEEN TWO RECORD TYPES OR A ^^FORTRAN\\ APPLICATION DOES NOT HAVE PSEUDONYMS FOR ALL DATA-NAMES,
DATA IS NOT NECESSARILY SEQUENTIAL. ^IN OTHER WORDS, THE VALIDATION CHECK ^^DBCS\\ MAKES IS NEGATED UNDER THESE TWO CIRCUMSTANCES.)
.B2
2.1.7.5 ^LOADING ^^DBMS\\ APPLICATIONS#-#
^^DBMS\\ APPLICATIONS ARE LOADED IN THE SAME FASHION AS ANY OTHER
^^COBOL\\ OR ^^FORTRAN\\ PROGRAM. ^THIS IS TRUE WHETHER OR NOT
ONE IS USING A PRIVATE LIBRARY OR A SYSTEM DEFAULT LIBRARY. ^FOR
EXAMPLE, .^^LOAD COBPRG\\ AND .^^LOAD FORPRG, MYFLIB /SEARCH\\.
.B2
2.1.8 ^THE ^^DBINFO\\ UTILITY
.B1
^THIS PROGRAM CAN BE USED TO DUMP DATA FROM A DATA BASE,
MAKE A CROSS-REFERENCE OF THE NAMES IN A SUB-SCHEMA, AND CALCULATE CERTAIN STATISTICAL INFORMATION ABOUT THE STATE OF A DATA BASE.
.B1
^IT IS SIMILAR TO ^^DBMEND\\ IN THAT ITS COMMAND INTERFACE IS VERB ORIENTED
AND HAS THE SAME LEXICAL RULES (EG. NAMES CONTAINING DASHES MUST BE ENCLOSED WITH QUOTE MARKS).
^ALSO IT SHARES SOME OF THE SAME "BACKGROUND" COMMANDS SINCE,
IN BOTH CONTEXTS, THE USER HAS TO SELECT A SCHEMA AND OPEN AND CLOSE AREAS.
.B2
2.1.8.1 ^^APPEND/SUPERSEDE\\ COMMANDS#-#
^THIS COMMAND SPECIFIES THE DESTINATION FILE SPEC FOR ANY ^^INFO\\ TO BE DISPLAYED. ^ITS SYNTAX IS SIMPLY:
.B1.C
^^APPEND!SUPERSEDE\\ FILE-SPEC
.B1
^IF ^^APPEND\\ IS SPECIFIED, ANY EXISTING INFORMATION IN THE FILE WILL NOT BE OVERWRITTEN. ^IF ^^SUPERSEDE\\ IS SPECIFIED, THE FILE WILL BE OVERWRITTEN.
.B2
2.1.8.2 ^^CLOSE\\ COMMAND#-#
^THIS COMMAND IS USED TO ^^CLOSE\\ ONE OR MORE AREAS THAT THE PROGRAMMER HAS ^^OPEN\\ED. ITS SYNTAX IS:
.B1.C
^^CLOSE ALL\\ ! AREA-NAME[,AREA-NAME...]
.B1
2.1.8.3 ^^DISPLAY\\ COMMAND#-#
^THIS IS THE PRIMARY ACTION COMMAND. ^EACH TIME THE USER GIVES A
^^DISPLAY\\ COMMAND HE CAUSES THE CURRENT ^^INFO\\ OUTPUT FILE TO BE APPENDED TO.
^THE SYNTAX FOR THIS COMMAND IS:
.B1.LM5.NF.NJ
^^DISPLAY CREF ! MAP ! \\FREE ! DATA ! USAGE
##USAGE-->^^USAGE\\ [:SET-NAME]
##DATA#-->^^DATA\\ [:SET-NAME]
##FREE#-->^^FREE\\ [:INTEGER]
.B1.LM0.F.J
^IF ^^USAGE\\ IS NOT FOLLOWED BY A SET-NAME, THE NUMBER OF RECORD OCCURRENCES FOR EACH RECORD TYPE IS
PRINTED FOR EACH OBJECT-PAGE (SEE 2.1.8.6).
^IF A SET-NAME ARGUMENT IS PRESENT, EACH OWNER RECORD OCCURRENCE WHICH
IS ON AN OBJECT PAGE IS DESCRIBED: THE
NUMBER OF MEMBER RECORDS ON THE SAME PAGE AS THE
OWNER AND THE NUMBER IN THE ENTIRE SET OCCURRENCE ARE DISPLAYED.
.B1
^IF ^^DATA\\ IS NOT FOLLOWED BY A SET-NAME, EACH RECORD OCCURRENCE ON AN OBJECT PAGE AND
IN THE SUB-SCHEMA IS DUMPED (IE. EACH OF ITS FIELDS IS DISPLAYED). ^EMPTY PAGES DO NOT PRINT ANY INFORMATION.
^IF ^^DATA\\ IS FOLLOWED BY A SET-NAME, THE ^^NEXT\\ POINTERS OF EACH
OBJECT SET OCCURRENCEUSAGE\\) ARE FOLLOWED, AND THE RECORDS ARE DUMPED IN THAT ORDER.
^A SET OCCURRENCE IS AN OBJECT OF THE COMMAND IF ITS OWNER RECORD IS
ON AN OBJECT PAGE (SEE 2.1.8.6).
.B1
^^FREE\\ NOT FOLLOWED BY AN "INTEGER" IS EQUIVALENT TO ^^FREE\\ FOLLOWED BY 0. ^^DISPLAY FREE\\ WILL CONSIDER ANY PAGE WHICH HAS LESS THAN
"INTEGER" WORDS FREE TO BE FULL. ^FOR EACH PAGE WHICH IS NEITHER FULL NOR EMPTY: THE PAGE NUMBER, THE COUNT OF FREE WORDS, AND SOME NUMBER (1/10-FREE-WORDS)
ASTERISKS (*) WILL BE PRINTED.
^ADDITIONALLY EMPTY (OR FULL) PAGE-SEQUENCES (AT LEAST 3 CONSECUTIVE PAGES) WILL BE DISPLAYED AS "(EMPTY PAGES) LOW - HIGH".
.B1
^THE ^^CREF\\ OPTION CAUSES ^^DBINFO\\ TO GENERATE AN ALPHABETICAL
LISTING OF THE SYMBOLS IN THE SUB-SCHEMA: WHAT EACH IS, PLUS HOW AND WHERE EACH IS USED.
.PG.B1
^THE ^^MAP\\ OPTION CAUSES ^^DBINFO\\ TO GENERATE A PICTORIAL REPRESENTATION OF EACH RECORD TYPE IN THE SUB-SCHEMA. ^IT SHOWS
WHICH WORDS CONTAIN SET (AND CALC) LINKAGES AND EXACTLY WHAT
USER DATA IS IN EACH WORD. ^EACH BYTE OF USER DATA IS REPRESENTED
BY AN ASTERISK. ^IN OTHER WORDS, THERE CAN BE AT MOST 6, 5, AND 4
ASTERISKS PER WORD IN A ^^SIXBIT\\, ^^ASCII\\ AND ^^EBCDIC\\ RECORD.
^CONVERSELY, FULL-WORD BYTES (IE. IN COMPUTATIONAL NUMERIC ITEMS)
ARE REPRESENTED BY ONE LEFT-JUSTIFIED ASTERISK.
^LASTLY, THE INDEX ASSOCIATED WITH EACH DATA-NAME IN THE MAP CORRESPONDS
TO THE INDEX PRINTED TO THE LEFT OF ITS VALUE
IN THE DATA DUMP.
.B2
2.1.8.4 ^^OPEN\\ COMMAND#-#
^THIS COMMAND ^^OPEN\\S EACH SPECIFIED AREA FOR ^^PROTECTED RETRIEVAL\\. ^ITS SYNTAX IS:
.B1.C
^^OPEN ALL\\![AREA-NAME[,AREA-NAME]] [:PRIVACY-KEY]
.B1
^IN OTHER WORDS, IT ^^OPEN\\S ALL AREAS IN THE RELEVANT SUB-SCHEMA OR
JUST THOSE EXPLICITLY SPECIFIED. ^EACH AREA NAMED (EXPLICITLY OR IMPLICITLY) IN THE COMMAND MUST
HAVE THE SAME PRIVACY-LOCK VALUE.
^THE PRIVACY-KEY PHRASE IS REQUIRED ONLY IF THE AREAS HAVE A NON-NULL PRIVACY LOCK.
.B2
2.1.8.5 ^^PAGES\\ COMMAND#-#
^THIS COMMAND ENABLES THE USER TO
CONTROL THE PAGES TO WHICH A ^^DISPLAY\\ COMAND WILL APPLY.
^ITS SYNTAX IS:
.B1.LM5.NF.NJ
^^PAGES\\ [RANGE-LIST]
##RANGE-LIST#-->RANGE-TUPLE [,RANGE-LIST]
##RANGE-TUPLE-->INTEGER ! INTEGER-INTEGER ! AREA-NAME
.B1.LM0.F.J
^IF NO RANGE-LIST IS SPECIFIED, THE RANGE-LIST IS DEFAULTED TO THE
LIST OF ^^OPEN\\ AREAS.
^AND SPECIFYING AN AREA AS A RANGE-TUPLE IS EQUIVALENT TO SPECIFYING
AREA-FIRST-PAGE - AREA-LAST-PAGE.
^LASTLY, SPECIFYING A SINGLE INTEGER, SAY (N), IS THE SAME AS
SPECIFYING N-N.
^IN OTHER WORDS, ^^PAGES\\'
ARGUMENT IS A LIST OF ZERO OR MORE (MAXIMUM 16) PAGE RANGES. ^FOR EXAMPLE, ^^PAGES\\ 4,7,13-25 WOULD LOCALIZE FUTURE
^^DISPLAY\\ COMMANDS TO PAGES 4, 7, AND 13 THRU 25.
.B2
2.1.8.6 ^^SCHEMA\\ COMMAND#-#
^THIS COMMAND IDENTIFIES THE SCHEMA FILE TO ^^DBINFO\\. ^ITS SYNTAX IS SIMPLY:
.B1.C
^^SCHEMA\\ SCHEMA-NAME
.B2
2.1.8.7 ^^SS\\ COMMAND#-#
^THIS COMMAND IDENTIFIES THE SUB-SCHEMA THAT WILL BE THE CONTEXT FOR ^^DBINFO\\'S EVALUATION OF FUTURE ^^DISPLAY\\
COMMANDS.
^IT IS AN ACTION COMMAND; THE SUB-SCHEMA SPECIFIED WILL BE BOUND BY ^^DBINFO\\ EACH TIME THE COMMAND IS GIVEN.
(^NOTE: USE OF THIS COMMAND DOES CAUSE THE RUN ^^ID\\ IN THE ^^.SCH\\ FILE TO BE INCREMENTED BY 1).
.PG.B1
^UNDERSTANDING THIS CONCEPT IS CRUCIAL TO EFFECTIVE USE
OF ^^DBINFO\\. ^BY JUDICIOUS SUB-SCHEMA SPECIFICATION, ONE CAN PRECISELY CONTROL WHAT RECORD TYPES ARE ^^DISPLAY\\ED, WHAT DATA-NAMES WITHIN THE RECORDS
ARE ^^DISPLAY\\ED, AND WHAT AREAS CONSTITUTE ^^ALL\\.
^THE SYNTAX OF THIS COMMAND IS:
.B1
.CENTER
^^SS\\ [SUB-SCHEMA-NAME]
.B1
^IF THE SUB-SCHEMA-NAME IS ABSENT, THE "IMPROPER" SUB-SCHEMA
IS IDENTIFIED; THAT IS, THE SUB-SCHEMA WHICH WOULD CORRESPOND
TO THE ENTIRE (CURRENT) SCHEMA. ^HOWEVER, REPEATING
THIS FORM OF THE ^^SS\\ COMMAND WITHIN ONE RUNNING OF ^^DBINFO\\ WILL
MERELY RESET THE CURRENT SUB-SCHEMA TO THE ORIGINAL "IMPROPER"
SUB-SCHEMA.
.B2.LM0
2.2##^FUNCTIONAL ^INCOMPATIBILITIES
.B1
^THE LIST OF FUNCTIONAL INCOMPATIBILITIES BETWEEN ^V3 AND ^V4 OF ^^DBMS-10/20\\ IS AS FOLLOWS:
.B1.LM9.I-4
1.##^ONLY 02-DATA-NAMES CAN APPEAR IN A DATA-NAME ENTRY IN A SCHEMA, SEE 2.1.2.2 AND 2.1.3.
.B1.I-4
2.##^A DATA-NAME ENTRY IN A SCHEMA MAY NOT CONTAIN A ^^USAGE COMP\\-X PHRASE,
SEE 2.1.2.2.
.B1.I-4
3.##^SUCCESSFUL ^^FIND\\S AND ^^STORE\\S WILL NO LONGER SET UP THE
SPECIAL REGISTERS ^^AREA-NAME\\ AND ^^RECORD-NAME\\; ONLY THE ^^MOVE\\ VERB WILL--SEE SUBSECTION 2.1.6.2.
.B1.I-4
4.##^CALC KEYS WILL APPEAR IN A HOST-LANGUAGE PROGRAM JUST AS THEY DO IN A ^^RECORD/DATA\\ ENTRY
IN A SCHEMA, SEE SUBSECTION 2.1.7.2.
(^THIS INCOMPATIBILITY IS TRANSPARENT TO ALL APPLICATIONS EXCEPT THOSE ^^COBOL\\ APPLICATIONS THAT DO A ^^MOVE\\ RECORD-NAME ^^TO\\ TEMP-NAME.)
.B1.I-4
5.##^^AREA-ID\\S, ^^DIRECT\\ KEYS, AND ^^ALIAS\\ES ARE DECLARED AS 01 NAMES IN ^^COBOL\\, SEE SUBSECTION 2.1.7.2.
^THIS IS NOT TRULY A CHANGE BUT A FIX FOR A BUG. ^UNFORTUNATELY IT
AFFECTS USAGE OF THE ^^ACCESS\\ STATEMENT IN ^^COBOL\\. ^IF YOU HAD BEEN
PASSING A RECORD-NAME TO AN ^^ACCESS\\ING SUBPROGRAM, AND EXPECTED ITS ^^DIRECT\\ KEY OR ^^AREA-ID\\ OR AN^^ALIAS\\ TO
BE IMPLICITLY PASSED, THE CALL WILL HAVE TO BE ALTERED TO MAKE EXPLICIT
REFERENCE TO THE ANCILLARY VARIABLE.
.B1.I-4
6.##^THE ACCESSING ALGORITHM
FOR ^^PROTECTED UPDATE\\ WILL NO LONGER INVOLVE WHAT IS CALLED AN ^^.RCV\\ FILE; AREAS ^^OPEN\\ FOR ^^PROTECTED UPDATE\\ WILL BE
UPDATED IN PLACE. ^ALSO
IF ONE PROGRAM HAS AN AREA ^^OPEN\\ FOR ^^PROTECTED UPDATE\\ AND ANOTHER
HAS IT ^^OPEN\\ FOR ^^RETRIEVAL\\, THE RETRIEVER (AND/OR UPDATER) IS RESPONSIBLE
FOR NOT GETTING MESSED UP BY THE CHANGES THE UPDATER MAKES. ^IF THIS IS
A PROBLEM, THE RETRIEVER SHOULD ^^OPEN\\ FOR ^^PROTECTED RETRIEVAL\\.
^FOR A THOROUGH DISCUSSION OF ^^USAGE-MODE\\S SEE SUBSECTION 2.1.6.1.
.B1.I-4
7.##^SUB-SCHEMA-NAMES MUST BE UNIQUE ACROSS ANY RUN-UNIT WHICH ^^INVOKE\\S MORE THAN ONE SUB-SCHEMA.
^THIS WAS ALREADY REQUIRED FOR ^^FORTRAN\\ USAGE AND IS BEING GENERALIZED FOR THE SAKE OF SIMPLICITY AND ^^DBCS\\ EFFICIENCY.
.B1.I-4
8.##^IF THE OWNER OF A SET IS TO BE ^^SELECT\\ED THRU THE ^^LOCATION MODE OF OWNER\\ PHRASE AND ITS ^^LOCATION MODE\\ IS ^^VIA\\,
THE ^^SET\\ ENTRY OF THE ^^VIA\\
SET MUST PRECEDE THE ^^SET\\ ENTRY IN WHICH THE RECORD IN QUESTION IS THE
OWNER.
(^THIS SOUNDS MUCH WORSE THAN IT IS.
^IF ONE PLACES ^^SET\\ ENTRIES THAT ARE NEARER THE ROOT OF
A DATA BASE STRUCTURE BEFORE ^^SET\\ ENTRIES
THAT ARE FARTHER FROM THE ROOT, ONE WILL NEVER HAVE A PROBLEM.)
.B1.I-4
9.##^THE NAME (AND DEVICE AND DIRECTORY) OF THE ^^.SCH\\ FILE WILL BE DERIVED FROM THE (POSSIBLY IMPLICIT) OUTPUT FILE SPEC
GIVEN ON THE COMMAND LINE TO ^^SCHEMA\\.
^EARLIER VERSIONS USED THE SCHEMA-NAME IN THE ^^SCHEMA\\ STATEMENT
FOR THIS PURPOSE--THIS NAME IS NOW IGNORED.
.B1.I-5
10.##^THE ^^PRINTA\\ ENTRY POINT NO LONGER EXISTS WITHIN ^^DBCS\\. ^ITS FUNCTIONALITY IS
SUBSUMED BY ^^DBINFO\\.
(^SEE 2.1.7.3 FOR THE COMPLETE LIST OF ^V4 ENTRY POINTS).
.B1.I-5
11.##^A ^^BIND\\ING FAILURE NOW RETURNS AN EXCEPTION RATHER THAN ^^EXIT\\ING, SEE 2.1.1.4 AND 2.1.5.4.
.B1.I-5
12.##^EXCEPTION 34 MAY HAPPEN TO AN EXISTING APPLICATIONS PROGRAM, SEE 2.1.5.4. (^THE
SOLUTION IS TO REMOVE THE SET-NAME FROM THE SUB-SCHEMA OR ADD THE OWNER RECORD-TYPE TO THE SUB-SCHEMA.)
.B1.I-5
13.##^THE EXCEPTION NUMBERS ABOVE 30 BEAR NO RELATIONSHIP WHATSOEVER TO
WHAT THEY WERE IN EARLIER VERSIONS, SEE 2.1.5.4.
.B1.I-5
14.##^PRIVACY LOCKS/KEYS WILL BE TRUNCATED TO 5 CHARACTERS RATHER
THAN 6 CHARACTERS.
.B1.I-5
15.##^THE EXACT MECHANISM FOR HANDLING ^^REMOVE\\D/^^DELETE\\D CURRENCY INDICATORS IN EARLIER VERSIONS IS UNCLEAR.
^SEE SUBSECTION 2.1.6.3 FOR
A DESCRIPTION OF HOW ^V4 HANDLES THIS SITUATION.
.B1.I-5
16.##^IN CASES WHERE A SCHEMA-DEFINED NAME IS ALWAYS SYNTACTICALLY PAIRED WITH A KEYWORD DESIGNATING THE TYPE OF NAME IT IS,
^^DBCS\\ WILL IGNORE THE KEYWORD. ^FOR EXAMPLE, IF ONE SAID ^^MOVE STATUS FOR REC1 RECORD TO X\\, ^^DBCS\\ WOULD DETERMINE
THAT ^^REC1\\ WAS A RECORD-NAME FROM THE
ITS SYMBOL BLOCK. ^IN OTHER WORDS,
KEYWORDS IN THIS CONTEXT SERVE PURELY AS VISUAL DOCUMENATION.
.B1.I-5
17.##^THE ^V4 MECHANISM FOR EXPLICITLY SPECIFYING
THE BUFFER COUNT OF AN AREA IS DESCRIBED IN SUBSECTION 2.1.1.5.
.B1.I-5
18.##^ON A ^^SCHEMA\\ COMMAND LINE, "^A." DOES NOT == "A.DDL", ONLY "A" OR "A.DDL" DOES.
.B1.I-5
19.##^TWO STATEMENTS MAY NOT BE ON THE SAME LINE IN A ^^DDL\\ PROGRAM.
.B2.LM0
2.3##^FUNCTIONAL ^DEFINITION OF ^^DBMS-V5\\
.B2
2.3.1##^V3 --> ^V5 CONVERSION UTILITY
.B1
^THIS UTILITY IS A PROGRAM NAMED ^^V3TOV5\\--AND BY DEFINITION IT WILL BE USEFUL ONLY TO EXISTING ^^DBMS-V3\\ USERS. ^THIS PROGRAM IS USED ON-LINE
BY GIVING A SEQUENCE OF COMMANDS WHICH IDENTIFIES (BY ITS SCHEMA) THE DATA BASE TO BE CONVERTED
AND REQUESTS INITIATION(CONTINUATION) OF THE ACTUAL CONVERSION.
.B2
2.3.1.1 ^CONVERSION ^STEPS AND ^^V3TOV5\\ ^USAGE#-#
^A SUCCESSFUL CONVERSION WILL ALWAYS CONFORM TO THE FOLLOWING SEQUENCE OF USER
ACTIONS. ^ALSO IT IS SUGGESTED (ALTHOUGH NOT REQUIRED) THAT YOU KEEP AROUND YOUR OLD ^^DDL\\ FILE AND GIVE YOUR
^V5 ^^DDL\\ PROGRAM AN EXTENSION OF ^.DDN\\ UNTIL YOU HAVE COMPLETED YOUR CONVERSION.
.B1.LM9.I-4
1.##^READ SECTION 4.1. ^THIS SECTION CONTAINS INSTRUCTIONS ON HOW TO CHANGE ^V3 SOURCE FILES INTO VALID ^V4/5 FILES.
(^IT IS UNLIKELY ANY FILE OTHER THAN THE .^^DDL\\ FILE WILL HAVE TO BE
CHANGED).
.B1.I-4
2.##^RUN ^^SCHEMA\\ (^V5) AND SPECIFY THE /^^CONVERT\\ SWITCH:
.B1.I5
^^R SCHEMA
SCHEMA-NAME^^.DDN/CONVERT\\
.B1
^THIS WILL CAUSE ^^SCHEMA\\ TO GENERATE ALL THE FILES IT WOULD NORMALLY
GENERATE, BUT SUCH THAT THE 3RD LETTER OF EACH FILE'S EXTENSION WILL BE "^N".
^IN OTHER WORDS, IT WOULD CREATE A .^^SCN\\ FILE AND SOME NUMBER OF ^^.DBN\\
FILES. ^THIS IS DONE TO FACILITATE CONCURRENT EXISTENCE OF THE OLD AND NEW COPIES OF THE DATA BASE.
.B1.I-4
3.##^THE ACTUAL CONVERSION PROTOCOL IS AS FOLLOWS:
.B1.LM29.TS29.NF.NJ.I-20
^^R V3TOV5 ;START UP THE PROGRAM
.I-20
SCHEMA \\SCHEMA-NAME ^^;IDENTIFY THE DATA BASE
;BEING CONVERTED
.I-20
TRACE \\INTEGER^^ ;IF ABSENT, TRACE 10 IS SIMULATED.
;ALLOWS CONTINUATION OF CONVERSION
;AFTER A CRASH BY TYPING
;[COMPLETED PAGE \N]
;EVERY \\INTEGER^^ PAGES.
;ALSO [COMPLETED AREA \\NAME^^]
;MESSAGES ARE TYPED.
.I-20
PAUSE ;OPTIONAL, IF PRESENT IT CAUSES
;V3TOV5 TO EXIT EACH TIME IT FINISHES
;PROCESSING AN AREA, THEREBY ALLOWING
;THE USER TO DO SOMETHING (EG.
;CHANGE DISKS) BEFORE RESUMING--BY
;TYPING CONTINUE.
.I-20
EXPUNGE ;REQUEST TO EXPUNGE DELETED RECORDS
;(NECESSARY IF THERE ARE ANY
; PARTIALLY DELETED RECORDS IN THE
; DATA BASE--SEE 2.3.1.2.2)
.I-20
START ;START (OR CONTINUE) EXPUNGE
.I-20
V3TOV5 ;REQUEST TO MAP V3 DATA
;INTO THE .DBN FILES
.I-20
START ;START (OR CONTINUE) THE MAPPING
.I-20
REKEY ;REQUEST TO FORMAT THE NEW DATA BASE'S
;USER-KEY (IE. SORT/CALC) CHAINS
.I-20
START ;START (OR CONTINUE) THE REKEYING\\
.B1.LM9.F.J.I-4
4.##^DELETE ALL THE OLD FILES (IE. THE .^^DBS\\ FILES AND THE .^^SCH\\ FILE).
.B1.I-4
5.##^RENAME ^^*.DBN \T\O *.DBS\\ AND SCHEMA-NAME^^.SCN \T\O \\SCHEMA-NAME^^.SCH\\
.B2.LM0
2.3.1.2 ^UNDERSTANDING THE ^CONVERSION ^PROCESS
.B1
2.3.1.2.1 ^PURPOSE OF ^MULTIPLE ^CONVERSION ^STEPS#-#
^THE CONVERSION PROCESS IS DIVIDED INTO PHASES (^^EXPUNGE, V3TOV5, REKEY\\) FOR TWO
REASONS. ^THE FIRST REASON IS THAT THE DATA BASE WILL BE OUT OF
COMMISSION LESS COMPLETELY--EVEN THOUGH THE TOTAL TIME OF CONVERSION
IS PROBABLY INCREASED SLIGHTLY. ^THIS IS BECAUSE THE POSSIBILITY OF
INTERLEAVING NORMAL USAGE IS MUCH HIGHER THAN OTHERWISE. ^THE
RULES FOR INTERLEAVING NORMAL USAGE ARE AS FOLLOWS:
.B1.LM9.I-4
1.##^DURING THE 1ST (IE. ^^EXPUNGE\\) PHASE, NO NORMAL USAGE
IS POSSIBLE.
.B1.I-4
2.##^AFTER THE 1ST PHASE, AND UNTIL THE 2ND (IE. ^^V3TOV5\\) PHASE IS
STARTED, ANY ACCESSING OTHER THAN ^^DELETE\\S IS PERMITTED.
.B1
(^NOTE: UNTIL THE 2ND PHASE IS STARTED THE ^^.DBN\\ FILES ARE 0-LENGTH).
.B1.I-4
3.##^DURING THE 2ND PHASE, AND THRU THE COMPLETION OF THE 3RD PHASE (^^REKEY\\), RETRIEVAL USAGE-MODE IS ALLOWED ON THE OLD DATA BASE.
.B1
(^NOTE: THE EARLIEST THE OLD DATA BASE CAN BE DELETED
IS AFTER COMPLETION OF THE 2ND PHASE).
.B1.LM0
^THE SECOND REASON FOR MULTIPLE PHASES IS THAT IT ACHIEVES ISOLATION
OF FUNCTIONAL PROCESSES:
.B1.LM9.I-4
1.##^THE 1ST PHASE MAY BE OMITTED BY SOME INSTALLATIONS (SEE 2.3.1.2.2).
.B1.I-4
2.##^ONLY THE 2ND PHASE SIMULTANEOUSLY REFERENCES BOTH THE OLD
AND NEW DATA BASES.
.B1.I-4
3.##^ONLY THE 3RD PHASE REQUIRES JOURNALING IN ORDER TO BE
CONTINUABLE AFTER A CRASH (SEE SECTION 2.3.1.3).
.B2.LM0
2.3.1.2.2 ^WHY/WHEN THE ^^EXPUNGE\\ PHASE IS NECESSARY#-#
^^DBMS-V3\\ AND ^V5 HANDLE RECORD DELETION DIFFERENTLY.
^IN ^^DBMS-V5\\, THE ^^DELET\\ION OF A RECORD COMPLETELY
ELIMINATES IT FROM THE DATA BASE.
^ON THE OTHER HAND, THE ^^DBMS-V3\\ DELETION ALGORITHM WILL NOT
RETURN THE ENTIRE SPACE OF A ^^DELETE\\D RECORD TO THE
FREE SPACE MANAGER UNTIL THE RECORD HAS BEEN REFERENCED THRU
EACH SET IN WHICH IT PARTICIPATES.
^UNTIL THIS HAS OCCURRED, THE REMAINING PART OF THE RECORD IS
KEPT
"INVISIBLE" BY THE MECHANISM OF HAVING ITS "DELETED" FLAG TURNED ON
IN ITS LINE HEADER. ^CONSEQUENTLY
BEFORE THE OLD DATA BASE CAN BE
MAPPED TO THE NEW FORMAT, ANY DELETED RECORDS MUST BE ELIMINATED FROM THE DATA BASE.
^CONVERSELY THE 1ST PHASE MAY BE OMITTED BY
AN INSTALLATION IF IT KNOWS THAT NO RECORDS IN ITS DATA BASE HAVE THE "DELETE" FLAG ON.
^THIS IS NOT A LIFE-AND-DEATH DECISION, HOWEVER, BECAUSE THE
2ND PHASE WILL DETECT SUCH RECORDS AND INFORM THE USER THAT HE MUST
EXECUTE THE 1ST PHASE BEFORE STARTING THE 2ND PHASE.
.B2
2.3.1.2.3 ^USER-DATA ^DBKEYS#-#
^ANY FIELD CONTAINING A DBKEY MUST BE DESCRIBED AS ^^TYPE DBKEY\\
IN THE SCHEMA BECAUSE THE FORMAT OF A DBKEY IN
^^DBMS-V5\\ IS DIFFERENT THAN IN ^V3.
^IF THE USER DOES NOT DESCRIBE SUCH A FIELD AS ^^TYPE DBKEY\\,
^^V3TOV5\\ WILL HAVE NO WAY OF KNOWING THAT
EACH OCCURRENCE OF THE DATUM NEEDS REFORMATTING.
.B2
2.3.1.2.4 ^ADDING ^^OWNER IS SYSTEM\\#-#
^IF YOU WISH TO ADD NEW SET AND RECORD TYPES TO YOUR ^^DDL\\ PROGRAM, YOU SHOULD
WAIT UNTIL AFTER THE CONVERSION PROCESS HAS BEEN COMPLETED.
^ADDITIONALLY, YOU SHOULD READ SECTION 2.4 IN THE ^DATA ^BASE ^ADMINISTRATOR'S ^MANUAL TO UNDERSTAND
JUST WHAT SORT OF CHANGES ARE FEASIBLE.
.B1
^IN THE PARTICULAR CASE THAT YOU WISH TO CREATE A
SYSTEM RECORD (IE. ONE OR MORE NEW MEMBER ENTRIES SPECIFIES ^^OWNER IS SYSTEM\\)
, YOU WILL HAVE TO DEFINE A NEW AREA
AND DESIGNATE IT AS YOUR SYSTEM AREA. ^THIS IS NECESSARY BECAUSE
^^DBCS\\ EXPECTS TO ALLOCATE THE SYSTEM RECORD WHEN
AN AREA IS ACCESSED FOR THE FIRST TIME--AND THERE IS NO WAY TO
SIMULATE THAT PATTERN OF ACCESS DURING THE CONVERSION OF AN EXISTING AREA.
.B2
2.3.1.2.5 ^HUSTLING#-#
^^V3TOV5\\ ALLOWS YOU TO OPERATE OUTSIDE THE PRESCRIBED PROTOCOL
IF YOU FEEL IT NECESSARY. ^BUT THESE MORE ERROR-PRONE ACTIVITIES ARE
ISOLATED HERE TO PROTECT THE AVERAGE "CONVERTER".
.B1.LM9.I-4
1.##^ANY NUMBER OF NEW POINTERS CAN BE ADDED TO A RECORD TYPE. ^IN PARTICULAR, YOU MIGHT ADD PRIOR POINTERS TO CERTAIN SETS TO IMPROVE UPDATING
EFFICIENCY. (^^IMPORTANT REMINDER\\: THE ORDER AND NUMBER OF 02-DATA-NAMES MUST
NOT BE CHANGED HOWEVER).
.B1.I-4
2.##^THE ^^REENTER\\ MONITOR COMMAND CAN BE USED (IN CONJUNCTION WITH ^^/PAUSE\\) TO CONTROL THE FLOW OF CONVERSION MORE CLOSELY. ^FOR EXAMPLE, ONE CAN DO ALL THREE STEPS FOR A SINGLE AREA BY SPECIFYING TO ^^/START\\ WITH THAT AREA FOR EACH
STEP AND DOING ^^REENTER\\/NEXT-STEP AFTER EACH PAUSE.
.PG.B2.LM0
2.3.1.3 ^EXCEPTIONAL ^CONDITIONS#-#
^THERE ARE CERTAIN "BAD" THINGS THAT CAN HAPPEN DURING THE CONVERSION
PROCESS. ^THE FOLLOWING SUBSECTIONS ENUMERATE THE KNOWN POSSIBILITIES AND DESCRIBE WHAT THE USER SHOULD
DO IN EACH EVENTUALITY.
.B2.LM0
2.3.1.3.1 ^RECOVERING FROM A ^SYSTEM ^CRASH#-#
^THE MECHANISM FOR RECOVERING FROM AN ABORTION OF EITHER THE
^^EXPUNGE\\ OR ^^V3TOV5\\ PHASE IS THE SAME. ^THE MECHANISM FOR
RECOVERING FROM THE ^^REKEY\\ PHASE IS AS FOR THE OTHER PHASES PLUS AN ADDITIONAL
PRELIMINARY STEP. ^THE CRITICAL PARAMETER DURING A RESTART IS
THE LAST ^^TRACE\\ MESSAGE PRINTED. ^IT WILL CONTAIN THE LAST
PAGE THAT IS KNOWN TO HAVE BEEN PROCESSED. ^CONVERSELY THE
ARGUMENT TO THE ^^TRACE\\ COMMAND CONTROLS HOW OFTEN THESE MESSAGES
ARE PRINTED. (^PRESUMABLY, IN A VERY LARGE DATA BASE ONE MIGHT
INCREASE THE INTERVAL FROM THE DEFAULT OF ONE MESSAGE PER 10 PAGES PROCESSED.)
^THE RECOVERY SCENARIO IS AS FOLLOWS:
.B1.LM9.I-4
1.##^IF ABORTED DURING ^^REKEY\\ING,
.B1.LM29.TS29.I-20
^^R DBMEND ;THE DATA BASE RECOVERY UTILITY
.I-20
CONVERT ;INDICATE THE USE OF .??N FILES
.I-20
JOURNAL V3TOV5 ;OPEN THE JOURNAL
.I-20
FORCE ALL ;OPEN ALL AREAS,
;GIVE PRIVACY KEYS IF ANY
.I-20
START ;GIVE THE MERGE'S "LEFT" BOUNDARY
.I-20
END ;...AND THE "RIGHT" BOUNDARY
.I-20
MERGE BEFORE ;PERFORM THE ACTUAL MERGE
.I-20
CLOSE ALL ;CLEANUP THE OPEN AREAS TO BE DONE
.I-20
UNLOAD ;DESIGNATE THAT V3TOV5.JRN
;IS DONE WITH\\
.B1.LM9.I-4
2.##^THEN FOR ALL PHASES,
.B1.LM36.TS36.I-27
^^R V3TOV5
.I-27
SCHEMA \\SCHEMA-NAME^^ ;IDENTIFY THE SCHEMA
.I-27
EXPUNGE \O\R V3TOV5 \O\R REKEY ;WHICHEVER ABORTED
.I-27
^^START\\ LAST-TRACE-VALUE ;^^TO RESUME AT RIGHT PAGE\\
.BR
;IE. RESTART AT 1ST PAGE AFTER
.BR
;LAST TRACE VALUE
.B2.LM0
2.3.1.3.2 ^AREA OR ITS ^PAGE ^SIZE ^TOO ^SMALL#-#
^EXCEPT FOR ONE CIRCUMSTANCE, THE NUMBER OF PAGES IN A ^V3 AREA WILL SUFFICE IN ^V5.
^THE EXCEPTIONAL CIRCUMSTANCE CAN MANIFEST ITSELF DURING CONVERSION IF A ^V3 AREA IS NEARLY FULL
AND THE AREA CONTAINS OCCURRENCES OF SORTED SET TYPES.
^THE CIRCUMSTANCE IS THAT THE AMOUNT OF SPACE AVAILABLE WILL BE INADEQAUTE
FOR STORING EACH SORTED-SET INDEX STRUCTURE DURING ^^REKEY\\ING.
^TO CORRECT THE PROBLEM, EITHER INCREASE THE LAST PAGE OF THE
AREA OR INCREASE THE AREA'S PAGE SIZE.
(^THE COMMENTS ABOUT DETECTION AND RESTARTING AT THE END OF THE NEXT PARAGRAPH ALSO
APPLY HERE.)
.PG.B1
^EXCEPT FOR ONE CIRCUMSTANCE,
THE INFORMATION ON A PAGE IN A ^V3 DATA BASE CAN BE MAPPED INTO THE SAME OR FEWER WORDS
IN ^^DBMS-V5\\. ^THE
EXCEPTION IS A SORTED SET IN WHICH ^^PRIOR\\ POINTERS ARE NOT
EXPLICITLY SPECIFIED. ^^DBMS-V5\\ ALWAYS PUTS A ^^PRIOR\\ POINTER
INTO EACH RECORD IN A SORTED SET. ^CONSEQUENTLY, IF AN OLD PAGE
IS VERY FULL AND HAS SOME SUCH RECORDS, THE CONVERSION PROCESS
WOULD OVERFLOW THE PAGE. ^IF YOU ARE SURE THIS WILL HAPPEN TO
ONE OR MORE OF YOUR AREAS, SIMPLY INCREASE THAT AREA'S PAGE
SIZE TO THE NEXT 128-WORD-MULTIPLE. ^IF YOU DO NOT ANTICIPATE
THIS EVENTUALITY AND IT OCCURS, ^^V3TOV5\\ WILL SIMPLY ABORT WITH AN
APPROPRIATE MESSAGE.
^AT THIS POINT, YOU SHOULD MODIFY THE APPROPRIATE PAGE SIZE(S) OF YOUR ^^DDL\\ PROGRAM (GIVE ^^SCHEMA\\
THE COMMAND LINE "SCHEMA-NAME^^/CREATE/CONVERT\\") AND RESTART THE
^^V3TOV5\\ PHASE FROM ITS BEGINNING.
.B2
2.3.1.3.3 ^IMPROPERLY ^CONVERTED ^^.DDL\\ ^FILE#-#
^ALTHOUGH IT IS UNLIKELY, IT IS POSSIBLE THAT
YOU WILL IMPROPERLY CONVERT YOUR OLD ^^.DDL\\ FILE
INTO THE NEW FORMAT. (^IT IS UNLIKELY BECAUSE THE CHANGES ARE EITHER
MECHANICAL, SUCH AS ^^USAGE COMP\\ TO ^^TYPE FIXED BIN\\, OR INVOLVE MOVING LINES INTO THE SUB-SCHEMA.)
^THE MORE LIKELY DANGER IS THAT YOU WILL TRY TO SLIP
AN EXTRA CHANGE INTO YOUR SCHEMA--IN WHICH CASE YOU ARE
ON YOUR OWN. ^IN ANY EVENT, ANY FLAW IN THE CONVERTED SCHEMA
SHOULD SHOW UP IN A WIDESPEAD FASHION. ^CONSEQUENTLY, AFTER
YOU HAVE RENAMED THE ^^.??N\\ FILES TO THEIR STANDARD
EXTENSIONS,
YOU SHOULD USE THE ^^DUMP\\ AND/OR ^^USAGE\\ COMMANDS OF ^^DBINFO\\ TO VALIDATE THAT THE DATA, AS REPRESENTED IN THE NEW FORMAT, IS VALID.
.B2
2.3.1.3.4 ^ABNORMAL ^ABORT DURING ^CONVERSION#-#
^THIS SITUATION IS DEFINED BY A TRUE ABORT (EG. ILL MEM REF), OR
THE ^^V3TOV5\\ MESSAGES ^^?VTVSAF\\ OR ^^?VTVDAF\\.
^BASICALLY, IT CAN BE CAUSED BY ONE OF THREE THINGS.
.B1.LM9.I-4
1.##^AN IMPROPERLY CONVERTED SCHEMA. ^BEFORE RETRYING, CHECK OVER
YOUR CHANGES.
.B1.I-4
2.##^A SPURIOUS MONITOR ERROR.
.B1.I-4
3.##^IF THE PROBLEM PERSISTS EACH TIME YOU RESTART,
IT MUST BE ASSUMED YOU HAVE DISCOVERED A BUG AND THE PROBLEM SHOULD BE REPORTED.
.B1.LM0
^PHASE SPECIFIC RESTART RULES:
.B1.LM9.I-4
1.##^IF ABORTED DURING 1ST PHASE, IT CANNOT BE SCHEMA PROBLEM.
^GET A FRESH COPY OF YOUR DATA BASE AND RESTART THE PHASE FROM THE
BEGINNING.
.B1.I-4
2.##^IF ABORTED DURING THE 2ND PHASE: CHECK THE SCHEMA, RECREATE
THE ^^.DBN\\ FILES WITH ^^SCHEMA\\, AND RESTART THE PHASE FROM ITS BEGINNING.
.B1.I-4
3.##^IF ABORTED DURING THE 3RD PHASE: DELETE ^^V3TOV5.JRN\\, CHECK THE SCHEMA,
THEN RESTART WITH THE 2ND PHASE--SEE PRECEDING RULE.
.PG.B2.LM0
2.3.1.3.5 ^OTHER ^^V3TOV5\\ ERROR MESSAGES
.B1.LM15.TS15.I-10
^^?VTVDUK V3TOV5\\ FOUND A SORT OR CALC KEY IN A RECORD THAT EQUALS THE KEY
IN ANOTHER RECORD, BUT THE SCHEMA STATES THAT DUPLICATES ARE NOT ALLOWED.
.B1.I-10
?^^VTVICS\\ IT IS NOT MEANINGFUL TO REPEAT A PHASE OR FOLLOW IT BY AN EARLIER PHASE (EG. ^^V3TOV5\\ FOLLOWED BY ^^EXPUNGE\\).
.B1.I-10
^^?VTVNAS\\ YOU GAVE A ^^START\\ WITHOUT PRECEDING IT WITH A CONVERSION ACTION.
.B1.I-10
^^?VTVNMF\\ IN PROCESSING YOUR OLD SCHEMA, ^^V3TOV5\\ FOUND AN AREA, SET, RECORD, OR DATA NAME
THAT IS NOT IN YOUR NEW SCHEMA...CORRECT THE DISCREPANCY.
.B1.I-10
?^^VTVOOS\\ ^^V3TOV5\\ DETECTS THIS CONDITION SO AS TO GUARANTEE ITS INTEGRITY; JUST TYPE ^^R V3TOV5\\ TO DO MORE WORK.
.B1.I-10
%^^VTVUFA\\ IF THE FILE ASSOCIATED WITH AN AREA IS NULL OR NOT FOUND,
^^V3TOV5\\ WILL AUTOMATICALLY SKIP THAT AREA AND CONTINUE WITH THE NEXT ONE. ^IF THE FILE SHOULD HAVE BEEN FOUND, REPORT THE PROBLEM OR CORRECT YOUR SCHEAM.
.B1.I-10
?^^VTVUAJ\\ YOU HAVE A ^^V3TOV5.JRN\\ FILE THAT IS IN AN UNDEFINED STATE. ^YOU SHOULD EITHER DELETE IT OR RUN ^^DBMEND\\ AS DESCRIBED IN 2.3.1.3.1.
.B2.LM0
2.3.1.4 ^RESOURCE REQUIREMENTS#-#
^THE RESOURCE REQUIREMENTS OF ^^V3TOV5\\ ARE APPROXIMATELY AS FOLLOWS.
^IT STATICALLY REQUIRES 15^K OF CORE AND WILL EXPAND ITS CORE AS NECESARY FOR AREA BUFFERS AND THE IN-CORE SUB-SCHEMAS. ^THE AVERAGE EXPANSION
WILL BE ON THE ORDER OF 5^K.
^THE DISK SPACE REQUIRED IS PHASE DEPENDENT AND IS THE ENTIRE DATA BASE:
PLUS NOTHING DURING THE ^^EXPUNGE\\ PHASE, PLUS A SECOND COPY OF THE
DATA BASE DURING THE ^^V3TOV5\\ PHASE, PLUS A 1-TRANSACTION JOURNAL DURING
THE ^^REKEY\\ PHASE.
^HOWEVER BY APPROPRIATE USE OF THE ^^PAUSE\\ SWITCH (SEE 2.3.1.1), YOU CAN CAUSE "DATA BASE" TO BE REPLACED BY "AREA".
.B2.LM0
2.3.2##^SIMULTANEOUS ^UPDATE
.B1
^^DBMS-V5\\ WILL ALLOW A USER TO UPDATE (OR RETRIEVE) DATA
WHILE ANOTHER UPDATES DATA IN THE SAME AREA/FILE.
^IT WILL HANDLE THE VALID-COPY-OF-DATA PROBLEM INHERENT IN THIS FACILITY THRU THE MECHANISM OF THE ^^ENQ/DEQ\\ MONITOR CALLS.
.B1
(^NOTE: THE FACILITY RELIES ON THE FACT THAT USERS OF A PARTICULAR DATA BASE
ALL ACCESS THE SAME SCHEMA).
.B1
^FOUR ^^DBMS\\ COMPONENTS CONTROL WHETHER AND HOW SIMULTANEOUS UPDATE IS INVOLVED IN A RUN-UNIT'S OPERATION.
.PG.B1.LM9.I-4
1.##^IT IS THE ^^OPEN\\ STATEMENT WHICH CONTROLS WHETHER A RUN-UNIT
IS WITHIN THE DOMAIN OF THE SIMULTANEOUS UPDATE FACILITY.
^THE SIMULTANEOUS UPDATE FACILITY REALLY CONSISTS OF THREE SEPARATE
^^OPEN USAGE-MODE\\S: ^^UPDATE, PROTECTED UPDATE\\, AND ^^RETRIEVAL\\.
^^PROTECTED UPDATE\\ IS INCLUDED BECAUSE A ^^PROTECTED UPDATER\\ MUST
BLOCK OUT ^^RETRIEVERS\\ (AND VICE VERSA).
^THE THREE NON-SIMULTANEOUS USAGE-MODES ARE ^^PROTECTED RETRIEVAL, EXCLUSIVE RETRIEVAL,\\ AND ^^EXCLUSIVE UPDATE\\.
^THE MEANING OF EACH ^^USAGE-MODE\\ IS PRESENTED IN SECTION 3 SUB-SECTION 2.1.6.1.
.B1.I-4
2.##^THE ^^OPEN JOURNAL\\ STATEMENT COMMUNICATES TO ^^DBCS\\ IF
A JOURNAL WILL BE SHARED BY MORE THAN ONE RUN-UNIT -- SEE 2.3.2.3.1.
.B1.I-4
3.##^THE ^^IMAGES\\ STATEMENT OF THE ^^DMCL\\ CONTROLS THE FORM OF INTERLEAVING-UNIT EMPLOYED BY A DATA BASE'S APPLICATIONS -- SEE 2.3.2.1 AND 2.1.1.3.
.B1.I-4
4.##^THE INTERVAL BETWEEN A CALL TO ^^JSTRAN\\ AND A CALL TO ^^JETRAN\\ DEFINES ONE TRANSACTION -- SEE 2.3.2.1.2.
.B1.LM0
^THE FOLLOWING TWO TABLES ARE INTENDED TO PROVIDE AN OVERVIEW OF THE TRADE-OFFS INVOLVED IN USING THE SIMULTANEOUS UPDATE FACILITY.
.B1
^^THE NON-SIMULTANEOUS USAGE-MODES ARE UNQUESTIONABLY MORE EFFICIENT THAN THE SIMULTANEOUS USAGE-MODES.\\
.B1.LM24.TS24.I-24
^^USAGE-MODE WHEN TO USE\\
.I-24
-------------------------------------------------------------
.I-24
^^RETRIEVAL\\ YOU INTEND OTHER RUN-UNITS TO BE SIMULTANEOUSLY OPEN FOR (^^PROTECTED) UPDATE\\.
.B1.I-24
^^UPDATE\\ USE ONLY IF YOU REALLY INTEND FOR THERE TO BE SIMULTANEOUS UPDATERS.
.B1.I-24
^^PROTECTED RETRIEVAL\\ USE IF YOU EXPECT CONCURRENT RETRIEVERS BUT NO CONCURRENT UPDATERS.
.B1.I-24
^^PROTECTED UPDATE\\ USE ONLY IF YOU REALLY INTEND FOR THERE TO BE SIMULTANEOUS RETRIEVERS.
.B1.I-24
^^EXCLUSIVE RETRIEVAL\\ USE ONLY IF YOU NEED TO BE SELFISH.
.B1.I-24
^^EXCLUSIVE UPDATE\\ USE RATHER THAN (^^PROTECTED) UPDATE\\ UNLESS YOU REALLY INTEND FOR THERE TO BE SIMULTANEOUS UPDATERS OR RETRIEVERS.
.PG.B2.LM0.TS28,44
^^LEVEL OF SIMULTANEITY FEATURES HOW TO ACHIEVE\\
.BR
-------------------------------------------------------------
.BR
NONE INEXPENSIVE ^^EXCL RETR!UPDATE\\
.BR
SIMULTANEOUS RETRIEVERS INEXPENSIVE ^^PROT RETR\\
.BR
PSEUDO-SIMUL UPDATERS SEE ^F1 SEE ^H1
.BR
COMMAND-INTERLEAVING SEE ^F2 SEE ^H2
.BR
TRANSACTION-INTERLEAVING
.BR
##WITH DEFAULT TRANSACTIONS SEE ^F3 SEE ^H3
.BR
TRANSACTION-INTERLEAVING SEE ^F4 SEE ^H4
.B1.LM6.I-6
(^F1)##^INEXPENSIVE BUT COMPLICATES THE DESIGN/CONTROL PROBLEM FOR THE IMPLEMENTOR.
.B1.I-6
(^F2)##^MINIMIZES BLOCKING TIME.
.B1.I-6
(^F3)##^MINIMIZES BLOCKING TIME WHILE STILL ACCOMODATING NON-INTERRUPTABLE ^^DML\\ COMMAND SEQUENCES.
.B1.I-6
(^F4)##^MINIMIZES ^^CPU\\ USAGE AND HANDLES NON-INTERRUPTABLE ^^DML\\ COMMAND SEQUENCES.
(^NOTE THAT ^F4 AND ^F3 EXIST ON A CONTINUUM, RATHER THAN BEING DISTINCT MODES).
.B1.I22
***************
.B1.I-6
^H2-^H4 APPLY TO ALL THE SIMULTANEOUS UPDATE ^^USAGE-MODES\\.
.B1.I-6
(^H1)##^YOU HAVE RUN-UNITS THAT SIMULTANEOUSLY OPEN
DISJOINT AREAS IN ^^EXCLUSIVE UPDATE\\.
.B1.I-6
(^H2)##^YOU OPTIONALLY DEFINE TRANSACTIONS AND SPECIFY THAT IMAGES ARE ORDERED BY COMMAND -- SEE 2.3.2.1.1.
.BR
(^HOWEVER IF THIS RUN-UNIT DID NOT INVOLVE THE SIMULTANEOUS UPDATE FACILITY,
SPECIFYING IMAGES NOT ORDERED BY COMMAND WOULD BE AN EFFICIENCY CONSIDERATION -- SEE SECTION 2.1.1.3).
.B1.I-6
(^H3)##^YOU SPECIFY THAT IMAGES ARE NOT ORDERED BY COMMAND AND DIVIDE
INTO TRANSACTIONS JUST THOSE COMMAND SEQUENCES THAT REQUIRE NO INTERVENTION -- SEE 2.3.2.1.2.
.B1.I-6
(^H4)##^YOU SPECIFY THAT IMAGES ARE NOT ORDERED BY COMMAND
AND DIVIDE ALL THE OPERATIONS OF YOUR RUN-UNITS INTO TRANSACTIONS -- SEE 2.3.2.1.2.
.B2.LM0.F.J
2.3.2.1 ^HOW ^SIMULTANEOUS?#-#
^ONE MAKES SIMULTANEOUS UPDATE "WORK" BY RECOGNIZING WHICH
MICROSCOPIC ACTIONS OF SIMULTANEOUS UPDATERS CANNOT BE TRULY SIMULTANEOUS. ^IN OTHER WORDS, ONE DEFINES THE WAYS IN WHICH THE OPERATIONS
OF TWO RUN-UNITS CAN BE INTERLEAVED (UNDERLINE IT!).
^THUS THE AMOUNT OF SIMULTANEITY SUPPORTED IS CONTROLLED BY THE SCOPE OF THE RESOURCE(S) INTERLEAVED UPON AND/OR BY THE (AVERAGE) DURATION
FOR WHICH A GIVEN RESOURCE IS CONTROLLED (IE. THE INTERLEAVING-UNIT).
.PG.B1
^LET IT BE STATED WITHOUT PROOF THAT THE FOLLOWING (INCREASING) SCOPES OF RESOURCE
ARE AT LEAST PLAUSIBLE: A DATA BASE PAGE, A DATA BASE AREA, OR THE DATA BASE; AND THAT THE FOLLOWING
(INCREASING-DURATION) INTERLEAVING-UNITS ARE PLAUSIBLE: ^^DML\\ VERB/COMMAND, USER TRANSACTION, OR RUN-UNIT.
^HOWEVER AS YOU DECREASE THE SCOPE OF RESOURCE CONTROLLED,
THE POTENTIAL FOR TWO RUN-UNITS NEEDING RESOURCES
IN A SEQUENCE THAT WILL CAUSE DEADLY EMBRACE IS INCREASED.
^IN PARTICULAR, A ^^DML\\ VERB CAN MANIPULATE PAGES IN AN ARBITRARY SEQUENCE, THEREBY MAKING THE DATA BASE PAGE AN
UNACCEPTABLE SCOPE OF RESOURCE BECAUSE OF THE STIGMA OF DEADLY EMBRACE.
^THE DATA BASE AREA IS AN ACCEPTABLE SCOPE OF RESOURCE, BUT THE EXISTING FUNCTIONALITY OF ^^ENQ/DEQ\\ PRESENTLY MAKES ITS USE UNFEASIBLE.
(^A PROPOSAL TO CORRECT THIS WILL BE GENERATED IN A SEPARATE MEMO.)
^THUS, IN ^^DBMS-V5\\ THE ONLY SCOPE OF RESOURCE SUPPORTED WILL BE
CONTROL OF THE DATA BASE ITSELF, IN CONJUNCTION WITH EITHER A ^^DML\\ COMMAND
AS THE INTERLEAVING-UNIT OR A USER-SPECIFIED TRANSACTION AS THE INTERLEAVING-UNIT (OR THE RUN-UNIT AS THE INTERLEAVING-UNIT, IE. THE THREE NON-SIMULTANEOUS USAGE-MODES).
.B1
^TO CONTROL WHICH INTERLEAVING-UNIT APPLIES TO A PARTICULAR SCHEMA,
ONE MUST USE THE ^^IMAGES\\ STATEMENT OF THE ^^DMCL\\ (SEE SECTION 3 SUB-SECTION 2.1.1.3).
^IN PARTICULAR, SPECIFYING THAT IMAGES ARE NOT ORDERED BY COMMAND WILL RESULT IN
TRANSACTIONAL INTERLEAVING; AND SPECIFYING THAT IMAGES ARE ORDERED BY COMMAND WILL RESULT
IN COMMAND-LEVEL INTERLEAVING.
.B2
2.3.2.1.1 ^COMMAND-INTERLEAVING CASE#-#
^IN PRACTICE, COMMAND-LEVEL INTERLEAVING TRANSLATES TO:
WHEN ^^DBCS\\ INITIATES A COMMAND, IT WILL
AUTOMATICALLY ^^ENQ\\ UPON THE DATA BASE RESOURCE (NOT AT ALL FOR BINDING, ^^STATS\\, ETC.; SHARED
FOR ^^FIND\\, ^^GET\\, AND ^^IF\\; AND EXCLUSIVE OTHERWISE);
AND WHEN IT COMPLETES THE COMMAND, IT WILL AUTOMATICALLY ^^DEQ\\.
^CONSEQUENTLY, EVEN THOUGH COMMAND-LEVEL INTERLEAVING GUARANTEES THE
PHYSICAL INTEGRITY OF THE DATA BASE, IT HAS ONE LIMITATION; IT GIVES ONE NO WAY
TO HANDLE THE CASE WHERE A RUN-UNIT REQUIRES THAT NO ONE INTERVENE WHILE IT EXECUTES
SEVERAL ^^DML\\ VERBS THAT AFFECT A SINGLE DESIRED CHANGE (E.G. A PASSENGER
WANTS TO CHANGE HIS AIRPLANE SET OCCURRENCE WITHOUT BEING LEFT WITH NO SEAT AT ALL).
.B2.LM0
2.3.2.1.2 ^TRANSACTION-INTERLEAVING CASE#-#
^THERE ARE BENEFITS TO A LARGE INTERLEAVING-UNIT, PARTICULARLY IN AN APPLICATION IN WHICH SIMULTANEOUS RUN-UNITS HAVE
A LOT OF DORMANT TIME ANYWAY.
^ONE, AN APPROPRIATE LARGE UNIT WILL ENFORCE THE LOGICAL INTEGRITY OF THE DATA BASE BY PREVENTING INTERVENTION FOR A USER-DETERMINED PERIOD OF TIME.
^TWO, DECREASING THE FREQUENCY WITH WHICH A SECOND RUN-UNIT MANIPULATES
"YOUR" DATA BASE AND JOURNAL, WILL DECREASE THE AMOUNT OF DEFENSIVE PROCESSING ^^DBCS\\ WILL HAVE TO DO (IE. IN
A ^^CPU\\ USAGE SENSE, YOUR RUN-UNIT WILL OPERATE MORE EFFICIENTLY).
^WHAT SHOULD THE LARGE INTERLEAVING-UNIT BE? CLEARLY THE
TRANSACTION (IE. USE OF ^^JSTRAN\\ AND ^^JETRAN\\).
^FIRST, USER-SPECIFIED TRANSACTIONS ARE BY DEFINITION THE MECHANISM BY WHICH A
RUN-UNIT DEFINES LOGICAL OPERATIONS ON THE DATA BASE.
^SECONDLY, RUN-UNIT INTERLEAVING PUTS A SPECIAL BURDEN ON THE JOURNAL PROCESSOR, SO COORDINATING JOURNALING AND INTERLEAVING IN
THE SAME UNITS HAS TO BE A GOOD IDEA.
.B1
^IN PRACTICE, TRANSACTION-INTERLEAVING MEANS THAT: WHEN ^^DBCS\\
INITIATES A TRANSACTION, IT WILL AUTOMATICALLY ^^ENQ\\ EXCLUSIVELY UPON THE
DATA BASE RESOURCE;
AND WHEN IT COMPLETES THE TRANSACTION, IT WILL AUTOMATICALLY ^^DEQ\\.
^HOWEVER COMMANDS NOT EXECUTED IN THE CONTEXT OF
AN ACTIVE TRANSACTION (EG. BEFORE THE FIRST ^^JSTRAN\\) ARE HANDLED SPECIALLY. ^EACH SUCH COMMAND
WILL CONSTITUTE A DEFAULT TRANSACTION, AND THE RULES OF 2.3.2.1.1 WILL APPLY TO IT.
^ALSO IF IT IS AN UPDATING COMMAND, IT WILL BE GIVEN A COMMAND HEADER AND TRAILER AS WHEN IMAGES ARE
ORDERED BY COMMAND.
^THERE ARE TWO REASONS FOR DEFAULT TRANSACTIONS. ^ONE,
RUN-UNITS THAT ONLY RETRIEVE (PARTICULARLY EXISTING ONES) WILL
NOT HAVE TO BE TROUBLED WITH EXPLICIT TRANSACTIONS.
^TWO, RUN-UNITS THAT WOULD LIKE THE MINIMUM BLOCKING TIME OF COMMAND-INTERLEAVING AND WISH TO CONTAIN A FEW
NON-INTERVENABLE COMMAND SEQUENCES, CAN DO THIS WITH SELECTIVE USE OF EXPLICIT TRANSACTIONS.
.B1
^THERE ARE TWO EXCEPTION CONDITIONS DIRECTLY RELATED TO TRANSACTION-INTERLEAVING.
^EXCEPTION 38 WILL OCCUR IF YOU CALL ^^JSTRAN\\ WHILE A TRANSACTION IS ALREADY ACTIVE.
^A ^^LIBOL/FOROTS\\ ERROR WILL BE SIGNALLED IF YOU ATTEMPT TO DO A NON-^^DBMS\\ ^^RETAIN\\ WHILE IN THE MIDDLE OF A TRANSACTION.
.B2.LM0
2.3.2.2 ^PROTECTION OF THE CURRENT RECORD OF THE RUN-UNIT#-#
^IT IS AN UNDERLYING PREMISE OF ^^DBMS\\ THAT ALL OPERATIONS ON THE
DATA BASE ARE DONE THRU ONE WINDOW: THE CURRENT RECORD OF THE RUN-UNIT.
^CONSEQUENTLY, IT IS NECESSARY THAT ^^DBCS\\ ENSURE THAT A RUN-UNIT WILL
NOT HAVE ITS OPERATION CONFUSED/ABORTED BECAUSE SOMEONE ELSE DELETED THAT RECORD.
^THE IMPLICIT PHILOSOPHY IS THAT THE BURDEN OF CONFLICTS SHOULD BE ON
THOSE WHO PERFORM ANTI-SOCIAL ACTIVITIES, IE. ^^DELETE\\.
.B1
^THIS PROTECTION DOES EXIST AND IS COMPLETELY AUTOMATIC, BUT IT DOES AFFECT THE USER'S ENVIRONMENT AS FOLLOWS.
.B1.LM9.I-4
1.##^THE ^^FIND\\ING RUN-UNIT WILL RETAIN THE FOUND RECORD SHARED
IF IT IS IN AN AREA OPEN FOR ^^UPDATE\\ OR ^^PROTECTED UPDATE\\ OR ^^RETRIEVAL\\.
^OTHERWISE IT WILL NOT RETAIN THE FOUND RECORD AT ALL.
^IT WILL OF COURSE ^^DEQ\\ THE OLD CURRENT OF RUN-UNIT WHEN A NEW ONE IS FOUND.
.B1.I-4
2.##^WHEN THE AREA IN WHICH THE CURRENT RECORD
OF THE RUN-UNIT RESIDES IS CLOSED, CURRENT OF RUN-UNIT IS DEQUEUED.
.B1.I-4
3.##^IF ONE DOES A ^^DELETE\\ WHICH EVENTUALLY TRIES TO
DELETE A RECORD WHICH IS RETAINED BY ANOTHER RUN-UNIT,
THE ^^DELETE\\ IS TERMINATED WITH EXCEPTION 40 (IE. RESOURCE NOT AVAILABLE).
.PG.B2.LM0
2.3.2.3 ^NEW ^JOURNAL-RELATED ^FUNCTIONALITY
.B2
2.3.2.3.1 ^SHARED ^JOURNALS#-#
^IF TWO RUN-UNITS ARE UPDATING THE SAME AREA SIMULTANEOUSLY, THEY OBVIOUSLY ARE ALSO
UPDATING THE JOURNAL FILE SIMULTANEOUSLY. ^WHEN A JOURNAL IS SHARED
LIKE THIS, SEVERAL THINGS MUST BE PERIODICALLY DONE TO IT TO ENSURE ITS
CONTINUING INTEGRITY.
^AND THE COST OF THAT WORK MAKES IT IMPERATIVE THAT A RUN-UNIT COMMUNICATE
TO ^^DBCS\\ WHEN ITS JOURNAL NEED NOT BE SHARED.
^CONSEQUENTLY, BEFORE ^^OPEN\\ING ANY AREAS, THE RUN-UNIT SHOULD EXECUTE THE
FOLLOWING STATEMENT:
.B1.C
^^OPEN JOURNAL USAGE-MODE [EXCLUSIVE] UPDATE.\\
.B1
^THE ^^EXCLUSIVE\\ KEYWORD SHOULD BE ABSENT IF AND ONLY IF
THE RUN-UNIT WILL BE BACKING UP ONE OR MORE AREAS ^^OPEN\\ED WITH ^^USAGE-MODE UPDATE\\.
.B1
^ALTHOUGH ITS USE IS SUGGESTED, IT MUST BE LEGAL TO OMIT
AN OPEN-JOURNAL STATEMENT SO THAT EXISTING ^^DBMS\\ PROGRAMS WILL
NOT BE IMPACTED.
^SO THE FOLLOWING RULES APPLY WHEN A OPEN-JOURNAL STATEMENT HAS NOT
BEEN EXECUTED BY THE TIME THE FIRST UPDATING OPEN IS ATTEMPTED.
^IF THE AREA IS BEING OPENED FOR EXCLUSIVE OR PROTECTED UPDATE,
AN ^^OPEN JOURNAL USAGE-MODE EXCLUSIVE UPDATE\\ WILL BE SIMULATED.
^CONVERSELY AN ^^OPEN JOURNAL USAGE-MODE UPDATE\\ WILL BE SIMULATED IF THE
AREA IS BEING OPENED WITH ^^USAGE-MODE UPDATE\\.
.B1
^A SECONDARY BENEFIT OF THE ^^OPEN JOURNAL\\ STATEMENT IS THAT IT
CAN BE USED TO FORCE OPEN THE JOURNAL EVEN WHEN ONLY TEMPORARY AREAS ARE TO BE OPENED. ^PREVIOUSLY THIS SITUATION WAS A PROBLEM BECAUSE USAGE OF ^^JSTRAN\\, ^^JRTEXT\\, ETC. COULD NOT BE
CHECKED OUT CONVENIENTLY WHEN IT APPLIED.
.B2.LM0
2.3.2.3.2 ^JOURNAL LIFETIME#-#
^WHEN A RUN-UNIT OPENS A JOURNAL, ^^DBCS\\ MUST DECIDE WHETHER IT
SHOULD APPEND TO THE JOURNAL, START ANEW AND OVERWRITE THE JOURNAL,
OR ABORT BECAUSE THE JOURNAL IS IN AN UNDEFINED STATE.
.B1
^^DBCS\\ WILL OVERWRITE THE JOURNAL ONLY IF IT IS IN A DONE-WITH STATE.
^A JOURNAL IS DONE-WITH IF THE IMAGES IN IT HAVE ALREADY BEEN MERGED (SEE 2.3.2.3.3),
OR YOU HAVE INDICATED THAT ALL RUN-UNITS HAVE SUCCESSFULLY
COMPLETED. ^YOU INDICATE THIS VIA USE OF THE
^^CLOSE JOURNAL\\ STATEMENT (AS OPPOSED TO ^^CLOSE RUN-UNIT\\). ^IF YOU ARE THE LAST/ONLY RUN-UNIT ACTIVE WHEN YOU DO A
^^CLOSE JOURNAL\\, ^^DBCS\\ WILL ALTER THE JOURNAL'S LABEL PAGE TO INDICATE THAT
THE JOURNAL IS DONE-WITH. ^OTHERWISE ^^CLOSE JOURNAL\\ WILL BE EQUIVALENT TO ^^CLOSE RUN-UNIT\\.
^ALSO BOTH ^^CLOSE RUN-UNIT\\ AND ^^CLOSE JOURNAL\\ WILL BE EQUIVALENT TO ^^CLOSE ALL\\ IF NO JOURNAL IS OPEN WHEN EITHER IS CALLED.
.PG.B1
^IF A JOURNAL IS NOT IN A DONE-WITH STATE, ^^DBCS\\ WILL APPEND TO IT
IF THE JOURNAL'S LABEL PAGE CORRECTLY REPRESENTS THE CURRENT STATE OF
THE JOURNAL. ^OTHERWISE IT WILL ABORT WITH EXCEPTION 61.
^A JOURNAL'S LABEL PAGE IS MADE TO CORRECTLY REFLECT THE STATE OF THE JOURNAL BY ^^CLOSE RUN-UNIT,
CLOSE JOURNAL\\, AND AT THE END OF EVERY INTERLEAVING-UNIT IN A RUN-UNIT IN WHICH THE JOURNAL IS SHARED. ^THUS EXCEPTION 61 WILL OCCUR
ONLY WHEN YOU HAVE PREVIOUSLY ABORTED ONE OR MORE UPDATING RUN-UNITS AND
NOT MERGED THE IMAGES THEY GENERATED BACK INTO THE DATA BASE -- SEE 2.3.2.3.3.
(^NOTE: ^^DBCS\\ NEVER SUPERSEDES THE JOURNAL (FOR EFFICIENCY REASONS). ^SO IF THE JOURNAL SOMEHOW GETS CLOBBERED -- IE. ^^DBCS\\ GENERATES EXCEPTION 61
OR 63 WHEN IT SHOULD NOT--SIMPLY DELETE THE JOURNAL.)
.B2.LM0
2.3.2.3.3 ^CHANGES TO ^^DBMEND\\ AND THE JOURNAL FILE#-#
^THE MOST OBVIOUS
CHANGE IS THAT THE JOURNAL MUST CONTAIN RUN-UNIT ^I^DS SO THAT THE
CHANGES OF A PARTICULAR RUN-UNIT CAN BE ISOLATED WHEN YOU ARE USING ^^DBMEND\\;
AND CONVERSELY ^^DBMEND\\ MUST HAVE SEMANTICS FOR DENOTING RUN-UNIT ^I^DS:
.B1.LM9.I-4
1.##^THE FORM OF A BOUNDARY INDICATOR GOES
FROM "[NAME:] INDEX" TO "[NAME:] INDEX [(RUN-UNIT ^I^D)]".
.B1.I-4
2.##^IF A RUN-UNIT ^I^D IS ABSENT FROM A BOUNDARY INDICATOR, ^^DBMEND\\
IGNORES THE RUN-UNIT ^I^DS IN THE JOURNAL WHEN ATTEMPTING A BOUNDARY MATCH.
.B1.I-4
3.##^THE RUN-UNIT ^I^D IN A COMPLETELY UNSHARED
JOURNAL IS 0. ^HOWEVER, THE "JOURNAL CHARACTERISTICS" MESSAGE GENERATED WHEN A RUN-UNIT OPENS
A JOURNAL WILL INDICATE IN ANY EVENT THE RUN-UNIT'S ^I^D. ^THE FORM OF THE MESSAGE IS:
.B1.LM18.NF.NJ
[^^JOURNAL CHARACTERISTICS ARE:]
RUN-UNIT ID####\\ID-VALUE
SCHEMA-NAME ^^RUN\\##SCHEMA-RUN-OF-LAST-OVERWRITER
DATE/TIME-JOURNAL-LAST-OVERWRITTEN
.B1.LM9.F.J.I-4
4.##^AN ABSTRACT WILL SHOW WHICH RUN-UNIT GENERATED
ANY TRANSACTIONS, TEXT, AND COMMANDS DISPLAYED IF YOU SPECIFY THE ^^RUNUNITID\\ OPTION TO THE ^^DISPLAY\\ COMMAND.
.B1.LM0
(^NOTE: THE ADDITION OF THE RUN-UNIT ^I^D PLUS EXPANSION OF THE JOURNAL LABEL MEANS THAT ^V4 JOURNAL FILES WILL NOT BE PROCESSABLE BY ^^DBMEND-V5\\; HOWEVER THERE IS NOTHING TO PREVENT ONE FROM
USING ^^DBMEND-V4\\ TO MERGE ^V4 JOURNAL FILES).
.B1
(^NOTE: BECAUSE A JOURNAL CAN NOW CONTAIN UPDATES OF DIFFERENT RUN-UNITS, IT MAY NO LONGER BE SORTED BY COMMAND INDEX AND EACH TRANSACTION INDEX.
^THUS ^^DBMEND\\ WILL NO LONGER BE ABLE TO DETERMINE IF CURRENT JOURNAL
POSITION IS "PAST" THE FIRST-PROCESSED BOUNDARY EXCEPT BY ENCOUNTERING
BEGINNING/END OF JOURNAL BEFORE IT ENCOUNTERS THE BOUNDARY).
.PG.B1
^TWO OTHER CHANGES TO ^^DBMEND\\ RELATE TO PLACING THE JOURNAL IN A DONE-WITH STATE.
^SPECIFYING THE /^^UNLOAD\\ SWITCH FOR A DISK JOURNAL WILL PLACE IT
IN A DONE-WITH STATE.
^SPECIFYING THE /^^COMPLETE\\ SWITCH (SEE 2.3.2.3.4 AS WELL)
FOR A MAGTAPE JOURNAL WILL PLACE THE JOURNAL (TEMP FILE) IN A DONE-WITH STATE.
.B1
^TO ACHIEVE THE ^^DBMS-V3\\ EFFECT OF A ^^/COMPLETE\\ SWITCH (IE. JOURNAL TRUNCATION), SPECIFY ^^COMPLETE\\ JPAGE.
^THIS WILL CAUSE A ^^POSITION\\ JPAGE FOLLOWED BY PLACEMENT OF AN ^^EOF\\ MARKER AFTER THAT PAGE.
.B2.LM0
2.3.2.3.4 ^MAGTAPE JOURNALING#-#
(^THE PROGRAM ^^DAEMDB\\ IS DESCRIBED IN 2.3.2.3.5).
.B1
^MAGTAPE JOURNALING WORKS AS FOLLOWS. ^^DBCS\\ WILL INITIATE MAGTAPE JOURNALING IF ANY OF THE CONDITIONS IN THE NEXT PARAGRAPH ARE SATISFIED. ^IT INITIATES MAGTAPE JOURNALING
BY (1) USING ^^IPCF\\ TO COMMUNICATE TO ^^DAEMDB\\
THE ^^MTA\\ UNIT WHICH IS TO BE
THE JOURNAL AND (2) OPENING A FILE CALLED ^^DSK: \\ JOURNAL-NAME^^.JRN\\REST-OF-SPEC. ^THIS FILE IS AN ORDINARY JOURNAL
FILE OTHER THAN FOR THE FACT
THAT ^^DAEMDB\\ IS AWARE OF ITS EXISTENCE--AND FROM ^^DBCS\\'S POINT OF
VIEW IT IS THE JOURNAL.
.B1
^IF ANY OF THESE CONDITIONS ARE SATISFIED, MAGTAPE JOURNALING WILL BE INITIATED.
.B1.LM9.I-4
1.##^^DEVCHR\\ OF THE DEVICE IN THE JOURNAL FILE SPEC
(SEE SECTION 2.1.1.2) HAS
MAGTAPE CHARACTERISTICS.
.B1.I-4
2.##^IF THE DEVICE IN THE JOURNAL FILE SPEC IS NOT ASSOCIATED TO AN ACTUAL
DISK DEVICE AND THE TEXT OF THE DEVICE IS ^^"MTA"\\, MAGTAPE JOURNALING WILL BE INITIATED ON THE MAGTAPE UNIT THE OPERATOR CHOOSES.
.LM4
.B1
^HOWEVER IF THE MAGTAPE SERVICE IS UNAVAILABLE, YOU ARE GIVEN THE OPPORTUNITY TO SELECT DISK INSTEAD.
^UNLESS YOU HAVE A ^^USE\\ CONDITION FOR 0946, ^^DBCS\\ EXITS AFTER TYPING:
.B1.C
%^^DBSODJ ONLY DISK JOURNAL FEASIBLE (DAEMDB CODE \\XXX)
.B1
^YOU SHOULD THEN (GIVE UP OR) ^^ASSIGN/DEFINE\\ THE JOURNAL NAME TO A DISK DEVICE AND THEN TYPE ^^CONTINUE\\.
^IF A ^^DBCS\\-CAUSED EXIT IS INCOMPATIBLE WITH YOUR APPLICATION, YOU SHOULD HAVE CREATED
A ^^USE\\ CONDITION FOR 0946 AND HAVE MADE THE ^^USE\\ PROCEDURE:
.B1.LM5.NF.NJ
^^CALL JMDISK\\#####...MERELY MAKES JOURNAL DEVICE ^^"DSK"\\
^^OPEN\\ THE JOURNAL AS BEFORE
^^IF\\ ERROR-STATUS NOT = 0 THEN ABORT PRESUMABLY TO GET A DISK JOURNAL.
.B1.LM0.F.J
(^NOTE: IF A ^^DBCS\\ SOFTWARE ERROR IS NOT AN ISSUE, ALSO ASSOCIATE THIS ^^USE\\ PROCEDURE WITH EXCEPTION 0967).
.PG.B1
^THE ^^DAEMDB\\-INTERACTION CODES ARE:
.B1.LM5.TS15.NF.NJ
0 SUCCESS, THE MESSAGE WILL NOT OCCUR
1 ^^DAEMDB\\ UNAVAILABLE (^^SHUTDOWN\\ ALREADY GIVEN)
2 MAGTAPE COULD NOT BE OPENED
3 UNABLE TO OPEN JOURNAL TEMP FILE
4 IMPROPER DEVICE TYPE AFTER ^^ASSIGN/DEFINE\\
5 ^^DBCS\\ SOFTWARE ERROR DURING INITIALIZATION
6 ^^JMDISK\\ ALREADY DONE ONCE
7 ^^DAEMDB\\ ALREADY MANAGING 8 JOURNALS
.B1.LM0.F.J
^ALSO THE GENERALITY OF JOURNAL DEVICE SELECTION IS SOMEWHAT RESTRICTED UNDER ^^TOPS-10\\.
^IF YOUR JOURNAL DEVICE ON THE ^^DECSYSTEM-10\\ WERE ^^JRN:\\ FOR INSTANCE,
YOU WOULD BE PRETTY MUCH RESTRICTED TO HAVING A DISK JOURNAL.
^YOU WOULD HAVE TO BE ABLE TO GAIN CONTROL OF ^^MTA\\N IN ORDER TO ^^ASSIGN MTA\N JRN\\;
WHEREAS ON THE ^^DECSYSTEM-20\\ ^^DEFINE JRN: MTA\\N: WOULD ALLOW YOU TO SPECIFY ^^MTA\\N WITHOUT YOUR JOB HAVING CONTROL OVER IT.
.
.B1
^THE RUN-UNIT AND ^^DAEMDB\\ INTERACT IN ESSENTIALLY THE SAME WAY AS TWO CONCURRENT UPDATING RUN-UNITS; EACH MAINTAINS KNOWLEDGE OF THE STATE OF THE JOURNAL (TEMP FILE) BY READING AND UPDATING THE JOURNAL'S LABEL PAGE AS NECESSARY. ^AND AS WHEN A RUN-UNIT OPENS
AN AREA (OR THE JOURNAL) WITH ^^USAGE-MODE UPDATE\\, THE RUN-UNIT WILL AUTOMATICALLY FOLLOW THE
APPLICABLE RULES OF 2.3.2.1 AND RETAIN THE DATA BASE FOR THE DURATION OF
EACH INTERLEAVING-UNIT. ^CONVERSELY ^^DAEMDB\\ DOES ITS WORK BY PERIODICALLY
COPYING THE INFORMATION IN THE JOURNAL TEMP FILE TO MAGTAPE AND THEN RETAINING
THE DATA BASE ^^ONLY LONG ENOUGH TO MAKE THE JOURNAL LABEL PAGE INDICATE
THAT DBCS CAN START WRITING TO THE BEGINNING OF THE JOURNAL FILE AGAIN\\.
.B1
^BECAUSE ^^DAEMDB\\/RUN-UNIT INTERACTION IS INTERLEAVED,
THE COST OF MAGTAPE JOURNALING IS NEARLY THE COST OF OPERATING WITH A JOURNAL OPENED WITH ^^USAGE-MODE UPDATE\\.
^THUS THE COST OF MAGTAPE JOURNALING FOR A SINGLE
UPDATER IS SOMEWHAT GREATER THAN THE COST OF DISK JOURNALING FOR
A SINGLE UPDATER. ^HOWEVER THE COST OF MAGTAPE JOURNALING AND DISK JOURNALING IS
APPROXIMATELY THE SAME FOR SIMULTANEOUS UPDATERS.
.B1
^JUST AS WITH A SHARED JOURNAL, IT IS THE USER'S RESPONSIBILITY TO GUARANTEE THAT THE PROTECTION OF THE JOURNAL TEMP FILE IS SUCH THAT EACH
ACCESSING RUN-UNIT CAN UPDATE IT. ^NOTE ALSO THAT THE NAME AND LOCATION OF THE
JOURNAL TEMP FILE IS ESTABLISHED SIMPLY BY REPLACING THE DEVICE FIELD
OF THE USER SPECIFIED JOURNAL SPEC
WITH ^^DSK\\. ^THUS THE ^^JOURNAL\\ STATEMENT OF THE ^^DMCL\\ GIVES THE USER COMPLETE CONTROL OVER THE NAME AND CHARACTERISTICS OF THE JOURNAL TEMP FILE.
.PG.B1
^THERE ARE SOME BENEFICIAL SIDE-EFFECTS TO THE FACT THAT THE JOURNAL
TEMP FILE IS AN ORDINARY DISK JOURNAL AND THAT ^^DAEMDB\\ IS A BACKGROUND TASK.
^FIRST, WHEN ^^DAEMDB\\ REACHES END-OF-REEL ON A MAGTAPE, THERE IS
NO PAUSE IN USER PROCESSING--THE RUN-UNIT'S JOURNAL TEMP FILE SIMPLY GROWS A LITTLE BIGGER THAN USUAL BEFORE IT IS COPIED TO MAGTAPE AND TRUNCATED AGAIN. ^SECOND, IF ^^DAEMDB\\ ABORTS
FOR SOME BIZARRE REASON, YOUR RUN-UNIT WILL NOT BE IMPACTED--IT WILL SIMPLY BECOME A DISK JOURNALER IN EFFECT.
^THIRD, THE MAGTAPE PART OF THE JOURNAL NEED NOT BE INVOLVED AT ALL IN YOUR USE OF ^^DBMEND\\ IF THE IMAGES WHICH ARE RELEVANT ARE
ALL STILL IN THE JOURNAL TEMP FILE--IN THIS CASE, YOU MAY SIMPLY SPECIFY
THE JOURNAL TEMP FILE SPEC (SEE ^^/UNLOAD\\ IN 2.3.2.3.3) TO THE ^^/JOURNAL\\ SWITCH
RATHER THAN THE MAGTAPE SPEC AND PROCEED AS USUAL.
(^^IMPORTANT NOTE:\\ KEEP IN MIND THAT JOURNAL PAGE TWO OF THE JOURNAL TEMP FILE, ITS FIRST DATA PAGE, IS ACTUALLY AT AN ARBITRARY POINT
IN THE PERMANENT JOURNAL. ^IN OTHER WORDS, TO GET AN ABSTRACT OF THE
JOURNAL TEMP FILE, YOU MUST "/POSIT 2" SO THAT ^^DBMEND\\ WILL KNOW IT
MUST FOLLOW "MIDDLE OF THE JOURNAL" PROTOCOL WHEN INITIALIZING THE ABSTRACT).
^FOURTH, MAGTAPE MANAGEMENT MESSAGES ARE NOT SEEN BY APPLICATION PROGRAMS. ^ONLY THE JOB CONTROLLING ^^DAEMDB\\ SEES NEW-REEL MESSAGES OR MAGTAPE ERRORS REPORTED.
.B1
^WHEN YOU DO WISH TO HAVE ^^DBMEND\\ OPERATE ON A MAGTAPE JOURNAL, THE
FOLLOWING RULES SHOULD BE OBSERVED. ^ONE, GIVE THE /^^JOURNAL\\ THE SAME FILE SPEC THAT WAS GIVEN BY THE ABORTED
RUN-UNIT(S) SO THAT ^^DBMEND\\ CAN AUTOMATICALLY LOCATE THE JOURNAL TEMP FILE AS WELL.
^TWO, DO NOT FORGET TO GIVE A /^^REELS\\ COMMAND IF THIS IS A MULTI-REEL JOURNAL.
^THREE, IF NOT ALL THE DATA IN THE JOURNAL TEMP FILE HAS BEEN COPIED TO MAGTAPE
(EG. THE SYSTEM CRASHED WHILE YOUR RUN-UNIT WAS ACTIVE), SPECIFY THE /^^COMPLETE\\ SWITCH TO
CAUSE ^^DBMEND\\ TO MERGE ANY UNMERGED JOURNAL TEMP DATA WITH THE MAGTAPE JOURNAL.
(^NOTE THAT THIS WILL PLACE THE JOURNAL TEMP FILE INTO THE DONE-WITH STATE).
^FOUR, PROCEED AS WITH A DISK JOURNAL.
.B1
^YOU MUST BE AWARE OF THE NATURE OF THE /^^COMPLETE\\ ALGORITHM TO THE FOLLOWING EXTENT.
^^DBMEND\\ BACKSPACES THREE JOURNAL PAGES AND SIMULATES A ^^/POSITION\\ "PAGE THE 1ST JOURNAL-TEMP-FILE-PAGE WILL BE".
^IF THE MAGTAPE IS IN A RANDOM POSITION, THIS OPERATION MAY FAIL. ^HOWEVER
YOU CAN GUARANTEE SUCCESS OF THIS POSITIONING BY SIMPLY DOING A ^^/REWIND\\ BEFORE THE ^^/COMPLETE\\.
.B2.LM0
2.3.2.3.5 ^THE BACKGROUND ^^MTA\\ JOURNAL PROCESSOR#-#
^^DAEMDB\\ IS SIMPLY A UTILITY TO COPY DATA FROM ONE OR MORE JOURNAL TEMP FILES TO A MATCHING SET OF ^^MTA\\ JOURNALS. ^IT RUNS AS
A BACKGROUND TASK CONCURRENTLY WITH APPLICATION RUN-UNITS AND CAN BE RUN UNDER ^^OPSER/PTYCON\\ OR AS AN ORDINARY TIME-SHARING JOB.
.PG.B1
^APPLICATION JOBS HAVE TO CAN COMMUNICATE WITH IT
VIA ^^IPCF\\ WHEN OPENING OR CLOSING THE JOURNAL--AND CAN BECAUSE THE ^^IPCF\\ NAME "^^[SYSTEM]DAEMDB\\" IS RESERVED TO IT.
^DURING AN ^^OPEN\\, THE APPLICATION WAITS UNTIL IT RECEIVES A MESSAGE BACK FROM ^^DAEMDB\\ BEFORE CONTINUEING. ^NOTE THAT
THIS WAITING PERIOD INCLUDES THE TIME FOR THE OPERATOR TO MOUNT THE TAPE UNLESS
ANOTHER APLLICATION HAS ALREADY STARTED OR A ^^/CREATE\\ WAS DONE AT
THE ^^DAEMDB\\ TERMINAL. ^SIMILARLY ON A ^^CLOSE\\, THE APPLICATION
WAITS WHEN IT DOES A "REAL" ^^CLOSE JOURNAL\\. ^ALSO DURING A ^^CLOSE JOURNAL\\, ^^DAEMDB\\ UNLOADS THE MAGTAPE AND ELIMINATES THE JOURNAL FROM ITS TABLE OF JOURNAL.
^^CLOSE\\S WHEN SOMEONE ELSE STILL HAS THE JOURNAL OPEN MERELY CAUSE
SOME TRIVIAL ACCOUNTING TO OCCUR. ^FINALLY, A ^^CLOSE RUN-UNIT\\, WHEN YOU ARE THE ONLY RUN-UNIT, COPIES ALL THE CURRENTLY REMAINING DATA FROM THE
JOURNAL TEMP FILE BUT LEAVES THE MAGTAPE OPEN AND THE JOURNAL IN ^^DAEMDB\\'S TABLE OF JOURNALS.
.B1
^TO INITIALIZE ^^DAEMDB\\ AS AN ORDINARY TIMESHARING JOB, JUST LOGIN
AND TYPE ^^R DAEMDB\\. ^TO RUN ^^DAEMDB\\ UNDER ^^OPSER\\, GIVE THIS SEQUENCE OF COMMANDS TO ^^OPSER\\:
.B1.LM5.NF.NJ
^^:SLOG 1/2
:DEF DB=
DB-R DAEMDB\\
.B1.LM0.F.J
^TO RUN ^^DAEMDB\\ UNDER ^^PTYCON\\, GIVE THIS SEQUENCE OF COMMANDS (THE $ IS AN ALTMODE):
.B1.LM5.NF.NJ
^^DEFINE $DB
DB-LOG OPERATOR ANY \\A-NUMBER^^
DB-DAEMDB\\
.B1.LM0.F.J
.B1
^^DAEMDB\\ RELIES HEAVILY UPON THE SCHEMA NAME ASSOCIATED WITH EACH
OF THE JOURNALS IT IS MANAGING. ^THE RELIANCE IS REALIZED IN TERMS OF
VOLUME IDS. ^A VOLUME ID TELLS THE OPERATOR/^^DAEMDB\\ USER WHICH MAGTAPE
TO MOUNT, AND IT WILL CONVENTIONALLY BE OF THE FORM "AAAABB" SO THAT
THE OPERATOR CAN USE PRE-LABELED TAPES. THE "A"S ARE THE FIRST LETTERS
OF THE SCHEMA NAME AND "BB" IS THE CURRENT REEL NUMBER. ^THUS IF YOUR INSTALLATION SUPPORTS MULTIPLE SCHEMAS THEIR INITIAL LETTER SEQUENCES MUST BE DIFFERENT.
^AS WELL AS IDENTIFYING TAPES FOR THE OPERATOR, THE VOLUME ID
TELLS ^^DAEMDB\\ (IN ^^ABORT, CREATE, MOUNT, RETRY\\)
WHICH OF THE "MANY" JOURNALS IT IS MANAGING TO MAKE "CURRENT".
^THUS VOLUME IDS ARE OPTIONAL ONLY IF ^^DAEMDB\\ CAN IDENTIFY THE JOURNAL FROM
AN IMMEDIATELY PRECEDING PROMPT
IT TYPED.
.B1
^THE OPERATION OF ^^DAEMDB\\ IS CONTROLLED BY THE FOLLOWING SWITCHES.
^ANY UNIQUE ABBREVIATION IS ACCEPTABLE EXCEPT FOR ^^ABORT\\, ^^EXIT\\ AND ^^STOP\\ --
THESE MUST BE SPELLED OUT.
^WHEN ^^DAEMDB\\ IS STARTED, IT PRESUMES IT JUST DID A POLLING
AND GOES TO SLEEP FOR THE DEFAULT POLLING PERIOD (=100 SECONDS).
^HOWEVER, WHETHER ^^DAEMDB\\ IS ACTIVE, SLEEPING, OR IN ^^TTY\\ WAIT,
ANY SWITCH WILL BE PROCESSED WHEN IT IS PRESENTED TO ^^DAEMDB\\. ^THE SWITCHES ARE AS FOLLOWS.
.PG.B1.LM25.TS25.I-25
^^SWITCH FUNCTION\\
.I-25
-----------------------------------------------------------
.I-25
^^ABORT\\ [DEV:][VOLID] ^^DAEMDB\\ HAS REQUESTED AN OPERATOR ACTION IN RESPONSE
TO ^^EOT\\ OR A MAGTAPE ERROR, AND THE OPERATOR HAS DECIDED THAT PROCESSING OF THE MAGTAPE PORTION OF THIS JOURNAL SHOULD BE STOPPED.
^THE DEVICE IS FOR CLARITY ONLY.
.B1.I-25
^^CREATE\\ DEV: VOLID ^PRE-ASSOCIATE A MAGTAPE TO ITS JOURNAL'S SCHEMA.
^NO APPLICATION REQUESTING THIS JOURNAL WILL EXPERIENCE A REAL-TIME
WAIT WHILE THE OPERATOR MOUNTS HIS TAPE. ^OF INCIDENTAL NOTE: ^^DAEMDB\\ WILL NOT ACTUALLY KNOW THE SCHEMA NAME UNTIL
AN APPLICATION STARTS UP...IT WILL ONLY KNOW IT APPROXIMATELY VIA
THE VOLUME ID.
.B1.I-25
^^CURRENT\\ ^TYPE OUT THE CURRENT SETTING FOR EACH MODE. ^THIS
IS BASICALLY A DEBUGGING SWITCH.
.B1.I-25
^^EXIT\\ ^EXIT TO THE MONITOR AFTER CLEARING ALL ACTIVE QUEUE REQUESTS. ^DO NOT ALLOW A ^^CONTINUE\\.
.B1.I-25
^^GO\\ ^CONTINUE AFTER A ^^STOP\\
.B1.I-25
^^HELP\\ ^PRINT THIS TABLE
.B1.I-25
^^MOUNT\\ [DEV:][VOLID] ^THE OPERATOR HAS MOUNTED A NEW MAGTAPE ON DEV: (OR THE DEVICE IN THE PROMPT
IF DEV: IS ABSENT). ^NOTE THAT ^^MOUNT\\ AND ^^ABORT\\ ARE "ANTONYMS".
.B1.I-25
^^POLL\\ SECONDS ^DEFINE AND INITIATE A NEW POLLING PERIOD.
^^DAEMDB\\ WILL SLEEP FOR N-SECONDS OR UNTIL IT HAS SOMETHING TO DO.
^THE DEFAULT POLLING PERIOD IS 100 SECONDS. (^IT IS THE JOURNAL TEMP FILES WHICH ARE BEING POLLED FOR UNCOPIED DATA).
.B1.I-25
^^RESET\\ ^SIMULATE STARTING ^^DAEMDB\\--WITH ONE DIFFERENCE--THE
EXISTING TABLE OF JOURNALS REMAINS INTACT. ^IT IS DIFFICULT TO PREDICT WHETHER THIS SWITCH IS USEFUL, BUT THE INTENT IS TO GIVE THE OPERATOR A MEANS OF GETTING ^^DAEMDB\\ BACK TO A DEFINED STATE WITHOUT LOSING
ITS TABLE OF JOURNALS.
.B1.I-25
^^RETRY\\ [DEV:][VOLID] ^TELLS ^^DAEMDB\\ TO IGNORE THE ERROR IT REPORTED
AND REPEAT THE OPERATION THAT FAILED. ^THE DEVICE WOULD BE SPECIFIED FOR
CLARITY ONLY.
^THIS COMMAND PREVENTS ^^DAEMDB\\ FROM UNNECESSARILY ABORTING AFTER A
SPURIOUS ^I/^O ERROR SUCH AS SOMETHING GOING TEMPORARILY OFF-LINE.
.B1.I-25
^^[NO]SHUTDOWN\\ ^TELL ^^DAEMDB\\ TO NOT ACCEPT ANY NEW JOURNALS AND TO DO AN ^^EXIT\\ WHEN ALL OF THE ACTIVE MAGTAPE JOURNALS HAVE BEEN CLOSED BY THE USERS.
^PREFIXING ^^NO\\ TAKES ^^DAEMDB\\ OUT OF A ^^SHUTDOWN\\ STATE, IE. IT WILL ACCEPT NEW JOURNALS.
.B1.I-25
^^STOP\\ ^RETURN TO ^^DAEMDB\\ COMMAND LEVEL IMMEDIATELY. ^THE OPERATOR WOULD PRESUMABLY USE THIS SWITCH TO
GIVE HIM TIME TO FIX
A MAGTAPE OR SOME SUCH PROBLEM.
.B1.I-25
^^THRESHOLD\\ PAGES ^TELLS ^^DAEMDB\\ TO BOTHER TO COPY AND TRUNCATE A JOURNAL TEMP FILE ONLY IF IT IS AT LEAST N-PAGES LONG. ^THE DEFAULT
THRESHOLD IS 50 JOURNAL PAGES.
.B1.I-25
^^WHAT\\ ^TYPE THE STATE OF EACH JOURNAL ^^DAEMDB\\ IS MANAGING.
.B1.LM0.F.J
^^DAEMDB\\ DOES AN "ACTION PROMPT" WHEN A MAGTAPE IS INITIALLY OPENED AND
EACH TIME THE CURRENT REEL OF A JOURNAL MUST BE REPLACED.
^THE PROMPT IS: [^^ACTION REQUIRED FOR VOLUME \\VOLID ^O^N MTA].
^ALSO, THE PROMPT MAY HAVE BEEN PRECEDED BY A MAGTAPE OR JOURNAL TEMP FILE
ERROR MESSAGE.
^IN ANY EVENT, YOU SHOULD RESPOND WITH EITHER THE /^^MOUNT\\ OR ^^/ABORT\\ OR ^^/RETRY\\ SWITCH AS APPROPRIATE.
^NOTE THAT THE PROMPT ALWAYS REFERS TO THE CURRENT REEL (VIA THE VOLID), SO THAT
TO MOUNT A NEW VOLUME YOU SHOULD EXPLICITLY GIVE THE VOLUME ID WHEN
YOU DO THE ^^/MOUNT\\.
^FINALLY, IN ORDER TO PROTECT AGAINST PARTIALLY COPIED SEQUENCES THAT
SPAN REELS, ^^DAEMDB\\ TYPES A MESSAGE WHEN THE FIRST COPY-SEQUENCE HAS BEEN COMPLETED ON A NEW REEL.
^IN OTHER WORDS, WHEN A REEL IS BEING REPLACED, ITS REPLACEMENT SHOULD NOT
BE CONSIDERED PART OF THE JOURNAL UNTIL ^^DAEMDB\\ RESPONDS WITH
[^^VOLUME\\ VOLID ^^NOW INITIALIZED]\\.
.B2.LM0
2.3.2.4 ^GUARDING ^AGAINST ^NON-COOPERATION OF ^RUN-UNITS#-#
^THERE ARE FORMS OF NON-COOPERATION THAT ARE NOT DETECTABLE EXCEPT FROM LONG-TERM SIDE-EFECTS.
^AS NOTED,
^^DBCS\\ CAN GUARANTEE THE PHYSICAL INTEGRITY OF THE DATA BASE, BUT
ONLY YOU CAN ENSURE WORLD-VIEW CONSISTENCY.
^HOWEVER THE FOLLOWING FORMS OF NON-COOPERATION ARE EITHER DETECTED BY ^^DBCS\\ OR DECLARATIVELY INHIBITED.
.B1
(^DECLARATIVE ^RESTRAINTS)
.B1.LM9.I-4
1.##^THERE IS ONE JOURNAL PER SCHEMA UNLESS A RUN-UNIT EXPLICITLY CIRCUMVENTS THIS
BY CALLING ^^JMNAME\\.
.B1.I-4
2.##^THE ^^IMAGES\\ STATEMENT PROVIDES INHERENT CO-ORDINATION OF JOURNALING AND RUN-UNIT INTERLEAVING.
.B1.I-9
(^PROCEDURAL ^CONSTRAINTS)
.B1.I-4
3.##^IF YOU ATTEMPT TO OPEN AN AREA WITH ^^USAGE-MODE UPDATE\\ AND
ALREADY HAVE ^^OPEN\\ED YOUR JOURNAL EXCLUSIVELY, EXCEPTION
CODE 0938 WILL BE RETURNED.
.B1.I-4
4.##^IF YOU HAVE A SHARED JOURNAL, THE ONLY WAY IN WHICH YOU CAN USE ^^JBTRAN\\ IS AS FOLLOWS: IN TRANSACTION MODE AND WITH AN ARGUMENT OF 0.
^OTHERWISE, EXCEPTION CODE 1645 IS RETURNED.
.B1.LM0
^THERE IS ONE "SPECIAL" FORM OF NON-COOPERATION. ^IF AN UPDATING
RUN-UNIT ABORTS ABNORMALLY, OTHER RUN-UNITS ARE "IN DANGER" OF ACCESSING A DATA BASE WHICH IS POTENTIALLY
IN AN UNDEFINED STATE.
^HOWEVER IT IS ONLY AN ILLUSION FOR A VERY SIMPLE REASON.
^SO LONG AS A ^^RESET\\ IS NOT DONE BY THE ABORTED JOB, ALL THE
LOCKS IT HAD IN PLACE TO PREVENT TRESPASS ARE STILL IN PLACE.
^THUS, IF THE SITE DOES NOT PANIC BY ALLOWING A ^^RESET\\ TO BE EXECUTED BY THE ABORTED JOB,
IT WILL HAVE ALL THE TIME IN THE WORLD TO EVALUATE THE SITUATION AND REACT ACCORDINGLY (EG. TERMINATE ALL THE RUN-UNITS AND RESTART
ENTIRELY, DO A ^^RESET\\ BECAUSE THE ABORTING RUN-UNIT DID
NOT INJURE THE INTEGRITY OF THE DATA BASE).
.B2
2.3.3##^MISCELLANEOUS ^CHANGES
.B2
2.3.3.1 ^UNROUNDED ^LOGICAL ^PAGE ^SIZE#-#
^BEFORE ^V5, EACH PAGE SIZE SPECIFIED IN THE ^^DMCL\\ WAS ROUNDED UP TO THE NEXT MONITOR-DEFINED
UNIT OF DISK STORAGE (IE. 128-WORD MULTIPLES ON THE 10 AND 512-WORD MULTIPLES ON THE 20).
^HOWEVER THIS IS NOT STRICTLY NECESSARY...THE PHYSICAL PAGE SIZE MUST BE
SUCH A MULTIPLE, BUT THERE IS NO REASON WHY THE LOGICAL PAGE SIZE CANNOT BE AS WAS SPECIFIED IN THE ^^DMCL\\. ^ADDITIONALLY THERE ARE
TWO REASONS TO SUPPORT THIS DISTINCTION: (1) IT ENABLES A SITE
TO ACCOUNT FOR DATA EXPANSION BY FILLING AN AREA IN LAYERS (IE. BY GRADUALLY INCREASING PAGE SIZE) (2) AS IMPLIED IN SECTION 2.3.1.3.2, IT WOULD MAKE A GENERAL PURPOSE CONVERSION UTILITY SOMEWHAT
EASIER TO USE.
.B1
^THIS FEATURE DOES NOT IMPACT EXISTING DATA BASES; THE EFFECT
OF UNROUNDED LOGICAL PAGE SIZES IS FELT AT PRECISELY ONE TIME ONLY,
WHEN A NEW RECORD IS STORED.
.B2
2.3.3.2 ^SPECIFYING A ^LIMIT TO ^JOURNAL ^SIZE#-#
^THE ^^JOURNAL\\ STATEMENT OF THE ^^DMCL\\ HAS BEEN EXTENDED TO
PROVIDE YOU A MEANS OF PREVENTING A DISK JOURNAL FROM GROWING TO AN ARBITRARY SIZE. ^BY APPENDING,
.B1.C
^^SIZE\\ [^I^S] INTEGER [^^TRANSACTIONS\\]
.B1
TO THE END OF A ^^JOURNAL\\ STATEMENT, YOU WILL CAUSE
^^DBCS\\ TO REPOSITION ITS JOURNAL FILE POINTER TO THE BEGINNING OF
THE JOURNAL AFTER EVERY (INTEGER)TH TRANSACTION.
^THUS, A SITE COULD USE THIS FEATURE IF ITS SITUATION IS SUCH
THAT IT KNOWS IT WILL NEVER NEED TO BACKUP A DATA BASE MORE
THAN (INTEGER) TRANSACTIONS.
^THIS CLAUSE APPLIES TO ANY RUN-UNIT THAT HAS A DISK JOURNAL
WHICH IS EITHER UNSHARED OR FOR WHICH IMAGES ARE NOT ORDERED BY COMMAND.
.B1
(^NOTE: A SECONDARY BENEFIT OF THIS FEATURE IS THAT
DISK JOURNAL EFFICIENCY IS IMPROVED BECAUSE IT IS CHEAPER TO REWRITE A JOURNAL PAGE THAN
TO EXTEND A JOURNAL.)
.B2.LM0
2.3.3.3 ^^/CONVERT\\ SWITCH FOR ^^SCHEMA\\ AND ^^DBMEND\\#-#
^THE ^^/CONVERT\\ SWITCH HAS BEEN ADDED TO SUPPORT ^^V3TOV5\\ AND
TO LAY THE GROUNDWORK FOR A GENERAL PURPOSE DATA BASE REDEFINITION UTILITY.
.B1
^^/CONVERT\\ TELLS ^^SCHEMA\\ TO GENERATE ^^.DBN\\ FILES AND A ^^.SCN\\ FILE RATHER THAN ^^.DBS\\ FILES AND A ^^.SCH\\ FILE.
.B1
^CONVERSELY ^^/CONVERT\\ SETS ^^DBMEND\\ TO PROCESS ^^.??N\\ FILES
AND ^^/NOCONVERT\\ RETURNS ^^DBMEND\\ TO ITS NORMAL MODE.
^WHEN YOU NEED TO USE A [^^NO]CONVERT\\ SWITCH, IT SHOULD PRECEDE THE ^^JOURNAL\\ OR (^^SCHEMA\\) SWITCH AND ALL ^^OPEN\\S SO THAT ALL RELEVANT FILES WILL BE PROCESSED IN THE CORRECT/SAME MODE.
.B2.LM0
2.3.3.4 ^^UNANTICIPATED\\ AS AN ^^INTERCEPT\\ OPTION#-#
^IF ONE SPECIFIES ^^INTERCEPT\\ (OR ^^NOTE\\) ^^UNANTICIPATED EXCEPTIONS\\, ALL EXCEPTIONS OTHER THAN 307 AND 326 WILL BE
INTERCEPTED (OR NOTED).
^THE PURPOSE OF THIS OPTION IS TO SUPPRESS INTERCEPTION ONLY FOR
THOSE EXCEPTIONS WHICH ARE (NORMALLY) USED TO CONTROL PROGRAM FLOW.
.B2
2.3.3.5 ^THE ^^/UNFLAGGED\\ SWITCH FOR ^^FORDML\\#-#
^THIS SWITCH ALLOWS A ^^FORDML\\ USER TO (OPTIONALLY) OMIT
THE "* ^^DBMS\\" LINE FOR SINGLE-LINE ^^DML\\ STATEMENTS, PROVIDED NO OTHER LINE IN THE PROGRAM HAS "PERIOD" AS ITS
LAST NON-BLANK NON-REMARK CHARACTER.
^THE PURPOSE OF THIS SWITCH IS TO ALLOW FOR SMALLER, MORE READABLE ^^FORDML\\ PROGRAMS AT THE PRICE OF CONFORMING TO ONE ADDITIONAL LEXICAL RULE.
.B2
2.3.3.6 ^THE ^^USE\\ STATEMENT#-#
^IT HAS BEEN MADE EASIER TO ASSOCIATE A VARIETY OF EXCEPTIONS WITH A ^^USE\\ PROCEDURE. ^GENERIC EXCEPTION CODES: ONE CAN SPECIFY
XX00 TO ASSOCIATE THE PROCEDURE TO ANY EXCEPTION FOR STATEMENT "XX".
^GENERIC STATEMENT CODES: ONE CAN SPECIFY 00YY TO ASSOCIATE THE
PROCEDURE TO THE EXCEPTION REGARDLESS OF THE EXECUTING STATEMENT.
^GRAB BAG PROCEDURE: ^^USE ERROR-STATUS.\\ WILL CAUSE APPLICATION OF ITS PROCEDURE TO EACH EXCEPTION WHICH IS NOT COVERED BY AN
EARLIER ^^USE\\ STATEMENT IN THE PROGRAM (CONVERSELY ANY ^^USE\\ STATEMENT AFTER THIS STATEMENT WOULD BE A NO-OP).
.B2.LM0
2.3.4##^SUMMARY OF ^ENVIRONMENTAL ^CHANGES
.B1
^THE FOLLOWING KEYWORDS HAVE BEEN ADDED
TO THE ^^DML\\: ^^JMDISK\\ (A USER-CALLABLE ENTRY) AND ^^JOURNAL\\.
^THE FOLLOWING KEYWORDS HAVE BEEN ADDED TO ^^SCHEMA\\: ^^TRANSACTIONS\\.
^THE /^^CONVERT\\ SWITCH HAS BEEN ADDED TO ^^SCHEMA\\ AND ^^DBMEND\\.
^EXCEPTIONS 46, 65, 66, AND 67 HAVE BEEN ADDED.
^EXCEPTIONS 38 HAVE BEEN GIVEN A DIFFERENT DEFINITION.
^EXCEPTIONS 31, 40, 45, 61 AND 63 HAVE BEEN GIVEN MORE GENERAL MEANINGS.
^SEE SECTION 2 SUBSECTION 2.1.5 FOR THE UPDATED EXCEPTIONS TABLE.
.PG.B3.LM0
3.0##^^KNOWN BUGS AND DEFICIENCIES\\
.B1.LM9.I-4
1.##^A ^^DBMS\\ APPLICATIONS PROGRAM CANNOT BE RESTARTED BY THE CTRL-^C/^^START\\ SEQUENCE; ONE CAN ONLY ^^RUN\\ (^^GET/START\\) A ^^DBMS\\ PROGRAM.
.B1.I-4
2.##^IF THE ^^CLOSE\\ STATEMENT SIGNALS AN EXCEPTION,
THE STATE OF THE SYSTEM WILL NOT BE BACKED UP TO WHAT IT WAS BEFORE THE ^^CLOSE\\.
.B1.I-4
3.##^EXPLICIT ^^SFD\\'S ARE NOT SUPPORTED IN FILE SPECS.
.B1.I-4
4.##^NO .^^DBS\\ FILE (IE. ^^DBMS-10\\ AREA) MAY HAVE A PAGE RANGE SUCH THAT IT COULD GROW TO LARGER THAN 256,000 DISK BLOCKS (ONE BLOCK=128 WORDS).
.B1.I-4
5.##^THE WORD ^^DBMS\\ IS A RESERVED WORD IN THE ^^COBOL\\ COMPILER,
BUT THIS FACT IS NOT PROPERLY DOCUMENTED NOR PROPERLY FLAGGED AS AN ERROR.
.B1.I-4
6.##^USER SYMBOLS IN AN ^^INVOKE\\ OR ^^ACCESS\\ STATEMENT
CONSTITUTE USER VARIABLES AS FAR AS THE ^^COBOL\\ COMPILER IS CONCERNED. ^THEREFORE THEY MAY NOT BE DECLARED ANYWHERE ELSE IN THE ^^DATA DIVISION\\.
.B1.I-4
7.##^IF EXCEPTION 03 (DATA-NAMES FROM WRONG RECORD) OCCURRED
DURING A ^^GET\\, THE ^^UWA\\ MAY NOT BE LEFT THE SAME AS IT WAS BEFORE THE VERB WAS EXECUTED.
.B1.I-4
8.##^AN AREA CANNOT BE SIMULTANEOUSLY ^^OPEN\\ TWICE (IE. BY TWO SUB-SCHEMAS OF THE SAME SCHEMA) IN A RUN-UNIT.
.B1.I-4
9.##^FLOATING POINT NUMBERS CANNOT BE DUMPED BY ^^DBINFO\\ ON A ^^KA10\\.
.B1.I-5
10.##^^COBOL\\ AND ^^FORTRAN\\ PROGRAM-UNITS BOTH CONTAINING ^^DML\\ STATEMENTS CANNOT BE MIXED IN THE SAME LOAD-UNIT
BECAUSE THE FORM OF THE SPECIAL REGISTERS IS DIFFERENT IN ^^COBOL\\ AND ^^FORTRAN\\.
.B1.I-5
11.##^THE "NAME" SPECIAL REGISTERS (EG. ^^ERROR-RECORD\\) CANNOT BE SIMPLY COMPARED TO ^^COBOL\\ LITERALS BECAUSE THE FORMER ARE ^^ASCIZ\\ STRINGS (TO FACILITATE DISPLAYING THEM).
^TO ACCOMPLISH THE COMPARISON, DO AN ^^EXAMINE LOW-VALUES TO SPACES\\ TO THE STRING.
.PG.B3.LM0
4.0##^^INSTALLATION INSTRUCTIONS\\
.B1
^TO INSTALL <DBMS-10, FOLLOW THE INSTRUCTIONS BELOW:
.B1.LM9.I-4
1.##^TO PLACE <DBMS-10 ON <SYS:, FOLLOW THIS PROCEDURE:
.B1.LM13.I-4
A.##^MOUNT THE <DBMS-10 DISTRIBUTION TAPE (MARKED <QH101) ON <MTA0:, AND TYPE THE FOLLOWING COMMANDS:
.B1.NF.NJ
^^R BACKUP
TAPE MTA0:
REW
INTERCHANGE
DENSITY\\ INSTALLATION-DEPENDENT
^^RESTORE SYS:*.*=DSKB:[10,6]*.EXE
REW
RESTORE SYS:*.*=DSKB:[10,6]*.HLP
REW
_^C\\
.B1.LM9.F.J.I-4
2.##^TO PREPARE TO (RE)LOAD <DBMS-10 (OR PARTS THEREOF):
.B1.LM13.I-4
A.##^MOUNT THE <DBMS-10 DISTRIBUTION TAPE (MARKED <QH101) ON <MTA0:, AND TYPE THE FOLLOWING COMMANDS:
.B1.NF.NJ
^^R BACKUP
TAPE MTA0:
REW
INTERCHANGE
DENSITY\\ INSTALLATION-DEPENDENT
RESTORE *.*=DSKB:[10,6]*.*
REW
_^C\\
.B1.LM0.F.J
^THE COMPONENTS OF THE ^^DBMS\\ PACKAGE, ARE AS FOLLOWS:
.B1.LM5.NF.NJ
^^SCHEMA
FORDML
COBOL\\ INTERFACE
^^DBCS
DBMEND
DBINFO
DAEMDB\\
.B2.LM0.F.J
4.1##^CONVERTING ^EXISTING ^APPLICATIONS
.B1
^THERE IS AN INHERENT OVERLAP BETWEEN THIS SECTION AND SECTION
2.3.1 SINCE ^^V3TOV5\\ IS REALLY
A UTILITY TO FACILITATE INSTALLATION OF ^^DBMS-V5\\ BY VERSION 3 SITES--RATHER THAN A SOFTWARE PRODUCT.
^ACCORDINGLY THIS SECTION ATTEMPTS TO EXPLAIN WHERE ^^V3TOV5\\
FITS INTO THE INSTALLATION PROCEDURE, WHILE SECTION 2.3.1 EXPLAINS IN
DETAIL THE STEPS INVOLVED IN USING IT.
.PG.B1
^STEPS TO CONVERT YOUR ^V3 DATA BASE:
.B1.LM9.I-4
1.##^SECTION 2.2 SHOULD BE READ CAREFULLY, AND
APPLICATION SOURCE FILES SHOULD BE CHANGED
TO REFLECT THE INCOMPATIBILITIES DESCRIBED THERE.
.B1
^THE PRIMARY CHANGE IS TO THE SCHEMA ^^DDL\\ DATA-NAME ENTRY, AND INVOLVES CHANGING ^^USAGE COMP\\...
TO ^^TYPE\\... AND MOVING ALL TEXT (IE. 03 NAMES) INTO THE APPROPRIATE SUB-SCHEMAS.
.B1
^THE ONLY ^^DML\\ CHANGE THAT IS LIKELY TO CAUSE ANY SOURCE ALTERATIONS AT ALL IS THAT
SUCCESSFUL ^^FIND\\S AND ^^STORE\\S NO LONGER SET UP ^^AREA-NAME\\ AND ^^RECORD-NAME\\...THE ^^MOVE\\ STATEMENT MUST BE USED INSTEAD.
.B1.I-4
2.##^READ SECTION 2.3.1 ON HOW TO USE ^^V3TOV5\\.
.BR
^HOWEVER IF YOU INTEND TO RELOAD RATHER THAN CONVERT, JUST DELETE
YOUR ^^DBS\\ FILES AND ^^SCH\\ FILE AND TRANSLATE YOUR CONVERTED
^^DDL\\ PROGRAM WITH ^^SCHEMA\\ ^V5 BEFORE RUNNING YOUR RELOADING PROGRAM.
.B1.I-4
3.##^THE HOST-LANGUAGE INTERFACE HAS CHANGED. ^EXISTING PROGRAMS MUST BE
(RE-PREPROCESSED AND) RECOMPILED WITH THE ^^COBOL\\ AND/OR ^^FORTRAN\\ SYSTEMS BUILT FROM THIS TAPE.
.B2.LM0
4.2##^CONFIGURING THE ^SYSTEM ^SOFTWARE
.B1.LM9.I-4
1.##<DBMS<N0 IS SHORTHAND FOR <DBMS10/DBMS20.
.B1
<TOPS-10 SETS SHOULD READ IT AS <DBMS10
.BR
<TOPS-20 SETS SHOULD READ IT AS <DBMS20
.B1.I-4
2.##^IF ^^COBOL\\ SUPPORT IS DESIRED:
.B1.LM13.I-4
A.##^READ ^^COBOL.MEM\\ IN THE 1ST SAVE SET OF THE ^^COBOL\\ DISTRIBUTION TAPE (MARKED <QH504). ^IT WILL
EXPLAIN HOW TO PLACE ^^LIBOL.REL AND ^^LIBSHR.REL\\ ONTO DISK.
.B1.I-4
B.##^MAKE SURE THAT YOUR NON-^^DBMS\\ COPY OF ^^LIBOL.REL\\ AND ^^LIBSHR.REL\\ ARE IN THE DIRECTORY
FROM WHICH ^^DBMS\N0.CTL\\ WILL BE SUBMITTED.
.B1.LM9.I-4
3.##^IF ^^FORTRAN\\ SUPPORT IS DESIRED:
.B1.LM13.I-4
A.##^READ ^^FORTRA.MEM\\ IN THE 1ST SAVE SET OF THE ^^FORTRAN\\
DISTRIBUTION TAPE (MARKED <QH500). ^IT WILL EXPLAIN HOW TO
PLACE ^^FORLIB.REL\\ ONTO DISK.
.B1.I-4
B.##^MAKE SURE THAT YOUR NON-^^DBMS\\ COPY OF ^^FORLIB.REL\\ IS IN THE
DIRECTORY FROM WHICH ^^DBMS10/20.CTL\\ WILL BE SUBMITTED.
.PG.B1.LM9.I-4
4.##^READ ^^DBMS\N0.CTL\\.
.B1.LM13.I-4
A.##^IN PARTICULAR, THERE ARE ^^DEFINE\\S (^^TOPS-20\\) AND ^^ASSIGN\\S (^^TOPS-10\\) AT THE BEGINNING OF THE ^^CTL\\ FILE.
^ALTER THE LOGICAL ASSIGNMENTS THEREIN AS NECESSARY FOR YOUR SITE.
.B1.I-4
B.##^TO LOAD JUST THE ^^OTS\\S, DO THIS SUBMIT:
.B1.I5
^^SUB DBMS\N0/RES/TIM:15:\\.
.B1
^TO LOAD ALL THE NON-^^OTS\\ COMPONENTS AS WELL, DO THIS SUBMIT INSTEAD:
.B1.I5
^^SUB DBMS\N0/RES/TIM:30:/TAG:DBALL\\.
.B1.I-4
C.##^IF EXECUTION OF ^^DBMSN\0.CTL\\ SHOULD ABORT, YOU SHOULD
REPERFORM STEPS 2B AND/OR 3B BEFORE REPEATING STEP 4B.
.B1.LM9.I-4
5.##^COPY THE BUILT HOST SYSTEMS TO ^^SYS:\\
.B1.LM13.NF.NJ
^^LIBOL.REL\\ TO ^^SYS:LIBOL.REL\\
^CDBOTS.EXE\\ TO ^^SYS:LIBO11.EXE\\
.I5
AND/OR
^^FORLIB.REL\\ TO ^^SYS:FORLIB.REL\\
^^FDBOTS.EXE\\ TO ^^SYS:FOROTS.EXE\\
.B1.LM9.F.J.I-4
6.##^COPY *.^^HLP\\ AND *.^^EXE\\ FROM THE 2ND SAVE SET
OF THE ^^DBMS\\ TAPE TO THE APPROPRIATE SYSTEM DEVICE.
.B1.I-4
7.##^IF SUPPORT OF ^^MTA\\ JOURNALING IS DESIRED AND YOU WISH TO RUN ^^DAEMDB\\ UNDER ^^OPSER/PTYCON\\, INSERT AT LEAST THESE COMMANDS
INTO YOUR SYSTEM-RESTART AUTO FILE (SEE 2.3.2.3.5 FOR HOW TO SETUP NON-DEFALT VALUES FOR ^^DAEMDB\\'S CONTROLLING PARAMETERS):
.B1
^FOR ^^TOPS-10\\:
.B1.I5
^^:SLOG 1/2
.I5
:DEF DB=
.I5
DB-R DAEMDB\\
.B1
^FOR ^^TOPS-20\\ (THE $ IS AN ALTMODE):
.B1.I5
^^DEFINE $DB
.I5
DB-LOG OPERATOR ANY 77777
.I5
DB-DAEMDB\\
.B1.LM9.F.J
^IF YOU WISH TO RUN ^^DAEMDB\\ AS AN ORDINARY TIME-SHARING JOB, SIMPLY LOGIN A JOB AND TYPE ^^R DAEMDB\\ EACH TIME YOUR SYSTEM STARTS UP.
.B1
^^IMPORTANT\\: FOR THE TIME BEING AT LEAST, ONE MUST PRE-ASSIGN MAGTAPES
TO THE ^^DAEMDB\\ JOB ON ^^TOPS-10\\. ^TO DO THIS, SIMPLY DO 1 OR MORE ^^MOUNT\\ COMMANDS BEFORE TYPING ^^R DAEMDB\\.
.PG.B1.I-4
8.##^^DBMS-V5\\ UTILIZES THE ^^ENQ/DEQ\\ FACILITY.
^CONSEQUENTLY YOU SHOULD ENSURE THAT YOUR SYSTEM IS CONFIGURED SUCH THAT
SUFFICIENT MONITOR FREE SPACE
IS AVAILABLE TO YOUR ^^DBMS\\ USERS, AND THAT EACH ^^DBMS\\ USER HAS
GLOBAL-^^ENQ\\ CAPABILITIES AND AN ADEQUATE ^^ENQ\\ QUOTA.
^FOR ^^TOPS-10\\ USE ^^REACT\\ TO SET QUOTAS AND CAPABILITIES
(^^ENQ\\ CAPABILITY IS BIT 11 (IE. 100,,0) OF THE CAPABILITIES WORD).
^FOR ^^TOPS-20\\, USE _^^ECREATE TO SET ^^ENQ\\ CAPABILITY.
^ALSO, SEE ^^ENQ/DEQ\\ IN THE MONITOR
INSTALLATION GUIDE. ^AS REGARDS QUANTIFYING YOUR NEEDS, THEY ARE APPROXIMATELY: 2 LOCKS FOR EACH OPEN AREA PLUS 2 LOCKS PER RUN-UNIT.
.B1.I-4
9.##^IF MAGTAPE JOURNALING IS DESIRED, THE COMMENTS REGARDING ^^ENQ/DEQ\\ APPLY TO ^^IPCF\\ AS WELL. ^AS REGARDS QUANTIFYING YOUR NEEDS,
THEY ARE APPROXIMATELY 1 SEND AND 1 RECEIVE FOR EACH APPLICATION RUN-UNIT;
AND (N) SENDS AND RECEIVES FOR ^^DAEMDB\\, WHERE (N) IS THE NUMBER OF SIMULTANEOUS MAGTAPE JOURNALERS.
.B3.LM0.F.J
5.0##^^INTERNAL CHANGES\\
.B1
^THE LIST OF INTERNAL DIFFERENCES IS NOT TRULY ORDERED, BUT THERE IS SOME ATTEMPT TO GROUP
THE ^^DML\\ CHANGES AND TO GROUP THE FILE-AFFECTING CHANGES.
^EXCEPT WHERE NOTED, THESE NOTES ARE DIFFERENCES BETWEEN ^V3 AND ^V4 (OR ^V5).
^DIFFERENCES BETWEEN ^V4 AND ^V5 ARE NOTED INDIVIDUALLY.
.B1.LM9.I-4
1.##^IN EARLIER VERSIONS EACH REFERENCE TO A RECORD, AREA, DATA, OR SET NAME IN A ^^DML\\
STATEMENT WOULD CAUSE A CHARACTER STRING, REPRESENTING THE NAME, TO BE PASSED TO ^^DBCS\\. ^FOR EXAMPLE,
^^GET REC1\\ WOULD HAVE TRANSLATED TO ^^CALL GET('REC1')\\ IN ^^FORTRAN\\ AND ^^ENTER MACRO GET USING "REC1"\\ IN ^^COBOL\\.
^IN VERSION 4, THE REFERENCE TO ^^REC1\\ WILL BE REPLACED
BY AN INDEX INTO A TABLE (ASSIGNED DURING SCHEMA PROCESSING), RATHER
THAN A CHARACTER STRING.
.B1
^HOWEVER IF THE USER WISHES TO EXPLICITLY CALL A ^^DBCS\\ ENTRY POINT,
HE MAY STILL PASS A STRING--WHICH WILL BE DYNAMICALLY CONVERTED TO ITS TABLE
INDEX.
^IN OTHER WORDS, ALTHOUGH ^^FORDML\\(OR ^^COBOL\\) WILL GENERATE ^^CALL GET(\\INTEGER), THE USER CAN STILL CODE ^^CALL GET('REC1')\\ IN HIS PROGRAMS.
^HOWEVER, THIS STRING PROCESSING ABILITY APPLIES ONLY TO RECORD, SET, AND AREA NAMES--AND NOT TO DATA-NAMES BECAUSE DATA-NAMES ARE SIMPLY NOT MAINTAINED INTERNALLY AT RUN-TIME.
.PG.B1.I-4
2.##^SIMILARLY, KEYWORDS SUCH AS ^^NEXT\\ WERE PASSED AS CHARACTER STRINGS. ^THESE ARE NOW PASSED AS NEGATIVE NUMBERS (TO DISTINGUISH THEM FROM THE TABLE INDEXES) AND ARE AS FOLLOWS:
.B1.LM16.TS32.NF.NJ
^^KEYWORD CODE
----------------------
ONLY #-10
SELECTIVE #-11
FIRST #-12
LAST #-13
PRIOR #-14
NEXT #-15
DUPLICATES #-16
ALL #-17
AREA #-18
RECORD #-19
SET #-20
UPDATE #-21
RETRIEVAL #-22
RUNUNIT #-23
PROTECTED #-24
EXCLUSIVE #-25
RESERVED #-26
RESERVED #-27
JOURNAL #-28\\#####(^V5 ONLY)
.B1.LM9.F.J
^WHEN A KEYWORD IS EXPECTED,
A 0 ARGUMENT INDICATES A DEFAULT (OR ABSENT) KEYWORD. ^AND THE ARGUMENT INDICATES AN ABSENT USER-NAME WHEN A NAME IS EXPECTED.
.B1.I-4
3.##^AN INDEXED SEQUENTIAL ACCESS METHOD WILL BE USED TO
ADD MEMBERS TO AND TO SEARCH SORTED SET OCCURRENCES. ^THIS WILL GREATLY
SPEED UP ^^STORE\\S, ^^INSERT\\S, AND ^^MODIFY\\S THAT ACCESS SORTED SETS.
^THE INDEX STRUCTURE WILL BE A ^B-TREE IN WHICH EACH INDEX BLOCK
IS BIG ENOUGH TO CONTAIN 16 SORT-KEY/DBKEY PAIRS, UNLESS
16 KEYS WOULD REQUIRE MORE THAN 120 WORDS. ^IN THIS CIRCUMSTANCE,
THE INDEX BLOCK SIZE WILL BE N*PAIR-SIZE WHERE (N) IS SUCH THAT
THE PRODUCT IS AS NEAR AS POSSIBLE TO 120 AND STILL LESS THAN 120.
.B1.I-4
4.##^THE ^^DELETE\\ VERB WILL ALWAYS COMPLETELY DELETE ANY
RECORD THAT IT PROCESSES. ^IN OTHER WORDS, THE RECORD WILL BE
REMOVED FROM EACH SET IT IS IN AND ALL SPACE ASSOCIATED WITH THE
RECORD WILL BE RETURNED TO THE FREE POOL.
.PG.B1.I-4
5.##^^FIND\\ INTEGER OF ^^SET/AREA\\ WILL NO LONGER GENERATE A
CALL TO ^^FIND3\\. ^INSTEAD IT WILL GENERATE A CALL TO THE NEW ENTRY
POINT, ^^FINDO\\.
.B1.I-4
6.##^THE ^^FUNCT.\\ ^^OTS\\ INTERFACE FACILITY, CREATED TO SUPPORT
^^LINK\\ OVERLAYS, WILL BE USED BY ^^DBCS\\ FOR ITS OWN ^^OTS\\ INTERFACING. ^^FUNCT.\\ IS DOCUMENTED IN AN APPENDIX OF THE ^^LINK\\ MANUAL.
.B1.I-4
7.##^THE FORMAT OF AN AFTER-IMAGE DIRECTORY FILE (^^.RCV\\ FILES WERE
AN EXAMPLE OF THIS TYPE OF FILE) HAS BEEN CHANGED SLIGHTLY.
^THE FIRST (N) PAGES OF AN AREA ^^.TMP\\ FILE ARE THE DIRECTORY, AND THERE
ARE ^^PAGESIZE\\*2 ENTRIES PER DIRECTORY-PAGE (IE. 18 BITS PER ENTRY).
^THUS N=!^^PAGERANGE\\/^^PAGESIZE\\*2!.
^THE ENTRIES ARE ARRANGED SUCH THAT THE LEFT-HALF OF THE FIRST WORD
CONTAINS THE FIRST PAGE POINTED TO BY THIS DIRECTORY-PAGE, THE
LEFT-HALF OF THE 2ND WORD CONTAINS THE 2ND PAGE, AND SO ON...
THUS THE RIGHT-HALF OF THE FIRST WORD OF THE DIRECTORY-PAGE
POINTS TO THE (^^PAGESIZE\\#+#1)TH PAGE.
.B1
^ALSO, THE MECHANISM BY WHICH ^^.DBS\\ FILES ARE EXTENDED IN ^V4
IS SUCH THAT UNREFERENCED PAGES WILL NOT BE PLACED IN THE AREA ^^.TMP\\
FILE. ^THUS TEMPORARY AREAS ARE NOW
IDEAL FOR DEBUGGING WHEN CALC RECORDS (WHICH ARBITRARILY EXTEND ^^.DBS\\ FILES) ARE INVOLVED.
.B1.I-4
8.##^THE SYMBOL BLOCKS IN A ^^.SCH\\ FILE AND THOSE CREATED DURING ^^BIND\\ING
ARE SOMEWHAT DIFFERENT THAN THEY WERE IN EARLIER VERSIONS.
(^A COMPLETE DESCRIPTION OF EACH TYPE OF SYMBOL BLOCK WILL APPEAR IN THE VERSION 4 MANUALS--AND DOES APPEAR IN
THE ^^UNV\\ SOURCE FILE ^^DBSDCL.MAC\\, WHICH IS ON THE DISTRIBUTION TAPE.)
.B1.I-4
9.##^THE FORMAT OF A PAGE IN A ^^.DBS\\ FILE HAS BEEN CHANGED TO IMPROVE
RECORD ACCESSING EFFICIENCY (AND GENERALIZED TO SUPPORT MULTIPLE CALC-CHAINS
PER PAGE). ^THE FORMAT IS AS FOLLOWS (WHERE ^^PAGESIZE\\ IS P):
.B1.LM12.TS26.NF.NJ
WORD 0: PAGE-NUMBER
WORD 1: I ! J
N WORDS: CALC-CHAIN POINTERS
WORD N+2: DATA WORD
#####:
#####:
WORD J-1: LAST DATA WORD
(WORD J##THRU##WORD P-I-1 ARE NOT IN USE)
WORD P-I: SEE ^^DBSDCL\\!OFFSET OF RECORD I
#####:
#####:
WORD P-1: SEE ^^DBSDCL\\!OFFSET OF RECORD 1
.B1.LM9.F.J
.PG.B1
^THE VALUE (I) IS THE HIGHEST RECORD NUMBER EVER USED ON THIS PAGE.
^THE VALUE (J) IS THE OFFSET OF THE FIRST WORD WHICH DOES NOT CONTAIN
DATA. ^THE VALUE (N) IS 0 OR MORE AND IS THE INTEGER GIVEN IN THE
^^CALC RPP\\ CLAUSE IN THE ^^ASSIGN\\ STATEMENT FOR THIS AREA.
^WORD P-1 BACK THRU WORD P-I ARE THE LINE HEADERS OF LINE-1 THRU LINE-I.
^FOR DETAILS, SEE ^^PH.*\\ AND ^L^H.* IN ^^DBSDCL.MAC\\.
.B1.I-5
10.##^THE 128-WORD PREFIX SECTOR HAS BEEN SUPPLANTED BY THE AREA STATUS RECORD, SEE SUBSECTION 2.1.5.3.
.B1.I-5
11.##^THE ^^ENQUEUE/DEQUEUE\\ FACILITY, RATHER THAN READER COUNTS, IS
USED IN VERSION 4 TO CONTROL CONCURRENT ACCESS TO AN AREA. ^NOTE THAT
THIS MEANS THAT RETRIEVAL-ONLY AREAS NO LONGER HAVE TO BE PROTECTED _<022>.
.B1.I-5
12.##^ALL SYSTEM PROCESSED STRINGS WILL BE REPRESENTED IN ^^ASCII\\ (RATHER THAN ^^SIXBIT\\), IE. THE RELEVANT SPECIAL
REGISTERS, ^^AREA-ID\\S, AND PRIVACY LOCKS.
.B1.I-5
13.##[^V5 ONLY] ^JOURNAL PAGE HEADERS HAVE BEEN EXPANDED FROM 4 TO 6 WORDS AND LOGICAL BLOCKS HAVE BEEN EXPANDED TO 3 WORDS, BOTH
TO ACCOMODATE SIMULTANEOUS UPDATE.
^THE MAKE-UP OF THESE HEADERS IS DETAILED IN ^^DBSDCL.MAC\\.
.B1
^BECAUSE THIS IS SUCH A COMPLICATED UPGRADE, NO BUG FIXES WILL BE DESCRIBED.
^WE WISH THIS UPGRADE TO CONSOLIDATE ^^DBMS\\.
.B3.LM0
6.0##^^SUGGESTIONS\\
.B1
^NONE.
.B3
[^END OF <DBMS5.DOC]