From Database Recovery Control (DBRC) in Practice by Peter Armstrong (Third Edition); copyright 1990 BMC Software.

Part 1  |  Part 2  |  Part 3  | Part 4  |  Part 5  |  Part 6

This chapter considers makes recommendations on some of the important parameters you have to set when initializing the RECONs.

INIT.RECON

To convert an empty VSAM KSDS into a RECON, you use the INIT.RECON command, which writes the RECON header records. These records identify the data set and are read whenever a RECON data set is opened. The parameters have the following meaning:

• RECOVCTL
indicates that DBRC is to be used for database Recovery Control only—not recommended. Dies in V6.

• SHARECTL
indicates that, in addition to Recovery Control, full DBRC Share Control is to be provided. SHARECTL is the default and is required for DBCTL.

• NONEW
will only allow a new subsystem to start if two RECONs are available. This option is the default and is strongly recommended. If a RECON I/O error does occur, the spare can be brought into service to restore the situation where new jobs can be run.

• STARTNEW
will allow a subsystem to start as long as there is one RECON available. This would lead to problems if that RECON also went down.

• FORCER
specifies that you wish DBRC to force registration of all databases processed in jobs under DBRC's control, which means that if you run a job with one or more unregistered databases it will abend. This is your ultimate goal. This parameter also means that DBRC will check the data set name of your DBDS against the name registered in RECON and abend if they don’t match.

• NOFORCER
means do not force registration of databases—default. In this case if the data set name does not match, you simply get a warning message—DB not registered. The typical case of this happening is when you have the same DBD names and ddnames for test and production but the data set names are different. You now run a test database against a production RECON by mistake—whoops!! Hence the recommendation to use FORCER.

Warning! The black hole in DBRC is when you run your production database against the test RECONs by mistake. You are very unlikely to be running FORCER on your test RECONs, so you would just get a message warning you that the database is not registered (and a message saying that you were running on the wrong set of RECONs—DFS487W) and the job would continue—you must make sure that you never run production databases against the wrong RECONs.

The DFS487W (and DFS485W, DFS486W) come from a fiendishly clever piece of DBRC code called DBRC Usage Indicator (DUI) checking, which is clever enough to tell if you are turning DBRC on and off, running on different RECONs etc. Unfortunately, it just gives you warning messages.

• CHECKxx
tells DBRC which type of log tape data set name comparisons to use during its JCL verification process. CHECK17 is the default, and is there for historical reasons—remember MVS tape labels? (In all cases, the volume serial number is checked.) Use CHECK44.

• SSID
Enter the name of the most frequently used online subsystem. This will save you having to enter the SSID on many commands during normal operation, since the default will be the one specified here. INIT.RECON

• CATDS|NOCATDS
are mutually exclusive, optional parameters you use to modify the status of whether image copy, change accumulation, and log data sets are catalog managed.

• CATDS
specifies that these data sets are catalog-managed. If the data set is allocated by the catalog and the CATDS option is used, DBRC bypasses volume serial and file sequence verification for the data set. See “DBRC and Data Facility Hierarchical Storage Manager (DFHSM)” on page 62 for an explanation of why this is useful.

Note: In order for CATDS option to be effective, the data set must be cataloged, and volume serial information for the data set must be omitted from the JCL. If the data set is cataloged, CATDS is specified, and volume serial information is included in the JCL, DBRC ignores CATDS and allocates the data set by the JCL. Normal volume serial and file sequence checking occurs.

If the data set is not cataloged, CATDS is not effective, and DBRC allocates the data set by the JCL, with volume serial and file sequence checking.

• NOCATDS
specifies that these data sets, whether cataloged or not, are not to be treated as catalog-managed. DBRC verifies that the volume serial and file sequence numbers appearing in the job file control block are the same as the information recorded in the RECON data set.

• DASDUNIT/TAPEUNIT
specify default UNIT information for tape and DASD. DBRC identifies if a data set is on tape or DASD and stores that information in RECON. It does this for logs, image copy data sets, and change accumulation data sets. Every time you create one of these data sets, DBRC extracts a one-bit flag from MVS that indicates whether the data set is on tape or DASD. It then checks the RECON header record to see what you defined as the default tape and DASD units. So, if you have specified TAPEUNIT(3480), all data sets that are on tape will be stored in RECON with a UNIT of 3480. See “Concatenated Tape and Disk” on page 62 for details of how to use these parameters.

• LOGRET(time_interval)
is an optional parameter you use to specify the retention period for log data sets. The retention period is the minimum amount of time in which a log becomes inactive after it is opened. (It is then eligible to be deleted).

• LISTDL|NOLISTDL
are mutually exclusive, optional parameters you use to specify whether data set names deleted from the RECON (by DELETE.LOG command or by an archive job log compression) are listed in the job output. The setting specified on this command can be overridden by the DELETE.LOG command. There is no way to override the setting for log compression (see “Continuous Operations” on page 58 for more information) during an archive job.

• UPGRADE
is an optional parameter you use to specify that the RECON is to be upgraded for IMS V6. It is required whenever a new V6 level RECON data set must be created for use by the Upgrade utility. This parameter sets a safety switch that makes the new RECON unusable until the Upgrade utility is run. Likewise, the upgrade utility requires that the switch has been set in the new RECON.

Entering Timestamps

Prior to V6, timestamps in RECON are 12 digits in the form

yyydddhhmmsst

V1, 2, 3, and 4 will not run in the year 2000. V5 (with the correct PTFs) will.

This is how you would enter a timestamp in a command:

GENJCL.RECOV DBD(...) DDN(...) RCVTIME(981231014169)

and when you print out the RECONs (or preferably just bits of them as

LIST.RECON tends to kill trees), DBRC will format these for you:
98.123 10:14:16.9

Some people have purchased or written ISPF front-ends to DBRC to enable them to enter commands and the timestamps more easily. I personally think this is a waste of time—my objective is to enter a “native” DBRC command as infrequently as possible. To me, the interface to DBRC should be automated, and if I need to find a timestamp/build a DBRC command on a regular basis, then I buy a product and/or write a GENJCL.USER procedure to extract the information from RECON and build the commands/JCL for me automatically.

Version 6

V6 uses Coordinated Universal Time (UTC—I know the initials are in the wrong order, but this comes from the French). UTC is also commonly referred to as Greenwich Mean Time (GMT—correct order, it’s British!). Actually, they are wrong—GMT and UTC are not the same—the difference is leap seconds. Is this important? I have no idea.

In V6 you can enter timestamps in one of the following formats:

• compressed: yydddhhmmsst [offset]
• punctuated: [yy]yy/ddd/hh/mm/ss/t [offset]

where:

yyyy

ddd

hh

mm

ss

t

/

Offset can be one of the following:

— Omitted. The current TIMEZIN value (see below) will be used.

— A numeric offset in the form hh:mm or hhmm that, when added to UTC, gives local time. hh is a numeric value from 0 to 14. For the compressed format if mm is specified, then hh must also be specified. mm is a value from the set {00, 15, 30, 45}.

hh:mm is valid only between the values -11:45 to +14:45.

hhmm is valid only between the values -1145 to +1445.

— A symbolic time zone label.

The value may have elements truncated on the right, in which case the omitted element's digits are assumed to be zeros.

You may truncate the input at the beginning of any element after ddd; so, yyyy/ddd is acceptable as is yyyy/ddd/hh. Part of an element may not be entered: for example, yyyy/ddd/h is invalid.

The same time stamp value could be entered in the following ways:

942520824457             942520824457-0800
94.252 08:24:45.7 -8      94/252-08.24.45.7 -8:00
94,252 08:24:45.7 PST      94.252/08:24:45.7
94/252-16.24.45.7 UTC       1994 252 16.24.45.7 +0

Note: See also the BMC Software manual Year 2000 and IMS for a description of the timestamp changes between IMS V5 and V6 and how these are stored in IMS log records, RECONs, etc.

The Time History Table (V6 only)

A time history table (THT) is created each time INIT.RECON is issued in IMS V6. The THT in the V6 RECON contains a history of time-zone changes. This is basically a record of when the system time was changed to and from Daylight Savings Time. The THT is used

• in the RECON Upgrade process (PGM=DSPURU00)
• in the RECON Coexistence environment to enable pre V6 DBRC code, with the proper RECON Migration and Coexistence support applied, to convert pre-V6 timestamps to the UTC format

You need the THT to upgrade a V4 or V5 RECON to V6. If you share a V6 RECON with a V5 and V6 system, then you need the THT—this is “coexistence” and you most likely upgraded the V5 RECON to a V6 RECON by following the RECON upgrade procedure. To coexist, you need the RECON Migration and Co-existence APAR (PN89491 or PN89490) applied. With it, DBRC “downgrades” timestamps it reads from the V6 RECON to the form for processing and then “upgrades” the 7-byte form to UTC format using the THT. This timestamp processing affects all DBRC processing (including Database Recovery).

Note: The execution of the V6 INIT.RECON command will create a THT record. You create the THT with the INIT.RECON command in V6. You change it with the CHANGE.RECON THT (or REPTHT) command in V6.

You change the THT whenever you change the system clock and you tell DBRC by issuing the CHANGE.RECON THT command. If you are not coexisting with pre V6 DBRCs and never intend to—i.e., you do not need a “fallback” capability—then you do not need to worry about the THT.

• THT|REPTHT
are mutually exclusive, optional parameters you use to specify whether an additional new time history table is created or the existing entry is replaced when the current THT entry and current MVS offset differ.

• THT
generates a new THT entry if the current MVS offset from UTC and the current THT entry differ.

• REPTHT
deletes the current THT entry and generates a replacement if the current MVS offset and the current THT entry differ. REPTHT is not valid if the table contains only the original single entry.

In other words, if your RECONs are only being used by V6, then you can forget all about the THT. If your RECONs are being shared between V6 systems and V4/5 systems, then you need the THT.

Warning! The code that allows you to keep IMS running when you change the clocks only applies when you are running V6—you cannot change the clocks and keep IMS running if you still have V4/5 systems using the RECONs. If you do, you will probably end up with bad timestamps and totally confused RECONs—see Appendix A, “THT Problems APAR—PQ03038” for details on how you can make a complete mess. The moral is don’t change the clocks and keep IMS running until you are totally on V6.

• TIMEZONE((label offset),(label offset))
alters the time zone label table. This parameter is used to define one or more symbolic time zone labels because most people do not readily associate a numeric offset with a time zone. TIMEZONE allows you to define symbolic labels, like PST (Pacific Standard Time), for numeric offsets, such as -8. The time zone label table can contain up to 32 entries each composed of a label and an offset.

Adding, replacing, and deleting entries from the stored list is supported as follows:

— Adding an entry to the stored table is accomplished when an input list entry contains both a label which does not exist in the RECON and a valid offset value.

— Replacing an entry to the stored table is accomplished when the input entry contains both a label that matches an existing label in the table and a valid offset value.

— Deleting an entry to the stored table is accomplished when the input entry is a label that matches an existing label in the table and no offset value. If the offset is omitted, and the label is not found in the table, the table is not altered.

The labels in the table must be unique.

• TIMEZIN(offset_rep [,duration])
an optional parameter you use to define a default time zone value for time stamps entered without time zone information on subsequent DBRC commands.

— offset_rep

The default time zone value. It can be one of the following choices:

• label
means a time zone label that has been previously defined using the TIMEZONE parameter.

• offset
means a numeric offset value in the same form as defined above for the TIMEZONE parameter.

• %SYS
is a keyword used to designate that the offset is to be derived from the current offset found in the MVS CVT control block. This is the initial default for DBRC.

— duration Specifies the duration of the offset_rep choice:

• PERM
indicates that the label or offset default is to be in effect for any subsequent DBRC command running with the same RECON.

• TEMP
indicates that the label or offset default is in effect only for the job in which the command is entered. If neither PERM nor TEMP is coded, TEMP is assumed.

• TIMEFMT(sublist)
an optional parameter you use to define the form in which timestamps appear in messages, displays, and listings from DBRC. The format of the TIMEFMT parameter sublist is as follows:

• TIMEFMT(offset,offset_display,form,year_size,duration)
If any of the items in the sublist is omitted, the current value from the RECON header is used.

— offset

specifies the offset which is to be applied to the UTC internal time before display:

• U means none—that is, display UTC when the event occurred.
• O means offset of origin—that is, display local time when and where the event occurred.
• L means current local offset—that is, display the current-local-time equivalent.

— offset_display specifies the display format of the offset which is appended to the time:

• L specifies that the offset is to be displayed in label format, if a label has been defined for it. If no label is defined, the offset is displayed in numeric format.
• O specifies that the offset is to be displayed in the numeric (+/- HH:MM) format.
• N specifies that no time zone information is to be displayed.

— form specifies whether the timestamp is to be displayed in punctuated or compressed form:

• P specifies that the timestamp is to be displayed in punctuated form.
• C specifies that the time is to be displayed in compressed form.

— year_size
specifies, for the punctuated form, whether all four digits of the year are to be displayed or only the two low-order digits. (This specification is ignored when the form is compressed; the compressed form only displays two digits.)

• 2 means only the units and tens digits of the year are displayed.
• 4 means all four digits of the year are to be displayed.

— duration
specifies the scope of these choices to be either limited to the current job or global overrides to the system defaults:

• PERM
  indicates that the specified options are to be in effect for any subsequent DBRC utility job running with the same RECON, i.e. these values become the defaults for subsequent jobs.
• TEMP
  indicates that the specified options are in effect only for the job in which the command is entered. If neither PERM nor TEMP is coded, TEMP is assumed.

Besides its use on the CHANGE.RECON command, the TIMEFMT parameter can be coded on any LIST.xxx or GENJCL.xxx DBRC command. It can also be specified in a skeletal JCL member as:

%SET TIMEFMT(....)

Here is an example of the %SET keyword in skeletal JCL.

%SET TIMEFMT(,N) %SELECT
RLDS(%SSID,LAST) LOGEND =%
LOGETIM %ENDSEL

Figure 8: Example of %SET TIMEFMT.

And here is what the output from the preceding example of %SET would render:

LOGEND =960111315000

The values set in the RECON by INIT.RECON or the upgrade utility are TIMEFMT(O,N,P,2).

The defaults used by GENJCL commands are TIMEFMT(O,O,C,2).

Example of it Going Wrong

To show you what this means in practice, imagine you issued the following command:

GENJCL.CA GRPNAME(AZB38PHD) NOJOB NOLIST MEMBER(CAJCL) -
CATIME('20000011355000')

This won’t work, because DBRC thinks you should be using two-digit years
on GENJCL (default TIMEFMT above). You will get the following messages:

DSP0304I  TIMER SERVICES FAILURE
DSP0304I  FUNCTION = EXTERNAL TO INTERNAL
DSP0304I  DIAGNOSTIC CODE=DDD
DSP0304I  CALLER=DSPURX00 TIMESTAMP=
DSP0204I  INVALID VALUE FOR PARAMETER CATIME
DSP0209I  PROCESSING TERMINATED WITH CONDITION CODE = 12

After playing around, we finally figured out that in order to specify a CATIME in punctuated format with a full four-digit year and have the command run successfully, the timestamp must be specified like this:

CATIME('2000 001 13 55 00 0') or CATIME(2000/001/13/55/00/0)

Alternatively, as GENJCL is expecting two-digit years you could use:

GENJCL.CA GRPNAME(AZB38PHD) NOJOB NOLIST MEMBER(CAJCL) -
CATIME(000011355000)

DSP0203I COMMAND COMPLETED WITH CONDITION CODE 00
DSP0220I COMMAND COMPLETION TIME 2000.002 01:56:43.4
IMS/ESA VERSION 6 RELEASE 1 DATA BASE RECOVERY CONTROL
DSP0211I COMMAND PROCESSING COMPLETE
DSP0211I HIGHEST CONDITION CODE = 00

Or you could specify a different TIMEFMT on the GENJCL command. I would personally carry on using 12-digit timestamps like we have all been using for years.

Figure 9: Sample RECON Header Record and Time History Table.

Part 1  |  Part 2  |  Part 3  | Part 4  |  Part 5  |  Part 6

--

Peter Armstrong joined IBM in 1976 and was the UK Country IMS specialist. He helped design parts of DBRC and wrote the Recovery/Restart procedures for IMS disk logging. He joined BMC in 1986 and travels the world discussing computing issues with customers, analysts, etc. He has used all this technical and practical experience to write a book on how DBRC works in practice rather than a boring theoretical tome. He hopes you will enjoy it.

Peter Armstrong's Blog - Adopting a Service Mentality