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 P 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 Netview File Transfer Program (FTP) to transmit your requests and responses to and from NWRDC. Netview FTP is a VTAM batch application in which jobs at two data centers establish 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, Netview FTP provides a facility for restarting the session between the two jobs so that they are able to pick up where they left off.

This manual is not designed as an instructional text in how to use Netview FTP. The JCL streams you will 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. However, for those who wish to learn more about how to transfer files between data centers, Appendix E should prove instructive.

The JCL streams created by the System submit a single job for execution at NWRDC, which includes steps to handle the transmission of data to or from your site as well as the posting or extraction of data to or from the database. In this way, all execution is performed at NWRDC, allowing that no local initiators are occupied - other than the normal resident execution of your Netview FTP.

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 VII-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. 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 VII-2. Eleven parameters are presented:

Node Name
Remote ID
Transfer Type
Remote Netview 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 using Netview FTP, your Transfer Type will be NVM. Under Netview FTP, the remote Netview logical unit (LU) will be the same whether the job is a send request or a receive request. The next three parameters, site receiving LU, NWRDC sending LU and NWRDC receiving LU are not required. The NWRDC local LU is a constant value known by the system and is the same whether the Netview job is a send request or a receive request. 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). The next two parameters, FTP Checkpoint Restart DSN and your FTP Load Library Name, are needed for MVS FTP/V2 only and should be left blank. The last parameter, FTP Checkpoint Restart VCAT, is applicable to DOS/VSE sites only and should also 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, 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 VII-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 (and so 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 VII-3. This screen has multiple parameters, dealing with your local settings:

Job Class
Job Time
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. A Job Time of 10 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.

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, 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 VII-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 VII-4 displays a window which, at this time, is looking into the first 19 lines of the JCL stream.

Pages 2 through 5 of Appendix P 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 three sets of lines that you must edit. These are labeled with plus signs (++) in the first 2 characters. They are grouped according to the steps this JCL stream will execute:

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 replacing the parameter PROGRAMMER NAME with your name. Initially, the line would look like this:

++JC.1++//FNDX03SD JOB (FNDX03,10,10,2),'PROGRAMMER NAME',MSGLEVEL=(0,0),

After editing to change PROGRAMMER 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 P-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 P-3) 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 step (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 may be found on page P-2 and is labeled with the parameter RFILEID = 'DSNPRFX.REQUESTS.ONTO.SYSTEM' (where DSNPRFX is your default dataset name prefix). Adjust the space by adjusting its primary space (RSPCPRIM) and secondary space (RSPCSEC) parameters. You will also need to adjust the size of the four SORTWK datasets that appear on page P-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 VII-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 chose 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 VII-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 at least 91 transcripts (for 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 as 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 VII-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 6 through 9 of Appendix P 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

three 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 RFILEID 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 P-8, 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 step (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 NWRDC job for the step that receives the response records you are sending. Ten seconds is sufficient to process more than 150,000 response records (as with 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 VII-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 VII-7. This screen has four parameter fields:

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 VII-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 VII-8. The following parameters (dealing with settings for your local MVS site) may be entered:

Job Class
Job Time
Output Dataset Name
Output Dataset Type
Output Dataset Space Allocation, Primary
Output Dataset Space Allocation, Secondary

Set Job Class according to your local standards. Job Time is the time required for the job to receive request records at your local site, and will probably not exceed ten seconds.

Output Dataset Name 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 VII-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 10 through 12 of Appendix P. This time, there are two sets of lines that you will edit in the same way as the JCL streams in Sections B and C. These two sets correspond to the following steps:

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 near the top of page 11 of Appendix P. 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 P-11:

//PARAM DD *
CURRENT

These statements were generated by the System because "current" requests were selected from Figure VII-7. Also note in the comments section starting at the bottom of page 10 of Appendix P 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 P, 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 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 VII-5. Make your selections on this screen in the same way 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 press the return key. You will be presented with a screen that looks similar to the one shown in Figure VII-9. This screen has five parameter fields you can fill in:

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

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.

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 P, 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 VII-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 VII-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, needed to process a greater volume of responses in a single execution of program SRTS04.

After pressing the return key, you will be presented with a screen similar to that shown in Figure VII-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 13 through 18 of Appendix P. 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 at the bottom of page 13 of Appendix P 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 (say, 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 VII-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 (say, 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 VII-7 and VII-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 VII-7 and VII-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 at the top of pages P-11 and P-14, 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 as to how this can be done).

Note that retransmission will be necessary if a retrieval job (either requests or responses) terminates due to insufficient time or space allocation. Such a situation might occur if an unexpectedly large number of requests or responses were waiting for you in your mailbox. Say that room had been provided for 200 transcripts, but 500 were in your mailbox. The job would terminate during the 201st response, and 200 of the responses would be marked delivered on the data base. The output file of transcripts would be incomplete, with a partial transcript, possibly, at the end. To recover from this situation, you would do the following:

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 VII-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 VII-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 VII-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 19 through 21 of Appendix P. There are two 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 20 of

Appendix P. 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 VII-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 shown in Figure VII-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 mmddyyyy.

Fill in these parameters and press the return key. You will now be presented with a screen similar to the one shown in Figure VII-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 VII-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 22 through 24 of Appendix P. There you will find the same two 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 on page 23 of Appendix P.

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

In this section you will create the JCL stream used to execute program SRTS31, the Participant Status Report generator. With this program, you will be able 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 transmi

From the System's main menu, type a 10 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 VII-15. Fill in Output Type with the standard File, Printer report, or Both. 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), options and press the return key. You will now be presented with a screen similar to the one shown in Figure VII-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 then be presented with a screen similar to the one shown in Figure VII-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 25 through 27 of Appendix P. There are the same two 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 VII-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 D).

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 VII-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 VII-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 then be presented with a screen similar to the one shown in Figure VII-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 28 through 30 of Appendix P. There are also the same two sets of lines to edit as occurred in the JCL streams in the sections above.

Once you have edited 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 VII-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, however, 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 communication 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.