Automatically Generated Lists
NERDC, Office of the Registrar, and UF Bridges jointly maintain a number of email lists, updated nightly from "official" data sources.
UF Business Email Address from the UF Directory
Bridges list extract (MVS procedure #J50LSRV)
OUR Class Roll data (RAV.CLASSROL)
OUR "CStat" (RAV.CSTTD2K)
All MVS jobs run under userid NESYLSTM. class-lists runs on nersp userid nesylstm.
Nightly processing is initiated by cron at 0115 on nersp running:
/u/nesylstm/class-lists -u
class-lists submits member LSTMFAC from MVS data set DB.NESYDBGL.PROJECT using the FTP Get/Put interface to MVS JES2. This job extracts the UF Business Email Address and the UUID from badbadm.aa21em01_email then loads the data into table NESYGRGL.NESYTBLD. Then procedure #J50LSRV is run to extract UUIDs, authcodes, and list names for administrative lists managed by UF Bridges. It then unloads RAV.CSTTD2K to a temporary sequential data set and uses REXX exec RACSLIST in DB.NESYDBGL.EXEC to select UUIDs for lists based on student demographic data. Both sets of data are loaded into DB2 table NESYGRGL.NESYTBAL for later processing.
Member NIGHTLY1 from DB.NESYDBGL.PROJECT is submitted using the FTP Get/Put interface. REXX exec RACSQRPT in DB.NESYDBGL.EXEC is used to extract class roll data from RAV.CLASSROL. Table NESYGRGL.NESYTBCR is loaded from the class roll data extract. Table NESYGRGL.NESYTBL2 is loaded with data selected from a join of NESYTBCR and NESYTBLD to simplify future processing.
class-lists now selects records from yesterday's class roll table (NESYGRGL.NESYTBL1) which are no longer in today's table (NESYTBL2) for lists that have been previously created. Listserv "quiet delete" commands are generated to modify the appropriate lists.
Next records are selected from today's class roll table (NESYTBL2) for requested class sections that do not exist in yesterday's table (NESYTBL1) for created lists. Listserv "quiet add" commands are generated to update existing lists and Listserv Put Commands with full header and subscription information are generated for any lists that have not yet been created. This completes the update process for class roll based email lists.
Maintenance of "Administrative" lists is done by complete replacement of subscribers every night. The first step in this process is to disable auto commits so that a temporary table of authcodes and list names may be created. Records are then selected for administrative lists, and authcode based lists. Update files for each list are built and sent to Listserv. Any record without an email address is written to table NESYGRGL.NESYTBNM.
When all updates have been sent to Listserv, member NIGHTLY2 from DB.NESYDBGL.PROJECT is submitted to update "yesterday's" class roll table (NESYTBL1) for the next processing run.
Finally job NIGHTLY3 from DB.NESYDBGL.PROJECT is run to release a Bridges job to notify them that list updates have been completed.
All DB2 tables used by this application reside on the production (DB0P) DB2 system on NERMVS and are owned by NESYGRGL.
- NESYTBAL
Adminstrative list table. Contains columns named ssn, authcd, list
- NESYTBCF
Configuration table. Contains columns named termname, dbid, prefix, current
- NESYTBCR
Current term class roll table. Contains columns named course, section, cdl, credit, ssn, ccl, name
- NESYTBLD
LDAP information table. Contains columns named ssn, curriculum, email
- NESYTBLR
List request table. Contains columns named course, section, profssn, created, replyto, profmail
- NESYTBL1, NESYTBL2
Course section processing tables. Contain columns named course, section, ssn, name, email
- NESYTBNM
No email address table. Contains columns named ssn, list
- NESYTBYC
Second administrative list table. Contains columns named curriculum, authcode, list
class-lists perl script maintains the automatically generated email lists. The script's name reflects its origin of managing lists for class sections. Over time it has been modified to handle lists requested by Bridges for various employee groups and later to handle various selections from student records.
class-lists [-A] [-C] [-u] [-i instance]
- -A
Do not update administrative lists.
- -C
Do not update class section lists.
- -u
Update class section tables.
- -i
Specify db2 instance name. The default is db2axs.
Administrative lists are created using "normal" list request procedures. This process is only used to manage the list subscriptions on a nightly basis. Subscriptions are managed by full replacement every night using a listserv job with input similar to:
QUIET DEL listname *@* BRIEF QUIET
ADD listname DD=NEWLIST IMPORT
//NEWLIST DD *
email@address1 *
email@address2 *
...
email@addressn *
/*
UF Bridges manages a number of lists from personnel data by creating a table of identifiers (UUIDs), authcodes, and list names. To add a list to this process for them, they request creation of the list then update MVS procedure #J50LSRV. There is no sanity checking of the output of this procedure and it is possible for them to overlay other lists by this process.
A number of lists are maintained for various campus entities by using authcode to select list subscribers. This process is controlled by rows in table NESYTBYC. Authcode masks in this table use db2 "LIKE" style wild cards. To add a new selection insert a row with the curriculum column blank, set the authcode column to the authcode mask and place the list name in the list column. There may be multiple rows with the same list name, a union of all addresses selected will be placed on the list.
Lists based on student demographic data (ie, all Engineering graduate students, or all Marketing Majors) are maintained by updating REXX exec RACSLIST in DB.NESYDBGL.EXEC. This exec can use any values in the Registrar's CSTAT file to make selections. It may be necessary to add fields to the Parse instruction to make the desired selections. The record definition for this file is in RA.M4DEF member RARACS2K.
Class section lists are created and managed by class-lists. To request a new list a row is added to NESYTBLR.
Both the course number and section must be specified.
The created column must be set to 'N'.
The replyto column is set to 'L' for reply to list, anything else (usually 'N') for reply to sender.
If profssn is set, the email address for that identifier in UF Directory is made a list owner.
All email addresses listed in profmail are made list owners.
Class section lists are named:
term-nnnn-L
Where term is the term associated with the class section (fall, spring, or summer) and nnnn is the section number.
Class section lists must be cleaned up by hand at the end of term (ie, delete all lists beginning "spring-") and the NESYTBLR table cleared. Any additions to or deletions from the list made by list owners will not be known about or modified by class-lists. This allows a professor to add TAs or others who should be on the list without interference.
Major changes to OUR's current class roll file can cause a very large number of list modofications. It is possible for the Listserv job to be so large (ie, over a megabyte) that Listserv assumes it is an error and refuses to process it. (Listserv is probably correct in this assumption.) Grade processing for Summer A can be especially bad because all subscriptions for Summer B and C class sections can be dropped due to the way OUR manages the class roll file ( class-lists tries to recognize this and stops processing if there are too many deletes from class section lists).