```**
The screen will appear ready for you to enter your code. A proforma will be shown on the screen. You can simply alter it to suit your needs. This saves keystrokes and minimizes errors.
If you need to add work areas into the Data Division you should use the RULWORK identifier as you would for a Business Rule.
| ```
**
RULADD VAD01/RULDELT
SEARCH ARG: ..................................................................
Password: M A G E C VAD01 page
New Password: ELEMENT DATA RULES (001)
MAGEC Vacation Dummy data TAB Option: ON
.....+..;10.;..+;..20....+...30....+...40...;+...50....+...60....+...70..
IF ____________________ 01
MOVE '___' TO ERROR-NUMBER 02
PERFORM CA100-LOAD-ERR-CODE-TBL THRU CA199-EXIT. 03
04
05
06
07
08
09
10
11
12
13
14
15
Move CURSOR to a line, use ERASE EOF to Delete it -or- PF20 to Insert After it
Semicolon (;) is the TAB Character Asterisk (*) in col. 1 = suppress upcase
Press PF4 for Menu of Named Proformas
```**
Figure 24 -- Deletion Rule Add Screen
| ```
** DO THIS:
Key in the code shown below, press ENTER.
```**
The error number '91J' should already exist on the MAGEC ERR file. If it does not, you should add it via the command: ERRADD 91J
To see if it is already defined you could use the command:
ERRSEE 91J
-- if it is on file, it will be displayed to you.
The restrictions which applied to Business Rules also apply to Deletion Rules. The only difference between them is where they are inserted in the logic of a generated MMP.
| ```
**
RULADD VAD01/RULDELT
SEARCH ARG: ..................................................................
Password: M A G E C VAD01 page
New Password: ELEMENT DATA RULES (001)
MAGEC Vacation Dummy data TAB Option: ON
....+..;10.;..+;..20....+...30....+...40...;+...50....+...60....+...70..
if vad01-empnum Less than nineteen 01
move '91j' to error-number 02
perform ca100-load-err-code-tbl thru ca199-exit. 03
04
05
06
07
08
09
10
11
12
13
14
15
Move CURSOR to a line, use ERASE EOF to Delete it -or- PF20 to Insert After it
Semicolon (;) is the TAB Character Asterisk (*) in col. 1 = suppress upcase
Press PF4 for Menu of Named Proformas
```**
**
NOTE:
**
It is not necessary to type the entire Cobol statement above since hte proforma displayed to you strongly resembles it. (cont.)
You can simply overkey the portions of the proforma which you need to alter in order to correctly build this Cobol (cont.)
statement. The underlines in the proforma help you to see where modifications most likely need to be made to the (cont.)
proforma in order to build a correct statement. This gives you a fill-in-the-blanks aid to coding.
Figure 25 -- Deletion Rule Logic
#
Review
In the preceeding project you have defined and created a completely new Data Class (a VSAM file, in this example) from (cont.)
scratch. The process is the same for any other data you need to define to MAGEC. You can review this tutorial and/or (cont.)
the MAGEC "Database Administration" chapter whenever you need to define new files or databases.
We defined it in a "top-down" manner as:
To define the Data Class:
DCLADD VAD
**
To define the Key:
KYFADD VADK1
To define the two Elements:
ELTADD VAD01
ELTADD VAD00
To define the Data Items
MAGECLBR
(-MAGECADD DIT VAD01 operation)
To customize the Data Items:
DITCHG VAD01//.....
To generate a copybook:
DITGEN VAD01
To add a Business Rule and Referential Integrity checking:
RULADD VAD01//RULWORK
RULADD VAD01//RULPROC
RULADD VAD01/RULDELT
#
Executing DCLDOC
##
Data Class Documentation
As a Database Administrator or Data Administrator you will often find a need for concise, hardcopy documentation of (cont.)
your Data Classes' definitions and Where-Used references. MAGEC provides a batch utility program which produces just (cont.)
such a report.
The report navigates through the dictionary, gathering facts related to the Data Class in question. It checks for many (cont.)
potential error conditions (inconsistent definitions or usages), missing pieces, overlapping definitions, and other (cont.)
circumstances which should be called to your attention. It also produces a where-used report showing all references to (cont.)
the Elements as primary or secondary Data Classes by both online and batch programs.
At this time, the VAD Data CLass has no references
it is not yet used by any application. Since a report of the VAC Data Class (which is used by MMP600 and MBP600B) would (cont.)
be more interesting than a report of the new VAD Data Class we just defined and created, we will produce a DCLDOC (cont.)
report for VAC. This will better demonstrate the usefulness of this report.
| ```
DO THIS:
Execute DCLDOC using a control card of:
DCLDOC VAC
Refer to your "Offline Utilities" chapter for appropriate JCL for your particular environment.
DCLDOC is executed using the .BAT file named DCLDOCEX if you are using a PC workstation.
```**
Review the output report carefully. You may wish to establish a standard of printing this report after any major (cont.)
additions or changes to the Data Class definitions and keeping the printed report on file for your use and for use by (cont.)
developers and maintenance programmers.
#
Domains
When you were defining the Data Items (DIT's), you might recall we mentioned "Domains". We did not try to explain (cont.)
Domains at that time because we did not want to disrupt the flow of the tutorial project with a long discussion, which (cont.)
Domains certainly require. Now we will take the time to discuss them.
A Domain is a category, or class, of data items. As an example, ZIP-CODE might be the name of a Domain that you have (cont.)
defined; you might have specified that ZIP-CODE's all should be five digit numeric items with a prompt (heading) of (cont.)
"Zip:", you might also have keyed in a narrative explanation which applies to ZIP-CODE's, in (cont.)
general.
Then you might specify that the data item named CUS01-ZIPCD is in the ZIP-CODE domain. You would do that by typing the (cont.)
Domain Name "ZIP-CODE" into the Domain Name specification on the DITxxx screen for the CUS01-ZIPCD data item. MAGEC (cont.)
will ensure that the specifications for CUS01-ZIPCD are compatible with the Domain definition; it will also default (cont.)
(copy) any specifications (i.e. Narrative, Prompt, etc.) which you have left blank. The Domain serves, therefore, as a (cont.)
model for zip code fields everywhere. You would likely have many other data items in other elements and files which are (cont.)
also in the ZIP-CODE domain. This mechanism ensures that all of them follow certain rules of conformity to one (cont.)
another.
It is not required that all data items within a Domain be defined *identically*, merely that they be compatible. For (cont.)
example, one ZIP-CODE might be packed, another binary, and another display numeric; all must be five digits and (cont.)
numeric, however. This ensures that you can use a Cobol MOVE from any one to any other without corrupting the data or (cont.)
your program. One possible exception is that it is legal for one ZIP-CODE item to be signed while another is not. You (cont.)
will receive a warning message when defining the data item telling you that a sign will potentially be lost when (cont.)
referencing this data item, but you can ignore the warning and accept the risk. This is done because signed numerics (cont.)
are often more efficiently accessed than unsigned numerics, and many people will specify signs even on items which can (cont.)
never be negative.
You may have noticed from the above explanation that a data item may be "subordinate" to both an Element and a Domain. (cont.)
Further, an Element may have several Data Items below it, and a Domain may have several Data Items below it. If you (cont.)
wished to change the rules for a given Domain, say to change ZIP-CODE from a five-digit to a nine-digit numeric, you (cont.)
would probably appreciate the ability to get a *Where-Used* report for that Domain. Fortunately MAGEC provides both (cont.)
online and hardcopy Where-Used reporting for Domains. Refer to the topic Suggestions Regarding Domains later in this (cont.)
chapter.
The diagram in Figure 26 will help to clarify the relationship between the various entities.
**
NOTE:
**
Your *Programmer's Reference Guide* contains a discussion about Domains in its "Database Administration" chapter.
##
Data Definition Entities
*
Figure 26 -- Data Entities Diagram
##
Defining Domains
To define a Domain you use the DOMADD function. Domains are uniquely identified in the dictionary using a six-digit (cont.)
number, they also have a twenty-character name. To add a new Domain you would enter the online (cont.)
command:
**
DOMADD nnnnnn
**
where nnnnnn is the unique id number. If one already exists with that number, you will receive the usual "Duplicate" message displaying the existing Domain definition.
A Domain definition is very much like a Data Item definition, with a few exceptions:
The Domain Name is limited to twenty characters
The "Cobol level number" must always be 50 thru 65
There is no Cobol dataname.
You should always provide a Narrative description for Domains since it will be used as the default description for any (cont.)
Data Items belonging to that Domain. If, for example, you do not specify a narrative for the Data Item named (cont.)
CUS01-ZIPCD, when an operator presses the field-level help key (PF2) for a screen field which has CUS01-ZIPCD as its (cont.)
source/target, MAGEC will get the narrative from the ZIP-CODE domain definition.
When you are adding Data Item definitions you can also save some effort since MAGEC will copy most of the (cont.)
specifications from the Domain definition, if a Domain Name is specified for that Data Item. If you enter (cont.)
specifications which are different from the Domains, MAGEC will compare them for compatibility and disallow (cont.)
incompatible definitions.
##
Domain-driven Joins
next: data09.md.txt