SYSVIEW CICSTRAN 255 data not being compressed and MXG getting INVALID DATE processing data
search cancel

SYSVIEW CICSTRAN 255 data not being compressed and MXG getting INVALID DATE processing data


Article ID: 249599


Updated On:


SYSVIEW Performance Management


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(                           
%INCLUDE SOURCLIB(TYPSSVIE);                   

NOTE: Invalid data for SMFTIME in line 1 3-10.              

***        DATA IS FROM SYSTEM=     _N_=1 ID=186 SYSTEM=    
***        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  

SMF-CICSSYSD-Compression         No
SMF-CICSTRAN-Compression         No
SMF-CICSTSUM-Compression         No
SMF-CICSXLOG-Compression         No


Release : 16.0

Component : SYSVIEW


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.
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.
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.