FLORIDA DEPARTMENT OF EDUCATION
OFFICE OF APPLICATION DEVELOPMENT AND SUPPORT (OADS)
Effective: December 15, 2013
Revised:
Instructions for Using FASTER to Submit Transcripts to Bright Futures
1.0 Pre-transmission
Checklist
2.0 Preparing Bright Futures Transcripts
4.0 FASTER Jobs Exceeding Their Time Limits
5.0 FASTER Jobs Exceeding Their Disk Space Limits
6.0 Overloading the FASTER/Bright Futures Disk Packs
7.0Reducing the Impact of Network Transmission Problems
9.0 Problems with Transcript Errors
10.0 Printing
Useful Error Diagnostics
11.0 Contacting
Applications Support Staff for FASTER Problem Resolution
12.0 List
of Common Error Messages
13.0 JCL
Errors
14.0 Exceeding
Time Limit
15.0 Running
Out of Space on a File Allocation
16.0 Lack
of Space on the FASTER/Bright Futures Disk Packs
17.0 FASTER
System Maintenance Problems
18.0 System
Contention Problems
19.0 Edit
Errors (Transcript Content Problems)
1.0 Pre-transmission Checklist
1.
Download the latest version of transcript editing
program SRTS03 and use it to edit a sample of your Bright Futures transcripts
so you can resolve as many edit problems as possible before submitting your
transcripts. See section 9.0, below.
2.
If your Bright Futures transmission took more than
2 hours of "clock time" last year, you might want to consider
breaking your transmission up into two or more parts to reduce your exposure to
data transmission and other errors. See sections 4.0 through 7.0, below.
3.
Remove any JOB statement parameters in the JCL you
use to post transcripts to the FASTER system that reduce the amount of
diagnostic information printed with this job (to speed error resolution if
something goes wrong). See section 10.0, below.
4.
Adjust the TIME parameter(s) in the JCL you use to
post transcripts to the FASTER system, based on the number of Bright Futures
transcripts you are sending. See section 4.0, below.
5.
Adjust the SPACE parameters in the JCL you use to
post transcripts to the FASTER system, based on the number of Bright Futures
transcripts you are sending. See section 5.0, below.
6.
If at all possible, post major transmissions to
FASTER during Northwest Regional Data Center’s (NWRDC) reduced cost processing
hours and add the appropriate job class parameter to the JOB statement on the
JCL you use to post the transmissions.
This can save the Department of Education significant processing charges
at NWRDC. The actual transmission of the
transcript file can still be done during the day (since only minor charges are
involved). Only the submission of the
JCL that posts the transcripts to FASTER needs to be done after hours (please
see section 3.0, below).
2.0 Preparing Bright Futures Transcripts
The Bright Futures Transcript Evaluation System
(the System) receives student transcripts from
The system processes student transcripts in two
evaluation cycles (Early or Summer) and, within each
cycle, in two modes of operation: Practice and Production. Transcripts are evaluated the evening of the
day they are submitted (or resubmitted) for seniors, and weekly for
underclassmen.
The principle
difference between Early and Summer Evaluations is that the Early Evaluation
makes use of the courses that the student has not yet completed. The same grade
point average criteria are used in both evaluations. In the Early Evaluation,
up to 1.0 credit in each subject area (English, Mathematics, Social Sciences,
etc.) can come from courses in progress (except for evaluations of the
International Baccalaureate and Advanced International Certificate in Education
curricula, in which courses in progress are not used). Courses in progress can
be annual courses that are still in progress or semester courses that
are scheduled for the student's second term of the academic year. Courses in
progress are only used when a student has no available required completed
coursework in determining whether or not the student has sufficient credits to
qualify for an award. Courses in progress play no part in the grade point
average calculations.
The other major
difference between Early and Summer Evaluations is that the Early Evaluation
uses test score results from the tests taken on or before January 31st
of the student's year of graduation. The Summer Evaluation uses test score
results from the tests taken through June 30th of the student's year
of the graduation. Students who improve their test scores between January 31st
and June 30th may well benefit from a Summer Evaluation of their
transcripts.
The Early and
Summer Semester Evaluation cycles each has its own Practice and Production
Systems.
Transcripts are evaluated the evening of the
day they are first submitted to the Production System. They are editable in the
Production System for 10 calendar days, giving the districts and high schools
the opportunity to review and make additional modifications. At the end of
those 10 days, students will be notified, of the evaluation results. Additional
changes can be made only after the school requests that the record be
"unlocked" by Bright Futures staff.
Students can be evaluated in either or both
evaluation cycles. A student who is found ineligible in the Early
Evaluation can enter the Summer Evaluation and be found eligible for a
scholarship. Or, a student found eligible for a lesser reward in the Early
Evaluation can improve his standing in the last term and be evaluated again in
the Summer Evaluation cycle to qualify for a higher award. The results of the
Summer Evaluation can only improve a student's scholarship eligibility. If the
student's Summer Evaluation results qualify the student for a lesser award--or
no award at all--the student would still retain the scholarship earned in
the Early Evaluation unless the student fails to earn a standard
2.1
FASTER Transcript Addresses - District 95 Processing
For both early and summer evaluations,
transcripts must be addressed to FASTER address 95. To identify the year and
evaluation cycle, use the addressed high school field on the FASTER header
record formatted YYSP.
YYSP - Bright Futures Practice or Production,
Early or Summer Evaluation
YY -
Two-byte graduation year (e.g., 09 = the student graduated during the
2008-2009 academic year)
S -
7 = 7th semester
- 8 = 8th semester
P -
0 = Practice
- 1 =
Production
Directions for using the district 95
addressing scheme can be found at Web site http://www.floridastudentfinancialaid.org/faster in the online FASTER User Manual, Appendix H. Select
the "Header" entry in the left sidebar, and scroll down to
"Addressed Institution."
Note that you specify a graduation year in
the addressed high school field. This allows you to submit early practice
transcripts for freshmen, sophomores and juniors and have them evaluated
according to the eligibility criteria that will be in effect in the student's
year of graduation.
Both the FASTER Interdistrict
Formats (I00 through I08) and the FASTER Secondary-to-Postsecondary Formats
(S00 through S08) can be used when preparing student transcripts. As long
as all necessary evaluation information is provided, either set of formats can
be used (though the two types of formats cannot be intermingled within a single
transcript).
FASTER system edits keep transcripts lacking
certain basic information from ever being posted to the Bright Futures
mailbox. The edit report from program SRTS03 lets school districts know
immediately if a transcript submitted to the Bright Futures Scholarship Award
System does not contain enough information (or contains invalid information).
The school district can then complete or correct the transcript and re-submit
it via FASTER.
2.2
Transcript Submission Rules
In preparing transcripts for submission to
the Bright Futures System, please bear in mind the following rules:
NWRDC charges
reduced rates on nights and (especially) weekends to promote the leveling of
the load on its central processors. Jobs
run from 9pm through 5am Mondays through Thursdays run at a reduced rate equal
to 60% of the standard rate. Weekend
jobs (run 9pm Friday through 2am Monday) are given an even greater price break,
running at only 25% of the standard rate.
There are, then,
very good reasons to conduct FASTER transmissions on nights and weekends. Some 80% of school district FASTER
transmissions are sent to Bright Futures, and the bulk of these transmissions
occur during the three annual transmissions in support of the high school
planning and advisement systems. These
occur at the start of the school year (after class assignments are made), in
the middle of the school year (after semester 1 grades have been posted), and
at the end of the school year (after final grades are posted). If school districts would run only these
transmissions during NWRDC’s reduced cost hours, the
lion’s share of potential cost reduction could be achieved, and without making
any other adjustments to the school districts’ FASTER processing schedules.
In addition, not
all FASTER functions need to be conducted during off-hours to achieve the bulk
of the savings. The most expensive
FASTER process is the editing and posting of transcripts to the system. We estimate that
two-thirds or more of FASTERS school district costs are generated here. Thus, school districts can achieve the
maximum savings for the least work and disruption by running their big transmissions during NWRDC’s reduced rate hours.
3.1 Posting FASTER Transcripts During
NWRDC Reduced Rate Hours
The posting of
FASTER transcripts is a three-step process.
First the transcripts must be sent from the school district to NWRDC
(typically, using Internet FTP). Once
this is complete, an NWRDC batch job is submitted to the mainframe’s internal reader. This batch job runs program SRTS03, editing
and posting the transcripts. The final
step, after this batch job has finished, is to retrieve and review the Edit
Report generated by program SRTS03.
As stated back in
section 1.0, the transmission of transcripts from school districts to NWRDC can
be conducted during the day during normal processing hours. Also, the submission
of the batch job to the NWRDC internal reader can be conducted as soon as the
transcript transmission is complete, the same as with normal FASTER
transmissions. The one difference is
that a specific job class parameter is used to instruct the internal reader to
delay running the job until reduced rate hours begin. The following is an example of the inclusion
of a reduced rate job class parameter at the start of a transcript posting job:
//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 RESPONSES *//**************************************************************
// EXEC IKJBATCH
//NWRISPF.SYSTSPRT
DD DUMMY
DELETE 'FN.DXnn.RESPONSE.ONTO.SYSERRS'
DELETE 'FN.DXnn.RESPONSE.ONTO.EDITRPT'
//SRTS03 EXEC PGM=IKJEFT01,DYNAMNBR=20
//STEPLIB DD
DSN=FRN.DISTRICT.LINKLIB,DCB=BLKSIZE=32760,DISP=SHR
//$ORTPARM DD *
INCORE=OFF
/*
//RSPFILE DD DSN=FN.DXnn.RESPONSE.ONTO.SYSTEM,DISP=SHR
//EDITRPT DD DSN=FN.DXnn.RESPONSE.ONTO.EDITRPT,
// DISP=(NEW,CATLG),UNIT=SYSDA,STORCLAS=SCFNSTD,
// DCB=(RECFM=FB,LRECL=133,BLKSIZE=27930,DSORG=PS),
// SPACE=(CYL,(1,1),RLSE)
//RSPERRS DD DSN=FN.DXnn.RESPONSE.ONTO.SYSERRS,
// DISP=(NEW,CATLG),
// DCB=(RECFM=FB,LRECL=1020,BLKSIZE=27540,DSORG=PS),
// UNIT=SYSDA,STORCLAS=SCFNSTD,
//
SPACE=(CYL,(1,1),RLSE)
(The balance of this JCL stream is not
needed for the purposes of this example.)
The ‘CLASS=C’ parameter on the second line of the
example instructs the NWRDC internal reader to run this job during class C
hours. So, if this
district FTPed transcript file FN.DXnn.RESPONSE.ONTO.SYSTEM to NWRDC between 10am and 11am
on Monday morning, and then FTPed the above batch job
to the NWRDC internal reader, the job would be submitted to the system, but
would remain inactive until 9pm that evening.
It would then execute (since class C hours had begun), and the school
district could review the EDITRPT file the following morning. The overall cost for this job would be 40%
less than it would have been had the job been submitted under some other class
than class C.
Note that the same thing would happen if this
scenario had been acted out on a Friday instead of a Monday. The job would begin execution at 9pm on
Friday, and would achieve the same 40% cost reduction. However, this would not have achieved the
maximum savings. Had the CLASS=G
parameter been used instead of the CLASS=C parameter, the job would still have
begun execution at 9pm on Friday, but a 75% cost reduction would have been
achieved.
CAVEAT: be careful
to use the CLASS=G parameter only on Friday or on a weekend. Like class C, a job submitted with the class
G parameter will not begin until class G hours
start. If a job is
submitted with a class G parameter on, say, a Tuesday, the execution of the job
will be delayed until Friday at 9pm, over 3 days later. It is important to use the right parameter at
the right time.
Remember, too, that the execution of a job during
reduced rate hours does not, by itself, earn a job a reduced rate. The job must also include one of the two
reduced rate job class parameters.
Without the inclusion of one of these parameters, the job will be
charged the standard rate. Thus, a job
submitted on a Saturday without either a CLASS=C or a CLASS=G parameter will be
charged at the standard rate, regardless of the fact that it is executing on a
weekend.
There is another, even more important point to
consider when using reduced rate job classes.
As outlined, above, a job with a reduced rate class will have its
execution delayed until the start of NWRDC’s next
reduced rate hours. During this delay,
users must remember not to destroy the data this reduced rate job intends to
process.
For example, a school district submits dataset FN.DXnn.RESPONSE.ONTO.SYSTEM between 10am and 11am on
Monday morning and then submits the job to post these transcripts with the job
class parameter set to class C. The
posting job will wait for 9pm to come around before it starts executing. While it is waiting, the school district must
take care not to FTP a second set of transcripts to dataset FN.DXnn.RESPONSE.ONTO.SYSTEM. That would result in the second file
overwriting the first. Worse, the school
district would also have submitted a job to post this second set of
transcripts. That job would run as soon
as it was submitted and post the second set of transcripts (the first set
having been overwritten and lost). When
the class C job begins executing at 9pm, it would post this second set of
transcripts again. The net result would be
that the second set of transcripts would get posted twice, and the first set
not at all.
Therefore, for these major transmissions, it will
probably be better for school districts to use a different dataset name than
the one they normally use for FASTER transmissions. For example, the school district could use
dataset FN.DXnn.BULK.ONTO.SYSTEM instead of FN.DXnn.RESPONSE.ONTO.SYSTEM. In this way, school districts can avoid
stepping on their own toes (so to speak).
Actually, there are ways to transmit to the same
file name in a way to add data to a dataset rather than replace it. For our purposes here, though, it will be
simpler just to use a different dataset name for these larger transmissions.
3.2 Savings
Realized
We first requested that FASTER users make more use
of reduced rate job classes in May of 2008.
During the first 9 months of Fiscal Year 2008-2009, an increasing number
of FASTER users did just that. During
this 9 month period, the total cost savings realized from FASTER users running
jobs during reduced rate hours amounted to $3,601.00. During the same period the previous year,
that savings only amounted to $388.20. A
net savings of over $3,400 was achieved.
We still, though, have a long way to go. In no month did the proportion of user jobs
being run in reduced rate classes exceed 18%.
If all FASTER users ran their bulk transcript posting jobs in reduced
rate classes, that percentage could be tripled.
In these times of tight budgets, all users should do their best to make
use of reduced rate job classes. Any
school district needing help with this process should contact the Student Data
Communications Support Section (Applications Support) of the Office of
Applications Support (see the “FASTER Contact Information” link on the FASTER
Web site http://www.floridastudentfinancialaid.org/faster in the online
FASTER).
In the past, some school districts submitted so
many records to the Bright Futures System at one time that the program (SRTS03)
posting transcripts to the Bright Futures System's FASTER postbox exceeded the
time limit those school districts specified in the JCL (Job Control
Language) they used to send and post the transcripts. This problem
occurs because school districts rarely send more than a handful of transcripts
during normal FASTER processing. This problem has occurred, in the past,
among large school districts sending bulk transmissions of high school
transcripts to colleges and universities at the end of the school year.
Since time limit parameters are normally set to handle the transmission of only
ten or twenty transcripts, these bulk transmissions result in transmission jobs
failing when their time limits are exceeded (unless MIS staff adjusted their
time limit parameters prior to job submission). The larger volumes of
Bright Futures transmissions only made these problems more common.
To prevent these problems, school district MIS
staff must make sure the JCL they use has a sufficiently large TIME parameter
to accommodate the number of transcripts they are sending. Program SRTS03
posts transcripts at the rate of about 35 per CPU-second. This rate is based on an even mix of
transcripts (freshmen through seniors) with an average size of 53 records per
transcript. If the average number of
records in your transcripts is larger, they will take proportionately longer to
process. Thus, if your transcripts
average twice as long as the above mix (that is, 106 records per transcript),
you will only be able to process about 17 per second.
Dividing the number of transcripts that are being
sent by the appropriate rate, above, yields a safe approximation of the TIME
needed to post that number of transcripts. For example, if a school
district is sending 5,000 transcripts averaging about 53 records in length, its
transmission job is going to require about 143 CPU-seconds (or 2 minutes and 23
seconds) of processing time. Rounding this up to the nearest minute, the
school district would then set the TIME parameter to TIME=(3).
Note: this TIME parameter must be adjusted wherever it appears
in the JCL stream (it will be found on all JOB statements and may also be found
on EXEC statements).
Sometimes, school district
MIS staff will not know the exact number of transcripts being sent, but will,
instead, know the number of 1,020-byte records in the transmission file.
To approximate the number of transcripts in such a file,
divide the number of records by 53 (the average number of records in Bright
Futures transcripts evenly distributed among freshmen through seniors).
For example, a transmission file containing 106,000 records (of 1,020
bytes, each) will contain about 2,000 transcripts. The number of
transcripts derived from this calculation can then be used to estimate the
transmission job's TIME parameter, as shown above.
Note: the average number of 1,020-byte records per
transcript varies considerably from district to district. After rounding
a TIME parameter up to the nearest minute, it is a good idea to add another
minute to this number, as a safeguard against local fluctuations in the number
of records per transcript.
5.0 FASTER Jobs Exceeding Their Disk Space Limits
This is another volume processing problem.
Transcript files can become so large that the data files used to receive and
(in some cases) sort them run out of room. As with the time limit
problem, file space allocations must be recalculated before making Bright
Futures transmissions, and JCL must be updated accordingly.
To optimize available space, the first thing that
must be checked is the BLKSIZE parameter associated with file FN.DXnn.RESPONSE.ONTO.SYSTEM (where nn is the school district number). This must
be set to 27540, the optimum blocking factor for the disk packs at
Northwest Regional Data Center (NWRDC). Using this blocking factor, 54
records (of 1,020 bytes each) can be stored on a single disk TRACK.
To calculate the SPACE parameter for file FN.DXnn.RESPONSE.ONTO.SYSTEM, divide the number of
1,020-byte records in the transmission file by 54. If you only know the number of transcripts in
your file, multiply that number by 53 (see the discussion is section 4.0,
above) to approximate the number of 1,020-byte records. After dividing by
54, the result is the number of TRACKS in the transmission file. Divide
this number by 15 and round up to get the number of CYLINDERS needed.
Finally, divide the number of CYLINDERS just calculated by 8 and round up to
the nearest whole number (add 1 if the number of CYLINDERS was evenly divisible
by 8). This gives both the primary and secondary SPACE allocation parameters
(nnn). Using this number, set the SPACE
parameter for file FN.DXnn.RESPONSE.ONTO.SYSTEM
to SPACE=(CYL,(nnn,nnn),RLSE).
There are also four "sort-work" files in
the job that posts transcripts to the FASTER system (SORTWK01, SORTWK02,
SORTWK03, and SORTKW04). Their SPACE parameters will be the same as for
file FN.DXnn.RESPONSE.ONTO.SYSTEM, which you
just calculated: SPACE=(CYL,(nnn,nnn),RLSE).
6.0
Overloading the FASTER/Bright Futures Disk Packs
The FASTER and Bright Futures Systems together have
eighty (80) 3390 tri-packs at NWRDC (about 144 gigabytes). Disk space
should, therefore, not pose a problem . To make
sure that this remains the case, these guidelines should be followed:
7.0 Reducing the
Impact of Network Transmission Problems
Some school districts lost a considerable amount of
time when a network transmission error of one kind or another caused a lengthy
transmission to fail. When an 8-hour transmission fails in the 7th hour,
an entire day is lost. This is very significant as the deadline approaches.
While there's not much a school district can do to
control random network problems, it is possible to limit their impact.
The best way to deal with this issue (as in the disk pack space problem, above)
is to reduce the size of the files that are sent by breaking a large
transmission up into several, smaller parts. By doing so, a lot less time
is lost when a network glitch ruins a transmission.
Note: It is good practice to maintain a copy of the
file or files that you send for a few days after making a transmission. If you keep
such a backup and then have to retransmit, you don't have to recreate the file
from your source data. This can be a considerable time saver.
“Timing is everything,” and this old saw is
applicable to the Bright Futures evaluation process. Ideally, a school district would want to
transmit their records to Bright Futures and have evaluations conducted
immediately. Unfortunately, cost
considerations do not permit this type of procedure. Instead of on demand processing, Bright
Futures evaluations are conducted on a nightly schedule.
On Mondays through Thursdays, the nightly Bright
Futures process begins at 11:00pm. This
timing is to give school districts the opportunity to submit bulk transmissions
to execute during NWRDC’s reduced rate hours (class C,;see section 3.0, above), which
begin at 9:00pm. This 2-hour window
should leave enough time for school districts to post their transcripts (which
they have FTPed to NWRDC earlier in the day) to the
Bright Futures FASTER mailbox.
During the day, therefore, school districts can FTP
their transcript files to NWRDC, and then FTP the JCL to post the transcripts
in class C. That JCL will wait in class
C until 9:00pm and then begin posting the transcripts to the Bright Futures
mailbox in FASTER. At 11:00pm, the
Bright Futures nightly run kicks off, picking up these transcripts (and any
transcripts posted by other school districts during the day) and running them
through the evaluation program. The next
morning when the school guidance counselors come in, the evaluation results
will be ready for viewing through the Bright Futures web system.
Additionally, any new student Florida Financial Aid
Applications (without which a transcript cannot be submitted to Production) get
loaded to the system at the start of the nightly run. Thus,any
applications filled out by students through 6:00pm that day are available for
matching with both existing transcripts and those newly loaded with the nightly
run.
The same kind of procedure operates on the
weekend. However, to give school
districts the opportunity to load larger files, the “Friday” run does not begin
executing until 10:00am on Saturday morning.
That is the only evaluation conducted on the weekend, making a total of
five evaluations per week.
Note: In another cost reduction move, the
transcripts of underclassmen (freshmen, sophomores, and juniors) are only
evaluated on the weekend run.
Transcripts for seniors (and students from prior years’ senior classes
who are undergoing special re-evaluations) are evaluated in both weekday and
weekend runs. In this way, nightly
evaluations are still conducted for students who are on the point of receiving
Bright Futures awards, while less time-critical evaluations are conducted on
the weekends to achieve the 75% class G savings.
9.0 Problems with
Transcript Errors
Your school district's MIS staff can avoid having
transcripts rejected by running your transcripts against the school district
copy of the edit program (SRTS03) before sending these Bright Futures
transcripts to the DOE. In this way, your MIS staff can reduce the number of
unpleasant surprises when submitting Bright Futures transcripts with a deadline
approaching.
School district MIS staff still, though, must
monitor their FASTER processing closely to ensure that their data is arriving
as intended. Check your error reports to determine whether any of the
records need to be corrected and re-sent. Running the Outgoing Aging
Report daily lets you know exactly when your records have been picked up.
It also helps the FASTER system archive out old records that have been
completely processed (improving system performance and freeing up disk space
see section 6.0, above).
In addition to monitoring your edit error reports,
be sure to pay attention to ‘B’ type request records that Bright Futures sends
back to you. These will occur after a
transcript successfully posts to FASTER but is later rejected during the
process of loading the transcript into the Bright Futures database. Your school district will receive its edit
error reports immediately after posting or attempting to post transcripts to
FASTER. The ‘B’ type request records,
though, are only generated during the next Bright Futures evaluation cycle
(typically, the following evening).
Therefore, be sure to check for incoming request records the day after
you post records to Bright Futures, since that will usually be when you will
receive notice of this type of rejection.
As mentioned in section 2.0, above, see Appendix D of the online FASTER
User Manual for an explanation of these problem codes.
10.0 Printing Useful Error Diagnostics
To reduce the volume of paper received from NWRDC
in the form of system logs, FASTER users can use a parameter in the JOB
statements of the JCL they submit to tell the system not to print any
system logs. This is fine for normal operations. When a problem does
occur, however, this often leaves the user with no diagnostic information with
which to diagnose the problem (this information is in the system logs). In such
a case, the transmission has to be rerun (after adjusting the system log
printing parameters) to even find out what has gone wrong.
To avoid this problem, when preparing the JCL to
submit Bright Futures transcripts, examine each JOB statement in the JCL.
If the JOB statement has the following parameter
MSGLEVEL=(0,0),
on either the line containing the JOB statement, or on the line immediately following the JOB statement, take out this parameter. This will permit the normal printing of system logs and diagnostic information. For example, if the JOB statement looks like:
//FNDX01S JOB
(FNDX01),'ALACHUA',MSGLEVEL=(0,0),
// REGION=4096K,MSGCLASS=A,TIME=(,40),CLASS=A
you should change it to:
//FNDX01S JOB
(FNDX01),'ALACHUA',
// REGION=4096K,MSGCLASS=A,TIME=(,40),CLASS=A
so that diagnostic messages
can be printed. Or, if the JOB statement
looks like:
//FNDX13S JOB
(FNDX13),'DADE',TIME=(5,30),MSGLEVEL=(0,0)
you should change it to:
//FNDX13S JOB
(FNDX13),'DADE',TIME=(5,30)
to let the diagnostic information print. The
purpose of listing the two
above examples was to illustrate how a two-line JOB statement, and then
a one-line
JOB statement would be modified. Remember:
the final line of a JOB statement
cannot end with a comma.
Once the Bright Futures transmissions are complete,
you are free to add the MSGLEVEL parameter back in to your JCL stream.
Given the higher likelihood of some form of error during Bright Futures
processing (due to the sheer volume of transmissions, system-wide), it is safer
to get all your diagnostic information the first time you run a job: if the
job works, you only get a few extra sheets of unneeded paper; on the other
hand, if the job fails, all the diagnostic information is available for
immediate reference. Having this information available helps Applications
Support staff resolve problems more rapidly if you have to call them.
11.0 Contacting Applications Support Staff for FASTER Problem
Resolution
Despite your best efforts, problems in submitting
the Bright Futures transcripts may occur. The quicker the problem is
diagnosed, the quicker it can be corrected, and the transcripts resubmitted to
the Bright Futures System. The following discussion lists some of the
more common errors FASTER users encounter and provides suggestions on what to
do about them. In all cases, you should contact
Applications Support staff at the numbers listed on the “FASTER Contact
Information” link on the FASTER Web site http://www.floridastudentfinancialaid.org/faster in the online FASTER User Manual, Appendix H. Select
the "Header" entry in the left sidebar, and scroll down to
"Addressed Institution."
It is important to
contact an Applications Support staff member because, while your job may not
have run to completion, your actual file transmission may have worked.
Applications Support staff can help you restart the job without the need to
send the file again. Since file transmission will probably be the most
time-consuming part of this procedure, you will probably save valuable time by
calling Applications Support.
12.0 List of Common Error Messages
As with the previous portion of this document, this
discussion will begin with a list of the common errors you might encounter,
with directions to the sections that describe the problem in detail.
A. ABEND=SB37 see section 15.0, below.
B. ABEND=SD37 see section 15.0, below.
C. ABEND=SE37 see section 15.0, below.
D. ABEND=S322: see section 14.0, below.
E. BEND SYSTEM=322: see section 14.0, below.
F. ALLOCATION FAILED FOR ALL VOLUMES: see section
16.0, below.
G. COND CODE 0000 (for job step SRTS03): see
section 19.0, below.
H. COND CODE 1000 (for job step SRTS03): you had
no edit errors.
I. JCL ERROR: see section 13.0, below.
J. SQLCODE = -904: see section 17.0, below.
K. SQLCODE = -911: see section 18.0, below.
L. SQLCODE = -913: see section 18.0, below.
M. SYSTEM COMPLETION CODE=B37: see section 15.0,
below.
N. SYSTEM COMPLETION CODE=D37: see section 15.0,
below.
O. SYSTEM COMPLETION CODE=E37: see section 15.0,
below.
If your job fails and you get very cryptic
information including the phrase "JCL ERROR," you have a JCL
error. These commonly occur when a typing error is made. Review
your JCL closely (look for such things as extra commas or commas that have been
mistakenly typed in place of periods). The best way to definitively
locate a JCL error is to look at a complete system log. In this case, it is
especially important that your JOB statement had the "MSGLEVEL=(0,0)" statement removed before it was
submitted. See section 10.0, above, for a discussion of how to receive
proper error diagnostics.
When the time limit is exceeded, you may get some
edit report output, with phrases such as "ABEND=S322" or "ABEND
SYSTEM=322" in the diagnostics. This means you ran out of time
before the job successfully completed. Check the time limit computations
(see section 4.0, above) as well as the number of records (individual1020-byte
records, not just transcripts) you are actually sending. If you can't find
where you've made a mistake, call Applications Support. This is one instance in which
you probably will not have to retransmit the records.
15.0 Running Out of Space on a File Allocation
When this happens, your job will fail, and you will
find phrases like "ABEND=SD37" or "SYSTEM COMPLETION
CODE=D37" or "ABEND=SB37" or "SYSTEM COMPLETION
CODE=B37" (basically, anything having a "37" among its error
codes) in the diagnostics. Recheck the SPACE computations (see section
5.0, above). If you can't find the problem, call Applications
Support. You may or may not have to retransmit
the transcripts (depending on which file was involved in the SPACE problem).
16.0 Lack of Space on the FASTER/Bright Futures Disk Packs
If you find the phrase "ALLOCATION FAILED FOR
ALL VOLUMES" in your diagnostics listing, this is an indication that the
FASTER/Bright Futures disk packs have been temporarily overloaded.
Contact Applications Support immediately so they can resolve the problem.
They will probably have to take steps to remove old files before they tell you
to resume processing. This is one case where you might be able to start
processing again immediately if you break your transmission file up into
smaller pieces.
17.0 FASTER System Maintenance Problems
If your job fails and you find the phrase
"SQLCODE = -904" in the diagnostics, this indicates that a FASTER
system resource was unavailable. You will see this code if a problem has
occurred with one of Applications Support's FASTER data base maintenance routines
(this error will usually occur on a Monday morning). Thus, if you get
this error on a Monday, contact Applications Support immediately: this problem
will affect all FASTER users.
This is also the error message you would receive if
the FASTER system itself runs out of room on the FASTER/Bright Futures disk
packs (this should not occur, given the steps Applications Support has
taken to acquire additional disk space). If this is the case, however,
Applications Support staff should be contacted immediately since this problem
will affect the entire system.
Finally, this is the error that will occur if
you run any FASTER jobs during FASTER system maintenance on Sunday
evenings. If this is the case, rerun the job and, thereafter, do not
submit a FASTER job on a Sunday evening!
18.0 System Contention Problems
If the job fails and you find the phrase "SQLCODE = -911" or the phrase "SQLCODE = -913" in the diagnostics, this is an indication that a data base "deadlock" has occurred and was not automatically resolved by the system. This can occur if too many FASTER users are trying to do the same thing at the same time (though this is very uncommon). It can also occur if Applications Support staff have to make a special maintenance run during daytime hours. Contact the Applications Support staff. This is likely a case in which you will not have to retransmit your transcripts.
19.0 Edit Errors (Transcript Content Problems)
If the job runs to completion but, upon review of
the edit report, you find that some of the transcripts were rejected and not
transmitted to the Bright Futures System, you should use the edit report to
identify the rejected transcripts, correct them, and resubmit them to the
Bright Futures System. These transcripts were rejected because they contained
errors or omissions critical to the Bright Futures transcript evaluation
procedures.
You should share the fact that FASTER has rejected
a transcript with the school that sent the transcript. We often get calls
from guidance counselors who tell us that they have sent a transcript, but that
it is not showing up on their evaluation reports. They ask us where the
transcript is and in those cases where it was FASTER that rejected the
transcript, we are unable to help them. In such a case, we only know that
someone has attempted to send a transcript but has had it
rejected. We are then forced to refer the school back to its district MIS
staff to learn the reason for the rejection (which is only carried on the Edit
Report). If you share the Edit Report with your schools when rejections
occur, you can speed their error resolution process (by taking us out of
the loop).
Finally: when in doubt, call one of the Applications Support numbers in section 11.0, above. The earlier in the processing period you call, the better (especially if you call before everyone else starts sending in their transcripts).