Not to my knowledge

From: MXG Software LIST <[log in to unmask]> On Behalf Of Tim Hare
Sent: Sunday, September 7, 2025 8:05 PM
To: [log in to unmask]
Subject: [MXG-L] Tape statistics

This is just a question of curiosity, really, since I'm retired and probably
not going to come out of retirement (but you never know). Many moons ago I
wrote a SHARE requirement and IBM RFE to ask that better tape mount
information be collected since most tape or virtual tape devices were now
computers in their own right with peripherals attached. My thinking was
based on virtual tape devices at the time, of 

[More ...]

There is no VTS-subsystem "event" data recorded to SMF, that I am aware of.

Otherwise, for IBM HYDRA/TS7700 technology, there is the non-SMF BVIR (Bulk Volume Information Retrieval) "interval / 15-min" data source which provides all sorts of virtual/physical tape mount activity.

MXG provides very-fine BVIR data source support. Useful links below: 

[More ...]

While I've never used it, IBM does provide the DFSMS Volume Mount Analyzer
if weren't aware:

https://www.ibm.com/docs/en/zos/3.1.0?topic=analyzer-understanding-volume-mount

*Steve Estle303-604-0925 (Office)303-817-9954 (Mobile)*

On Mon, Sep 8, 2025 at 10:02 AM Scott Barry <[log in to unmask]> wrote:

> There is no VTS-subsystem “event” data recorded to SMF, that I am aware
> of.
>
>
>
> Otherwise, for IBM HYDRA/TS7700 technology, there is the non-SMF BVIR
> (Bulk Volume Information Retrieval) “interval / 15-min” data source which
> provides all sorts of virtual/physical tape mount activity.
>
>
>
> MXG provides very-fine BVIR data source support. Useful links below:
>
>
>
> 

[More ...]

I'd have to dig up the RFE but I believe my suggested solution was to add
the information in an extension of SMF 21, which is written when a tape
volume is demounted.

I'm betting by now that the number of shops with VTS backed by physical tape
is getting very small.

Tim Hare

Hare Systems Support (retired) 

[More ...]

The service unit variables in SMFINTRV come directly from the SMF 30 interval records, subtype 2 and 3

The original values were
INPUT @OFFPERF
SERVUNIT &PIB.4. /*SMF30SRV*/
CPUUNITS &PIB.4. /*SMF30CPU*/
SRBUNITS &PIB.4. /*SMF30SRB*/
IOUNITS &PIB.4. /*SMF30IO */
MSOUNITS &PIB.4. /*SMF30MSO*/

but they were only 4-byte fields and the SMF manual noted
they could wrap and added 8-byte variables:

SM30SRVL &PIB.8. /*TOTAL*SERVICE*UNITS*/
SM30CSUL &PIB.8. /*CPU*SERVICE*UNITS*/
SM30SRBL &PIB.8. /*SRB*SERVICE*UNITS*/
SM30IOL &PIB.8. /*I/O*SERVICE*UNITS*/
SM30MSOL &PIB.8. /*MSO*SERVICE*UNITS*/ 

[More ...]

Member SENDDATA has examples of sending data; the basic problem is that whenever
any ftp program sees the input program is RECFM=V/VB/VBS, ftp strips the BDW and
RDW and you have an unreadable file.

The solution is to specify RECFM=U on the input to send to your ftp server,
like this example to send data to MXG support:: 

[More ...]

I would suggest overriding the data set attributes for the transfer
to RECFM=U, LRECL-32760, and BLKSIZE=32760.

Michael

At 04:02 AM 6/25/2025, Peter Elliott wrote:

>Hi MXG folk,
>
>We are looking at using sftp to transfer our SMF files to our SAS
>ITRM MXG server to replace the current proprietary software in use currently.
>
>This was tested a while ago by our sysprogs and they found sftp was
>dropping the span bytes from the VBS records and not fix was found.
>
>Is anyone using sftp to successfully transfer SMF data from z/os to Linux?
>
>Is there a 

[More ...]

One fundamental challenge is that sftp cannot read a traditional MVS dataset directly, so it (your SMF data to be processed) must first be copied (using TSO-batch and OCOPY with BINARY) to a USS/OMVS zFS file (possibly using /tmp directory) – here is where you likely need to provide the RECFM=U,BLKSIZE=32760 DD parameters on your SMF input dataset. And then after the OCOPY step, you must likely use BPXBATCH to invoke sftp and perform the binary-format put operation. 

[More ...]

Add to your %UTILBLDP invocation-string the keyword parameter BUILDPDB=NO

Scott Barry
SBBTech LLC

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Andreas von Imhof
Sent: Monday, April 28, 2025 12:33 PM
To: [log in to unmask]
Subject: [MXG-L] Migrate BUILDPDB to UTILBLDP

Currently we use the following statement to do our daily build:
%INCLUDE SOURCLIB(BUILDPDB);
%INCLUDE SOURCLIB(VMACSMF,VMAC98,IMACKEEP);
DATA
_VAR98
_SMF
_CDE98

Take note for the following in the SASLOG:
435296 +PROC SORT DATA=NDMAE OUT=PDB.NDMAE ;
435297 + BY SYSTEM SMFTIME NDMTIME ;
435298 +
NOTE: Input data set is empty.
NOTE: The data set PDB.NDMAE has 0 observations and 15 variables. 

[More ...]

Hi Scott,
Thanks for that. It does work, buuut it now only builds the 98's.
We need everything, like the 70's, DB2, CICS TCPIP etc etc. Thus what the BUILDPDB does plus what we have in EXPDBINC.
Kind regards,
Andreas

Might you have a job log of a long run to share?

Michael

At 11:32 AM 4/28/2025, Andreas von Imhof wrote:

>Currently we use the following statement to do our daily build:
>%INCLUDE SOURCLIB(BUILDPDB);
>%INCLUDE SOURCLIB(VMACSMF,VMAC98,IMACKEEP);
>DATA
>_VAR98
>_SMF
>_CDE98
>
>Take note for the following in the SASLOG:
> 435296 +PROC SORT DATA=NDMAE OUT=PDB.NDMAE ;
> 435297 + BY SYSTEM SMFTIME NDMTIME ;
> 435298 +
> NOTE: Input data set is empty.
> NOTE: The data set PDB.NDMAE has 0 observations and 15 variables.
>
>All good, but with CICS records approaching 400M it's time for a
>redesign 

[More ...]

11 The SAS System 00:41 Monday, April 28, 2025

NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA.
NOTE: SAS (r) Proprietary Software 9.4 (TS04.01M6P11072018)
Licensed to RABOBANK- MAINFRAME BEST5 (3931-705 1A17B8), Site 50900004.
NOTE: This session is executing on the z/OS V02R05M00 platform.

NOTE: Running on IBM Model 3931 Serial Number 0A18E8. 

[More ...]

Probably need to process cics separately

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Andreas von Imhof
Sent: Monday, April 28, 2025 12:23 PM
To: [log in to unmask]
Subject: Re: [MXG-L] Migrate BUILDPDB to UTILBLDP

Hi Michael,
This is the SASLOG from todays BUILD (took 5 hours). The (Rabo) coding in the beginning is for controls. Look for the BUILDPDB statement.

Probably need to remove expdb* from USER.Sourclib

w---Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Michael
Oujesky
Sent: Monday, April 28, 2025 12:00 PM
To: [log in to unmask]
Subject: Re: [MXG-L] Migrate BUILDPDB to UTILBLDP

Might you have a job log of a long run to share?

Michael

At 11:32 AM 4/28/2025, Andreas von Imhof wrote:

>Currently we use the following statement to do our daily build:
>%INCLUDE SOURCLIB(BUILDPDB);
>%INCLUDE SOURCLIB(VMACSMF,VMAC98,IMACKEEP);
>DATA
>_VAR98
>_SMF
>_CDE98
>
>Take note for the following in the SASLOG:
> 435296 +PROC SORT DATA=NDMAE OUT=PDB.NDMAE ;
> 435297 + BY SYSTEM SMFTIME NDMTIME ;
> 

[More ...]

TRY TGUS AFTER REMOVING EXPDB* FROM USER SOURCLIB
%UTILBLDP(USERADD=98,SUPPRESS=CICS,
OUTFILE=INSTREAM);
%INC INSTREAM;
-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Andreas von Imhof
Sent: Monday, April 28, 2025 11:33 AM
To: [log in to unmask]
Subject: [MXG-L] Migrate BUILDPDB to UTILBLDP

Currently we use the following statement to do our daily build:
%INCLUDE SOURCLIB(BUILDPDB);
%INCLUDE SOURCLIB(VMACSMF,VMAC98,IMACKEEP);
DATA
_VAR98
_SMF
_CDE98

Take note for the following in the SASLOG:
435296 +PROC SORT DATA=NDMAE OUT=PDB.NDMAE ;
435297 + BY SYSTEM SMFTIME NDMTIME ;
435298 +
NOTE: Input data set is empty.
NOTE: The data set PDB.NDMAE has 0 observations and 15 variables. 

[More ...]

Hi Chuck,

At this stage we must run the complete build in one step. It is quite a bit of engineering to split it into CICS / and the rest. We have a lot of own coding for controls (not just in this BUILD step).
Our EXPDBINC has the following which I cannot just strip out.
%INCLUDE SOURCLIB(VMACACHE) ;
%INCLUDE SOURCLIB(VMACNDM) ;
%INCLUDE SOURCLIB(VMACTCP) ;
%INCLUDE SOURCLIB(VMAC1415) ;
%INCLUDE SOURCLIB(VMAC1718) ;
%INCLUDE SOURCLIB(VMAC22) ;
%INCLUDE SOURCLIB(VMAC28) ;
%INCLUDE SOURCLIB(VMAC33) ;
%INCLUDE SOURCLIB(VMAC41) ;
%INCLUDE SOURCLIB(VMAC42) ;
%INCLUDE SOURCLIB(VMAC85) ;
%INCLUDE SOURCLIB(VMAC88) ;
%INCLUDE SOURCLIB(VMAC90) ;
%INCLUDE SOURCLIB(VMAC94) ;
%INCLUDE SOURCLIB(VMAC102) 

[More ...]

With an elapsed time to just read in the raw SMF data of "Elapsed
time - 04:57:43.29", I would heartily agree.

I would suggest starting at the SMF dump/offload process and segment
the data by clusters of related records (i.e. CICS, DB2, networking,
security, auditing, accounting/charge-back, etc.) as appropriate to
the installation.

Then provide separate MXG processing by each category of data
segmentation. That should also reduce the SAS CPU time by
dramatically reducing the size of the data step dope vector by
reducing the number of variable superfluous to that data segments
needs. This also allows for parallel processing 

[More ...]

As well, you may have other performance-improvement opportunities, such as exploiting zEDC data-compression (DASD-directed sequential allocations via a pre-defined DATACLAS) and also SAS CONFIG/OPTIONS settings DLLBI & FILELBI (for some elapsed time reduction normally.) Additionally, consider any opportunities to specify JCL DD parameter BUFNO=20 for your SMF input-data allocations. Furthermore, you will want to ensure that your SAS system is relatively "current" and at least SAS 9.4 TS1M6 or higher. 

[More ...]

Unfortunately, if you have all your eggs in the same basket, you are
stuck with the time it takes to cook them. Divide and conquer.

At 01:39 PM 4/28/2025, Andreas von Imhof wrote:

>Hi Chuck,
>
>At this stage we must run the complete build in one step. It is
>quite a bit of engineering to split it into CICS / and the rest. We
>have a lot of own coding for controls (not just in this BUILD step).
>Our EXPDBINC has the following which I cannot just strip out.
>%INCLUDE SOURCLIB(VMACACHE) ;
>%INCLUDE SOURCLIB(VMACNDM) ;
>%INCLUDE SOURCLIB(VMACTCP) ;
>%INCLUDE 

[More ...]

Two things – but not a definitive answer:

z16 Topology is only in SMF 70-1, not -2. And is in the Logical Processor Data Section.

I would use ERBSCAN / ERBSHOW as an easier and more reliable method of examining 70-1 (as opposed to IDCAMS PRINT, which this might be).

I’ve not seen any sudden zeroes for processor counts in 70-1 in my z16 customers (of which I’ve seen plenty). 

[More ...]

I just discovered this (SMF70CTN = 0 when it should not be) in one of our customer’s data yesterday!

 
Today, confirmed it affecting two other customers. All three on 3931 or 3932 processors. On a mix of z/OS 2.4, 2.5, and z/OS 3.1. Two on CMF, one using RMF. Not all systems are affected at each customer, and I have some indication that the problem may have started with people taking maintenance to systems, but I’ve not tried to verify that every effected system started showing the problem right after an IPL. 

[More ...]

Presumably not under VM. We don’t say where RMF gets its data from – with a few exceptions – and I simply don’t know in this case.

But both vendors, several OS levels, z16 of one type or the other: SMELLS LIKE some hardware interface. But, as you say, might be a z/OS problem. 

[More ...]

Well, trying to dig a little deeper I noticed that that data from the RMF customer was actually from their DR environment, and I believe that probably was under VM as SMF70CAN was also zero, which is not the case on the other systems I’ve seen. So… maybe we can’t rule out a CMF issue quite yet. 

[More ...]

Analcec may help find the answer

From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott Chapman
Sent: Saturday, February 15, 2025 11:51 AM
To: [log in to unmask]
Subject: Re: [MXG-L] SMF type 70 question - zero processors?

Well, trying to dig a little deeper I noticed that that data from the RMF customer was actually from their DR environment, and I believe that probably was under VM as SMF70CAN was also zero, which is not the case on the other systems I’ve seen. So… maybe we can’t rule out a CMF issue quite yet. 

[More ...]

Scott Chapman – do you know/can you find out what maintenance was applied to what at your end, so I can ask my customer if they have done the same?

Best wishes
Nick

From: MXG Software LIST <[log in to unmask]> On Behalf Of Chuck Hopf
Sent: 17 February 2025 14:36
To: [log in to unmask]
Subject: Re: [MXG-L] SMF type 70 question - zero processors? 

[More ...]

It looks like this might be happening due to some maintenance being applied to BMC’s AMI OPS Monitoring product. If I find out more I’ll post back.

Nick.

From: MXG Software LIST <[log in to unmask]> On Behalf Of Chuck Hopf
Sent: 17 February 2025 14:36
To: [log in to unmask]
Subject: Re: [MXG-L] SMF type 70 question - zero processors? 

[More ...]

Just a follow-up to the problem with SMF70CTN being zero, there’s now a CMF PTF (BCM1657) available that fixes the problem.

 
Scott Chapman

Wayne

A little of both. Rather than hold the zIIP work for an available engine, it will dispatch on a general CP for a while and then switch to a zIIP. Monitor the zIIP-eligible work and when it increases it can help you decide when to add another zIIP.

There is an old 2008 presentation I wrote about this on https://www.mxg.com/downloads/ search for “zIIP and zAAP Eligible Time Analysis <>”. 

[More ...]

Yup, that’s the “lazy switching” and it goes both ways. (E.G. when running Java workload, JNI calls won’t immediately go back to the GP.) My assumption has always been that the work is allowed to finish its time slice before it switches.

 
There’s also certain interrupt and lock handling that has to be done on a GP. So you can’t expect the zIIP eligible on CP to ever quite get to zero, although it can be very low. 

[More ...]

Messrs. Sherkow and Chapman,

Thank you for your quick and insightful replies. Much appreciated.

Greetings from mosquito-free Minnesota (at least for time being)

Wayne

Wayne Schumack
US Bank
Resource Management Group

From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott Chapman
Sent: Sunday, January 26, 2025 12:19 PM
To: [log in to unmask]
Subject: [EXTERNAL] Re: [MXG-L] Question regarding attribution of zIIP-eligible time in SMF Type70 records during periods of low zIIP processor utilization. 

[More ...]

Generally – for the “lock handling” * case you’ll find that’s persistent, regardless of system conditions. Especially for some address spaces that exhibit lock behaviours. Compare and contrast with the “resource management” case – which is what people usually see – which comes and goes according to system conditions.

* Note: This has nothing to do with database locks or coupling facility lock structures. 

[More ...]

How about SMF99_CCTRC100 in the type99 subtype 1 records?

From: MXG Software LIST <[log in to unmask]> On Behalf Of Keith Shaffer
Sent: Monday, January 6, 2025 10:31 AM
To: [log in to unmask]
Subject: [MXG-L] Undispatched Tasks

We have a live monitoring tool that provides "Undispatched Tasks" (number of tasks/ASs that have not been dispatched by srm due to constraints) I've tried to locate this field in smf & mxg without any luck - has anyone come 

[More ...]

Sorry, Anthony, don’t think I ever replied to your suggestion.

Yes, that and other 99s do seem relevant to what I was looking for
(although we don’t have them collected..)

Thank you for the idea

On Mon, Jan 6, 2025 at 12:43 PM Hirst, Anthony M. <
[log in to unmask]> wrote:

> How about SMF99_CCTRC100 in the type99 subtype 1 records?
>
>
>
> *From:* MXG Software LIST <[log in to unmask]> * On Behalf Of *Keith
> Shaffer
> *Sent:* Monday, January 6, 2025 10:31 AM
> *To:* [log in to unmask]
> *Subject:* [MXG-L] Undispatched Tasks
>
>
>
> We have a live monitoring tool 

[More ...]

Turn on and collect the 98s and 99s. What’s a few GBs of data per day for today’s systems? There’s good data in some of those records.

 
In the mid-90s when the 99s first came out they were recommended to be turned off due to their volume, but what should be considered a significant volume has changed over the past 30 years. The 98s are newer and while we’ve found less day-to-day usefulness in those records, there’s still data in them that is interesting for certain problem analysis. 

[More ...]

Hi Barry,

We will not be renewing MXG, because we’ve sold the Tuning Letter to PlanetMainframe and are no longer selling BoxScore, our only SAS program.

I have to admit that I’m loving retirement, with time for reading whatever I want.

I was so sorry to hear about Judy. I know how important she was to you. 

[More ...]

You won’t find the address space responsible there, although you should be able to see activity by requesting system. IGWLOCK00 is VSAM RLS, so I’d look to see what system(s) are driving the activity into the CF, then look at the VSAM activity on those systems.  The SMF 42s have some VSAM RLS interval details in the subtypes 15-19. 

[More ...]

I don't see that the Address Space is externalized into RMF records,
but here are some suggestions from Dr. Google.

To view the address space utilization of an IBM Coupling Facility, you can use the Address Space Memory (AS) panel and the Coupling Facility Usage Summary section:

* Address Space Memory (AS) panel
Shows system storage utilization for all address spaces in the sysplex. The panel also shows memory object usage and provides access to the Job Memory (JM) and Job Device (JD) panels. 

[More ...]

Hello Andreas old friend!

Add _S98, which does the SORTS from WORK to PDB.

Al

> On Dec 5, 2024, at 10:42 AM, Andreas von Imhof <[log in to unmask]> wrote:
>
> Hi,
> I am sure that the answer is staring me in the face but this dumbo just cannot find it.
> I have turned on SMF type 98's and now I want all the members that de build produces in my PDB. Some members such as TYPE9801 got to WORK, whilst some like TYPE98B1 go to PDB. What do I need to change to get say TYPE9801 into my PDB?
 

[More ...]

YOU COULD USE UTILBLdP to build your pdb as follows

%UTILBLDP(useradd=98,outfile=instream);
%inc instream;

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Andreas von Imhof
Sent: Thursday, December 5, 2024 10:42 AM
To: [log in to unmask]
Subject: [MXG-L] TYPE9801 in build

Hi,
I am sure that the answer is staring me in the face but this dumbo just cannot find it.
I have turned on SMF type 98's and now I want all the members that de build produces in my PDB. Some members such as TYPE9801 got to WORK, whilst some like TYPE98B1 go to PDB. What do I need 

[More ...]

Hi Al,
Thank you so much! It works!
When you visited us, MVS was doomed to die... end of life. A bunch of us were shown the door. 7 years later we were back. Now Z is the main platform of choice with loads and loads of new development.
Kind regards
Andreas

Certainly on MXG-L we have heard this story before regarding “leaving the mainframe”. It seems always to be harder than the “consulting” indicated!

Al

> On Dec 5, 2024, at 11:31 AM, Andreas von Imhof <[log in to unmask]> wrote:
>
> Hi Al,
> Thank you so much! It works!
> When you visited us, MVS was doomed to die... end of life. A bunch of us were shown the door. 7 years later we were back. Now Z is the main platform of choice with loads and loads of new development.
> Kind regards
> Andreas

You could also use %UTILBLDP to add the 98 to be processed in the
BUILDPDB SMF read and avoid the second pass of the SMF file for
the 98's in your solution.

%UTILBLDP(BUILDPDB=YES,USERADD=98,INCLAFTR=ASUM113,OUTFILE=INSTREAM);
%INCLUDE INSTREAM;

Barry

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Al Sherkow
Sent: Thursday, December 5, 2024 10:52 AM
To: [log in to unmask]
Subject: Re: [MXG-L] TYPE9801 in build 

[More ...]

They keep "modernizing" the process - one of my former employers now is trying to use WatsonX, the AI tool, to migrate their mainframe work. We'll see how it goes. Which reminds me - has anyone ever published a credible report of whether or not these moves saved any money? 

[More ...]

Imo it probably increases costs but spreads it out across depts instead of being a huge lump

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Tim Hare
Sent: Monday, December 9, 2024 8:53 AM
To: [log in to unmask]
Subject: Re: [MXG-L] TYPE9801 in build

They keep "modernizing" the process - one of my former employers now is trying to use WatsonX, the AI tool, to migrate their mainframe work. We'll see how it goes. Which reminds me - has anyone ever published a credible report of whether or not these moves saved any money? 

[More ...]

Once upon a time, a company I worked for had a
correspondence application that ran under CICS
with overnight in the wee hours of the morning
after all critical batch was done to produce the
mailings. They justified the "savings" of
doing correspondence on a distributed platform
based on the mainframe cost-sharing dollars.

The conversion project cost ten million to build
and implement with an on-going expenditure of
twelve million over the next ten years. Since
the mainframe resources were insignificant, the
conversion realized no material mainframe cost
savings. The annual IT budget took the ten
million hit in the 

[More ...]

New Zix secure email message from Wells Fargo

Do not reply to this notification message; this message was auto-generated by the sender's security system.

To view the secure message or reply to the sender, click on the link below or copy and paste the link into your Internet browser address bar.

https://securemail.wf.com/s/e?m=ABB2X1SNdUtMfYtD2agyZiSp&c=ABAHlOHqvnkKNM7OBmFOBmri

You are reading the plaintext version of this message. For a better user experience, change your email settings to enable the viewing of HTML. 

[More ...]

I'm not a MXG user so can't help you on those specifics but...

... Is your source data 110's, 30's, or 72's (the latter exploiting report classes perhaps) ?

I ask because that WOULD affect what the SAS queries would look like.

Cheers, Martin

Sent from my iPad

On 23 Sep 2024, at 23:08, Arun Prasad Rajagobalan <[log in to unmask]> wrote: 

[More ...]

You would want to use the SMFINTRV dataset (see member SMFINTRV) which has the interval
total CPUTM for each job, and select your CICS Regions by JOB name and summarize by INTBTIME
to get the total MSU for all CICS regions.

You would use MSU=SMF70CPA*CPUTM/1000000; to get the MSU for each interval for each region.
The SMF70CPA is in the TYPE70 dataset, and you may need to code a test for SYSTEM to select
the SMF70CPA value for each SYSTEM if you have multiple CPU models.
My test data had SMF70CPA=24060 for a 3931-18, and the MSU Capacity for those 

[More ...]

Multiple sources have multiple MIPS ratings. When somebody asked me how many MIPS we had on the floor I always asked what software contract they were worried about so we could see whose MIPS chart (if any) the contract referenced.

 
PCI is IBM term for something that looks remarkably like MIPS. But they probably don’t want to label it MIPS to avoid stepping on toes for others who have different “MIPS” ratings. Or it could be an honesty thing to avoid confusion about MIPS not really being equal to the Millions of Instructions executed per second. 

[More ...]

I still think engines-worth is the best metric. And, as I indicated (and echoing you, Scott), multiple sources. Depends on what?s available.

Cheers, Martin

From: MXG Software LIST <[log in to unmask]> on behalf of Scott Chapman <[log in to unmask]>
Date: Tuesday, 24 September 2024 at 21:52
To: [log in to unmask] <[log in to unmask]>
Subject: [EXTERNAL] Re: [MXG-L] CICS REGION MIPS USAGE
Multiple sources have multiple MIPS ratings. When somebody asked me how many MIPS we had on the floor I always asked what software contract they were worried about so we could see whose MIPS chart (if any) the contract referenced. PCI is IBM 

[More ...]

Oh I agree… I much prefer more concrete measures, but when tracking utilization over long terms where the machine model may change, MSUs or MIPS can be useful. Although I prefer MSUs over MIPS just because MIPS is so vague because of those multiple sources.

 
Scott

 
From: MXG Software LIST <[log in to unmask]> On Behalf Of Martin Packer
Sent: Wednesday, September 25, 2024 5:03 AM
To: [log in to unmask]
Subject: Re: [MXG-L] CICS REGION MIPS USAGE 

[More ...]

As I was name checked 😊 one thing to mention…

… If you see the L4RP or MEMRP numbers in SMF 113 as non-zero don’t be alarmed now. It’s just a spring clean 😊 er um it’s quite normal because there are things that have nothing to do with LPAR cross-drawer activity… 

[More ...]

We also tried this at the service class level for a client pre-pandemic for a set of WAS environments and it also had no noticeable impact.

We never got to the bottom of why there was this persistent ZIIP eligible that would not run on a ZIIP.

I theorized this had to do with the hesitance of WLM to force a processor move other than on a time slice, but was unable to prove it. 

[More ...]

There is the concept of lazy switching. I.E. if the work is doing things such that it’s switching back and forth between zIIPs and GPs, the dispatcher will not immediately move it from the processor that it’s on, because if it did so it would simply have to reload the L1/possibly L2 caches on the other / new processor. I have a recollection that it will switch on the next minor or major (don’t remember which though) time slice. 

[More ...]

Yes, I guess lazy switching is probably what it is down to.

There is a tiny amount of GP-only (calculated by GP CPU - ziip eligible) of
around 1.5%.

But thinking about it, the nature of that GP-only consumption could be
quite detrimental to the ability to properly switch back to zIIP if some
part of the code is repeatedly needing to use GPs.
So I have now looked at the I/O profile, and it is actually doing several
thousand IOPS, and unless things have changed, I believe I/O can only be
initiated on GPs.
Although it is not "normal" 

[More ...]

I believe (but am not 100% of the details here) that while zIIPs are never enabled to handle I/O interrupts they can (technically) initiate an I/O. But whether the JVM does initiate I/O from the zIIPs or not (or partial) I’m not sure at this point. I clearly remember that when zIIPs were introduced there was a mantra of “zIIPs don’t do I/O”. (Or maybe it was “can’t”?) 

[More ...]

I Use ODS PDF file='/u/mxg/graphs,pdf';; then download rhe pdf file.

From: MXG Software LIST <[log in to unmask]> On Behalf Of Brian
Sanger
Sent: Tuesday, July 30, 2024 3:38 AM
To: [log in to unmask]
Subject: [MXG-L] SAS9.4 Graphing to TSO terminal

I have a mainframe SAS9.1 application that runs under TSO ISPF that triggers
dynamic SAS queries to GDDM device drivers to show graphs on the TSO
Terminal. Data input is summarized and trended MXG data. The application
is used across teams and requires no sas knowledge to use. 

[More ...]

Hi Mike,

I don't know about canned MXG reports that do this, but I've been charting "ZIIP Eligible" on the same chart with "ZIIP Busy" in Excel (chart has two Y-Axes) for many years.

If you'd like to see a sample chart, I could send you a screenshot of my PowerPoint slide, showing ZIIP Busy and ZIIP Eligible Minutes, by Hour. 

[More ...]

I would be interested in seeing the chart and the SAS/MXG code.

From: MXG Software LIST <[log in to unmask]> On Behalf Of Ken W Pressley
Sent: Thursday, July 25, 2024 4:36 PM
To: [log in to unmask]
Subject: Re: [MXG-L] zIIP on CP Chart?

⚠ EXTERNAL MESSAGE – Think Before You Click

Hi Mike,

I don’t know about canned MXG reports that do this, but I’ve been charting “ZIIP Eligible” on the same chart with “ZIIP Busy” in Excel (chart has two Y-Axes) for many years. 

[More ...]

Grafwrkx produces A PLOT of zip eligible time

From: MXG Software LIST <[log in to unmask]> On Behalf Of Landholm, Kent (US - Nebraska)
Sent: Friday, July 26, 2024 8:03 AM
To: [log in to unmask]
Subject: Re: [MXG-L] zIIP on CP Chart?

I would be interested in seeing the chart and the SAS/MXG code.

From: MXG Software LIST <[log in to unmask] <mailto:[log in to unmask]> > On Behalf Of Ken W Pressley
Sent: Thursday, July 25, 2024 4:36 PM
To: [log in to unmask] <mailto:[log in to unmask]>
Subject: Re: [MXG-L] zIIP on CP Chart? 

[More ...]

Hi

There is a MXG program\macro called 'ANALMSU'.

Try it.

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Jeff Curfman
Sent: Monday, July 15, 2024 4:34 PM
To: [log in to unmask]
Subject: [MXG-L] Calculate MSU at the Sysplex level

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

[More ...]

Thank you very much!!

From: MXG Software LIST <[log in to unmask]> On Behalf Of Sarel Swanepoel
Sent: Monday, July 15, 2024 11:29 AM
To: [log in to unmask]
Subject: Re: [MXG-L] Calculate MSU at the Sysplex level

Caution: External email. Do not open attachments or click on links if you do not recognize the sender.

Hi

There is a MXG program\macro called 'ANALMSU'. 

[More ...]

The changing RACF userid and group within an SSH task on z/OS can indeed be
perplexing. This behavior is typically related to how SSH sessions and RACF
work in concert on z/OS. Here are a few key points and resources that might
help you understand this behavior:Explanation of the BehaviorSession
Initialization and User Authentication: When an SSH session starts, the
initial setup might run under a default userid/group (e.g., SSHDAEM/SYS1).
Once the user logs in and is authenticated, the session can switch to the
user's specific userid/group (e.g., WWCJPD/MFXUSR).SMF Record Subtypes: The
subtypes in SMF records (3, 4, and 5) 

[More ...]

Type74 has the pav information. Scan adoc74 fort pav

From: MXG Software LIST <[log in to unmask]> On Behalf Of Sarel Swanepoel
Sent: Wednesday, June 12, 2024 5:07 AM
To: [log in to unmask]
Subject: [MXG-L] PAV

Hi

I require PAV information to determine how many PAV’s are in use and also to determine if there is a shortage of PAV’s (Type78). 

[More ...]

Complete job log, please.

Michael

At 06:57 AM 6/3/2024, Sarel Swanepoel wrote:

>Hi all
>
> 1 of our jobs, pdwdma12 , ran for 10 hours instead of 1.5. The
> number of records were the same. It ran on NAT61
>There are 4 jobs that start together, around 11h00 previously, but
>yesterday they all started at 15h12.
>
>The VAT ADABAS database was converted to larger block sizes on
>Saturday night.
>The new volumes for this database has a prefix of VPB****
>
>Any idea where I can start to identify this problem please?
>
>
>Disclaimer
>
>Please 

[More ...]

On Jun 3, 2024, at 6:57 AM, Sarel Swanepoel <[log in to unmask]> wrote:

1 of our jobs, pdwdma12 , ran for 10 hours instead of 1.5. The number of records were the same. It ran on NAT61
There are 4 jobs that start together, around 11h00 previously, but yesterday they all started at 15h12.

The VAT ADABAS database was converted to larger block sizes on Saturday night.
The new volumes for this database has a prefix of VPB**** 

[More ...]

This is just an educated guess as I’m not an ADABAS guy – but when the databases were converted, were the indexes rebuilt?

Tim Hare

Interested Bystander, Non-Inc.

From: MXG Software LIST <[log in to unmask]> On Behalf Of Pew, Curtis G
Sent: Monday, June 3, 2024 4:56 PM
To: [log in to unmask]
Subject: Re: [MXG-L] System Z Batch Job running longer 

[More ...]

So, this is not a MXG processing issue, but an application performance problem?

Michael

At 11:08 PM 6/3/2024, Tim Hare wrote:

>This is just an educated guess as I’m not an
>ADABAS guy – but when the databases were converted, were the indexes rebuilt?
>
>Tim Hare
>
>Interested Bystander, Non-Inc.
>
>From: MXG Software LIST
><[log in to unmask]> On Behalf Of Pew, Curtis G
>Sent: Monday, June 3, 2024 4:56 PM
>To: [log in to unmask]
>Subject: Re: [MXG-L] System Z Batch Job running longer
>
>On Jun 3, 2024, at 6:57 AM, Sarel Swanepoel
><<mailto:[log in to unmask]>[log in to unmask]>
>wrote:
>
> 1 of our jobs, pdwdma12 , 

[More ...]

Hi Sarel - take a look in ADOC30 in the sourclib.
It has really good descriptions into the life of a job and the variables that make up the elapsed time.
The job log will also give lots of information as to what the job is doing.

BROWSE ISV.MXG.SOURCLIB(ADOC30)

ACTDLYTM NUM 5 TIME12.2 DELAY DURATION*EXECUTING*NOT ACTIVE
This is the difference between EXECTM and ACTIVETM, which includes the
time the address space was swapped out due to Detected Wait or Long
Wait events and includes TSO user's think time.
ACTDLYTM includes Mount Pending Time for some types of Tape Mounts,
especially 

[More ...]

DSPDLYTM Duration when the task was resident but not dispatched,
calculated as RESIDTM-CPUTCB+SRB+HPT+RCT+IPT. This duration
is the time the task was resident in memory but was not
executing instructions. It includes the delay for CPU
dispatch (when you enter the MPL set you don't immediately
get CPU - a hot CICS transaction may still have the
processor, so you wait here until dispatched on a CPU), and
the delay for I/O (you execute a few CPU instructions and
then issue an I/O and you wait for IOS to get the data for
you), and the delay due to page faults 

[More ...]

DSPDLYTM NUM 5 TIME12.2 DELAY DURATION*RESIDENT*NOT DISPATCHED
Difference between RESIDTM and the sum of five of the seven CPU times
in the record. CPITCBTM and CPISRBTM are included in variable CPUTM,
because it represents all CPU time used by the step/job, but for the
calculation of DSPDLYTM, those two CPU times are not used because they
occur outside the actual EXECTM (either before or after). Thus the
DSPDLYTM is the time the task was resident in memory but was not
executing instructions. This includes any delay for CPU dispatch
(when you enter the MPL set you don't immediately get CPU 

[More ...]

If the job uses adabas and that was the only difference that is the place to
start. Sadly adabas does not produce data

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Michael
Oujesky
Sent: Monday, June 3, 2024 11:58 AM
To: [log in to unmask]
Subject: Re: [MXG-L] System Z Batch Job running longer

Complete job log, please.

Michael

At 06:57 AM 6/3/2024, Sarel Swanepoel wrote: 

[More ...]

Please send the job log and the 112 records to either [log in to unmask] or ftp to
ftp.mxg.com user mxgtech pw mxgtech.

Barry

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Michael Oujesky
Sent: Monday, June 3, 2024 12:16 PM
To: [log in to unmask]
Subject: [MXG-L] Sample of internally compressed 112 (OM/CICS) records

Might anyone have a small sample to share? 

[More ...]

Congrats Doug! Thanks for your contributions (from one of the more silent members here) and enjoy what’s to come. I’m right behind you. 😊

NTAC:3NS-20
From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland
Sent: Thursday, May 30, 2024 11:16 AM
To: [log in to unmask]
Subject: [EXT] [MXG-L] Final Day

This email originated from outside the organization. Do not click links or open attachments unless you have verified this email is legitimate. 

[More ...]

Good Luck Doug! I hope retirement is everything that you hoped for!

Jill Ackerman
SAS Technical Support

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland
Sent: Thursday, May 30, 2024 12:16 PM
To: [log in to unmask]
Subject: [MXG-L] Final Day

EXTERNAL
Good afternoon. I am retiring tomorrow after 45 years in mainframe IT. I just want to say a big thanks to Barry and Chuck and the folks at MXG for helping me throughout my career. Also, to all the wonderful colleagues that posted, replied and helped me along the way. Most of my job was "by myself" so I 

[More ...]

Congratulations on retirement Doug – and remember to ask for a purchase order and check when they come to you to ask about your code 😊

Tim Hare

Also retired

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland
Sent: Thursday, May 30, 2024 12:16 PM
To: [log in to unmask]
Subject: [MXG-L] Final Day

Good afternoon. I am retiring tomorrow after 45 years in mainframe IT. I just want to say a big thanks to Barry and Chuck and the folks at MXG for helping me throughout my career. Also, to all the wonderful colleagues that posted, replied and helped me 

[More ...]

Congrats. Any idea who will be taking over?

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland
Sent: Thursday, May 30, 2024 11:16 AM
To: [log in to unmask]
Subject: [MXG-L] Final Day

Good afternoon. I am retiring tomorrow after 45 years in mainframe IT. I just want to say a big thanks to Barry and Chuck and the folks at MXG for helping me throughout my career. Also, to all the wonderful colleagues that posted, replied and helped me along the way. Most of my job was "by myself" so I couldn't collaborate with anyone to help me with issues. That's 

[More ...]

Looking in MXG SOURCLIB member VMAC119 (or a PROC CONTENTS on the PDB file), it is a SAS CHARACTER type variable, so the literal-string comparison reference becomes '0301'X

Scott Barry
SBBTech LLC

From: MXG Software LIST <[log in to unmask]> On Behalf Of Vitner, Jerome
Sent: Thursday, May 23, 2024 5:33 PM
To: [log in to unmask]
Subject: [MXG-L] Simple, I hope, SAS question 

[More ...]

Yes, that was simply and I had thought I tried that. It worked.

Get Outlook for iOS<https://aka.ms/o0ukef>

No abstract is available available for this message. [Read Message ...]

I concur.Something about Barrys and MXG!

On Thu, May 23, 2024 at 6:17 PM Marvin Silverman <
[log in to unmask]> wrote:

> Scott Barry is the man!
>
> Best regards,
> Marv
>
> On May 23, 2024, at 3:28 PM, Vitner, Jerome <
> [log in to unmask]> wrote:
>
> 
> Yes, that was simply and I had thought I tried that. It worked.
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* MXG Software LIST <[log in to unmask]> on behalf of Scott
> Barry <[log in to unmask]>
> *Sent:* Thursday, May 23, 2024 5:36:38 PM
> *To:* [log in to unmask] <[log in to unmask]>
> *Subject:* [EXTERNAL] Re: [MXG-L] 

[More ...]

Classification: Public As far as I am aware we use the default sampling rate (SAMPFREQ= 800000) and default counters (COUNTER SET= BASIC,PROBLEM-STATE,CRYPTO-ACTIVITY,EXTENDED). The maximum CPU I can find from yesterday on a z16 7xx machine is 0.012 seconds in a 900 second interval (0.00134% of one GP engine). Stephen From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland Sent: Tuesday, April 16, 2024 7:46 PM To: [log in to unmask] Subject: [MXG-L] HIS Setup *** This email is from an external source - be careful of attachments and links. Please report suspicious emails *** Good afternoon. Our customer is reacting to our 

[More ...]

Hi Stephen...thank you for the details. It seems to match my belief that 113s are not that resource consumptive. I think we’ll have more of a task explaining what the benefits are of having the 113s active. Outside of a CPU analysis, for tools like zPCR, I’m not sure what to tell them. This particular account does not upgrade that often so the next upgrade from our new z16 will be awhile. 

[More ...]

Doug,
You want to be collecting CPU MF Counters mode for all LPARs/Systems all the time, not Sampling mode. It’s a switch, you run one or the other. Typically CPU MF Sampling is done for a short
Period of time (e.g. 10 minutes, and usually directed by IBM L2, which is a very infrequent event). CPU MF Counters should be enabled as the default for all LPARs (regardless of size), and the overhead is not measurable. CPU MF Counters is what zPCR uses to establish your LSPR workload match. 

[More ...]

Try these links instead.

CPU MF Counters: Collecting Detailed Instructions and the lates Formulas including z16 and AIU

https://www.ibm.com/support/pages/node/6354583
[cid:image001.png@01DA9042.C5F833F0]
SIIS

Formulas, including z16
https://www.ibm.com/support/pages/system/files/inline-files/Identifying%20SIIS%20Inefficiency%20by%20Using%20CPU%20MF%20Counters%20slides%20Updated%20May%202022_0.pdf

White paper
https://www.ibm.com/support/pages/system/files/inline-files/Identifying_SIIS_Inefficiency_by_Using_CPU_Counters_paper.pdf

Hope this helps,
John

From: MXG Software LIST <[log in to unmask]> On Behalf Of John Burg
Sent: Tuesday, April 16, 2024 8:57 PM
To: [log in to unmask]
Subject: [EXTERNAL] Re: [MXG-L] HIS Setup

Doug, You want to be collecting CPU MF Counters mode for all LPARs/Systems all the time, not Sampling mode. It’s a switch, you run one or the other. Typically CPU MF Sampling is done for a short Period of time (e. g. 10 minutes, 

[More ...]

Not to undermine John’s presentation but the synopsis of the situation is this: The value of SMF 113 is very high; The cost is very low. Turn it on everywhere and – combined with the new home address fields in z16 RMF SMF 70-1 – you’ll have a lot of fun. 

[More ...]

Hi John...thanks for your reply. Sampling actually had me worried but it sounds like even with sampling HIS doesn’t use much CPU. If we wanted to have no sampling would we just put zero in place of the default? I do like the idea of cutting these records as it is mentioned as an IBM best practise. 

[More ...]

Good morning...I’ve checked out some of the links. Counter mode seems to be what is recommended (so I didn’t have to ask my last question).

Great replies! Thank you all!

Regards,

Doug Medland
Performance Analyst
Mainframe Performance and Capacity Management
Email: [log in to unmask]

From: MXG Software LIST <[log in to unmask]> On Behalf Of John Burg
Sent: Tuesday, April 16, 2024 9:20 PM
To: [log in to unmask]
Subject: [EXTERNAL] Re: [MXG-L] HIS Setup 

[More ...]

I don’t remember seeing this around boost periods, but I would not at all be surprised by it. (Which is to say, maybe I have seen it and dismissed it.)

 
We see this sometimes when a new WLM policy is activated right at the beginning of an interval. This predates system recovery boost. What appears to be happening is that everything momentarily loses it’s service class assignment (i.e. is SYSOTHER) while WLM reclassifies everything on the system. If that happens right as the SMF/RMF interval is being finalized, some workload ends up showing as “SYSOTHER” when in fact it 

[More ...]

Interesting. I should think this would also
affect the RMF III data store with all the policy activations.

Michael

At 07:55 AM 4/15/2024, Hoar, wrote:

>Classification: Public
>
>Dear MXG Users
>
>My Colleague picked up some sporadic activity in
>the SYSOTHER service class which he has tracked
>down as only appearing when a speed boost is
>invoked. IBM documentation says WLM behaves
>differently during a boost and it appears it has
>to refresh the policy on the affected systems.
>This is not just the main system receiving an
>IPL boost but others in the Sysplex receiving
>smaller boosts such 

[More ...]

Classification: Public We have them "turned on" from an SMF point of view in that, if an RMF 76 were ever to be written again we would at least collect it. Perhaps that is all the person actually wants to know as you suspect. Although I don't remember seeing the 76 records for probably 35 years, I last used RMF 79 records a coupe of years ago to review IRLM issues (TYPE79 subtype 15) however these are not generated by RMF or CMF but come directly from IMS. Stephen From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland Sent: 

[More ...]

Monitor II Type 79 is a separate RMF session and you request information on specific Jobs:

Snapshot monitoring with Monitor II The scope of Monitor II data gathering is mainly related to single address spaces or resources, giving snapshots of the current status. You can collect data about address space activities and resource consumption, and about processor, DASD volume, and storage activities and utilization. With Monitor II, it is also possible to monitor one specific job or volume continuously 

[More ...]

Likely you will need to investigate processing the z/OS HTTP (Apache) WEB SERVER logs (non-SMF dataset source, a log set per web server instance), after suitable APACHE logging activation. Once populated, the logs likely are found under z/OS USS/zFS file-system directory location: /u/ihsa_zos/<server>/ihs/logs

Regards,

Scott Barry
SBBTech LLC
EMAIL: [log in to unmask]
TEL: 1.305.509.1096

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Renato Degasperi
Sent: Thursday, March 21, 2024 9:34 AM
To: [log in to unmask]
Subject: [MXG-L] SMF 120 - Web Server report 

[More ...]

Assuming scott is correct if you send us the log and any doc you have on it we will try to develop source to read it.

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott Barry
Sent: Thursday, March 21, 2024 9:36 AM
To: [log in to unmask]
Subject: Re: [MXG-L] SMF 120 - Web Server report 

[More ...]

Mxg does support reading www logs but may not support yours.

try running
filename wwwlog '/u/your log name';
%include sourclib(typewww);

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott Barry
Sent: Thursday, March 21, 2024 9:36 AM
To: [log in to unmask]
Subject: Re: [MXG-L] SMF 120 - Web Server report

Likely you will need to investigate processing the z/OS HTTP (Apache) WEB SERVER logs (non-SMF dataset source, a log set per web server instance), after suitable APACHE logging activation. Once populated, the logs likely are found under z/OS USS/zFS file-system directory location:
/u/ihsa_zos/<server>/ihs/logs 

[More ...]

1. No, because the group caps are based on the RHA of the group compared to the limit.
2. In terms of group absolute capping, yes, an LPAR can be subject to group limits as well as individual limits. As for can you click the box to enable initial capping as well as define an absolute cap for an LPAR, I’m not 100% sure of this, but I believe so. I believe the lower of the two would be enforced.
3. ABSMSUCAPPING. https://www.ibm.com/docs/en/zos/2.4.0?topic=parameters-statements-ieaoptxx <https://www.ibm.com/docs/en/zos/2.4.0?topic=parameters-statements-ieaoptxx> 

[More ...]

Hi Scott...thank you again for a great answer. Oddly enough I’m reading a PDF from an IBMer (Horst Sinram Apr 2016) “Capping Technologies and 4HRA Optimization.” Lots of “permutations and combinations” to be sure and some answers to my questions. Essentially my client is putting their 3 mainframes into one box. They’d like certain LPARs/groups to be “no more than X MSUs.” I think absolute capping would work for the two smaller production LPARs not in the Group Profile. We’ve set the Group Profile to be 150 MSUs (which equates to our current z14 box 3907-L04). Inside that profile the 

[More ...]

Take a look at analcec – it may help

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug
Medland
Sent: Monday, March 18, 2024 12:17 PM
To: [log in to unmask]
Subject: Re: [MXG-L] More Fun With Capping

Hi Scott...thank you again for a great answer. Oddly enough I’m reading a
PDF from an IBMer (Horst Sinram Apr 2016) “Capping Technologies and 4HRA
Optimization.” Lots of “permutations and combinations” to be sure and some
answers to my questions. Essentially my client is putting their 3
mainframes into one box. They’d like certain LPARs/groups to be “no more
than X MSUs.” I think absolute 

[More ...]

Ha! The many, many forms of capping. Perhaps I should do a webinar on this sometime.

 
In short: Initial (sometimes also called “hard”) capping enforces the LPAR’s weight and doesn’t let the LPAR get more than it’s share as determined by the LPAR’s weight / sum(weight of all activated LPARs). But note that if an LPAR is activated or deactivated that changes the total sum of the weights. So you might have 356 but an LPAR is deactivated (assuming you don’t change any weights to compensate for the deactivation) it will be able to get to more than 774 

[More ...]

A good answer

From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott
Chapman
Sent: Wednesday, March 13, 2024 3:24 PM
To: [log in to unmask]
Subject: Re: [MXG-L] HMC Group Profiles

Ha! The many, many forms of capping. Perhaps I should do a webinar on this
sometime.

In short: Initial (sometimes also called "hard") capping enforces the LPAR's
weight and doesn't let the LPAR get more than it's share as determined by
the LPAR's weight / sum(weight of all activated LPARs). But note that if an
LPAR is activated or deactivated that changes the total sum of the weights.
So you might have 

[More ...]

Good afternoon...yes...an excellent answer...thanks Scott and MXG-L!

Regards,

Doug Medland
Performance Analyst
Mainframe Performance and Capacity Management
Email: [log in to unmask]

From: MXG Software LIST <[log in to unmask]> On Behalf Of Chuck Hopf
Sent: Wednesday, March 13, 2024 5:02 PM
To: [log in to unmask]
Subject: [EXTERNAL] Re: [MXG-L] HMC Group Profiles

A good answer From: MXG Software LIST <MXG-L@ PEACH. EASE. LSOFT. COM> On Behalf Of Scott Chapman Sent: Wednesday, March 13, 2024 3: 24 PM To: MXG-L@ PEACH. EASE. LSOFT. COM Subject: Re: [MXG-L] HMC Group Profiles Ha! The many, many forms of capping. 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Dq81_Y1A2Q!e1OFkIEqJybldsWLokNQYgNIW0wZ0_aT59Y1fAC9zY4Vwrn9sNqMbFn6Mdlr-6TCgoytcEhFlAs9l5WHZa3lZAcNJ02kVv0$> ‌
ZjQcmQRYFpfptBannerEnd
 

[More ...]

Avoid coding any DCB-related parameters – see dumbed-down example below (screenshot – both SASLOG output and JCL-script) but I can assure you that SAS can read/write SMF data.

Suggest you provide some specific symptom-information to the list for further guidance ?

Scott Barry
SBBTech LLC

[cid:image001.png@01DA706D.548B6A60]

From: MXG Software LIST <[log in to unmask]> On Behalf Of Heimir Hauksson
Sent: Thursday, March 7, 2024 6:44 AM
To: [log in to unmask]
Subject: [MXG-L] SMF record with length 32764 

[More ...]

Thanks Scott,
I tried your job and it worked as expected.
My job failed because I specified RECFM=U for the input SMF file and with this specification record length over 32760 are not allowed.
Heimir

Heimir Hauksson | Global z/OS Strategy | Infrastructure Services
Tel +44 (0)330 1535061 | Mobile +44 (0)7780 754767 | Email [log in to unmask]<mailto:[log in to unmask]>
Barclays Technology Centre Radbroke, Wilson House, GF A37, Knutsford, Cheshire, WA16 9EU (Mail Area 49)
Barclays.com 

[More ...]

SAS and MXG can read/write VBS files with LRECL of up to 16384K-1. See VMACSMFL as a reference. though IFASMFD? is limited to 32767.

Michael

On Thu, Mar 7, 2024, at 5:44 AM, Heimir Hauksson wrote:
> Hi all,
> Our IFASMFDL task fell over as it specified LRECL=32760 for the output file, but a record of length 32764 was present.
> Removing the LRECL from the dump JCL gives the output dataset LRECL=32767.
> SAS refuses to read this as it is over 32760. How can I get around this?
> Thanks,
> Heimir
>
> Heimir Hauksson | 

[More ...]

I should mention that when a VBS data setshows a LRECL of 32768, this
appears to indicate the possible existense of long recorsa and the
application will be responsible for re-assembling the segmentys into
the long record.

At 02:19 PM 3/7/2024, Michael Oujesky wrote:
>SAS and MXG can read/write VBS files with LRECL of up to
>16384K-1. See VMACSMFL as a reference. though IFASMFD? is limited to 32767.
>
>Michael
>
>
>On Thu, Mar 7, 2024, at 5:44 AM, Heimir Hauksson wrote:
>>
>>Hi all,
>>
>>Our IFASMFDL task fell over as it specified LRECL=32760 for the
>>output file, 

[More ...]

Since I haven’t seen a reply from SAS I thought I’d offer some further insight….

Take a look at this from SAS Problem Note 69871:

MXG code cannot read TYPE 70/72 records that are longer than 32K record due to a change that IBM made .

You’ll see that there is a hotfix available but only for 9.4M7 or 9.4M8 – this aligns with the change in support policy that SAS made last year. 

[More ...]

‘Tis true. Just do it.

 
For a single system from a smallish customer that I just happen to have stats sitting here for:

SMF 113: 2.6 MB

SMF 72: 13 MB

SMF 30: 153 MB

SMF 74: 297 MB

 
They could have saved 1.3 MB by turning off the 113 subtype 2s which are the older record format with accumulated values. The subtype 1s have been the preferred records for several years now. But nobody is going to notice 1.3MB of SMF data! 

[More ...]

Also, important to configure the HCD LPAR profile with all counter-types activated (i.e., BASIC, PROBLEM, EXTENDED, and beyond) - primarily for the SMF 113 performance analysis benefit.

....Internet search argument to use: "cpu mf" "activation"

Scott Barry
SBBTech LLC

From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott Chapman
Sent: Wednesday, January 31, 2024 10:04 AM
To: [log in to unmask]
Subject: Re: [MXG-L] SMF 113 Records 

[More ...]

YOU NEED TO BE SURE YOU HAVE THE MOST CURRENT mxg AS WELL

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug
Medland
Sent: Wednesday, January 31, 2024 8:45 AM
To: [log in to unmask]
Subject: [MXG-L] SMF 113 Records

Good morning. We are installing a new z16 and we're being asked to provide
SMF 113 records. On this particular account there have never been 113
records created. I understand the HIS (?) task creates these records and
that CPU consumption is not much. How about the number of 113 records
created...is it similar to RMF, ie. recorded at some interval? I've
basically 

[More ...]

Good morning...this is great...thanks to all who have replied. Just one more question. Our new z16 will have at least six LPARs. Is it appropriate to have HIS on all LPARs or only the larger ones? My assumption would be all LPARs...thanks again.

Regards,

Doug Medland
Performance Analyst
Mainframe Performance and Capacity Management
Email: [log in to unmask] 

[More ...]

HIS started-task must be setup/configured and running on each z/OS LPAR, those where the SMF 113s are generated – which really needs to be “all LPARs big and small”….

Example all-in-one HIS started task JCL-PROC:

[cid:image002.png@01DA5438.7D1DFCF0]

Scott Barry
SBBTech LLC

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland
Sent: Wednesday, January 31, 2024 11:23 AM
To: [log in to unmask]
Subject: Re: [MXG-L] SMF 113 Records 

[More ...]

Leave it on for all 6. It’s not burdensome or voluminous.

Cheers, Martin

From: MXG Software LIST <[log in to unmask]> on behalf of Doug Medland <[log in to unmask]>
Date: Wednesday, 31 January 2024 at 16:23
To: [log in to unmask] <[log in to unmask]>
Subject: [EXTERNAL] Re: [MXG-L] SMF 113 Records
Good morning. . . this is great. . . thanks to all who have replied. Just one more question. Our new z16 will have at least six LPARs. Is it appropriate to have HIS on all LPARs or only the larger ones? My assumption would be all LPARs. . . thanks again. 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!1e-s7j4TRvmalYv7eaEF4Ahyvew8YtZePNXWKLe5ofTUSR38Vzv_xddXPVZM8gsU3IYeSGBNuchjmfpcQMc1ZjM2p2BMdJpu8RhjaQnJ2n2OWxyBMP_rvW_oZ4AkmmqG8Ajp2KQ904fSXg8$>
 

[More ...]

Collecting CPU MF (SMF 113s in z/OS) is an IBM Best Practice. They are important to collect so you can match your workloads to an LSPR curve. You should continuously collect CPU MF on all systems so
that you can determine the workload match (on the “before” processor) and then accurately size your “after” processor, e.g. z16, via zPCR (which reads in CPU MF and sets the LSPR workload curve match for each LPAR in the configurations). 

[More ...]

Classification: Public WLM would probably be overkill, you should be able to extract its CPU and that of the TCPIP address space from the SMF30 records which go into your SMFINTRV file (CPUTM). Of course this will be the CPU for all uses of those address spaces. Stephen From: MXG Software LIST <[log in to unmask]> On Behalf Of MARTIN, MIKE Sent: Monday, January 29, 2024 1:52 PM To: [log in to unmask] Subject: [MXG-L] Measuring BPXOINIT CPU You don't often get email from [log in to unmask]. Learn why this is important *** This email is from an external source - be careful of attachments and links. Please 

[More ...]

Thank you Stephen,

I really like that idea.

Below is from a busy morning last week. BPXOINIT CPU seems surprisingly low to me, since one of our top CPU consumers is a CICS sockets transaction, so I may have to ponder that some more.

Thank you for your help.

Mike Martin

SMFTIME

CPUTM

JOB

25Jan2024:06:15:39.77

0:00:00.14

BPXOINIT

25Jan2024:06:16:25.05

0:00:44.28

TCPIP

25Jan2024:07:15:39.80

0:00:00.12

BPXOINIT

25Jan2024:07:16:25.08

0:01:00.46

TCPIP

25Jan2024:08:15:39.83

0:00:00.49

BPXOINIT

25Jan2024:08:16:25.10

0:01:31.10

TCPIP

25Jan2024:09:15:39.77

0:00:00.49

BPXOINIT

25Jan2024:09:16:25.05

0:02:18.80

TCPIP

25Jan2024:10:15:39.80

0:00:00.52

BPXOINIT

25Jan2024:10:16:25.08

0:02:16.09

TCPIP

From: MXG Software LIST <[log in to unmask]> On Behalf Of Hoar, Stephen (CIO GS&S - Core Infrastructure & 

[More ...]

Could it be that the sockets work goes to s specialty engine such as a ZIIP?

On Mon, Jan 29, 2024 at 8:47 AM MARTIN, MIKE <
[log in to unmask]> wrote:

> Thank you Stephen,
>
>
>
> I really like that idea.
>
>
>
> Below is from a busy morning last week. BPXOINIT CPU seems surprisingly
> low to me, since one of our top CPU consumers is a CICS sockets
> transaction, so I may have to ponder that some more.
>
>
>
> Thank you for your help.
>
>
>
> Mike Martin
>
>
 

[More ...]

Thanks Shawn,

I wouldn’t think so, but I will do some digging and try to find out for sure.

Mike Martin

From: MXG Software LIST <[log in to unmask]> On Behalf Of Shawn Beardsley
Sent: Monday, January 29, 2024 10:53 AM
To: [log in to unmask]
Subject: Re: [MXG-L] Measuring BPXOINIT CPU

CAUTION! This email is from an external source. Do not click on links or open attachments from unknown senders.
Could it be that the sockets work goes to s specialty engine such as a ZIIP? 

[More ...]

It might be helpful to know what "sort" of sockets transaction you are
referring to.
e.g.
Inbound? e.g. Standard CICS web services, or homegrown?
Outbound? persistent connections? using URIMAP to create thread pools?

I would imagine BPXOINIT would only come into play if you are using some
sort of llistener that is actively spawning new USS threads. 

[More ...]

Thanks Graham,

The RedPaper I was referring to, calls it “Communication Server IP Sockets”. More specifically, the “concurrent child server” model.
IBM CICS Performance Series: A Processor Usage Study of Ways into CICS<https://urldefense.com/v3/__https:/www.redbooks.ibm.com/redpapers/pdfs/redp4906.pdf__;!!ALsnuAY!GKXS36Wb_LNNPHgoF52sgHstegT9umhAFMk1O0Pcu1uDPjbI2mZILooIl-gARkPnpy3y0NUeGpUqdMgKweVw2ZzZknIgOm4eEt-I$>
In our shop, one CICS application uses IP Sockets is to obtain application data from another region. Our application folks want to replace it, but it would be good if we could compare before/after stats to understand what the impact is on CPU (since the transaction involved is one of our top transactions).
The IBM study (above) captured BPXOINIT CPU usage for the Communication Server IP Sockets.
 

[More ...]

Each MXG dataset built from data records defines a “_Kdddddd” macro which
can be used to KEEP (ADD) or DROP variables.

The dddddd value is defined in the IMACxxxx member for the xxxx SMF record token.

The syntax is, for your SYSIN is
%LET MACKEEP=
MACRO _Kdddddd list-of-variables-to-ADD DROP= list-of-variables-to-be-dropped %
;

%LET MACKEEP= MACRO _KTY1415 NEWTIME % ; 

[More ...]

Additionally for consideration, if the intent is to add a new variable name (derived at output time), likely as well as the SAS macro (old-style) _Kdddddd definition (user’s KEEP list addition), also the related MXG “output exit” macro _Edddddd is necessary as demonstrated below – see topic mention in SOURCLIB member DOCMXG: 

[More ...]

It’s driven by goal attainment – hence the WLM involvement.

Cheers, Martin

From: MXG Software LIST <[log in to unmask]> on behalf of Heimir Hauksson <[log in to unmask]>
Date: Thursday, 14 December 2023 at 11:24
To: [log in to unmask] <[log in to unmask]>
Subject: [EXTERNAL] [MXG-L] How does WLM/IRD determine weights?
We have a sysplex running on several physical boxes, with a number of systems on each box. This question is about one box and three systems on that box. Let us call the systems BIG, MEDIUM and SMALL, or B M S for short. B gets an increase in
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message 

[More ...]

To that point: goals that are being easily attained are going to make a workload more likely to be  donor (absent CPU critical). I believe when IRD weight changes are being considered, the projected goals are considered for the LPAR donors/receivers. So if you want to protect M more then I think you’d want to make sure the work there has “tighter” goals that are running right on the edge of missing and meeting their goals. In some cases, that may require assigning the work to different service classes based on the system, assuming it’s for work types where you 

[More ...]

When I set this up years ago in another shop -> we would specify minimum & maximum weights in the partition definitions, to set a floating range of capacity for a given system based on its needs. Perhaps you could tailor that to suit you needs.

Derrick Haugan
Sr. z/OS Mainframe Systems Engineer
Northwestern Mutual

I agree. Too many times I see goals that are too easily met. That leads
WLM to make bad decisions.

From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott
Chapman
Sent: Thursday, December 14, 2023 9:00 AM
To: [log in to unmask]
Subject: Re: [MXG-L] How does WLM/IRD determine weights?

To that point: goals that are being easily attained are going to make a
workload more likely to be donor (absent CPU critical). I believe when IRD
weight changes are being considered, the projected goals are considered for
the LPAR donors/receivers. So if you want to protect M more then I think
you'd 

[More ...]

You might find this redbook helpful
https://www.redbooks.ibm.com/redbooks/pdfs/sg245952.pdf
It is quite old (2001) but should cover the basics.

This topic should cover how it is now.
https://www.ibm.com/docs/en/zos/2.4.0?topic=management-intelligent-resource-director

As other have pointed out, the key is going to be how much 'spare' resources are on each box after their goals have been met, and how much 'weight' each box is guaranteed to have (min weight) 

[More ...]

Slightly off topic but I should point out that Logical CPU Management is gone from IRD - with HiperDispatch.

I agree with what's been said about lax (or overly right) goals.

I'm not a big fan of IRD Weight Managermnt, by the way. Especially since the advent of HiperDispatch. I'd rather see Automation shift the weights and manage physical and logical CPU numbers. 

[More ...]

Thanks for your responses. We will look into changing the minimum weights.
As M and S do very similar work the goals are basically the same and cannot be easily changed.

Heimir

Heimir Hauksson | Global z/OS Strategy | Infrastructure Services
Tel +44 (0)330 1535061 | Mobile +44 (0)7780 754767 | Email [log in to unmask]<mailto:[log in to unmask]>
Barclays Technology Centre Radbroke, Wilson House, GF A37, Knutsford, Cheshire, WA16 9EU (Mail Area 49)
Barclays.com 

[More ...]

Try having a look at CICTSR: CICS TRANSACTION STATS.

Presuming you do graceful shutdowns of the regions and no region abends.

Michael

At 10:40 AM 11/7/2023, MARTIN, MIKE wrote:

>Hi all,
>
>I'm having a senior moment.
>
>We do not collect CICS Performance Class 110 data. However, we do
>collect EOD statistics.
>
>What MXG dataset do I want to use - to report daily transaction
>count by TRANID for a Region (from our EOD stats) ?
>
>Ideally, I'd like to avoid populating a PDB to get the output I'm
>looking for.
>
>Mike Martin
>This email may 

[More ...]

And CICXMR: CICS TRANSACTION MANAGER TRANS might provide some further details.

Michael
At 10:54 AM 11/7/2023, Michael Oujesky wrote:

>Try having a look at CICTSR: CICS TRANSACTION STATS.
>
>Presuming you do graceful shutdowns of the regions and no region abends.
>
>Michael
>
>At 10:40 AM 11/7/2023, MARTIN, MIKE wrote:
>
>>Hi all,
>>
>>I'm having a senior moment.
>>
>>We do not collect CICS Performance Class 110 data. However, we do
>>collect EOD statistics.
>>
>>What MXG dataset do I want to use - to report daily transaction
>>count by TRANID for a Region (from our EOD stats) 

[More ...]

My observed experience is that CICS sites are finding it necessary to augment CICS CMF monitoring by adding sections/extensions (some referred to as "clocks and counters") and USER-area -- it's difficult enough to get buy-in with having a "standard MCT" at all......that creates challenges between z/OS platforms and/or CICS Release/Maint-levels within a particular sub-environment/SYSPLEX/shared-environment. 

[More ...]

In IBM's Customer Beta 16 Release of CICS/TS 6.2 there is a new feature that is automatic and can't be turned
off.

"Suppress SMF records with zero-counting fields" has major space reduction benefit by eliminating Statistics SMF 110 Subtype 2 records that have zero counts.

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Michael Oujesky
Sent: Friday, October 13, 2023 11:48 AM
To: [log in to unmask]
Subject: [MXG-L] Tailored CICS MCTs 

[More ...]

Edward Jones is.

Jim Poletti
Tech Mainframe Oversight
314-324-4689
Mainframe Oversight Request (ServiceNow)

If you are not the intended recipient of this message (including attachments) or if you have received this message in error, immediately notify us and delete it and any attachments.

If you do not wish to receive any email messages from Edward Jones, excluding administrative communications, please email this request to [log in to unmask] from the email address you wish to unsubscribe. 

[More ...]

For 10.2 domain statistics. Does not affect 110.1 performance class records.

Michael

At 01:43 PM 10/13/2023, Barry Merrill wrote:
>In IBM's Customer Beta 16 Release of CICS/TS 6.2 there is a new
>feature that is automatic and can't be turned
>off.
>
>"Suppress SMF records with zero-counting fields" has major space
>reduction benefit by eliminating Statistics SMF 110 Subtype 2
>records that have zero counts.
>
>-----Original Message-----
>From: MXG Software LIST <[log in to unmask]> On Behalf Of
>Michael Oujesky
>Sent: Friday, October 13, 2023 11:48 AM
>To: [log in to unmask]
>Subject: [MXG-L] Tailored CICS MCTs
>
>Just a quick survey- How many folks 

[More ...]

using IBM's sample tailored MCT samples? Or did you customize your own?

Michael

At 09:40 AM 10/14/2023, Poletti,Jim wrote:

>Edward Jones is.
>
>Jim Poletti
>Tech Mainframe Oversight
>314-324-4689
>Mainframe Oversight Request (ServiceNow)
>
>
>
>
>
>
>
>If you are not the intended recipient of this
>message (including attachments) or if you have
>received this message in error, immediately
>notify us and delete it and any attachments.
>
>If you do not wish to receive any email messages
>from Edward Jones, excluding administrative
>communications, please email this request to
>[log in to unmask] from the email address you wish to 

[More ...]

Customized our own.

Jim Poletti
Tech Mainframe Oversight
314-324-4689
Mainframe Oversight Request (ServiceNow)

If you are not the intended recipient of this message (including attachments) or if you have received this message in error, immediately notify us and delete it and any attachments.

If you do not wish to receive any email messages from Edward Jones, excluding administrative communications, please email this request to [log in to unmask] from the email address you wish to unsubscribe. 

[More ...]

1. The code in VMAC30:

IF LOADTIME GT 0 THEN DO;
DSPDLYTM=RESIDTM-SUM(CPUTCBTM,CPUSRBTM,CPUHPTTM,CPUIIPTM,CPURCTTM);
/* EXCLUDE CPISRBTM AND CPITCBTM INTENTIONALLY */
RESDLYTM=ACTIVETM-RESIDTM; /*MULTI-PROGRAMMING-LEVEL DELAY TIME*/
ACTDLYTM=EXECTM-ACTIVETM; /*NOT ACTIVE*DW/LW SWAP, IDLE*MT PEND*/
IF . LT ACTDLYTM LT 0 THEN ACTDLYTM=0;/*NEG RESULTS FM RESOLUTION*/
END;

1. The original Change:

Change 10.031 New variables ACTDLYTM/RESDLYTM/DSPDLYTM are now created

VMAC30 in TYPE30_4, TYPE30_V, PDB.STEPS and PDB.JOBS datasets. 

[More ...]

Hi Robert,

This doesn't answer your delay question, but have you seen the field called HICPUPCT? I found that field to be very useful when we implemented threadsafe in CICS.

[cid:image001.png@01D9F759.CC1BBC20]

Mike Martin

From: MXG Software LIST <[log in to unmask]> On Behalf Of Crawford Robert C (Contractor)
Sent: Wednesday, October 4, 2023 4:43 PM
To: [log in to unmask]
Subject: [MXG-L] DSPDLYTM 

[More ...]

No SMF data provides an aggregate (DASD?) storage-consumption metric – you may consider doing periodic DCOLLECT (non-SMF) data-collections, possibly not at the DATASET-level, and capture it in MXG for say hourly DASD pool/storage-group analysis.

Scott Barry
SBBTech LLC

From: MXG Software LIST <[log in to unmask]> On Behalf Of Keith Shaffer
Sent: Wednesday, October 4, 2023 3:47 PM
To: [log in to unmask]
Subject: [MXG-L] volume space 

[More ...]

I am only aware of products or snapshot utilities like DCOLLECT or
ISPF available for tracking volume space utiklization. I beleive
their used to be products that did interval sampling and recorded
those snapshots in FMF records, but that was long, lpng ago.

At 02:46 PM 10/4/2023, Keith Shaffer wrote:

>Does anyone know if there's an smf record (and hopefully a column in
>mxg) that would let me go back to an interval and see how much space
>was used (or free) on a volser? trying to do this with pure smf and
>not rely on any products
>Thanks for 

[More ...]

Are you trying to track down an issue with something(s) filling a volume? While it might not include the actual space, SMF type 15 can show each non-VSAM dataset opened for output, and contains job name, dataset name, and the volume(s). I think there’s a type 6x equivalent for VSAM datasets but I don’t know which one would show the actual space created when you define a cluster. 

[More ...]

Look at analcec

From: MXG Software LIST <[log in to unmask]> On Behalf Of
[log in to unmask]
Sent: Monday, October 2, 2023 8:33 AM
To: [log in to unmask]
Subject: [MXG-L] MXG - Soft Capping Information Needed

We have recently implemented (group) soft capping. I can find fields
which show me for each LPAR the PCT of time it was soft-capped, but nothing
for the CEC or capping Group over all. I am trying to create a report
which will show that soft capping is active/inactive (ideally by CEC.since
we are small and only have 1 group) and what the capping value is set to. 

[More ...]

Is that something new? Added after 40.05?

From: MXG Software LIST <[log in to unmask]> On Behalf Of Chuck Hopf
Sent: Monday, October 2, 2023 10:04 AM
To: [log in to unmask]
Subject: [EXTERNAL] Re: [MXG-L] MXG - Soft Capping Information Needed

CAUTION! This message was NOT SENT from DOMINION ENERGY
Are you expecting this message to your DE email? Suspicious? Use PhishAlarm to report the message. Open a browser and type in the name of the trusted website instead of clicking on links. DO NOT click links or open attachments until you verify with the sender using a known-good phone number. Never provide your DE 

[More ...]

YES - it is new

From: MXG Software LIST <[log in to unmask]> On Behalf Of
[log in to unmask]
Sent: Monday, October 2, 2023 9:22 AM
To: [log in to unmask]
Subject: Re: [MXG-L] MXG - Soft Capping Information Needed

Is that something new? Added after 40.05?

From: MXG Software LIST <[log in to unmask]
<mailto:[log in to unmask]> > On Behalf Of Chuck Hopf
Sent: Monday, October 2, 2023 10:04 AM
To: [log in to unmask] <mailto:[log in to unmask]>
Subject: [EXTERNAL] Re: [MXG-L] MXG - Soft Capping Information Needed 

[More ...]

I still do work but my ability to travel is limited.

I can do things remotely.

-----Original Message-----
From: MXG Software LIST <[log in to unmask]> On Behalf Of Poletti,Jim
Sent: Tuesday, August 29, 2023 9:42 AM
To: [log in to unmask]
Subject: [MXG-L] Chuck. Need some MXG work done

Chuck,

Hi, I'm a capacity perf person at Edward Jones. Our SAS MXG expert retired and we need our MXG upgraded to support various new software on the Z/os side.
Years ago you worked at Edward Jones to install MXG and SAS on a windows server. We still use windows for SAS , SAS EG and 

[More ...]

If you are comparing zOS to Linux that is consistent with results I have seen. Think about it. ON Z you are competing with sometimes hundreds of other tasks on Linux not so much. WE HAVE also found little benefit to Viya with MXG, ALSO SAS and ViyA use a lot of JAVA which generally runs slow on Z, 

[More ...]

I’m curious about this – has anyone seen presentations or discussions about the performance of Java on Z ?

Tim Hare
Interested Bystander, Non-Inc.

From: MXG Software LIST <[log in to unmask]> On Behalf Of Chuck Hopf
Sent: Wednesday, July 19, 2023 1:58 PM
To: [log in to unmask]
Subject: Re: [MXG-L] MXG Read SMF on Viya versus on LinuxDoes have anyone the sampe experi 

[More ...]

Pretty sure I did one back when I was a customer. At one point IBM even had a quote from me on some marketing flyer. (Which probably tells you where I stand on the issue.) I don’t think I’ve explicitly addressed it in a presentation since. Although maybe I should. 

[More ...]

Appears to have come in with 2.4:
<https://www.ibm.com/docs/en/zos/2.4.0?topic=xc-cross-system-coupling-facility-xcf-enhancements-zos-v2r4>Cross-System
Coupling Facility (XCF) enhancements for z/OS V2R4 - IBM Documentation
I would suggest having a look at TYPE74PA and the
new fields that came in with 37.166

Michael

At 09:04 AM 7/10/2023, Morrell, Kim wrote:
>Apparently this is new with zOS 2.4 – we have
>not implemented it yet. Just finished installing zOS 2.5
>
>I would like to get ahead of the new signally
>process before we make changes, I am looking for the pdb
>
>That would have the new metrics using XCF accounting and measurement services
>
>Thank you

Yes. It came in with 2.4 and is an XCF simplification measure. The extra metrics are a nice bonus.

Mark Brooks has presented on this, including at SHARE.

Cheers, Martin

Sent from my iPad

> On 12 Jul 2023, at 19:37, Michael Oujesky <[log in to unmask]> wrote:
>
> Appears to have come in with 2.4:
> <https://www.ibm.com/docs/en/zos/2.4.0?topic=xc-cross-system-coupling-facility-xcf-enhancements-zos-v2r4>Cross-System Coupling Facility (XCF) enhancements for z/OS V2R4 - IBM Documentation
> I would suggest having a look at TYPE74PA and the new fields that came in with 37.166
>
> Michael
>
> At 09:04 AM 7/10/2023, Morrell, Kim wrote:
>> Apparently this is 

[More ...]

Might look at www.intellimagic.com <http://www.intellimagic.com> & www.pivotor.com <http://www.pivotor.com> …

[log in to unmask] <mailto:[log in to unmask]>

From: MXG Software LIST <[log in to unmask]> On Behalf Of MARTIN, MIKE
Sent: Thursday, June 29, 2023 8:18 AM
To: [log in to unmask]
Subject: [MXG-L] z/OS Capacity Planning tool

Hi all,

This isn’t likely an MXG question, but this is probably the best group to ask... 😊

I’ve used IBM’s zPCR, but there is a lot of manual effort for planning different scenarios. Let’s say… a scenario that involves removing x% workload after 2.5 years and changing the growth rate then too. 

[More ...]

I’m willing to weigh in with some opinions based on my experience…

 
Ah… “budget friendly”.  Not so sure about that, other than Excel. And as you seem to understand, there’s some work involved there to build your spreadsheets. But it does force you think about your data and in more detail, which can be a good thing. (At least I find it so!) You can of course ask for a CP3K study from your business partner, but most of the CP3K studies I’ve seen don’t seem to be very sophisticated in relation to growth. That may of course may 

[More ...]

I second Scott's recommendation - Excel. We use a combination of data
pulled from MXG, imported into Excel with a ginormous amount of VBA to
automate the forecasting process.

On Thu, Jun 29, 2023 at 9:41 AM Scott Chapman <
[log in to unmask]> wrote:

> I’m willing to weigh in with some opinions based on my experience…
>
>
>
> Ah… “budget friendly”. Not so sure about that, other than Excel. And as
> you seem to understand, there’s some work involved there to build your
> spreadsheets. But it does force you think about your data and in more
> detail, 

[More ...]

You could use the _SMF macro that reads only the SMF header to select by APPLID:

// EXEC MXGSAS94
//SMF DD
//SMFOUT DD
//SYSIN DD *
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
IF APPLID IN ('CICS1','CICS2');
FILE SMFOUT DCB=SMF;
PUT _INFILE_;
FILE LOG;

You could also select by CICS Version

IF SMFPSRVR EQ 73; /*select only CICS/TS 5.6 APPLIDs*/

From: MXG Software LIST <[log in to unmask]> On Behalf Of Fernandez, Miguel A
Sent: Wednesday, June 28, 2023 12:45 PM
To: [log in to unmask]
Subject: [MXG-L] SMF110 Extract 

[More ...]

Likely / hopefully you are only passing SMF 110 data (subtypes 1 and 2) to MICS DAY040 (not that big an issue but still for consideration) and also be sure that any CICS "software compressed" regions' input data is decompressed prior to input (look to use DFH$MOLS or CA SMF DIRECTOR has an option to de-compression on-the-fly) - as well, you may want to consider turning off CICS compression if activated, given it's inherent CPU-overhead encountered during both compression and de-compression (inspect DFHMCT option-setting COMPRESS=YES, and also analyze CICCSU variable CSUCOMSW). 

[More ...]

Several years ago I wrote a set of IFASMFDP exits to segment our SMF
data by other criteria than IFASMFDP provided. Part of the criteria
it supported was by APPLID and DB2 sub-system as well as separating
out the CICS 110 dictionary records to be used as input to UTILEXCL
prior to each processing of performance class data. These exits also
separated out 110 records by management class, DB2 records selection
also had some IFCID selection capabilities. 

[More ...]

Forgot to mention that if y'all still have internal compression
enabled for CICS and DB#\w records, you might consider disabking it
to recover some of the CPU time in processing the data due to
decompression. As an alternative, if you are usinglog-stream,s
instead of MAN datasets and have zEDC available, compressing the
log-stream moves the compression off the GP engines. If the offload
extracts are on DASD, then consider using zEDC SMS compression on those. 

[More ...]

MXG PDB.SMFINTRV which is created from SMF type 30 subtypes 2 and 3 - also key here is that you must have INTERVAL RECORDING activated in your LPAR's PARMLIB SMFPRMxx member.

Regards,

Scott Barry
SBBTech LLC

From: MXG Software LIST <[log in to unmask]> On Behalf Of Longnecker, Dennis
Sent: Friday, June 23, 2023 11:21 AM
To: [log in to unmask]
Subject: [MXG-L] CPU Usage by Job 

[More ...]

Apologies for the unintended EMAIL-attachment (please disregard)....aggressive mouse-cursor action - good grief !!

From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott Barry
Sent: Sunday, June 25, 2023 5:58 PM
To: [log in to unmask]
Subject: Re: [MXG-L] CPU Usage by Job

MXG PDB.SMFINTRV which is created from SMF type 30 subtypes 2 and 3 - also key here is that you must have INTERVAL RECORDING activated in your LPAR's PARMLIB SMFPRMxx member. 

[More ...]

To elaborate on Scott's correct answer, member SMFINTRV will create the PDB.SMFINTRV dataset from
the SMF Interval TYPE 30 subtype 2 and 3 records and there are JCL examples in the comments.

The PDB.SMFINTRV dataset is used because it is the only source of address space level CPU and
other resources for each interval for your long running tasks, that never terminate and thus
do not write TYPE 30 Subtype 4 or 5 step/job termination records. 

[More ...]

And to correct my incomplete answer, PDB.SMFINTRV is the only source in SMF records,
but the RMF III dataset PDB.ZRBASI created by TYPERMFV reading the RMFBSAM records
created by ASMRMFV from the RMF III VSAM files not only provides interval data for
all address spaces, it can be created at 1 minute interval resolution to provide
significantly more detail on what's really happening in your z/OS system. 

[More ...]

Good afternoon...I was wondering if TSO and batch are different when it comes to the Type 30. We have a user complaining about an LPAR being slow and upon investigation CPU busy is fine, as is TSO response. Looking at the users active period I noticed one of his test jobs running. I checked Type77 for the time in question and sure enough JOBWANT1 is his TSO session waiting for his own job to complete. But he says the “system is slow.” When I looked at the DSENQTM for the specific user I was surprised to see it not as 

[More ...]

DSENQTM is an MXG Construct for the delay between Step Initiation Time and Allocation Time,
and really is a batch metric, as it has already occurred before the TSO User ever sees
the first READY!

Barry

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland
Sent: Monday, June 26, 2023 11:51 AM
To: [log in to unmask]
Subject: Re: [MXG-L] CPU Usage by Job 

[More ...]

These are the variables that we use for SMT calculations. These, however, are MICS variables, you would need to determine the equivalent MXG:

/* SMT VARIABLES WE ARE USING FOR ZIIP SMT SUPPORT: */
/* CPUSMTST - TIME WHEN EITHER ONE OR 2 THREADS EXECUTING */
/* CPUSMTMS - SMT MODE, 1 OR 2 */
/* CPUAVFAS - AVERAGE ACTUAL CAPACITY FACTOR (CF). I.E. */
/* BENEFIT RECEIVED FROM SMT (1 LE CF LE 2) */
/* CPUAVFMS - AVERAGE MAX CAPACITY FACTOR (MCF). I.E. */
/* ESTIMATE OF MAXIMUM WORK CORE CAN DO USING */
/* SMT WITH THE 

[More ...]

The SMT metrics are in the TYPE70EN dataset:

75

CPU ZIP NUMBER MT
BUSY PERCENT ENGINE OF SMT LPARBUSY CORE
PERCENT BUSY (DISPATCHED) TYPE SEGMENTS VALID? IDENTIFICATION SMT_LPAR_BUSY
Obs (PCTCPUBY) (PCTZIPBY) (SMF70TYP) (SMTSEGNR) (SMT_CORE_FLAG) (SMT_CORE_ID) (SMT_LPAR_BUSY)

1 19.1 . 0:CP 6 Y 00 189.842
2 10.0 8.2 2:ZIP 6 Y 01 87.934
3 . 4.2 2:ZIP 6 Y 01 .
4 0.8 0.6 2:ZIP 6 Y 02 6.841
5 . 0.3 2:ZIP 6 Y 02 .
6 9.5 . 0:CP 6 Y 03 88.732
7 39.4 . 0:CP 6 Y 00 384.641
8 12.6 10.4 2:ZIP 6 Y 01 111.012
 

[More ...]

Great stuff thanks! (courier new)

75

CPU ZIP NUMBER MT

BUSY PERCENT ENGINE OF SMT LPARBUSY CORE

PERCENT BUSY (DISPATCHED) TYPE SEGMENTS VALID? IDENTIFICATION SMT_LPAR_BUSY

Obs (PCTCPUBY) (PCTZIPBY) (SMF70TYP) (SMTSEGNR) (SMT_CORE_FLAG) (SMT_CORE_ID) (SMT_LPAR_BUSY)

1 19.1 . 0:CP 6 Y 00 189.842

2 10.0 8.2 2:ZIP 6 Y 01 87.934

3 . 4.2 2:ZIP 6 Y 01 .

4 0.8 0.6 2:ZIP 6 Y 02 6.841 

[More ...]

Good morning...interesting post (aren’t they all 😊) I noticed in our TYPE70EN data that our SMT* variables are blank so I’ll assume we don’t have SMT enabled. RMF will show what SMT mode provides via a ratio under the CPU Activity but what can we do to show management what the gains would be by enabling this? Our zIIPs are very heavy in xxxDIST DB2 work which I imagine other sites are as well. IBM site says this is the type of work that would gain with SMT enabled. The head scratcher for me is if this is a “good 

[More ...]

SMT is effectively a more/slower vs. fewer/faster trade-off. When two threads are executing simultaneously on the processor, they will contend for those core resources and will each effectively run slower. But in general youll likely get more work through the processor per unit of time. The magnitude of both is very workload dependent. 

[More ...]

Good morning...yes I would be interested...email is in my salutation...thanks!

Regards,

Doug Medland
Performance Analyst
Mainframe Performance and Capacity Management
Ph: (905) 316-1154
Email: [log in to unmask]

From: MXG Software LIST <[log in to unmask]> On Behalf Of Scott Chapman
Sent: Wednesday, May 31, 2023 10:56 AM
To: [log in to unmask]
Subject: [EXTERNAL] Re: [MXG-L] Determining SMT benefit

SMT is effectively a more/slower vs. fewer/faster trade-off. When two threads are executing simultaneously on the processor, they will contend for those core resources and will each effectively run slower. But in general you’ll likely get more
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from 

[More ...]

“why isn’t it a default?” -- historically, IBM doesn’t make new features or improvements the default because sites don’t like it when their environment changes without their knowledge. “Opt In” is the safe choice in a stable environment which depends upon change management controls for reliability.

Tim Hare
Interested Bystander, Non-Inc.

From: MXG Software LIST <[log in to unmask]> On Behalf Of Doug Medland
Sent: Wednesday, May 31, 2023 10:40 AM
To: [log in to unmask]
Subject: Re: [MXG-L] Determining SMT benefit 

[More ...]

The instrumentation doesn’t really speak to that. The statistics are at the LPAR level.

Also, which aspect of benefit? You could see in SMF 72-3 a potential reduction in zIIP delay or zIIP-on-GCP. Maybe report classes (of which more soon) are the right thing to analyse with this data.

On the other hand the slowing down of CPU-intensive jobs (if that happens) could be observed in SMF 30. Likewise for DDF via MF 101. You might discern reduction in queuing for zIIP in these two record types as well. 

[More ...]

The PDB.ASUMCELP dataset created by ASUM70PR from the TYPE70PR dataset contains those statistics for each LPAR in the CEC.

Barry

From: MXG Software LIST <[log in to unmask]> On Behalf Of Sarel Swanepoel
Sent: Tuesday, June 13, 2023 3:47 AM
To: [log in to unmask]
Subject: [MXG-L] RMF zIIP Values

Morning.

Our Systems Programmers make use of the TOTAL figure in the PHYSICAL zIIP PROCESSORS values for each LPAR per 15 minute interval . 

[More ...]

Thanks Barry

From: MXG Software LIST <[log in to unmask]> On Behalf Of MXG Support
Sent: Tuesday, June 13, 2023 5:32 PM
To: [log in to unmask]
Subject: Re: [MXG-L] RMF zIIP Values

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Classification: Public I suspect you were aiming this as MXG support rather than us but looking at your RMF report there are seven partitions whereas your excel chart has only six (the MXG graph only has five). Are you sure they are all from the same period? Stephen Hoar From: MXG Software LIST <[log in to unmask]> On Behalf Of Sarel Swanepoel Sent: Friday, June 9, 2023 8:54 AM To: [log in to unmask] Subject: [MXG-L] Anomalies in zIIP Percent Reporting *** This email is from an external source - be careful of attachments and links. Please report suspicious emails *** Hi, I received the following 

[More ...]

Thanks for the reply.

I have excluded them as they are only software test LPARS.

Sarel

From: MXG Software LIST <[log in to unmask]> On Behalf Of Hoar, Stephen (CIO GS&S - Core Infrastructure & IT Operations )
Sent: 09 June 2023 10:34
To: [log in to unmask]
Subject: Re: [MXG-L] Anomalies in zIIP Percent Reporting

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.