General Topics

General Accounting/Chargeback Methodology Considerations

1. An effective DB2 accounting methodology must accommodate the unique conditions present with DB2 resource usage reporting, specifically:
1. DB2 resource usage for local Batch, TSO and IMS connections is accounted for in the caller’s program (TCB) execution.
2. DB2 resource usage for "local" CICS connections is not accounted for in the caller’s CICS transaction-level program (TCB) execution, however the resource utilization is accounted for in the CICS online region’s program (TCB) execution (SMF type 30 statistics).
3. Remote (DBAT or Database Access Thread) DB2 resource usage, such as DB2-to-DB2 on behalf of a requesting connection, is not accounted for in the remote connection’s program (TCB) execution.
4. Distributed (Allied) DB2 resource usage, such as client/server workstation request (for example, AS/400, RS/6000, ODBC/SQL-compliant desktop applications like MS Access), is not accounted in any OS/390 MVS-resident address space other for the DSN1DIST DB2 address space.
   
2. Given the above conditions, an effective DB2 accounting methodology requires that DB2 Accounting Trace be activated (with Class 2 CPU time captured) must only charge selected DB2/SMF type 101 usage data from appropriate DB2 subsystems and connection types, identification information found in the DB2 raw SMF data.  To achieve this objective, IBM DB2 data source fields QWHCATYP, QWHCCN, QWHDRQNM and QWHSLOCN must be validated for desired values based on the above objectives; those input data not meeting the criteria must be omitted, otherwise duplicate charging will occur.
   
3. The DB2/SMF Class 2 CPU time which represents time spent in DB2 provides a most accurate DB2 resource CPU usage measurement.  The IBM DB2 data fields QWACAJST and QWACASRB report TCB and SRB time statistics for a thread execution.
   
4. DB2/CICS applications should be implemented with CICS RCT parameters TOKENE=YES and AUTH=USERID (or equivalent configuration in later CICS/TS version), to ensure adequate detail for proper cost allocation and accounting results.
   
5. DB2 resource usage for CICS connections may or may not accurately identify the requesting USERID/LOGONID depending on how the CICS/DB2 application interface has been implemented (AUTH=USERID).  An effective DB2/CICS accounting methodology should consider matching the IBM CICS transaction data fields NETNAME and UOWID with the corresponding fields reported in the DB2/SMF data source to ensure accurate identification for cost allocation.
   
6. An effective CICS billing methodology must take into consideration unique resource usage reporting with IBM’s MRO (Multiple Region Option) where a CICS TOR (Terminal-Owning Region) and AOR (Application-Owning Region), and additional FOR (File-Owning Regions) cause transaction data to contain insufficient USERID information in the AOR and FOR/DOR to accurately identify the resource consumer, if USERID is the identifying attribute for a cost allocation algorithm.  Resource Management software products that collect this CICS transaction measurement data handle this condition differently.  CA’s NeuMICS CICS Analyzer can correlate the TOR derived resource consumer to the AOR/FOR region activity allowing for proper account identification.  Other similar software packages that provide accounting/chargeback interfaces require supplemental processing to ensure accurate identification based on NETNAME and UOWID information.  Confirm with your software vendor as to how this environment is handled to ensure the highest level of data accuracy.
   
7. For proper CICS transaction charging, the CICS system monitor’s transaction detail data must be generated through a monitor installation option.  For CICS CMF, the MNPER=YES parameter must be activated to generate the CMF type 110, subtype 1 record type.  For Candle’s Omegamon/CICS product, the SMF=YES option must be specified to generate the CMF-compatible detail transaction data to SMF type 110.  For Landmark’s TMON/CICS, the detail CICS transaction statistics must be captured to the TMON system logging address space and then processed after each night’s dump/collection processing.
   
8. Consider that the SMF type 30, subtypes 2 and 3 (step interval) records provide a more accurate and timely source for capturing OS/390 MVS address space resource usage statistics as compared to the SMF type 30, subtypes 4 (step termination) or subtype 5 (job termination) data.  A recommended interval for collection address space statistics is between 15 minutes and 1 hour depending on how much detailed SMF data can be accommodated; 15 minutes is a recommended value.  Ideally the SMF and RMF interval values should be the same to permit meaningful correlation analysis between these two data sources, the type 30 subtypes and type 70 series.

CICS Transaction Resource Usage and Chargeback Considerations

MN=ON,
MNPER=ON, 
MNFREQ=hhmmss,

Without the parameter MNPER=ON, the CICS default settings (i.e., MN=OFF) will result in no CMF performance (transaction) data being generated yet some CICS Statistics records which are unique subtype records of the type 110 will be generated.  Additionally, the MNFREQ=hhmmss (hour, minute, second) identifies the time interval frequency for generating CICS region-level "global" or interval statistics, an important measurement for tracking CICS region interval activity, considering tha the absence of interval statistics indicates down-time.  Without specifying MNFREQ, no interval statistics will be generated and a single data record set containing a summary of CICS activity statistics since the region was started will be generated.

With IBM's CICS/CMF monitor, the specific SMF record used for capturing CICS user transaction records is SMF type 110, subtype 1. This CMF performance data populates the MICS CICS Analyzer's CICCSU file.  With Candle's Omegamon product, specifying the Omegamon parameter SMF=YES generates the SMF type 110 "look-alike" data for post-processing by various data analysis reporting tools. With Landmark's TMON/CICS software, you would normally process the TMON/CICS transaction log data for each system/region.

Charging for CPU Time Measurement in OS/390 MVS

First, given that CPU measurements for SRB time can vary based on workload variance and processor load, consider charging only for the TCB portion present in the following sources:

• SMF type 30, subtypes 2 and 3 (interval frequency less than 1 hour), subset of SMF30xxx CPU measurements (CPT+HPT+RCT) all address space types (e.g., batch, TSO, STC, APPC/MVS, OpenEdition/Unix), but one must exclude duplicate resource counting for CICS, IMS and others -- see below),
• SMF type 30, subtype 4 (SMF30ICU or INIT TCB) -- CPU measure not captured in the subtypes 2 and 3,
• SMF type 101 (DB2), but only CICS and remote thread which are not counted in caller's TCB/exec,
• SMF type 110, subtype 1 (CICS transaction),
• IMS log (if used), but must exclude BMPs since they are counted in SMF type 30,
• IDMS/PM SMF (if used), all access types (according to CA tech support),
• other DBMS/Transaction logs (if used and if collected and if not counted in caller's TCB/exec),
• VM/CMS Accounting typed 01 (VTIME) (if used).

You may be challenged on this one because some believe that "if they use the resource, they should be charged for it." The perspective to take here is that two jobs that run the same on two different days should be charged the same amount, right? The overall system configuration and workload tuning considerations will come into play here. That's a windmill that you'll have to joust and be prepared to be guided down the path of charging for SRB resource usage.

If you are going to use a time-oriented measure as opposed to service units, it must be normalized to some base processor type otherwise each CPU upgrade (or even an LP/PP configuration change) would justify a rate change. Once you've committed to a specific set of chargeback rates, customers will expect to see the same rate applied throughout some defined time-period, normally a year. One method to normalize is correlate the SRM coefficient factor (SMF72ADJ or now R723MADJ with WLM) of your processor to the factor for the baseline processor keeping in mind that this is not a scientific method and there are other approaches one may consider.

And, in developing realistic (and justifiable - no SWAG accepted in most industry/government enterprises) rates, there must be consideration for a capture ratio factor with most of the sources, where you should consider comparing the above sources (workload-specific aggregate over a data sample period) to the address space summary for the same time-frame. The premise here is that you don't want one business workload type subsidizing others simply because their CPU resource usage calculation/capture process is less-accurate. You have to assume that your various customers will share with each other information about the service they are getting from the I/S organization which can fuel discussion and sometimes even doubt about equitable service.

Relating various cost pools (e.g., hardware, software licensing, personnel, building/plant) to expected resource (usage) measurement collection will help achieve meaningful chargeback rates, even beyond CPU measurement. Be forewarned, some I/S bean-counters and department executives will expect to see how rates are developed, especially when say their year-end departmental bonus is riding on it. Be prepared to back-up rate derivations with a set of spreadsheet formulas or at least an illustration of the derivation methodology and metric components.

Then take into consideration more fixed costs say for telecommunications and other such facilities that which must already be in place to support an expected number of customers/users, consider a "per-seat" (monthly) rate structure that would likely affect the rates charged for the fee-for-service type resource usage areas like CPU. Also, if particular users "must" have a particular software that's not in the "standard suite", expect to hit them with a period-surcharge for the additional licensing costs and support/maintenance. And, if there's still any loved-ones who simply must have their own LPAR/domain, fixed DASD pool, that's another justification for surcharge.

Each of these considerations will have an impact on the eventual normalized-CPU-hour rate charged since costs are directly linked to rates charged. And this all assumes that a data center is not trying to make a profit!!

MICS

MICS Installation

Q:

Why should I create a separate set of SAS libraries for MICS?

A:

The only real reason to create a separate set of SAS libraries for MICS is a preventive one.  MICS makes use of many SAS Base features, some which are critical to successful MICS operation.  A SAS Base software update has the potential for rendering MICS inoperative, so the MICS developers execute program code that verifies the SAS version, and MICS will fail execution, if the version is not one that has been certified by Computer Associates.

Only in cases where the SAS and MICS Administrators are the same individual would it be considered acceptable to use the production SAS software libraries with the MICS system.  In any other case, there is an inherent risk that the SAS software could be updated to a maintenance level that is not yet certified for MICS.  Check with the MICS Product Support staff before updating SAS to ensure that no additional MICS support is required first.

Q:

What rationale should I use when configuring my production MICS unit data bases?

A:

A popular approach to organizing MICS unit data bases within a MICS complex is to group MICS components and Field-Developed Applications (FDAs) in the same unit data base when their input sources are the same.

For example, one approach is to install all MICS components that receive their input from SMF in a single unit data base.  The rationale is one where all input will be available for the particular unit data base at a specified time and so that unit data base processing can commence when the SMF daily processing is complete.  Issues regarding limiting access to specific personnel and data base size must also be taken into consideration when planning a MICS unit data base configuration.

An alternate approach is to install MICS components based on the data similarities, such as combining all on-line MICS components in a single unit data base.
In some circumstances, one MICS component may be dependent upon another component for critical information, such as the case with the MICS CICS Analyzer feeding CICS Unit-of-Work (UOW) information to the MICS DB2 Analyzer through an intermediate permanent working (detail) file.  When implemented as a CICS Analyzer exit, this SAS file contains key information that relates CICS User ID information to a CICS UOW, which must be referenced in the MICS DB2 Analyzer's DB2 Account Code derivation (DB2ACRT) routine.  In some DB2 installations, the CICS User ID information is critical to properly assigning DB2 resource usage information to the proper user or account.  This support is not included with MICS and must be coded by users that require this level of detail for assigning CICS/DB2 resource usage.

Considering that the SAS Version 6 architecture introduced support for spanned DASD volumes with SAS data libraries, MICS can be configured with unit time-span libraries that span volumes, though Computer Associates does not officially support this approach. Other standard MICS techniques, such as Data Base Split (DBSPLIT), can address the issue of time-span library size in most cases.

Q:

What days and hours make up a typical business week when designing a MICS ZONE configuration?

A:

The sample MICS ZONE member provides a very basic illustration for establishing a business week. Unfortunately, the outer boundaries, specifically MONDAY AM and SATURDAY AM may not be appropriate for the typical data center.

Considering that the production processing for a business day typically starts on the evening shift that follows the business day and continues until the start of the next day, keeping in mind that Saturday is not typically a business day in the United States and many other countries.  Keeping this thought in mind, a MICS ZONE definition that reflects this type of production processing schedule should consider MONDAY AM from midnight until say 8:00 AM as part of the weekend ZONE or shift.  Similarly, the period from SATURDAY at midnight until say 8:00 AM should really be considered as part of the weekly night shift that supports the business week.

These time-periods are easily represented in the MICS ZONE member but they do require additional ZONE definition statements, since the time-periods are not contiguous for the midnight shifts.

MICS Administration

Q:

What MICS jobstream must I run after updating prefix.MICS.PARMS(cccOPS), where ccc identifies a particular MICS Analyzer?

A:

One can use the following general rules for determining what unit-level MICS generation must be performed after updating a prefix.MICS.PARMS(cccOPS) member:

• For an OPTIONS statement change, submit cccPGEN job for the particular MICS Analyzer, and in cases where a DD reference specified in an OPTIONS statement is changed, the corresponding INPUTccc member in prefix.MICS.PARMS must be updated and the DAILY job must be regenerated using the JCLGENU PARMS/CNTL process or by executing the JCLGEND jobstream to regenerate all unit-level data base update jobstreams;

• Also for OPTIONS statement changes involving ORGSYSID/SYSID modifications, deletions or additions, the MICS BASPGEN job must be executed after reviewing/updating the prefix.MICS.PARMS members and optionally the sharedprefix.MICS.PARMS( CPLXSID) member that may contain related parameter definitions,

• For INCRxxxxxxxx statements for the MICS Incremental Update Facility, the jobs cccINCR and cccIUALC must be generated at a minimum using JCLGENU or JCLGEND, and then executed to properly configure a unit data base; depending on chosen options the cccIUGDGS (if "INCRSPLIT TAPE" and/or "INCRDB TAPE" is specified), and SPLITSMF for SMF data source units (if "INCRSPLIT USE" is specified) jobs must also be generated and then executed to perform necessary data set allocations and Generation Data Group (GDG) base definitions;

• For DYNAMWAIT, RESTART, RESTARTCKPT, RESTARTWORK statements for the MICS Internal Step Restart Facility, submit cccPGEN;

• For WORK, MULTWORK, and NOMULT for MICS Daily Update WORK allocation overrides,, submit cccPGEN, then regenerate the DAILY jobstream using JCLGENU (if "INCR YES" is also specified in cccOPS, the member INCRccc must also be executed.

• For options unique to a specific MICS Analyzer such as the CICS Analyzer's MSACCOUNT option, in most cases only the cccPGEN jobstream execution is required.

• For the TRANS and RESP parameter statements that are unique to the MICS Analyzers that process transaction-related data sources, the cccPGEN jobstream execution is required.

• For the TAPEfff parameter statements that control the capture of detail transaction data for certain MICS Analyzers, submit cccPGEN job, and the DAILY job must be regenerated using the JCLGENU PARMS/CNTL process or by executing the JCLGEND jobstream to regenerate all unit-level data base update jobstreams;

Please refer to Chapter 7 of the applicable MICS Analyzer Guide or to Chapter 3 of the MICS PIOM Guide for specific control statement syntax and more detailed instructions.  These documentation references also provide prerequisite SAS system requirements in support of the MICS Internal Restart Step Facility.

Above all, ensure that adequate review, planning, testing and verification is performed before implementing any changes to the production system as to ensure continued operation.

Q:

What MICS jobstream must I run after updating the member prefix.MICS.PARMS(ZONE)?

A:

The MICS administration jobstream prefix.MICS.CNTL(BASPGEN) activates ZONE PARMS member updates.  This member is most typically updated just before year-end for holiday changes.

Any changes to the ZONE member to increase or decrease the number of unique ZONEs may have unanticipated impact on current MICS reporting routines.  For example, adding a new ZONE value to separate PRIME and PEAK-PRIME into two ZONE values may have impact on existing reports that are expected to show only a single line-item for the standard business day.  Other routines that currently subset one or more MICS files selecting the PRIME ZONE would need to be updated to select the PRIME and PEAK-PRIME ZONE values.  In comparison, a MICS administrator may want to reduce the number of unique ZONE values which also could impact existing SAS reporting routines, for example routines that generate a report showing weekend/holiday usage may have a different ZONE value, if changed.

Take care to consider other users of your MICS data when deciding whether or not to make significant configuration changes to an existing production system.

Q:

How can I get MICS to generate JCL members with the proper information for both production as well as administration jobstreams?

A:

The MICS JCL Generation process provides a facility for tailoring MICS-generated JCL members using a combination of user-defined JCL generation parameters and Generation Control Language (GCL) statements.  The USERDEF statements are coded in the JCLDEFC (complex-level) and JCLDEF (unit-level) members and the GCL statements are coded in the USERJCL member of PARMS.  The GCL statements reference the USERDEF parameter values to conditionally generate MVS JCL JOB and JESx statements, based on processing conditions, such as whether the jobstream is a production-type one, like DAILY, WEEKLY, etc., or an administrative-type jobstream, like BASPGEN.

The USERDEF statements are used to substitute alternate JCL values for PROGRAMMER NAME, MVS ACCOUNT, suppress the NOTIFY parameter, and other site-specific conditions.  Special JCL comments, such as Operational Restart instructions can be included with production-type jobs only, as an example.  The GCL statements must be programmed by the MICS Administrator to make the substitutions, where appropriate.

The JCLINFO member in PARMS supplies certain JCL JOB statement values, such as JOB NAME and JOB CLASS. GCL must be used in conjunction with the JCLINFO values for more complex MICS JCL generational processes.

Given that each MICS unit data base can have up 25 or more unique JCL jobstreams generated for production and administration functions, a more automated approach to JCL generation can be implemented to reduce that occasional administrative time.

Q:

How can I avoid "missing data" condition on a MICS audit archive file?

A:

For this discussion, MICS requires that there be sufficient DETAIL (or DAYS) cycles available online when the WEEKLY/WEEK300 process runs to capture the prior week's data but only if the information is contained in cycles 10 through 01, meaning from the past 10 DAILY update cycles. By the way, any observations from the current week are discarded during the WEEK300 archive creation process to help ensure that only prior week data is captured on the new generation. The potential exposure is when there are insufficient DETAIL (or DAYS) cycle retention limits defined in prefix.PARMS(DBMODEL) for any MICS files activated for Audit Archive.

Consider, the CYCLEGEN process and the WEEK300 process will generate NO warning message. The only symptom observed will be when you go to access a particular audit archive file generation and there are one or more days missing, normally that being a Sunday or Monday of the collected week. Also note that more than just the prior week's data will be saved in the new archive generation, up to the maximum of cycle 10. Given this condition, any reporting that uses or crosses multiple audit archive generations must consider that duplicate observation may be found in two consecutive generations and must be removed at reporting time to ensure accuracy.

The amount of missing information captured on an audit archive generation is directly affected by the DBMODEL DETAIL (or DAYS, if DETAIL is inactive) retention limit along with when the WEEKLY job is scheduled for a unit data base. If there are 8 DAILY updates in a period before a WEEKLY update occurs say Sunday night (into Monday AM), the minimum DETAIL (or DAYS) cycle retention limit necessary for a complete Audit Archive generation is 08. But, for example, say the WEEKLY job is run on Monday night (into Tuesday AM) after the 9th DAILY update since the start of the PRIOR week, the cycle retention limit must be 09 to capture a complete prior week of data in cycles 09 through 03, viewing the cycles chronologically. That is why the default setting for most MICS files is 10, those that are set with Audit Archive active in the sp.GENLIB(cccGENIN) member. This condition provides upwards of 10 DAILY cycles before the next WEEKLY cycle.

So, verify that your DBMODEL cycle retention limits are sufficient to handle the maximum number of DAILY update cycles between WEEKLY cycles, if you have AUDIT ARCHIVE activated in prefix.PARMS(JCLDEF). Also, remember that the most recent generation of an audit archive file will NOT have data from the current week; any reporting on the current week will need to be done using the online time-span cycles. Lastly, beware that audit archive files can have duplicate observations across generations because the audit archive creation process captures up to 10 cycles, if available, while only deleting observations from the current week.

Q:

Tip on Using EXECDEF Parms for Testing MICS System Changes

A:

If you have ever wanted to execute a MICS component
DAILY update in your test unit DB (if you have a test DB,
raise your right hand -- that's a good showing!); and,
how about if you only want to supply a subset of reasonably
current input data to expedite the test, say one hour?  Here are a
few methods of accomplishing this objective:

1) Create a data extract file with a data sample for one or more
systems for input to a MICS component (good luck with decoding
some of the input timestamps on non-SMF files),
2) Edit the MICS test unit checkpoint file and create a SELECT
parameter to input a subset of input data from a typical daily
input file generation from production,
3) Edit prefix.USER.SOURCE(#BASEXIT) for the test DB, add a
_USRSEL exit macro after the %INCLUDE statement, and
code your input data subset selection criteria in an _USRSEL
exit as required,
4) Specify the not-well-documented SELECT parameter in
prefix.PARMS(EXECDEF) and specify a date/time range for
input data selection, letting MICS do the subsetting work?

When possible, I typically choose #4.  My reasoning is that
method #1 requires some utility to create and maintain an
extract file (remember you get to decode the non-SMF records),
method #2 requires modifying the checkpoint, possibly having
to prime it with dummy entries just so the
S(ddmmmyy:hh:mm:ss ddmmmyy:hh:mm:ss) parameter, and #3 though
may be the only reasonable approach for some testing, this
method also requires SAS coding.  But method #3, depending
on your testing requirements, only requires that a single
MICS parameter statement being used, as follows:

SELECT ddmmmyy:hh:mm:ss ddmmmyy:hh:mm:ss

By the way, you may also add additional statements to
either exclude or include specific ORGSYSID values, again
without having to use SAS code. Here's an example using
the SELECT and ORGSYSIDS statement to process input (based
on ENDTS value) from 0800-0900 on 28Dec00 and only for input
data from SYSA (add the statements below anywhere in EXECDEF
and no MICS GEN job is required!):

SELECT 28DEC00:08:00:00 28DEC00:09:00:00
ORGSYSIDS SYSA

You can find more information about these "special" processing
parameters in the MICS Planning, Installation, Operations and
Maintenance (PIOM) Guide, Section A.3, titled SPECIAL Database
Execution Definitions.  Yes, these parameters are discussed in
the section on The MICS SPECIAL Database but the parameters are
supported for all types of MICS databases.

This approach will help speed up the DAILY processing for the
MICS components while allowing better productivity, depending
on the configuration change being made.

Q:

Testing a MICS Custom Calendar Change

A:

This approach will ensure that the current calendar member will be invoked based on the MICS unit data base being referenced, even if the 13MONTHYEAR parameter is changed (if it is coded at all.)

Here’s sample code that demonstrates how to test changes to the MICS-computed calendar for the next 180 days:

//jobname JOB ….
//MICS EXEC MICSNDBx <- your unit ID goes here
//SYSIN DD DATA,DLM=ZZ
* We want to see the SAS source code. ;
OPTIONS SOURCE SOURCE2;
* Invoke MICS-maintained member that identifies MICS calendar options.;
%INCLUDE USOURCE($BASMSTR);
* Turn on SOURCE again since $BASMSTR turns it off.;
* ;
* This SAS DATA step generates diagnostic messages to test the ;
* user-defined MICS calendar code and displays the associated ;
* MICS Common Data Element assignments in SASLOG output. ;
DATA _NULL_;
* Use the SAS function TODAY to get the current date. ;
TESTDT=TODAY();
* If you want to start on a particular date, uncomment the next line. ;
* TESTDT = ‘ddmmmyyyy’D;
* Now loop on index variable I to increment the date for ;
* SASLOG printed output diagnostic purpose. ;
DO I=0 TO 180;
* Assign SAS date/time stamp using DHMS function. ;
ENDTS=DHMS(TESTDT+I,0,0,0);
* Compute MICS common elements based on calendar date.;
%YEAR;
%MONTH;
%WEEK;
%DAY;
* Now display the diagnostic messages showing the MICS common ;
* elements. ;
PUT ‘MICS CALENDAR VALUES: ’ ENDDT= DATE. YEAR=
MONTH= DAY= WEEK=;
END;
STOP;
RUN;
ZZ

The sample code above can help MICS Administrators with testing MICS custom calendar changes. The SASLOG output will display diagnostic information to verify expected results -- any missing values should be investigated. A standard MICS calendar (no 13MONTHYEAR parameter is coded in the SITE member) should generate acceptable values unless the sharedprefix.SOURCE($DWMY12) member has been modified.

MICS Accounting and Administration

Q:

What considerations should be made when implementing CPU time accounting for my MVS resources?

A:

LPAR or domain configurations today frequently make use of multiple processors, possibly dedicating one or more processor to a system and/or sharing multiple processors between those systems.  When this configuration is established by a data center, the combination of processors creates a level of performance for a particular configuration.  For example, a system with two dedicated processors, meaning they are not shared between multiple systems, will perform somewhat more efficiently under MVS/ESA and OS/390 than a system that is configured to share its processors with one or more other systems.

This situation can affect accounting practices because a user that runs the same batch jobs on different systems should experience the same cost, assuming that the jobs perform the same function or task on both systems.  If different customers get charged differently for similar resources, someone's going to have to answer why in the data center.

This condition is addressed by what's referred to as charging users for a normalized CPU time measurement. The actual CPU time consumed on a particular system is normalized to a base-configuration (or base-processor), ideally using a reliable measurement to determine the normalization factor.  The data center's accounting software must be able to apply a normalization factor to the actual CPU time measurement to arrive at a normalized CPU time measurement and resulting charge.  A good source for determining the normalization factor is the RMF Service-Units/CPU Time Coefficients which are available in MICS (and MXG).  These values can be used to compute the normalization factor based on the MICS SYSID value, using the RMF Coefficient for the base-processor. The computation is performed by dividing the system's current RMF coefficient by the RMF base-processor coefficient arriving at the normalization factor to use.

Applying these normalization factors against the CPU measurement must be performed at the time of data collection so that the proper normalization factor is used with a given configuration.  Configuration changes or system upgrades may alter this normalization factor, so it is best to make the calculation at data collection time rather than say applying the factor at month-end time during accounting close-out.

When configuring MICS Accounting and Chargeback to define Computation Codes (COMPCODEs) for normalized CPU time charging, it may be useful to define parallel COMPCODEs that have a zero rate and are collected to track the unnormalized CPU time measurement in the MICS Accounting journal files.  This information can prove beneficial when someone wants to know the unnormalized CPU usage as recorded by MICS Accounting in comparison to the normalized CPU time charges.

MICS Accounting and Chargeback provides menu options to control how zero charges are to be handled in the Ledger and Recap files, so you may want to visit MWF option "4;2;3;2" and review the MICS Accounting General Options dialog to set these options according to your collection and reporting needs.

Q:

How can I take advantage of the MICS/SAS formats used with MICS Accounting to display Invoice Category and COMPCODE information in SAS?

A:

MICS Accounting maintains a series of SAS formats that are used, primarily by MICS SAS code, but they are also available for user-developed SAS code.  The following SAS formats can be used in SAS or in MICF for display Accounting-related descriptive information:

Format	Description
$ACTCMPF	Computation Code descriptive text
$ACTCPUF	Computation Code Units of Measure descriptive text
$ACTIVCF	Invoice Category descriptive text
$CC1NAME	Cost Center #1 (COSTCTR1) Name

The following example demonstrates how to use the $CC1NAME format to display the descriptive text for the COSTCTR1 data element:

PROC SUMMARY NWAY MISSING DATA=TABLES.ACTRCP01
                  (KEEP=COSTCTR1 YEAR MONTH RCPCHG);
CLASS COSTCTR1 YEAR MONTH;
VAR RCPCHG;
OUTPUT OUT=RCP SUM=;
RUN;
PROC PRINT U LABEL DATA=RCP;
VAR COSTCTR1 YEAR MONTH RCPCHG;
FORMAT COSTCTR1 $CC1NAME.;
RUN;

Q:

Why should I consider implementing a MICS Accounting External File Unit Data Base?

A:

MICS Accounting provides the ability to collect chargeback information from external sources, such as monthly (or more frequent) charges for data sources not collected by MICS Analyzers or FDAs.  These external charges can be entered on-line, or they can be loaded using batch SAS, if the data volume is too much for manual entry.

A recent enhancement introduced support for collecting these charges in a separate MICS unit data base.  This enhancement reduces the size of the MICS TABLES data set and introduces an Accounting journal and ledger collection process for the external charges, as is performed for standard MICS data sources.  Additional function for MICS Checkpoint validation were added with this enhancement, a much needed function to prevent loading duplicate charges accidentally.

SAS code previously used with external file charges can be used with the new Accounting external file unit, in most cases, reducing the implementation time required for taking advantage of this enhancement.  The additional function for MICS Checkpoint validation makes this feature one that current MICS users should consider converting to, when convenient, especially those sites that have issues with excessive information being retained in the MICS TABLES data set.

MICS Reporting and Analysis

Q:

A:

Example #1:
Using INTNX function and SAS System/Automatic macro variables SYSDATE and SYSTIME to subset input data in a WHERE statement:

//STEP1 EXEC MICSSHR_,   <= SPECIFY YOUR SMF UNIT DB HERE
// OPTIONS=HSWORK        <= USE HIPERSPACE FOR WORK DATASET
//SYSIN DD DATA,DLM=ZZ
%CPLXDEF; /* get complex name from SHRPARMS(CPLXDEF) */
OPTIONS SOURCE SOURCE2 NOCENTER;
DATA JOB;
* use MICS MFILE macro to select multiple cycles of data, ;
* also select the current job suspend file records. ;
SET %MFILE(F=JOB35-01,TS=DETAIL)
        &BATX..BAT_JS01;
* define low/high cutoff range based on current timestamp;
WHERE RDRTS GE INTNX('DTMONTH',"&SYSDATE:&SYSTIME"DT,-1) AND
            RDRTS LT INTNX('DTMONTH',"&SYSDATE:&SYSTIME"DT,-0);
FORMAT RDRDT DATE9.;
RDRDT = DATEPART(RDRTS);
KEEP RDRDT SYSID;
RUN;
PROC SUMMARY NWAY MISSING DATA=JOB;
CLASS SYSID RDRDT;
OUTPUT OUT=JOB ;
RUN;
PROC PRINT U NOOBS LABEL DATA=JOB (RENAME=(_FREQ_=COUNT));
VAR SYSID RDRDT COUNT;
SUM COUNT;
FORMAT COUNT COMMA9.;
LABEL SYSID = 'SYSTEM';
LABEL COUNT = 'JOB COUNT';
LABEL RDRDT = 'SUBMIT DATE';
* use MICS/SAS macro variable from CPLXDEF for complex name;
TITLE1 "&CPXRNAME";
TITLE2 "TOTAL JOBS SUBMITTED BY SYSTEM AND DATE - PREVIOUS MONTH";
RUN;
ZZ

Example #2:
Using MICS-supplied PREVWK macro to subset input data for previous week:

//STEP1 EXEC MICSSHR_,   <= SPECIFY YOUR CICS UNIT DB HERE
// OPTIONS=HSWORK        <= USE HIPERSPACE FOR WORK DATASET
//SYSIN DD DATA,DLM=ZZ
* get week start day value - required for PREVWK macro below ;
%INCLUDE USOURCE($BASMSTR);
%CPLXDEF; /* get complex name from SHRPARMS(CPLXDEF) */
OPTIONS SOURCE SOURCE2 NOCENTER;
DATA CSY;
* use MICS MFILE macro to select multiple cycles of data ;
* increase cycle 10 if job not automatically scheduled ;
SET %MFILE(F=CSY10-01,TS=DAYS);
* subset input data for previous week observations only ;
%PREVWK; /* use MICS-supplied macro for subsetting input */
* combine excessive trans with normal total for grand total ;
CSYTRANS = SUM(CSYTRANS,CSYETRN);
FORMAT ENDDT DATE9.;
ENDDT = DATEPART(ENDTS);
KEEP ENDDT SYSID CICSID CSYTRANS;
RUN;
PROC SUMMARY NWAY MISSING DATA=CSY;
CLASS SYSID CICSID ENDDT;
VAR CSYTRANS;
OUTPUT OUT=CSY SUM= ;
RUN;
PROC PRINT U NOOBS LABEL DATA=CSY;
VAR SYSID CICSID ENDDT CSYTRANS;
SUM CSYTRANS;
FORMAT CSYTRANS COMMA9.;
LABEL ENDDT = 'DATE';
LABEL SYSID = 'SYSTEM';
LABEL CICSID = 'REGION';
LABEL CSYTRANS = 'TOTAL TRANS';
* use MICS/SAS macro variable from CPLXDEF for complex name;\
TITLE1 "&CPXRNAME";
TITLE2 "TOTAL TRANSACTIONS BY SYSTEM/REGION AND DATE - PREVIOUS WEEK";
RUN;
ZZ

SAS

Data Step and Procedure (PROC) Performance

Q:

What are some methods of improving SAS performance when selecting data files?

A:

SAS provides several ways to control processing time by only selecting specific observations or data elements which we will explain.  In some cases, a DATA step is not necessary to select observations prior to performing data manipulation and say printing the information.

For example, the WHERE statement can be specified within a PROC or DATA step execution to limit the observation selection.  The following SAS DATA step demonstrates how the WHERE statement is used in place of the IF/THEN statement to select an observation subset for subsequent processing:

DATA PRINT;
SET DETAIL.BATSPL01;
WHERE SPLCOST GT 0; /* SELECT ONLY DEVICES THAT HAD A CHARGE */
ATTRIB TOTPAGE LABEL='TOTAL PAGES PRINTED'
               FORMAT=COMMA9.;
* Combine PSF and non-PSF pages into TOTPAGE element;
TOTPAGE = SUM(SPLPGE,SPLPPGE);
ATTRIB ENDDT LABEL = 'Date'
             FORMAT=DATE9.;
* Derive Date from Ending Timestamp;
ENDDT = DATEPART(ENDTS);
KEEP SYSID DEVNAME ENDDT TOTPAGE SPLCOST;
RUN;
PROC SUMMARY NWAY MISSING DATA=PRINT;
CLASS SYSID DEVNAME ENDDT;
VAR TOTPAGE SPLCOST;
OUTPUT OUT=PRINT SUM=;
RUN;
PROC PRINT U LABEL ;
VAR SYSID DEVNAME ENDDT TOTPAGE SPLCOST;
SUM TOTPAGE SPLCOST;
TITLE "DAILY MVS PRINT ACTIVITY (PAGE COUNT AND CHARGES)";
RUN;

The KEEP= keyword can also be added to the SET statement to instruct SAS to process only specified data elements from the source files, such as:

SET DETAIL.BATSPL01 (KEEP=SYSID DEVNAME SPLCOST SPLPGE SPLPPGE);

Keep in mind that the KEEP statement does not perform the same function as the KEEP= keyword on the SET statement.  The KEEP statement controls the output file, where the KEEP= keyword on the SET statement controls the data elements from the input file(s) that are read by SAS.

Using SAS output with PC spreadsheet applications

Q:

How can I import SAS report output into Microsoft Excel on my PC?

A:

SAS output from PROC PRINT can be imported into Excel with minimal effort, once the information as been captured to an MVS file and then downloaded to a PC file.  Microsoft Excel provides an intelligent wizard to help with converting the data to spreadsheet columns and rows.

The following checklist should result in a PC file suitable for importing to Excel:

1. In SAS or in MICF, specify the following options to generate one continuous output page, thus omitting page/column headings: OPTIONS PS=MAX LS=MAX;. These options instruct SAS to generate the maximum number of lines for a page, currently 65,535, and the maximum column width for a page, currently 255 characters.  This configuration is ideal for creating spreadsheet-type data from within SAS with minimal programming effort.

2. Use a batch operation, if possible, to generate SASLIST output from a SAS procedure like PROC PRINT.

3. Capture the SASLIST output to a new sequential data set using the appropriate commands and functions of your MVS output viewing production (e.g., PRINT DATASET, PRINT, PRINT CLOSE commands with IBM's SDSF software).

4. Download the data set containing the SAS procedure output to a PC file, preferably one named with the file extension of "TXT", such as a file named RECP2004.TXT.

5. Start the Excel application, click on FILE, then click on OPEN, and then specify "FILES OF TYPE" of Text to list the file created in the previous step.  Double-click the selected file and Excel will initiate the TEXT Wizard processing.

6. Excel allows the user to specify the first record that contains proper column heading information in a LIST box, so specify the row containing the column heading, normally row #1.

7. The wizard asks the user to specify any validation type, the columns either being TEXT-type or GENERAL-type.  The wizard also attempts to distinguish column breaks which can sometimes be incorrect, so double-click or move the column breaks according to the column data format.

8. When complete, the results should be an Excel data file containing the SAS Procedure output. Save the file as an Excel workbook.  This data can be used for charting, detail and summary analysis or to generate an Excel Pivot Table report.

General OS/390 MVS

Sending Desktop EMAIL from OS/390 MVS

Q:

How can generate an EMAIL from an OS/390 MVS-based batch job?

A:

IBM introduced with the ability to send SMTP-based EMAIL from OS/390 MVS (actually TCP/IP) using a SMTP mail server that connects MVS to the Internet or Intranet as configured by an enterprise.  Sites must implement this technique using the SMTPNOTE feature of TCP/IP, and the end-user must setup JCL and related control statements that identify the destination recipient (TO:) and sender (FROM:) as well as any desired instream text or report information.

Once an SMTPNOTE server is configured and started, a TSO user, batch job or other OS/390 task can initiate an EMAIL that is directed to a JES-controlled destination (for example, DEST=SMTPNOTE).

An example of how this facility can be leveraged with accounting and chargeback function is to generate a summary-level report for daily charges, one that is sent directly to the administrator on a daily basis summarizing the prior day's processing, thus avoiding further action unless deemed necessary based on daily statistics.

For more information on this topic, refer to IBM install documentation for TCP/IP for MVS (publication SC31-7136) for more information about implementing the SMTPNOTE feature.

CIMS for MVS Software Implementation

General CIMS/MVS Installation

1. Develop a set of CIMS billing codes that provide adequate detail for all resource usage technologies (e.g., OS/390 MVS Batch, TSO, Open/Edition MVS, CICS and AS/400 Batch, Interactive and System) and consider having a naming convention that permits generic prefix identification of each category of billing codes (e.g., “MVCICxxx” prefix for CICS, “MVDB2xxx” for DB2, “MVBATxxx” for OS/390 MVS Batch, “MVTSOxxx” for TSO, “MVSTCxxx” for Started Tasks, “A4BATxxx” for AS/400 Batch).
   
2. If LPAR/domain identification is desired in summary-level billing and resource usage or cost analysis, consider developing unique CIMS billing code suffix characters to uniquely define systems (e.g., “MVBATA” for MVS Batch on SYSA, “MVTSOA” for MVS TSO on SYSA).
   
3. If shift-level discounts or surcharges are to be applied, or data analysis at the business shift level is desired, consider developing unique CIMS billing codes to define unique periods (e.g., “MVBATAP” for MVS Batch – SYSA – Prime Shift).
   
4. The CIMS 32-character account code definition provides the ability to define a fairly detailed accounting reporting structure, and multiple summary-levels can be generated from the CIMSACCT/CIMSBILL files to accomplish different reporting requirements, as necessary.  One version of the CIMSACCT/CIMSBILL summary file may provide detail down to say an Division, Department and Application level, while a more detailed file structure may provide even more detail down to the USERID level, as required for reporting.
   
5. CIMS sites would benefit from handling any duplicate data processing requirement outside of the CIMS system, meaning that the SMF and system monitors’ data capture processes should be optimized to ensure that no duplicate data capture occurs.  CIMS provides a utility program to remove duplicates but this utility sorts CIMSACCT data into a sequence that attempts to match the first 1024 bytes or so to identify and remove a duplicate CIMS data record.  This approach may not be an effective validation and removal method, especially if the duplicate deletion utility must be executed on a daily basis.  For a CIMS site to be able to generate period-to-date charges, a daily execution is an absolute must to ensure high CIMSACCT/CIMSBILL data accuracy.
   
6. CIMSMULT utility program performs proration functionality based on user-supplied input and output arguments for the entire CIMS account code field.  A wildcard character can be used with the input look-up argument to permit conditional comparison on a subset of the CIMS account code, but the output (prorated) CIMS account code value must be coded in its entirety which may not be effectively addressed in shops that capture large combinations of CIMS account code sub-fields.  Contact the vendor for a recommended approach where it is not possible to code all possible combinations of a prorated CIMS account code.
   
7. For several data sources, CIMS provides a means for accomplishing CPU normalization through various CIMS utility control statements depending on the data source.  In the case of CICS and DB2, the CIMS site cannot code the required parameter to normalize all CICS regions on a given LPAR/domain; the parameter is specified at the CICS region level.  This requirement may not be possible for some CIMS sites.  As an alternative, the CIMS Report Writer may be used to read the CIMS data source usage data files and generate the CIMSACCT charges data file with normalized CPU quantity values.  Contact the vendor for a recommended approach to address this requirement.
   
8. CIMSACCT utility program provides users the ability to input data records (TRANS Control Statement) supplying an 80-column, multiple field format to generate external CIMSACCT data for inclusion in CIMS charging.  Information can be supplied in this TRANS record providing audit information to support the CIMS chargeback data being loaded.  This utility may provide a means of loading external data from other resource usage data sources by generating the TRANS records using a programming language such as the CIMS Report Writer, REXX or SAS.
   
9. CIMS Report Writer provides a high-level programming and report generation language to be used with the CIMS system.   Frequently this utility program is used to address supplemental processing of CIMS input data sources where “out-of-the box” solutions do not provide adequate reports such as a standard report format.
   
10. CIMS Desktop software application provides a PC-based application based on Microsoft Access to import and report on CIMS mainframe and distributed systems/server data sources.  The CIMS Account Code is used to build a series of key data strings for generating reports and for performing ad hoc data analysis.  One recommendation is to setup automated FTP batch jobs or scripts to load CIMS Desktop (DIST) files from the respective hosts to a LAN-based file server for simplified user  access while ensuring that only authorized users have data access to this financial information.  The CIMSBILL utility that generates the DIST file can be setup in multiple iterations to generate different summarization levels to allow for tailored reporting such as having one DIST file configured to analyze CIMS data at the division/department level while generating a separate DIST file format that provides division/application level summary data for application chargeback analysis.
    
11. During the CIMS implementation phase, develop a comprehensive CIMS data file naming convention, one that includes the data source, time‑frame, and CIMS data format type (e.g., CIMS.ALL.MONTHLY.CIMSBILL.DIST for CIMS Desktop monthly combined data source GDG base or CIMS.CIC.DAILY.CIMSACCT for CIMS CICS data source daily CIMS Account data source GDG base).
    
12. CIMS account code conversion processing using the CIMSTABL data table allows for records to be validated either in sorted sequence with each pass of an input data record, or the entire CIMSTABL data table is passed with each input record.  It’s the user’s responsibility to ensure that no duplicates exist and that the data table is properly formatted.  In the case of multiple qualifier search arguments, such as a multi-node DSN, the user must handle how the most granular DSN prefix is to be matched to a CIMSDISK input data record.  The CIMS Report Writer or other suitable data manipulation utility must be used to validate a candidate data table, organize the input data to be in the desired comparison format, and generate a CIMSTABL compatible format.  Two examples are listed below:
    
    Example #1: Properly Ordered CIMSTABL file having the most granular match condition entry listed prior to the more generic entry:
    
    SYS2:CIMS*:*,,SYS CIMS OVHD
    SYS2:*,,SYS OVHD OVHD
    *,,*** **** ****
    
    Example #2: CIMSTABL file sorted in character order resulting in a undesirable match condition of the first record rather than the second entry:
    
    SYS2:*,,SYS OVHD OVHD
    SYS2:CIMS*:*,,SYS CIMS OVHD
    *,,*** **** ****
    
13. CIMSBILL utility provides users the ability to separate a prior period’s data during period-end processing, and a separate step filters current period’s data to a new period-to-date file.  Users are expected to understand that if older data beyond the previous period is processed, the standard CIMSBILL utility control statement DATE SELECTION PREVIOUS processing must be altered to code a low_value and high_value instead of the PREVIOUS parameter to ensure that no historical charges are lost during period-end processing.  The CIMS period split job inputs the current period-to-date file twice, the first time to select prior period’s records building a new period history GDG file and a second time to select the current period’s records building a new period-to-date GDG file for future processing.  This condition applies to monthly, weekly and user-defined business period cycles.
    
14. CIMSACCT code matching process is based on a maximum 8-character field.  This architecture can be augmented by separating a field of greater length into two sub-field strings, such as a 12-character account field.
    
15. CIMS batch processing utilities generate non-zero COND CODE completions and not USER ABEND conditions when an unexpected processing condition such as “no input data” or an unexpected parameter value.  This behavior can cause confusion with data center Operations staff when a failing job must be restarted at a step other than the failing step and recover action is almost always expected to delete an intermediate temporary/permanent data set prior to performing a restart.
    
16. Specifying SHIFT derivation is limited to expected day-of-week being either SATURDAY or SUNDAY, and SHIFT definition is limited to a specific maximum number.  Also, the CIMS site cannot specify a complete business weekend start date/time and end date/time.  Typically a data center’s business week starts 0700 on Monday and runs through early Saturday AM at 0700.  Correspondingly, the weekend begins at 0700 on Saturday morning (after Friday night’s business day’s processing) and runs until 0700.  CIMS expects the SHIFT derivation using standard control statements to start on Saturday and end on Sunday.

CIMS OS/390 MVS Address Space Support

1. CIMS OS/390 MVS address space processing captures and retains MVS JCL account field information from the time a job enters the system until an SMF type 30, subtype 5 (job end) record is encountered.  The CIMSACCT parameter “SUSPENSE DAYS” defines how long CIMS is to retain this account field information from the type that a job starts execution.  This account field information is retained in the CIMS SUSPENSE file, a sequential file created and again used by the CIMSACCT program. 
   
   For long-running started tasks and unique jobs, accurate CIMS account code assignment usually requires some sort of JCL account field or other supplemental information (e.g., USERID, started task name).  Once the “SUSPENSE DAYS” has been exceeded the JCL account field information for a particular job/task is purged from the CIMS SUSPENSE file.  A recommended value for “SUSPENSE DAYS” is 15 days.  Again, this means that MVS account field data will be purged after 15 days from the date a job started execution or when the SMF type 30, subtype 5 is encountered, whichever occurs first.
   
   Consider that it is possible for sites to code JCL account field information on the EXEC ACCT= parameter thus ensuring accurate CIMS account code assignment for all step/interval statistics, regardless of the CIMS SUSPENSE LIMIT parameter value.  The CIMS Lab staff recommends that long-running tasks and jobs have the ACCT= parameter specified to ensure accurate accounting.
   
   As of CIMS V11.2, the CIMSACCT program does not process the MVS account field information present in the SMF type 26 record that was added by IBM with MVS/ESA 4.3 JES2 and all OS/390 OS levels.  This condition presents a unique challenge for charging for JESx output/print activity where there is no job execution statistics recorded, such as a situation where printers are connected to a production OS/390 MVS system and a “test” system not captured in CIMS shares a printer connected to the production system, or an environment where a VM system uses JESx printers attached to a production system.  For these applications, charging based on USERID is recommended.
   
2. CIMS supplies a standard billing code that captures all MVS CPU measurement fields recorded in the SMF type 30, subtypes 2 and 3.  The CPU measurement for Initiator CPU time present only in the SMF type 30, subtype 4 record is captured when CIMS step charging is chosen.  Additional CIMS standard billing codes capture and report traditional CPU components, TCB and SRB time, if desired.  These standard billing codes, however, do not provide unique separation of each OS/390 MVS address space type permitting a site to generate an invoice with say Batch, TSO, Started Task and OpenEdition/MVS separately reported.  Users can define their own billing codes though, as desired, and can generate user-defined resource usage measurements and charges with those billing codes. 
   
3. Charging for JESx-controlled printed output can identify local vs. remote print usage, however the remote print usage identification limits the FORM NUMBER value to six-characters of the CIMS billing code since the billing code is prefixed with the string “R:” within the maximum 8-character CIMS billing code.  Current JESx subsystems permits FORM field up to 8‑characters.  Supplemental processing of the SMF type 6 record allows a site more flexibility in how JESx output/print usage is charged rather than using the CIMS-supplied options for the CIMSBILL program.  A site wishing to separate various print output types, such as impact, laser and microfiche, should consider using the CIMS Report Writher utility to generate the CIMSACCT TRANS records based on the SMF type 6 records and user-developed processing logic addressing required charging logic.

CIMS DB2 Support

1. CIMSDB2 utility program generates a resource usage file based on SMF type 101 input data.  The CIMSDB2 output file does not permit adequate identification of CIMS remote (DBAT) and distributed (allied) resource usage separate from the DB2 local requests.  This identification is important to ensure that duplicate charging is prevented.  Refer to the General Section above for more information about an effective DB2 charging algorithm.
   
2. Consider preprocessing the CIMSDB2 detail transaction file to subset that data to collect and charge for local CICS and all DB2 remote and distributed resource usage connection types.

CIMS CICS Support

1. The CIMSCMFP utility program is used to process IBM standard-format CMF performance (type 110, subtype 1) data for generating CICS transaction resource usage statistics.  This utility program expects the CMF Performance record in a standard IBM-compatible format, though additional clocks/counters and other supplemental software user fields can be appended to the standard record using CICS facilities.
   
2. Supplemental batch process must be developed if an MRO site must correlate TOR USERID information to corresponding AOR/FOR/DOR transaction records based on NETNAME and UOWID.  Refer to the General Discussion above for more detailed information on this topic.  Also, check with the vendor for a recommended approach. 
   
3. Sites running Landmark’s TMON/CICS product should consider using the Landmark-supplied utility for converting TMON/CICS transaction data to an IBM-compatible format for CIMS CICS processing using CIMSCMFP.  CIMS Lab does provide a CIMS Report Writer utility program used to pre-process the TMON/CICS transaction data and convert that data into a CIMSCICS utility compatible format.

CIMS DASD/DFHSM Support

1. The CIMSDISK utility program processes IBM’s DCOLLECT utility output for capturing OS/390 MVS DASD VTOC information.  If a site has implemented DFHSM, DCOLLECT provides support to generate DFHSM migrated and backup record types for archive-managed data.  As of CIMS V11.2, CIMSDISK provides only limited support for the DFHSM data source.  Statistics for ML2 (migration level 2) data archived on tape are not captured in the CIMSDISK output file.  Check with CIMS Lab for current information about CIMS support for ML2 data which is data managed by DFHSM and resides on tape resources.  DCOLLECT does provide accurate reference information such as original data set name along with data storage resource usage statistics such as Bytes Used for an accurate and complete OS/390 MVS DASD/DFHSM data storage billing methodology.
   
   
2. As of CIMS V11.1, the DCOLLECT utility execution must not generate CAPACITY records or these records must be filtered with a data manipulation utility such as DFSORT or SYNCSORT to omit these records.  These records are generated with the DCOLLECT parameter CAPPLANDATA.  This behavior should be validated with the most current CIMS software version or simply ensure that the capacity records are not passed to CIMSDISK.
   
   
3. An effective OS/390 MVS DASD accounting methodology may consider assigning CIMS account code ownership based on either a data set name (or DSN prefix) or a USERID, if contained in a data set name.  To achieve this objective with CIMSDISK, the CIMSDISK batch jobstream may need to process the DCOLLECT data source multiple times, once for assigning CIMS account code based on a data table mapping DSN prefix to an application-based account code, and a second pass of the exception data attempting to assign CIMS account code ownership based on a USERID list mapped to an owning CIMS account code value.
   
4. Due to CIMSDISK performance considerations where a large DSN data table maps a large number of DSN prefix values in excess of 500, it may be necessary to setup a multiple step batch jobstream to process the DCOLLECT in phases such as the first pass processing the DSN prefix (four data set nodes) data table first, then process the exceptions using a DSN prefix (three data set nodes) data table, then process the exceptions using a DSN prefix (two data set nodes) data table, and last processing the exceptions using a DSN prefix (one data set node) and USERID data table. 
   
5. CIMSDISK processes the DCOLLECT “D” records representing a VTOC perspective of data set occupancy.  This record records the SPACE ALLOCATED but not SPACE USED which is recorded in the DCOLLECT VSAM record type.  Sites wishing to charge for SPACE USED can process the DCOLLECT data source using the CIMS Report Writer utility.