COPYRIGHT (C) 1984-2009 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter FIFTY-FOUR
Last Updated: Aug 10, 2009.
***********************NEWSLETTER FIFTY-FOUR****************************
MXG NEWSLETTER NUMBER FIFTY-FOUR, AUG 11, 2009.
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
I. MXG Software Version.
II. MXG Technical Notes
III. MVS, aka z/OS, Technical Notes
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VI.A. WPS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
XI. Incompatibilities and Installation of MXG.
See member CHANGES and member INSTALL.
XII. Online Documentation of MXG Software.
See member DOCUMENT.
XIII. Changes Log
Alphabetical list of important changes
Highlights of Changes - See Member CHANGES.
COPYRIGHT (C) 1984,2009 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2009 Annual Version MXG 26.26 was dated Feb 12, 2009.
All sites were mailed a letter with the ftp download instructions.
The availability announcement was posted to both MXG-L and ITSV-L.
You can always request the current version using the form at
http://www.mxg.com/ship_current_version.
1. The current version is MXG 27.07, dated Aug 10, 2009.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
1. DB2 CPU Cost using MACDB2H Header Exit vs _EDB2ACC Dataset Exit.
An SMF file of 58GB of 35 Million SMF records, 17 Million DB2 101
Subtype 0 (DB2ACCT) was processed using the MACDB2H "Header Exit"
or using the _EDB2ACC "Dataset Exit" to select/output 36998 obs,
with and without using the MACFILE "SMF Header Exit" to skip the
other SMF records in the file. The INPUT program was TYPEDB2, with
_NDB2 nulling out the OUTPUT of all but DB2ACCT; however, the _NDB2
only nulls the OUTPUT of those other datasets - the DB2 records are
still fully decoded to the point of the OUTPUT. The _EDB2ACC exit
selected which observations were to be output to DB2ACCT, whereas
the MACDB2H code threw away the unwanted records as soon as the DB2
header was INPUT, so it eliminated all of the decoding code for the
unwanted records. Only 11 variables were KEPT in DB2ACCT.
Records Read Exit Used CPU Time mm:ss DB2ACCT obs
ALL 35MM Records _EDB2ACC 23:32 36998
17MM ID 101 ST 0 None 14:33 17MM
17MM ID 101 ST 0 _EDB2ACC 13:59 36998
17MM ID 101 ST 0 MACDB2H 6:38 36998
Skipping half the records in the MACFILE exit dropped the CPU time
from 23 minutes to 14 minutes, but that run output all 17 MM obs.
Using the _EDB2ACC reduced that time by 34 seconds, showing that
the cost to write 17MM vs 36000 (short) observations is cheap.
Then, using MACDB2H to eliminate the decoding dropped CPU time to
only 6 minutes.
The MACDB2H exit was used to "look ahead" and INPUT the QMDA fields
that were used in the selection. (Note that SUBTYPE had to be INPUT
in the MACFILE exit because SMF 101 records do NOT have the subtype
bit enabled; that has been corrected in VMACSMF in MXG 27.03 which
inputs the SUBTYPE for the 101, 110, 115, and 116, in spite of the
absence of the bit that says the subtype field is valid.)
%LET MACFILE=
%QUOTE ( IF ID=101 ;
INPUT @19+OFFSMF SUBTYPE &PIB.1. @;
IF SUBTYPE=0;
) ;
%LET MACDB2H=
%QUOTE ( IF OFFQMDA GT 0 AND NRQMDA GT 0;
OFFTEST=OFFQMDA-3+OFFSMF;
INPUT @OFFTEST+41 TESTCNAM $EBCDIC8.
TESTCTYP $EBCDIC8.
@;
IF TESTCNAM='BATCH' OR TESTCTYP='BATCH';
);
%LET MACKEEP=
%QUOTE( _NDB2
MACRO _SDB2 %
MACRO _WDB2ACC PDB.DB2ACCT %
MACRO _VDB2ACC KEEP=JOB SYSTEM DB2SRBTM DB2TCBTM
QB1CGET QB2CGET QB3CGET QB4CGET
QB1CRIO QB2CRIO QB3CRIO QB4CRIO %
);
%INCLUDE SOURCLIB(TYPEDB2);
III. MVS, a/k/a z/OS, Technical Notes.
15. APAR OA27752 corrects possible low counting of SMF 30 EXCPs in the
DD Segments; IBM field SMF30BLK in the DD segments is EXCPTODD and
all of the per-device EXCP counts (EXCP3380 etc.) in MXG TYPE30xx
datasets.
DD LEVEL EXCP COUNT DECREASED BY 5% GOING TO Z/OS 1.7 FROM 1.4.
Since migation to z/OS R7 from R4, customer noticed the DD level
EXCP count (SMF record type 30 SMF30BLK or type 15 SMFEXCP) is
slightly less than it should be. For example, when a program does
10,000 blocks BSAM WRITE, SMF30BLK /SMFEXCP shows (1st) 9,795 (2nd)
9,801 (3rd) 9,831 (4th) 9,838 .. The count varies each time and
2-3% less than 10,000. This,typically, occurs on PSE (extended
format) with multiple extents. The cause seems to be the fix of
OA05045 (FIN) for IEASMFEX. With this fix code, IEASMFEX sometimes
returns RC4 to SMFIOCNT macro issuer when local/CML lock is not
available and so it does not update DD level EXCP count. But it
looks nobody cares about this RC04 from IEASMFEX.
For PSE case, SMFIOCNT macro is issued from ICYDIE.
The SMF30BLK field of the SMF type 30 record reports the block I/O
counts at the DD level. The value in this field may be slightly low
at releases above z/OS 1.6. Lower values in this field can be
attributed to lock contention for updating the TCT I/O Table
(TCTIOT) control block, where the interim count value for this field
is maintained. Serialization for updating the TCTIOT was introduced
at z/OS 1.7 causing some attempts to increment the count in the
TCTIOT to be rejected.
PROBLEM CONCLUSION:
Internal SMF services are updated to use a different serialization
mechanism to update the TCTIOT. Although this solution will not
completely eliminate the possibility that a TCTIOT update can be
rejected, resulting in lower DD level block I/O counts, it will
reduce the possibility of this.
14. APAR OA29803 corrects JES2 SMF 26 variable SMF26WCL when the Service
Class was changed; it has the same value as SMF26WOC, the initial
WLM Service Class, without this APAR. Jul 20, 2009.
13. APAR OA27563 corrects errors in SMF ID=42 ST=21,24 and 25 records:
-SMF 42 subtype 25 contains an incorrect triplet count.
Subtype 25 contains x'0003' at offset 18 for the number of
triplets present, but there are actually 4 triplets.
-SMF 42 subtype 21 and 24 userID token not correctly formatted.
And now, after Change 27.155 circumvented the mislocated ICHRUTKN,
a new APAR OA29737 adds these notes of the fixes in the original
OA27563 APAR, with no new PTF:
-Record has truncation - Solution: Apply existing APAR OA27563.
-SMF42 SUBTYPE24 AND SUBTYPE21 USER INFORMATION SECTION
Correct start location is skewed by +2 bytes.
-SMF42 ST24 and ST21 records are incorrectly created with a 2
byte field ( SMF42P#A or SMF42LNA ) for Alias Names section
when there are no alias names. Jul 13, 2009.
12. From the text of APAR OA26104 New Function: Work Dependent Enclaves:
"For SQL statements that are eligible for parallel query execution,
DB2 creates additional independent enclaves. These enclaves are
created under subsystem DB2 (which the DBM1 space is connected to)
and are classified according to the classification rules for
subsystem DB2. In order for these enclaves to be classified
correctly, the classification rules for subsystem DB2 must be
updated to replicate existing classification rules for every
subsystem that may cause a stored procedure to run that exploits CPU
parallelism. Furthermore, these additional independent enclaves are
regarded as new transactions."
Updates to
MVS Programming: Workload Managment Services
SA22-7619-14 / SA22-7619-16 / SA22-7619-17
Section "Enclave Resource Accounting":
The accounting for resources consumed by an enclave depends on
whether it is an independent, work-dependent, dependent, or a
foreign enclave. (...)
For an independent enclave and work-dependent enclaves, CPU
service is included in the SMF 30 record of the owning address
space, and in the SMF 72 record for the enclave service class or
performance group period. MSO service is not calculated for either
kind of enclave.
For dependent, work-dependent, and independent enclaves, IOC
service is included in the SMF 30 and 72 records associated with
the address space where the enclave work is executing. SRB service
for enclaves is always zero.(...)
Table "Enclave Characteristics and Resource Accounting"
** NOTE: if a cell is omitted here, it's content hasn't
changed **
Dispatchable unit type:
Work-dependent enclave: SRBs and/or tasks
New transaction:
Work-dependent enclave: no
Owner:
Dependent enclave:
Depends on the TYPE parameter passed to IWM4ECRE:
If TYPE=DEPENDENT, the home a.s. at the time the
service was issued.
If TYPE=WORKDEPENDENT, the creating (dependent)
enclave's home a.s.
If TYPE=MONENV, the a.s. associated with the
monitoring environment - see note 1
Work-dependent enclave:
owner a.s. of the creating independent enclave
Server:
a.s. where enclave work is dispatched
Service class/report class:
Work-dependent enclave:
same as owning independent enclave's
CPU time:
Independent enclave:
owner's SMF30CPT - MXG CPUTCBTM (total)
owner's SMF30ENC - MXG CPUENCTM (independent and
work-dependent only)
Work-dependent enclave:
owner's SMF30CPT - MXG CPUTCBTM (total)
owner's SMF30ENC - MXG CPUENCTM (independent and
work-dependent only)
CPU service by address space:
Independent enclave:
owner's SMF30CSU - MXG CPUUNITS (total)
owner's SMF30ESU - MXG ENCLCPSU (independent and
work-dependent only)
Work-dependent enclave:
owner's SMF30CSU - MXG CPUUNITS (total)
owner's SMF30ESU - MXG ENCLCPSU (independent and
work-dependent only)
CPU service by period:
Independent enclave: enclave's R723CCPU - MXG CPUUNITS
Dependent enclave: owner's R723CCPU - MXG CPUUNITS
Foreign enclave: enclave's R723CCPU - MXG CPUUNITS
Work-dependent enclave: enclave's R723CCPU - MXG CPUUNITS
DASD I/O connect time by a.s. (see note 3)
Independent enclave: owner's SMF30EIC
(independent and work-dependent only)
Dependent enclave: owner's R723CCPU - MXG CPUUNITS
Foreign enclave: enclave's R723CCPU - MXG CPUUNITS
Work-dependent enclave:
owner's SMF30Eic (independent and work-dependent
only)
DASD I/O connect time by period (see note 3)
Independent enclave: enclave's R723CICT
Dependent enclave: owner's R723CICT
Foreign enclave: enclave's R723CICT
Work-dependent enclave: enclave's R723CICT
DASD I/O counts by address space:
Independent enclave: owner's SMF30EIS
(independent and work-dependent only)
Work-dependent enclave: owner's SMF30EIS
(independent and work-dependent only)
DASD I/O counts by period:
Independent enclave: enclave's R723CIRC
Dependent enclave: owner's R723CIRC
Foreign enclave: enclave's R723CIRC
Work-dependent enclave: enclave's R723CIRC
Page delay samples, with storage mgt. (see note 4)
Work-dependent enclave: enclave's R723CSPV - MXG PCTDLSPV
Page delay samples, without starage mgt. (see note 4)
Work-dependent enclave: enclave's R723CAXM - MXG PCTDLAXM
IOC service:
Work-dependent enclave:
server's SMF 30 and 72 records
SRB service:
Work-dependent enclave: n/a
MSO service:
Work-dependent enclave: n/a
11. APAR OA29102 (HIPER,PERVASIVE,DATALOSS) for HSM corrects an error
in z/OS 1.8 and 1.9 that corrupts Create Date when a VSAM file was
RECALLed or RECOVERed; the invalid value 1901.921 is stored, and
it is possible VSAM datasets with that create date could have been
prematurely deleted. Among more details in the APAR text is this
note with regard to possible DATALOSS:
4) Recover datasets that were prematurely deleted.
To determine if any VSAM datasets were deleted, first determine
the window that VSAM datasets were susceptible to the problem.
Determine the time frame between when PTFs UA46732/UA47067 R180
or UA46733/UA47068 R190 were applied and when the fixing ++APAR
or PTF was applied. For this time frame, collect all SMF
records type 60 to 65 and HSM FSR records (SMF 241 if using the
default value for SETSYS SMF(type)+1). The SMF data along with
the date of when the ptfs were applied will be needed by IBM
support to determine what datasets may have been prematurely
deleted. Contact IBM support once you have the all of the
above information.
You might detect any current VSAM datasets with that Invalid Create
Date of 1901.921 by reading the EXPORT of your CATALOG with MXG's
TYPECTLG program; that invalid value for OWNCREDT should print notes
on the SAS log; once I see an example of how that is stored in three
bytes of packed decimal, I will detect that value and format it so
you can identify all such VSAM datasets in your catalog.
10. APAR OA28459 for SMF 42 Subtype 6 removes an exposure to SMSVSAM
ABEND 0C4 in IGWMCOLP in SMSVSAM.
9. APAR PK83021 reports DFH$MOLS fails with ABENDU0103 if the SMF110
records are longer than 32754. The PTF changes the LENGTH in the
DFHMOLS created DFSORT RECORD control statement from the wrong 32752
to the proper maximum of 32756 bytes for an SMF record.
8. Work-dependent Enclave Resource Accounting.
Documentation in "MVS Programming: Workload Management Services",
SA22-7619, Chapter 3. Creating and Using Enclaves has been updated
with more extensive information, but this summarizes whats where:
The accounting for resources consumed by an enclave depends on
whether it is an independent, work-dependent, dependent, or a
foreign enclave.
For an independent enclave and work-dependent enclaves, CPU service
is included in the SMF 30 record of the owning address space, and
in the SMF 72 record for the enclave service class or performance
group period. MSO service is not calculated for either kind of
enclave.
For dependent, work-dependent, and independent enclaves, IOC
service is included in the SMF 30 and 72 records associated with
the address space where the enclave work is executing. SRB service
for enclaves is always zero.
7. Measuring the amount (length) of a tape volume that has data, is no
longer possible as discussed in this thread on IBM-Main in June 09:
Length of tape (in metres) nowadays is bulls*t:
1. Serpentine recording. It's like audio cassettes with A and B
side, but modern tapes have multiple dozen of "sides" (72 for
TS1130 aka Jaguar3). Because of that real physical tape length
should be multiplied by "number of sides".
2. Blocking. Space (length) occupied "brutto" depends on the
block size, both logical and physical. Physical means modern
tape drives do its own reblocking "under the cover".
3. Last but not least: COMPRESSION. While you may find out how
much of a tape has data bytes (maybe provided by RMM/CA-1), of
course "the number of bytes" has little to do with dataset(s)
size, and you cannot predict exactly how well your future data
will be compressed. Of course you can always estimate it using
"not less than" operator, but such estimates will be veeeeery
inaccurate, unless you record really non-compressible data.
This post was then added to the thread:
Actually, that will depend on the TAPEMAP utility. Some (the one
included with the CA-1/Copycat and CA TLMS/Copycat utitilies for
example) will actually get the physical tape position from the
device at the end of each file to give an accurate position map
of all files on the tape. But you are correct, based strictly on
the amount of data written does nothing to determine how much of
the tape has been used; not since IDRC was introduced.
6. APAR PK84730 is a error in IBM ftp introduced in z/OS 1.10 that
showed up when the SAS ftp access method tried to read a data file
that was on tape. There was no ftp error message; the problem only
surfaced with this SAS message on the log when SMF records were
read with MXG under z/OS 1.10:
NOTE: Invalid data for SMFTIME in line 1 3-10.
but the tape was read without that message under z/OS 1.10.
However, the APAR text notes that the error could fail with
200-Conflicting SITE operands RDw and READTAPEFormat.
READTAPEFormat ignored.
IBM Support has opened that APAR and is working on the PTF, but by
modifying the ftp command to have two site commands, this syntax
has circumvented the error:
FILENAME SMF FTP
("'MXG.SMF.PROD.DAILY(-00)'"
"'MXG.SMF.DEVA.DAILY(-00)'"
"'MXG.SMF.TST1.DAILY(-00)'")
USER='username' HOST='where.i.loading.from'
RCMD='SITE RDW;SITE READTAPEFORMAT=S'
S370VS LRECL=32760 PASS='password' DEBUG;
5. APAR PK77275 for SMF 120 Subtype 9 corrects a problem with the CPU
usage subsection not being generated when enabled via the MODIFY
command.
4. APAR PK83225 for SMF 120.
SMF data is not returned by the data collector(DC) if SMF type 120
subtype 8 (Web container interval) records have not been written by
the pap server, detected by the CYN1 U83 exit, and recorded into
the CYN1 subsystem. In our Web console BE, this message is
displayed:
CYNVE0388E The data is currently unavailable.
This situation exists until Http traffic is received. Those
customers using WebSphere as an EJB server without Web container
activity are not seeing any data in the SMF Data page. With this
APAR, CAM will be changed so that the DC will return SMF data once
SMF 120-3 ( server interval) records are detected. Web container
activity no longer is required for this page to be populated.
3. APAR OA28499 is opened for an issue that caused PTF UA46066 (for
APAR OA27699) to be PE'd. That was a PTF that is recommended if
you use logstreams for SMF, but it causes a buffer shortage if you
are instead using MANx datasets and you have a high volume of SMF
records. The 'IEE986E SMF HAS USED 25% OF AVAILABLE BUFFER'
messages are NOT issued, but you will get RC 28 from SMFWTM. The
APAR OA28499 is open for z/OS 1.10, but the error may apply to
lower levels with PTF UA46066 applied.
2. APAR OA27752 reports incorrect reduction in recorded EXCP counts in
DD segments in SMF 30 (IBM SMF30BLK, all EXCPxxxx variables in
TYPE30 and PDB.STEPS/PDB.JOBS except EXCPTOTL), and in SMF 14/15
(IBM SMFEXCP, MXG EXCPCNT in TYPE1415), migrating from z/OS 1.4
to 1.7. No PTF or explanation, so it's not clear if this is ONLY
a z/OS 1.7 issue or if it impacts subsequent z/OS releases. Text
here will be updated when a PTF exists for this APAR. 18Feb2009.
1. New EMPTYEXCPSEC option in PARMLIB is z/OS 1.10 only.
While EMPTYEXCPSEC option is documented in the z/OS 1.9 SMF manual
in Section 13.34.2.7 (Execute Channel Program (EXCP) Section) of
z/OS MVS System Management Facilities (SMF) Document SA22-7630-16,
for z/OS 1.9, testing on a z/OS 1.9 system resulted in
IEE945I UNRECOGNIZABLE OPTION 'EMPTYEXCPSEC' IN PARMLIB INPUT
IEE947I '/* DEFAULT RETRY */
EMPTYEXCPSEC(SUPPRESS)' SKIPPED DUE TO PREVIOUS ERROR
IBM has confirmed that the option only exists in z/OS 1.10, where
it is listed in the Release Guide as a 1.10 enhancement
The option prevents the creation of null segments in SMF 30 records
for SMS Candidate Volumes, and could significantly reduce the size
of your step and job termination records, especially if your site
has a default of (SYSDA,5) for every allocation!!
The MVS Initialization and Tuning Reference,
under the SMFPRMxx parmlib parameter definitions, EMPTYEXCPSEC:
SUPRESS specifies that the system suppress the creation of empty
EXCP sections. Empty sections can be the result of non-dataset
allocations, such as DD DUMMY, or for non-allocated candidate
volumes in the SMS storage group.
IV. DB2 Technical Notes.
1. APAR PK84187 corrects QWSAPSRB "Negative" value, but would be seen
in MXG as a very LARGE positive value. Due to timing conditions,
the value for QWSAPSRB_zIIP could be greater than the total SRB time
for the address space. This could result in an incorrect value for
QWSAPSRB.
PROBLEM CONCLUSION: The total SRB time is loaded after the zIIP
time. Thus the total time should exceed the total zIIP time. This
will result in correct values for QWSAPSRB.
V. IMS Technical Notes.
VI. SAS Technical Notes.
8. "ERROR 455-185: Data set was not specified on the DATA statement"
is usually caused by an incorrect _VARxxxx token in the DATA
DATA statement (e.g., spelling _VAR7072 as _VAR70720 which does
not exist, so SAS thinks that's just a variable name), or an
override that nulled out the _VARxxxx definition.
7. NEVER use FLOWOVER; if you MUST circumvent STOPOVER, then you MUST
use MISSOVER instead. As documented in the INSTALL member, if you
get an INPUT STATEMENT EXCEEDED RECORD LENGTH error condition, the
MXG job will stop at that point because the MXG default option on
the INFILE statement is STOPOVER (and the job ends with a USER 999
ABEND, because MXG also specifies option ERRORABEND).
Once you have sent the full log with the hex dump of the record to
support@mxg.com, so we can diagnose the cause (usually, due to a
new version of the product that created the record read with an old
version of MXG Software!), you can circumvent the error using:
MACRO STOPOVER MISSOVER %
%INCLUDE SOURCLIB.....
which will change the MXG STOPOVER default to MISSOVER (without you
having to EDIT the MXG code that has the "STOPOVER" text).
With MISSOVER, the variables MXG is trying to INPUT beyond the end
of the record will be set to a missing value, which may have other
unintended consequences, but the the next logical record in the
input file is read. But with FLOWOVER, the variables beyond the
end of this current logical record will be populated from the NEXT
logical record, and thus that next record will NEVER be examined
by MXG for its record ID, etc. Using FLOWOVER will GUARANTEE that
the next record (or records) will be SKIPPED.
6. "Why did MXG translate lower case text into upper case?" Actually,
it's the SAS system option CAPS/NOCAPS that determines, at INPUT,
whether lower case characters are unchanged (NOCAPS), or whether
are all translated to uppercase (CAPS), but CAPS/NOCAPS option is
NOT used for input from "external files" (i.e. essentially all MXG
fields are input from external files), so MXG preserves original
case.
Note that NOCAPS only applies to when the Data Set is created; once
you have created a mixed-case variable, you cannot use OPTIONS CAPS
to then print it in upper case.
-Specifically, the SAS help documentation of CAPS states:
CAPS
specifies that SAS translate lowercase characters to uppercase
in these types of input:
-data following CARDS, CARDS4, DATALINES, DATALINES4, and
PARMCARDS statements
-text enclosed in single or double quotation marks
-values in VALUE and INVALUE statements in the FORMAT procedure
-titles, footnotes, variable labels, and data set labels
-constant text in macro definitions
-values of macro variables
-parameter values passed to macros.
Note: Data read from external files and SAS data sets
are NOT translated to uppercase.
NOCAPS
specifies that lowercase characters that occur in the types of
input that are listed above are not translated to uppercase.
5. Character variables IMPORTed from Excel Spreadsheets with SAS V9.2
have very different lengths than when IMPORTed with SAS V9.1.3, but
V9.2 does warns you that it truncated a character field. With 9.1.3
all character variables are length $255 (even when the Excel field
is longer, and 9.1.3 did NOT warn that a variable was truncated).
With V9.2, most character variables have length/format/informat set
to the actual length of the Excel field. However, if the length is
greater than 255, the V9.2 character variable is truncated to $255,
with this WARNING message to alert you to that truncation:
Failed to scan text length or time type for column .
SAS Note 33257 documents how to change the Windows Registry
HKEY_LOCAL_MACHINE-SOFTWARE-Microsoft-Jet-4.0-Engines-Excel
key "TypeGuessRows" to a zero, which increases the number of Excel
rows (that will be read to determine the variable attributes) from
the default of 8 to 16384, which causes SAS V9.2 to use the maximum
field length as the character variable's length, eliminates the
truncation, and eliminates the warning message. May 28, 2009.
4. SAS Problem Note SN-035112 documents HotFix E9BC81, which corrects
the error discussed in March, 2009, in the text of Change 27.014,
in MXG 27.02, which applied the ATTRIB TRANSCODE to all MXG-built
character variables that contain HEX data (i.e., with $HEX format
or with an MXG-created FORMAT that maps character hex values).
The TRANSCODE=NO attribute is needed on all of these variable so
that, if you move that SAS dataset from EBCDIC to ASCII platforms,
those HEX-containing character values are NOT translated, since
TRANSCOD=YES is the SAS default, and that would corrupt the data.
Prior to the HotFix, the TRANSCODE attribute was NOT passed into a
dataset that was created by a SAS VIEW, but that is corrected now
by the HotFix.
3. Perhaps the FINAL note on MEMSIZE= parameter, for SAS on z/OS.
Ever since SAS V9 in 2000, I have STRONGLY recommended that you
NEVER have a MEMSIZE= parameter in your CONFIGxx members (MXG's or
SAS's CONFIG options.) SAS Technical support has also discouraged
the use of MEMSIZE=, as it can ONLY limit the virtual storage to
less virtual storage than is actually available to the address
space. but prior to SAS 9.2 it was not enforced. SAS 8 through
SAS 9.1.3 only reset MEMSIZE value if what is set is greater than
REGION- MEMLEAVE. In SAS 9.2, the logic is changes, and SAS now
will always reset the MEMSIZE= option to the (REGION-MEMLEAVE)
value. Note that this ONLY applies to SAS on z/OS platforms.
MEMSIZE can still needed on some unix and windows platforms.
2. SAS V9.2 on z/OS requires about 20MB more virtual storage for the
same job than SAS V9.1.3 required. For example, an enhanced
BUILDPDB with additional SMF records that ran in 72MB with 9.1.3
required 92MB when executed with SAS V9.2 Phase 1:
Data Program Total
9.1.3 73728 3308 77036 KB, SAS Total Memory
EXT SYS
73728 12344 86072 KB, IBM IEF374I, last two
9.2 92934 17426 109360 KB, Total Memory
94132 12276 106408 KB, IBM IEF374I, last two
Note that it is the "Data" or IEF374I "EXT" value that is limited
by the REGION on the JOB card; the "Program" or (second) SYS value
is the area below the 16MB line.
So there was right at 20MB virtual more needed by 9.2, but no
significant difference between the IEF374 and Total Memory.
1. A problem with SAS Connect Logon Scripts not working when z/OS was
upgraded to z/OS 1.10, in which the telnet TSO logon does not
a ready prompt, was due to an IBM error which is corrected by IBM
APAR OA26966 and PTF UA44635.
VI.A. WPS Technical Notes.
1. X
VII. CICS Technical Notes.
1. X
VIII. Windows NT Technical Notes.
IX. z/VM Technical Notes.
X. Email notes.
1.
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 27.yy (since MXG 26.26):
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 JCLINST9 for
SAS V9.1.3 or JCLINST8 for SAS V8.2.
XII. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
XIIV. 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 24.24 now in MXG 25.01:
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 27.yyy thru 27.001 are contained in member CHANGES.