MDBS APPLICATION PROGRAMMING REFERENCE MANUAL
-The MDBS DMS MANUAL
Version 3.08
Micro Data Base Systems, Inc.
P. O. Box 248
Lafayette, Indiana 47902
USA
Telex: 209147 ISE UR
(312) 303-6300 (in Illinois)
December 1985
Copyright Notice
This entire manual is provided for the use of the customer and the customer 's employees . The entire contents have been copyrighted by Micro Data Base Systems,
Inc . , and reproduction by any means is prohibited except as permitted in a written
agreement with Micro Data Base Systems, Inc.
(C) COPYRIGHT 1981 Micro Data Base Systems, Inc. Rev. 85A
NEW RELEASES, VERSIONS, AND A WARNING
Any programming endeavor of the magnitude of the MDBS software
will
necessarily continue to evolve over time. ReaHzing
this,
Micro Data " Base Systems, Inc., vows to provideits
users with updates tothis
version for a nominal handling fee.
New versions of MDBS software
will
be considered as separate products.However, bona fide owners of previous versions are generally
entitled
to a preferential rate structure.
Finally,
each copy of our softwareis
personalized toidentify
thelicensee. There are several levels of
this
personalization,' some ofwhich involve encryption methods guaranteed to be
combinatorially
difficult
to decipher. Our products have been produced with a verysubstantial
investment ofcapital
and labor, to say nothing of theyears of
prior
involvement in the data base management area by ourprincipals.
Accordingly, we are seriously concerned about anyunauthorized copying of our products and
will
take any andall
available legal action against
illegal
copying ordistribution
of ourproducts.
(C) COPYRIGHT 1981 Micro Data Base Systems,
MDBS DMS MANUAL MDBS DMS MANUAL
PREFACE
By the miá-1960s, application developers were well aware of the
data handling
limitations
of programming languages andfile
management _ systems. To overcome theselimitations,
data base management systemsbegan to appear. By 1971, four major approaches to data base management had taken shape: the hierarchical, shallow-network,
relational,
and CODASYL-network approaches to logical data structuring and manipulation. Each represented an advance over the oldfile-oriented data handling methods and the
latter
two approaches offered advances over the former two. By the mid-1970s, data base managementsoftware was well established as the cornerstone for application development on mainframes and some mini computers.
Near the end of the decade, microcomputers
--
withtheir
phenomenal computing power on a per dollar basis
--
began toproliferate.
The acceptance of mainframe data base management systems coupled with the rise of microcomputers led to the formation of Micro Data Base Systems Incorporated by a group with expertise in bothareas. The
initial
objective was to make qenl1ine data base managementtools available in the micro realm. This objective was
fulfilled
in 1979 with the release of MDBSI --
thefirst
authentic and viable data base management system (dbms) for microcomputers. Over the years,this
has evolved into the present MDBSIII
which operates not only on many microcomputers but on larger machines as well. The evolution ofMDBS
III
is highlighted with manyfirsts:
first
micro dbms withbuilt-in
logging and recovery,first full
implementation of apostrelational dbms,
first
multiuser micro dbms,first
dbms to rununder PCDOS, MSDOS and UNIX.
Today, MDBS
III
offers professional application developers adegree of power and
flexibility
unavailable with any other data base management software--
beit
on micros, minis or mainframes. This ispartially
due to the highlyefficient,
proprietary implementationtechniques. MDBS
III
is not a mainframe retread shoehorned into amicrocomputer.
It
is also due to the innovative data modelingfeatures that MDBS
III
provides. Because these features go far beyondthose of the older data base management approaches, MDBS
III
isvariously referred to as postrelational or multiarchical or
extended-network. The emphasis in
this
approach to data base management is ondirect,
natural representation of the application world. The resultis a tremendous increase in developer productivity. As stated in the
authoritative DApt'ÁhÁqe
-
r.he 7"Ñí generÁr.ic)n· qtAfe of fjie Arr. pepc)rt.(ed., D.
j.
L. Gradwell, Pergamon press, Oxford, England, 1982): "The data modellingcapability
of MDBSIII
is superior to anyother commercially available DBMS." MDBS
III
is"...
a productthat
is,
in many ways, ahead of mainframe DBMSs." (D.j.
L.gradwell)
All
ofthis
translates into convenience for application systemdevelopers and administrators.
mdbs dms manual mdbs Dl4S manual
The MDBS R&D Lab's expertise in the areas of decision support
systems and
artificial
intelligence
has resulteá in two uniqueenvironments
for
processing MDBSIII
data bases. One is a decisionsupport environment called Kmwledgeí·iam
It
functions as a universalknowledge management system, allowing users to represent and process
knowledge in many
different
ways--
including spreadsheets,text,
graphics, forms, procedural models,relational
data bases, and-postrelational
MDBSIII
data bases. The secondis
arevolutionary
artificial
intelligence
environment called Guru.It
wakes thebenefits
of both expert system technology andnatural
languageprocessing easily accessible to business users, without
sacrificing
familiar
business computingcapabilities.
FIDBSIII
data base contents aredirectly
accessible within the Guru environment.This manual provides details on the features and
utilization
of the l<DElS Data fianipulation Language. Companion manuals discuss the I·1DBS Data Description Language and variousoptional
modules. Thismanual is not intended to be a
tutorial.
For atutorial
treatment ofdata base management (including
it
s many advantages overf
lle
management), the reader is advised to consult such suitable references as:
l.
i'iicrQ nAt'AhAse l'1AnAqpmenr,-
pra'wim'íl Tpchniq\Íes Mr t\pp1i-c(qt.ion Dpve1Apm.enr by
r.
H. Bonczek, et.al,
53CCpages,
Academic Press, New York, 1984.
2. "A Perspective on Data Models," pc Tech jc)l1rnÁ1 P vol. 2, No.
l,
1984.3
. "Fiicros Get Mainframe Data Scheme," sY5r.elAs Áñá 8oftwa.rp,!
Vol. 3, No. 5, 1984.
4
. "Uniting Relational and Postrelational Database bianagenent
Tools," sYsrems arrí ,qoftware,, Vol. 3, No.
li,
1984.The
f irst
reference provides the mostdefinitive
coverage to date of thepostrelational
approach, comparing andcontrasting
it
with
thefour oláer data base management approaches. That book also includes
extensive examples of !·ÍDI3S
III
usage.It
isavailable
through yourlocal
bookstore, from the publisher, or from Í4DBS, Inc. For manyyears, the Company has offered
practical
I'ÍDBSIII
training seminars inmajor
cities
and at customer sites.Rev
. 85A (C) COPYRIGHT 1981 i·licro Data Base Systems, Inc.
MDBS DEIS MANUAL MDBS DMS MANUAL
The I'IDBS, Inc. commitment to customer success does not stop with
software innovation, quality and support. The Company offers a
full
range of consulting and
application
development services toclients
through
its
regionaloffices
in the Dallasits
regional Chicago andNew York areas. Services include:
l.
Customized application systems design2
. Customized
application
systems development using Guru,Knowledgeí·lan and/or the MDBS
III
tools3
. Communications interfaces including mainf rame-wicro links 4
. Special
training
on a widevariety
of topics includingspecific application systems, C programming, HDBS
III
usage, and Guru usage5
. General
consulting
including
feasibility
studies andhardware/software recommendations
The experienced, professional
staff
handles consulting and applicationdevelopment needs of some of the world's
largest
corporations andgovernments.
It
has developed very extensive microapplication
systems in such diverse areas as cash management, strategic planning,human resources
administration,
waste disposal management, anddistributed service support. In many cases, these application systems have involved multiuser processing or mainframe-micro
links.
(C) COPYRIGHT 1981 blicro Data Base Systems, Inc. Rev
.
MDBS DMS MANUAL MDBS DEIS MANUAL
Table
of Contents
PREFACE
CHAPTER I. OVERVIEW . . . . . . . . . . . . . . . . . . . . .
l
A. Organization . . .
l
-b. The Role of DRIL in Application Development
. . .
l
CHAPTER II. GENERAL BACKGROUND . . . . . . . . . . . . . 3
A. Data Transferral . . . . . . . . . . . . . . . . . . . . 3
B
. Currency Indicators. . . 3
C
. Classes of D!4L Commands. . . 5
D
. Stating a DML Command. . . 5 E
. l·lultiuser Environment. . . 8 F
. Protecting Data Base Consistency against
External Factors. . . .
9
CHAPTER III. FIND COMMANDS . . . . . . . . . . . . . . . .
li
A
. Overv iew . . .
li
B. Comnaaná Details . . . 12
CHAPTER IV. RETRIEVAL COMMANDS . . . . . . . . . . . . . 29
A. Overview . . . . . . . . . . . . . . . . . . . . . . . . 29
B. Command Details.
. . . 3 O
CHAPTER V. MODIFY COMMANDS . . . . . . . . . . . . . . . 33
a. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3
B. Command Details.
. . . 34
CHAPTER VI. ASSIGNMENT COMMANDS . . . . . . . . . . . . 39
a. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 9
B. Command Details.
. . . 40
CHAPTER VII. CREATION COMMANDS
. . . 53 A
. Overv iew . . . 53 B
. Comrtíand Details. . . 54
CHAPTER VIII. CONNECT COMMANDS .
. . . 57 A
. Overview . . . 57 B
. Command Details . . . D . . . . . . . . . . . . 57
CHAPTER IX. DISCONNECT COMMANDS
. . . 59
A. Overview . . . . . . . . . . . . . . . .
. . . 59
El
. Command Details. . . 59
CHAPTER X. DELETION COMMANDS . . . . . . . . . . . . . . 63
a. Overview . . . . . . . . . . . . . . . . . . .
. . . 63
B. Command Details.
. . . 63
CHAPTER XI. UTILITY COMMANDS
. . . 67
A. Overv iew . . . . . . . . . . . . . . . .
. . . 67 B
. Command Details. . . 67
CHAPTER XII. BOOLEAN COMMANDS
. . . 81 A
. Overview . . . 81
B
. Command Details. . . .
82
(C) COPYRIGHT 1981 Micro Data Base Systems, Inc. Rev. 85A
i
MDBS DMS MANUAL 14DBS DEIS MANUAL
Ea=
CHAPTER XIII. SPECIAL COMMANDS .
. . . 89
A. Overview . . . . . . . . . . . . . . . . . . . . . . . . 89
B. Commaná Details.
. . . 89
CHAPTER XIV. MULTIUSER LOCKING COMMANDS . . . . . . . 93
A. Overview . O . . . . . . . . . . . . . . . . . . . . . . 9 3
B. Command Details.
. . . 95
CHAPTER XV. RECOVERY COMMANDS . . . . . . . . . . . . . lOl A. Overview . . . . . . . . . . . . . . . . . . . . . . . . 101
B. Command Details.
. . . 102
CHAPTER XVI. COMMAND STATUS DESCRIPTIONS
. . . . . . . 107
a. Overview . . . . . . . . . . . . . . . . . . . . . . . . 107
B. Command Status Details
. . . 107
TABLE XIV"1: tiultiuser Locking Contention Protocols. . . . . . . 94
APPENDIX A . . . . . . . . . . . . . . . . . . . . . . . . . . A-l
APPENDIX B . . . . . . . . . . . . . . . . . . . T . . . . . . B-l
COMMAND INDEX . . . . . . . . . . . . . . . . . . . . . .
.CI-l
GENERAL INDEX . . . . . . . . . . . . . . . . . . . . . . ..GI-l
MDBS DMS MANUAL MDBS DMS MANUAL
COMMAND CLASSIFICATIONS
ÉácLQ ASSIGNMENT COMMANDS
SCD (Set Current oft run
unit
to Data base key).. . . 40.1 SCM (8et Current of run unit based on MeInber)
. . . 40.1
-SCN (Set Current of run unit to ]$[ull)
. . . 40.2
seo (8et Current of run unit based on Qwner). . . 40.2 SCU (Set Current of run unit based on user indicator) . . . 41 SDC (Save Qata base key for Qirrent of run
unit).
.. . . . 41 SMC (Set Member based on Cwxent of run unit) . . . . . . . 42 SME (Set Member to current of run unit (£xception))
. . . . 43 SMM (Set ELe1Tber based on Member).
. . . 43
spin (,aet Member to
fiull).
. . . . . . . . . . . . . . . . . 44SMO (Set Member based on Qwner)
. . . 44 SMU (Set Member based on Eser
indicator).
. . . . . . . . . 45 SOC (Set Qwner based on Current of rununit).
. . . 46 SOE (£et Qwner to current of run unit (Exception)).
. . . . 46 SOM (Set Qwner based on Member)
. . . 47 SON (Set Qwner to Elull)
. . . 47 SOO (Set Qwner based on Qwner).
. . . . . . . 48
SOU (8et Qwner based on lZser indicator)
. . . 49
sue (Set user indicator to Current of run unit) . . . . . . 49 SUM (Set ¶ser indicator to E!ember).
. . . 50 SUN (áet Aser indicator to HUD.
. . . 50
SUO (Set LLser indicator to Qwner)
. . . 51 SUU (Set Rser indicator to user indicator).
. . . 52
BOOLEAN COMMANDS
AÑM (Añd of Members with Members)
. . . 82 AMO (AM of Members with Qwners).
. . . 83 AOM (And of Qwners with Members).
. . . 83 AOO (And of Qwners with Qwners)
. . . 84 XMM (eXclude Wembers from Members).
. . . . . . . . . . . . 85
XMO (eXclude Members from Qwners)
. . . . . . . . . 86
XOM (eXclude Qwners from MeInbers)
. . . . . . . . . 87
XOO (eXclude Qwners from Qwners).
. . . 88
CONNECT COMMANDS
IMS (Lnsert Uember into 8et).
. . . . . . . . . . . . . . . 57
lOS (Lnsert Qwner into Set) . . . . . . . . . . . . . . . . 58
CREATION COMMANDS
CRA (Cxeate Becord in Area)
. . . 54 CRS Greate Eecord and 8tore)
. . . 55
(C) COPYRIGHT 1981 Micro jjata Base Systems,
Inc. Rev. 85A
MDBS DMS MANUAL !4DBS Dl4S MANUAL
DELETION COMMANDS
DRC (Qelete Record that is Current)
. . . 63
DRE! (IZelete Record that is Member) . . . 64
DRO Qelete Eecord that is Qwner) . . . 65
"
DISCONNECT COMMANDS RMS (Bemove fiember froríi Set) . . . 59ROS (Bemove Qwner from Set) . . . 60
RSÉ4 (EeInove
all
Bet MeInbers) . . . . . . . . . . . . . . . . 60RSO (Bemve
all
Set Qwners) . . . . . . . . . . . . . . . . 61FIND COMMANDS FDRK (Eind Quplicate Record based on calc Key) . . . . . . . 12
ffm (Eind
Urst
Member) . . . . . . . . . . . . . . . . . . 13FEO (Eind
Eirst
Qwner) . . . 14FPS (Eirúí
Eirst
aequential record) . . . @ . 14FLÍ'Í (Eind j¿ást Member) . 0 . O 0 0 e . . © O . . e . . G © . 15 FLO (EiM Last Qwner) . . * 0 0 . . . . e G . . e . 0 C G . 15 FÉ4I (Eind j',ember based on data ítem) . . © . . . G . . . O . 16 F81SK (Eind Kerber based on Sort [[ey) . . . . . . . . . . . . 17
FN!·1 (Eind Eext L1enber) . . . 18
FNI'.II (Eind Next áember based on data Ltem) . . . 19
FNFISK (Einá 4ext l1elTber based on Sort Key) . . . . . . . . . . 19
fno (Eiñd Next Qwner) . . . . . . . . . . . . . . . . . . . 20
FNOI (Eind Next Qwner based on data ítem) 0 . . . . . . . . . 21
FNOSK (EiU Eext Qwner based on ,áort Key) . . . 22
FNS (Eind Eext ,aequential record) . . . . . . . . . . . . . 23
FOl (Einá Qwner based on data Ltem) . . . 24
FOSK (Eind Qwner based on Sort U}') . . . 25
FPt.l (EÁnd Etüor Member) . . . O . . . . . . 26
FPMI (Eind
2rior
Éáerrlber based on data Ltera) . . . 26F!¥1SK (Eind
2rior
Llember based on Sort %ey) . . . 27FPO (Eiñd
2rior
Qwner) . . . 0 . . . . . . 28FPOI (Einá Erior Qwner based on data Lten'.) . . . 28.1 FPOSK (Eind Erior Qwner based on Sort Key). . . . 28.2
frk
(Eiñd Record based on calc Key) . . . . . . . . . . . 28.3 MODIFY COMMANDS PFC (2ut data into Ueicí of Current of run unit) . . . 34pF!q (Eut data into Eield of Member) . . . . . . . . . . . . 34
PEO (Eut data into EidLd of Qwner) . . . 35
PUTC (EñT data into Current of run unit) . . . 35
PUTI·1
(=
data into KeTaber) . . . 36PUTO (E9T data into Qwner) . . . 37
MDBS DMS MANUAL MDBS DMS MANUAL
MULTIUSER LOCKING
MAU (Multiuser Active Qser indicators) . . . .95
MCC (Mültiuser Gontention Count). . . . . . . . . . . . . . 96
MCF (Multiuser
>rrent
of run unit Eree) . . . . . . . . . .96"
MCP (Múltiuser>rrent
of run unit Erotect). . . . . . . . .97MRTF (Multiuser Becord Type Eree). . . 98
MRTP (Multiuser Eecord jype Erotect) . . . . . . . . . . . . 98
MSF (Multiuser Set Eree). . . . . . . . . . . . . . . . . . 99
MSP (Mültiuser Set Erotect) . . . 99
RECOVERY COMMANDS LGCPLX (LoG
start
of ComELeX transactions) . . . .105LGENDX (LoG ENCL compleá transactions). . . . .106
LGFILE (LoG EILE
specification).
. . . . . . . . . . . . . . .102LGFLSH (LoG
file
buffer El,úSH) . . . . . . . . . . . . . . . .103lgmsg (LoG UJ& ]y[eSsage). . . . . . . . . . . . . . . . . . .103
PIFD (EXe-Lmage Eile Declaration). . . . . . . . . . . . . .104
TRABT (TEansaction AEoRT) . . . .104
TRBGN (=ansaction BeGiN) . . . .105
TRCOE4 (=ransaction CQélmit) . . . .106
RETRIEVAL COMMANDS GETC (GET data from Current of run unit) . . . 30
GETM (GEE data from Member). . . . 30
GETO (GET data from Qwner) . . . 31
GFC (Get Eield from Current of run
unit).
. . . 31GFM (Get
Uekí
from Member) . . . 32GFO (Get Eield from Qwner). . . . 32 ODRK (Qbtain Duplicate Record based on calc Key)
. . . 32.1 OF'M (Qbtain
Eirst
Me1nber). . . 32.2 OFO (Qbtain
Urst
Qwner).. . . 32.3 OLM (Qbtain j,ast Member).
. . . 32.4 OLO (Qbtain Last Qwner)
. . . . . . . . . . . . . . . 32.5
OMI (Qbtain Member based on data ftem).
. . . 32.6 OMSK (Qbtain Member based on Sort Key)
. . . 32.7 ONM (Qbtain Next fjember).
. . . 32.8 ONMI (Qbtain Next MeInber based on data Ltem)
. . . 32.9 ONMSK (Qbtain Next E1elnber based on 8ort Key).
. . . .32.10 ONO (Qbtain Next Qwner)
. . . .32.11 ONOI (Qbtain Next Qwner based on data ítem).
. . . .32.12 ONOSK (Qbtain Next Qwner based on Sort Key)
. . . .32.13 OOI (Qbtain Qwner based on data ítem)
. . . .32.14 OOSK (Qbtain Qwner based on 8ort Key).
. . . .32.15 OPM (Obtain Erior Member)
. . . .32.16
OPPII (Qbtain 2Uor Member based on data Ltem).
. . . .32.17 OPMSK (Qbtain
2rior
MeTnber based on 8ort Key). . . .32.18 OPO (Qbtain 2Uor Qwner).
. . . . . . . . . . . . . . . .32.19
OPOI (Qbtain 12rior Qwner based on data Lteni)
. . . .32.20
OPOSK (Qbtain Erior Qwner based on Sort Key).
. . . .32.21 ORK (Qbtain Eecord based on calc Key)
. . . .32.22
MDBS DMS MANUAL MDBS DMS MANUAL
SPECIAL COMMANDS
ALTEOS (ÁLíTer Eñd Qfi ,aet).
. . . 89
dbinit
(IZata Base control systemINITialization)
. . . . . . . 90 DBSEL (Qata 2ase SEl,ection). . . 90
DEFINE (PFFTNF data block)
. . . 90.1
DMSSJP (wis Set JimE).
. . . 90.2 EXTEND (FYTFNP data block)
. . . 90.2 MPL (Mu1tiuser
Eriority
j,evel).. . . 91 SETPBF (SEE Eage BuEfer region).
. . . 92
undef (TjNr)EFine data blocks). . . . . . . . . . . . . . . . . 92
varcs
(miable
for Command átatus). . . 92.1
UTILITY COMMANDS
AUI (Allocate Aser Lndicators). . . . . . . . . . . . . . . 67 CCU (Check Qirrent of run unit against Yser
indicator).
. . 68 DBCLS (Oata Base CCLoáe)
. . . 69 DBCLSA (Oata Base CL,oáe for Area).
. . . 70 DBCNV (pata Rase format CoNyersion)
. . . 70 DBENV (Qata Base ENYironment)
. . . 70.1
dbopn (Oata j3,ase QEeN).
. € . . . . . B . . . . . . . . . O . 71
DBOPNA (Oata Base QEeli Áxea)
. . . 72 DBSAVE (Oata E,ase
.
. . . 73DBSTAT (Oata Base
.
. . . 74 GMC (Get fjember Count).. . . 75 GOC (Get Qwner Count)
. . . 75 GTC (Get Type of
>rrent
of run unit). . . 76 GTM (Get Type of fjember).
. . . ·. . 76 GTO (Get Type of Qwner)
. . . 77
NCI (Null
all
>rrency Lñdicators). . . 77 TCN (Tfst Current of rununit
for Eiull). . . 78 TCT (Fest Current of run
unit
Type). . . 78 TMN (Test Member for
NUI).
. . . 78.1 TMT (Tést Member Type). . . . . G . . . . . . . . . . . . . 78
TON (Tést Qwner for
tiull)
. . . 78.2 TOT (Tést Qwner rype)
. . . 78.2 TUN (Test Yser indicator for
NullA
. . . 79
MDBS DMS MANUAL MDBS DMS MANUAL
I. OVERVIEW
a. Organization
This is the MDBS DMS Manual.
It
is the second component in the"
set of MDBS Reference Manuals and assumes the reader is
familiar
withdata description
facilities
presented in the MDBS DDL Manual. This document describes the MDBSIII
Data Manipulation Language (DML) andthe
effect
that each DML command has on the behavior of the data basecontrol system (MDBS.DMS). The MDBS DMS Manual is written on two
levels: fundamental manipulation features and advanced manipulation
features. An understanding of the fundamentals is
sufficient
fordeveloping useful application systems. The advanced features are denoted by a
vertical
bar in the outsiáe margin. These are perhapsless frequently needed, but they are valuable for certain special kinds of data manipulation.
The documentation in
this
manual is applicable to both versions3a and 3c. Appendix A describes those data manipulation features that are applicable only to Version 3a.
It
is also independent of the hostlanguage(s) selected to interface with mdbs.dms. Host language-dependent aspects of the interface are described in appropriate MDBS System Specific Manuals.
Tlíe remainder of
this
chapter outlines the role of MDBS.DMSsoftware and
its
associated Data Manipulation Language (DML), inapplication development. Chapter
II
provides the detailed backgroundthat is necessary to
effectively
use the MDBS Data ManipulationLanguage. Each of Chapters
III
through XV documents a class of DMLcommands. The individual commands in each class are presented
alphabetically and the function of each command is described. When a
DML command is executed, MDBS.DMS reports on the status of that
command's execution. Each possible command status is explained in
Chapter XVI.
b. The Role of DML in Application Development
The MDBS Data Manipulation Language consists of a group of
commands, each of which performs some data manipulation task. A DML
command is stated within an application program. The programming
language used to write an application program is called the hzak 1(Ínql1(aqe. a DML command is
typically
invoked as a function in thehost language. when a DML command is given, the MDBS.DMS software
carries out the actual data manipulation. This could involve storing data from a host program variable into the data base. Conversely,
it
could involve extracting data from the data base and depositing
it
ina host language variable. Many other kinds of data manipulation are
supported. In
effect,
the DML extends the data handling capability of a programming language, so that programs canutilize
MDBS data basesin addition to
traditional files.
Usage of the MDBS DML in developing an application program
depends QIÜY upon a knowledge of the data base's
logical
structure.The application programmer need not be concerned with using pointers,
searching indices, disk I/O,
file
handling, free space management,(C) COPYRIGHT 1981 Micro Data Base Systems, Inc. Rev. 85A
MDBS.DMS MANUAL
- I:
OVERVIEI·I-
IQJBS.DMS MANUALetc.
All
of these factors are automatically handled by the I'IDBS.DE1Ssoftware. Furthermore,
all
data manipulation occurs subject to thesecurity
andintegrity
constraints
defined in a data base's DDLspecif ication. In a multiuser environment, MDBS.DMS manages record
lockout to prevent such problems as one user attempting to modify a
record
that
another user is reading. Special DÍ4L commands are-available
to theapplication
programmer who (beyond the standardpassive lockouts) desires to actively lock out records, record types[ or sets.
A data manipulation language provides a procedural approach to
data manipulation.
It
can therefore be contrastedwith
a querylanguage, which provides a nonprocedural approach to data
manipulation.
From thestandpoint
ofachieving
thehighest
performance
for application
software, using a DMLis inevitably
superior to using a nonprocedural query language. On the other hand,
the application developer who is not experienced in using DEIL can very
likely
achieve more rapid development by using a nonprocedural querylanguage (at the expense of a
sacrifice
in perll'-Xmance). In data base management systemsthat
do not support both a DI4L and a querylanguage, the
application
developer has no choice. Both kinds of languages are available with FIDBS.It
is recommended that the querylanquage (see the MDBS QRS Manual) be used in
situations
where theneed flor rapid development outweighs the need for optimal perforr.íance.
If
optimal performance is the overriáing consideration, then the MDEIS DML is most appropriate. In addition to QRS, there are other optionalaccess modules including IDML, IBS, RDL and BLF.
Although the MDBS DML makes many commands
available,
it
is
typically
the case that an application developerwill
need to use onlya few kinds of DML commands in any given application program. Across
all
application programs, there is a small group of about a dozen DMLcommands that tend to be heavily used. Varying degrees of selective
MDBS.DL4S
linking
are permitted, depending on the host language used(see MDBS System Specific Manuals for details). In other words, only
that
part of 14DBS.DI4Sthat
is needed to execute anapplication
program's DFIL commands is held in main meiaoryú Since the
entire
!4DBS.DMS software
is
not in main memory, there is more memoryavailable for
alarger
appliCation program or alarger
pagebuffer
region.
One component of FIDBS.DMS performs
virtual
buffer paging, basedon an enhanced least-recently-used page replacement algorithm. When a DML command
is
executed, MDBS.DMS determines whether images ofall
needed pages are in main memory.
If
needed pages are notresident,
!4DEIS.DMS has them read into main memory. Tíie larger the page buffer
region in main memory, the more
likely
it
isthat
needed pages areresident and the Faster the processing
will
be. Thusit
is importantfor the application developer to allow as large a page buffer region
as possible. In a single-user environment, the page
buffer
regionsize is
directly
assigned by the programmer. In amultiuser
environment, EÍDBS.DPIS determines the size of the page
buffer
regionthat
i
s shared byall
users (i
.e . ,simultaneously
executingapplication programs) .
MDBS DMS MANUAL MDBS DMS MANUAL
II. GENERALBACKGROUND A. Data Transfer
Some DML commands pass data from a host language
variable into
the data base. Others
retrieve
data from the data baseinto
a hostlanguage
variable,
from which the data can then be usedfor
computation or program output. There are two basic approaches
for
allowing
MDBS.DMS to accomplish the datatransferral
between a database and an
application
program. The approach used depends on thenature of the host programming language. Non-record-oriented languages (such as BASIC) require the data block approach. Host
languages with a
facility
for
defining program record types (e.g.rCOBOL,
PL/l,
PASCAL) use the program record type approach.Füll
details of the approach used for a particular host language appear in
the MDBS System Specific Manual for that host language.
l.
Rata ElQgks. A data blockis
a named sequence of one ormore host language variables. MDBS DML commands
exist
todefine, extend, and undefine data blocks (see Chapter
XIII).
a given host language variable can participate in many datablocks. A DML command to put data
into
a data base has adata block name as one of
its
arguments. The value(s) ofthe host language variable(s)
for
that data block is(are) putinto
the data base. ADMLcommandtoretrieve
data froma data base has a data block name as one of
its
arguments.The retrieved value(s) becomes the new value(s) for the data
block's host language variable(s).
2. elq9lmd BegQrg Typq,s. A program record type plays the same
role as a data block.
It
is a named sequence of one or morehost language
variables.
It
is
not definedwith
DML commands, but is specified with the host language'sfacility
for defining
program record types (for example, a Dllevel
entry in a COBOL working storage section, or a record
structure
of Cor PASCAL). A given host language
variable
usually cannot participate in more than one program record
type. A DML command to put data
into
a data base has aprogram record type name as one of
its
arguments. Thevalue(s) of the host language variable(s)
for
that program record type is(are) putinto
the data base. A DML commanáto retrieve data from a data base has a program record type
name as one of
its
arguments. Theretrieved
value(s) becomes the new value(s) of the program record type's hostlanguage variable(s).
B. Currency Indicators
Cjjll£1jgy iÁÁicátQts are used by an application programmer to keep
track of which record occurrences in a data base are
currently
ofinterest.
MDBS.DMS maintains two currencyindicators for
each setspecified
in a data base's schema: the cutxentqwrrl
of the set andthe cuixent id£iÜ2qL of the set. There can be many owner record
MDBS DMS MANUAL
-
II:
BACKGROUND - MDBS DMS MANUALoccurrences in the data base
for
a given set. At any moment duringthe execution of an
application
program no more than one of those owner record occurrencesis
the csuxmt owner of the set. dmlcommands allow the application programmer to control which
(if
any) owner record occurrenceis
the current owner of a set. The SXSTEM
-LéQQKjj QggyKKeÁge
ia
aluavs the cjjtr£ntqwijal q£ 2y£ly sYskelD=Qwneg
sek (unless
it
is
explicitly
made to benull
by the programmer).Similarly,
there can be many member record occurrences in the data basefor
a given set. At any moment during the execution of anapplication
program, no more than one of those member recordoccurrences
is
the set's mirrent member. DML commands allow theapplication
programmer tocontrol
which(if
any) member recordoccurrence is the current member of a set.
As soon as a record occurrence becomes the current owner of a
set,the
DML can be used:to find any of
its
related members through that set (ChapterIII),
to modify
its
data values (Chapter V),to retrieve
its
data values (Chapter IV),to delete the record occurrence from the data base (Chapter X),
etc.
As soon as a record becomes the current member of a set, the IJML can be used:
to find any of
its
related owners through that set (ChapterIII),
to delete the record from the data base (Chapter IX),
to modify
its
data values (Chapter V),to retrieve
its
data values (Chapter IV),etc.
Another kind of currency
indicator
that can be used during datamanipulation is called the CjjttMjt Q£ the ljji)
jjjjit.
A run unitis
anexecuting instance of an application program. There are many record
occurrences in a data base. At any moment during the execution of an
application program, no more than one record occurrence in the entire
data base
is
the current record ofthat
rununit.
The current of arun
unit is typically
the recordthat
was mostrecently
found by theapplication
program(i.e.,
by the rununit).
DML commands allow the application programmer to control which(if
any) data base record isthe current of run
unit.
As soon as a record becomes the current ofrun unit, the DML can be used:
to delete the record from the data base (Chapter IX),
to modify
its
data values (Chapter V),to retrieve
its
data values (Chapter IV).Suppose a data base schema has
five
sets. These can be anymixture of
l:
l,
I:
N, N:l,
N: M sets. Anapplication
program can make use of any of eleven currency
indicators.
There arefive
currentowner
indicators
(one per set),five
current memberindicators
(one per set), and the current of rununit.
In a multiuser environment,each
application
programthat is
usingthis
data basewill
haveits
own eleven currency indicators.MDBS DMS MANUAL
-
II:
BACKGROUND - MDBS DMS MANUALIn
addition
to the three kinds of currencyindicators
alreadymentioned, MDBS allows an application programmer to optionally define
additional
currencyindicators within
the scope of anapplication
program. No more than 255 user-defined currency indicators can be usedwithin an application program. These additional currency indicators
-can be usefully employed to "remember" the current owner of some set,
before processing causes that current owner to change. The same
principle
can be applied to current members and the current of rununit.
Various DML commands can be used in subsequent processing toaccess the remembered record. DML commands are also provided for the
user
(i.e., application
programmer) to defineadditional
currencyindicators
and to make the record thatis
a set's current owner (ormember or current of run unit) the current record for a user-defined
currency indicator.
All
currencyindicators
arenull
when anapplication
programbegins execution, except the current owner of each system-owned set and the current of run
unit,
which also has the SYSTEM record asits
current record. A currency indicator remains
null until
a DML commandis executed to change
it.
C. Classes of DML CommandsThe DML commanás
fall
into thirteen classes. Each command class has one chapter devoted toit.
The order of presentationfor
theseclasses is as follows:
Finding records (Chapter
III)
Retrieving data from records (Chapter IV)
Modifying data in records (Chapter V)
Assigning currency indicators (Chapter VI)
Creating records (Chapter VII) Connecting records (Chapter
VIII)
Disconnecting records (Chapter IX)
Deleting records (Chapter X)
Utilities
(Chapter XI)Boolean operations (Chapter XII)
Special operators (Chapter
XIII)
Multiuser locking (Chapter XIV) Recovery operators (Chapter XV)
The DML commands within a given class
are presented alphabetically in
the chapter for that class. In becoming acquainted with
this
manual,it
is recommended that these chapters be examined in sequence. Also,the reader may want to ignore the advanced manipulation features on
the
initial
pass throughthis
manual. D. Stating a DML ConunandEach DML command consists of a short mnemonic. For instance, the
mnemonic FFM is used for Finding the
first
újember record connected tothe current owner of a set. A
list
of zero, one, two, or threearguments is stated along with a DML command. An argument is either a
(C) COPYRIGHT 1981 Micro Data Base Systems,
Inc. 5
MDBS DMS MANUAL
-
II:
BACKGROUND-
MDBS DMS MANUALset name, record type name, area name, data item name, or data
block/program record name. For example, FEM needs a single argument:
a set name, to
indicate for
which set we want tofind
thefirst
member. Correct usage of a DML command depends on a knowledge of thekinds of arguments required by that commaná.
If
one of the arguments _is
a data block (or program record), the application programmer must be aware of whether the commandwill
use the data block's variables asinputs or outputs.
A DML command can use currency indicators and can change currency
indicators.
Anapplication
programmer must know which currencyindicators a DML command can use and which currency ináicators
it
canalter
(and the nature of the alterations) .Command Status
The execution of a DML command always
results
in a cQIuDangStátjjá. A command status
is
an integer in the range from Othrough
255. The command status number
is
returned as the value of a hostlanguage variable of the programmer's choosing. A command status of O
means that the execution of a command was successfully completetL A
command status of 255 means that the data manipulation system
tried
tofind
a record occurrence indicated by the command, butthat
theindicated record occurrence does not
exist
in the data base. Anyother command status means that the command did not execute normally. Generally speaking,
this is
caused byeither faulty logic
of theprogrammer, a mis-statement of the command, an attempt to
violate
security
orintegrity
constraints specified
in the DDL,failure
to have a needed diskon-line,
or a hardware malfunction. Adetailed
description of each such command status error appears in Chapter XVI.
Comnand Form
The precise syntax employed for stating a DML command depends on
the host language being used. The MDBS System Specific Manual for a
given host language shows the syntax
for
using DMLwithin that
hostlanguage. There are flour major
categories
of host language interfaces:a) Data block oriented w
ith
direct
DML invocation (e. g. , some FORTRANS, some BASICS)b) Data block oriented with
indirect
DML invocation (e.g., someBASICS)
C) Record oriented with
direct
DML invocation (e.g., C, some PASCALS, PL/l)d) Record oriented with
indirect
DML invocation (e.g., some PASCALS, some COBOLS)A host language
is
data block orientedif it
does not allow programrecord types; otherwise,
it
is said to be record oriented. Invoking a DML commanddirectly
means that the host language allows a DMLmnemonic to be treated as a host language
function.
Thisis
notMDBS DMS MANUAL
-
II:
BACKGROUND - MDBS OMS MANUALallowed in the
indirect
case, where a DML mnemonic andits
associatedarguments are parameters of a function. For instance, in the direct
case the FFM command has the following generic form:
ED
= FFM ("arguments")
"
where ED is a host language variable that receives the command status
value returned by the FFM
function.
In theindirect
case, the FFM command has the following generic form:ED
= OMS ("FFM,arguments")
where ED
is a host language variable that receives the command status
returned by the DMS function as a result of executing the FFM command. Command String
When a DML command
is
stated, the portion of that command withinquotes
is
called the commandstring.*
Two elements in a commandstring are separated by
a series of one or more blanks, a comma, or
a comma embedded in a series of blanks.
Two consecutive commas, without an intervening nonblank character,
indicate
a missing element in a commandstring
(e.g., "X,,Y"). Acommand string with one fewer than the permitted number of elements is
typically
treated asif
the rightmost elementis
missing (e.g.rif
three elements are permitted, then the rightmost element
is
regarded as missing from "X,Y"). The exceptionis
when the omitted elementshould have been a data block name (or program record type name)
immediately following a data item or record type name (e.g., with the CRS command). In this case, the data block name is assumed to be the
same a"s the record type or data item name (e.g.,
if
Zis a data item
name, then "X,Z"
is
equivalent to "X,Z,Z").All
elements are missing from a commandstring
if
there are no elements in the quotes. For some DML commands,it
is permissible foran argument in a command
string
or theentire
commandstring
to be'missing (e.g., FE'S). Some DML commands have no command
string
(e.g~ DBCLS).
Command Descriptions
As each DML command
is
described in thefollowing
chapters,examples of the four
different
categories of command usage areprovided. Even
within
a category, the exact syntaxfor
using a0
*
Some host languages do not use double quotes (""). The exact
convention employed by a host language
is
described inits
systemspecific manual.
MDBS DMS MANUAL
-
II:
BACKGROUND-
MDBS DMS MANUALcommand may
differ slightly
from one host language to another. Torepeat, the 4pprQptiat£ áYátéw áHqgi£ig wanml ahQula Kq cQn,ajjlkQg £ql
the exact §YjjtÁx L£AjjjL£g Ky a gjj¿qjj jjQSt l@Dgjj4ge. The mnemonic, arguments, currency indicators used, currency indicators changed, and
impact on the data base
for
each dml command areall
independent of "the host language used.
All
of thesefactors
are described in subsequent chapters of the MDBS DMS Manual. Thus the logic employediii
using the data manipulation language is the same, regardless of thehost languages used.
In presenting the DML commands in subsequent Chapters, the
following conventions are used:
EQ host language variable for the command status
itío the name of a data item defined with the DDL
k9g the name of a record type defined with the DDL
áeF=LL 'M_?, sgt=3 the names of sets áefined with the DDL áLé@ the name of an area defined with the DDL
klk the name of a data block (or program record type)
ihlk
the name of adata block (or program recordtype) whose hostlanguage variables provide input to a DML command
oklk the name of a data block (or program recordtype) whose host language variables receive output from a DML command
CEUI current of run
jjnit
indicatorCQSsqtL gurrent Qwñer of the indicated set CMLáétL current wember of the indicated set
I
CiLLiL gurrent ijser-defined indicatori
(lSiS255)for
example, CU(7) denotes the current recordfor
the seventh user-defined indicatorAlthough the description for a DML command may refer to a data block,
it
should be understood that a program record type takes the place of a data block for record-oriented host languages.E. Multiuser Environment
In a multiuser environment, many run
units
can simultaneouslyshare the sa