The initiation procedure creates eight sets of job streams which you can edit and save under the logon ID you will be assigned by FIRN. Appendix M contains a sample of the generated Job Control Language (JCL). In this appendix ACCT represents your 6-character NWRTSO logon ID provided by FIRN (e.g. FNDX03). DSNPRFX represents your default dataset name prefix which is generated from your logon ID by inserting a period between characters 2 and 3 (e.g. FN.DX03). All editing is done with the facilities of ISPF under TSO. After a dataset has been edited and saved you can submit it via the System's menu screens or through any other process by which batch jobs may be submitted for execution at NWRDC.

As an MVS site, your institution will be able to use IBM's File Transfer Program V2 (FTP V2) to transmit your requests and responses to and from NWRDC. FTP is a VTAM batch application in which jobs at two data centers get into a file transfer session with each other. Files are transferred via an error-checking protocol. In the event of a failure in the data communications link between the two data centers, FTP provides a facility for restarting the session between the two jobs at the point that it was interrupted.

This manual is not designed as an instructional text in how to use FTP. The JCL streams you create will have the correct file transfer control statements automatically provided in the proper place. There should be no need for you to become a file transfer expert. For those who wish to learn more about how to transfer files between data centers, Appendix E should prove instructive.

Since file transfer using FTP depends on the execution of jobs at two data centers, each of the JCL streams you are about to create will submit more than one job. The execution of the two jobs need not be simultaneous: FTP V2 jobs are able to wait (30 real time minutes in this case) for the companion job at the other data center to begin execution.

A JCL stream could be generated in which two separate jobs were submitted, one for execution at your data center, the other for execution at NWRDC. This could, though, cause a problem in the event that, when you submitted the jobs, your data center was up and running while NWRDC was down. The NWRDC job would never execute and your job would spend the entire 30 minute wait time occupying one of your local initiators, waiting for a companion job that would never begin.

To avoid this problem, the JCL streams created by the System begin by submitting a single job for execution at NWRDC. This job will then submit a second job to the internal reader for execution at your site. In this way, the System is assured (as much as possible) that both jobs will be able to begin execution at just about the same time. No jobs will begin executing until it is known that both data centers are operational.

To conduct the initiation session, logon to TSO under the FIRN-provided logon ID. After a brief pause, you will be presented with a menu screen similar to the one shown in Figure VI-1. This menu has eleven options, plus one more for exiting the menu. Note that when you exit this menu, you will then be presented with the ISPF Information Center Menu screen. You can exit this screen by pressing PF3 (program function key 3), and sign off by typing logoff and pressing the return key. However, do not select exit at this point. Select option U, instead, to update your profile default values.

By selecting option U (type the letter U on the COMMAND line and press the return key), you will be presented with a screen resembling the one shown in Figure VI-2. Eleven parameters are presented:

Node Name
Remote ID
Transfer Type
Site Sending LU
Site Receiving LU
NWRDC Sending LU
NWRDC Receiving LU
File Type
FTP Checkpoint Restart DSN
FTP Load Library Name
FTP Checkpoint Restart VCAT

If you do not already know your Node Name and Remote ID, consult your systems personnel. These values, which may already be filled in, determine where your local jobs will be routed for execution and where your printer reports are to be sent. Please check them for accuracy.

As an MVS installation, your Transfer Type will be MVS. The next four parameters have been taken from the tables in Appendix G. Under FTP, sending and receiving logical unit (LU) names are paired because, at any given time, a logical unit may only be executing at a single site within VTAM. You must only use the receiving NWRDC logical unit name that is lined up with your sending logical unit name, and vice versa. Otherwise, you cannot be sure that the logical unit name with which you are to begin a data transfer session is not already in use. It is still possible for your jobs to be locked out (if someone at your site is already using FTP) but using the proper logical unit names minimizes this risk. Your correct logical unit names should already have been entered, but check Appendix G to make sure. Contact FIRN if you think your logical unit names have been entered incorrectly.

Your File Type will probably be SAM (Sequential Access Methods). Consult your systems personnel for the name of your FTP Checkpoint Restart DSN and your FTP Load Library Name. The last parameter, FTP Checkpoint Restart VCAT, is applicable to DOS/VSE sites only and should be left blank.

After entering these parameters, type go on the line at the bottom of the page. This will cause the System to update your institutional profile, and return you to the main menu. Alternatively, you may type can to abort this execution, returning you to the main menu with your original profile intact.

After typing go or can, you will again be returned to the System's main menu. You are now ready to generate your first JCL stream. This is the stream that will execute program SRTS01 and post a batch of requests to your addressees' mailboxes. Type the number 4 on the COMMAND line. Then type a g into the Generate/ Edit/Submit field in the lower right hand corner of the screen where, in Figure VI-1, it reads:

Job Stream (G, E, or S) ==>

This lets the System know that you want to generate an entire new JCL stream. Had you typed an e you would have told the System that you wanted to edit a JCL stream that you had previously generated (you will select this option when, at some later date, you need to make a change to the JCL you have stored at NWRDC). Use the s option when you want to submit a previously generated and edited JCL stream to NWRDC for execution.

After typing the g, press the return key. You will then be presented with a screen similar to the one shown in Figure VI-3. This screen has multiple parameters, dealing with your local settings

Job Class
Job Time
FTP Checkpoint Restart DSN
FTP Loadlib Name
Input Dataset Name
Input Dataset Type
Input Dataset Record Count
Output Type
Output Dataset Name
Output Dataset Type
Output Dataset Space Allocation, Primary
Output Dataset Space Allocation, Secondary

Filling in these parameters lets the System produce a JCL stream that will run at your local site. Therefore, fill in Job Class according to your local standards. Ten seconds--entered as (,10)-- is the default Job Time setting. This default is sufficient to process about 1,500 requests, so you probably won't have to adjust it in the normal course of affairs. Please keep in mind that you already entered your FTP Checkpoint Restart Dataset and Load Library names in Section A. You may change them here, but you will likely not need to.

Input Dataset Name is the name of the dataset on your local system on which you have stored your requests. Space is provided here for a DSN of up to 44 characters. Dataset Type will probably be SAM (Sequential Access Methods). Number of Records is used to calculate SPACE requirements at NWRDC. Set this to the largest reasonable number of request records you anticipate transmitting at any one time. Be aware, for the future, that you may need to adjust the SPACE parameters in your JCL stream if this maximum is exceeded.

The JCL that will be created for you will automatically route your edit report to your remote printer. You may also elect to have a file containing all rejected records transmitted to your local site by setting Output Type to "B". If you do this, you will need to enter the characteristics of the dataset that will hold this error file. Its data set name may also be up to 44 characters in length. Set dataset type as before. You must also set Primary and Secondary SPACE allocations for this dataset in terms of tracks.

After setting all parameters, press the return key. The System, using the information provided in your profile, will create a JCL stream and write it to a dataset under your FIRN-provided account. You will then be presented with a screen similar in appearance to the one shown in Figure VI-4. This is an ISPF editing screen. In the upper left hand corner is the name of the dataset being edited (the dataset which contains the JCL stream that has just been generated). This name will be in the format

DSNPRFX.REQUESTS.ONTO.SYSJCL

where DSNPRFX is your default dataset name prefix. ISPF is a full screen editor, with "PF" (program function) keys displayed on the lower two lines of the screen. It is similar to many mainframe editors and, if you need assistance on using it, you may press PF1 and receive on-line HELP on any of ISPF's features (pressing PF3 ends the HELP session). Figure VI-4 displays a window which, at this time, is looking into the first 19 lines of the JCL stream.

Pages 2 through 7 of Appendix M contain the text of the JCL stream you have generated. The first 14 lines contain some notes on which lines in the JCL stream need to be edited. Note that, after all other editing is complete, you must delete any line that begins with the word NOTE.

There are five sets of lines that you must edit. These are labeled with plus signs (++) in the first 2 characters. They are grouped according to the five jobs this JCL stream will execute:

Note that, while the editing and posting of your request records could have been done as a part of the first job, a second job is executed instead. This is done to free up a Class F initiator at NWRDC, under which all FTP jobs at that data center are submitted. The editing and posting of your request records are not data communications operations and can be carried out on one of NWRDC's standard job initiators. Thus, you will free up an NWRDC class F initiator while you are not communicating so that other data communications jobs are not kept waiting.

Preceding each set of lines to be edited is a set of NOTEs that explains the necessary editing. You may edit this dataset in any way that you wish, as long as you finish by removing all characters between the pair of double plus signs, the double plus signs themselves, and any line beginning with the word NOTE. Suppose, for example, you want to edit the JOB card of the job that executes on your local system, replacing the parameter PROGRAMMER NAME with your name. Initially, the line would look like this:

After editing to change PGMR NAME to JANE DOE, this line would appear as follows:

/FNDX03SD JOB (FNDX03,10,10,2),'JANE DOE',MSGLEVEL=(0,0),

Many of the statements marked with double plus signs will not need any editing (other than removal of the double plus labels), since you will have provided the necessary information on the previous screen and when you set your profile values. Most of the remaining statements will not need to be considered for any editing at all. As stated above, though, you may use the editor to make any changes you think are fitting.

Note, on page M-4, the following lines:

//PARAM DD *
B

This is the parameter statement for program SRTS01. The parameter, in the first column, has been set to "B", directing the program to produce both a printer report and a data file of the records rejected for having edit errors. Note (on page M-4) that the formats for the parameter statements for this and all System programs are provided as comment statements in each JCL stream you will generate. If you wanted the program to produce only the printer report, you would need to change the "B" to a "P". You would also need to change the five-line DD statement for the request error file RQSERRS to the following single line:

//RQSERRS DD SYSOUT=A

In addition, the last two jobs (which transmitted the error data file to your local site) would also need to be deleted.

There is one situation in which you would need to make additional modifications. If you are processing more than 2,100 requests, you will need to increase the size of the dataset used to receive your request records at NWRDC. This dataset appears on page M-3 and is labeled with DD Name DD1. You will also need to adjust the size of the four SORTWK datasets that appear at the bottom of page 4 and have SPACE allocations set to (TRK,(3,3),RLSE). Room for 2,800 requests would be provided by changing the SPACE allocations for each of these five datasets to (TRK,(4,4),RLSE). Another 700 can be provided by increasing SPACE to (TRK,(5,5),RLSE), etc.

When you have made all the edits you wish (remembering to delete the NOTE lines) you may exit the editor by pressing the PF3 key. The System will then present you with a screen

similar to the one shown in Figure VI-5. This screen presents you with two questions. In the first, you are asked whether or not you want to have the JCL you just edited saved as a disk file. The default value is to have the JCL saved.

The second question gives you four choices. You can:

This fourth choice is one you can use if you wish to use the on-line System to release your batch jobs for execution.

If you choose to have the JCL stream routed to your local PUNCH queue, you must also enter the two fields at the bottom of the screen: Job Name, and Programmer Name. You may also enter alternate PRINT and/or PUNCH remote queue designations in the two fields provided at the bottom of the screen.

When you have completed filling out this screen, press the return key. The System will then perform the operations as you have directed and return you to the main menu (unless your choice was to return to the editor). You will have created the JCL stream necessary to post a batch of request records to the System.

You are now ready to generate the JCL stream that will execute program SRTS03 and post a batch of responses to your addressees' mailboxes. Type a 5 on the main menu's COMMAND line, and a g into the Generate/Edit/Submit field on the lower right hand corner of the screen to let the System know that you want to generate a new response-posting JCL stream. After typing the g, press the return key. You will then be presented with a screen resembling the one shown in Figure VI-6. Fill in these parameters in the same way that you did in Section B.

Job Class should be set in the same way as for request processing. Ten seconds, the default Job Time setting, is sufficient to process about 91 transcripts (say, 9,100 response records). You may need to adjust this parameter. If you have to err, do so on the side of safety. For example, if you have 1000 transcripts to process with an average of 100 response records per transcript, that would leave program SRTS03 with 100,000 response records to process. That is about 11 times as many records than it would be safe to attempt to process with a time limit of 10 seconds, the default. Eleven times 10 gives 110 seconds, or one minute fifty seconds. It would be reasonable to round this up to a full two minutes, which would be rounded up and typed as (2).

After setting all parameters, press the return key. The System, using the information provided in your profile, will create a JCL stream and write it to a dataset under your FIRN-provided account. You will again be presented with an ISPF editing screen similar in appearance to that shown in Figure VI-4. The dataset you will be editing, this time, will be named:

DSNPRFX.RESPONSE.ONTO.SYSJCL

where DSNPRFX is your default dataset name prefix.

Pages 8 through 13 of Appendix M contain the entire text of the JCL stream you have generated. This JCL stream is very similar to the stream for posting requests. You edit the same five sets of lines, and there are the same NOTE lines to be deleted. The main difference is in the names of the datasets being sent and received. Also, this JCL stream will execute program SRTS03.

As with requests, you will need to adjust the SPACE allocations of your DD1 and SORTWK datasets if relatively large numbers of response records are being processed. An allocation of (TRK,(22,3),RLSE) is sufficient to process about 3,000 response records (or 60 transcripts of 50 records each). An allocation (CYL,(1,1),RLSE), on the other hand, would provide room for about 10,000 response records. Adjusting this allocation to (CYL,(2,2),RLSE) on all four datasets doubles that number. (CYL,(3,3),RLSE) triples capacity, etc.

Note, on page M-11, the following lines:

//PARAM DD *
B

This is the parameter statement for program SRTS03. The parameter, in the first column, has been set to "B", directing the program to produce both a printer report and a data file of responses found to have edit errors. If you wanted the program to produce only the printer report, you would need to change the "B" to a "P". You would also need to change the five-line DD statement for the response error file RSPERRS to the following single line:

//RSPERRS DD SYSOUT=A

In addition, the last two jobs (which transmitted the error data file to your local site) would also need to be deleted

It is possible, though unlikely, that you will need to adjust the TIME parameter on the first NWRDC job, the one that receives the response records you are sending. Ten seconds is sufficient to process more than 150,000 response records( i.e., 3,000 transcripts of 50 records each). There will rarely be a need for anyone to transmit this many records at one time.

When you have made all the edits you wish (remembering to delete the NOTE lines), exit the editor by pressing the PF3 key. The System will then present you with a screen similar to that in Figure VI-5. Resolve the questions put to you by this screen in the same way as you did with the request-posting JCL stream. Then press the return key. The System will perform the operations as you have directed and return you to the main menu (unless your choice was to return to the editor). Now you will have created both of the JCL streams used to get records from your files to the System. The next two sections deal with the flow of records in the opposite direction.

This time, select the RECEIVE REQUESTS option by typing a 6 on the main menu's COMMAND line and a g in the Generate/Edit/Submit field, and then pressing the return key. You will be presented with a screen that looks similar to the one shown in Figure VI-7. This screen has four parameter fields you can fill in:

Selection Criteria (Current/Retransmit)
Beginning Date (for retransmission)
Ending Date (for retransmission)
Output Type

The Selection Criteria field governs the type of request records that are to be retrieved by the JCL stream you are going to create. Normally, you will be retrieving those requests in your mailbox that have not yet been delivered. These are referred to as your "current" requests. Retransmission of request records (meaning, literally, the retrieval of records that already have been retrieved at least once) will be dealt with in Section F, below.

To select your current requests, type current in the Selection Criteria field in the upper right of the screen. The next two fields, Beginning and Ending Date, are applicable only to record retransmission situations. Leave them blank.

The fourth field specifies the form in which you wish to receive the request records from the System. You may choose to receive your requests as a machine-readable file (by typing the letter f) or as a printer report in the format shown in Appendix T (by typing the letter p). You may also elect to have both of the above operations performed, by typing the letter b.

For purposes of this discussion, both a machine-readable file and a printer report will be selected. Having typed the letter b on the next to the last printed line shown in Figure VI-7, you will then press the return key. Note that if you wish to cancel the entire operation and return to the main menu you may press the PF3 key.

You will now be presented with a screen similar to the one shown in Figure VI-8. The following parameters (dealing with settings for your local MVS site) may be entered:

Job Class
Job Time
FTP Checkpoint DSN
FTP Load Library Name
Output Dataset Name
Output Dataset Type
Output Dataset Space Allocation, Primary
Output Dataset Space Allocation, Secondary

Set Job Class according to your local standards (NWRDC uses class F for FTP jobs, and your installation may have its own setting). Job Time is the time for the job that will receive the request records at your local site, and will probably not be too large (ten seconds should usually be adequate). FTP Checkpoint and Load Library names will have been set to the values you entered into your profile in Section A and will probably not need adjustment.

Output Dataset Name is specified in the same way as Input Dataset Name in Section B, but provides the name of the dataset you want requests written to instead of read from. You follow the same kind of logic in entering these criteria as you did in Section B (for posting requests). Dataset Type will likely be SAM (Sequential Access Methods). Primary Allocation and Secondary Allocation (both given in tracks) will be used to set the SPACE allocation of the Output Dataset Name at your local site.

After pressing return, you will be presented with a screen similar to that shown in Figure VI-4. This time you will be editing a file named DSNPRFX.REQUESTS.FROM.SYSJCL, where DSNPRFX is your default dataset name prefix. This file will contain a JCL stream similar to that contained on pages 14 through 17 of Appendix M. This time, there are three sets of lines that you will edit in the same way as you edited the JCL streams in Sections B and C, above. These three sets correspond to the following jobs:

In this JCL stream there is only one other dataset whose SPACE allocation might possibly need to be reset. This is the dataset with DD name RQSFILE that appears on page 15 of Appendix M. Its allocation is set to (TRK,(3,3),RLSE), which is sufficient to hold about 2,100 request records. If you anticipate receiving more than this number of requests, you can add 700 requests additional capacity for each (1,1) that you add to the SPACE allocation. For example, you would leave room for 1,400 additional requests (for a total of 3,500) by setting the allocation to (TRK,(5,5),RLSE).

Note the parameter statements on page M-15:

//PARAM DD *
CURRENT

These statements were generated by the System because "current" requests were selected from Figure VI-7, above. Also note in the comments section on page 15 of Appendix M that a sending institution can be specified in columns 27 through 33 of the parameter card. This parameter allows you to select only those records that originated from a specific institution.

You may also wish to modify the parameter input line. In addition to the parameters generated by the initiation process, there is an optional parameter (see Appendix W) that can be used with program SRTS02. This is Sending Institution, a seven digit field for the institution code which allows you to specify the records to be selected by the institution that sent them. See Appendix M, JCL for Extracting Requests, for a byte by byte layout of the parameter fields.

There may or may not be any requests waiting for you in your mailbox, so the file that is created may be empty. You will know whether there were any requests by reading the request summary report (DD name RQSUMRY) which is routed to your remote printer.

Edit this JCL stream in the same way as you edited the JCL streams that will execute programs SRTS01 and SRTS03. Then press PF3 to exit the ISPF editor. You will then be presented with a screen similar to the one shown in Figure VI-5. Make your selections on this screen in the same way as you did in the two previous sections and press the return key to execute the functions specified and return to the main menu (unless you opted to return to the editor). When you are presented with the main menu, you will have created the JCL stream necessary to retrieve request records from the System.

This time, select the RECEIVE RESPONSES option by typing a 7 on the main menu's COMMAND line and a g in the Generate/Edit/Submit field, and then pressing the return key. You will be presented with a screen that looks similar to the one shown in Figure VI-9. This screen has five parameter fields you can fill in:

As with requests, the Selection Criteria field governs the type of records that are to be retrieved by the JCL stream you are going to create. Normally, you will be retrieving those responses in your mailbox that have not yet been delivered, your "current" responses. Retransmission of response records will be dealt with in Section F, below.

To select your current responses, type current in the Selection Criteria field in the upper right of the screen. The next two fields, Beginning and Ending Date, apply only to record retransmissions, so leave them blank. As with request retrieval, Output Type specifies the form in which you wish to receive the response records: as a File, a Printer report, or Both.

Response Type indicates, for postsecondary institutions, the type of transcript you wish to receive. Postsecondary institutions are permitted to receive either Secondary Transcripts (by typing sec), or Postsecondary Transcripts (by typing pst), or both (by typing all). Districts can receive all three types of records. Interdistrict Records are specified by typing int, Secondaries by typing sec and Postsecondaries by typing pst. Typing all, of course, results in the selection of all types of records available. Any institution can send any type of record to itself, which it may wish to do when it is in the status of Local Testing (see section K of this chapter). When an institution types all, the JCL that is generated includes both print programs (SRTS12IS and SRTS12P) in the event that more than one type of record is available. See Appendix M, JCL to Extract Responses, for an example.

For purposes of this discussion, both a machine-readable file and a printer report will be selected. Having typed the letter b on the next to the last printed line shown in Figure VI-9, you will then press the return key. Note that if you wish to cancel the entire operation and return to the main menu you may press the PF3 key.

You will now be presented with a screen similar to the one shown in Figure VI-10. The same parameters are entered as in Section D. The Job Time concerns are roughly the same. In this case, the default value of 10 seconds would be sufficient to process about 50 sets of Interdistrict Records or transcripts. You should not need to adjust this default unless you, for some reason, need to process a greater volume of responses in a single execution of program SRTS04.

After pressing return, you will be presented with a screen similar to that shown in Figure VI-4. This time you will be editing a file named DSNPRFX.RESPONSE.FROM.SYSJCL, where DSNPRFX is your default dataset name prefix. This file will contain a JCL stream similar to the one shown on pages 18 through 24 of Appendix M. There are the same three sets of lines that you edited in Section D. These correspond to the following jobs:

Note in the comments section that begins on page 18 of Appendix M that a sending institution can be specified in columns 30 through 36 of the parameter card. This parameter allows you to select only those records that originated from a specific institution.

Some attention should be paid to the setting of the SPACE allocation for the dataset with DD name RSPFILE (the dataset to which the retrieved responses will be written). Its allocation of (CYL,(1,1),RLSE) is sufficient to hold about 10,000 response records (or about 200 fifty-record transcripts. An additional 10,000 records of space can be added for each (1,1) added to the specification. For example, a setting of (CYL,(3,3),RLSE) would leave room for a total of 30,000 response records (which would be 600 transcripts of 50 records each).

There may or may not be any responses waiting for you in your mailbox, so the file that is created may be empty. You will know whether there were any responses by reading the response summary report (DD name RSSUMRY) which is routed to your remote printer.

Edit this JCL stream in the same way as you edited the JCL streams in the last three sections. Then press PF3 to exit the ISPF editor. You will then be presented with a screen similar to the example shown in Figure VI-5. Make your selections on this screen as before and press the return key to execute the functions specified and return to the main menu (unless you opted to return to the editor). When you are presented with the main menu, you will have created the JCL stream necessary to retrieve response records from the System.

Situations may arise in which you will find it useful to have certain records retransmitted (such as when the originally retrieved records were lost or damaged). You can request the generation of a retransmission JCL stream by giving different answers to the questions posed by the screens represented in Figure VI-7 and VI-9 (for requests and responses, respectively). Instead of typing the word current in the first field, type the word retransmit. Then fill in the range of access dates for which you wish to retrieve records for retransmission, using the Beginning Date and Ending Date fields. After this screen, everything else is the same as in the case where current (undelivered) records are requested. Note that only previously delivered records are retrieved when retransmission is selected.

Thus, you can use the screens shown in Figures VI-7 and VI-9 to generate retransmission job streams. These will, however, overwrite any request/response receive JCL streams you may already have created. As an alternative, you might simply edit your existing request or response JCL streams when a need for retransmission arises. The statements following the PARAM DD statements in the SRTS02 and SRTS04 job steps (shown on pages M-15 and M-19, respectively) will need to be changed:

where mmddyyyymmddyyyy are the beginning and ending access dates of the date range you wanted to select (for example, 0701198907031989 to retrieve all delivered records accessed between July 1st and 3rd, 1989). You would do this by typing the letter e in the main menu's Generate/Edit field and selecting either option 7 or 8, depending on the JCL stream you wanted to edit. Then, after submitting the retransmission job, you would return to edit mode (again through the main menu) and return the JCL stream to its original state, this time instructing the System to save but not execute the JCL stream.

You will be able to decide which procedure works best for your institution. You may wish to save separate copies of the JCL streams that request current or previously delivered (retransmit) records. You would do this by saving the copies to different datasets. Note that the System can only be used to submit JCL streams stored on datasets DSNPRFX.REQUESTS.FROM.SYSJCL or DSNPRFX.RESPONSE.FROM.SYSJCL, for requests and responses, respectively (where DSNPRFX is your default dataset name prefix). To submit a JCL stream stored on a different dataset, you will need to exit the System and submit the JCL directly from ISPF (a simple procedure, but those not conversant in TSO/ISPF may need to speak with FIRN personnel for instructions upon how this is done).

The resulting dataset might contain additional records that you had already received, but no information would be lost.

In this section you will create the JCL stream used to execute program SRTS21, the Outgoing Aging Report generator. With this program, you will be able to track the request and response records sent out from your local system as they are posted to your addressees' mailboxes and, ultimately, received by your addressees. Records you send will only remain in the post office data base for a predetermined length of time as stated in section E of Chapter III. Therefore, it is imperative that this program be executed on a regular basis if you wish to have an accurate audit trail for all your outgoing requests and responses.

From the System's main menu; type an 8 on the COMMAND line, a g on the line in the lower right-hand corner labeled Job Stream (G, E, or S) ==>, and press the return key. You will be presented with a screen similar to the one shown in Figure VI-11. There are two parameters to be filled in: Output Type (with the standard File, Printer report, or Both options) and Record Status Restriction.

Record Status Restriction is the parameter used to keep redundant information from appearing on the report. Typing a y in this field directs program SRTS21 to ignore those records that had achieved "delivered" status prior to the last time this program was executed with a value of "Y" in the parameter. Typing the letter n, on the other hand, directs the program to report the status of every request and response that you sent out that still remains in the post office data base

Fill in the two parameters and press the return key. You will now be presented with a screen similar to the one shown in Figure VI-12. Enter these parameters as you did in Section D. In this case, the default value of 10 seconds would be sufficient to process about 750 requests and/or response Header Records. Adjust this parameter if you have sent out more messages than that and press the return key.

You will be presented with a screen similar to the one shown in Figure VI-4. This time you will be editing a file named DSNPRFX.OUTGOING.FROM.SYSJCL, where DSNPRFX is your default dataset name prefix. This file will contain a JCL stream similar to that shown on pages 25 through 28 of Appendix M. There are three sets of lines that you will edit in the same way as you edited the JCL stream in Section D, above:

In this JCL stream there is only one dataset whose SPACE allocation might possibly need to be reset. This is the dataset with DD name AGEFILE that appears near the top of page 22 of Appendix M. Its allocation is set to (TRK,(3,3),RLSE), which is sufficient to hold about 2,100 Header Records. If you anticipate receiving more than this number of records, you can add 700 requests additional capacity for each (1,1) that you add to the SPACE allocation. For example, you would leave room for 1,400 additional requests (for a total of 3,500) by setting the allocation to (TRK,(5,5),RLSE).

After editing this JCL stream, press PF3 to exit the ISPF editor. You will then be presented with a screen similar to the one shown in Figure VI-5. Make your selections on this screen and press the return key to execute the functions specified and return to the main menu.

In this section you will create the JCL stream used to execute program SRTS22, the Incoming Aging Report generator. With this program, you will be able to check the access dates and status of the request and response records that have come into your mailbox. Use this report to assist in the identification of records for retransmission purposes.

From the System's main menu, type a 9 on the COMMAND line, a g on the line in the lower right-hand corner labeled Job Stream (G, E, or S) ==>, and press the return key. You will be presented with a screen similar to the one show in Figure VI-13. There are two parameters to be filled in: Output Type (with the standard File, Printer report or Both options) and Access Date Range. Access Date Range must be filled in. There is a field for Beginning Access Date and a field for Ending Access Date, both formatted mmddyy.

Fill in these parameters and press the return key. You will now be presented with a screen similar to the one shown in Figure VI-14. Enter these parameters as you did in Section G.

As with the Outgoing Aging Report generator, the default value of 10 seconds would be sufficient to process about 750 requests and/or response Header Records. Adjust this parameter if there are more messages than that in your mailbox and press the return key.

You will be presented with a screen similar to the one shown in Figure VI-4. This time you will be editing a file named DSNPRFX.INCOMING.FROM.SYSJCL, where DSNPRFX is your default dataset name prefix. This file will contain a JCL stream similar to that shown on pages 29 through 32 of Appendix M. There are the same three sets of lines to edit as in Section G.

In this JCL stream there is only one dataset whose SPACE allocation might possibly need to be reset. This is the dataset with DD name AGEFILE that appears near the top of page 26 in Appendix M. Its allocation is set to (TRK,(3,3),RLSE), which is sufficient to hold about 2,100 Header Records. If you anticipate receiving more than this number of records, you can add 700 requests additional capacity for each (1,1) that you add to the SPACE allocation. For example, you would leave room for 1,400 additional requests (for a total of 3,500) by setting the allocation to (TRK,(5,5),RLSE).

Edit this JCL stream in the same way as you did in Section G and press PF3 to exit the ISPF editor. You will then be presented with a screen similar to the one shown in Figure VI-5. Make your selections on this screen and press the return key to execute the functions specified and return to the main menu.

In this section you will create the JCL stream used to execute program SRTS31, the Participant Status Report generator. This program permits you to get a report and/or file detailing the current level of participation for each institution. Since the System will reject records which are addressed to an institution that cannot electronically accept the data, you can use the output from this program to limit transmission of response records to only those institutions that are in full production mode.

From the System's main menu, type a 10 on the COMMAND line, a g on the line in thelower right-hand corner labeled Job Stream (G, E, or S) ==>, and press the return key. You will be presented with a screen similar to the one shown in Figure VI-15. Fill in Output Type with the standard File, Printer report, or Both options. Then fill in Participant Type with F (FASTER participants; i.e., Florida public school districts, community colleges, and universities), N (non-FASTER institutions; i.e., non-FASTER participants in the SPEEDE/ExPRESS national electronic transcript system), or B (for both), and press the return key. You will now be presented with a screen similar to the one shown in Figure VI-14. The usual parameters may be entered: Job Class, Job Time, Output Dataset Name, etc. The default value of 10 seconds should be sufficient to process all participants.

You will be presented with a screen similar to the one shown in Figure VI-4. This time you will be editing a file named DSNPRFX.PARTSTAT.FROM.SYSJCL, where DSNPRFX is your default dataset name prefix. This file will contain a JCL stream similar to that shown on pages 33 through 36 of Appendix M. There are the same three sets of lines that you will edit in the same way as you edited the JCL streams in the sections above.

Edit this JCL stream in the same way as you edited the System's other JCL streams. Then press PF3 to exit the ISPF editor. You will then be presented with a screen similar to the one shown in Figure VI-5. Make your selections on this screen and press the return key to execute the functions specified and return to the main menu.

In this section you will create the JCL stream used to execute program SRTS42, the Contacts List Report generator. This program creates a report and/or file containing names, addresses, and phone numbers of key FASTER personnel at each institution. This data is maintained by individuals at each institution using the on-line screens provided for that purpose (see Chapter XI Section E).

From the System's main menu, type an 11 on the COMMAND line, a g on the line in the lower right-hand corner labeled Job Stream (G, E, or S) ==>, and press the return key. You will be presented with a screen similar to the one shown in Figure VI-15. Fill in Output Type with the standard File, Printer report, or Both options, and Participant Type with FASTER, Non-FASTER, or Both options, and press the return key. You will now be presented with a screen similar to the one shown in Figure VI-14. The usual parameters may be entered: Job Class, Job Time, Output Dataset Name, etc. The default value of 10 seconds should be sufficient to process all contacts.

You will be presented with a screen similar to the one shown in Figure VI-4. This time you will be editing a file named DSNPRFX.CNTCLIST.FROM.SYSJCL, where DSNPRFX is your default dataset name prefix. This file will contain a JCL stream similar to that shown on pages 37 through 40 of Appendix M.

Edit this JCL stream in the same way as you edited the System's other JCL streams. Then press PF3 to exit the ISPF editor. You will then be presented with a screen similar to the one shown in Figure VI-5. Make your selections on this screen and press the return key to execute the functions specified and return to the main menu. Once you have completed this section you will have assembled the complete set of JCL streams necessary to execute the System's programs. You will then be ready to proceed with the next phase of the user initiation procedure, local testing.

When you receive your logon ID, FIRN staff will identify your institution to the System as a participant and set your initial participation status to "Local Testing." This permits you to begin working with the System, but informs other users (through the Participant Status Display, described in Chapter XI Section C) that you are not yet ready to exchange records. There are a number of tasks you will need to complete before you can enter the parallel testing phase.

Once you have created and/or downloaded the JCL streams used to execute the programs of the System, your next step should be to download some of the programs themselves (Chapter XII details this process). RJE institutions will need to download programs SRTS05 and SRTS06, to preprocess and postprocess their records. Many institutions will want to download the four report writing programs:

Every institution should download copies of programs SRTS01 and SRTS03. These are the programs that edit your requests and responses, respectively, before posting them in your addressees' mailboxes. The data base access portions of the programs have been removed, so you can use them locally as edit programs.

Local Testing begins with the local development of the programs and procedures necessary to permit an institution to take student records and transcripts from its local files and rewrite them according to the System's formats. Until you have accomplished this task, the bulk of your work still lies ahead. You will still be able to use the interactive features of the System described in Chapter XI to make basic contact with other institutions, but this really isn't a truly electronic exchange of student records. An electronic transcript is one that is taken directly from the automated records of one institution and passed through the System to another institution, where automated procedures use the electronic transcript to update the second institution's files. To produce an electronic transcript, you must be able to generate student records in the System's formats from your local data files.

When you have developed the necessary software you should then use it to create a set of test requests and responses. These should list your institution as both sender and addressee. This way, you will be able to put requests in your own mailbox and pick them up. Then you can send the responses and pick those up, too. You will also be able to use the Aging Reports to track the entire process.

Before actually sending out any requests, you should first run your test records through your copies of the System's edit programs. This will permit you to gauge the validity of your test records within the friendly confines of your own data center. This way, misunderstandings concerning the formats and their edits can be cleared up before you begin experimenting with the data communications' elements of the System.

At this or any other point in working with the System, if you have any questions, please feel free to contact FIRN. The FIRNMAIL user-ids are designed to facilitate this process, so use them as much as you can.

Once you're confident your test records can pass the System's edits, you will be ready to test the JCL streams you created during User Initiation. Send and pick up your requests and responses. Familiarize yourself with the System's reports and other output. Be especially sure to use the Outgoing Aging Report!

When you have successfully sent and received student records using the System, you will be ready to take the next step. Use the Participant Status Display (as described in the Chapter XI Section C) to change your status to "Parallel Testing." Then use this same facility to determine which of the institutions with whom you normally exchange records is farthest along in the record transfer process. Contact that institution using FIRNMAIL and arrange a test transmission. Then begin to incorporate the use of the System with your normal record processing procedures.