COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter THIRTY SEVEN
/* COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS, DALLAS, TEXAS */
****************NEWSLETTER=THIRTY-SEVEN*********************************
MXG NEWSLETTER NUMBER THIRTY-SEVEN, October 20, 2000
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 18.08.
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 18.08.
X. Online Documentation of MXG Software.
XI. Changes Log
Alphabetical list of important changes
Highlights of Changes 18.001 thru 18.250 - See Member CHANGES.
COPYRIGHT (C) 2000 MERRILL CONSULTANTS DALLAS TEXAS USA
I. MXG Software Version 18.08 is now available, upon request.
1. Major enhancements added in MXG 18.08:
II. MXG Technical Notes
1. Converting from JES3 to JES2 (or vice versa) could cause problems
in your weekly/monthly jobs or in your regular reporting:
-JES2's BUILDPDB creates the PDB.NJEPURGE dataset, which is not
created by JES3, while JES3's BUILDPD3 creates the PDB.TYPE25,
PDB.DJEPURGE, and PDB.SPIN25 datasets, which are not created by
JES2. If those non-created datasets are referenced in reports
or WEEK/MONTH build jobs, you must revise those programs when
you change JESes.
-BUILDPDB for JES2 creates variables in PDB.JOBS, PDB.SPIN26,
and PDB.SPUNJOBS, from JES2 6 and 26 records, that do not
exist in those datasets built by BUILPD3 for JES3 records:
ACTBYTES ACTPAGES DEVNAME DUPJBDLY INNODE INREASON
INROUTE JOBMODE0 JOBMODE1 OFFLPURG PRNTCOPY PRPRTY
PRROUTE PUROUTE SETUP SMF26WCL SMF26WIN SMF26WJC
SMF26WOC SMF26WSE SUBMUSER SYSTRANS
III. MVS Technical Notes.
26. APAR OW46470 corrects wrong value in TYPE1415 management class and
data class variables MGMTCLAS and DATACLAS. 19Oct2000.
See also OW46606. 03Nov2000.
25. APAR OW46336 corrects wrong value in TYPE26J2 variable JOBMODE1,
set from IBM bit SMF26SJB to indicate "Job ran because of $S J'.
IBM never set the bit, so JOBMODE1 was always blank in MXG. 19Oct.
24. APAR OW43954 corrects a problem with high disconnect time in RMF
variable R723CIDT in dataset TYPE72GO, that also affected measures
of velocity and delays.
23. APAR OW44517 corrects a problem with high uncaptured CPU time,
with capture ratio dropped by 10% (i.e., CPU time was lost in both
SMF type 30 and RMF type 72 records). This APAR applies to OS/390
R2.5 thru R2.10.
22. APAR OW45020 recommends you should now specify NOTYPE(69), even
though there are no type 69 (VSAM Data Space) records. An LSPACE
macro is issued if TYPE(69) is specified explicitly or implicitly,
and that LSPACE can cause an IPL or long delay as discussed in the
APAR text. Sep 7, 2000.
21. BMC's CMF type 71 SMF record had incorrect values for CSFRxxxx
fields. Relevant BMC PTF numbers are BPM6617 (introduced error),
BPM6791 (fixed to make CMF look like RMF) & BPM7077 & BPM7557.
MXG Change 18.199 is also needed for CSFRxxxx TYPE71 variables.
20. APAR PN65504 reports SMF type 118 has incorrect timestamps for FTP
start and stop events if the C-FTP server is used; timestamps for
the Pascal FTP server had correct numbers. The C-FTP server used
the time function of the C runtime, which returned the number of
seconds since Jan 1, 1980, when it was only the seconds from the
midnight that should have been returned.
19. APAR PQ38319 for DFSORT R14 does not impact MXG sorting under SAS,
but if your site uses DFSORT to sort SMF (or any VBS) records, and
also uses E15/E35 Sort Exits, this APAR corrects DFSORTS error
MSGICE204A 5 INCOMPLETE SPANNED RECORDS DETECTED ON SORTIN.
18. APAR OW45192. RMF 72 records have very large values in CPU time,
elapsed time, and in CPUUNITS fields ('7FFFFFFF'x > 2*10**9 ), but
only in records from Performance Groups or Service Classes in
which enclaves are running. PTFs for APAR OW40548 (which raised
the previous limit of 5,000 enclaves per system to over 32,000)
introduced the error, but only for OS/390 R2.6, R2.7, and R2.8
(the R2.9 PTF for APAR OW40548 was not in error).
The bad data was first seen in records from the DDF (Distributed
DB2), because DDF is the most common user of enclaves, but other
enclave users include CPU Parallelism in DB2, IBM's Web Server (in
Scalable mode), and the MQ Series WorkFlow products.
These bad values cause Negative Uncaptured CPU time error messages
on the SAS log during creation of MXG dataset RMFINTRV, and trash
the TYPE72/TYPE72GO and PDB.RMFINTRV datasets.
Until IBM has a PTF for APAR OW45192, you must delete these bad
observations, in the MXG exit member EXTY72 or EXTY72GO. Look at
your TYPE72/TYPE72GO data to see if CPUUNITS can be used to detect
and if so, then delete the bad observations using:
IF CPUUNITS GE 2E09 THEN DELETE;
in the exit member. Or you could use the PERFGRP number or the
SRVCLASS name to delete the DDF (or any other) observations with
the bad data values. 26Jun2000.
Sep 21, 2000: PTFs exist for APAR OW45192 and did correct that
error at one site.
17. APAR OW41270, OS/390 R2.8 caused creeping ECSA problem that was
resolved by OW43069.
16. APAR OW39924, OS/390 R2.8 and R2.9, macro STCKCONV bad. 17May2000.
There is a blank line in the IBM STCKCONV macro, and it causes the
Assembly of ASMTAPES to fail under OS/390 R2.8 and R2.9. The APAR
identifies the blank line to be removed (or the High Level ASM
can
be used, as the blank line does not trip it up!).
15. APAR OW40458 corrects large values in TYPE72GO Period 2. 27Apr00.
If you are in Goal Mode and specify multiple periods for the
service class that CICS or IMS regions are running in, and you
are also classifying the transactions, negative/large/invalid
values for many variables in period 2 and later periods are
created, because when an address space stops being a server,
it is moved back to period 1 without updating the workload
reporting numbers for the period it had been running in. While
the APAR fixes the IBM error, the site with the problems real
culprit was the accidental misclassification of a test CICS
region into a service class with multiple periods.
14. APAR OW43817 corrects SMF type 85 CICS TRAN ID blank. 26Apr2000.
OAM SMF 85 R85PTRXN was not filled in for customers using the
Default Security Checking Bypass, because the Authorization Check,
and the Gathering of Userid, Trans ID were both being bypassed.
13. APAR OW43581 corrects SMF type 17 fields. Apr 26, 2000
Installing APAR OW41664 corrupts SMF type 17 fields JOB, READTIME,
and LOCLINFO, and the DSNAME has 'SYS' in Columns 1-3. New APAR
OW43581 corrects the problem created when the strengthening of
DADSM's name checking by OW41664 destroyed the register used to
build the type 17 SMF record (Data Set SCRATCH).
12. APAR OW43846 (FIN=Fixed In Next). Apr 17, 2000. Incorrect values
in type 14/15 SMF records for striped extended format sequential
data sets. The first stripes number of tracks is not included in
SMF15NTU if the OPEN was for output with partial release, and both
SMF14NTU and SMF15NTU are too large by one track for each stripe.
11. Multi-volume tape data library last vol not read. April 16, 2000.
IBM APAR OW31263 (1997) for message IEC999I IFG0551H,jjj,prog....
The 35th volume of a 35 volume CICSTRAN-on-tape was not read after
being created; the job stopped after the 34th volume. The SAS log
reported only that an error had occurred "OUTSIDE THE SAS SYSTEM".
10. IBM/Tivoli NetView/FTP Apr 6, 2000. FTP apparently creates SMF
records for FTP with ID=0 if you do NOT specify SMFREC=nnn INIT
parameter for FTP. MXG detects a "Bad IPL" record and deletes;
a hex dump of the type 0 record shows NFTP as the product name.
9. RMF TYPE74 PAV/SHARK Apr 3, 2000. APAR OW40885 reports incorrect
(high) values for PAV devices director port busy (DPB), control
unit busy (CUB) and device busy (DB).
8. CA Dispatch. April 1, 2000. CA Dispatch Release 5.1 can produce
type 6 SMF records with non Y2K Ready date value in SM6JLDAT (the
date part of READTIME); this only seems to occur for Dispatch
data sent directly to 'distribution' (as opposed to printing from
'online viewing' or 'archiving'). CA has a temporary pft
available under CA Problem Number 1195.
7. TCP/IP SMF records. Mar 15, 2000. APAR PQ36346 reports that the
wrong STC name (SMFAPINM) is in the SMF INIT API call records.
The INIT record has the started task name of the TCP/IP stack, the
TERM record is correct and has the started task name of the
application.
6. FTP SMF records. Mar 15, 2000. APAR PQ36103 reports that an SMF
record is not always written when an FTP client user aborts the
connection to OS/390 FTP server. IBM reports "FIN", Fixed in Next
Release, but notes "problem is easily avoided if the client FTP
user avoids aborting the transfer"!
5. WEBSERVER SMF 103. Mar 15, 2000. APAR PQ32435 reports that the
incorrect IP stack address is stored in a VIPA environment.
The OS/390 Webserver (IHS) writes SMF records TYPE103 subtypes 1
and 2 to report configuration and performance data. The customer
has an environment with multiple Webservers using VIPA and Network
Dispatching via D/T2216 routers. They found that the IP address
of the Webserver, reported in the SMF record, derived from the
HTTP Server MIB, variable EntityAddress (and also EntityPort) were
incorrect. The record always contains the default IP stack's
primary IP address. They also noted that the records do not
contain the jobname of the webserver, which would be useful for
subsequent analysis. This APAR is recently opened and no PTF yet.
4. OMVS/USS TYPE 30. Mar 15, 2000. Information APAR II12312:
On OS/390 V1R3 and prior, OMVS used APPC/ASCH initiators for
address space creation. From RACF definitions, an OMVS users
workaccount and workattribute fields were added to the EXEC card
and this information was recorded in SMF Type30 Subtype 2 and 3
records, so OMVS Accounting fields are in the SACCTn variables in
MXG's TYPE30_V and PDB.SMFINTRV datasets. With OS/390 V2R4+, OMVS
now uses WLM initiators for address space creation. From RACF
definitions, an OMVS users workaccount and workattribute fields are
added to the JOB card and this information is recorded in SMF
Type30 Subtype 1 and 5 records, so the OMVS/USS accounting fields
will be in the ACCOUNTn variables in MXG TYPE30_1 and TYPE30_5
datasets, and in the PDB.JOBS/PDB.STEPS observations for OMVS jobs.
3. DCOLLECT. Mar 8, 2000. APAR OW43104 reports incorrect Device
Type on the type 'V' records for RVA and SHARK DASD. RVA shows
9393 instead of 3390 and the SHARK showed as /UNKN/.
2. TYPE92. Mar 3, 2000. According to APAR OW41113, SMF 92 records cut
for open/close under UNIX System Services capture the SAF (RACF)
userid of the process (server) rather than the actual caller of the
service (task). The "process" level OMVS Real UserId and OMVS Real
GroupId were being recorded instead of the "task" level OMVS Real
UserId and GroupId. As of March 3, 2000, that APAR was only a
request; there is no PTF yet that actually records the "task" level
IDs in SMF type 92 records.
1. TPX 4.1. Feb 9, 2000. TPX 4.1 originally wrote GMT time, and then
added GMT offset, so MXG converted times to Local time, but now TPX
has added a new PARM, "Reserve Option #45=Y", that changes the time
values in the record to Local time, but sets no flag in the record
that the timestamps are now on the local clock, so MXG re-adjusted
the time away from local by the GMT offset. (In my opinion, they
should have just zeroed the GMT offset field when the times are
local, and MXG would have calculated correctly!). But instead, you
must set that parm to N so that the record values are in GMT and
the non-zero GMT offset will be used by MXG to correct TPX records.
IV. DB2 Technical Notes.
1. DB2STATS. Mar 29, 2000. APAR PQ21969 corrects QTSLWDD values; the
incorrect (large) value in the type 100 subtype 1 SMF record caused
negative values for IN USE DATASETS in DB2PM and ANALDB2R reports.
DSNB1CST did not decrement the count in QTSLWDD correctly when
closing a linear pageset with multiple pieces during deferred close
request processing, i.e., a problem in serialization if several DB2
jobs 'declaim' at nearly the same time. APARS PQ23458 affects the
Program name and PQ24406 affects the count of datasets closed due
to DSMAX or DDLIMIT being exceeded in error.
V. IMS Technical Notes.
Sep 12, 2000. IMS PTF UQ35642 for APAR PQ30803 has no impact.
That change to the IMS log record fixes an IBM error, where a bit
in field DLRNOSTP is now set when it was not, but MXG does not use
nor care about that bit flag.
VI. SAS Technical Notes.
12. Starting with SAS 8.1, the Sequential Engine names of SASV5SEQ,
SASV6SEQ, and SASV7SEQ cannot be used. However, the engine names
of V5SEQ, V6SEQ, V7SEQ, V8SEQ, & VnSEQ are still supported and will
be supported in future versions. Fortunately, I never knew of the
SASVnSEQ form, so all MXG notes and references have been for VnSEQ!
This note was precipitated because the manual What's New in SAS 8.1,
page 21, Chapter 7 states that "SEQENGINE= now has a default of TAPE
and no longer supports values in the form SASVnSEQ". SAS plans to
change the note to document that the VnSEQ form is still valid.
Additionally, the default of TAPE will be the VnSEQ engine for the
Vn release of SAS, i.e., TAPE=V8SEQ when under SAS V8. 28Sep2000.
11. If you use SAS V8's default Engine to write to a SAS Data Library
that was previously written to by a SAS V6 Engine, and MXG has set
the new SAS V8 option SASCHRLN=32000 (done for you by VMXGINIT when
under V8, but only if you also set option COMPRESS=YES, for some
long text variables in type 102 records), you get ERROR: CHARACTER
VARIABLE HAS TOO LONG A VALUE FOR THE SASEB ENGINE, because SAS
recognized the output data library was built with V6, so it changed
the default Engine from V8 to V6, but the V6 engine doesn't support
long-length variables! The only permanent fix is to not do that:
change your data libraries to V8-built. You must allocate new data
libraries ("PDBs"), and use PROC COPY to copy from V6 to V8, then
delete the old data library, and rename the old back to new. You
cannot use PROC DELETE nor PROC DATASETS to delete all members and
re-use the existing data library, because the SAS directory remains
in V6-format, and so that data library will always be built with the
V6-engine. However, if you still must create SAS V6 data libraries
under MXG under SAS V8, you can reset the value of SASCHRLN by using
%LET SASCHRLN=100; as your first //SYSIN. Sep 6, 2000.
10. Comparing values between MXG PDBs built with V6 versus V8 can show
some differences, but only in the 7th-8th significant digit. The
SAS V8 INHERIT parameter of PROC SUMMARY/PROC MEANS apparently now
uses the length of the input variable for the internal length use in
calculations, whereas without it SAS uses an internal length of 8 in
calculations. With an input dataset that had length 4 variables,
the output values with INHERIT are slightly less than the same PROC
MEANS without INHERIT specified. INHERIT was designed for MXG so
that an entire step in VMXGSUM can be avoided.
9. SAS V8 did not RELEASE space from SAS Data Libraries when it was
requested. SAS Technical Note SN-002674 has the fix. 28Jun00.
8. PROC APPEND with new versions of MXG/ITSV: 26Jun2000.
If you use PROC APPEND to create week-to-date
or month-to-date SAS datasets, new variables added to
MXG datasets will not be added to the APPENDed "Base"
dataset, and lengths of variables that were changed
in MXG will not be changed in your "Base" dataset.
MXG does not actually use PROC APPEND in its code,
because it breaks the sort order of sorted datasets,
but now also because it doesn't propagate dataset changes.
But if you have inherited a job that uses PROC APPEND to
concatenate NEW observations to a BASE dataset:
PROC APPEND BASE=BASE.DATASET NEW=NEW.DATASET FORCE;
and if the contents of NEW.DATASET are different, you get
a condition code 4 and these warning messages on the SAS log:
WARNING: Variable x was not found on BASE file and/or
WARNING: Variable y has different lengths on Base and Data files
(BASE 4 DATA 8).
and the output BASE.DATASET will still have only the
original variables and their original attributes.
You must replace the "BASE.DATASET" with a dataset with the same
name:
a. Somewhere in your jobstream, before the first day of the
whatever-to-date you are building, or after the last day
of that period, that BASE.DATASET is being re-set to zero
observations, instead of being deleted.
If it were being deleted, then the first execution of
the PROC APPEND with a null BASE dataset will contain
all of the variables in the NEW dataset.
Find where that setting of BASE.DATASET to zero observations
is located, and replace it with a PROC DELETE DATA=BASE.DATASET
before the first-day-of-period run.
However, BASE.DATASET will contain only those variables in the
NEW dataset; variables dropped by the new version will not
exist in the replacement BASE.DATASET. If your reports used
those now-non-existent variables, they could fail, but because
of this impact, MXG almost never drops variables!
b. Or, with complete safety, you can re-create your BASE.DATASET, as
it now exists, to contain the union of all variables in both the
BASE.DATASET and NEW.DATASET, with all of the observations in the
BASE.DATASET, adding nothing from NEW, with this program. Execute
the program for each DATASET in the BASE library that is being
PROC APPENDED (after first backing up the BASE library!):
/* Create WORK.NEWBASE with zero obs but with all variables*/
OPTIONS OBS=0;
DATA WORK.NEWBASE;
SET NEW.DATASET BASE.DATASET;
RUN;
/* Reset option obs to max to now actually read observations*/
OPTIONS OBS=MAX;
RUN;
/* Data step will create a new BASE.DATASET; by listing the */
/* WORK.NEWBASE first, its attributes will be used to set */
/* the attributes of variables found in NEWBASE. */
DATA BASE.DATASET;
SET WORK.NEWBASE BASE.DATASET;
RUN;
7. SAS Version 8/8.1 corrupted multi-volume SAS Data Library. Jun 23.
SAS Version 8 & 8.1 will create a corrupted multi-volume SAS Data
Library on DASD (but not a problem with multi-volume Tape), if you:
- Use a STORCLAS with "Guaranteed Space" attribute enabled when
the library dataset was allocated, and
- Have a non-zero Secondary Space Allocation value in the SPACE=
parameter when the library dataset was allocated, and
- The second volume was actually written to.
There is NO error during creation, but when the data library is read
you may get USER 0315 ABEND, with this error message on the SAS log:
Physical I/O error on SAS data library DATA.SET.NAME on
volume volser,jobname,stepname,dev-addr,ddname,86-OP
or you may just get RC=8 with these messages on the SAS log:
Expecting page NNN, got page -1 instead.
Page validation error while reading LIBREF.DATASET.DATA
File LIBREF.DATASET.DATA is damaged.
I/O processing did not complete.
Removing the Secondary Space Value will eliminate this error, and,
if you still must use Guaranteed Space (for example, so you can use
VOLSER= in your JCL), that is the solution. However, if the only
reason you used a STORCLAS with GS was to satisfy SAS V6, then the
permanent solution is to remove the Guaranteed Space attribute from
the STORCLASS, or change your JCL to a different STORCLAS that does
not have the GS attribute specified.
Under SAS V6, GS was REQUIRED for multi-volume DASD, but GS does not
use secondary extents, although they were tolerated in your JCL by
V6. Now, under SAS V8, the existence of a secondary value and GS
causes the corruption (but only when the second volume is actually
opened), but GS is no longer required by V8, and in general, GS
should not be used with V8: with GS and five volumes of 3000 PRI
cylinders, you get 15,000 cylinders whether you need it all or not,
whereas with SAS V8 and without GS, you allocate only the primary on
the first volume, until more is needed by today's job!
Tests with SAS V8 multi-vol DASD strongly suggest that you SHOULD
have a secondary allocation value, once you have removed the GS
attribute, as it makes it easier for allocation to find more space
when available on each volume.
How do you know if you have Guaranteed Space? Look at the STORCLAS
of the Data Library (either in the JCL or on the SYSMSG allocation)
and go to your Storage Administrator, who can use ISMF to see if the
GS attribute is specified for that Storage Class.
SAS Institute is currently investigating a fix (at best, probably,
to force a failure rather than creating the corrupt dataset), and
SAS Technical Support Note 002881 will be posted later this week to
track the problem.
In summary: For Multi-Volume Data Libraries under SAS V8:
a - If you must use Guaranteed Space, do not have a Secondary.
b - Without Guaranteed Space, do have a Secondary allocation.
6. SAS V8 PROC COPY IN=WORK OUT=PDB; if the PDB DDNAME points to a V6
SAS data library, when copying WORK.REGSTRY (MEMTYPE=ITEMSTOR), with
ERROR: REQUESTED FUNCTION IS NOT SUPPORTED, PDB.REGSTRY.ITEMSTOR HAS
NOT BEEN SAVED.... While SAS investigates, adding MEMTYPE=DATA to
the PROC COPY is what you really wanted in the first place, and will
avoid the incompatibility. Jun 12, 2000.
5. The SAS V8 TAPE Engine cannot be safely used. May 12, 2000.
The SAS V8 TAPE Engine (V7SEQ=V8SEQ) cannot be used with complete
safety to create or even to read tape-format datasets. LABELs of
variables in datasets that are created (on tape or disk!) from
V8SEQ-format datasets can be trashed (truncated, overlaid, extra
blanks) if a SET statement with a (KEEP=) dataset option is used.
Bad LABELs can destroy reports, and there is no warning, error
message, nor a condition code set. V8SEQ can also error if you
create tape-format on DASD, but at least then, you do get an error!
These errors were found too late to be fixed in SAS Version 8.1!
July 26, 2000 update: See SAS Note SN-002651. SAS ZAP Z8002651 now
exists for SAS V8.0 and V8.1, and the error is corrected in V8.2.
Until then, the circumvention is to tell SAS Version 8 to use the
V6SEQ engine instead of the V8SEQ engine (both to create and to read
tapes) until SAS Institute has a corrected version.
The Trashed LABELs error:
SAS V8 will create V8SEQ-format datasets on tape, and the LABELs in
the tape dataset are fine, but if you then read that tape dataset to
create a new dataset, the LABELs in that new dataset are trashed if
the SET statement also uses the (KEEP=) dataset option:
DATA SUBSET; SET CICSTRAN.CICSTRAN (KEEP= A B .. Z);
While this case exposes the error, there may be other exposures.
MXG uses (KEEP=) to reduce the number of bytes read into memory. It
is used in VMXGSUM (invoked by all TRNDxxx members and most ASUMxxxx
members), and bad labels were found first in TRND70PR. The (KEEP=)
option is also used by ASUMUOW, which has only data steps, was the
second instance of bad labels, and helped isolate the problem.
The circumvention for Trashed Labels error in SAS V8.0 and V8.1:
You should add SEQENGINE=V6SEQ in your CONFIG member to make V6SEQ
your default tape (sequential) engine. However, you must also scan
your tailoring and report source libraries for any instances of
"LIBNAME ddname TAPE;" and must change "TAPE" to "V6SEQ", because
TAPE in a LIBNAME statement overrides the SEQENGINE option, and TAPE
defaults to V8SEQ under SAS V8, a default that cannot be changed.
SAS V8 should be able to detect that a tape dataset was built with
the V6SEQ engine, but it can't. If you try to read a V6SEQ dataset
with V8SEQ engine, the step fails with error message:
LIBRARY ddname IS NOT VALID FORMAT FOR ACCESS SASV7SEQ!
That's why you should change you CONFIG option to SEQENGINE=V6SEQ.
However, you could instead add a LIBNAME statement for each tape DD,
(in your SYSIN stream) with "LIBNAME ddname V6SEQ;" and not have to
update the CONFIG member, but changing the CONFIG member is probably
the best circumvention.
Second V8SEQ error, tape-format-on-DASD.
V8SEQ also fails if you try to write a tape-format dataset on DASD,
using just the old DDname convention of //TAPExxxx to invoke the
tape engine, because that option invokes only the V5SEQ engine, and
SAS V8 is no longer backwards compatible, as it can only read V5SEQ
libraries; writing to V5SEQ from V8 causes error messages:
WARNING:76-63: THE OPTION LABEL IS NOT IMPLEMENTED IN V5TAPE ENGINE
ERROR: WRITE ACCESS TO MEMBER TAPEXXXX.yyyyyyyy.DATA IS DENIED.
This is documented in the SAS Companion for MVS, V6, Second Edition,
Appendix I, page 437, which is also the reference in the V8
Companion for MVS.
The circumvention is to use LIBNAME ddname V6SEQ ; for any
tape-format-dataset-on-DASD.
MXG's WEEKBLDT and MONTHBLD members use //TAPETEMP for temporary
files to create weekly and monthly PDBs on tape without rewinds, but
both had "LIBNAME TAPETEMP TAPE;" statements, so that "TAPE" was
changed to "V6SEQ" in those two members.
Even if you specify SEQENGINE=V6SEQ in CONFIG, that only applies if
the actual device is tape; to now create a tape format dataset on
DASD under SAS V8, you must now also specify:
LIBNAME TAPExxxx V6SEQ; or LIBNAME ddname V6SEQ;
The text of Change 18.104 has details on the actual MXG changes.
4. SAS V8 OPTION FILEEXT=IGNORE default value must be used with MXG.
The new options can be used to control the syntax than can be used
in SAS programs to reference PDS member names; the FILEEXT=VERIFY
should not be used, since MXG syntax works just fine when OS/390
"ignores" this option by default. FILEEXT=VERIFY causes errors:
ERROR: MEMBER NAME VMXGINIT.SAS CONTAINS AN EXTENSION.
THE SYSTEM OPTION FILEEXT IS SET TO VERIFY, WHICH REQUIRES THE LAST
QUALIFIER OF THE PDS OR PDSE TO MATCH THE EXTENSION.
ERROR: CANNOT %INCLUDE MEMBER VMXGINIT IN THE AGGREGATE SOURCLIB.
3. SAS V6.09E TS455 or later, VM 1319 and USER ABEND 1319, "No MKLEs"
can be corrected by SAS zap number Z609E449, although the problem
can also be circumvented simply by a) making sure your MEMSIZE
option in MXG's CONFIG member is 64M, and b) making sure your REGION
parameter is also 64M so that SAS can get its requested MEMSIZE.
2. SAS V8 ABEND S01D when HSWORK is used. Apr 25, 2000.
SAS zap number Z8001639 corrects said ABEND with SAS Version 8.
1. SAS V8 does not support V5 data libraries. Apr 17, 2000.
SAS V8 does not support V5 format data libraries (recognizable by
their old RECFM=U,BLKSIZE=32760 DCB), failing when written-to with a
WRITE ACCESS DENIED error (which otherwise is the result of using
DISP=SHR for an output SAS data library). In this case, it was the
MXG //SPIN library in the BUILDPDB logic that was still V5, so to
preserve the data and create a V8-format data library, the site
first used V6 to PROC COPY from V5 to a V6 library (DISP=NEW), and
then used V8 to PROC COPY from the V6 library to the (new and not
backwards compatible) V7/V8 SAS data library (DISP=NEW).
VII. CICS Technical Notes.
1. APAR PQ41392 corrects wrong TERMID in SMF type 110 records that was
written for non-Terminal transactions. The TERMID name was FHCI.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 18.04.
1. Incompatibilities introduced in MXG 18.04 (since MXG 17.17):
a- No changes in MXG architecture were made between 17.17 and 18.04
that introduced incompatibilities.
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 17.17 now in MXG 18.04:
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 18.264 thru 18.001 are contained in member CHANGES.