Chapter I gave a brief overview of program operations for the System, and Chapter II went through the mechanics of creating System input files. 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. Also, some institutions will find it more convenient to batch their outgoing requests and responses and submit them during the late night shift. This has the added advantage of lower nighttime processing rates at NWRDC. In section J, below, you will find a thorough discussion of processing rates.

A word, then, on scheduling and the availability of the System. FIRN2, NWRDC, and the System are, for the most part, 24-hours per day, 7-days per week operations. For the most part 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 6:00 P.M. and midnight. 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 to program SRTS01. SRTS01 edits and posts requests to the mailboxes of Addressed Institutions. Its output consists of an edit report (see Appendix S) that lists any errors and prints the total number of requests posted.

You may also ask the program to produce an error file containing all request records that had errors. This option is selected by entering the letter "B" (instead of "P") in the first column of the parameter statement in the JCL (job control language) stream used to execute this program at NWRDC.

In addition to being able to execute program SRTS01, this program's JCL stream must also manage the transfer of data files between the Sending Institution and NWRDC. The JCL streams that execute the System's programs thus tend to be somewhat complicated. And, since the data transfer procedure depends to a large extent on the makeup of each computer system involved, the JCL streams will differ from institution to institution. For these reasons, the System itself assists user institutions with the development of the necessary JCL streams. This is done as a part of the User Initiation procedure that will be described in the next chapter. In that procedure, OADS staff will walk each institution through the use of the System in the creation of the necessary JCL streams. For purposes of this discussion, however, it will be assumed that these JCL streams already exist.

The sending school district executes program SRTS01 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

Program SRTS02 is used to pick up an institution's request mail. These can be received in the form of a file of requests to be transferred to the institution for local processing, in the form of a printer report, or both. Different JCL streams are used in each of the above cases, and these will be explained in a subsequent chapter.

Program SRTS02 is parameterized to permit an institution to make the selection it wants. Institutions may change the parameter statement in the JCL.

Program SRTS02 permits the retransmission of records. Once request records have been retrieved by an institution, SRTS02 marks the records as having been "delivered." Simply re-executing SRTS02 will not result in the retransmission of these delivered records. To make retransmission happen, the institution will have to change the parameter statement in the JCL from:

CURRENT	(in columns 1-10) Selecting new request records.
to:
RETRANSMITmmddyyyymmddyyyy	(in columns 1 - 26)

where mmddyyyymmddyy represents the access dates between which the institution wishes to have all delivered records retransmitted. Separate sets of JCL can be created for data retransmission. This is also discussed in the following chapters. Should there be some doubt as to the proper range of access dates, you can execute the Incoming Aging Report program (SRTS22) that produces a report of all messages in your mailbox, both delivered and undelivered. This program is discussed in section E of this chapter.

An institution may also choose to pick up only requests sent from a specific institution by replacing the blanks in columns 27-33 with that particular institution's ID, right-justified and zero-filled. Refer to Appendix A for school district ID's and Appendix C for postsecondary institution ID's. This also applies to records sent back from the Bright Futures evaluation and load process. An institution may choose to pick these requests up separately by specifying the Bright Futures institution number (0000095) in this parameter.

Institutions may also pick up the header records of transcripts that failed to post by implementing the parameter in column 34. The valid values are:

In columns 35-37 of the JCL parameter, define the type of transcripts desired.

If the institution wants Interdistrict transcripts, use:

     INT

If the institution wants Secondary transcripts, use:

     SEC

If the institution wants Postsecondary transcripts, use:

     PST

If the institution wants a combination of Interdistrict, Secondary, and Postsecondary transcripts, use:

     ALL

If the institution wants Technical Center transcripts, use:

     TEC

If the institution wants a combination of Interdistrict, Secondary, Postsecondary, and Technical Center transcripts, use:

     ALT

If the institution puts SPACES in position 35-37, the system will default to a combination of Interdistrict, Secondary, Postsecondary, and Technical Center transcripts.

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 execute the JCL stream that executes program SRTS03 at NWRDC. Like program SRTS01, this program has an edit report as its output (see Appendix S) and can optionally produce a file of error records if the proper parameter is set (also the same as program SRTS01). This 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

Program SRTS04 is used to pick up an institution's response mail. As with requests, responses can be delivered as a file for local processing, in the form of a printer report, or both. See Appendices U and V for sample transcript print formats.

Program SRTS04 is parameterized to permit an institution to make the selection it wants. Institutions may change the parameter statement in the JCL.

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.

In columns 1 - 3 of the JCL parameter, define the type of transcripts desired. The valid parameters are the same as in SRTS02.

     INT – Interdistrict Transcripts

     SEC – Secondary Transcripts

     PST – Postsecondary Transcripts

     ALL – A combination of Interdistrict, Secondary, and Postsecondary Transcripts

     TEC – Technical Center Transcripts

     ALT - A combination of Interdistrict, Secondary, Postsecondary, and Technical Center Transcripts

As with program SRTS02, program SRTS04 permits the retransmission of records. The user may request that current (“undelivered”) transcripts be selected or may retransmit records accessed within a specified date range.

CURRENT	(in columns 4-13) Selecting new response records.
to:
RETRANSMITmmddyyyymmddyyyy	(in columns 4 - 29)

where mmddyyyymmddyy represents the access dates between which the institution wishes to have all delivered records retransmitted.

As with requests, an institution may choose to pick up only responses sent from a specific institution by replacing the blanks in columns 30-36 with that particular institution's ID (Appendices A and C), right-justified and zero-filled.

Institutions may also pick up the header records of transcripts that failed to post to their institutions by implementing the parameter in column 37. The valid values are:

E. Aging Reports

This section of the manual deals with confirmation or aging reports. Once, for example, SRTS01 (the request-posting program) reaches normal completion, you can be sure that your student record requests have been stored in your addressees' mailboxes. SRTS01 does not, however, provide you with a report detailing the date and time each request was posted. Moreover, this program has 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 programs have been written to provide this kind of confirmation information. The first is SRTS21, the program that produces the Outgoing Aging Report. The report is so named because it reports to you the status of the requests and the responses you have sent out. Program SRTS21 has four parameters. The first governs the type of output produced by the program, and has values of:

The second parameter is used to restrict the set of records available to program SRTS21 for reporting. If this parameter is set to "Y", the program will exclude any records that appeared on a prior report marked as having been delivered. If this parameter is set to "N", the program will report the status of every header record you've sent out that is still in the data base post office (i.e., that hasn't been archived). Most of the time, you will want the first alternative since you probably won't need to have the delivery date for a record appear on more than one report.

The third parameter is used to restrict the type of record transfer included in the report. The parameter is one character which goes in column 3 of the parameter card and has the values of:

The fourth parameter allows an institution to pick up only records you sent to a specific institution by replacing the blanks in columns 4-10 with that particular institution's ID (Appendices A and C), right-justified and zero-filled.

The System keeps track of the date and time you execute program SRTS21. In the System's eyes, a request or response that was marked delivered prior to the latest execution of program SRTS21 is considered to have been "checked." It is critical that you execute program SRTS21 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 other aging program is SRTS22. This program 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.

Another purpose served by the Incoming Aging Report is to assist in the recovery of lost data. Suppose, through some hardware failure, you find that one of the files of transcripts you pulled down during the first four days of this week has been destroyed. Worse luck is that the backup procedures for these four files were inadvertently not run. You want to retransmit the missing file, but you don't want to retransmit the other three.

Program SRTS22 provides you with a solution to the above problem. The first two parameters to this program permit you to specify a range of access dates to which the program's operation will be restricted. The earliest date (MMDDYYYY) comes first, immediately followed by the latest date (MMDDYYYY). By setting the first parameter to Monday's date and the second to Thursday's, you can produce a list of the requests and responses you picked up during the first four days of the week, arranged according to access dates. From this you can locate the particular retransmission parameters you will need.

Like program SRTS21, program SRTS22 also has a report type parameter. As before, this lets you specify whether you want the program's output in the format of a print report or a data file or both. Respectively, the parameter values are P, F, and B. This parameter appears in the parameter statement just after the access dates in column 17. Thus, a parameter statement used to restrict program SRTS22 to the first three days of August, 2008, and to direct the program to produce only data file output would appear as follows:

0801200808032008F

In general, though, you will most likely request output from program SRTS22 in the form of a printer report. Undelivered mail is reported regardless of the dates placed in columns 1 through 16.

There is also a parameter that is used to restrict the type of record transfer included in the report. This goes in column 18 of the parameter card and has the values of:

The fifth parameter allows an institution to pick up only records sent from a specific institution by replacing the blanks in columns 19-25 with that particular institution's ID (Appendices A and C), right-justified and zero-filled.

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 Batch Program (SRTS31) discussed in this section meets this need.

Like previous programs discussed, the user specifies a parameter indicating the type of output desired: P for printed report only, F for file only, and B for both a report and a file. 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.

A parameter has been added to the parameter card of the program that retrieves the Participation Status File. This parameter lets you retrieve only records for FASTER system participants (when the parameter is "F" or blank), only non-FASTER institutions (parameter value of "N"), or both (parameter value of "B").

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. In addition, when downloading this list, a submission form will also be downloaded. Utilize the submission form to update or add contacts to the list and 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. Note: the sole exception to these rules comes in the special case of consortium processing, where a single institution acts as the processing agent for several institutions. In these cases, a special logon ID is established to handle multiple institution processing. Please see Chapter XIII or a more complete explanation of multiple institution processing.

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

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.

I. Testing Annual Updates

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. Any FASTER user can test their updated code against the new versions by following the instructions below:

1. Copy your production JCL to a test file.
2. Change all occurrences of FRN.DISTRICT.LINKLIB to FRN.DISTRICT.TEST.LINKLIB.
3. Change all occurrences of SYSTEM(DSN) to SYSTEM(DB2T).
4. Change all FN.XXNN to FN.XXNN.TEST where XXNN is the last four characters of your logon id (e.g. if you are FNDX15 then XXNN is DX15).
5. When you have completed testing, copy your production JCL back and you are ready to go.

J. Processing Costs

The staff at DOE are always looking for ways to cut costs. One big expense is processing costs. There is a way that you can help in that regard, by including a job class on your JCL. Some institutions process their FASTER transmission jobs during the day, while others process at night or on weekends, but without a job class. By adding or changing the job class on the JCL, you could save the state up to 75% of the cost of processing that job. Even if you run your job at night, you do not get a cost savings unless you specify the appropriate class.

Whenever possible run FASTER jobs at night or on weekends. Use CLASS C when submitting jobs after 9 p.m. on Monday through Thursday, and CLASS G for jobs submitted after 9 p.m. on Friday or anytime over the weekend. Below is a break down of the job classes and examples of each.

Class C jobs start after 9 p.m. and must finish before 5 a.m. They provide a 40% cost reduction over jobs run during the day, or running with a different job class.

     //FNDXnnSQ JOB (FNDXnn),'USER NAME',  
     //   REGION=4096K,MSGCLASS=A,TIME=(,10),CLASS=C
     /*JOBPARM CARDS=999999,LINES=9999
     /*ROUTE XEQ NWR
     /*PASSWORD ???????
     /*ROUTE PRINT ??????
     //**************************************************************
     //*          STUDENT RECORD TRANSFER SYSTEM                    *
     //*                   POST REQUESTS                            *
     //**************************************************************

Class G jobs start after 9 p.m. on Friday evening and must finish before 2:20 a.m. the following Monday. They provide a 75% cost reduction.

     //FNDXnnSC JOB (FNDXnn),'USER NAME',
     //     REGION=4096K,MSGCLASS=A,TIME=(,20),CLASS=G 
     /*JOBPARM CARDS=999999,LINES=9999
     /*ROUTE XEQ NWR
     /*PASSWORD ???????
     /*ROUTE PRINT ??????
     //***************************************************************************
     //*          STUDENT RECORD TRANSFER SYSTEM                                 *
     //*     PROCESS RESPONSE FILE AND REPORT RESPONSES                          *
     //*************************************************************************** 

Whenever transmissions are not time critical, such as the first Bright Futures/FACTS transmission, please use one of the classes above. If you have any questions or suggestions please contact the FASTER Technical Contact.