PERSON Area
Procedure For Deleting Persons From
UNM Database
In order to delete a person from the UNM database, the person requesting
the deletion must complete the following steps:
- Must be authorized via
a department head; valid departments are Admissions, Registration,
Accounting, Records, and School Relations.
- Sign on to IDMS and execute
dialog DUNM000.
- Select option 3 (Person
Deletion Information).
- Enter the person's sequence
number(default), or the person's SSN.
- Hit the PF9 key to authorize
this person for deletion.
Note: Do this only if you intend for this person to actually be deleted!
This action will flag
the person for deletion, and can NOT be reversed.
- Check the 'Signature Required'
column; if it is clear of all 'X's and you have been authorized to
delete persons from the database, hit PF10 now too actually delete this
person.
Note: When a person has been successfully deleted from the database an
audit record is
created which contains the person's name, SSN, sequence number, authorized
user
id's, and a date/time stamp for each user id.
If you have been authorized to delete persons from the database and you
have access
to TSO/ISPF, you may request a copy of a program that will list all
deleted persons
since 09/25/98.
IDMS30 Person-Area Maintenance
In order to keep the Test IDMS Person Area from overflowing and to protect
crucial test data from being inadvertently modified or deleted, the following
procedures should be followed by all.
Each major application area may maintain 100 PERSON records on the database.
To identify its data, the area is assigned a two-character ID, a two-digit
ID range, and one or more project codes.
| Application Area |
Character Code |
Numeric Code |
Some Sample Project Codes |
| Alumni |
AL |
10 - 14 |
ALU |
| Computer Accounting |
CA |
15 - 19 |
CAS |
| DBA Group |
DB |
20 - 24 |
DBA,UNM |
| Financial Aid |
FA |
25 - 29 |
|
| Financial Resource |
FD |
30 - 39 |
FGL,SAR,FAP |
| Human Resource |
HR |
40 - 45 | |
| Student Systems |
SD |
70 - 79 |
DEG,SGP,PSS,SRG,SAS |
The character code and project code are inserted on the right-hand side
of the name (NA-NAME field of the NAME-ID record) of each database person
belonging to the area and project. Example:
-
'SMITH,MARY K. SD SRG'
One of the numeric codes should be used as the first two digits of the
database person's Social Security number in the IDSSN and ID-ALIAS records.
For example, a database person belonging to the Student Development area
could have any of the following SSN's: 701368227, 719002168, 720000000,
731222333, 748888888, etc. . It is anticipated that this numeric prefix
may be used in the future to identify other owned entities in the database,
such as course sections, buildings, rooms, accounts, etc. .
One application area should not tamper with another area's data, whether
to modify or delete it. When an area owns a database person, all records
associated with that person are also owned--except, of course, records
such as course sections, buildings, etc. . Each of the application areas
is responsible for allocating persons among its projects, deleting unneeded
persons and establishing further rules within its own area.
Areas exceeding their 100-person allocations will be asked to delete
the extra person records. During emergencies, extra allocations will be
made available on a temporary basis.
Dialog For Inserting Area and Project
Codes
If in creating a person on the database you should forget to add the area
and project codes, or if you wish to change the codes, use DBOL to
directly update NAME-ID records associated with a person.
DBOL can also be used to directly modify the social security
number of a person on the database without creating an ID-ALIAS record.
Facilities of the Online
Person Area Utility
The person area utility is a set of dialogs accessible to all systems to
provide central, consistent maintenance of the Person, Name-ID, Address
and ID-Alias records of the database. No security is performed with this
utility - except in the sense of enforcing certain rules noted later -
consequently system restrictions need to be considered in the application
design. The following discussion outlines the structure and method of usage
for the utility.
Person area routines are called by an INVOKE 'DUNM050' statement, with
DBA-NAME, DBA-SSN(optional) and DBA-AREA-ID stored in record WUNM050 prior
to the call. Other parameters may be required as appropriate to the application
area. The record used to transmit data between dialogs is as follows:
-
RECORD NAME IS WUNM050 VERSION 2
-
05 DBA-NAME PICTURE IS X(30)
-
05 DBA-SSN PICTURE IS X(9)
-
05 DBA-PER-SEQ PICTURE IS X(6)
-
05 DBA-PER-DBKEY PICTURE IS S9(8)
-
05 DBA-AREA-ID PICTURE IS X
-
05 DBA-STATUS-CODE PICTURE IS XX
-
05 DBA-TR-LK PICTURE IS X
-
05 DBA-CD PICTURE IS X(8)
-
05 DBA-DEPT-ID PICTURE IS X
-
05 DBA-ACTION PICTURE IS X
-
05 DBA-UPD-AREA PICTURE IS X
-
05 DBA-BATCH-NUM PICTURE IS XXX
-
05 DBA-ACA-SEM PICTURE IS XXX
-
05 DBA-ADM-FUNCTION PICTURE IS X
-
05 DBA-INQ-UPD PICTURE IS X
In the text below certain of these variables will be defined and discussed
in more detail.
If only DBA-NAME is given by the calling dialog then the alpha look
up screen will be the first one encountered. If DBA-SSN is given by the
calling dialog it is assumed the person is to have demographic data updated,
if other information update is desired use the PF keys to position within
the utility. Upon return to your process DBA-NAM, DBA-PER-SEQ, DBA-PER-DBKEY
and DBA-STATUS-CODE have been stored for your use. Selection of screens
within the utility is consistent throughout as follows:
-
PF 1
-
RETURN TO THE CALLING DIALOG
-
PF 2
-
DEMOGRAPHIC SCREEN
-
PF 3
-
ALTERNATE NAMES
-
PF 4
-
ADDRESSES
-
PF 5
-
ALPHA LOOK UP
-
PF 6
-
CHANGE IDENTIFICATION NUMBER
-
PF 7
-
.PAGE BACKWARD
-
PF 8
-
PAGE FORWARD
-
PF12
-
HELP FOR THE SCREEN BEING VIEWED
Some functions are not available to all applications or from all screens.
PF5 is effective only for Financial Disbursement and Computer Accounting,
while PF6 is only available to Financial Disbursement.
Upon return to the calling dialog the DBA-STATUS-CODE shows the outcome
of the processing that was attempted, and will be specified with the needs
of the calling dialog's requirements in mind. If new applications require
an indicator for a specific condition please convey a description of the
requirements to the Database Support Group. The error codes currently set
are as follows:
-
CODE
-
CONDITION
-
00
-
SELECTION AND RETURN FROM ALPHA LOOK UP SCREEN
-
01
-
NO SELECTION MADE ON ALPHA LOOK UP BEFORE RETURN
-
02
-
BYPASS FUNCTION ATTEMPTED BY NON-ADMISSION APP'L
-
10
-
SUCCESSFUL ADDITION OF NEW PERSON
-
11
-
ADMISSION BYPASS ADD OF PERSON FAILED
-
20
-
SUCCESSFUL MODIFICATION OF PERSON
-
30
-
SUCCESSFUL ALTERNATE NAME MODIFICATION
-
40
-
SUCCESSFUL ADDRESS ADDITION OR MODIFICATION
-
60
-
SUCCESSFUL CHANGE OF ID NUMBER OF PERSON
-
99
-
OPERATION BACKED OFF BECAUSE OF UPDATE BY SOMEONE
-
XX
-
ANY UNRECOVERABLE DATABASE ERROR
Control is not returned to the calling dialog when an unrecoverable error
occurs.
DBA-AREA-ID initialized by the calling dialog determines the name returned.
The DBA-AREA-ID codes for use by various systems are as follows:
-
CODE
-
APPLICATION
-
A
-
ADMISSIONS
-
B
-
STUDENT ACCOUNTS RECEIVABLE
-
F
-
FINANCIAL DISBURSEMENTS
-
I
-
REGISTRATION CALL FOR INSTRUCTOR ADDITION
-
P
-
COMPUTER ACCOUNTING
-
S
-
REGISTRATION
-
W
-
FINANCIAL AIDS
-
O
-
OFFICE OF SCHOOL RELATIONS (Student Outreach Services)
'A', 'B' and 'S' will return the student name 'I'
the
employee name 'P' the computer-accounting name 'F' the financial
disbursement name 'W' the financial aid name. Names for any area
default to the first name of the set if a primary name has not been designated
for the system.
The ID-Alias dialog is available for change of identification numbers.
It can be accessed by the Financial Disbursement application from the demographic
screen by pressing PF6, or by setting DBA-ADM-FUNCTION to 'I' before
invoking DUNM050. All future applications should use the last method and
consideration should be given to modification of the existing application
to that method also. In that way aliasing can be easily controlled with
security dialogs.
The DBA-ADM-FUNCTION codes were established to permit the current Admissions
system to have limited flexibility within the called dialogs. Since then
it has taken an extended interpretation to allow application to more selectively
tailor screen presentation to their particular needs when they enter this
utility. Any call to DUNM050 with a nonblank entry in DBA-ADM-FUNCTION
presupposes that a previous call has returned a valid DBA-SSN and DBA-PER-DBKEY.
When DBA-ADM-FUNCTION is 'A' the address dialog will be executed.
'N'
The
name dialog, 'B' bypass of alpha look up before person modification
or addition (more about the
'B' option will be specified below),
'D'
the demographic dialog will be executed, and 'I'
the ID-NUMBER
change dialog is entered. Note that when this option is used only that
function specified will be available, i. e., a return to the calling dialog
will be taken when any valid response process is selected. It of course
is the responsibility of the calling dialog to specify a valid DBA-PER-DBKEY
and DBA-SSN for the person they intend to view or modify.
Finally, selection of the QUERY ONLY or UPDATE option is specified
by "U" for UPDATE or "I" for INQUIRY in the variable DBA-INQ-UPD.
The default for this is INQUIRY ONLY.
Most of the remaining elements of WUNM050 are associated with the Registration
system's need to keep the batch system current with the database. In particular
DBA-UPD-AREA determines which of the batch files will be updated when Student
Demographic, Alternate Name or Addresses are changed.
To satisfy the desire to keep the screens of the Admission system unchanged
(relatively), another interface to add or update the Person record without
seeing the central utility's screens was needed. Another record designed
specifically for this interface is structured as follows:
-
RECORD NAME IS UNMW0580 VERSION is 1
-
05 DBA-ADDR1 PICTURE IS X(30)
-
05 DBA-ADDR2 PICTURE IS X(30)
-
05 DBA-CITY PICTURE IS X(23)
-
05 DBA-STATE PICTURE IS XX
-
05 DBA-ZIP PICTURE IS X(9)
-
05 DBA-PHONE-AREA PICTURE IS X(3)
-
05 DBA-PHONE PICTURE IS X(7)
-
05 DBA-NUM-PHONE REDEFINES DBA-PHONE PICTURE IS 9(7)
-
05 DBA-SEX PICTURE IS X
-
05 DBA-CITIZEN PICTURE IS X
-
05 DBA-NUM-CITIZEN REDEFINES DBA-CITIZEN PICTURE IS 9
-
05 DBA-ETHNIC PICTURE IS X
-
05 DBA-NUM-ETHNIC REDEFINES DBA-ETHNIC PICTURE IS 9
-
05 DBA-BIRTHDAY PICTURE IS X(8)
-
05 DBA-BIRTHPLACE PICTURE IS X(15)
-
05 DBA-VISATYPE PICTURE IS XX
-
05 DBA-PERM-ADDR PICTURE IS X
-
05 DBA-DELIVERABLE PICTURE IS X
-
05 DBA-ADDRESS-TYPE PICTURE IS X
-
05 DBA-NAME-DBKEY PICTURE IS S9(8)
-
05 DBA-PRIVACY-INDICATOR PICTURE IS X
-
05 DBA-HANDICAP-TYPE PICTURE IS X
This new record is used to implement the 'B' (Bypass) function,
and supplements the information transmitted by WUNM050. Elements of the
new record which are not spaces will be used to create or update the Person
record. To change an element already stored in the database to an initialized
condition, place an equal sign (=) anywhere in the field. If the DBA-PER-DBKEY
is set to -1 the data will be used to create a new person. It is assumed
that all data transmitted to the subroutine has been fully edited and is
complete as required by the conventions for storing or modifying person
records. Note that IDSSN and NAME-ID records may also be affected. Also
note that it is anticipated that modifications to students will cause the
necessary batch maintenance records STU92RD or STU99RD to be written. The
bypass function is available only to the Admission system and the prospective
Student System (PSS).
Restrictions by DBA-AREA-ID
'B may not change student names - but may establish one if none
exists.
'P or 'F' only may access the alpha look up by use of
the PF5 key (displayed only on Demographic screen but available from all
major screens).
'F only may access the ID Number Change dialog by use of the
PF6 key from the Demographic dialog.

