DASD Billing › Accumulate JCL for Non-VSAM Data Sets › ACCUMULATE Command

ACCUMULATE Command

The ACCMULATE command is used to accumulate the billing charges for the data sets on each DASD volume.

The ACCUMULATE command syntax is:

ACCUMULATE DATE=,MODE=,BYPASSNEW,ADDMISSING,BEGIN=,BWEEK=,BMONTH,
BMEMBER=,SIMULATE

DATE=

A date other than the current date can be substituted for the current date. This allows users to run billing as if it had been run on a different date. The date can be in any accepted CA Disk format.

Note: Data sets with a creation date greater than this date will be bypassed.

MODE=

Two different techniques of billing are supported. They are selected through the MODE= parameter. When MODE=IMMEDIATE is specified, occupancy days are calculated each day a data set is found during the ACCUMULATE process; that is, if a data set is seen today, it will be billed for the day.

• When MODE=ELAPSED is specified, occupancy days are calculated based on the number of days the data set has existed since the last ACCUMULATE process.
• The primary difference between these two modes is that IMMEDIATE calculates occupancy days immediately, as soon as a data set is found on a volume, while ELAPSED requires that the data set exist across ACCUMULATE runs on two different days before charges will be accumulated.

BYPASSNEW

Valid only if MODE=IMMEDIATE is specified, the BYPASSNEW parameter indicates that if a data set's creation date is the same as the current date, no occupancy days are to be accumulated for it. The purpose of this command is to provide a way to avoid billing for transient data sets (those that are on the volume less than one day).

ADDMISSING

Valid only when MODE=IMMEDIATE is specified, the ADDMISSING parameter indicates that processing is to calculate occupancy days for all of the days the data set existed since the Accumulate processing was previously run.

• If Accumulate processing has not previously processed a data set in this billing cycle and the ADDMISSING parameter is specified, occupancy days will be determined by the date of the beginning of the billing cycle or the create date of the data set, whichever is later.
• If not specified, only one occupancy day is calculated each day the accumulate is run.

BEGIN=

This date is used to determine the beginning date of the billing cycle. No data sets will be billed for occupancy days before this date. The date can be in any accepted CA Disk format. (See BWEEK=,BMONTH, and BMEMBER= parameters also)

BWEEK=weekday

For users implementing a weekly billing cycle, the BWEEK= parameter is an alternative to the BEGIN= parameter for setting the begin date of the billing cycle. Specify the name of a day in the week, and the beginning of the billing cycle will automatically be set each week to the date corresponding to the specified weekday name; for example, BWEEK=MONDAY.

BMONTH

For users implementing a monthly billing cycle, the BMONTH parameter is an alternative to the BEGIN= parameter for setting the begin date of the billing cycle. When BMONTH is specified, the beginning of the billing cycle will automatically be set each month to the date corresponding to the first day of the month.

BMEMBER=

This parameter is an alternative to the BEGIN= parameter for setting the begin date of the billing cycle. The BMEMBER= specifies a member name in the parmlib that contains begin dates of billing cycles. When BMEMBER= is specified CA Disk scans the specified member name to determine the begin date of the active billing cycle.

The entries must be in an accepted CA Disk format. Sample entries in the parmlib member:

01/01/95

04/01/95

07/01/95

10/01/95

01/01/96

To determine the BEGIN date to use, CA Disk scans the member entries searching for the highest date that is equal to or prior to the current date. For example, using the previous entries, if the date of the accumulate run is 02/15/95, the Begin date used would be 01/01/95.

To use this parameter, first create a new member in the parmlib data set with the dates corresponding to your billing cycle begin dates. Then specify the member name in the BMEMBER= parameter.

SIMULATE

The presence of this parameter will cause the processing to take place, but no billing records will actually be updated.