In another place where I worked, we set up a penalty LPAR. And
since Vendors wanted to bill by MSUs..... Well, that LPAR was
limited to maybe 10 MSUs. As I recall, they only got the SCRT
reports for that LPAR.
Just backing up what Paul said. And no, to my knowledge we didn't
work at the same place.
Also we had a TPM and it was set to route those products to the
penalty box/lpar, so there was no cheating.
Steve Thompson
On 5/7/2024 5:52 PM, Paul Feller wrote:
I'll go a little different route. If the real issue is with the dollars for
the software there is an interesting approach you could look at.
The place I worked at had setup some years ago several lpars that got grouped
together in a softcap capacity group. Then we forced jobs to run there based
on the software they ran. A good example for us was SAS and SAS/MXG stuff. We
had other software that also got forced there. This allowed us to save money.
Didn't have to pay SAS the full machine price for their software.
So, there are some things to consider.
You would need to have some spare MIPS and memory for two or three lpars on the
same CEC. We used three lpars. One prod, one test and one for the systems
programmers.
You would have to setup some type of routing scheme to get the jobs over to the
lpars. We used JES2 exits to do that. This way we didn't have to change JCL
to get the jobs run on those lpars. Naturally you would either use shared
spool or an NJE connection to get jobs routed and run.
It would be best if you are a sysplex so you could properly setup things like
WLM and GRS and your security product.
There maybe some work for your scheduling software and maybe your spool offload
product (if you have one).
You have to look at all the resources your SAS jobs need and how do you share
those resources across lpars.
I'm sure I missed something to mention.
Yes, this is a bit of work to setup.
The up side is you now have a place to run things like SAS that maybe have low
usage but high dollars. I think we had someplace between 6 to 10 software
products that we pushed to the environment. Basically, low usage software that
we needed but didn't like paying full price for.
Also, this assumes the software vendor plays nicely and agrees to charge based
on the softcap.
Paul
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Bob
Bridges
Sent: Tuesday, May 7, 2024 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe performance tool replacement
I think I'm about to reveal my obsolescence: Where my clients didn't use SAS,
they mostly used DYL-280II or QuikJob. Or REXX, of course.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Jonny snorted. "You mean out among the decadence of the big worlds? Come on, Jame, you
don't really believe that sophistication implies depravity, do you?" / "Of course not.
But someone's bound to try and convince you that depravity implies sophistication." From
_Cobra_ by Timothy Zahn */
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
raji ece
Sent: Tuesday, May 7, 2024 8:20 AM
We have been running with SAS and MICS software to analysis system performance
and to produce reports on daily basis.
There is a situation to come out of using SAS due to many reasons.
We would like to know the alternate product for this SAS and MICS.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Regards,
Steve Thompson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN