One downside for new MICS clients, the MICS software install will also involve applying numerous fix / enhancement PTFs out-of-the-box in order to be at a “current” maintenance level — something that’s not obvious in the MICS software install checklists and announcements, though CA is considering documentation improvements in this awareness area.

MICS administrators are strongly encouraged to use CA Support Online and periodically check PROBLEM and SOLUTION records for licensed MICS components, as a proactive problem identification/diagnosis methodology.  The objective here is to avoid MICS database corruption problems that don’t necessarily manifest as an ABEND condition or something obvious to get the MICS administrator’s attention.  Also, one may find that CA is also delivering technology support and MICS enhancements as interim PTF maintenance – something worthwhile to consider as well as problem avoidance perspective.

• Added BoxScore CPU table support for IBM’s July 2010 LSPR announcement (zEnterprise 196 processors), to include new TABLE= and WORKLOAD= parameter values, based on IBM’s LSPR changes.
• New BoxScore exit (when using BOXSCORE=BATCH)  for improved matched-set identification/correlation by concatenating a candidate’s PROC-Step identification to existing Job-Step data-value.
• Added BMC MainView for IMS direct input support.
• Additional maintenance and fixes.

 Also, Watson & Walker customers receive updated CPU Charts (Excel document format) that includes the IBM z196 processor technology.

 You can contact Watson & Walker’s BoxScore support at boxscore@watsonwalker.com  for more information.

Link below to IBM APAR; confirmed first by an MXG client with APAR info (thanks to Barry Merrill’s support team); also another MICS / MXG client we support, where both MICS and MXG database corruption is reported. For a particular MICS client, we saw the condition also with SMF30_TIME_ON_IFA, though this field is not mentioned explicitly in the IBM APAR description / text. I expect it has to do with zAAP / zIIP CP combination and the behavior difference with ZAAPZIIP=YES (default starting with z/OS 1.11) and having no zAAP CP engines.

Scott Barry
SBBWorks, Inc.

OA34007: NEGATIVE VALUES CAN BE SEEN FOR SMF30_TIME_ON_ZIIP IN TYPE30 SUBTYPE 3 RECORDS

Author/Presenter: Scott Barry, Principal Consultant, SBBWorks, Inc.

Click here for a copy of this presentation in PDF-format (no registration required).

Author/Presenter: Scott Barry, Principal Consultant, SBBWorks, Inc.

Click here for a copy of this presentation in PDF-format (no registration required).

Author/Presenter: Scott Barry, Principal Consultant, SBBWorks, Inc.

Click here for a copy of this presentation in PDF-format (no registration required).

Allocate an unused “fileref” SYSOUT file in your SAS or WPS session – and, from the JES-assigned temporary dataset name, you can extract the JES job number for your batch job or TSO session (it is the third dataset qualifier, generated by JES2), as demonstrated below using a SAS macro language technique:

%* Allocate a SYSOUT-file to an unused external fileref - MYSYSOUT ;
FILENAME MYSYSOUT SYSOUT=*;
%* Using SAS CALL function PATHNAME, obtain the JES-assigned dataset ;
%LET MYPATH = %SYSFUNC(PATHNAME(MYSYSOUT));
%* Extract the JES job number - it is the third dataset node ;
%LET MYJESNUM = %SYSFUNC(SCAN(&MYPATH,3,%STR(.)));
%* Now display the information on the log - available to use ;
%PUT MY JES JOB NUMBER IS: &MYJESNUM;
%* free the SYSOUT allocation ;
FILENAME MYSYSOUT CLEAR;


Another approach is to use the SAS PEEK function and navigate through chained z/OS control blocks to get to the same result.

Also, you will find the JES job-name information is captured as a SAS or WPS automatic variable name &SYSJOBID — these “automatic” system macro variables can be displayed with the %PUT command below and can be used in your program, as needed:


%PUT _AUTOMATIC_;


Visit the DFSORT Downloads homepage for details on what’s currently available.

Below is a DATA step example where a report routine called UIDMMNR1, only to be executed on the 2nd calendar date in order to generate some “early” monthly reports, in advance of the MICS MONTHLY process execution. And if your SMF / log data capture is more accurate such that you can run monthly reports on the AM of the 1st calendar date, the code could be changed to test and execute on the 1st.

You could add this logic to the prefix.MICS.USER.SOURCE(DYUSER) member and it will be executed in DAY500 of the DAILY job.

For the record, this technical approach presumes that you will always run the DAILY job on the 2nd calendar date and since you will be running your report code UIDMMNR1 prior to MONTHLY, you will want to use both the “00″ and “01″ cycles as shown in the sample report code excerpt.

Sample DAY500/DYUSER code to execute a SAS program on the 2nd calendar date:

* TEST IF IDMS MONTHLY REPORTING SHOULD BE EXECUTED ON 2ND OF MONTH.;
DATA _NULL_;
IF DAY("&SYSDATE9"D) = 2 THEN DO;
* COME HERE TO EXECUTE MONTHLY IDMS REPORTING CODE IN DAILY/DAY500. ;
CALL EXECUTE('%INCLUDE SOURCE(UIDMMNR1);');
END;
STOP;
RUN;


SAS program excerpt for UIDMMNR1 using SET with %MFILE macro for MICS cycle input selection:

DATA IDMSUA;
SET %MFILE(F=SUA01-00,TS=MONTHS);
* SUBSET INPUT IDMSUA OBSERVATIONS AND SELECT ONLY PRIOR MONTH. ;
WHERE INTNX('MONTH',DATEPART(ENDTS),0) = INTNX('MONTH',TODAY(),-1);
* REMAINING SAS PROGRAM FOLLOWS THIS COMMENT. ;