COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter FORTY FOUR
/* COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS, DALLAS, TEXAS */
****************NEWSLETTER=FORTY-FOUR***********************************
MXG NEWSLETTER NUMBER FORTY-FOUR, Feb 11, 2004.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version.
II. MXG Technical Notes
III. MVS Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
X. Online Documentation of MXG Software.
See member DOCUMENT.
XI. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 2004 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 21.21, the 2004 Annual Version, Feb 6, 2004,
was mailed to all sites by Feb 13, 2004.
1. Major enhancements added in MXG 21.21:
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. None.
III. MVS Technical Notes.
11. A closed ETR documents that SRVCLASS='SYSOTHER' can occur in SMF 30
records, even when you have a Default Fall-Thru Service Class, if
the SMF record is being written, i.e., if SMF requests the service
class data from WLM, during a "Service Policy Activation". During
that event, WLM cannot return the valid service class name, so it
is coded to return "SYSOTHER". Working as Designed, no APAR.
10. APAR OA06350 discusses problems with WLM-managed Initiators that did
not start for what appeared to be very long times.
9. Erratic, large values for DEVCONTM and DEVDLYTM ('FFFFnnnn'x, in the
RMF 74 record, IBM fields SMF74CNN and SMF74DVB, a result typical of
a subtraction underflow error) were found when OA05197 and OA05589
APARs were installed, but only for FICON connections, and only for
random read tests. Those APARs revised calculations of values in
the RMF records, but their code changes have no impact on actual I/O
performance. With both APARs removed, the erratic large values in
those two fields did go away, but the RMF numbers without the APARs
showed cache hit response time increased and thruput reduced, so the
APARs were re-installed, large values discarded while IBM works on
the problem, and the numbers with the APARs presumed more correct.
Jan 27, 2004: IBM has PE'd APAR OA05197 with new APAR OA06168 which
acknowledges an RMF coding error is the cause of negative values for
FICON, and the PTF for OA06168 should correct the error.
Feb 16, 2004: APARs OA05197+ was installed and fixed the error.
But the changes in how FICON connect time is measured with and with
out the APAR is discussed in the text of OA05589:
Because of the multiplexing capability built into fibre channel
and FICON, physical disconnection during execution of a channel
program is rare. Control Unit queue time is accumulated during
connect time and not disconnect time, as was the case with ESCON.
The RMF device activity reporting has to be changed to reflect
this difference from ESCON. Affected RMF releases: OS/390-2.10 up
to z/OS-1.5
With this APAR OA05589 RMF device activity reporting will be
changed for FICON attached devices as following:
CU queuing time is now subtracted from Connect time and no
longer from Disconnect time.
For ESCON attached devices the calculation for connect and
disconnect time remain unchanged:
CU queuing time is subtracted from Disconnect time.
8. APAR OA04323 has no impact on MXG Software; it increased the number
of channels to 512, which caused some system monitor programs to
fail because they had internal tables that were too small.
7. APAR OA05542 reports large values in SMF30SRV, ACTIVETM, SMF30PSF.
See also APAR OW53698 for IOUNITS and SERVUNIT errors.
6. APAR PQ82309 reports growth in the Subpool 230 Protect Key 0 virtual
storage when using MULC and creating SMF 89 records. 01Jan04.
5. APAR PQ81716 reports incorrect SMF 119 End Time Stamp for TN3270
sessions that start before midnight UTC and end after midnight UTC.
01Jan04.
4. APAR OA06009 reports SMF 64 fields SMF64RIO, SMF64BMH and SMF64CFH
are not being updated while running RLS. 1Jan04
3. How can you move SMF files between MVS Systems?
a. XMIT/RECEIVE
b. ftp data directly, to pre-allocated VBS file 'SMF.dest.name':
MODE B
TYPE E
GET 'SMF.source.name' 'SMF.dest.name' (REPLACE
c. TRSMAIN
//PACKIT EXEC PGM=TRSMAIN,PARM=PACK
//SYSPRINT DD SYSOUT=*
//INFILE DD DISP=SHR,DSN=input.smf.data
//OUTFILE DD DISP=(,CATLG),UNIT=SYSDA,SPACE=(CYL,(20,10),RLSE)
// DSN=input.smf.data.packed
//***********************************************************
//FTPOSA EXEC PGM=FTP,REGION=4M
//INPUT DD *
domain.name.bla.bla
userid
< >
bin
put 'input.smf.data.packed' (replace
QUIT
/*
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
d. ftp as RECFM=U to PC, ftp PC file to MVS RECFM=U,BLKSIZE=32760,
and then use MXG's UDEBLOCK utility to re-create the VBS records
from the uploaded RECFM=U file.
2. ABEND 0C9 in DFSORT (especially in SAS invoked sorts!!) is corrected
by APAR PQ70787. The ABEND is in ICEKPUT at X'1230' when E33 Exit
is used (and SAS uses that exit). Nov 20, 2003.
1. Type 42 Subtype 21 (DELETE ALIAS) SMF records are not written if you
have CA's PDSMAN product, and you have FASTSTOW=Y (i.e, FAST STOW
option of PDSMAN is enabled). The deletion 'feature' is not yet in
the PDSMAN documentation for FASTSTOW option, but it was CA support
that recommended disabling FASTSTOW so the SMF records are written.
Nov 19, 2003.
IV. DB2 Technical Notes.
3. Another source of negative DB2TCBTM is noted in APAR PQ83772, is
"INCORRECT TIME IN QWACEJST WITH ACCOUNTING TRACE CLASS 2 OFF".
Turning on DB2 Accounting Trace Class 2 on corrected the problem.
The problem reportedly only occurs with CICS/TS 2.2. 17Feb04.
2. APAR PQ79622 corrects error that caused QWACBJST to be greater than
QWACEJST, which caused negative DB2TCBTM. The error occurred when
an SQL statement fired a trigger and that trigger called either a
UDF or a stored procedure, that class 1 non-nested CPU time could
erroneously be a negative value.
1. The DB2PM product statistics reports did not correctly deaccumulate
buffer pool activity in intervals in which a Buffer Pool was skipped
(where that Buffer Pool had had activity in the previous interval).
MXG properly deaccumulated across the missed intervals, and IBM's
DB2PM has accepted the error in APAR PQ81241. PTF issued 4Mar2004.
V. IMS Technical Notes.
1. None.
VI. SAS Technical Notes.
5. MXG has added long-length variables to some datasets, which cause
ERROR: THE CHARACTER VARIABLE xxxxxxxx HAS TOO LONG A VALUE ....
ERROR: FILE DDNAME.yyyyyyyy.DATA HAS NOT BEEN SAVED BECAUSE COPY
COULD NOT BE COMPLETED
when you PROC COPY any of those datasets from a V8/V9 data library
to a V6 data library (like your daily DISP=OLD PDB data library
build years ago with SAS V6).
If DDNAME points to a disk data library, then you must create a new
data library under V8/V9 and use PROC COPY IN=OLD OUT=NEW MT=DATA;
to preserve the existing datasets
If DDNAME is a tape data library, see the next technical note, 4.
4. SAS Version 9.1 (TS1M0) had been tested by MXG under Windows, Linux,
and z/OS versions of SAS, with no real problems or errors, and with
only positive execution results; there is either equal or slightly
better performance (Elapsed, CPU) with V 9.1.
A. Feb 11, 2004: FLASH: MXG default changed to V8SEQ or V9SEQ.
Please replace V6SEQ in CONFIGV8/CONFIGV9 with V8SEQ/V9SEQ, to
be completely safe and avoid potential errors.
In the Feb 6, 2004 (first) MXG 21.21 code and in the Newsletter
FORTY-FOUR that was in NEWSLTRS member, MXG still used the
SEQENGINE=V6SEQ option, because it saved some CPU time by not
compressing when datasets were written/copied to tape. But I
had failed to test PROC COPY to tape with all MXG datasets, and
today discovered that copying some datasets would fail with
ERROR: THE CHARACTER VARIABLE EKC80FRD HAS TOO LONG A VALUE....
ERROR: FILE TUE.TYPE8XEK.DATA HAS NOT BEEN SAVED BECAUSE COPY..
if the MXG dataset contains long-length variables. Only a few
MXG datasets, built under SAS V8/V9 have long-length variables,
but for long text strings, like SQL text, it is the right thing
to do (the alternative: break text into 200 byte chunks!).
So to avoid the errors, the MXG Sequential Engine default was
changed in the Feb 11, 2004 edition of MXG 21.21.
The original note in Feb 6 Newsletter, below, is technically
correct as to why V6SEQ was originally used, but the additional
CPU time for the "unnecessary" compression to IDRC tape drives
is so small that I now wonder if I should have ever spent all
this time/effort discussing it; for a 265 MegaByte file, the
added CPU time was only 20 CPU seconds on a SU_SEC=10000 CPU!
This is the original Technical Note in Feb 6, Newsletter:
MXG still uses SEQENGINE=V6SEQ for SAS V 9.1 instead of V9SEQ,
because the V9SEQ engine spends CPU time when PROC COPY to tape
with COMPRESS=YES is used: since all MVS tape devices are IDRC
hardware compressed, we don't want SAS to compress to tape.
In SAS V9.1, the V9SEQ engine WAS changed for the DATA step,
and SAS datasets written to tape in a DATA step are no longer
compressed. But there's nothing wrong with V6SEQ, and nothing
new/needed in V9SEQ, and the V6SEQ engine has always not invoked
SAS compression when writing to a tape device, so there is no
reason to change MXG, and if I did, some site somewhere would
see and investigate an avoidable CPU bump in their copy jobs.
It turns out the real "culprit" isn't PROC COPY, per se, but
the NOCLONE option of PROC COPY. If we could change the text
of every PROC COPY statement in source code (in MXG, and in
all of your tailoring and personal libraries!), to add the
NOCLONE option (assuming there's enough blank space on each
line), we see that CPU time results with V9SEQ match V6SEQ.
B. Condition Code (also called Return Code) value of 4 can be
expected with MXG's BUILDPDB, because of
WARNING: CHARACTER VARIABLE xxxxxxx LENGTH HAS BEEN SET.
The warning now identifies the variable, and can't be avoided
for JOBCLASS; JOBCLASS is $8 for JES3, but only $1 for JES2.
READ: A PERFECTLY GOOD DAILY JOB WITH CC=0 WILL NOW HAVE CC=4.
And if you use CA-7 for job control and it now expects RC=00,
you'll need to change that in CA-7 before runing under SAS 9.1.
UPDATED: JAN 21, 2005: MXG Change 22.365 has eliminated this
Condition Code problem with SAS V9. With MXG 22.22 or later,
the JES2 default BUILDPDB will end with Condition Code of ZERO.
C. Windows-only comparisons, XP on 3.2 GHz Processor, with disk
copy speed: 8.7 MegaBytes/sec to same disk, 23.4 MB/sec to a
second disk:
Input SMF is 882 MegaByte "JOBS" (SMF 6s, 26s, 30s).
1. BUILDPDB+ big PDB.DDSTATS + PDB.SMFINTRV, FULLSTATS:
V9.0 ET V9.1 ET V9.0 CPU V9.1 CPU
With Compress: 1910 2042 488 382
No Compress 3143 3000 354 330
2. BUILDPDB, no DDSTATS/SMFINTRV created:
V9.1 ET V9.1ET
FULLSTATS NOFULLSTATS
With Compress: 278 264
Observations:
a. COMPRESS=YES on Windows definitely reduces run time from
large BUILDPDB run time of 50 minutes without, to only
34 minutes, for one additional minute of CPU time.
b. FULLSTATS used to cause E.T increase, but not with 9.1;
BUILDPDB took 4 min 38 seconds with FULLSTATS, and took
4 min 24 seconds, so FULLSTATS don't cost much and provide
diagnostic data that is helpful!
D. MXG and SAS V9.1 were run under Windows XP, Linux RH8, z/OS 1.4.
Linux and Windows used the same AMD 1400 1.5 GHz processor with
500 MB and removable drives; z/OS runs were on an IBM 2064-210.
The 842MB SMF file was used.
The DATA step cost is tabulated, and the PROC SORT of TYPE30_D,
which was 3.4 GigaBytes in size are compared:
Data Step LINUX WINDOWS z/OS
Elapsed Time 4:27.70 7:40.02 11:03.36
CPU time 3:59.46 3:57.64 5:56.7
PROC SORT
SORTSIZE DEFAULT 48MB 64MB MAX
Elapsed 15:39.82 28:19.89 12:28.98
User CPU 5:01.43 4:02.93 5:23.16
SORTSIZE 200MB 200MB
Elapsed 15:26.10 28:19.89
User CPU 5:01.02 4:02.93
SORTSIZE 400MB 400MB
Elapsed 19:12.40 35:05.38
User CPU 5:02.79 4:15.81
Observations:
a. SAS V9.1 under LINUX signficantly outperforms Windows XP, in
both the DATA step and in the SORTS.
b. SAS V9.1 under z/OS is significantly slower than either
LINUX or Windows for the DATA step.
c. SAS V9.1 under z/OS is better for PROC SORT, but that was
with SYNCSORT on z/OS. Newsletter FORTY showed that the
SYNCSORT product under Windows was significantly better
than the internal SAS sort under V9.0, but SYNCSORT on
Windows was not available for these tests.
d. On ASCII platforms the SORTSIZE parameter does impact the
elapsed time, and elongation occurs if SORTSIZE is too
large or too small. SAS V9.1 defaults were increased from
the old 2MB default, and seem fine for this 3.4 GB sort.
e. But what is really demonstrated is the repeatability and the
reliability of the SAS System's MVA Architecture to meet the
needs of your SAS applications on any of these platforms. It
takes SAS 5-10 minutes to read a 1 GB SMF file and to create
an MXG "MVS" PDB data library, and 15 minutes to sort a 4 GB
dataset, no matter where you run it; that's pretty cool!
And clearly this is not a capacity comparison of the two
hardware platforms; running MXG on Intel requires dedicated
hardware, at least during the creation of the PDB libraries,
while z/OS can support thousands of users during BUILDPDB.
But it should give you confidence that MXG will continue to
measure your computer systems, no matter where SAS runs, and
your MXG and SAS skills are transferrable across platforms.
3. ERROR: OPEN FAILED FOR FILE XXX: SYSTEM ERROR 013-0E1 results on MVS
if you try to read a Large Block Interface tape file with block size
greater than 32760.
(introduced in OS/390 R2.10, LBI, Large Block Interface, allows
256K for 3590s, 65535 for other tapes, no change for DASD).
SAS Note SN-010759 documents that LBI support is being looked at for
a future release after SAS 9.1, and "until this, it will not be
possible to read those tape files".
2. ABEND 0C4 in the FORMATS step of JCLINSTL with SAS Version 9 was
caused by REGION=6M statement on the JOB card. REGION=64M or
REGION=0M has been recommended for Version 8 and 9 for BUILDPDB.
Also make sure there is not a REGION= parameter on the STEP card.
1. For execution under Windows systems, batch file examples using the
START command are discussed in SN-010991 which lists the link:
"For more information about running jobs in batch, see:
http://support.sas.com/techsup/unotes/SN/004/00449.html
which then lists the link:
http://support.sas.com/techsup/technote/ts648/ts648.pdf
that does discuss batch execution of SAS under Windows.
VII. CICS Technical Notes.
1. APAR PQ81482 corrects CICS ABENDS and overlays that are caused when
PTF UQ79397 is applied after APAR PQ63141, when MNRES=ON in your
CICS SIT to enable Transaction Resource Class monitoring, if DFHMCT
is coded with FILE=8 or more.
VIII. Windows NT Technical Notes.
1.
IX. Incompatibilities and Installation of MXG 20.20.
1. Incompatibilities introduced in MXG 21.07 (since MXG 20.20):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
X. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XI. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetical list of important changes after MXG 20.20 now in MXG 21.xx:
Dataset/
Member Change Description
See Member CHANGES or CHANGESS in your MXG Source Library, or
on the homepage www.mxg.com.
Inverse chronological list of all Changes:
Changes 21.yyy thru 21.001 are contained in member CHANGES.