SYSVIEW CICSTRAN 255 data not being compressed and MXG getting INVALID DATE processing data
Article ID: 249599
Updated On:
Products
SYSVIEW Performance Management
Issue/Introduction
Moving from z/OS V2.3 with SYSVIEW 16.0.01 to z/OS V2.4 SYSVIEW 16.0.03 and getting the following when trying to build an MXG PDB (VMACSVIE) against CICS 255 data created after the SYSVIEW and z/OS 2.4 upgrade:
%LET MXGREADSMF=LOGGER;
%LET MACKEEP=%QUOTE(
MACRO _IDSVIE 255 % /*SMF ID NUMBER MACRO */
);
%INCLUDE SOURCLIB(TYPSSVIE);
NOTE: Invalid data for SMFTIME in line 1 3-10.
*** ERROR. INVALID SMF RECORD. INVALID SMF TIME.
*** ERROR. INVALID SMF RECORD. INVALID SMF TIME.
*** DATA IS FROM SYSTEM= _N_=1 ID=186 SYSTEM=
*** PREVIOUS RECORD WAS FROM PREVVSYS= PREVVTIM=.
*** HEADER IN HEX IS: C2BA76CD010C0000000000000000
I get that error for every record created under the later SYSVIEW on z/OS V2.4. The hex listing in the MXG output makes it look like the records are not valid SV27TRAN records:
--
I noticed that between old data and new data there is no indication that the new data is being compressed by SYSVIEW, but the previous (old data) was, as per this screen image:
Using SYSVIEW LGBROWSE GSVX.CICSLOGR.TRAN.XXXX and I get the same indication of old data compressed and new data not compressed:
Selecting one of the old records (DAsis – DUMP Record ASIS) and new ones and extracting the SMF Timestamp at x’286’:
When I run the values through a STCK REXX EXEC it prints the correct GMT time:
2022.200 1:50:46.465
2022.222 7:48:39.147
The CTRANLOG “LENGTH” of the new CICS 255 records are all > 3734 bytes, with most being > 4K, yet on the MXG VMACSVIE PDB build output on new data it shows the records are uncompressed and < 3K:
GSVX920I LOGGER LOGRExit GSVXLGEX 1A273C88 Release 16.0 Build 0990 20210823 10.47
GSVX921I LOGGER Open Log Stream GSVX.CICSLOGR.TRAN.XXXX
GSVX922I LOGGER Options GSVXLGEX
GSVX922I LOGGER Options FROM=(2022/222,17:00:00),TO=(2022/223,10:00:00),LOCAL
GSVX922I LOGGER Options EXPAND,STATS,FORWARD,NORDW
GSVX927I LOGGER Requested start time 2022/08/10 17:00:00.000000 Local
GSVX927I LOGGER Oldest record read 2022/08/10 17:49:18.763426 Local
GSVX927I LOGGER Youngest record read 2022/08/11 09:16:55.903345 Local
GSVX928I LOGGER Oldest block ID read 000000C63D71655C
GSVX928I LOGGER Youngest block ID read 000000C63D9ABE05
…
GSVX923I LOGGER Record Statistics
GSVX923I LOGGER Records returned 922
GSVX923I LOGGER Log records expanded 922
GSVX923I LOGGER Average compression 0% <--
GSVX923I LOGGER Max input record length 5069
GSVX923I LOGGER Max output record length 5069
GSVX923I LOGGER Avg input record length 2903
GSVX923I LOGGER Avg output record length 2903
GSVX923I LOGGER Avg expanded length 2903 <--
Do not understand how uncompressed records can be all smaller. But if I run the identical job to process old data created under z/OS V2.3 (19-July-2022) I get much longer records and an indication of 62% compression:
GSVX923I LOGGER Record Statistics
GSVX923I LOGGER Records returned 1557
GSVX923I LOGGER Log records expanded 1557
GSVX923I LOGGER Average compression 62% <--
GSVX923I LOGGER Max input record length 2459
GSVX923I LOGGER Max output record length 6078
GSVX923I LOGGER Avg input record length 2256
GSVX923I LOGGER Avg output record length 5822
GSVX923I LOGGER Avg expanded length 5822 <--
It also seems weird that there would be problems dealing with uncompressed data, though compression wanted, feeling that the lack of compression is an indication that something is wrong.
Noticing these parameters CASYSVW.CNM4BPRM(CICSLOGR) in both old and new SYSVIEW configurations show no compression, but not sure if these parms apply to 255 records. If the parms do apply, then not understanding how our old configuration has, for years, run with those default parameters yet we still get compression; unless somebody dynamically updated the value online only – is there some way that I can verify what these settings are active online in SYSVIEW?
DynamicExit-CICSSYSD No
DynamicExit-CICSTRAN No
DynamicExit-CICSTSUM No
DynamicExit-CICSXLOG No
ISERVE-NAME ISRV
LOG-EXCEPTIONS-SMF NO
LOG-SYSTEM-DATA-SMF NO
LOG-TRANSACTION-SUMMARY-SMF NO
LOG-TRANSACTIONS-SMF NO
…
…
SMF-CICSSYSD-Compression No
SMF-CICSTRAN-Compression No
SMF-CICSTSUM-Compression No
SMF-CICSXLOG-Compression No
Environment
Release : 16.0
Component : SYSVIEW
Resolution
Summary of why the zEDC-compressed records did not get uncompressed by GSVXLGEX in your environment:
SYSVIEW PTF LU02534 added support for zEDC hardware compression when the proper hardware is available. In this case of z15 it is (even though you have FEATURENAME(zEDC) disabled).
Changes made to GSVXLGEX in support of this now require it to be invoked from an authorized step, e.g. any STEPLIB in the step that invokes GSVXLGEX must be APF, else it won't be able to uncompress the records.
Changes made to GSVXLGEX in support of this now require it to be invoked from an authorized step, e.g. any STEPLIB in the step that invokes GSVXLGEX must be APF, else it won't be able to uncompress the records.
In the case it was invoked by an EXEC PGM=SAS step which had a STEPLIB to the SAS loadlib that wasn't APF.
The alternative is to add an IEBGENER step that invokes GSVXLGEX to read/uncompress the records to a file, and then use that file as input in the SAS step.
The alternative is to add an IEBGENER step that invokes GSVXLGEX to read/uncompress the records to a file, and then use that file as input in the SAS step.
Going forward we'll look at modifying GSVXLGEX to make this APF issue more easily identifiable with error msg or such. I'll also look at updating our doc in this area.
Feedback
Yes
No
Powered by
