FLORIDA
AUTOMATED SYSTEM FOR TRANSFERRING EDUCATIONAL RECORDS
FLORIDA DEPARTMENT OF EDUCATION
OFFICE OF APPLICATION DEVELOPMENT AND SUPPORT (OADS)
Effective: October 7, 2024
Revised:
Chapter III
Batch Processing
This chapter will discuss the step-by-step operation of the System as a part of daily production. Program parameters and options will be detailed, as will data security and journaling.
Institutions using the System will be involved with two kinds of record transfer scenarios. First, there will be situations in which a student authorizes one institution to request his or her student records from another institution. This will typically be the case when a primary or secondary student has transferred from one public school district to another. In the other type of transaction, a student will authorize one institution to send the student's records to a second institution, without the second institution having to make a prior request. The forwarding of a Secondary Transcript from a high school to a postsecondary institution is typical of this kind of transaction. Since the second transfer type is a partial subset of the first, the following example involves the first kind of record transfer situation.
A student transfers from a school in one district to a school in another. The new school in which the student is enrolling needs to get the student's records from the prior school. The school collects as much identifying information about the student as possible (name, birth date, SSN, Student Number Identifier, Florida, etc.). Under a manual system, the new school would then contact the old one (in a letter or telephone call) and ask that the student's records be sent. After confirming that the student had withdrawn, the old school would comply with the request. The new school would receive the request, but weeks might pass before the records arrived. Still more time would pass before data entry staff could get the records into the new school's automated files.
The FASTER System takes a different approach. After the new school collects the identifying information, it uses this data to fill out a request record that is collected (on at least a daily basis) by the district office. Note that the procedures involved in collecting request records will differ from institution to institution, depending on the local systems involved. Recognizing that there is a great deal of variety at the local level, the System only starts once the records reach the district office. Thus, it is the school districts, state colleges, technical centers, and universities that are the "users" of the System. Their component schools and campuses do feed information into the System and are listed as Sending and Addressed Institutions; but their participation ends once records reach the district office, and only begins again when requests and responses from other districts reach their district office.
The student's new school also fills in the Message Type field on the request record. Message Type is a codification of the standard messages passed from one school to another when student records are being requested. Valid Message Types are to be found in Appendix D. There are both request and response Message Type codes. Some may not be used by school districts (all are valid for postsecondary institutions). In preparing the request records, the institution will select the most appropriate request code and store it in the Message Type field.
The school district collects the record requests from the student's new school. The school district has the option of submitting the request to the System immediately. This has the advantage of speeding the record transfer process. It is a fact, though, that the System operates more efficiently when batches of records are submitted together.
A word, then, on scheduling and the availability of the System. NWRDC, and the System are, for the most part , 24-hours per day, 7-days per week operations. Both NWRDC and the System have scheduled downtime for normal maintenance purposes. NWRDC is down on Sundays from 2:00 A.M. to 7:00 A.M. The System is down each Sunday between 4:00 P.M. and 7:00 P.M. All times shown are Eastern Standard or Daylight times, depending on the time of year.
A. Posting Student Record Requests
In any event, the school district prepares a batch of request records (and this "batch" could be a single record). As explained in the Introduction, this batch of request records is submitted as input for Process Requested POSTREQS (see Chapter 6. Process Parameter Record). Process Requested POSTREQS edits and posts requests to the mailboxes of Addressed Institutions. Its output consists of 1) an edit report (see Appendix S) that lists any errors and prints the total number of requests posted, and 2) an error file containing all request records that had errors.
The sending school district sends the FN_FSTR_PARAM_INPT.JCLS file with Process Requested POSTREQS to edit the batch of requests and put all requests not having reject errors into the addressees' mailboxes. The edit error report can be used to correct and retransmit any rejected requests.
B. Receiving Requests
Process Requested RTRVREQS (see Chapter 6. Process Parameter Record) is used to pick up an institution's request mail. The output consists of 1) a file of requests to be transferred to the institution for local processing, 2) a summary report of the requests, and 3) a detailed report of requests.
C. Posting Responses
After receiving requests for student records, institutions will follow internally developed administrative procedures for compiling responses. These will involve getting the requests to the staff best able to match the requests against local records and may involve automated systems. This manual will not go into a discussion of all of these administrative procedures. These will be left, primarily, to the individual institutions and their oversight agencies (the Office of Education Information & Accountability Services has distributed a Recommended District Procedures manual for school districts in responding to automated requests for student records).
Responses are prepared as described in Chapter II. Again, institutions must store section "A" information from the request record in section "B" of the response Header Record. Message Types are also selected from the list shown in Appendix D. The school district will batch its responses in the same way (and possibly at about the same time) as it did its requests and sends the FN_FSTR_PARAM_INPT.JCLS file with Process Requested POSTRESP. Its output consists of 1) an edit report (see Appendix S) that lists any errors and prints the total number of responses posted, and 2) an error file containing all response records that had errors. This error file contains the Header Records of each set of student records having edit errors with the number of fatal errors for the transcript stored in columns 1004-1007.
Note that this is where the record transfer process begins in the case of a student asking his or her institution to transfer an unsolicited set of student records. From this point onwards, the procedures are the same whether this set of student records has been solicited by another institution or not.
D. Receiving Responses
Process Requested RTRVRESP (See Chapter 6. Process Parameter Record) is used to pick up an institution's response mail. The output consists of 1) a file of responses (secondary and postsecondary) to be transferred to the institution for local processing, 2) a summary report of the responses, 3) a file of high school transcripts, 4) a PDF file of high school transcripts, 5) a file of postsecondary transcripts, and 6) a PDF file of postsecondary transcripts.
Postsecondary institutions can receive both Secondary and Postsecondary Transcripts. School districts will only receive Interdistrict Records and Postsecondary Transcripts. When first beginning participation in the System, however, a school district may wish to double check its transmission of Secondary Transcripts for accuracy. The System therefore permits a school district to send Secondary Transcripts to itself while in local testing mode.
E. Aging ReportsThis section of the manual deals with confirmation or aging reports. Once, for example, when Processes Requested POSTREQS and POSTRESP (see Chapter 6. Process Parameter Record) reach normal completion, you can be sure that your student record requests/responses have been stored in your addressees' mailboxes. Processes Requested POSTREQS and POSTRESP do not, however, provide you with a report detailing the date and time each request/response was posted. Moreover, these processes have no way of telling you when your addressees actually picked up their mail. This can be important information, especially in responding to students' parents who want to know when their child's transcript reached this or that postsecondary institution.
Two Processes requested AGE-OUT and AGE-IN (see Chapter 6. Process Parameter Record) provide this kind of confirmation information.
The Process Requested AGE-OUT produces output consisting of 1) Outgoing Aging Report of all records, not previously report, that were addressed from your institution to other institutions, and 2) a file containing the header records of all records on the report.
The System keeps track of the date and time you execute Process Requested AGE-OUT. In the System's eyes, a request or response that was marked delivered prior to the latest execution of Process Requested AGE-OUT is considered to have been "checked." It is critical that you execute Process Requested AGE-OUT on a regular basis because records are eligible for archiving and removal from the data base fourteen days after delivery. If your records are removed in this way, you will not have an accurate audit trail for your record keeping.
The Process Requested AGE-IN produces the Incoming Aging Report, a sample of which appears in Appendix X. This report lists the contents of your data base mailbox grouped by access date, requests/responses, sending institution, addressed institution, posting date and time and student name. With this report, you can see whether or not you have any mail to pick up. Since the report lists the posting date of each message, you can also see how long the requests and responses have been waiting for you.
The Process Requested AGE-IN produces output consisting of 1) Incoming Aging Report of all records, not previously report, that were addressed to your institution from other institutions, and 2) a file containing the header records of all records on the report.
F. Participation Status
Institutions using the System need to have an up-to-the-minute list of the institutions with whom they can exchange records. After all, sending transcripts to the mailbox of an institution that is unable to pick them up accomplishes nothing. The Participant Status Summary Report created by the Process Requested PARTSTAT (see Chapter 6. Process Parameter Record) discussed in this section meets this need.
The Process Requested PARTSTAT produces output consisting of 1) FASTER/SPEEDE Participant Status Report of FASTER and SPEEDE participants, and 2) a file containing the FASTER and SPEEDE participants on the report. A sample of the printed report can be seen in Appendix Y and the record layout format for the file generated is supplied in Appendix K.
The participant status of an addressee institution may affect what happens when a record is processed. When a transcript is sent to a "HEADERS ONLY" institution, the edit program returns an informative error to the sending institution indicating that the transcript was ignored. Only the header record is posted to the addressed institution. The print program will indicate that the reason no transcript was attached is because of the "HEADERS ONLY" status of the receiving institution.
Using the batch file at the local site to validate the participation status of an institution before transmitting records to an institution is an effective way of saving both personnel time and computer resources. During the beginning stages of the electronic transfer of student records, it would be wise to run this program on a regular basis to keep your local file up to date. Of course, once all institutions are in full production mode, the utility of this program will disappear.
Now that the system interfaces with the national electronic transcript system SPEEDE/ExPRESS, the participation status file and report must contain information on our non-FASTER electronic trading partners. The Number of Institution field will be 0000099 in the case of a non-FASTER elementary/secondary school, and 0010002 for non-FASTER postsecondary institutions. A field has been added to the file and report to record the non-FASTER institution's National Institution ID (a 15-byte field that must be included in the Header Record when exchanging records with a non-FASTER institution). PGP Compliance and Non-PGP Acceptance code fields have also been provided, as well as fields representing an institution's status with respect to the SPEEDE and ExPRESS portions of the national system.
G. FASTER Contacts
Effective communications between FASTER participants is greatly increased when contact
lists are available and kept up to date. A list of
FASTER Community Technical Contacts has been added to the FASTER home page.
This is a list of technical contacts by district and institution which can be either
downloaded or viewed to facilitate communication regarding technical aspects of
the FASTER system.
To update or add contacts to the list, e-mail it to FSTR@fldoe.org.
H. Security and Header Record Archival
Since the System transfers student records covered by a number of confidentiality laws and regulations, data security is of high importance. Access to working files is controlled through each user's logon ID. To see these files a person must have access to the institution's logon ID and password. If these are kept safe, data security is assured. As an additional security measure, only logon ID's that have been marked as participating in the System are permitted to execute the System programs that access the data base mailboxes.
The System's programs also make sure that the institution's logon ID matches the code of the institution that makes each individual transaction. Thus, one school district could not send a set of student records labeled as coming from another district. And one institution has no access to requests and responses stored in the mailbox of any other institution.
Another security feature is that the data base itself can be accessed directly only by the NWRDC systems manager and the OADS systems administrator. No other access to the data base is permitted, excepting the access granted each participating institution to execute the System's Process Requested in FN_FSTR_PARAM_INPT.JCLS file (see Chapter 6. Process Parameter Record).
As long as all logon ID's and passwords remain secure, the student records will remain confidential. In addition, a journal is kept of any access (read or write) to any request or response that passes through the System. A copy of each Header Record is kept, together with a date and time stamp and the logon ID of the user that made the access.
As previously mentioned in Section E of this Chapter, records remain on the system for at least fourteen days after they have been downloaded by the addressed institution, changing the status from "unseen" to "delivered." After fourteen days, delivered records are deleted from the system. Each Sunday evening, delivered records fitting the above criteria are deleted. Only the Header Records written to the journal files remain as an indication that the records ever passed through the System.
FASTER software is updated annually to stay current with DOE data element definitions and edits, as well as to meet the needs of the FASTER user group. The upgrade of the software usually takes place in mid-November. However, the OADS staff makes the updated versions of the programs used to post and receive transcript requests and responses available before that time, in a test environment. See Chapter 6. Parameter Process Record. In Section 1 - General Format of the Process Parameter Record, see Process Qualifier information for test submissions.
FASTER users are notified via
the FASTER website, www.firn.edu/faster, and via the FASTER listservs
when the programs are available.