Financial Accounting System

Current Process

Jobstream requests are originated by the FAS Control Unit staff in General Accounting. Requests for JAMDAY series jobs are filled out on a nine page paper request form and sent by courier daily to I.S. Staging.

The following types of information are contained in a FAS Daily request:

• System Interface Parameters (i.e., PAS, Student, Budget)
  • Interface on/off switch
  • Control dates and run numbers
  • Run types, i.e., extract, resubmit, backout

  The parameter arguments are assigned to WFL variables. With the exception of the interface on/off switch, which is a WFL variable used to control the flow of execution within the jobstream, all parameters are passed directly to the interface programs via the WFL syntax "RUN pgmname (argument list)".

• FAS process control parameter
  • Control dates - current/previous process dates
  • Run numbers - sequential beginning with 001 each biennium
  • Accounting month
  • Switches - 1st/last run of month/biennium
  • Report requests

  This information is entered as one long string via an input datacard to a program, which edits and writes it out as a disk file.

• Input file run numbers and tape serialno's (where applicable)
  • Run numbers are entered in designated column ranges within a program's input data card. This is a process control mechanisim which matches the run number in the programs control card against the run number in the first record of the input file.
  • Tape serialno's are entered as WFL file attribute data in the corresponding global file declaration area.

• Report printcopies for variable copy reports. These parameters are entered by replacing a placeholder token within WFL "printcopies=AMrpt.no.copies" statements with the actual requested number of copies as a numeric literal. These values cannot be passed to the printcopies statement by assigning them as arguments to an integer variable.

• Microfiche copies for variable fiche copy reports. This information is recorded by staging on a paper fiche form sent to the microfiche vendor.

Problems with the current system

• Errors can be introduced at either end of the process. Job requests may be filled out incorrectly by the FAS Accounting Control Unit, or transcribed incorrectly when re-entered into the jobstream by Staging.

• Process parameters are not edited until the job actually runs. If entered incorrectly the job will abort in the middle of the night. Time is wasted contacting the appropriate production support person. Once contacted they must verify and re-edit the incorrect data and arrange for correct restart of the job.

• Input tape serialno's are not verified until run time. When the serialno's are incorrect and do not match the tape title, the job has to be killed and manually edited.

• An inordinate amount of time must be spent by staging setting up our jobs. Stagers must be knowledgable about the system in order to catch job request errors.

Overview of Proposed System

An automated parameter entry and scheduler system will reduce manual editing and entry of job and program parameters by staging. Parameters will be entered through input screens and entered directly into an application database where they will be harvested by individual programs.

Jobs which utilize a process control parameter to pass control data to jobstream programs, such as the JAMDAY series, monthly jobstreams and annual jobstreams, will use the control parameter program to harvest parameter arguments from the database and will pass these arguments to the jobstream programs via the process control parameter.

The application database will have the potential to store:

• Job schedules and execution sequence by date
• Advance scheduling
• Schedule templates
• Schedule, job, and program dependencies
• Call back information
• Report request, report copies, microfiche information and report routing.
• Program input file data
• Input file statistics
• Job and program statistics

Nightly schedule information will be emailed as well as printed at both local and remote printer locations convenient to all responsible parties.

The system will allow for a programmatic interface to the new Production Scheduler through the Portfile process when feasible.

Potential benefits of the proposed system.

• Full editing of process parameters when entered and as a result, reduced likelihood of error.
• The ability to verify input tapes for our JAMDAY jobs prior to the nightly run.
• We will be able to set up an entire month's or more schedule in advance.
• The FAS Control Unit will directly control the number of report copies produced. New jobstream versions will no longer have to be turned over every time the number of report copies changes.
• Additional print control capabilities will be possible.
• Each team can control it's own callback information.
• Input file and job statistics will not have to be manually compiled on a daily basis.
• Last but not least, reduced reliance on stagers and staging.

Initially only JAMDAY jobs will be addressed.

The following features will be included in the first phase:

• Entry screens will be provided for:
  • PAS/FAS interface arguments (multiple screens needed),
  • BGT/FAS interface arguments,
  • FAS process control data,
  • Report Requests/Report Copies/Microfiche Copies,
  • File input parameters.

• Process parameters will be fully edited against control data when entered

• All process control data, except input file data, will be harvested by AM10000 (control parameter update program). Interface on/off switches, interface parameter arguments, and on request report copies will be passed to the job's programs via the control parameter.

• Input file data will be harvested by AM11000 (Reformat) from the Program-Files data set.

• Job requests will be printed remotely for staging, operations, and FAS control unit review.

• All concerned parties will be notified when a schedule is submitted.

• Program Modification/Specification List

• Add additional functionality and extend parameter entry to the JAMPAY1 jobstream.

• Automatic summation of input file record counts for JAMDAY1 (Reformat).

• Automatic recording of completion status and process time/resource utilization for key programs which form the basis of an automatic restart capability.

• Automatic jobstream restart for JAMDAY jobs through a combination of dataset entries in the Program-Req dataset, the Jobstream-Req dataset.

• Extend request capabilities to Monthly jobs.

• Add schedule in advance capabilities.

Beyond:

• Add portfile interface to Production scheduler.

Functions/Screens

Job Request - Mock JAMDAY1 request form

System Administration- Building the System

1. Add personnel information which will be referenced by the Jobstream Master and Names-Jobs-Assoc datasets to the Valid-Names-Mstr dataset.

2. Add jobstream name, contact names, etc., to the Jobstream_Master dataset.

3. Add jobstream programs (minimumly, those requiring parameter input) to Program_Master dataset.
   (e.g., AM10000, AM11000 are required for JAMDAY jobs)

4. Add default report information to Pgm_Report_Master.
   (for JAMDAY jobs all on request jobs would be entered)

5. Add job/name associations to identify valid job requestors to the Names-Jobs-Assoc dataset.

6. Add jobname groupings to Process_Groups dataset as needed.

7. Add Events to be referred to in the dependency datasets to the Event-Master dataset.

8. Add default job dependencies to Job_Depends_Master.

9. Add default program dependencies, if any, to Pgm_Depends_Master

Scheduling

1. Schedule Data

2. Job Data

3. Program Data

4. Schedule Submission

5. Advance Scheduling

Other Functions

• Schedule Inquiries

• Schedule Flowcharts on-line

Possible Batch Processes

• A job to run everyday at 2pm to check that a schedule has been submitted.

• A job to run every afternoon which would verify the input tape numbers against the tapelib database. (eliminate input tapes not created on the A-Series, Physics ISDs and Academic Computer Center ISDs, and Hospital JV's should all be converted to Fastrans. Eliminate tape stacking for Stores and GRS.

  The same job would check for the presence absence of the correct iteration of input disk files.