.RU
Карта сайта

* copyright (C) 1984-2012 merrill consultants dallas texas usa * - старонка 36


Thanks to Michael Oujesky, Bank of America, USA.

Change 29.009 VMXGUOW fails if //CICSTRAN or //DB2ACCT is on tape, with

VMXGUOW MXG 28.06 thru MXG 28.28, but the error is circumvented

Jan 24, 2011 if you add LIBNAME statements to tell MXG it's on tape:

Jan 31, 2011 //SYSIN DD *

LIBNAME CICSTRAN V9SEQ;

LIBHAME DB2ACCT V9SEQ;

%LET PCICTRN=CICSTRAN;

%LET PDB2ACC=DB2ACCT;

%LET MACKEEP= MACRO _NOOBS % MACRO _YESOBS %

%INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);

-Prior to Change 28.204, VMXGUOW only tested existence of

the _Ldddddd dataset token, but in 28.204, a test for the

existence of that LIBNAME was added (so we could tell you

what you did wrong when you didn't have one). But under

z/OS, if the LIBNAME had not been referenced in this SAS

session, it is not in DICTIONARY, and MXG fell thru to

use WORK for the LIBNAME, but as WORK.CICSTRAN did not

exist (your data was in CICSTRAN.CICSTRAN on tape), MXG

failed with NOT FOUND BY VARIABLES and MXGWARNS.

-In this revision, the EXTFILES table is scanned and if

the &PCICTRN "ddname" is found, _LCICTRN is set to

CICSTRAN. Likewise, _LDB2ACC and _LMONTSK are set to the

normal defaults if not found.

-In all cases, if the LIBNAME pointed to does not exist,

VMXGUOW will still fail.

Thanks to Hugo L. Michel, Prince Georges County, MD, USA.

Change 29.008 -WEEKBLD/MONTHBLD: to eliminate NOTSORTED errors, MXGNOBY

VMXGINIT is now specified in VMXGINIT so there will be no testing

BLDSMPDB of the sort order of the input, and no NOTSORTED error.

Feb 3, 2011 -BLDSMPDB: SORTEDBY=NO is now specified as the default.

(Also, LIBNAME=WEEK1 was in error and changed to WEEK.)

-Previously, you had to define MXGNOBY with this statement

%LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;

in your //SYSIN DD, to disable the sort testing and the

interleave of input observation in sort order. That will

still work fine, but no longer needed with this change.

Although I can't see a reason why you would want to go

back to the NOTSORTED exposure, you can redefine macro

MXGNOBY as null with this syntax to reinstate sorting:

%LET MXGNOBY= ;

-The exposure occurs when MXG has to change the sort order

of a dataset when it is built, and that dataset with new

sort order is combined in WEEKBLD/MONTHBLD with datasets

that were created with the previous sort order.

-The only reason MXG ever changes the sort order is when

the initial order was insufficient to remove duplicates

with the NODUP option of PROC SORT. Errors can occur if

your old WEEKBLD has the old sort order (TYPE72DL in MXG

28.28), or if MXG failed to update the new order in its

WEEKBLD/MONTHBLD member (DB2STATS in MXG 28.28)

-MXG does not require the WEEKLY and MONTHLY datasets to

be sorted; no report programs should ever expect ordered

data as there is no way to guarantee someone else didn't

sort the dataset after it was first created.

-Building sorted output is only a possible performance

benefit: if subsequent programs happen to use the same

order in their PROC SORT, SAS is smart enough to bypass

the unneeded sort, and that was the original purpose for

creating WEEKBLD/MONTHBLD in sort order. And, because

the "daily" datasets were already sorted, the WEEKBLD and

MONTHBLD programs preserved that sort order with a BY

statement, without re-sorting.

-However, it turns out that disabling the sort order test

and building the output as the concatenation of the input

datasets instead of interleaving observations to preserve

the sort order is a REAL performance benefit: benchmarks

show a reduction of about 12% of the CPU time with the

MXGNOBY enabled.

Change 29.007 Documentation if CICSTRAN variables are EXCLUDEd/DROPPED.

ASUMUOW This isn't new behavior, and has been in place long time.

ASUMCICX For ASUMUOW to execute, these BY-VARIABLES are REQUIRED:

Jan 21, 2011 TRANNAME STRTTIME ENDTIME NETSNAME

UOWID UOWIDCHR UOWTIME

There is no circumvention; ASUMUOW fails without them.

These KEPT variables from CICSTRAN aren't required for

execution, but MXGWARN messages will be printed if

these variables do not exist in your CICSTRAN:

APPLID USER LUNAME SYSTEM TERMINAL USERCHAR

This list is defined in MACRO _KUOWIDC, which you can

redefine to keep only your variables to eliminate the

MXGWARN messages.

For ASUMCICX to execute, these BY-VARIABLES are REQUIRED:

APPLID OPERATOR USER TERMINAL STRTTIME TRANNAME

SYSTEM SHIFT

If any do not exist, ASUMCICX fails.

This list is defined in MACRO _BSUCICS and some can be

removed, but you could end up with useless output if,

for example, you didn't keep STRTTIME.

If some of these variables are not kept, you can redefine

_KUOWIDC and _BSUCICS to list only those that exist.

For example, these variables are removed from CICSTRAN:

USER OPERATOR TERMINAL USERCHAR

Then you would add the MACRO _KUOWIDC and _BSUCICS into

the %LET MACKEEP= in your current JOB:

//UOWCICX EXEC MXGSAS92

//CICSTRAN DD DSN=YOUR.CICSTRAN,DISP=SHR

//DB2ACCT DD DSN=YOUR.DB2ACCT,DISP=SHR

//PDB DD DSN=NEW.ASUMUOW,DISP=(,CATLG),...

//SYSIN DD *

%LET PCICTRN=CICSTRAN;

%LET PDB2ACC=DB2ACCT;

%LET MACKEEP=

MACRO _KUOWIDC APPLID LUNAME SYSTEM %

MACRO _BSUCICS APPLID STRTTIME TRANNAME SHIFT %

MACRO _NOOBS % MACRO _YESOBS %

;

%INCLUDE SOURCLIB(ASUMUOW);

%INCLUDE SOURCLIB(ASUMCICX);

Thanks to Hugo L. Michel, Prince Georges County, MD, USA.

Change 29.006 Variables DVRTBV01-DVRTBV32, Returned Borrowed Volumes,

VMACBVIR were incorrectly formatted $MGBVIPT but $MGBVIPO is the

Jan 21, 2011 correct format to decode when printed.

Thanks to Doug Boettcher, Atco I-Tek, CANADA.

Change 29.005 Documentation of INTERVAL= change in default RMFINTRV.

RMFINTRV INTERVAL=DETAIL in MXG 27.27 became INTERVAL=QTRHOUR in

Jan 19, 2011 MXG 28.01, Change 28.046, in MXG default RMFINTRV member,

but that was not documented, carelessly, but also because

I didn't think anyone used MXG's default RMFINTRV member.

I expected each site to have their own tailored RMFINTRV

with both INTERVAL= and WORKnn= (maps Service Classes to

WORKLOADs) definitions, and thus my default would only be

used by new sites, and only before they read the INSTALL

instructions to tailor those RMFINTRV definitions, so I

could change the interval with impunity. Well, almost!

I replaced DETAIL with QTRHOUR because DETAIL creates an

observation for every RMF start, including those short

interval at each IPL that have VERY high CPU Busy and are

outliers on normal interval graphs and reports, whereas

INTERVAL=QTRHOUR creates equal intervals and smooth data.

But, with DETAIL, you get an observation with the exact

STARTIME of each interval, and if SYNC59 is in use, those

startimes were of 59:00 14:00 29:00 44:00. But SYNC59=YES

is the default for Real Intervals, so changing from the

INTERVAL=DETAIL to INTERVAL=QTRHOUR, for SYNC59 sites,

changed their STARTIMEs to 00: 15: 30: & 45: when they

"dropped-in" MXG 28.28 after MXG 27.27. Tailoring their

RMFINTRV with INTERVAL=DETAIL restored original values.

Change 29.004 ISO format dates with 19990000 for "never expire" are now

VMACEDGR detected and the DATE variable is set missing.

Jan 20, 2011

Thanks to Harald Seifert, Huk-Coburg, GERMANY.

Change 29.003 If you have ancient JCL with //SASAUTOS DD DSN=&&NULLPDS,

VMXGGETM MXG 28.28 UTILGETM ran much longer (10x) because it did

Jan 19, 2011 not read the (new in 28.28) %DATATYP macro function from

the SAS-provided AUTOCALL PDS. The ERROR message didn't

stop the read of the large SMF file, but the message

wasn't the expected APPARENT MACRO %DATATYPE NOT FOUND.

Because of the way %DATATYP was used, the error was:

ERROR: Character operand was found in the %EVAL function

... where %DATATYP(&NRECORD) NE NUMERIC ....

The JCL &&NULLPDS token was removed many MXG versions ago

for unrelated problems and lack of need, but I was not

aware that the &NULLPDS stopped the AUTOCALL search, but

only recent MXG versions actually use macros (%TRIM) from

that library. But the %DATATYP was added ONLY to detect

that you had mistyped an alphabetic text for NRECORD=,

and only in your own %VMXGGETM invocation (UTILGETM has

NRECORD=50), so we shot ourselves in the foot adding it.

And ONLY to prevent a less-than-clear warning message.

DATATYP is no longer used; the logic is in a data step.

Change 29.002 -APAR OA31615 was NOT supported by MXG 28.28 as claimed.

VMAC89 That APAR will cause many INVALID SMF89CTZ log messages,

Jan 20, 2011 but the job does NOT ABEND (unless the log fills!).

Jan 21, 2011 -MXG detection of records with Invalid Intersect Segments

Feb 3, 2011 had no limit on the number of Invalid Record messages,

but also falsely detected some valid records as invalid.

The MXG test was corrected so only true Invalid segments

are detected, and only the first 3 are printed on log.

-But, feedback from IBM has clarified the new intersect

data in new TYPE89I dataset, and MXG was wrong to carry

the PRODxxxx variables from the Usage Data Section; those

variables were removed from the KEEP= list, and from the

Sort Order in MACRO _BTY89I, which now uses the CPO-CPI

and IPO-IPI variables to order and remove duplicates, and

is sequenced SMF89UST SMF89IST within those variables.

-Unrelated to the APAR, these variables in subtype 2 have

never been populated and are no longer kept in TYPE892:

MACHTIME SMF89UET SMF89UST

Thanks to Jim Poletti, Edward D. Jones, USA.

Thanks to Jeana M. Bechtel, Edward D. Jones, USA.

Thanks to Al Sherkow, I/S Management Strategies, Ltd.

Thanks to Scott Barry, SBBWorks Inc, USA.

Thanks to Harald Seifert, Huk-Coburg, GERMANY.

Change 29.001 Support for SMF 111 IPIC now creates obs in TY111CXI.

VMAC111 No observations were created because MXG incorrectly had

Jan 19, 2011 them to be in CTGRECID=2 when they are CTGRECID=7, so the

Jan 24, 2011 code for IPIC was relocated to that correct subtype, and

obs are now created.

-Warning added when a new subtype is detected.

-Change 28.329 for SMF 111 was NOT included in 28.28 as

originally claimed.

Thanks to Jim Poletti, Edward D. Jones, USA.

Thanks to Jeana M. Bechtel, Edward D. Jones, USA.

Thanks to Gordon E. Griffith, Edward D. Jones, USA.

LASTCHANGE: Version 29.

=========================member=CHANGE28================================

/* COPYRIGHT (C) 1984-2011 MERRILL CONSULTANTS DALLAS TEXAS USA */

Annual MXG Version 28.28 is dated Jan 18, 2011, thru Change 28.331.

MXG Newsletter FIFTY-SEVEN is dated Jan 18, 2011.

Prelim MXG Version 28.28 was dated Jan 12, 2011, thru Change 28.326.

Interim MXG Version 28.09 was dated Jan 11, 2011, thru Change 28.325.

MXG Version 28.08 was dated Dec 13, 2010, thru Change 28.297.

MXG Version 28.07 was dated Nov 5, 2010, thru Change 28.265.

MXG Version 28.06 was dated Oct 7, 2010, thru Change 28.239.

MXG Version 28.05 was dated Aug 18, 2010, thru Change 28.187.

MXG Newsletter FIFTY-SIX was dated Aug 18, 2010.

First MXG Version 28.05 was dated Aug 17, 2010, thru Change 28.186.

MXG Version 28.04 was dated Jul 5, 2010, thru Change 28.152.

MXG Version 28.03 was dated May 25, 2010, thru Change 28.114.

MXG Version 28.02 was dated Apr 14, 2010, thru Change 28.081.

MXG Version 28.01 was dated Mar 9, 2010, thru Change 28.047.

MXG Version 27.27 was dated Jan 20, 2010, thru Change 27.361.

MXG Version 27.27 was the 2010 "Annual Version".

MXG Newsletter FIFTY-FIVE was dated Jan 20, 2010.

Instructions for ftp download can be requested by using this form:

http://www.mxg.com/Software_Download_Request

Your download instructions will be sent via return email.

Contents of member CHANGES:

I. Current MXG Software Version 28.28 is available upon request.

II. SAS Version requirement information.

III. WPS Version requirement information.

IV. MXG Version Required for Hardware, Operating System Release, etc.

V. Incompatibilities and Installation of MXG 28.28.

VI. Online Documentation of MXG Software.

VII. Changes Log

Member NEWSLTRS contains Technical Notes, especially APARs of interest

and is updated with new notes frequently. All Newsletters are online

at http://www.mxg.com in the "Newsletters" frame.

Member CHANGES contains the changes made in the current MXG version.

Member CHANGESS contains all changes that have ever been made to MXG.

All MXG changes are also online at http://www.mxg.com, in "Changes".

=======================================================================

I. MXG Version 28.28 dated Jan 18, 2011, thru Change 28.331.

Major enhancements added in MXG 28.28, dated Jan 18, 2011

TYPEDB2 28.326 Invalid DB2 V10 Distributed Header protected in MXG.

There will be an IBM APAR, but this change is needed

to avoid the ABEND with earlier MXG versions, so, now

MXG 28.28 IS NOW REQUIRED FOR DB2 V10.1

to ensure your daily jobs doesn't ABEND.

APAR PM32425 has been opened, no PTF as of Feb 21.

WEEKBLD 28.324 Weekly exposure to DATASET TYPE72DL NOT SORTED.

MONTHBLD 28.324 Monthly exposure to DATASET TYPE72DL NOT SORTED.

BLDSMPDB 28.324 BLDSMPDB exposure to DATASET TYPE72DL NOT SORTED.

-If you have tailored those members and TYPE72DL is

built, you need to EDIT those members per the text

in that Change to avoid the possible ABEND of your

weekly or monthly build jobs.

EXITCICS 28.298 EXITCICS decompresses SMF 100,101,102,110 and 112.

MXG enhanced INFILE exit for CICS now supports DB2.
2014-07-19 18:44
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • Контрольная работа
  • © sanaalar.ru
    Образовательные документы для студентов.