Date: Mon, 12 Feb 2001 11:50:15
From: Larry Weaver
PSU.LIB subroutine
Returns email addresses for persons associated with a particular application or group of applications. Where ADDRESSES is a list of email addresses delimited by field marks, and APPLICATION.NAME is the key to a record in APPLICATION.EMAILS containing multivalued IDs in field 1.
The same rules outlined in Kathy's email (email follows) should be observed with the use of this subroutine.
Date: Mon, 12 Feb 2001 11:46:21
From: Kathy Sanley
The proliferation of hardcoded email address in programs and paragraphs has worried me for some time. It is difficult and time consuming to grep for people's emails and change them all when someone leaves. Often, reports are being sent to never-never land for a period of time until someone in the department realizes they are no longer getting the report and calls us. Then the programmer has to dig for where the email address is. Also, we have ended up being in the position of changing email addresses when people go on vacation, then changing them back when they return.
In order to facilitate this process and clean it up some, a new file has been created called APPLICATION.EMAILS. It will be used to store the PEOPLE IDS (not email addresses - I'll tell you why later) of individuals who should receive the output email from an application.
Then, when someone leaves and/or goes on vacation, we simply need to find their id in the various records in the file and change it as appropriate.
Note that the field is multivalued, so more than one person can be listed to receive the output.
I have written a generic program in PSU.LIB which can be run from a paragraph and uses 3 data statements to create and execute a SETPTR command from this new file. The program is called SET.APPLICATION.EMAIL and an example of its use is VOCLIB FA.SCH.DELETE.REPORT.
Larry is working on a generic program which can be called from another program and uses this file.
I would recommend using the file in 2 ways:
1. A generic departmental record (example: DCO or FINAID.DIRECTOR) can be set up and used whenever there is a significant (3 or more) applications potentially going to one (or more) person(s) in a department.
2. An application specific record (example: FINAID.DISBURSE) can be set up and used whenever there is one or more people (usually more) who need to receive the output in a minimum number of applications.
PLEASE, PLEASE, PLEASE refrain from using people's names (example: TOM.EMAIL). This somewhat defeats the generic purpose of the file. If Tom leaves and Sam takes his place, we either still have stuff pointing to something called TOM.EMAIL or else we have to change all the paragraphs and programs to now use SAM.EMAIL.
The one exception to the above rule is if you want to set up something for your own use. KATHY.EMAIL, LARRY.EMAIL, THERESA.EMAIL, BECKY.EMAIL, etc., would be OK.
As I said before, we should no longer be hard coding email addresses. Also, as you come across stuff previously written with hard-coded email addresses, it should be changed to use this table file.
As to why we are using people ids rather then email addresses, I will be writing a program which will provide a list on a daily basis of people who have been terminated and who are coded in this file to receive email reports. This should assist us in keeping these reports going out to clients.
If you have questions, please see me.
thanks
kathy