Re: Progam directory AD/Cycle C/370

[Jan Vanbrabant]

Is/was the a PGMDIR,  Peter?

https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd&subtype=sm&htmlfid=897/ENUS5688-216

Jan

On Tue, Dec 15, 2020 at 10:19 AM Peter  wrote:

> Hello
>
> Does anyone have a copy of Progam directory AD/Cycle C/370 1.2 ?
>
> I don't find the installation manual over web might be due to backlevelled
>
> Any pointers ?
>
> Peter
>
> --
> 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

Re: (My) John Ehrman Assembler Book

[Jan Vanbrabant]

:-

I feel 40 yeras younger!

Thanks John,   what a wealth!!

Jan



On Mon, Feb 9, 2015 at 7:40 PM, John Ehrman  wrote:

> Richard Lawrence posted:
> >The long awaited John Ehrman Assembler book as available at the
> >Marist College web site:
>
> >
>
> http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language%20Programming%20for%20IBM%20z%20System%20Servers.pdf
>
> I appreciate the many kind comments posted on these discussion lists.
>
> Please note that some fixes will be in the next update:
> (1) The fragmentary index after the preface/introduction will be removed.
> (2) The solutions for sections 25 and 26 will be restored.
> (3) Various typographic errors will be fixed.
> (4) Some minor text reorganizations.
>
> Rather than adding change bars, I plan to add an "Updates" section
> somewhere at the front or back of the text explaining differences from
> version to version.
>
> After those are finished:
> (n) I'm currently preparing some "lecturer materials" like presentation
> slides.
> (n+1) A major item will be to add hyperlinks for contents and
> cross-references.
> (n+2) I apologize, Lizette, but I doubt I'll add another 1200 pages any
> time soon.
>
> John Ehrman (ehr...@us.ibm.com)
>
> --
> 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

Re: z/OS System Initialization Logic (IPL)

[Jan Vanbrabant]

:-)))

I always kept the first version of 5 years ago!
IPLSTATX and IPLSTATZ weren't there yet.
Jan


On Wed, Jul 16, 2014 at 12:24 AM, Don Imbriale 
wrote:

> For those interested, came across the following:
>
> http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS3699
>
> --
> 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

Re: PFA (Now, an HZR subject)

[Jan Vanbrabant]

Radoslaw,

A redbook not being a real "official" manual,
look at
G325-2564-09  zOS V1R13.0 Problem Management  (e0z1k151)
page 39-45Runtime Diagnostics symptoms
http://publibfp.dhe.ibm.com/epubs/pdf/e0z1k151.pdf

or

http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.e0zk100%2Frtdch.htm


jan





On Wed, May 7, 2014 at 12:08 PM, R.S. wrote:

> W dniu 2014-05-06 13:29, Karla Arndt pisze:
>
>  Runtime Diagnostics (HZR) does 7 types of analysis only one of which has
>> any association with OPERLOG.
>>
> Side question: where is it documented? I mean Runtime Diagnostic
> documentation.
> I can't find the manual.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> ---
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru
> przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień
> 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi
> 168.696.052 złote.
>
>
>
> --
> 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

Re: PFA (Now, an HZR subject)

[Jan Vanbrabant]

Radoslaw,

SG24-8070-00 Extending z/OS System Management Functions with IBM zAware (z
Advanced Workload Analysis Reporter) (august 1, 2013)

page 32-42  2.4  Runtime Diagnostics

· Runtime Diagnostics searches OPERLOG for any occurrences of an
IBM-defined list of messages that are deemed to be critical tosystem
availability.

· Runtime Diagnostics detects three types of global resource
contention

o   Enqueue contention for system address spaces

o   GRS-managed latch contention

o   z/OS UNIX System Services file system latch contention

· Runtime Diagnostics provides three types of checking to determine
whether execution within any address space is behaving abnormally such that
it might cause a soft failure.

o   CPU analysis

o   Local lock suspension

o   TCB loop detection

 http://www.redbooks.ibm.com/abstracts/sg248070.html

jan


On Wed, May 7, 2014 at 2:37 PM, Dana Mitchell  wrote:

> On Wed, 7 May 2014 12:08:27 +0200, R.S. 
> wrote:
> >Side question: where is it documented? I mean Runtime Diagnostic
> >documentation.
> >I can't find the manual.
> >
> >--
> >Radoslaw Skorupka
> >Lodz, Poland
>
> Radoslaw,
>
> I found it in the z/OS 1.13 "Info center"  and the heading on the section
> "Enabling Runtime Diagnostics" states:
>
> z/OS Problem Management
> G325-2564-09
>
> Dana
>
> --
> 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

Re: Does z/OS 2.1 support COBOL 4.2?

[Jan Vanbrabant]

Re.   Effective ?Jan 1?, 2014, Cobol 3 and 4 prices will be raised to match
Cobol


True.

But going COBOL 5.1 may possibly be a serious migration/upgrade project.
Look at several COBOL 5.1  and/or PDSE threads earlier this month, all  the
consequence of the 5.1 executables having to reside in PDSEs, no longer in
PDSs.
PDS/E, Shared Dasd, and COBOL
V5
*(81 messages)   *entre autres


jan


On Wed, Sep 18, 2013 at 5:39 PM, Mike Schwab wrote:

> Effective ?Jan 1?, 2014, Cobol 3 and 4 prices will be raised to match Cobol
> 5.
>
>
> On Wed, Sep 18, 2013 at 10:24 AM, Rouse, Willie 
> wrote:
>
> > Hello All,
> >
> > I would like to know where to find what IBM products z/OS 2.1 supports.
> >
> > Respectfully,
> > Willie C. Rouse
> >
> >
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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

Re: Does z/OS 2.1 support COBOL 4.2?

[Jan Vanbrabant]

Good question!

Because  the "Software Product Compatibility Reports" tool
http://pic.dhe.ibm.com/infocenter/prodguid/v1r0/clarity/index.jsp
doesn't know anything (yet) about z/OS V2.1.
I did a fdbk about this. No answer yet.


But I'm sure z/OS V2.1 supports COBOL 4.2
Often in the announcement letters under "Software requirements"  is
indicated such a thing as:
   Version/Release  xyz  or  later.
Didn' check the 4.2 announcement letter, but i'm sure  the  wrote:

> Hello All,
>
> I would like to know where to find what IBM products z/OS 2.1 supports.
>
> Respectfully,
> Willie C. Rouse
> Senior Mainframe Consultant
> Prince George's County, Maryland
> Office of Information Technology
> 9201 Basil Court/ Room B8
> Largo, MD 20774
> Voice: 301-883-7189
> Fax: 301-883-3790
>
>
>
> --
> 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

Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)

[Jan Vanbrabant]

Hi listers,

The base IOS apar
OA41040 has been closed.

It contains now:

*V1R13 GA23-0854 z/OS MVS  Data Areas, Volume 2
 http://publibz.boulder.ibm.com/zoslib/pdf/IOSDFBA_113.pdf

*V1R13 GA32-0855 z/OS MVS Data Areas, Volume 3
 http://publibz.boulder.ibm.com/zoslib/pdf/IOSDIOST_113.pdf

*V1R13 SA22-7608 MVS Programming Authorized Assembler Services
*Guide
 http://publibz.boulder.ibm.com/zoslib/pdf/IOSFBASC_113.pdf

 *Chapter 32. z/OS FBA services*

*V1R13 SA22-7610 MVS Programming Authorized Assembler Services
*Reference
 http://publibz.boulder.ibm.com/zoslib/pdf/IOSFBA_113.pdf

  *Chapter 96. IOSFBA — IOS fixed block architecture service*

*V2R1 GA32-0855 zOS MVS Data Areas, Volume 3
 http://publibz.boulder.ibm.com/zoslib/pdf/IOSDIOST_21.pdf

*V2R1 SA22-7610 MVS Programming Authorized Assembler Services
*Reference
 http://publibz.boulder.ibm.com/zoslib/pdf/IOSFBA_21.pdf

jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: GIMZIP (was: free zIP/UNZIP in z/OS)

[Jan Vanbrabant]

Hi dear IBM-MAINers,

First of all  a BIG THANK YOU for your 30+ reactions !!!

This situation is one between z/OSs!
The other site is zipping with PKZIP.

GIMZIP is charming my client.

Question though:
While PKZIP en GIMZIP have both "zip"in common in their namings,
is GIMZIP's "zip-format" compatible with  PKZIP's "zip-format" ?

Rgds,
Jan




On Tue, Jun 25, 2013 at 10:31 PM, Kurt Quackenbush  wrote:

> Given my (unfounded?) assumption that GIMZIP was devised to
>> support SMP/E installation and service, it's puzzling that GIMZIP
>> supports objects SMP/E doesn't process.  Are they intended for
>> use in a post-APPLY script?
>>
>
> Have you heard of ServerPac?  GIMZIP and GIMUNZIP are integral to the
> internet delivery and installation of an IBM ServerPac offering, that is
> why GIMZIP supports non-SMP/E consumable file formats in addition to the
> standard SMP/E stuff.
>
> Kurt Quackenbush -- IBM, SMP/E Development
>
>
> --**--**--
> 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

free zIP/UNZIP in z/OS

[Jan Vanbrabant]

Hi,

My customer is looking for a freeware ZIP/UNZIP.
The 2013 budget doesn't allow him to acquire a fee one.

I looked a bit around & found

Info-ZIP   http://www.info-zip.org/pub/infozip/Zip.html

IBM Ported Tools for z/OS ---  Supplementary Toolkit --- bzip2

http://www-03.ibm.com/systems/z/os/zos/features/unix/ported/suptlk/index.html

The free ones aren't as functional as the fee ones of course (PKZIP,
ZIP/390, SLIKZIP);  think bout encryption, zIIP support, UNIX file system
support, …).


Any  experiences to share?

Possibly  other tools  (free, of course  ;-)   )   ?

Advices?


Rgds,
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

free zIP/UNZIP in z/OS

[Jan Vanbrabant]

Hi,

My customer is looking for a freeware ZIP/UNZIP.
The 2013 budget doesn't allow him to acquire a fee one& apparabtly his need is 
now.

I looked a bit around & found

Info-ZIP   http://www.info-zip.org/pub/infozip/Zip.html

IBM Ported Tools for z/OS ---  Supplementary Toolkit --- bzip2

http://www-03.ibm.com/systems/z/os/zos/features/unix/ported/suptlk/index.html


The free ones aren't as functional as the fee ones of course (PKZIP, ZIP/390, 
SLIKZIP);  think bout encryption, zIIP support, UNIX file system support, …).


Any  experiences to share?

Possibly  other tools  (free, of course  ;-)   )   ?

Advices?


Rgds,
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

zIIP enablement with BMC

[Jan Vanbrabant]

Hi,
Is thee some documentation or some article which globalizes all (BMC
products which are zIIP-capable?
Is it correct that zIIP-capable offloading is discovered by the tools and
utilities themselves and that it starts by itself (without parametrization,
I mean),  *IF*  they are at the correct maintenance levels of course?
Rgds,
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: To recompile or not recompile, that's the question

[Jan Vanbrabant]

Hi to you all, wise gal and guys,

THANK YOU SINCERELY for all your valuable réactions!

I think the overall conclusion might (!) be:
the techies seem  rather to be PRO-recompile,  while the more development
oriented people  CONTRA-recompile and hence PRO-copying, and this certainly
between ACCEPTANCE and PRODUCTION !

I am a techie, and hence rather PRO-re-compile, while I adore technical
beauties, much more than the application solution.
But these wise considerations about regression testing and its managing
burden when re-compiling lead to my final conclusion:

A chacun son métier !.

"Every man to his own trade!"   (does this sound english enough ?;-)
  )

We can't be good at everything

Cheers to you all.

Jan



On Mon, Jun 3, 2013 at 1:27 PM, Jan Vanbrabant wrote:

> Hi John,  Peter,
>
> *>> Re.  I am also suspicious of Jan Vanbrabant's esclusion of
> homologation from this discussion.  The word is derived from the ancient
> Greek verb homologein, to approve, which becomes homologare, to agree, in
> fairly late Latin.  (It has a special meaning in Scots law, where it is
> used to characterize a process of removing minor defects from contracts,
> the remediated versions of which are then given the force of law.)*
>
> *> Re.   As for Jan Vanbrabant's stage names, HOMOLOGATION easily
> translates to "(Internal or Product) Quality Assurance" and ACCEPTANCE to
> "Client Test".  My organization uses both, though not in disparate
> technical or physical environments, and always without recompilation.*
> This is exactly what it means, Peter !
>
> Jan
>
>
> On Fri, May 31, 2013 at 9:40 PM, Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
>
>> The problem with recompilation is not purely technical though.  ISTM that
>> there is far more bureaucracy needed to monitor and guarantee successful
>> completion of full regression testing at each recompilation than there is
>> payback from using notionally "better" translators and runtimes at a given
>> stage.
>>
>> In the case where each stage from development to production may reside on
>> physically and/or technically disparate systems, I admit that recompilation
>> seems like a reasonable solution to ensure accurate and effective execution
>> at each stage, but again ISTM that the additional verification requirements
>> are far too onerous a cost both technically and bureaucratically.
>>
>> IMHO, of course.  We can certainly agree to disagree on this.
>>
>> As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to
>> "(Internal or Product) Quality Assurance" and ACCEPTANCE to "Client Test".
>>  My organization uses both, though not in disparate technical or physical
>> environments, and always without recompilation.
>>
>> Peter
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of John Gilmore
>> Sent: Friday, May 31, 2013 2:40 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: To recompile or not recompile, that's the question
>>
>> Predictably I suppose, recompilation gets my vote.  The issues
>> involved are technical and not management ones, and bureaucratizing
>> them never helps.
>>
>> Development takes some time, and linking the development version of a
>> PL/I compiler to that in current production use is always a bad  idea.
>>  It ensures that retrograde technology and performance will be wired
>> into newly developed systems.  (This may happen anyway, of course; the
>> use of the best  translator is a necessary but not a sufficient
>> condition for high performance.  That use can be, often is,
>> perfunctory.)
>>
>> I am also suspicious of Jan Vanbrabant's esclusion of homologation
>> from this discussion.  The word is derived from the ancient Greek verb
>> homologein, to approve, which becomes homologare, to agree, in fairly
>> late Latin.  (It has a special meaning in Scots law, where it is used
>> to characterize a process of removing minor defects from contracts,
>> the remediated versions of which are then given the force of law.)
>>
>> If, as I suspect, homologation here has to do with ensuring that a
>> systems meets its functional specifications, it is relevant.
>>
>> John Gilmore, Ashland, MA 01721 - USA
>> --
>>
>> This message and any attachments are intended only for the use of the
>> addressee and may contain information that is privileged and confidential.
>> If the reader of the message is not the intended recipient or an authorized
>> r

Re: To recompile or not recompile, that's the question

[Jan Vanbrabant]

Hi John,  Peter,

*>> Re.  I am also suspicious of Jan Vanbrabant's esclusion of homologation
from this discussion.  The word is derived from the ancient Greek verb
homologein, to approve, which becomes homologare, to agree, in fairly late
Latin.  (It has a special meaning in Scots law, where it is used to
characterize a process of removing minor defects from contracts, the
remediated versions of which are then given the force of law.)*

*> Re.   As for Jan Vanbrabant's stage names, HOMOLOGATION easily
translates to "(Internal or Product) Quality Assurance" and ACCEPTANCE to
"Client Test".  My organization uses both, though not in disparate
technical or physical environments, and always without recompilation.*
This is exactly what it means, Peter !

Jan


On Fri, May 31, 2013 at 9:40 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> The problem with recompilation is not purely technical though.  ISTM that
> there is far more bureaucracy needed to monitor and guarantee successful
> completion of full regression testing at each recompilation than there is
> payback from using notionally "better" translators and runtimes at a given
> stage.
>
> In the case where each stage from development to production may reside on
> physically and/or technically disparate systems, I admit that recompilation
> seems like a reasonable solution to ensure accurate and effective execution
> at each stage, but again ISTM that the additional verification requirements
> are far too onerous a cost both technically and bureaucratically.
>
> IMHO, of course.  We can certainly agree to disagree on this.
>
> As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to
> "(Internal or Product) Quality Assurance" and ACCEPTANCE to "Client Test".
>  My organization uses both, though not in disparate technical or physical
> environments, and always without recompilation.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Gilmore
> Sent: Friday, May 31, 2013 2:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: To recompile or not recompile, that's the question
>
> Predictably I suppose, recompilation gets my vote.  The issues
> involved are technical and not management ones, and bureaucratizing
> them never helps.
>
> Development takes some time, and linking the development version of a
> PL/I compiler to that in current production use is always a bad  idea.
>  It ensures that retrograde technology and performance will be wired
> into newly developed systems.  (This may happen anyway, of course; the
> use of the best  translator is a necessary but not a sufficient
> condition for high performance.  That use can be, often is,
> perfunctory.)
>
> I am also suspicious of Jan Vanbrabant's esclusion of homologation
> from this discussion.  The word is derived from the ancient Greek verb
> homologein, to approve, which becomes homologare, to agree, in fairly
> late Latin.  (It has a special meaning in Scots law, where it is used
> to characterize a process of removing minor defects from contracts,
> the remediated versions of which are then given the force of law.)
>
> If, as I suspect, homologation here has to do with ensuring that a
> systems meets its functional specifications, it is relevant.
>
> John Gilmore, Ashland, MA 01721 - USA
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> --
> 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

To recompile or not recompile, that's the question

[Jan Vanbrabant]

Hi wise guys and gals,



HOW are you in your shop managing your sources and load modules and the
versions of compilers and z/OS?



*Intro:*

My customer (a data center) has several environments/LPARs:

1.   SYSTEMS environment   (for the system programmers team:
installations, system tests, …)

2.   DEVELOPMENT environment (for the application developers)

3.   HOMOLOGATION environment (it doesn’t matter for the discussion
what it’s purpose is)

4.   ACCEPTANCE environment

5.   PRODUCTION environment

They deploy the installations of z/OS  in that order. I.e. PRODUCTION at
the end of the chain.

Idem for the compiler versions.



The development department also deploy their applications in that very same
order.





Till now, the application programs are RE-COMPILED in each environment;
this in order to avoid the slightest problem.  For example:

· Runtime LE 1.13 in development and  runtime LE 1.12 in production
MIGHT possibly generate a different behavior if the applications were not
recompiled

· A program compiled with the highest PL/1 version and executing
with a too low LE might also have problems.





The customer is considering now to use Serena’s ChangeMan/ZMF to manage the
application sources and load modules.  That  tool does not really support
re-compile.

Consequence:

The modules, compiled in development, are COPIED to the different
environments tlll into the PRODUCTION environment eventually. In concreto:
if development is done in z/OS R13 with the highest PL/1 compiler
version,  this
load module finally executes in z/OS R12.  This too MAY generate problems.

The problem can be avoided  by NOT upgrading  the development environment
before the production environment, but rather at the end of chain.



In what order do you do the different environment upgrades in your shop?
Development before production? Production before development?



*A last consideration:*

Thinking of the latest HW announcements of zEC12 and the last C/C++ , PL/1
4.2, or COBOL 5.1 announcements, the synergy between HW & SW is definitely
growing.  Think of ARCH(10),  or zEC12’s TEF ( Transactional Execution
Facility).

· If development is at a higher SW level than production,  then
COPYING (in stead of RE-COMPILE) might cause execution problems in
production.

· If development is not at the latest SW level,  one might not take
profit in production of those newer HW capabilities such as ARCH(10) or TEF.



Please, your thoughts!

Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

CICS V3.2 and IMS/DB 12

[Jan Vanbrabant]

*** Cross-posted to CICS-L, IMS-L and IBM-MAIN listservers ***

Hi,


Any problems/caveats/does/don'ts with  IMS/DB V12  connected to CICS V3.2 ?


A customer of mine will go CICS V4.2,  but his installation upgrade
planning starts with IMS/DB V12(coming from UNsupported IMS/DB V9).

IMS 12's announcement letter
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS211-365#h2-techinfx
indicates:
"IMS 12 DB can be connected using the appropriate interface to IMS 12 TM
(5635-A03), CICS Transaction Server for z/OS V3.1 (5655-M15), or later, ...
etc ..."

Hence my question in the beginning:
Any problems/caveats/does/don'ts with  IMS/DB V12  connected to CICS V3.2 ?

Jan Vanbrabant, dynosaur SE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ROTs and/or considerations and/or doc about *PROC Speed (Workflow) (WFEX), ERV, CCCAWMT

[Jan Vanbrabant]

Hi,


I didn't find any additional doc  or considerations about these 3 items
than what's indicated in the manuals.

1°   WFEX report (RMF Mon III) --- DELAY Indicator --- Field: *PROC Speed
(Workflow) Guideline:

If this value is low (less than 40%), it may be due to CPU delay.  If this
value is greater than 80%, there is no CPU problem.

2°   ERV=500 (“enqueue residency” time) in IEAOPT



3°   CCCAWMT (Alternate Wait Management)  about the low utilization effect
for HIPERDISPATCH=YES:  the valid range is 1600 to 3200, with 3200 being
the default value.

Do yo have any pointers to additional  doc?  Any considerations?  ROTs?

Cheers,
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ''MVS overhead'' (as indicated by OMEGAMON)

[Jan Vanbrabant]

Thanks to you all for your thoughts and good advice so far!*
*
Horst,

*Re. you saying:
(IMHO the term "overhead" is misleading, 'management time' would be more
accurate).*

What do you mean by this?
Simply stated:   overhead is all wat is NOT 'captured' on some application
or  sw component.
LPAR Mgt time  for example *is* reported.

So, what are you having in mind?
Work Load Mgr ?(your beloved  'baby'  ;-))

Jan


On Thu, Feb 21, 2013 at 5:21 PM, Horst Sinram  wrote:

> Jan,
>
> it appears the monitor is trying to tell you that you have a low "capture
> ratio". Searching for that term should give you a good understanding of
> what the message really means, and in a lot of good advice, e.g. in the
> "Effective zSeries Performance Monitoring Using Resource Measurement
> Facility" publication. (IMHO the term "overhead" is misleading, 'management
> time' would be more accurate).
> If you believe there might be a problem you may want to start with
> verifying LPAR configuration and IEAOPTxx settings (any obscure timing
> parameters? Anything violating recommendations?). You could also verify
> that the capture ratio is indeed low using SMF70/72 data.
>
> Phantom weight is irrelevant in this context. It is only a vehicle to tell
> PR/SM how to cap the partition. The fact that the LPAR *is* capped at that
> time (to what extent?) may very well be relevant, though: More work, longer
> work queues...
> CPUMF counters won't help you diagnosing anything. CPUMF sampling could
> help -theoretically- but the data may be very hard to evaluate.
>
> Horst Sinram - IBM z/OS Workload Management
>
> --
> 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

Re: ''MVS overhead'' (as indicated by OMEGAMON)

[Jan Vanbrabant]

Hi Dave & co-listers,

1°
Is  OMEGAMON capable of drilling down into "MVS Overhead" ?
If not, how can further PD (Problem Detemination) be done?
2°
Is the CPU-MF HIS approach based on SMF113 not too  long-winded and
over-doing?

CPU-MF (HIS)  NOT being a substitute for traditional performance nor
capacity metrics.  And it does NOT indicate either the capacity being
achieved by the LPAR or processor

3° Where is "*phantom load*"   (or a *“phantom” logical partition) *
and  "*cap(ping)
pattern*" reported?  IF reported.   Or where can we find it?

SG24-6472-03 System Programmer's Guide to  Workload Manager (WLM) (last
update 20 april 2010) (applies to zOS V1R8 - Maart 2008)
http://www.redbooks.ibm.com/abstracts/sg246472.html
3.4 Soft capping   (page 101 ... etc ...)
3.4.1 *Defined capacity*
When WLM caps the logical partition, there are three possible scenarios:
 *1° The percentage share of the logical partition processing weight is
equal to the percentage share of the defined capacity.*  *(relative weight
= defined capacity)*
In this case, the capping is done at the logical partition processing
weight. This is the best and recommended situation.
 2° *The percentage share of the logical partition processing weight is
greater than the percentage share of the defined capacity.*   *(relative
weight > defined capacity)*
In this case, capping at the weight has no effect, because the logical
partition has more MSU than allowed. To enforce the percentage share of
WLC, PR/SM subtracts a certain number from the logical partition processing
weight to match the desired percentage share and calculates a *“phantom”
logical partition* that receives the remaining unused weight. This
guarantees that other logical partitions are not affected by the weight
management, because the total logical partition processing weight stays the
same.
* 3° The percentage share of the logical partition processing weight is
lower than the percentage share of the defined capacity.*   *(relative
weight < defined capacity)*
WLM defines a cap pattern that repeatedly applies and removes the cap at
the logical partition processing weight. Over time, this looks as though
the partition is constantly capped at its defined capacity limit.
The *cap pattern* depends on the difference between the capacity based on
the weight and the defined capacity limit. If the weight is small compared
to the defined capacity, the capacity of the partition can be reduced
drastically for short periods of time. This can cause performance to
suffer. Therefore, we recommend to keep both definitions as close as
possible.

Where is "phantom load" or the "phantom logical partition" reported?   (IF
reported !?)Where is "cap(ping) pattern" reported? (IF reported !?)
RMF ???

Is "cap pattern"  part of the "MVS Overhead" ?  Because WLM must be working
like hell.

Please, enlighten us.
Jan


On Fri, Feb 15, 2013 at 12:48 AM, Dave Barry  wrote:

> Jan,
>
> The description of MVS overhead in the User Guide is technically correct.
>  You might think of it as uncaptured time--basically hardware overhead not
> attributable to an address space or service class measurement taken by RMF.
>  That includes interrupt handling due to I/O, page faults, etc., performed
> in supervisor state.  I think some listers may dicker over the fine points,
> but the traditional way of apportioning this overhead is by attribution of
> I/O activity.
>
> The MVS overhead reading will fluctuate.  If you have more than one CP, it
> is not uncommon to see TCB and enclave percentages greater than 100.  The
> unnormalized, sliding scale runs from times-one to times-the number of CPs.
>  That is, an LPAR with two CPs running at a (normalized) level of 75
> percent overall can display as "150 percent of 200 percent."  The
> unnormalized value makes it easier to compare machines with different
> numbers of CPs, but if you want Omegamon to normalize the numbers to 100
> percent, you have the option.
>
> In my observation, as the underlying hardware architecture becomes more
> complex, MVS overhead has become less well correlated to interrupt rates.
>  You may not be able to do much about it, but you might try comparing your
> systems on the basis of SMF type 113 data from Hardware Instrumentation
> Services (HIS).  A higher or lower Relative Nest Intensity (RNI),
> indicating a less processor-cache-friendly workload mix, may help explain
> the differences in uncaptured time.  A good explanation can be found in
> "LSPR Workload Categories" on IBMs Web site at
> https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprwork?OpenDocument
> .
>
> Sorry if this is more than you wanted to know, but IBM-MAIN is definitely
> a good place to ask.
>
> Dave Barry
> Doctor of Omegamology
>

Re: Defined capacity

[Jan Vanbrabant]

Aaah,   I think I've found the clue:
Understanding and Controlling LPARs  (draft whitepaper V3)  (ZSW03077USEN)
ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/zsw03077usen/ZSW03077USEN.PDF
page 4 !

** Why is this EXCELLENT paper still a draft ???* *

I think I've been confused by  the terms "Relative Weight"  or  "initial
processing weight"  in IRD's HARDCAP world
While I was more interested in the SOFTCAPPING - "defined capacity" -
4-hour rolling average world.

Anyway, isn't the remark on page 2 of the same document not a bit confusing?
*PLEASE KEEP IN MIND:  Defined Capacity is only availabe when there is no
hardcap  (that is the relative weight is NOT enforced).  Please note that
the HMC will allow you you to set both a defined capacity and enforce the
relative weight... But WLM will ignore the defined capacity.*

jan


On Fri, Feb 15, 2013 at 8:30 AM, Jan Vanbrabant wrote:

> Thanks Fabio.
>
> I have read about the 3 possible scenarios when WLM asks PR/SM to cap the
> logical partition at the HMC-defined weight value.   (page 102-103 of the
> redbook)
> I encounter what Kees was talking about (phantom load or “phantom” logical
> partition   &  cap pattern that repeatedly applies and removes the cap at
> the logical
> partition processing weight..)
> But my lack of understanding still remains.  I must be missing some
> essential piece.
>
> Jan
>
>
>
> On Wed, Feb 13, 2013 at 6:40 PM, Fabio Massimo Ottaviani <
> fabio.ottavi...@epvtech.com> wrote:
>
>> Hi Jan
>> Redbook - WLM System Programmer Guide - Chapter 3
>> Best regards
>> Fabio
>> +
>> + Fabio Massimo Ottaviani
>> + EPV Technologies Technical Director
>> + Skype: fabio.massimo.ottaviani
>> + Mobile: +393406168088
>> +
>> + IT Cost under Control
>> + www.epvtech.com
>> +
>>
>>    Please consider the environment - do you really need to print this
>> email?
>>
>> -Messaggio originale-
>> Da: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Per
>> conto di Jan Vanbrabant
>> Inviato: mercoledì 13 febbraio 2013 17:13
>> A: IBM-MAIN@LISTSERV.UA.EDU
>> Oggetto: Re: Defined capacity
>>
>> Hi Kees,
>>
>> I'm following this thread. (Learning a lot doing this...)
>>
>> Whare can I find more about  'phantom load' and 'capping pattern'?
>> Didn't find these terms in de 2 WLM manuals you mentioned earlier:
>>
>> SA22-7602-19z/OS V1R12.0 MVS Planning Workload Management
>> SA22-7999-06z/OS V1R12.0 Planning for Subcapacity Pricing
>>
>> (I am at R12, so I looked in the R12 manuals)
>>
>> Jan
>>
>> On Tue, Feb 12, 2013 at 4:00 PM, Vernooij, CP - SPLXM <
>> kees.verno...@klm.com
>> > wrote:
>>
>> > Yes, LPAR Clusters are IRD managed groups of LPARs.
>> >
>> > Don't forget to read about Weight in relation to 'phantom load' and
>> > 'capping pattern', to avoid erratic Lpar performance.
>> >
>> > I always like to have a monitor telling what is going on in the
>> > system, so I will not be surprised by angry telephone calls and have
>> > no clue where to start looking. I use Mainview, I don't know RMF, but
>> > it probably also displays the 4HrRA, the current LPAR utilization and
>> > the status of softcapping, so you know why the system is doing what it
>> is doing.
>> >
>> > HTH,
>> > Kees.
>> >
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> > On Behalf Of R.S.
>> > Sent: Tuesday, February 12, 2013 15:36
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Defined capacity
>> >
>> > "To enable the WorkLoad Manager (WLM), select Enable workload manager.
>> > Selecting WLM from one processor details automatically selects WLM
>> > from the other processor details and conversely. Specify the minimum
>> > and maximum processing weights. Change LPAR management weights based
>> > on customer policies and current work loads. "
>> >
>> > Indeed, to enable WLM I have to check "Enable WLM". I wouldn't know
>> that!
>> > Of course there is no explanation what does it mean "enable WLM". WLM
>> > is enabled on every z/OS image and cannot be disabled. 

Re: Defined capacity

[Jan Vanbrabant]

Thanks Fabio.

I have read about the 3 possible scenarios when WLM asks PR/SM to cap the
logical partition at the HMC-defined weight value.   (page 102-103 of the
redbook)
I encounter what Kees was talking about (phantom load or “phantom” logical
partition   &  cap pattern that repeatedly applies and removes the cap at
the logical
partition processing weight..)
But my lack of understanding still remains.  I must be missing some
essential piece.

Jan


On Wed, Feb 13, 2013 at 6:40 PM, Fabio Massimo Ottaviani <
fabio.ottavi...@epvtech.com> wrote:

> Hi Jan
> Redbook - WLM System Programmer Guide - Chapter 3
> Best regards
> Fabio
> +
> + Fabio Massimo Ottaviani
> + EPV Technologies Technical Director
> + Skype: fabio.massimo.ottaviani
> + Mobile: +393406168088
> +
> + IT Cost under Control
> + www.epvtech.com
> +
>
>    Please consider the environment - do you really need to print this
> email?
>
> -Messaggio originale-
> Da: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Per
> conto di Jan Vanbrabant
> Inviato: mercoledì 13 febbraio 2013 17:13
> A: IBM-MAIN@LISTSERV.UA.EDU
> Oggetto: Re: Defined capacity
>
> Hi Kees,
>
> I'm following this thread. (Learning a lot doing this...)
>
> Whare can I find more about  'phantom load' and 'capping pattern'?
> Didn't find these terms in de 2 WLM manuals you mentioned earlier:
>
> SA22-7602-19z/OS V1R12.0 MVS Planning Workload Management
> SA22-7999-06z/OS V1R12.0 Planning for Subcapacity Pricing
>
> (I am at R12, so I looked in the R12 manuals)
>
> Jan
>
> On Tue, Feb 12, 2013 at 4:00 PM, Vernooij, CP - SPLXM <
> kees.verno...@klm.com
> > wrote:
>
> > Yes, LPAR Clusters are IRD managed groups of LPARs.
> >
> > Don't forget to read about Weight in relation to 'phantom load' and
> > 'capping pattern', to avoid erratic Lpar performance.
> >
> > I always like to have a monitor telling what is going on in the
> > system, so I will not be surprised by angry telephone calls and have
> > no clue where to start looking. I use Mainview, I don't know RMF, but
> > it probably also displays the 4HrRA, the current LPAR utilization and
> > the status of softcapping, so you know why the system is doing what it
> is doing.
> >
> > HTH,
> > Kees.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of R.S.
> > Sent: Tuesday, February 12, 2013 15:36
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Defined capacity
> >
> > "To enable the WorkLoad Manager (WLM), select Enable workload manager.
> > Selecting WLM from one processor details automatically selects WLM
> > from the other processor details and conversely. Specify the minimum
> > and maximum processing weights. Change LPAR management weights based
> > on customer policies and current work loads. "
> >
> > Indeed, to enable WLM I have to check "Enable WLM". I wouldn't know that!
> > Of course there is no explanation what does it mean "enable WLM". WLM
> > is enabled on every z/OS image and cannot be disabled. So, there must
> > be some other explanation of the words above. IRD? No clue about IRD.
> >
> >
> > However I found "WLM checkbox" in the chapter about IRD:
> > "For each logical partition that will participate in LPAR weight
> > management, do the following:
> >
> >  -   Make sure that "Initial Capping" is turned off. WLM cannot
> > manage the weight of a logical partition that is capped.
> >
> >  -   Enter the initial processing weight. This becomes the logical
> > partition's weight when it is first IPLed.
> >
> >  -   Enter the minimum and maximum weights. These set the lower and
> > upper limits for the weights that WLM will assign to the logical
> partition.
> >
> >  -   Check the "WLM Managed" box. This is the final step in
> > activating LPAR weight management." ---> THAT'S THE CHECKBOX!
> >
> >
> >
> > BTW: I never used IRD for simple reason: lack of sysplex.
> >
> >
> > So, to my knowledge:
> > WLM checkbox - used only for IRD, leave unchecked otherwise.
> > Defined Capacity - simply put non-zero value, uncheck Initial Capping
> > on CP, zIIP, zAAP.
> >
> >
> &g

Re: Defined capacity

[Jan Vanbrabant]

I second Dave's question, Kees.
jan

On Fri, Feb 15, 2013 at 1:08 AM, Dave Barry  wrote:

> Kees,
>
> I'd like to know more about the lack of cooperation between weight
> management and softcapping.  Can you enlighten us?
>
> Much obliged,
> db
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, CP - SPLXM
> Sent: Tuesday, February 12, 2013 8:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Defined capacity
>
> Radoswaw,
>
> One to the manuals has a chapter IRD, I think you will find there that the
> WLM checkbox triggers IRDs weight management.
> From my experience: forget IRD on modern machines. CPU management is
> disabled by Hiperdispatch and weight management and softcapping do not
> cooperate.
>
> Kees.
>
> --
> 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

‘’MVS overhead’’ (as indicated by OMEGAMON)

[Jan Vanbrabant]

Hi,

A customer of mine is  HiperDispatch with “defined” capacity”  (hence
possible softcapping based on the 4Hr-rolling average.)



In the the ‘*System CPU Utilization table view’* of Omegamon XE on z/OS,
and more specifically in the ‘*Workload CPU Usage bar chart* ‘  we  regularly
see (very) high values for the ‘MVS OVERHEAD’ attribute.

Some examples:

1°

Average CPU Percent:  19.5  (TCP % 19;  SRB % 2; partition overhead
negligible)

MVS OVERHEAD :  13

2°

Average CPU Percent:  82  (TCP % 50;  SRB % 2; partition overhead
negligible)

MVS OVERHEAD :  31

3°

On a small system on the contrary,  the MVS OVERHEAD is small.

Average CPU Percent:  27  (TCP % 22;  SRB % 6; partition overhead
negligible)

MVS OVERHEAD :  2

This system has bad P/Is, for example one Service Class has a P/I=18.5
while there are  no bottlenecks at all with the resources, while being  idle
for 96,9%.





We would like to know how we’ve to interpet .

The user’s guide explains it as:

CPU utilization percentage that is not attributable to any
user or address space. It is calculated as the difference between the total
software utilization times and the total hardware time ((TCB + SRB)-CPU)
over the last reporting interval. Valid value is a 4-byte integer.

In a complex with more than one CPU, z/OS overhead can be
computed based on the number of processors, or normalized to a maximum of
100%.



???

Any of you able to explain this in a better way?   (So that I’m able to
understand what this means.)



And where should we start looking to find out what’s happening underneath?

Poor  WLM definitions?   (The performance is n't bad finally.)

But if the overhead can go down,  MSU-based CEC invoices are loweedr;  so
the point of view is rather cost-oriented.





In this sysplex  with 6 systems, 34 ServicesClasses are actually
defined

In the system of the second example, 16 SCs of the 34 are actually used.

(I don’t know if it might be important, but on top of the 34 there are
another 8 system SC’s with

 a goal of SYSTEM; they are SYSTEM, SYSSTC, SYSSTC1,  SYSSCT2, SYSSTC3,
SYSSTC4,  USSCT5, SYSOTHER).





IBM-MAIN is probably not the  most appropriate listserver or forum to post
this OMEGAMON-based question at the origin?  Is there a better place at
your knowledge?



Jan



PS

Customer already reduced the number of logical processors  by running Alain
Maneville’s  EXCELLENT (!)  LPARDesign-HD-V3-spreadsheet.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Defined capacity

[Jan Vanbrabant]

Hi Kees,

I'm following this thread. (Learning a lot doing this...)

Whare can I find more about  'phantom load' and 'capping pattern'?
Didn't find these terms in de 2 WLM manuals you mentioned earlier:

SA22-7602-19z/OS V1R12.0 MVS Planning Workload Management
SA22-7999-06z/OS V1R12.0 Planning for Subcapacity Pricing

(I am at R12, so I looked in the R12 manuals)

Jan

On Tue, Feb 12, 2013 at 4:00 PM, Vernooij, CP - SPLXM  wrote:

> Yes, LPAR Clusters are IRD managed groups of LPARs.
>
> Don't forget to read about Weight in relation to 'phantom load' and
> 'capping pattern', to avoid erratic Lpar performance.
>
> I always like to have a monitor telling what is going on in the system, so
> I will not be surprised by angry telephone calls and have no clue where to
> start looking. I use Mainview, I don't know RMF, but it probably also
> displays the 4HrRA, the current LPAR utilization and the status of
> softcapping, so you know why the system is doing what it is doing.
>
> HTH,
> Kees.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Tuesday, February 12, 2013 15:36
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Defined capacity
>
> "To enable the WorkLoad Manager (WLM), select Enable workload manager.
> Selecting WLM from one processor details automatically selects WLM from
> the other processor details and conversely. Specify the minimum and maximum
> processing weights. Change LPAR management weights based on customer
> policies and current work loads. "
>
> Indeed, to enable WLM I have to check "Enable WLM". I wouldn't know that!
> Of course there is no explanation what does it mean "enable WLM". WLM is
> enabled on every z/OS image and cannot be disabled. So, there must be some
> other explanation of the words above. IRD? No clue about IRD.
>
>
> However I found "WLM checkbox" in the chapter about IRD:
> "For each logical partition that will participate in LPAR weight
> management, do the following:
>
>  -   Make sure that "Initial Capping" is turned off. WLM cannot
> manage the weight of a logical partition that is capped.
>
>  -   Enter the initial processing weight. This becomes the logical
> partition's weight when it is first IPLed.
>
>  -   Enter the minimum and maximum weights. These set the lower and
> upper limits for the weights that WLM will assign to the logical partition.
>
>  -   Check the "WLM Managed" box. This is the final step in
> activating LPAR weight management." ---> THAT'S THE CHECKBOX!
>
>
>
> BTW: I never used IRD for simple reason: lack of sysplex.
>
>
> So, to my knowledge:
> WLM checkbox - used only for IRD, leave unchecked otherwise.
> Defined Capacity - simply put non-zero value, uncheck Initial Capping on
> CP, zIIP, zAAP.
>
>
> Thank you Kees!
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
> P.S.
> I just found another "helpful" explanation:
> Image Pforile, Options tab:
>
> "CP management cluster name
>
> The name specified for the CP management cluster. "
>
> I suspect it's also IRD related stuff.
>
>
>
>
>
>
>
>
> W dniu 2013-02-12 14:58, Vernooij, CP - SPLXM pisze:
> > Radoswaw,
> >
> > One to the manuals has a chapter IRD, I think you will find there that
> the WLM checkbox triggers IRDs weight management.
> >>From my experience: forget IRD on modern machines. CPU management is
> disabled by Hiperdispatch and weight management and softcapping do not
> cooperate.
> >
> > Kees.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> > Sent: Tuesday, February 12, 2013 14:30
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Defined capacity
> >
> > W dniu 2013-02-12 13:50, Vernooij, CP - SPLXM pisze:
> >> Check this paper too:
> >> http://www.ibm.com/common/ssi/fcgi-bin/ssialias?infotype=SA&subtype=WH
> >> &appname=STGE_ZS_ZS_USEN&htmlfid=ZSW03077USEN&attachment=ZSW03077USEN.
> >> PDF
> >>
> >> kees.
> >
> > Kees,
> > Thank you for quick response. Actually I have 3 open documents on my PC,
> exactly the same which you mentioned ;-) I found and answer for Q1 (MSU as
> a unit), which I was 99% sure.
> >
> > Unfortunately I found no explanation about WLM checkbox. From your
> response I assume I should leave it unchecked, since I don't use IRD.
> >
> > Regarding Q3 - I found that Initial Capping on any processor-type tab
> gives the same result - it disables WLM checkbox. So I assume, I shouldn't
> use Initial Capping for any CP type, including zIIP.
> >
> >
> > BTW: General observation. It is typical for IBM - Software manuals avoid
> describing any details about hardware panels, while H/W manuals do not
> describe the meaning of the fields and panels.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> >
> >
> >
> > --
> > Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej

Re: Beware BPXWDYN (Was: Problem with REXX using OMVS stuff...)

[Jan Vanbrabant]

Bit Bucket x’28’ (SHARE 116, Anaheim, Session 8666, 3 March 2011) (Ed
Jaffe, Sam Knutson, Skip Robinson)
http://proceedings.share.org/client_files/SHARE_in_Anaheim_2/Session_8666_handout_1051_0.pdf
slide 12-14



On Sat, Jan 12, 2013 at 8:26 AM, Edward Jaffe
wrote:

> On 1/11/2013 1:32 PM, Mark Zelden wrote:
>
>> I'm not in love with BPXWDYN as much as you - only because I haven't
>> used it that much, but I'll keep that in mind if / when I have to make
>> any major updates.All the random DD code predates BPXWDYN
>> and of course what works in one of my execs is easily cut/pasted
>> into another one.  :-)
>>
>
> We re-engineered all of our TSO/E logon execs to use BPXWDYN instead of
> ALLOCATE a while back. This was needed to get around the hard-wired
> DYNAMNBR=100 limit for z/OS UNIX forked procedures. (I mentioned this
> restriction and solution in a SHARE Bit Bucket session -- perhaps Atlanta.)
>
> Just this week I discovered a _major_ drawback to BPXWDYN. If OMVS is not
> up, BPXWDYN will issue the following message and then WAIT for OMVS to
> initialize:
>
> BPXP022E ONE OR MORE JOBS ARE WAITING FOR UNIX SYSTEM SERVICES
> AVAILABILITY.
>
> OMVS would not come up on one of our images this week because ZFS wouldn't
> come up because of some missing toleration APARs/PTFs on the back-level
> systems in the sysplex. Using TSO/E ALLOCATE I can logon to TSO/E on the
> "problem" image, use ISPF, submit jobs, etc. even while OMVS is down. Using
> BPXWDYN the TSO/E session just hangs dead. :(
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.**com/ 
>
> --**--**--
> 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

Service Unit rate and HiperDispatch

[Jan Vanbrabant]

Hi,

As indicated in the LSPR manual,  SRM constants at the LPAR level can
deviate substantially from the actual capacity of the LPAR due to their
sensitivity to the number of logical engines.
Each time that you manually vary a CP offline (or online),  The SRM
constant is changed.
When an LP is added to an LPAR, the SRM constant is recalculated to reflect
the new configuration. However, this recalculation does NOT (!)  occur when
IRD (Intelligent Resource Director) adds or removes the LP.

Is this true too with HiperDispatch (HD) ?   *(When HD is turned on, IRD is
de-activated of course.)*

But there IS a difference between IRD and HD in the way these mechanisms
work.
IRD  varies  CPUs  'online/offline'.
While HD adjusts the number of  'active' CPUs  to achieve the minimum
required to run the work of the partition.  It 'parks' unused processors,
'parking' meaning - in simple terms - placing a CPU in kind of a long-term
wait until it is again needed to run work. (Parked CPUs get
no share distribution.)
So what about the service unit rate in respect with HD?
Is the SU rate changed or unchanged when CPs are parked or unparked?
If unchanged when CPs are parked/unparked  and  if you use service units as
the basis of charge-back,  this will skew the results because fewer service
units will be produced than if you manually configure the logical
processors.


Please shed some light.
Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How can we get the normalization factors R723NFFI / R723NFFS / SMF70NRM numbers out of RMF?

[Jan Vanbrabant]

Thanks Daniel for your gentle offer, but my customer doesn't work with PL/I.
Cheers, jan

On Thu, Oct 4, 2012 at 1:56 PM, Daniel Jacot wrote:

> If you really want to find this value in RMF, you have to look at R791NFFS
> which is a field in SMF type 79 (RMF II), subtype 1 (Address Space State
> Data).
> Since it's not listed in the RMF tool in ISPF, you have to call the RMF
> interface ERBSMFI and interpret its output. Nice little programming work,
> colleague of mine did it using a small ASM interface for the call and PL/I
> for interpretation.
>
> Obviously, you can also read SMF records, using a REXX, Assembler, COBOL
> or PL/I program to get this information. I can provide you a little PL/I
> program for reading SMF type 70 if this helps you.
>
> Also obviously, the zIIP normalization factor is a constant, determined at
> IPL time and stored anywhere in the memory where it can be read by RMF and
> SMF. However, I did not find any hint so far where to search in memory. The
> published Data Areas don't provide this factor.
>
> --
> 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

How can we get the normalization factors R723NFFI / R723NFFS / SMF70NRM numbers out of RMF?

[Jan Vanbrabant]

Hi,

How (or where) can I find  in RMF the normalization factors for specialty
engines (zIIP, zAAP) [R723NFFI (zAAPs)  or R723NFFS (zIIPs)]  against
kneecapped GP processors?
Or the SMF70NRM value from TYPE70?

Products such as MICS or MXG will do this conversion for you, but I don't
have them in my shop.   Omegamon neither.

Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: WLM Resource Group not working.

[Jan Vanbrabant]

Oh, yes, Uwe!
Jan

On Thu, Aug 30, 2012 at 8:29 AM, Uwe Oswald
wrote:

> This behaviour is described in the WLM Redbook I believe. I can find the
> document if someone is interested to understand the capping mechanism in
> more detail.
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Ron Hawkins
> Gesendet: Mittwoch, 29. August 2012 18:52
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: WLM Resource Group not working.
>
> Kees,
>
> I've just done some trial and error setup for a service unit based
> resource group. This one is running about 300 jobs at once.
>
> We've noticed the behavior when submitting all these jobs after some
> inactivity is the work in the resource group will run unconstrained for a
> few minutes, and then gradually be throttled back to service unit limit
> specified. After approx. ten minutes the resource group cap is working
> perfectly. We've tested this for 8-10 hours continuous running.
>
> The service unit limit we used was arrived at through trial and error. I
> noticed the above behavior late in the piece. I have not checked the
> accuracy of the SU consumption of the resource group as we arrived at the
> PCTCPUBY we needed more out of luck then design, but we stopped toying with
> it once we got what we needed.
>
> Ron
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Vernooij, CP - SPLXM
> > Sent: Wednesday, August 29, 2012 6:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [IBM-MAIN] WLM Resource Group not working.
> >
> > Hello list,
> >
> >
> >
> > I implemented a Resource Group to limit the CPU consumption of our
> > CICS Devl and Acc systems, but I can't get the RG to do what I want.
> >
> >
> >
> > I want to limit the group to 2 MSU, so I gave the RG a max of
> > 200/3600=555 SU/sec (Option 1, sysplex wide) and started a CPU
> > looper
> > (iefbr15) in the SC connected to the RG. In Mainview I see that WLM is
> > capping the looper, but it is still allowed to consume 2000 SU/sec.
> > If I
> start a
> > second looper, the RG starts consuming even more CPU.
> >
> >
> >
> > Why does this not work as I expected and how do I limit the group to
> > 555 SU/sec?
> >
> >
> >
> > Thanks for your help,
> >
> > Kees.
> >
> >
> >
> > 
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> > If
> you
> > are not the addressee, you are notified that no part of the e-mail or
> > any attachment may be disclosed, copied or distributed, and that any
> > other action related to this e-mail or attachment is strictly
> > prohibited, and
> may be
> > unlawful. If you have received this e-mail by error, please notify the
> sender
> > immediately by return e-mail, and delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> > its employees shall not be liable for the incorrect or incomplete
> > transmission
> of
> > this e-mail or any attachments, nor responsible for any delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with
> > registered number 33014286
> > 
> >
> > --
> > 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
>
> --
> 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

Re: Web interface

[Jan Vanbrabant]

Superb indeed !!!
THANKS!
Jan

On Fri, Aug 17, 2012 at 10:44 AM, Shane Ginnane  wrote:

> Seems to be all better ... touch wood.
>
> Thanks to any and all who facilitated its recovery. - Darren especially I
> guess.
>
> Shane ...
>
> --
> 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

Re: Who's blacklisting IBM-MAIN

[Jan Vanbrabant]

No problem in Belgium with
https://listserv.ua.edu/cgi-bin/wa?A1=ind1207&L=ibm-main

jan



On Thu, Jul 26, 2012 at 11:40 AM, Bruno Sugliani wrote:

> On Thu, 26 Jul 2012 00:27:05 -0500, Shane Ginnane 
> wrote:
>
> >On Wed, 25 Jul 2012 11:13:50 -0600, Paul Gilmartin wrote:
> >
> >>And access to the archives is unbearably slow to impossible from
> elsewhere.
> >
> >Likewise profundo.
> >Getting a full listing of (this) month on the web interface can take days
> (of attempting to refresh the page) to accomplish.
> >
> >And I though it was my flakey copper link or maybe a clogged pipe under
> the Pacific.
> >
> >Shane ..
> >
>
> Quite impossible to display also...  here in France
> Looks like it needs a DB reorg :-))
>
> Bruno Sugliani
> zxnetconsult(at) free(dot)fr
>
> --
> 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

Re: ROI of zIIP investment on kneecapped z Systems

[Jan Vanbrabant]

That's exactly what it is about, Mike.
jan

On Fri, Jun 29, 2012 at 7:43 PM, Mike Schwab wrote:

> As far as I know, only full service CPs are kneecapped.
> Low cost specialty processors run full speed
> (I. E. as fast as the fastest CP processor with the same number of
> processors).
>
> On Fri, Jun 29, 2012 at 12:34 PM, Jan Vanbrabant
>  wrote:
> > Hi,
> >
> > Mgt wants to know the ROI of a zIIP investment on zSystems with
> > *kneecapped*GP processors.
> >
> > I've been reading Jim Horne's
> >
> > *Specialty Engines & Kneecapped Processors(Jim Horne,
> ShareOrlando2011)How
> > specialty engines are reported in RMF TYPE70 & TYPE72)
> > https://share.confex.com/share/117/webprogram/Session9528.html *
> >
> > *&*
> >
> > *The_Myth_of_MSU_(final_version) (CMG paper 7171, Jim Horne (Lowe’s
> > Companies, Inc.))(RMF TYPE70 and TYPE72 records review)**
> > http://www.mxg.com/downloads/the%20myth%20of%20msu.doc*
> >
> >
> > In order to NOT compare apple with oranges MSU's we have to normalize the
> > zIIP MSU's with *R723NFFS*   (or zAAP MSUs with *R723NFFI* ).
> >
> > Towards the end of his CMG paper,  in his wish list, Jim indicated:
> >
> > Fourth, IBM needs to develop reliable numbers for the speed relationship
> > between specialty engines and general purpose engines.  As of right now,
> no
> > one knows how fast the specialty engines actually are.  Those numbers
> need
> > to be developed and implemented.  The conversion factors for zAAP
> > (R723NFFI) and zIIP (R723NFFS) engines do not currently show this
> > relationship properly.
> >
> > My questions:
> >
> > 1°   Is this still true?
> >
> > 2°   If not, where can we find the correct normalization factors?  If
> > yes, any ideas how we MIGHT calculate them ourselves?
> >
> >
> > Jan
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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

ROI of zIIP investment on kneecapped z Systems

[Jan Vanbrabant]

Hi,


Mgt wants to know the ROI of a zIIP investment on zSystems with
*kneecapped*GP processors.

I've been reading Jim Horne's

*Specialty Engines & Kneecapped Processors(Jim Horne, ShareOrlando2011)How
specialty engines are reported in RMF TYPE70 & TYPE72)
https://share.confex.com/share/117/webprogram/Session9528.html *

*&*

*The_Myth_of_MSU_(final_version) (CMG paper 7171, Jim Horne (Lowe’s
Companies, Inc.))(RMF TYPE70 and TYPE72 records review)**
http://www.mxg.com/downloads/the%20myth%20of%20msu.doc*


In order to NOT compare apple with oranges MSU's we have to normalize the
zIIP MSU's with *R723NFFS*   (or zAAP MSUs with *R723NFFI* ).

Towards the end of his CMG paper,  in his wish list, Jim indicated:

Fourth, IBM needs to develop reliable numbers for the speed relationship
between specialty engines and general purpose engines.  As of right now, no
one knows how fast the specialty engines actually are.  Those numbers need
to be developed and implemented.  The conversion factors for zAAP
(R723NFFI) and zIIP (R723NFFS) engines do not currently show this
relationship properly.

My questions:

1°   Is this still true?

2°   If not, where can we find the correct normalization factors?  If
yes, any ideas how we MIGHT calculate them ourselves?


Jan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN