Differences Between ACR/Summary and ACR/Detail

ACR/Summary

ACR/Detail

Used to process STATIC files

Used to process dynamic files

History file is a relative record database

History file is a keyed sequenced database

Jobs are referenced in the history file by JOB-ID and CYCLE-ID

Keys and cycles are stored in the database; You do not reference history by JOB-ID in ACR/Detail

Customer mainly have one history database in their production environment

Due to the key-structure, customers often have one history database per application

Access Modes are important for efficient processing. By appropriately specifying the access mode, definitions will be applied to only the records of importance (instead of definitions being applied to every record)

Definitions are applied to every record in the file regardless of access mode.

A valid cycle number is mandatory in order to run a job

Most customers run with our default of cycle of 00000001. Run numbers are not used in ACR/Detail (the run number is always 000). In general, cycle options are much more extensive in ACR/Summary.

Stores and maintains histories for jobs that run multiple times in the same cycle (by using run numbers)

Because ACR/Detail does not use run numbers, keys associated with multiple runs within the same cycle are either accumulated or overlayed in the history database (unless a random cycle number is issued and incremented).

Dual history is an option for obtaining a back-up of the history file.

Dual history is not an option. If the customer wants to back-up the history file, they must do so using their site's standard backup procedures.

The control report is the most widely used report

The user report is most effective due to a large number of keys (The control report prints one key per page).

Write-to-console is an option when specifying rule actions

Write-to-console is not an option

Users must code definitions for the Recap Report. These definitions specify which jobs to recap.

The recap report is simply turned on and lists the keys for THIS job and whether they were in or out-of-balance.

Users can verify some basic information about the file they are bringing in using file control balancing

Obtaining file information is not an option in ACR/Detail. More extensive file control balancing would require ACR/File

Jobs can have 100 internal items, history items, calculated items and rules - to obtain more you must use JSQs.

Jobs can have 999 internal items and calculated items

Offers alternate balancing rules; enables different rule sets based on customer's criteria

Alternate balancing rules is not an option

Allows execution from within a COBOL program by means of the program interface.

Program interface is not an option. (Do not confuse ACR/Detail Extraction Program Interface with Program Interface in ACR/Summary - they are not the same thing).

Processing time is not normally an issue

Extraction Program Interface (EPI) will significantly decrease processing times of large files. There are limitations with EPI - be sure to review these before attempting implementation.

You can use job/file modeling to replicate definitions of jobs with similar balancing requirements

Modeling is not available in ACR/Detail.

Offers the ability to enter control values directly into the job definitions via Direct Input. Normally used for testing of rules, etc

Does not offer the ability to enter control values directly into the job definitions via Direct Input.

Offers spool monitor functionality, where a designated spool class is specified for Unitech use only.

Spool monitor is not an option

An embedded key is one definition type used to access the appropriate record needed for extraction. "Floating" keys are allowed.

Selection fields are used to access the appropriate record. "Floating" selects aren't available, multiple selection groups would need to be used.