Decision Support for z/OS, Version 1.8.1
Suppose you want to process a log XMP where each record contains a date in the format exemplified by 14MAR00. This date format is not supported by the log collector. You might define the three parts of the date as three fields in CHAR format, use the facilities of the log collector language to build from them a date string 00-03-14, and then convert that string to date using the DATE function. You would have to do this in every update definition that uses the date. If you have many such update definitions, it may be simpler to convert the date using a log procedure.
An example of a log procedure that you might write to perform this conversion is shown in Example C log procedure. An Assembler version of the same procedure is shown in Example Assembler log procedure.
In order to illustrate the use of the parameter specified via PARM clause, the example assumes that the month part of the date in the input record may sometimes be missing or invalid. In such a case, you want to replace it by a default supplied by means of PARM.
DEFINE LOG XMP
LOGPROC XMPPROC
LANGUAGE C
PARM :DEF_MONTH;
The default month is supplied via the variable DEF_MONTH that must be set every time you work with the log XMP. The value of the variable should be a two-digit string from 01 through 12.
The input record from the log data set is represented in the procedure by the structure in_record. The first seven bytes contain date as described above, and the next six bytes contain a transaction count represented as an external integer.
The structure out_record represents a record built by the procedure. The record starts with a two-byte length field, followed by the converted date in the format DATE(YYMMDD), followed by a copy of transaction count from the input record. You define this record to the log collector like this:
DEFINE RECORD XMP_REC
IN LOG XMP
FIELDS
(RECLEN OFFSET 0 LENGTH 2 BINARY,
DATE OFFSET 2 LENGTH 6 DATE(YYMMDD),
TRANS_COUNT OFFSET 8 LENGTH 6 EXTERNAL INTEGER);
You cannot build the output record in a variable that is local to your procedure, because it must be accessible to the log collector after a return from the procedure. So, the first call to the procedure must allocate a buffer for the output record that will remain allocated until it is freed by the last call.
The output buffer is placed in a data area that is allocated by the first call and freed by the last call. The layout of this area is represented by the structure work_area. In this example, the work area contains only the output buffer. In general, you include there all information that you need to store between the calls to the procedure.
Other details of the procedure are explained by comments.
[ Top of Page | Previous Page | Next Page | Contents ]