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:

  1. Must be authorized via a department head; valid departments are Admissions, Registration,
                    Accounting, Records, and School Relations.

  2. Sign on to IDMS and execute dialog DUNM000.

  3. Select option 3 (Person Deletion Information).

  4. Enter the person's sequence number(default), or the person's SSN.

  5. 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.

  6. 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.


table of contentsprev pagenext page