COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER FIFTY-SEVEN
***********************NEWSLETTER FIFTY-SEVEN***************************
MXG NEWSLETTER NUMBER FIFTY-SEVEN, JANUARY, 18, 2011.
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,2011 MERRILL CONSULTANTS DALLAS TEXAS USA
I. The 2011 Annual Version MXG 28.28 is dated Jan 18, 2011.
All sites were EMAILED the ftp download instructions on Jan 18, 2011
The availability announcement was posted to MXG-L.
IF your email address is in our database AND your license is paid.
Otherwise, you can always use this form
http://www.mxg.com/Software_Download_Request
to request the ftp download instructions for the current version.
1. The current version is MXG 28.28, dated Jan 18, 2011.
See CHANGES member of MXG Source, or http://www.mxg.com/changes.
II. MXG Technical Notes
2. Removal of duplicate (SMF) records on z/OS - new ANALDUPE member.
500,000 SMF Records Processed
Several techniques for removal of duplicate SMF records on z/OS
are provided in the new ANALDUPE member. Two approaches are both
sort-based but are limited by requirements for MASSIVE amounts of
disk space or tape drives and require more CPU time than the two
elegant solutions created by MP Welch, who imagined a solution and
discovered that the SAS V9 MD5 (digital signature) function could
be used to create a unique Hash Value for each record, and the Hash
Values are then sorted (instead of the full record), to MASSIVELY
reduce the disk and CPU requirements. A one-pass solution using
a hash table works fine, but could rapidly exhaust virtual storage,
so the recommended solution creates the MD5 Hash Value, but then
uses a second step (freeing temp space of the first step) and a SAS
Format for the look up table to remove duplicates.
SORT ONE SORT TWO SORT THREE SORT FOUR
DISK BASED TAPE BASED MD5 HASH FUNCTION MD5 HASH
29 SORTWRK 7 TAPE DRIVES HASH TABLE SAS FORMAT
1000 CYL REQUIRED ONE PASS TWO STEP
CPU 41.40 SEC 49.80 SEC 16.2 SEC 16.2 SEC
SRB 3.60 SEC 6.60 SEC 0.6 SEC 1.2 SEC
EXT 31,780 K 31,776 K 43,848 K 50,284 K
SYS 11,860 K 11,864 K 11,884 K 12,060 K
EXCP 484,000 463,000 84,000 126,000
CONN 27.052 SEC 20.40 SEC 15.00 SEC 18.00 SEC
CLOCK 648.00 SEC 1380.00 SEC 18.00 SEC 42.00 SEC
Clearly it's much more efficient to hash a record and operate on a
shorter value than operating on the full record itself. In this
case, it works particularly well because there is no expectation
nor requirement to reorder the records. The Hash table filled 2GB
of memory at 3.5 million unique records. But the two pass hash will
handle hundreds of millions of records in most shops.
1. Processing Compressed CICS data on z/OS and on Windows.
An SMF file of 125,712 ID=110 records that created 267,899 CICSTRAN
transactions was 212 MB when IBM Compression was enabled, and was
970 MB when uncompressed by the IBM utility DFH$MOLS. The example
JCL for CICS decompression is in new DFH$MOLS member in MXG 28.06.
-On z/OS, three alternatives exist to process compressed CICS data:
a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
b. Use EXITCICS (SAS Infile Exit) to read COMPRESSED WITH EXIT.
c. Use MXG's internal SAS code to read COMPRESSED WITH INTERNAL.
Average 7 runs: Elapsed TCB SRB EXCP Connect Size
(min) (min) (min) (sec)
a. DFH$MOLS .8 .07 .00 53158 11.2 212/970
UNCOMPRESSED 2.0 .62 .01 47934 11.3 970 MB
total 2.8 .69 .01 101092 22.5
b. COMP WITH EXIT 2.3 .70 .00 14549 5.7 212 MB
c. INTERNAL SAS 22.4 9.88 .00 14554 5.7 212 MB
As previously reported, the INTERNAL SAS algorithm on z/OS is VERY
CPU intensive (and it takes a long time, too!). DFH$MOLS and read
UNCOMPRESSED is only slightly slower than reading COMPRESSED+EXIT,
but the uncompressed file needs nearly 5 times the disk space for
the (temporary) uncompressed file, and I/O activity with DFH$MOLS
(read compressed, write uncompressed, then read uncompressed) took
six times the EXCPs and four times the IOTM (Connect Time), so the
reading of the compressed file with the EXITCICS exit is best.
Note that executing on z/OS with the ftp access method to read
data from a different z/OS system CAN NOT use the EXITCICS code.
The INFILE exit and the ftp access method are mutually exclusive.
-Executing SAS on Windows/ASCII platforms (which includes using the
SAS ftp access method), SAS Infile Exits do not exist (and, if they
existed, the ASM code in EXITCICS couldn't execute on ASCII), so if
the SMF data file is downloaded and then processed, there are only
two ways to process compressed CICS data:
ORIGINAL EXAMPLE - SEE REVISED EXAMPLE IN NEWSLETTER SIXTY-ONE.
a. Use DFH$MOLS first to uncompress the file and read UNCOMPRESSED.
c. Use MXG's internal SAS algorithm to read COMPRESSED NO EXIT.
Elapsed User SYS Size
a. DFH$MOLS .4 .07 .00 212/970
ftp download 2.0 .04 .00 970 MB
UNCOMPRESSED .4 .23 .05 970 MB
total 2.8 .34 .05
c. ftp download 0.5 .01 .00 212 MB
INTERNAL SAS 3.8 2.71 .05 212 MB
total 4.3 2.75 .05
The internal algorithm on Windows is only ten times as CPU intensive
reading the compressed file, compared to reading uncompressed, but
a lot more disk space is needed for the uncompressed file.
Unfortunately, at this test site, we were not able to use the SAS
ftp access method on ASCII to read the uncompressed and compressed
files directly from z/OS, without download, for that comparison, but
prior tests using the access method to directly read z/OS files have
always been cheaper and faster than reading the downloaded files, so
I would expect that if you can tolerate the temporary disk space on
z/OS for the uncompressed file, using DFH$MOLS first would be best.
III. MVS, a/k/a z/OS, Technical Notes.
19. APAR OA34480 for z/OS 1.12 RMF III, ERB944I REPORT IS NOT AVAILABLE
REASON CODE 2, due to an incorrect check for "zFS inactive or
shutting down.
18. APAR OA34375 provides new function SMARTENDPOINT for IFASMFDL for
SMF Dumping from Logstreams, and a new keyword SMARTEPOVER so that
the amount of time that is added to the end date/time to calculate
the smart end point can be controlled by the user.
The SMF Manual is updated with these descriptions:
SMARTENDPOINT Specifies that processing of input records in
the logstream should discontinue once it has
been determined that records for all known SIDS
contain a date and time that is past the
IFASMFDL specified date and time plus the
specified SMARTEPOVER value.
The default behavior is that IFASMFDL continues
to read records all the way to the end of the
logstream.
This keyword only applies to the DUMP option.
SMARTEPOVER(hhmm) Specifies the amount of time that is added to the
end date and time to determine the SMARTENDPOINT
time.
The value specified by hhmm can range from zero
(0000) to two hours (0200). The value to specify
can be determined by taking the following
considerations into account:
- If no SIDs are being specified then this value
should be set to double the maximum MAXDORM
value of any image recording into the
logstream. This allows for the best results
from SID auto-detection.
- If all SIDs are being specified then this value
can be minimized down to zero.
- If only a single SID is being recorded into
this logstream (for example in a DASD-only
logstream) then this value can be minimized
down to zero.
The default for this value is two hours (0200).
This keyword only applies when SMARTENDPOINT is
specified.
17. z/OS 1.10 new parameter USEZOSV1R9RULES VSM has no impact on MXG.
It is a new optional control of allocation of GETMAINs, which MXG
never issues; that is SAS's job, and the default in DIAG is (YES)
which means no change from prior allocation scheme.
16. APAR PM16750 reports invalid BLKSIZE for SMF 42 subtype 6 after
using the IBM File Manager (FMNQSAM) DSU function with a procedure
containing REXX CHG_OUT function.
15. APAR OA34190 reports incorrect capacity data in SMF 30/89/90-34
when a dynamic processor speed change occurs.
14. APAR OW47653 lists a number of errors in RMF Post Processor Reports
13. APAR OA29314 makes no changes, but documents all of the things that
DO NOT happen with regard to wlm weight management and group
capacity, especially the (BAD) design that:
Group capacity will function together with IRD weight management
as long as the partitions in the group are not subject to
capping. No weight moves will take place for partitions as long
as the group is being capped.
12. APAR OA32067 corrects SMF 42 Subtype 16 with SMF2ADG2=14880, which
was greater than the LRECL of the SMF record. The text of the APAR
is interesting reading!
11. Duplicate JESNR for OMVS "jobs" in SMF 30 subtype 1,2,3,4 and 5.
MXG has always used SMF 30 variables READTIME JOB JESNR to identify
all of the records created by a "job", and JESNR was incremented
each time a new "job" was read in. Now, OMVS/USS processes can
reuse WLM initiators, which retain their JESNR, so the SMF records
for different OMVS jobs will have the same duplicated JESNR.
These OMVS jobs creates subtype 1/3/4/5 records. By using READTIME
along with JOB and JESNR, these job's SMF records can be grouped to
identify each job, but only accidentally because the closest values
of READTIMEs for these duplicate JESNR jobs are 0.09 seconds, and
READTIME's resolution is 0.01 seconds. At some point, OMVS jobs
will have identical READTIME and JESNR for different jobs, and we
will not be able to identify which SMF records belong to which job.
For the interval, step terminate, and job terminate SMF 30 records,
the OMVS Segment has exactly what we need, the OMVS Process ID,
to identify each OMVS "job"'s unique set of SMF data, but the SMF
30 subtype 1 job initiate record does not have an OMVS/USS Segment.
If IBM could add that segment to the job initiate record, or even
just the PID and perhaps PPID fields, then we would have the data
to satisfy our billing/chargeback/auditors that we can correctly
identify the resources and identity of each JOB in z/OS, a feature
that is unique to the z/OS platform!
But whether IBM does or does not add that identification data to
the SMF 30 subtype 1 records for OMVS tasks, I should be able to
solve the IBM exposure in MXG code, by adding the PID and PPID to
READTIME JOB JESNR to group the subtype 2/3/4/5 data, and I should
be able to detect and protect that unlikely instance in the
BUILDPDB logic when identical Subtype 1 records were created.
From IBM USS/OMVS support's explanation:
When a USS application issues a fork or spawn request (and a new
address space for the request is required), USS will go to pool of
WLM initiator address spaces to satisfy the fork/spawn request.
This is done to cut down on the overhead of address space
creation.
When a fork/spawn is called, the new process will run in the WLM
initiator address space if one is available in the WLM init pool.
If no idle WLM inits are available then a new one is created to
satisfy the request.
When the requesting process terminates, the WLM init is returned
to the pool of WLM inits. There it will wait for a new fork/spawn
request. If 30 continuous minutes pass and the init is not used
again, it is ended. But on a system that with significant USS
activity, it is more likely that it be re-used before the 30
(continuous) minutes elapses.
When a WLM init is re-used, the only thing it retains from the
previous job is its JOBID.
The following statements apply to WLM inits and USS:
- The WLM initiator will keep its JES jobid for its entire
lifespan (whether it is unused or in use).
- The JOBNAME associated with a WLM initiator will change when it
is 'in use'. When it is idle it will have a JOBNAME of BPXAS
- WLM initiators are eligible to be re-used when ANY process
issues a fork/spawn call.
When a new address space is created as part of a fork/spawn call,
USS will typically add a numeric suffix to differentiate the
parent process from the child process. It only does this IF the
parent process has a jobname of 7 characters or less. With a
jobname of 8 characters, USS will not add a numeric suffix to the
jobname.
With OMVS processes, each process has a Process ID (PID) and when
a child process is created, the PID of the Parent is recorded as
the PPID. You can use this Parent PID (PPID) to find the parent
that started this process.
A PPID of 1 is special as that is BPXOINIT. That means the
original parent has ended and the child is now an orphan.
The PPID is set to 1 which is BPXOINIT in this case.
The command D OMVS,A=ALL displays the PID and PPID for each
OMVS process so you can see how to chain back thru the PPID to
the parent process and if it has a PPID then back to that
parent and so on.
From IBM USS/OMVS support's explanation:
When a USS application issues a fork or spawn request (and a new
address space for the request is required), USS will go to pool of
WLM initiator address spaces to satisfy the fork/spawn request.
This is done to cut down on the overhead of address space
creation.
When a fork/spawn is called, the new process will run in the WLM
initiator address space if one is available in the WLM init pool.
If no idle WLM inits are available then a new one is created to
satisfy the request.
When the requesting process terminates, the WLM init is returned
to the pool of WLM inits. There it will wait for a new fork/spawn
request. If 30 continuous minutes pass and the init is not used
again, it is ended. But on a system that with significant USS
activity, it is more likely that it be re-used before the 30
(continuous) minutes elapses.
When a WLM init is re-used, the only thing it retains from the
previous job is its JOBID.
The following statements apply to WLM inits and USS:
- The WLM initiator will keep its JES jobid for its entire
lifespan (whether it is unused or in use).
- The JOBNAME associated with a WLM initiator will change when it
is 'in use'. When it is idle it will have a JOBNAME of BPXAS
- WLM initiators are eligible to be re-used when ANY process
issues a fork/spawn call.
When a new address space is created as part of a fork/spawn call,
USS will typically add a numeric suffix to differentiate the
parent process from the child process. It only does this IF the
parent process has a jobname of 7 characters or less. With a
jobname of 8 characters, USS will not add a numeric suffix to the
jobname.
With OMVS processes, each process has a Process ID (PID) and when
a child process is created, the PID of the Parent is recorded as
the PPID. You can use this Parent PID (PPID) to find the parent
that started this process.
A PPID of 1 is special as that is BPXOINIT. That means the
original parent has ended and the child is now an orphan.
The PPID is set to 1 which is BPXOINIT in this case.
The command D OMVS,A=ALL displays the PID and PPID for each
OMVS process so you can see how to chain back thru the PPID to
the parent process and if it has a PPID then back to that
parent and so on.
10. Impact of NO REGION versus REGION on JOB and STEP JCL statements.
(MXG Version 32.32, Jan 2015: BUILDPDB REGION=140M, 31.31 was 130M)
REGION REGION REGREQST in TYPE30_4
on JOB on STEP that the step
"CARD" step "CARD" received
none step 1 none 64M <- IEFUSI site limit no REGION
none step 1 150M 150M
0M step 1 none 10M <- IEFUSI site limit for 0M
150M step 1 none 150M
150M step 1 400M 150M
none step 1 10M 10M
none step 2 150M 150M
none step 3 400M 400M
none step 4 40M 40M
none step 5 64M 64M
9. APAR OA34261 corrects error in RMCTADJN (MXG R723NADJ) when running
at reduced speed, (e.g., due to Power Save Mode). In control block
IRARMCT, module IRAEVSSI may return incorrect values due to
rounding problems when the machine is running at reduced speed.
Instead of computing RMCTADJN from RMCTADJC proportionally to
the ratio of actual and nominal CPU capability, module IRAEVSSI
has been changed to calculate RMCTADJN similar to RMCTADJC by
applying the MP factors to the nominal CPU capability. D/T2817
8. APAR OA34576 documents that false contention values may differ
between SMF 74, SMF 42, and the D SMS,CFLS command results.
False Contention is recorded by XCF when it detects multiple
values hashing to same entry in a coupling facility lock
structure. When this is detected a counter is incremented
internally, and passed to RMF(SMF 74) via macro call. The
requestor of the lock will be notified of false contention via
the completion exit once the request has been satisfied. False
contention can occur on IXLLOCK, IXLALTER, or IXLRELEASE calls.
When a request hits contention, it becomes globally managed by
XCF. If it was incorrectly in contention and the global manager
runs the request it is marked in False Contention. Thus even
release requests can incur false contention counts.
But, in SMSVSAM's (SMF 42 and the D SMS command), only lock or
alter requests have their values recorded for false contention,
while Release requests are ignored.
SMF 74s may have higher false contention counts than SMF 42.
LOCAL FIX:
Use RMF and SMF 74's to keep track of false contention values.
False contention can occur during release request.
Currently, SMF42 only records lock and alter requests.
Due to skipping the release requests, SMF74 false contention
values are higher than the SMF42 records.
7. APAR OA33682 addresses Page Fixing Storage issues between 16M-2G.
6. APAR OA33527 reports Logical OUT and READY count in RMF 70s can be
wrong in z/OS 1.11.
5. APAR OA31895 corrects an error in RMF 73 records (although the
text only mentions corrections to the RMF IOQ Report) that when
Channel Paths are added dynamically, they are not recorded.
4. APAR OA30563 and z/OS 1.12 added the MAXEVENTINTRECS parameter in
SMFPRM to determine if type 30 and type 89 interval records will
be generated when the processor capacity is changed. This could
be important for billing issues, since the CPU times recorded are
potentially impacted by a capacity change. The default value of
MAXEVENTINTRECS is zero, so no event driven interval records are
created when capacity is changed. If non-zero, the value limits
the maximum number of event driven interval records allowed during
a regular scheduled interval. The capacity changes are recorded in
SMF70CCR and can be due to POWERSAVE or CYCLESTEERING or EXTERNAL.
3. APAR OA34007 reports SMF30 TIME_ON_ZIIP can be negative in subtype
3 records; this caused LARGE values in CPUZIPTM.
2. APAR OA33712 reports SMF64DAU and SMF64RLM were swapped, but now
are correct. OA33712 is an AE fix completion for OA33315.
1. APAR OA33841 corrects SMF 14/15 error; CLOSTIME/SMF30OPD was set
incorrectly to zero time if OPENTIME/SMF30OPE was midnight, i.e.
exactly zero time.
IV. DB2 Technical Notes.
2. How do you find out who deleted/dropped a DB2 database/table.
If you had the DDL Audit Trace enabled it is easy.
%ANALDB2F(PMACC01=NO,PMACC02=NO,PMSTA01=NO,
PMAUD02=YES,AUDIT=DDL);
will print those events.
But even if trace is not enabled, it still can be done:
Looking at the TYPE6156 records, selecting the zOS dataset name:
PROC PRINT DATA=TYPE6156 (WHERE=(ENTRNAME='whatever.yours'));
VARIABLES SMFTIME JOB ENTRNAME ACTION;
you can find the time when the zOS datasets were deleted, but they
will show the job name of the DB2*DBM1 address space as the user.
Then looking at DB2ACCT records in the same time period with
QXDRPDB OR QXDRPTA OR QXDRPIC GT 0:
PROC PRINT DATA=DB2ACCT.DB2ACCT (where=
( (qxdrpdb gt 0 or qxdrpta gt 0 or qxdrpic gt 0)
and
('18NOV2010:12:30:45.99'DT LE QWHSSTCK LE
'18NOV2010:12:40:55.11'DT) ));
VARIABLES QWHCAID QWACBSC QWACESC QXDRPDB QXDRPTA QXDRPIX;
will show the RACFUSER that did the dirty deed in QWHCAID;
1. APAR PM17542. DD Segments NOT WRITTEN as part of DB2 Performance
Improvements in z/OS 1.12.
DB2 exploits z/OS 1.12 new allocation functions to improve the
performance of allocation, deallocation, open, and close of the
data sets in DB2 page sets. It will improve the performance when
opening a large number of data sets concurrently, and shutdown
time, especially for DB2 users with high DSMAX. Significant
reduction in elapsed time has been observed by DB2 and z/OS
performance test. Allocation will manage DB2 data set ENQs in
memory, and SUPPRESS CERTAIN DB2 DD-LEVEL ACCOUNTING IN THE SMF
records to save significant overhead.
ATTENTION to DB2 DBA and system programmers:
To make the APAR effective:
- Update the ALLOCxx parmlib member to set
SYSTEM MEMDSENQMGMT(ENABLE).
- or issue command SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE.
Updating the ALLOCxx parmlib is strongly recommended as it
remains effective across IPLs. If the SETALLOC command is
used to enable SYSTEM MEMDSENQMGMT, a DB2 restart is required
to make the change effective.
"Suppress CERTAIN DB2 DD-LEVEL ACCOUNTING" means that DB2 with
this APAR sets the new S99DASUP bit, described in MVS Programming
Authorized Assembler Services Guide:
S99DASUP Used by authorized programs to suppress the
DD-level accounting. Setting this bit can affect the SMF
data created for the following:
The EXCP section of SMF Record Type 30.
SMF Record Type 40.
SMF Record Type 14 for the fields SMF14NTR and SMF14NER.
This bit is only recommended for programs allocating VSAM data
sets with generated DD names, or when the exploiting program
has established that the usefulness of the SMF data is less
than the benefit to system performance. Because the data is
used by an installation and suppressed by the exploiting
program, an external switch controlling the program's use of
this bit is strongly recommended.
But the Services Guide is unclear (are ALL DD Segments suppressed
or is S99DASUP set for individual DD's), but Bob Rogers' SHARE
presentation added information:
Suppress DD accounting (in SMF 30 records)
Suppresses creation of SMF Type 30 EXCP section data on
a per-DD basis
Reduces CPU in Allocation and Unallocation processes
Requested by program with S99DASUP flag on DynAlloc
S99DASUP is set ONLY for Selected Dynamically Allocated DD's.
But, thanks to Merrill Consultant's IBM "TLC" Technical liaison
Consultant in Poughkeepsie, who contacted the author of the APAR,
she has confirmed that the APAR suppresses all Database Dataset
Dynamic Allocation Requests in the DBM1 Address Space, so when
enabled, SMF 30 records for DBM1 will not contain DD segments
for those allocations.
V. IMS Technical Notes.
1.
VI. SAS Technical Notes.
2. Using SAS Enterprise Guide 4.2 or earlier with ANALDB2R, the
standard SAS report can fail to open when there exist unprintable
characters in DB2 data. You may see some of the report if you
invoke HTML output, but in that HTML report you may see reams of
blank pages. SAS Support said that EG 4.22 had added new data
cleansing functionality that would resolve the errors, adding:
To use this functionality, you must first bring the data down to
your PC, then use the "file > import" menu option in EG. After
importing the data, run your code against the newly imported data.
See also SAS Note http://support.sas.com/kb/32/133.html.
There are DB2 variables with mixed valid EBCDIC and HEX values.
Wherever possible, MXG changes '00'x in EBCDIC text fields to a
blank, because IBM initialized text fields with '00'x. Or, MXG
formats all-hex variables with $HEX format so they are printable.
But mixed fields can start with a useful EBCDIC text (netname)
followed by a TODSTAMP in hex aren't formatted $HEX because that
would make the useful EBCDIC name unreadable (except to certain
hex'd sysprogs!).
See member UTILNPRT in MXG 28.08 to identify all variables in all
SAS datasets that have non-printable character values.
1. z/OS SAS Version 9 USER ABEND U0998-16D is actually ABEND 16D RC 8
and only occurred on a system where the SAS write-SMF-record exit
was installed, but the SAS Load Library module was not copied over
when a SYSRES was cloned.
VI.A. WPS Technical Notes.
1. X
VII. CICS Technical Notes.
1.
VIII. Windows NT Technical Notes.
1. Using MicroSoft Security Essential, MSE, causes various errors when
the MXG QA job is run, never at the same place in the job:
ERROR: User does not have appropriate authorization level for
library WORK.
Followed, sometimes, with a second error:
FATAL: Code generation error detected during BY compare
generation.
ERROR: File Deletion Failed For MXGSUM1 (after prior successes).
ERROR: An I/O error has occurred on file WORK._tf6737.UTILITY.
ERROR: An I/O error has occurred on file WORK.OPTVAR.DATA.
ERROR: Rename of temporary member for WORK.OPTVAR.DATA failed.
ERROR: Rename of temporary member for WORK.TMVSCH.DATA failed.
Only by disabling MSE Settings to:
-exclude the SAS.EXE process
-exclude files *.sas7bdat and to
-exclude the d:\qa\ directory, where all output was written, AND
-exclude the d:\sastemp\ "WORK" directory.
were both errors were eliminated.
However, that "does not have appropriate authorization level" error
can also occur, especially with Windows 7, without MSE, when your
program is attempting to write to the root directory or to the
Program Files directory, especially when not executing your program
"as administrator".
This issue had been open with SAS Institute and Microsoft support
since February, 2010; finally, in October, a new MicroSoft "Senior
Escalation Engineer" attempted resolution, providing instructions
to install several MicroSoft diagnostics tools that either failed to
initialize or failed to capture the event data, including runs with
TTTracer that generated over 85 GigaBytes of trace (how do you send
a file that big??) that still did not capture anything of use to MS.
Then, out of the blue, in November, 2010, fourteen updates were auto
installed by MicroSoft autoupdate, and the error went away. The MS
escalation engineer was unable to identify which update corrected.
Moral: Disable MSE for SAS.
Update: May, 2011.
RUN SAS AS ADMINISTRATOR.
Starting with SP1 for Windows 7, writing to any sub-directory under
c:\PROGRAM FILES is restricted, with NOT AUTHORIZED error messages,
unless SAS is RUN AS ADMINISTRATOR. This is where the default SAS
root directory is located, which is where xxx.log and xxx.lst files
are created by default.
A Windows 7 system that does NOT have SP1 and its recent updates
does not restrict saving/writing into the SAS root directory here.
Update: May, 2011.
Disable Microsoft Security Essentials, again.
After autoinstall of SP1 for Windows 7, the above MSE error has
reoccurred, and in some cases, even using the above settings was
not sufficient; MSE real-time monitoring had to be turned off for
the full MXG QA job to complete. These errors occur at different
times and places in the 33 minute QA job, and always involves a
file in the WORK library that is being written to, or is being
deleted (MXGSUM1) or is being renamed (OPTVAR), in the QA run with
zero observations.
These errors with MSE and authorization are on 64 bit Windows 7
Ultimate on 64 bit hardware with 64 bit SAS, on two separate
machines; on two more machines that do NOT have SP1, these errors
do NOT occur.
IX. z/VM Technical Notes.
1.
X. Email notes.
1. X
XI. Incompatibilities and Installation of MXG vv.yy.
1. Incompatibilities introduced in MXG 28.28 (since MXG 27.27):
See CHANGES.
2. Installation and re-installation procedures are described in detail
in member INSTALL (separate sections for each platform, z/OS, WIN,
or *nix), with examples of common Errors/Warnings messages a new MXG
user might encounter, and in member JCLINSTT for SAS V9.2 or member
JCLINSTW for WPS. INSTALL also shows how to read SMF data on PCs/nix
using the FTP ACCESS METHOD.
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 27.27 now in MXG 28.28:
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 28.yyy thru 28.001 are contained in member CHANGES.