The table below shows major 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. |
Comments
0 comments
Please sign in to leave a comment.