Enabling Auditing and Versioning in SCLM
Auditing and Versioning are enabled in the SCLM project definition. The SCLM project administrator determines which groups and types within the project will have versions. By default, no versions are stored. To enable versioning, the project administrator uses the following SCLM macros in the project definition:
FLMCNTRL
The following parameters are used to define versioning:
VERCOUNT - the number of versions to keep for each member in the version partitioned data set. If you specify 0, all versions are kept.
VERPDS - the name of the partitioned data set to contain the versions of the members. SCLM allows the use of variables when specifying the name. Because you will want to allocate a separate version partitioned data set for each group, using the @@FLMGRP variable is convenient.
VERS - the name of the primary auditing and versioning control data set.
VERS2 - the name of the secondary auditing and versioning control data set. This is optional. Use it if you want to keep a backup copy of the SCLM auditing information.
Here is an example of the FLMCNTRL macro, in a project where 5 versions are kept:
FLMCNTRL ACCT=SHELLY.ACCOUNT.FILE, C VERS=SHELLY.VERSION.FILE, C VERPDS=SHELLY.VERSION.PDS, C VERCOUNT=5
FLMALTC
The following parameters are used to override the FLMCNTRL versioning controls for particular groups:
VERPDS - the name of the partitioned data set to contain the versions of the members. Using alternate controls with the FLMALTC macro can allow you to specify a separate version partitioned data set for each group, if you did not use the @@FLMGRP variable on the VERPDS parameter of the FLMCNTRL macro.
VERS - the name of the primary audit control data set.
VERS2 - the name of the secondary audit control data set. Again, this is optional, and only to be used if you want to keep a backup copy of the SCLM auditing information.
Here is an example of the FLMALTC macro overriding the FLMCNTRL values for the PROD level of the hierarchy for the PAYROLL project:
PRDCNTL FLMALTC ACCT=PAYROLL.PROD.ACCOUNT, * PROD ACCOUNTING C ACCT2=PAYROLL.PROD.ACCOUNT2, * PROD ACCOUNTING 2 C VERS=PAYROLL.PROD.AUDIT, * PROD AUDIT FILE C VERS2=PAYROLL.PROD.AUDIT2, * PROD AUDIT FILE 2 C VERPDS=@@FLMDSN.VERSION * VERSION PDS NAME
This alternate control is associated with a particular group by using the ALTC keyword of the FLMGROUP macro, like this:
PROD FLMGROUP AC=(D),KEY=Y,ALTC=PRDCNTL EMER FLMGROUP AC=(E),KEY=Y,PROMOTE=PROD,ALTC=PRDCNTL
In this case, alternate controls apply to both the production group (PROD) and the emergency fix group (EMER).
FLMATVER
The following parameters are used to enable versioning for whatever groups and types are necessary:
GROUP - the name of the group for which version data is to be maintained.
TYPE - the name of the type for which version data is to be maintained.
VERSION - specify YES to enable versioning, or omit the VERSION parameter or specify NO to enable auditing without versioning.
VERCOUNT - specify a number of versions to override the default VERCOUNT on the FLMCNTRL macro.
SEQNUM - specify STANDARD (or STD) to ignore standard sequence number differences when creating versions. Specify COBOL to ignore COBOL sequence number differences when creating versions.
This example of the FLMATVER macro shows how to save versions for group RELEASE and type SOURCE:
FLMATVER GROUP=RELEASE, C TYPE=SOURCE, C SEQNUM=STD, C VERCOUNT=2, C VERSION=YES
In this example, the VERSION keyword is YES, so versioning is turned on.for group TEST and type SOURCE. The SEQNUM parameter is set to STD to avoid saving versions when the only changes are to the standard sequence numbers. The VERCOUNT parameter is set to 2, which overrides the VERCOUNT parameter which is set to 5 on the FLMCNTRL macro.
The FLMATVER macro statements are processed in the order given. Once the audit and version values are set, they will not be reset. If you want to audit all types that are changed in the PROD group, but only version the SOURCE modules in PROD, you might set your FLMATVER macro like this:
FLMATVER GROUP=PROD,TYPE=SOURCE,VERSION=YES FLMATVER GROUP=PROD,TYPE=*,VERSION=NO
Managing Versions
Version data sets can take up a lot of space. Unless your space is unlimited, you will have to control how many versions are kept on your system. Here are some ideas you might use.
1. Use the VERCOUNT parameter of the FLMCNTRL and FLMATVER macros to limit the number of versions that are kept. If you choose to keep 3 versions of a member, when you change the member a fourth time, the first version is overwritten with the new information, so only the most recent 3 versions are kept.
2. Do not use versioning on your development libraries. Because development libraries tend to change frequently, versioning would cause lots of traffic in the versioning partitioned data sets. Also, there are usually many more libraries in the development groups than there are at other levels, so eliminating them produces a big savings.
3. The D (delete) command on the SCLM - Version Selection panel allows you to delete versions (and audit records) you no longer need.
4. Two versioning services, VERINFO and VERDEL, can be used to automate the version maintenance process. For example, you can write an exec or program to use the VERINFO service to get the information for all version (and audit) records before a certain date. Then the VERDEL service can delete them. For an example of how to use the VERINFO and VERDEL services, SCLM provides two members, FLMSVERI and FLMSVERD, in the ISPF sample library ('ISP.SISPSAMP').