3.2 Definitions

< Day Day Up >

All log streams (and the structures used by CF-Structure log streams) must be defined in the System Logger policy. Some of the log streams are hard-coded in nature and are only defined in the System Logger policy; others log streams can have variable names and are specified in parmlib or in the catalog.

3.2.1 Subsystem definitions

Following are information on where you need define the log stream names to your TVS subsystem.

The Undo Log

Each instance of Transactional VSAM requires two unique log streams, and the name of the particular instance of Transactional VSAM is incorporated into the log stream names. In parmlib member IGDSMSxx, you associate the name of the Transactional VSAM instance for a given system using two keywords: SYSTEM and TVSNAME. There are three different ways to code these keywords: a unique IGDSMSxx member for each system in the sysplex, a shared IGDSMSxx member for all systems in the sysplex without system symbols, and a shared IGDSMSxx member for all systems in the sysplex using system symbols. For the following examples, assume that we have three systems in the sysplex called #@$1, #@$2 and #@$3 and that we want to run Transactional VSAM instance 001, 002 and 003 on them (Transactional VSAM instance names must be numeric in the range from 001 to 999).

Unique IGDSMSxx member for each system in the sysplex

With this method, you require three unique IGDSMSxx members, one for each of the three systems. In the member used on system #@$1, you would code:

Example 3-1: Sample IGDSMSxx member for system #@$1

 SYSTEM(#@$1) TVSNAME(001)

Similarly, for the member used on #@$2, you would code:

Example 3-2: Sample IGDSMSxx member for system #@$2

 SYSTEM(#@$2) TVSNAME(002)

Finally, for the member used on #@$3, you would code:

Example 3-3: Sample IGDSMSxx member for system #@$3

 SYSTEM(#@$3) TVSNAME(003)

With this methods, you need to remember to create a new parmlib member every time you add a system in the sysplex.

Shared IGDSMSxx member without system symbols

With this method, you only need one IGDSMSxx, but you have to define all the systems in the sysplex in the member. For this example, you would code:

Example 3-4: Sample IGDSMSxx member for all system without using system symbols

 SYSTEM(#@$1,#@$2,#@$3) TVSNAME(001,002,003)

Note

The values for these keywords are positional and you must ensure that you specify the values for SYSTEM in the same order as TVSNAME. In addition, if you add (or remove) a system to the sysplex, you have to update this parmlib member accordingly.

Shared IGDSMSxx member with system symbols

If you use system symbols, you can code a single IGDSMSxx member that does not need to be updated whenever you add additional members to the sysplex. First you must define a symbol that gets a unique value for each system in the sysplex. In this example, we have symbol &SYSID1 which gets the value 1 on system #@$1, a 2 on #@$2 and 3 on #@$3. Now in the IGDSMSxx you code:

Example 3-5: Sample IGDSMSxx member using system symbols

 SYSTEM(&SYSNAME.) TVSNAME(&SYSID1.)

With this method, when you add a system to the sysplex, you only need to ensure that the variable &SYSID1 (defined in IEASYMxx) gets a unique value.

The forward recovery log streams

When you use IDCAMS to DEFINE or ALTER a data set with LOG(ALL), you must also specify the name of the forward recoverylog stream with the LOGSTREAMNAME keyword. Each data set does not need a unique forward recovery log stream; multiple data sets can share the same forward recovery log stream. In this case, usually they are grouped by application.

The log-of-logs

The log stream used for the log-of-logs is defined in two places. For Transactional VSAM, you define the log-of-logs in the IGDSMSxx parmlib member using the LOG_OF_LOGS keywords. Refer to "Subsystem definitions" on page 141 for details on defining the log-of-logs log stream to CICS TS.

Activity keypoint frequency (AKP in IGDSMSxx)

The activity keypoint frequency value specifies the number of write operations to the undo log stream buffer before an activity keypoint is taken. It does not reflect how much data is held in the buffer prior to it being written to IGWLOG.SYSLOG. A keypoint is a snapshot of in-flight URs in the system at that time. The activity keypoint interval is defined as the amount of time between two sequential activity keypoints.

During the activity keypoint, DFSMStvs initiates the log tail trimming for IGWLOG.SYSLOG and IGWSHUNT.SHUNTLOG. After determining the oldest record that is still needed to perform UR backout (this is called the history point), DFSMStvs issues an IXGDELET request to delete all log blocks older than the history point from the log streams. The data is then physically deleted by System Logger during the next offload performed for each log stream. Refer to "Deleting log data" on page 62 for details on the relationship between the logical deletion and physical deletion during an offload.

If you set AKP too high, DFSMStvs performs log-tail trimming less frequently, which results in more data in the log stream. A larger amount of data in the log stream results in an increase in storage usage in the System Logger address space along with an increase in the restart time should DFSMStvs fail.

If you set AKP too low, DFSMStvs performs log-tail trimming more frequently, which might result in the shunting of URs (moving the data associated with a UR from the IGWLOG.SYSLOG to IGWLOG.SHUNTLOG log streams). If the UR ends a little while after the shunting, the shunting was performed needlessly.

The recommendation is to take the default value for this keyword.

3.2.2 Logger definitions

DFSMStvs can use either Coupling Facility log streams or DASD-only log streams; it all depends on your configuration and needs. If you are only running Transactional VSAM on one system, then you can use DASD-only log streams for all the log streams. However, given that all the connections to a DASD-only log stream must come from the same system, if you plan on using Transactional VSAM on two or more systems in the system, then you MUST define all the forward recovery log streams and the log-of-logs log streams as Coupling Facility log streams; however, even in a multi-system environment, you can keep the undo log (IGWLOG.SYSLOG and IGWSHUNT.SHUNTLOG) as DASD-only log streams (as each instance of Transactional VSAM connects to just its log streams).

Coupling Facility log streams or DASD-only log streams for Undo logs

There are items to consider when deciding whether to use Coupling Facility log streams or DASD-only log streams for the IGWLOG.SYSLOG and IGWSHUNT.SHUNT log streams. Positive attributes of a Coupling Facility log stream include better performance (if they are properly tuned). On the other hand, if you are constrained for space in the Coupling Facilities, or your Coupling Facilities are failure dependent with your z/OS images (for a discussion on failure dependent and independent connections, refer to "Failure independence" on page 65), in which case you should use Staging Data Sets anyway, you should consider using DASD-only log streams.

3.2.3 Coupling Facility log streams

You can use Coupling Facility log streams for all the log streams used by Transactional VSAM. Here are a few examples for defining each type of log stream where we highlight the important keywords and their definitions.

Note

When defining a Coupling Facility log stream, you need to ensure that the structure for the log stream is defined both in the CFRM Policy and the System Logger Policy. The order does not matter (you can update the CFRM policy and then the System Logger Policy, or the other way around). However, both definitions must be made BEFORE you attempt to use the desired log stream.

Defining Coupling Facility log streams

Example 3-6 contains a sample job to update the CFRM Policy with a structures to be used by System Logger for IGWLOG.SYSLOG and IGWSHUNT.SHUNTLOG log streams.

Example 3-6: Defining structures in the CFRM policy

 //DEFCFRM  JOB CLASS=A,MSGCLASS=A,NOTIFY=&SYSUID. //CFRMPOL  EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN    DD *    DATA TYPE(CFRM) REPOR(YES)    DEFINE POLICY NAME(CFRMPOL1) REPLACE(YES)    DEFINE STRUCTURE NAME(LOG_IGWLOG_001)       INITSIZE(5120)       SIZE(10240)       PREFLIST(cfname1,cfname2)       ALLOWAUTOALT(NO)       DUPLEX(ALLOWED)       FULLTHRESHOLD(0)    DEFINE STRUCTURE NAME(LOG_IGWSHUNT_001)       INITSIZE(5120)       SIZE(10240)       PREFLIST(cfname1,cfname2)       ALLOWAUTOALT(NO)       DUPLEX(ALLOWED)       FULLTHRESHOLD(0)       STRUCTURE NAME(LOG_CICSVR_001)       INITSIZE(5120)       SIZE(10240)       PREFLIST(cfname1,cfname2)       ALLOWAUTOALT(NO)       DUPLEX(ALLOWED)       FULLTHRESHOLD(0)       STRUCTURE NAME(LOG_LOGOFLOGS)       NITSIZE(2560)       SIZE(5120)       PREFLIST(cfname1,cfname2)       ALLOWAUTOALT(NO)       DUPLEX(ALLOWED)       FULLTHRESHOLD(0) /*

Note

After running the job to update the CFRM Policy, you must issue the z/OS command to activate the new policy. In this example that is:

 SETXCF START,POLICY,TYPE=CFRM,POLNAME=CFRMPOL1

When using Coupling Facility log streams, there are several general recommendations:

INITSIZE and SIZE

The value coded for SIZE should not be more than twice the value coded for INITSIZE. When the structure is allocated, the Coupling Facility Control Code (CFCC) reserves enough control space to accommodate the largest structure possible. If SIZE is much greater than INITSIZE, the portion of control space, which is not usable, system logger does not leave much usable space for System Logger in the structure.

PREFLIST

Eliminate a single point of failure by always having at least two Coupling Facilities. If you only have one Coupling Facility (or if you have multiple Coupling Facilities by only specify one in the PREFLIST for a given structure), if that Coupling Facility needs to come down (for example, to apply a micro-code update to pick-up a newer version of the CFCC), then the structure cannot be rebuilt to an alternate Coupling Facility. By having a second Coupling Facility and specifying at least two Coupling Facilities in the PREFLIST, you allow the structure to be rebuilt from one Coupling Facility to another (either automatically by the operating system or in response to an operator command).

ALLOWAUTOALT(NO)

Since System Logger deletes data from the structure once the log block has been hardened to disk or deleted, the structures used by System Logger may appear to XES as good candidates for an automatic reduction in size. However, the smaller structure size adverse effects System Logger performance. To prevent XES from automatically altering the size of System Logger structures, code ALLOWAUTOALT(NO)

FULLTHRESHOLD(0)

System Logger manages the space within the structure, and at times goes over the default value of 80% structure full. Instead of using the XES messages to determine the structure use, you should use the SMF 88 records and the output from IXGRPT1 or IXGRPT1J to analyze the log stream performance. Therefore, we recommend coding FULLTHRESHOLD(0) to disable the XES monitoring.

In addition to defining the structures in the CFRM policy, you must also define the structures and the log streams in the System Logger Policy. Example 3-7 provides a sample for updating the System Logger Policy.

Example 3-7: Defining Coupling Facility log streams in the logger policy

 //CFBASED  JOB CLASS=A,MSGCLASS=A,NOTIFY=&SYSUID. //LOGRPOL  EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=* //SYSIN    DD *    DATA TYPE(LOGR) REPORT(NO)    DEFINE STRUCTURE NAME(LOG_IGWLOG_001)       LOGSNUM(10)       AVGBUFSIZE(4096)       MAXBUFSIZE(64000)    DEFINE STRUCTURE NAME(LOG_IGWSHUNT_001)       LOGSNUM(10)       AVGBUFSIZE(4096)       MAXBUFSIZE(64000)    DEFINE STRUCTURE NAME(LOG_CICSVR_001)       LOGSNUM(10)       AVGBUFSIZE(4096)       MAXBUFSIZE(64000)    DEFINE STRUCTURE NAME(LOG_LOGOFLOGS)       LOGSNUM(1)       AVGBUFSIZE(4096)       MAXBUFSIZE(64000)    DEFINE LOGSTREAM NAME(IGWTV001.IGWLOG.SYSLOG)       AUTODELETE(NO)       RETPD(0)       DIAG(YES)       HIGHOFFLOAD(80)       LOGGERDUPLEX(COND)       LOWOFFLOAD(60)       LS_DATACLAS(LOGR24K)       LS_SIZE(2000)       OFFLOADRECALL(NO)       STG_DUPLEX(YES)       DUPLEXMODE(COND)       STG_DATACLAS(LOGR4K)       STG_SIZE(0)       STRUCTNAME(LOG_IGWLOG_001)    LIST LOGSTREAM NAME(IGWTV001.IGWLOG.SYSLOG) DETAIL(YES)    DEFINE LOGSTREAM NAME(IGWTV001.IGWSHUNT.SHUNTLOG)       AUTODELETE(NO)       RETPD(0)       DIAG(YES)       HIGHOFFLOAD(80)       LOGGERDUPLEX(COND)       LOWOFFLOAD(0)       LS_DATACLAS(LOGR24K)       LS_SIZE(2000)       OFFLOADRECALL(NO)       STG_DUPLEX(YES)       DUPLEXMODE(COND)       STG_DATACLAS(LOGR4K)       STG_SIZE(0)       STRUCTNAME(LOG_IGWSHUNT_001)    LIST LOGSTREAM NAME(IGWTV001.IGWSHUNT.SHUNTLOG)    DEFINE LOGSTREAM NAME(CICSVR.LOG001)       AUTODELETE(NO)       RETPD(0)       DIAG(YES)       HIGHOFFLOAD(80)       LOGGERDUPLEX(COND)       LOWOFFLOAD(0)       LS_DATACLAS(LOGR24K)       LS_SIZE(2000)       OFFLOADRECALL(NO)       STG_DUPLEX(YES)       DUPLEXMODE(COND)       STG_DATACLAS(LOGR4K)       STG_SIZE(0)       STRUCTNAME(LOG_CICSVR_001)    LIST LOGSTREAM NAME(CICSVR.LOG001) DETAIL(YES)    DEFINE LOGSTREAM NAME(CICSVR.LGOFLOGS)       AUTODELETE(NO)       RETPD(0)       DIAG(YES)       HIGHOFFLOAD(80)       LOGGERDUPLEX(COND)       LOWOFFLOAD(0)       LS_DATACLAS(LOGR24K)       LS_SIZE(9000)       OFFLOADRECALL(NO)       STG_DUPLEX(YES)       DUPLEXMODE(COND)       STG_DATACLAS(LOGR4K)       STG_SIZE(0)       STRUCTNAME(LOG_LOGOFLOGS)    LIST LOGSTREAM NAME(CICSVR.LGOFLOGS) DETAIL(YES) /*

Note

Before you can reference a structure in a log stream definition in the System Logger Policy, you MUST first define the structure. If you try to define a Coupling Facility log stream before defining the associated structure, the job fails with:

 IXG018E STRUCTURE strname DOES NOT EXIST IXG002E LOGR POLICY PROCESSING ENDED WITH RETCODE=00000008 RSNCODE=00000827

Here are the general recommendations for defining the Coupling Facility structures for the Undo logs in the System Logger Policy.

Defining a separate structure for IGWLOG and IGWSHUNT

When using Coupling Facility log streams, you can either use a dedicated structure for each log stream or you can group several log streams onto one structure. (Refer to "How many CF structures do I need?" on page 25 for details on how to best group log streams in the same structure). If you do group multiple log streams into one structure, you should only place log streams with similar characteristics (arrival rate of log blocks, average size of log blocks and maximum size of log blocks) on the same structure. Since IGWLOG and IGWSHUNT have such different characteristics (IGWLOG is written to frequently while IGWSHUNT is rarely updated), we recommend that you use separate structures for the IGWLOG and IGWSHUNT log streams.

Structure related keywords

Following is a description of the keywords used to define the structure for the log stream(s) in the LOGR policy:

LOGSNUM(10)

You should not place more than 10 log streams in the same structure as a larger number adversely effects the System Logger performance when the structure needs to be rebuilt. (Refer to "How many CF structures do I need?" on page 25 for additional considerations).

AVGBUFSIZE(4096)

Specifies the average size of the buffer DFSMStvs passes to the System Logger when it issues an IXGWRITE. For a CF-based log stream, this value, along with the value specified for MAXBUFSIZE, determine the initial entry-to-element ratio for the structure when it is first allocated. MAXBUFSIZE determines the size of the entries: a value of X or more (I need to verify this value) results in an entry size of 512, while any value less than X results in an element size of 256. System logger then calculates how many elements are needed to accommodate the average buffer size, as specified in AVGBUFSIZE, and uses that ratio to set the initial entry-to-element ratio.

When System Logger first became available, it was vital to code these two values correctly as System Logger could not dynamically alter the entry-to-element; if you needed to effect the ratio, you had to delete all log streams associated with this structure, and then delete and re-define the structure with the desired values. However, all supported releases of System Logger can now alter this ratio, so it is not as important to code these values. However, as with most functions that heuristic tune themselves, providing a reasonable initial starting point hastens the tuning.

MAXBUFSIZE(64000)

Specifies the maximum size of the buffer DFSMStvs can pass to the System Logger when it issues an IXGWRITE. For a CF-based log stream, this value, along with the value specified for AVGBUFSIZE, determine the initial entry-to-element ratio for the structure when it is first allocated. MAXBUFSIZE determines the size of the entries: a value of X or more (I need to verify this value) results in an entry size of 512, while any value less than X results in an element size of 256. System logger then calculates how many elements are needed to accommodate the average buffer size, as specified in AVGBUFSIZE, and uses that ratio to set the initial entry-to-element ratio.

Keywords for log stream definitions

Following is a description for the keywords used to define the log streams in the LOGR policy:

AUTODELETE and RETPD

AUTODELETE and RETPD can have a disastrous effect on IGWLOG and IGWSHUNT if specified other than AUTODELETE(NO) and RETPD(0). With AUTODELETE(YES) and RETPD>0, even though DFSMStvs attempts log tail management, all data is offloaded to the offload data sets and held for the number of days specified for RETPD. AUTODELETE(YES) allows the System Logger (rather than DFSMStvs) to decide when to delete the data. When a new offload data set is allocated and AUTODELETE(YES) is specified with RETPD(0), the System Logger deletes the old offload data set (and the data). If DFSMStvs needs the data for backout, the result is a IGW839I message with a 804 return code and DFSMStvs terminates.

For forward recovery and the log-of-logs log streams, you might want to have System Logger automatically delete data that is older than three days by coding RETPD(3) and AUTODELETE(YES). However, if you allow System Logger to delete the data, you should ensure that you are taking back-ups of the associated VSAM data sets at a more frequent interval to ensure you have all the data needed to reconstruct the data set. For example, if you only take back-ups every four days, then you should code a retention period of at least 5 (if not 9 to ensure you have two generations of back-ups).

DIAG(YES)

DIAG(YES) should always be specified for IGWLOG and IGWSHUNT. In a case where the System Logger is unable to locate data requested by Transactional VSAM, a response of return code 8 with reason code IXGRSNCODENOBLOCK is given. This means backout data is not available and Transactional VSAM treats it as a fatal error, terminating with a IGW839I message. In many cases, information from the System Logger address space is needed to resolve the problem. When DIAG(YES) is specified in the log stream definition, a dump of the System Logger address space is provided (by the System Logger) in addition to the dump provided by Transactional VSAM. There is no overhead associated with this parameter unless a dump is requested. This error is normally seen when Transactional VSAM issues an IXGBRWSE for backout data or during activity keypoint processing when Transactional VSAM issues the IXGDELET command to trim the tail of the log stream. It can also be returned when DFSMStvs initializes and perform an IXGCONN (connect) to connect to the undo log stream.

HIGHOFFLOAD

The HIGHOFFLOAD parameter, in conjunction with the size of the log stream, has a major impact on the amount of virtual storage used by the System Logger. For a Coupling Facility log stream, before data is written to the Coupling Facility, it is written to a buffer in the System Logger dataspace. If staging data sets are used, the data is written to the Coupling Facility first, and then written to the staging data set, rather than the dataspace.

If the HIGHOFFLOAD value is too high, the log stream may fill before offload processing can free up sufficient space in the log stream. Transactional VSAM is not aware the offload process is taking place, and continues to write to the log stream. This can lead to an entry or structure full condition, which causes log writes to be suspended for 3 seconds.

HIGHOFFLOAD should be set at 80 - 85% for all Transactional VSAM log streams.

LOGGERDUPLEX

LOGGERDUPLEX(UNCOND) specifies that System Logger should continue to perform its own log data duplexing even if the structure is exploiting the System-Managed Coupling Facility Structure Duplexing function. LOGGERDUPLEX(COND) allows System Logger to rely on the duplexing of data provided by System-Managed Coupling Facility Structure Duplexing support, which means that System Logger does not need to maintain its own version of duplexed data.

Refer to "Defining CF structures - System Logger policy" on page 31 for a discussion on the values for LOGGERDUPLEX keyword.

Specifying LOGGERDUPLEX(COND) only has any meaning if you are exploiting System-Managed Coupling Facility Structure Duplexing.

LOWFFLOAD

The LOWOFFLOAD value defines the amount of data which may be retained in the log stream interim storage following an offload process. In the Transactional VSAM environment, the LOWOFFLOAD value should be high enough to retain the data required for backout but low enough to keep the number of offloads to a minimum.

LOWOFFLOAD should be set around 60% for IGWLOG, and 0 for IGWSHUNT, forward recovery log stream and the log-of-logs log stream.

LS_DATACLAS

With this keyword, you can specify the SMS Dataclass that is used for the allocation of offload data sets. The Automatic Class Selection (ACS) routines can override this value so you should ensure the desired dataclass is used. In addition to the size of the data set, the dataclass defines the CI Size for the data set along with the SHAREOPTIONS. Offload data sets may use a CI size up to 24K; in general, the larger CI size provides better performance, however, if the log stream consists mostly of log blocks of a much smaller size, the 24K CI size may be wasteful.

Important:

The data class is the only way to specify the SHAREOPTIONS for a data set. You MUST ensure that all System Logger data sets, including offload data sets, are allocated with a dataclass that defines SHAREOPTIONS (3,3).

LS_SIZE

LS_SIZE defines the allocation size for the offload data sets. It should be specified large enough to contain several offloads, possibly a day's worth. IGWLOG and IGWSHUNT should only offload a minimal amount of data.

For forward recovery log streams, all data is offloaded. It's very important to specify LS_SIZE large enough to limit the number of times an additional data set is allocated, to reduce the exposure to delays during the allocation process. The size to be specified is based on the amount of data written during the prime processing window of the day. The amount of data written can be determined using the SMF 88 data produced for the log stream by the System Logger.

If the extent size of the LS_DATACLAS (or the value specified in LS_SIZE) is too small, frequent DASD shifts (allocation of a new offload data set) will occur. Frequent DASD shifts have a negative effect on performance and expose the system to a depletion of the offload data sets. The number of offload data sets is limited by the DSEXTENT value specified in the LOGR Couple Data Set. The DSEXTENT value defines the number of logger directory entries. Each directory can point to a maximum of 168 offload data sets. Prior to OS/390 1.3, the number of extents was limited to 1; with OS/390 1.3 and above, the number is limited only by the amount of DASD available.

Attention:

If LS_SIZE is not specified in the log stream definition, and an extent size is not specified in the data class pointed to by LS_DATACLAS, the value is taken from the ALLOCxx Parmlib member and the default value in ALLOCxx is 2 tracks. For information on how to change this value, refer to the z/OS MVS Initialization and Tuning Reference, SA22-7592. Using this default value results in many small offload data sets, which adversely effects System Logger performance.

OFFLOADRECALL

OFFLOADRECALL should be set to NO for Transactional VSAM log streams. This option was added via APAR OW48404. With OFFLOADRECALL(NO), System Logger does not recall an offload data set that was migrated by HSM, but instead, it allocates a new offload data set. This prevents the System Logger from waiting for the recall and avoids the risk of Transactional VSAM being unable to write to a log stream which has filled while waiting for the offload to proceed.

STG_DUPLEX and DUPLEXMODE

STG_DUPLEX and DUPLEXMODE determine under what conditions, if any, System Logger uses a staging data set for a given log stream on a given system.

STG_DUPLEX(NO) indicates that System Logger never uses staging data sets, regardless of the nature of the connection to the structure on which the log stream resides. Since Transactional VSAM cannot tolerate a loss of data condition on the IGWLOG and IGWSHUNT log streams, you should not code STG_DUPLEX(NO) for these log streams. (The one exception to this recommendation is in a test environment where you are willing to perform a Transactional VSAM cold start after a double failure.)

STG_DUPLEX(YES) with DUPLEXMODE(UNCOND) states that System Logger should always use staging data sets for the log stream, even if the connection to the associated structure is failure independent. Even though this guarantees that there will never be a loss of data condition on the log stream, it comes at a price: every write to the log stream is gated by the speed of the I/O to the staging data set.

STG_DUPLEX(YES) with DUPLEXMODE(COND) means that System Logger only uses a staging data set if the CF on which the structure resides becomes volatile, or the structure resides in the same failure domain as the System Logger system. If none of these conditions exists, System Logger duplexes the log blocks in the System Logger dataspace. With this setting, you only pay the penalty of writing to a staging data set in those conditions that might reside in a loss of data condition due to a single failure. This is the recommended setting for all Transactional VSAM log streams

STG_DATACLAS

With this keyword, you can specify the SMS Dataclass that is used for the allocation of staging data sets. The Automatic Class Selection (ACS) routines can override this value so you should ensure that desired dataclass is used. In addition to the size of the data set, the dataclass defines the CI Size for the data set along with the SHAREOPTIONS. Staging data sets must use a CI size of 4K.

Important:

The data class is the only way to specify the SHAREOPTIONS for a data set. You MUST ensure that all System Logger data sets, including staging data sets, are allocated with a dataclass that defines SHAREOPTIONS (3,3).

STG_SIZE

STG_SIZE defines the size of the staging data set to be allocated if one is going to be used. (See the description , "STG_DUPLEX and DUPLEXMODE" on page 97 for details on when a staging data set is used.)

The size of the staging data set (STG_SIZE) must be large enough to hold as much data as the log stream storage in the Coupling Facility.

Data is written to the staging data set in 4096 byte increments, regardless of the buffer size.

For a Coupling Facility log stream, if you don't code STG_SIZE or specify STG_SIZE(0), then System Logger allocates a staging data set as large as the structure to which this log stream is defined; this ensures that the staging data set is not too small compared to the size of the structure. Also, if you increase the size of the structure, the next time the staging data set is allocated, System Logger allocates a larger staging data set.

On the other hand, sometime this might waste DASD storage space since logger doesn't know how many connectors will share the log stream, it always allocate a staging data set as big as the coupling facility structure size and this might be too much. For this reason, it is suggested that you monitor the staging data set configuration through the IXGRPT1 report.

STRUCTNAME

This keyword defines the structure, which must be already defined in the System Logger Policy and which must exist in the active CFRM policy before a connection to this log stream is made, in which the data for this log stream resides.

Multiple log streams can use the same structure, or you can dedicate a given structure to a single log stream.

Note

When grouping log streams onto the same structure, you should ensure that all the log streams have similar characteristics. You want the arrival rate of the data along with the average log block size and the maximum buffer size to be the same. You should NOT place IGWLOG and IGWSHUNT log streams in the same structure since those two log streams have such different characteristics. However, it may be appropriate to group several IGWLOG log streams into one structure.

Defining DASD-only log streams

Example 3-8 contains a sample job that defines DASD-only log streams for IGWLOG and IGWSHUNT. Since the forward recovery and log-of-logs log streams are really multi-system in nature, they are not capable of being defined as DASD-only.

Example 3-8: Defining DASD-only log streams in the System Logger Policy

 //DASDONLY JOB CLASS=A,MSGCLASS=A,NOTIFY=&SYSUID. //LOGRPOL  EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=* //SYSIN    DD *    DATA TYPE(LOGR) REPORT(NO)    DEFINE LOGSTREAM NAME(IGWTV001.IGWLOG.SYSLOG)       AUTODELETE(NO)       RETPD(0)       DASDONLY(YES)       DIAG(YES)       HIGHOFFLOAD(80)       LOWOFFLOAD(60)       LS_DATACLAS(LOGR24K)       LS_SIZE(2000)       MAXBUFSIZE(64000)       OFFLOADRECALL(NO)       STG_DATACLAS(LOGR4K)       STG_SIZE(0)    LIST LOGSTREAM NAME(IGWTV001.IGWLOG.SYSLOG) DETAIL(YES)    DEFINE LOGSTREAM NAME(IGWTV001.IGWSHUNT.SHUNTLOG)       AUTODELETE(NO)       RETPD(0)       DASDONLY(YES)       DIAG(YES)       HIGHOFFLOAD(80)       LOWOFFLOAD(0)       LS_DATACLAS(LOGR24K)       LS_SIZE(2000)       MAXBUFSIZE(64000)       OFFLOADRECALL(NO)       STG_DATACLAS(LOGR4K)       STG_SIZE(0)    LIST LOGSTREAM NAME(IGWTV001.IGWSHUNT.SHUNTLOG) DETAIL(YES) /*

Keywords for log stream definitions

Following is a description of the keywords used to define the log stream in the LOGR policy:

AUTODELETE and RETPD

DASDONLY(YES)

This is how yo identify a log stream as DASD-only. You cannot code STG_DUPLEX, DUPLEXMODE or LOGGERDUPLEX; you can only code this keyword.

DIAG(YES)

DIAG(YES) should always be specified for IGWLOG and IGWSHUNT. In a case where the System Logger is unable to locate data requested by Transactional VSAM, a response of return code 8 with reason code IXGRSNCODENOBLOCK is given. This means backout data is not available and Transactional VSAM treats it as a fatal error, terminating with a IGW839I message. In many cases, information from the System Logger address space is needed to resolve the problem. When DIAG(YES) is specified in the log stream definition, a dump of the System Logger address space is provided (by the System Logger) in addition to the dump provided by Transactional VSAM. There is no overhead associated with this parameter unless a dump is requested. This error is normally seen when Transactional VSAM issues an IXGBRWSE for backout data or during activity keypoint processing when Transactional VSAM issues the IXGDELET command to trim the tail of the log stream. It can also be returned when DFSMStvs initializes and issues an IXGCONN (connect) to connect to the log stream.

HIGHOFFLOAD

HIGHOFFLOAD should be set at 80 - 85% for all Transactional VSAM log streams.

LOWFFLOAD

LOWOFFLOAD should be set around 60% for IGWLOG, and 0 for IGWSHUNT.

LS_DATACLAS

Important:

LS_SIZE

Attention:

If LS_SIZE is not specified in the log stream definition, and an extent size is not specified in the data class pointed to by LS_DATACLAS, the value is taken from the ALLOCxx Parmlib member and the default value in ALLOCxx is 2 tracks. Refer to the z/OS MVS Initialization and Tuning Reference, SA22-7592. Using this default value results in many small offload data sets, which adversely effects System Logger performance.

OFFLOADRECALL

STG_DATACLAS

Important:

The data class is the only way to specify theSHAREOPTIONS for a data set. You MUST ensure that all System Logger data sets, including staging data sets, are allocated with a dataclass that defines SHAREOPTIONS (3,3).

STG_SIZE

STG_SIZE defines the size of the staging data set to be allocated. For DASD-only log streams, staging data sets are always used.

Data is written to the staging data set in 4096 byte increments, regardless the buffer size.

The rule of thumb is it must be large enough to hold the data written during an activity keypoint interval, plus the length of time of the longest running unit of work.

Attention:

If STG_SIZE is not specified in the log stream definition, and an extent size is not specified in the data class pointed to by STG_DATACLAS, the value is taken from the ALLOCxx Parmlib member and the default value in ALLOCxx is 2 tracks. Refer to the z/OS MVS Initialization and Tuning Reference, SA22-7592.

A staging data set with a size of only 2 tracks has an adverse effect on the performance of a DASD-only log stream.

You should monitor the SMF 88 records (using either the sample program IXGRPT1 or IXGRPT1J to format that data) to ensure that the staging data sets are properly sized.

3.2.4 Security definitions

DFSMStvs requires read and write access to all the log streams that it uses and you have to ensure that the proper definitions are made to the security product (like RACF®) to allow this access while at the same time prohibiting undesired accesses.

The easiest way to grant DFSMStvs access to its log streams is to assign the RACF attribute of PRIVILEDGED or TRUSTED to the VSAM RLS server address space, which is called SMSVSAM. With either of these attributes, most RACROUTE REQUEST=AUTH requests are deemed successful without performing any checks and the SMSVSAM address space can access its log streams without any additional profiles.

If SMSVSAM is not given the PRIVILEDGED or TRUSTED attribute, then the userid associated with the SMSVSAM address space must have UPDATE access to all the log streams that DFSMStvs uses.

All log streams are protected by profiles in the LOGSTRM class, and if you use a good naming convention for all your log streams, you can protect the log streams with a few generic profiles. For example, the undo log streams start with a given pattern of IGWTV&tvsname (where &tvsname is defined in IGDSMSxx and is a number in the range of 001 to 999). First you want to ensure that no unexpected programs can access the log streams by defining a profile in the LOGSTRM class with universal access of NONE. For an instance of DFSMStvs with a suffix of 001 that is assigned a userid of smsvsam_userid, the definition of the profile looks like:

Example 3-9: Defining the generic profile to protect the undo log streams

 RDEFINE LOGSTRM IGWTV001.** UACC(NONE)

Now you must grant the SMSVSAM address space UPDATE access to that profile:

Example 3-10: Granting access to the undo log streams to the DFSMStvs userid

 PERMIT IGWTV001.** CLASS(LOGSTRM) ACCESS(UPDATE) USERID(smsvsam_userid)

The forward-recovery log streams and the log-of-log log stream must be protected in a similar fashion. However, in addition to the userid associated with the SMSVSAM address space, the userid of all the forward recovery products need at least READ access (and UPDATE if they are to perform the log-tail trimming for the log streams). If all the forward recovery log streams start with the same prefix of FORWARD, the name of the log-of-logs log stream is LOG.OF.LOGS and the userid associated with the forward recovery program (like CICSVR) is rebuild_userid, the definition of the profiles and the PERMITs might look like:

Example 3-11: Profiles for protecting forward recovery and log-of-log log streams

 RDEFINE LOGSTRM FORWARD.** UACC(NONE) RDEFINE LOGSTRM LOG.OF.LOGS UACC(NONE) PERMIT FORWARD.** CLASS(LOGSTRM) ACCESS(UPDATE) USERID(smsvsam_userid) PERMIT FORWARD.** CLASS(LOGSTRM) ACCESS(UPDATE) USERID(rebuild_userid) PERMIT LOG.OF.LOGS CLASS(LOGSTRM) ACCESS(UPDATE) USERID(smsvsam_userid) PERMIT LOG.OF.LOGS CLASS(LOGSTRM) ACCESS(UPDATE) USERID(rebuild_userid)

To perform peer-recovery, one Transactional VSAM instance might have to access the log streams from another instance of Transactional VSAM. To allow this access with the fewest number of security profiles, we recommend that you associate the same userid with each instance of the SMSVSAM address space.

< Day Day Up >