Re: PTF error clarification

[Staller, Allan]

Research this apar:

ERROR HOLD AA49159 WAS NOT RESOLVED


Either order/install the additional maintenance required  *OR*

*WITH GREAT CARE AND EXTREME DILIGENCE*, determine if the exposure in this 
AA49159 will affect you installation.

If *YES* DO NOT bypass the error hold.
If *NO*, the error hold can be bypassed on the APPLY.

e.g. Many times the error holds are associated with a particular feature. If 
you do not have, and are not planning to install this feature, the error hold 
may be safely bypassed.
The fixing PTF will come along in due course and be installed in the normal 
maintenance stream. If you have, or are planning to install the feature, then 
it is most likely not a 
good idea to bypass the error hold.

Another possibility is to research the PTF chain leading to AA49159. It is 
possible that somewhere in the chain, there is a "stop point" where all prior 
maint will go on with error. IF PTFS in the chain subsequent to the "stop 
point" are excluded from the apply, the earlier PTF's will go on without any 
issues.

HTH,



I am applying few toleration fixes for a hardware but I a receiving the below 
error message.

CAUSER SYSMOD SUMMARY REPORT FOR APPLY CHECK PROCESSING

CAUSER   FMID MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE CAUSES

UA90976  HBB7790  GIM35901I  2   ERROR HOLD AA49159 WAS NOT RESOLVED.

PAGE 0003  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
 SMP/E


UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK PROCESSING

NOTE: THE SYSMODS LISTED IN THIS REPORT ALSO APPEAR IN THE CAUSER SYSMOD SUMMARY


 HOLD MISSING  HELD RESOLVING  RESOLVER

TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS

--  ---  ---  ---  ---  -  

ERROR   HBB7790  PE   AA48273  UA90976  UA78633NOGO(H)
UA78870NOGO(H)
  AA48642  UA90976  UA78971NOGO(H)
  AA48858  UA90978  UA78965NOGO(H)
  AA49159  UA90976

deleted

MISSING
APAR
---
AA48273

AA48642
AA48858
AA49159

z/OS 2.1


This email � including attachments � may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: PTF error clarification

[Skip Robinson]

I'm pretty adamant on this question: I will not bypass an error hold unless 
Level 2 blesses it. Relying on the error description and the environment it 
pertains to can be very risky. Error descriptions are often tailored for the 
customers reporting the problem. You don't want to be grist for the next 
description update: 'and BTW this problem may affect you in this additional 
circumstance'. The only valid case I can see for bypass is to install a fix 
that I absolutely need for an ongoing problem. That is, break-fix, not 
preventative maintenance. Even then I would still seek the vendor's counsel. 

Picture this scenario. Your latest maintenance bundle goes south and causes an 
outage. The boss invites you drop by and explain what happened. Where would you 
rather be?

1. Gee boss, I looked at an error hold, decided it didn't pertain to us, and 
jammed it on over SMPE's objection.
2. I followed the vendor's educated advice and let the process work as 
designed. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Staller, Allan
> Sent: Tuesday, December 22, 2015 07:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: PTF error clarification
> 
> Research this apar:
> 
> ERROR HOLD AA49159 WAS NOT RESOLVED
> 
> 
> Either order/install the additional maintenance required  *OR*
> 
> *WITH GREAT CARE AND EXTREME DILIGENCE*, determine if the exposure in
> this AA49159 will affect you installation.
> 
> If *YES* DO NOT bypass the error hold.
> If *NO*, the error hold can be bypassed on the APPLY.
> 
> e.g. Many times the error holds are associated with a particular feature. If 
> you
> do not have, and are not planning to install this feature, the error hold may 
> be
> safely bypassed.
> The fixing PTF will come along in due course and be installed in the normal
> maintenance stream. If you have, or are planning to install the feature, then 
> it is
> most likely not a good idea to bypass the error hold.
> 
> Another possibility is to research the PTF chain leading to AA49159. It is 
> possible
> that somewhere in the chain, there is a "stop point" where all prior maint 
> will go
> on with error. IF PTFS in the chain subsequent to the "stop point" are 
> excluded
> from the apply, the earlier PTF's will go on without any issues.
> 
> HTH,
> 
> 
> 
> I am applying few toleration fixes for a hardware but I a receiving the below
> error message.
> 
> CAUSER SYSMOD SUMMARY REPORT FOR APPLY CHECK PROCESSING
> 
> CAUSER   FMID MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE
> CAUSES
> 
> UA90976  HBB7790  GIM35901I  2   ERROR HOLD AA49159 WAS NOT
> RESOLVED.
> 
> PAGE 0003  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME
> 06:33:34
>  SMP/E
> 
> 
> UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
> 
> NOTE: THE SYSMODS LISTED IN THIS REPORT ALSO APPEAR IN THE CAUSER
> SYSMOD SUMMARY
> 
> 
>  HOLD MISSING  HELD RESOLVING  RESOLVER
> 
> TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS
> 
> --  ---  ---  ---  ---  -  
> 
> ERROR   HBB7790  PE   AA48273  UA90976  UA78633NOGO(H)
> UA78870NOGO(H)
>   AA48642  UA90976  UA78971NOGO(H)
>   AA48858  UA90978  UA78965NOGO(H)
>   AA49159  UA90976
> 
> deleted
> 
> MISSING
> APAR
> ---
> AA48273
> 
> AA48642
> AA48858
> AA49159
> 
> z/OS 2.1
> 

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[R.S.]

W dniu 2015-12-22 o 21:13, Paul Gilmartin pisze:

On 2015-12-22 11:15, R.S. wrote:

It would be better to define usec at the first occurence.
Or use full name: 'microsecond'.
BTW: 'us' seems to be more cryptic, while it's more correct than usec.


what about "μs"
That's the best, the most accurate, but ...still can be problematic 
since not everything can use greek letters.



BTW: some time ago in Poland there was netiquette rule to AVOID using 
polish characters (ąćęłńóśżź) since it was rearely understood. Not to 
mention we have many codepages: CP870, ISO8859-2, CP1250, CP852 to name 
few popular ones.


--
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.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: SRB And Enclave SRB

[Barry Merrill]

Look at the value of SMF30SNF or SMF70NRM, divide it by 256,
and that is the speedup ratio of your zIIP engine compared 
with the CP engine speed, and I've seen higher ratios than 4.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Klein, Kenneth E
Sent: Tuesday, December 22, 2015 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

We just enabled zPSaver Suite on an LPAR on a z12 z/os 2.1 as a POC. We're
getting 72.1 percent offloaded to zIIP on that LPAR. There's a little
savings in IEBGENER, too, but too little to matter.

What I can't figure out is where the CPU time went, because I did NOT see
the 72.1 percent show up in the zIIP column. I know the specialty engines
are not hamstrung like the 2827-H43-407 general purpose engines, but it
looks the 1 zIIP on the CEC is 4 times faster! Can that be true? Any form of
reality check would be welcome here.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Blaicher, Christopher Y.
Sent: Friday, November 06, 2015 10:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

Go to http://www.syncsort.com/en/Products/Mainframe/ZPSaverSuite and see
what we can do on z/IIP engines.  In a nutshell, we can offload about 90% of
our normal TCB workload to a z/IIP engine, your mileage may vary depending
on a number of things, but we can do an awful lot.  This has been a
multi-year project by a number of very talented people.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Friday, November 06, 2015 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

On 6 Nov 2015 08:11:52 -0800, in bit.listserv.ibm-main you wrote:

>SRB's were not meant for general application code.  Also, I hope nobody
builds a quick and dirty SRB routine.  Those should be carefully constructed
and tested.
>If by quick and dirty you mean short lived, then yes, that was their
original use case.  Some SRB routines today are much more robust and can do
significant work, but that is what the z/IIP engines are for.

What is the work done on a Ziip engine?  As I understand other postings
(possibly incorrectly) the work runs under an enclave SRB.
Java and XML parsing to my mind are application code.  I can't speak as to
what type of code DF/Sort and Syncsort are running on Ziip and Zaap.

Clark Morris
>
>
>Chris Blaicher
>Technical Architect
>Software Development
>Syncsort Incorporated
>50 Tice Boulevard, Woodcliff Lake, NJ 07677
>P: 201-930-8234  |  M: 512-627-3803
>E: cblaic...@syncsort.com
>





ATTENTION: -

The information contained in this message (including any files transmitted
with this message) may contain proprietary, trade secret or other
confidential and/or legally privileged information. Any pricing information
contained in this message or in any files transmitted with this message is
always confidential and cannot be shared with any third parties without
prior written approval from Syncsort. This message is intended to be read
only by the individual or entity to whom it is addressed or by their
designee. If the reader of this message is not the intended recipient, you
are on notice that any use, disclosure, copying or distribution of this
message, in any form, is strictly prohibited. If you have received this
message in error, please immediately notify the sender and/or Syncsort and
destroy all copies of this message in your possession, custody or control.

--
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: SRB And Enclave SRB

[Martin Packer]

Also R723NFFS - if you're working with Report / Service Class data.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Barry Merrill 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 20:44
Subject:Re: SRB And Enclave SRB
Sent by:IBM Mainframe Discussion List 



Look at the value of SMF30SNF or SMF70NRM, divide it by 256,
and that is the speedup ratio of your zIIP engine compared 
with the CP engine speed, and I've seen higher ratios than 4.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Klein, Kenneth E
Sent: Tuesday, December 22, 2015 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

We just enabled zPSaver Suite on an LPAR on a z12 z/os 2.1 as a POC. We're
getting 72.1 percent offloaded to zIIP on that LPAR. There's a little
savings in IEBGENER, too, but too little to matter.

What I can't figure out is where the CPU time went, because I did NOT see
the 72.1 percent show up in the zIIP column. I know the specialty engines
are not hamstrung like the 2827-H43-407 general purpose engines, but it
looks the 1 zIIP on the CEC is 4 times faster! Can that be true? Any form 
of
reality check would be welcome here.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Blaicher, Christopher Y.
Sent: Friday, November 06, 2015 10:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

Go to http://www.syncsort.com/en/Products/Mainframe/ZPSaverSuite and see
what we can do on z/IIP engines.  In a nutshell, we can offload about 90% 
of
our normal TCB workload to a z/IIP engine, your mileage may vary depending
on a number of things, but we can do an awful lot.  This has been a
multi-year project by a number of very talented people.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Friday, November 06, 2015 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

On 6 Nov 2015 08:11:52 -0800, in bit.listserv.ibm-main you wrote:

>SRB's were not meant for general application code.  Also, I hope nobody
builds a quick and dirty SRB routine.  Those should be carefully 
constructed
and tested.
>If by quick and dirty you mean short lived, then yes, that was their
original use case.  Some SRB routines today are much more robust and can 
do
significant work, but that is what the z/IIP engines are for.

What is the work done on a Ziip engine?  As I understand other postings
(possibly incorrectly) the work runs under an enclave SRB.
Java and XML parsing to my mind are application code.  I can't speak as to
what type of code DF/Sort and Syncsort are running on Ziip and Zaap.

Clark Morris
>
>
>Chris Blaicher
>Technical Architect
>Software Development
>Syncsort Incorporated
>50 Tice Boulevard, Woodcliff Lake, NJ 07677
>P: 201-930-8234  |  M: 512-627-3803
>E: cblaic...@syncsort.com
>





ATTENTION: -

The information contained in this message (including any files transmitted
with this message) may contain proprietary, trade secret or other
confidential and/or legally privileged information. Any pricing 
information
contained in this message or in any files transmitted with this message is
always confidential and cannot be shared with any third parties without
prior written approval from Syncsort. This message is intended to be read
only by the individual or entity to whom it is addressed or by their
designee. If the reader of this message is not the intended recipient, you
are on notice that any use, disclosure, copying or distribution of this
message, in any form, is strictly prohibited. If you have received this
message in error, please immediately notify the sender and/or Syncsort and
destroy all copies of this message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send 

Re: SRB And Enclave SRB

[Klein, Kenneth E]

We just enabled zPSaver Suite on an LPAR on a z12 z/os 2.1 as a POC. We're 
getting 72.1 percent offloaded to zIIP on that LPAR. There's a little savings 
in IEBGENER, too, but too little to matter.

What I can't figure out is where the CPU time went, because I did NOT see the 
72.1 percent show up in the zIIP column. I know the specialty engines are not 
hamstrung like the 2827-H43-407 general purpose engines, but it looks the 1 
zIIP on the CEC is 4 times faster! Can that be true? Any form of reality check 
would be welcome here.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Friday, November 06, 2015 10:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

Go to http://www.syncsort.com/en/Products/Mainframe/ZPSaverSuite and see what 
we can do on z/IIP engines.  In a nutshell, we can offload about 90% of our 
normal TCB workload to a z/IIP engine, your mileage may vary depending on a 
number of things, but we can do an awful lot.  This has been a multi-year 
project by a number of very talented people.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Friday, November 06, 2015 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

On 6 Nov 2015 08:11:52 -0800, in bit.listserv.ibm-main you wrote:

>SRB's were not meant for general application code.  Also, I hope nobody builds 
>a quick and dirty SRB routine.  Those should be carefully constructed and 
>tested.
>If by quick and dirty you mean short lived, then yes, that was their original 
>use case.  Some SRB routines today are much more robust and can do significant 
>work, but that is what the z/IIP engines are for.

What is the work done on a Ziip engine?  As I understand other postings 
(possibly incorrectly) the work runs under an enclave SRB.
Java and XML parsing to my mind are application code.  I can't speak as to what 
type of code DF/Sort and Syncsort are running on Ziip and Zaap.

Clark Morris
>
>
>Chris Blaicher
>Technical Architect
>Software Development
>Syncsort Incorporated
>50 Tice Boulevard, Woodcliff Lake, NJ 07677
>P: 201-930-8234  |  M: 512-627-3803
>E: cblaic...@syncsort.com
>





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
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: [Bulk] Re: Coupling Facility Structure Re-sizing

[Mike Schwab]

On Tue, Dec 22, 2015 at 2:39 PM, R.S.  wrote:
> W dniu 2015-12-22 o 21:13, Paul Gilmartin pisze:
>>
>> On 2015-12-22 11:15, R.S. wrote:
>>>
>>> It would be better to define usec at the first occurence.
>>> Or use full name: 'microsecond'.
>>> BTW: 'us' seems to be more cryptic, while it's more correct than usec.
>>>
>> what about "μs"
>
> That's the best, the most accurate, but ...still can be problematic since
> not everything can use greek letters.
>
>
> BTW: some time ago in Poland there was netiquette rule to AVOID using polish
> characters (ąćęłńóśżź) since it was rearely understood. Not to mention we
> have many codepages: CP870, ISO8859-2, CP1250, CP852 to name few popular
> ones.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
UTF-8 includes them all.  But UTF-EBCDIC is only suggested
transformations, not storage.

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

Re: SRB And Enclave SRB

[Cheryl Watson]

Hi Kenneth,

The speed of a single CP on a 407 is about 210 MIPS, while the speed of a
single CP on a 707 is about 1280 (per our CPU Chart).  The zIIP runs like a
7xx, so yes, there is a considerable difference in CPU time between the two.
We try very hard to push zIIPs (and software that offloads work to zIIPs) as
one of the easiest ways to reduce the rolling 4-hour average, and often
software costs.  In many cases, the cost of a zIIP-enabled software product
can easily be offset by the software stack savings.

Best regards,
Cheryl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Klein, Kenneth E
Sent: Tuesday, December 22, 2015 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

We just enabled zPSaver Suite on an LPAR on a z12 z/os 2.1 as a POC. We're
getting 72.1 percent offloaded to zIIP on that LPAR. There's a little
savings in IEBGENER, too, but too little to matter.

What I can't figure out is where the CPU time went, because I did NOT see
the 72.1 percent show up in the zIIP column. I know the specialty engines
are not hamstrung like the 2827-H43-407 general purpose engines, but it
looks the 1 zIIP on the CEC is 4 times faster! Can that be true? Any form of
reality check would be welcome here.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Blaicher, Christopher Y.
Sent: Friday, November 06, 2015 10:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

Go to http://www.syncsort.com/en/Products/Mainframe/ZPSaverSuite and see
what we can do on z/IIP engines.  In a nutshell, we can offload about 90% of
our normal TCB workload to a z/IIP engine, your mileage may vary depending
on a number of things, but we can do an awful lot.  This has been a
multi-year project by a number of very talented people.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Friday, November 06, 2015 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SRB And Enclave SRB

On 6 Nov 2015 08:11:52 -0800, in bit.listserv.ibm-main you wrote:

>SRB's were not meant for general application code.  Also, I hope nobody
builds a quick and dirty SRB routine.  Those should be carefully constructed
and tested.
>If by quick and dirty you mean short lived, then yes, that was their
original use case.  Some SRB routines today are much more robust and can do
significant work, but that is what the z/IIP engines are for.

What is the work done on a Ziip engine?  As I understand other postings
(possibly incorrectly) the work runs under an enclave SRB.
Java and XML parsing to my mind are application code.  I can't speak as to
what type of code DF/Sort and Syncsort are running on Ziip and Zaap.

Clark Morris
>
>
>Chris Blaicher
>Technical Architect
>Software Development
>Syncsort Incorporated
>50 Tice Boulevard, Woodcliff Lake, NJ 07677
>P: 201-930-8234  |  M: 512-627-3803
>E: cblaic...@syncsort.com
>





ATTENTION: -

The information contained in this message (including any files transmitted
with this message) may contain proprietary, trade secret or other
confidential and/or legally privileged information. Any pricing information
contained in this message or in any files transmitted with this message is
always confidential and cannot be shared with any third parties without
prior written approval from Syncsort. This message is intended to be read
only by the individual or entity to whom it is addressed or by their
designee. If the reader of this message is not the intended recipient, you
are on notice that any use, disclosure, copying or distribution of this
message, in any form, is strictly prohibited. If you have received this
message in error, please immediately notify the sender and/or Syncsort and
destroy all copies of this message in your possession, custody or control.

--
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: ASG ZEKE Responding to program generated messages

[John Sawyer]

Hello,

SuperVision Automation can do it.

John


On Dec 22, 2015, at 4:17 PM, Mitch Mccluhan wrote:

> Hello,
> 
> I don't believe Zeke has that capability.  I personally recommend TWS from 
> Tivoli.
> 
> 
> 
> Mitch McCluhan
> mitc...@aol.com
> 
> 
> 
> 
> 
> -Original Message-
> From: Carl Edwards <00df3759e3e7-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN 
> Sent: Tue, Dec 22, 2015 12:00 pm
> Subject: ASG ZEKE Responding to program generated messages
> 
> I have a client that is considering installing ZEKE. Said client has a fair 
> amount of console diakaig that needs to be automated. The questions is Can 
> ZEKE recognize console messages generated via a program(DISPLAY UPON CONSOLE) 
> and respond to such? 
> 
> 
> --
> 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: PTF error clarification

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Skip Robinson
> Sent: Tuesday, December 22, 2015 3:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PTF error clarification
> 
> This is a hot button of mine: going to extraordinary lengths to second
guess
> SMPE. Like Santa Claus, SMPE knows who's been naughty and who's been nice.
> Goodies and lumps of coal will be distributed accordingly. GROUPEXTEND is
> *always* in order. There's nothing wrong with RC 8. Resolvable hold chains
> will be applied; unresolvable ones will be not. It's an utter waste of
time
> to build an exclude list just to achieve RC 0. That ploy is decades
obsolete
> and achieves nothing that SMPE won't deliver for free.

Our quality control process required an audit for any project that was about
to be released for production.  That included scheduled system updates.  The
audit personnel were not mainframe savvy, not even software savvy.  What
they did excel at was ensuring that our procedures were approved before we
built the project and that we actually followed them.  This was usually
achieved by retaining the output from the jobs that built and tested the
project.  An RC of 0 and an empty causer report made the audit go much
smoother.  (It's not easy explaining to a welding inspector why a PTF error
would not be a real problem.)

You may be right about no technical gain but clean builds are a political
lifesaver.  I doubt my organization was unique in this regard.

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

Re: Coupling Facility Structure Re-sizing

[Skip Robinson]

I made a lame assumption based on 20 years of parallel sysplex. Our
sysplexes have always consisted of boxes a few meters apart. I have (rather
unkindly) scoffed at suggestions that we build a single sysplex between our
data centers 100+ KM apart. It's not as much about speed as about the
fallibility of network connections. The DWDM links that transport XRC
connections are wicked fast, but they hiccup occasionally for usually
unfathomable reasons. We can handle XRC suspend/resume, but having a sysplex
go hard down in such circumstances is not acceptable. Maybe I'm behind the
times, but that 'conversation with the boss' I alluded to in a previous post
looms large in my imagination. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Vernooij, CP (ITOPT1) - KLM
> Sent: Tuesday, December 22, 2015 12:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: [Bulk] Re: Coupling Facility Structure Re-sizing
> 
> One crucial parameter: at what distance are the CFs?
> There must be a noticable difference between 5 usecs for an unduplexed
local
> CF or a number of 150 usecs signals between CFs at 15 km distance.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Martin Packer
> Sent: 22 December, 2015 8:55
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing
> 
> We're not going to BLANKET recommend System-Managed Duplexing for high-
> volume, high stringency structures such as LOCK1. SCA has little traffic.
> 
> But I've seen MANY customers (including the one I worked with yesterday
here
> in Istanbul) that successfully use it. And I support their use of it.
> Other customers:
> 
> 1) Have a failure-isolated CF for such structures.
> 
> Or
> 
> 2) Take the risk of doing neither.
> 
> I've seen all 3 architectures even in the past 6 months. And your local
IBMer is
> normally willing to give their view, hopefully backed up by data and
people who
> know what they're talking about. :-)
> 
> Cheers, Martin
> 
> Martin Packer,
> zChampion, Principal Systems Investigator, Worldwide Cloud & Systems
> Performance, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> 
> 
> From:   "Vernooij, CP (ITOPT1) - KLM" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   22/12/2015 07:39
> Subject:Re: [Bulk] Re: Coupling Facility Structure Re-sizing
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Of course 'it depends'.
> 
> At least on the distance between the CFs. Signals are delayed by 10
usec/km.
> The number of signals traveling for SMCFSD have indeed been optimized
since
> the beginning, but it still makes a difference if the CF's are 1 or 15 kms
apart. Our
> latest researches from this year is that IBM still does not recommend
SMCFSD
> for Lock and SCA.
> 
> What is your configuration? If a CEC fails, others DB2's in the group
should do
> the recovery without delay. Did all your CECs and DB2s fail? Our
experience is
> that a group-restart is very fast, at max. 2 - 3 minutes and that are also
IBMs
> figures.
> Altogether, we still see advantages in not using SMCFSD for Lock and SCA.
> 
> Why did you decide different?
> 
> Kees.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Skip Robinson
> Sent: 21 December, 2015 20:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing
> 
> I'm talking from experience. The two hours-long CEC failures we had--most
> recently in the fall of 2014--took down all CICS and DB2 applications as
well as
> three ICFs on the box that failed. The secondary 'penalty' box stayed up
and kept
> live copies of structures so that after hardware repair, all LPARs--host
and CF--
> came up with no recovery needed. In particular, no DB2 log processing,
which is
> the worst case for recovery.
> 
> As for processing overhead, that's why IBM delayed SMCFSD. We're as
> concerned with performance as any shop. Millions of CICS/DB2 transactions
per
> hour. For DASD mirroring, we went with XRC (async) rather than PPRC
> (sync) for that reason. Today we see no visible delays from SMCFSD. This
is
> predicated on having enough CF engines to do the job. As previously
stated,
> beware of putting CF LPARs on hardware that's slower than the exploiters.
Note
> that CF, ZIIP, and IFL engines run at full rated speed even on a box
that's
> 'downsized' to run GP engines at less than maximum speed--to save software
> costs. That's why we're happy to 

Re: PTF error clarification

[Skip Robinson]

The CAUSER report is the papal encyclical. If there are utility errors, they 
will be enumerated in sufficient detail to ferret them out in minutes. Still 
way less trouble than building an exclude list, which leaves you to investigate 
utility errors anyway.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Tuesday, December 22, 2015 04:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: PTF error clarification
> 
> On Tue, 22 Dec 2015 14:59:52 -0800, Skip Robinson wrote:
> >
> >This is a hot button of mine: going to extraordinary lengths to second
> >guess SMPE. Like Santa Claus, SMPE knows who's been naughty and who's
> been nice.
> >Goodies and lumps of coal will be distributed accordingly. GROUPEXTEND
> >is
> >*always* in order. There's nothing wrong with RC 8. Resolvable hold
> >chains will be applied; unresolvable ones will be not. It's an utter
> >waste of time to build an exclude list just to achieve RC 0. That ploy
> >is decades obsolete and achieves nothing that SMPE won't deliver for free.
> >
> Is there a "Boy Who Cried 'Wolf!'" phenomenon?  You do APPLY CHECK and get
> RC=8.
> You investigate the causes and decide they're all OK.  So you APPLY for real 
> and
> tolerate the RC=8 because the CHECK was OK.  But this time there's  a utility
> failure.
> 
> I suppose you need to inspect the reports from APPLY as thoroughly as those
> from APPLY CHECK.  Whittling down the APPLY CHECK to RC=0 improves the S/N
> ratio for APPLY.  Hasn't there been a recent enhancement so BYPASS can get
> RC=0?
> 
> -- gil

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

Re: PTF error clarification

[Paul Gilmartin]

On Tue, 22 Dec 2015 14:59:52 -0800, Skip Robinson wrote:
>
>This is a hot button of mine: going to extraordinary lengths to second guess
>SMPE. Like Santa Claus, SMPE knows who's been naughty and who's been nice.
>Goodies and lumps of coal will be distributed accordingly. GROUPEXTEND is
>*always* in order. There's nothing wrong with RC 8. Resolvable hold chains
>will be applied; unresolvable ones will be not. It's an utter waste of time
>to build an exclude list just to achieve RC 0. That ploy is decades obsolete
>and achieves nothing that SMPE won't deliver for free.
>
Is there a "Boy Who Cried 'Wolf!'" phenomenon?  You do APPLY CHECK and get RC=8.
You investigate the causes and decide they're all OK.  So you APPLY for real 
and tolerate
the RC=8 because the CHECK was OK.  But this time there's  a utility failure.

I suppose you need to inspect the reports from APPLY as thoroughly as those from
APPLY CHECK.  Whittling down the APPLY CHECK to RC=0 improves the S/N ratio
for APPLY.  Hasn't there been a recent enhancement so BYPASS can get RC=0?

-- gil

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

Re: PTF error clarification

[Clark Morris]

On 22 Dec 2015 16:47:14 -0800, in bit.listserv.ibm-main you wrote:

>The CAUSER report is the papal encyclical. If there are utility errors, they 
>will be enumerated in sufficient detail to ferret them out in minutes. Still 
>way less trouble than building an exclude list, which leaves you to 
>investigate utility errors anyway.
>
Is a return code of 4 more appropriate for PTFs not applied because of
error hold? Actually for any kind of hold?  Are there holds that
should be bypassed such as Action after noting the action that should
be taken and scheduling it?

Clark Morris
>.
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>jo.skip.robin...@att.net
>jo.skip.robin...@gmail.com
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Paul Gilmartin
>> Sent: Tuesday, December 22, 2015 04:39 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: PTF error clarification
>> 
>> On Tue, 22 Dec 2015 14:59:52 -0800, Skip Robinson wrote:
>> >
>> >This is a hot button of mine: going to extraordinary lengths to second
>> >guess SMPE. Like Santa Claus, SMPE knows who's been naughty and who's
>> been nice.
>> >Goodies and lumps of coal will be distributed accordingly. GROUPEXTEND
>> >is
>> >*always* in order. There's nothing wrong with RC 8. Resolvable hold
>> >chains will be applied; unresolvable ones will be not. It's an utter
>> >waste of time to build an exclude list just to achieve RC 0. That ploy
>> >is decades obsolete and achieves nothing that SMPE won't deliver for free.
>> >
>> Is there a "Boy Who Cried 'Wolf!'" phenomenon?  You do APPLY CHECK and get
>> RC=8.
>> You investigate the causes and decide they're all OK.  So you APPLY for real 
>> and
>> tolerate the RC=8 because the CHECK was OK.  But this time there's  a utility
>> failure.
>> 
>> I suppose you need to inspect the reports from APPLY as thoroughly as those
>> from APPLY CHECK.  Whittling down the APPLY CHECK to RC=0 improves the S/N
>> ratio for APPLY.  Hasn't there been a recent enhancement so BYPASS can get
>> RC=0?
>> 
>> -- gil
>
>--
>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

Apache Spark Downloads Now Available from IBM

[Timothy Sipples]

Just in case you haven't heard the news, IBM has released the "IBM Packages
for Apache Spark," available for download at no charge here:

https://www.ibm.com/developerworks/java/jdk/spark/

Borrowing a little from Wikipedia, Apache Spark(TM) is an open source
cluster computing framework well suited to solving many types of big data
analytics problems, and it also supports certain types of machine learning
algorithms. Apache Spark is available for several platforms including
especially IBM z Systems. Both z/OS and Linux on z versions are available.
If you'd like some more information on typical use cases for Apache Spark
on IBM z Systems, this YouTube video should be helpful:

https://www.youtube.com/watch?v=sDmWcuO5Rk8

Some more introductory information on Apache Spark is available here:

http://www.ibmsystemsmag.com/mainframe/Business-Strategy/BI-and-Analytics/dynamic-Spark/?page=1

For z/OS you should have z/OS 2.1 or higher and the latest 64-bit IBM Java
SDK (Version 8). It's possible Apache Spark will run on z/OS 1.13, but IBM
has not tested that particular combination. If you don't have the latest
Java SDK you can get it here:

http://www.ibm.com/developerworks/java/jdk/

You also may need to download an updated version of bash. The installation
documentation explains how to do that. Check back periodically for updated
documentation that will detail more installation and configuration
scenarios such as deployment to a Parallel Sysplex.

Enjoy!


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: ASG ZEKE Responding to program generated messages

[Lizette Koehler]

I am not sure about Zeke, 
Are you looking at other products like IBM Tivoli Automation, AFOPER, CA 
OPS/MVS, BMC tools?

Or here on cbttape.org:

File # 627 AUTOMAN Console Operations Package
File # 770 Event Management System for Automation - Deru Sudibyo
File # 404 TSSO for OS/390 and z/OS


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Carl Edwards
> Sent: Tuesday, December 22, 2015 10:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ASG ZEKE Responding to program generated messages
> 
> I have a client that is considering installing ZEKE. Said client has a fair
> amount of console diakaig that needs to be automated. The questions is Can
> ZEKE recognize console messages generated via a program(DISPLAY UPON CONSOLE)
> and respond to such?
> 

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

Re: ASG ZEKE Responding to program generated messages

[Mitch Mccluhan]

 Hello,

I don't believe Zeke has that capability.  I personally recommend TWS from 
Tivoli.

 

Mitch McCluhan
mitc...@aol.com

 

 

-Original Message-
From: Carl Edwards <00df3759e3e7-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN 
Sent: Tue, Dec 22, 2015 12:00 pm
Subject: ASG ZEKE Responding to program generated messages

I have a client that is considering installing ZEKE. Said client has a fair 
amount of console diakaig that needs to be automated. The questions is Can ZEKE 
recognize console messages generated via a program(DISPLAY UPON CONSOLE) and 
respond to such? 


--
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

IEAVAPE2/IEAVPSE2 for SRB

[michelbutz]

Hi

I have two questions regarding the following services used to suspend a SRB

First if IEAVPSE2 suspends a SRB Then it in fact
Works like a WAIT execution stops after the SVC 2 from wait and BASR from 
IEAVPSE2 
So how would the updated STOKEN get returned

Second IEAVAPE2 has a parameter for address space token does this mean if I 
specify the STOKEN of address space "a" I can Suspend from address space b the 
current SRB running in "a"

Thanks 

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[R.S.]

W dniu 2015-12-22 o 21:58, Mike Schwab pisze:

UTF-8 includes them all.  But UTF-EBCDIC is only suggested
transformations, not storage.

Compatibility.
It is kind for recipients to use "lowest common denominator" instead of 
"my standard is the best one". I have no problems with viewing mu letter 
(it's much harder to type it), but I can imagine others still may have 
ones.


BTW: AFAIK mu is the only greek letter used as prefix. It wasn't good 
choice.


Note: there is (was?) also Å like Angstrem (Ångström), which is non-SI.  
It's 10^-10.
Obviously it's a name, 19th century Swedish scientist. The letter Å is 
also not the best choice.


--
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.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: PTF error clarification

[Skip Robinson]

This is a hot button of mine: going to extraordinary lengths to second guess
SMPE. Like Santa Claus, SMPE knows who's been naughty and who's been nice.
Goodies and lumps of coal will be distributed accordingly. GROUPEXTEND is
*always* in order. There's nothing wrong with RC 8. Resolvable hold chains
will be applied; unresolvable ones will be not. It's an utter waste of time
to build an exclude list just to achieve RC 0. That ploy is decades obsolete
and achieves nothing that SMPE won't deliver for free. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Longabaugh, Robert E
> Sent: Tuesday, December 22, 2015 10:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: PTF error clarification
> 
> Receive the HOLDDATA.  Then SMP/E checks for PE.  Do specify GROUPEXTEND
> (or GEXT).
> 
> Bob Longabaugh
> CA Technologies
> Storage Management QA
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Tuesday, December 22, 2015 11:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PTF error clarification
> 
> In
>  P_4n2wgVV7eZRvhsCNh+fDxP==s=xz...@mail.gmail.com>,
> on 12/22/2015
>at 05:32 PM, Jake Anderson  said:
> 
> >Does that mean, I have to receive the APAR
> 
> If there is a PTF that resolves the APAR, receive that. If not, and there
is an APAR
> fix, receive that. Either way, specify group extend.
> But first check for PE.
> 
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Paul Gilmartin]

On 2015-12-22 11:15, R.S. wrote:
> It would be better to define usec at the first occurence.
> Or use full name: 'microsecond'.
> BTW: 'us' seems to be more cryptic, while it's more correct than usec.
> 
what about "μs"

-- gil

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

Re: Where is SET allowed in JCL?

[Paul Gilmartin]

On Tue, 22 Dec 2015 21:41:21 -0600, Paul Gilmartin wrote:

>Sometimes within a DD concatenation; sometimes not.  For example:
>
>3 //STEP  EXEC  PGM=IEFBR14   
>  //* 
>4 //DD1DD   * 
>5 //   DD   PATH='/dev/./null'
>6 //  SET V1=WOMBAT   
>7 //   DD   PATH='/dev/./null'
>  //* 
>8 //DD2DD   * 
>9 //  SET V2=WOMBAT   
>   10 //   DD   PATH='/dev/./null'
>   11 //  
> STMT NO. MESSAGE 
>   10 IEFC019I MISPLACED DD STATEMENT  
>
>Why does it report IEFC019I at statement 10, but not at statement 7?
>
>I had grown accustomed to placing SET in complex concatenations, near
>a reference for clarity.  Today was the first time I tried it after DD *.
>
>Should I submit an RCF requesting clarification or an SR for inconsistent
>behavior?
>
>I hate JCL!
>
Aargh!  It's documented!:

Location in the JCL
z/OS MVS JCL Reference
SA23-1385-00
...
It cannot appear immediately after the first DD statement within a 
concatenation.

YTF!?  Does anyone believe it was specified that way, or instead that a coder
wrote the code and when someone stumbled on the behavior it was documented
as a restriction?  I wonder if it was documented that way in the earliest JCL
reference in which SET was described?

I hate JCL!

-- gil

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Robert A. Rosenberg]

At 23:59 +0100 on 12/22/2015, R.S. wrote about Re: [Bulk] Re: 
Coupling Facility Structure Re-sizing:


I have no problems with viewing mu letter (it's much harder to type 
it), but I can imagine others still may have ones.


HARD TO TYPE? On a Mac it is Option-m. On a Windows machine, there is 
a similar key combination (alt-m I think).


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

Where is SET allowed in JCL?

[Paul Gilmartin]

Sometimes within a DD concatenation; sometimes not.  For example:

3 //STEP  EXEC  PGM=IEFBR14   
  //* 
4 //DD1DD   * 
5 //   DD   PATH='/dev/./null'
6 //  SET V1=WOMBAT   
7 //   DD   PATH='/dev/./null'
  //* 
8 //DD2DD   * 
9 //  SET V2=WOMBAT   
   10 //   DD   PATH='/dev/./null'
   11 //  
 STMT NO. MESSAGE 
   10 IEFC019I MISPLACED DD STATEMENT  

Why does it report IEFC019I at statement 10, but not at statement 7?

I had grown accustomed to placing SET in complex concatenations, near
a reference for clarity.  Today was the first time I tried it after DD *.

Should I submit an RCF requesting clarification or an SR for inconsistent
behavior?

I hate JCL!

-- gil

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Robert A. Rosenberg]

At 03:58 -0600 on 12/22/2015, Elardus Engelbrecht wrote about Re: 
[Bulk] Re: Coupling Facility Structure Re-sizing:



Vernooij, CP (ITOPT1) - KLM wrote:

Yes, u as a replacement of the greek letter mu, used to indicate 
the micro prefix, where the greek letter cannot be used.


Many thanks. Much appreciated. I agree it can be somewhat 
troublesome to send Greek and Russian (or Japanese) characters via 
e-mail or webpage. Either you use the wrong font / codepage or it is 
enforced up you... groan...


Via Email just go UTF-8. The same for Web Pages or just use the 
Unicode codepoint () or . BTW: This symbol is part of 
ISO-8859-1 as codepoint b5 (181) so should be easy to add to normal 
email - µ.




I will try to post this greek letter via IB-MAIN web-page below this 
line and see what happens (and send a copy to my e-mail address:

É s


It came through as a UTF-8 character.



I just wonder why only microsecond has this greek letter, but nano, 
pico, femto, etc. don't have greek letters.


I think I will not spend one more microsecond of my time on this thread...

Thanks Kees for your kind answer! Much appreciated.

Groete / Greetings
Elardus Engelbrecht

--
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: SNTP client on z/OS

[Pommier, Rex]

Hi Craig,

Not quite the same question.  We already have NTP running on the windows boxes. 
 I was asked if the mainframe could participate as a client, getting its time 
from a windows based NTP server.

Thanks,

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Craig Pace
Sent: Tuesday, December 22, 2015 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SNTP client on z/OS

If I am understanding your question correctly, you are wanting the mainframe to 
be the NTP correct?  If this is the question, then the answer is yes.  In fact, 
we once ran the SNTP server in both OS/390 V2R10 and z/OS V1R4 for just this so 
that the distributed systems could use the mainframe as their time source.




Thanks,

Craig Pace
Senior Manager Technical Services
Fruit of the Loom, Inc.®

Direct: (270) 935-4397
Main:   (270) 781-6400 ext 4397
Cell:   (270) 991-7452
Fax:(270) 438-4430

E-mail:  craig.p...@fotlinc.com

Mailing Address:
One Fruit of the Loom Drive
PO Box 90015
Bowling Green, KY 42102-9015

Physical Address:
675 Hennessy Way
Bowling Green, KY 42101-7122

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Tuesday, December 22, 2015 09:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SNTP client on z/OS

Hello all,

I have what I hope will be a quick question.  I've seen older threads on this 
subject that are several years old, and even then, I saw a lot of "yes it can" 
versus "no it can't".  SO here's my scenario and question (based on management 
asking me).

We are running a zBC12, 2 LPARs, z/OS 1.13, no sysplex.  Can z/OS in this 
environment function as an NTP client without needing to buy/install/implement 
STP on the z?

I've done some research/reading on this but haven't found the definitive 
answer.  If somebody could point me to where the answer is, that would be much 
appreciated.

TIA

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

IXGLOGR on RSM usage

[Nathan Astle]

Hi

Are there any best practices documented to reduce real storage usage of
IXGLOGR ?

We are in base sysplex.

z/OS 2.1

Regards
Nathan

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Elardus Engelbrecht]

Vernooij, CP (ITOPT1) - KLM wrote:

>Yes, u as a replacement of the greek letter mu, used to indicate the micro 
>prefix, where the greek letter cannot be used. 
 
Many thanks. Much appreciated. I agree it can be somewhat troublesome to send 
Greek and Russian (or Japanese) characters via e-mail or webpage. Either you 
use the wrong font / codepage or it is enforced up you... groan...

I will try to post this greek letter via IB-MAIN web-page below this line and 
see what happens (and send a copy to my e-mail address: 
μs

I just wonder why only microsecond has this greek letter, but nano, pico, 
femto, etc. don't have greek letters.

I think I will not spend one more microsecond of my time on this thread... ;-)

Thanks Kees for your kind answer! Much appreciated.

Groete / Greetings 
Elardus Engelbrecht 

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Vernooij, CP (ITOPT1) - KLM]

The mu was readable, but for some reason I hesitate to bet on relying on it.
When both milli and micro abbreviate to the same letter m (and mega already 
abbreviates to M), you must invent something. No technician would like to make 
a guess for mseconds or mmeters between their milli and micro versions. 

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 22 December, 2015 10:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing

Vernooij, CP (ITOPT1) - KLM wrote:

>Yes, u as a replacement of the greek letter mu, used to indicate the micro 
>prefix, where the greek letter cannot be used. 
 
Many thanks. Much appreciated. I agree it can be somewhat troublesome to send 
Greek and Russian (or Japanese) characters via e-mail or webpage. Either you 
use the wrong font / codepage or it is enforced up you... groan...

I will try to post this greek letter via IB-MAIN web-page below this line and 
see what happens (and send a copy to my e-mail address: 
μs

I just wonder why only microsecond has this greek letter, but nano, pico, 
femto, etc. don't have greek letters.

I think I will not spend one more microsecond of my time on this thread... ;-)

Thanks Kees for your kind answer! Much appreciated.

Groete / Greetings 
Elardus Engelbrecht 

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

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Elardus Engelbrecht]

Vernooij, CP (ITOPT1) - KLM wrote:

>One crucial parameter: at what distance are the CFs? 

Distance is indeed important.

>... 5 usecs  ... 150 usecs ...

First time I see 'usecs' here [1] on IBM-MAIM. After looking in Wikipedia, I 
want to know - is this microseconds? ( SI unit of time equal to one millionth 
of a second)?

Just curious please.

Groete / Greetings
Elardus Engelbrecht

[1] - from the context - this is not a Linux variable.

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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Vernooij, CP (ITOPT1) - KLM]

One crucial parameter: at what distance are the CFs? 
There must be a noticable difference between 5 usecs for an unduplexed local CF 
or a number of 150 usecs signals between CFs at 15 km distance.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: 22 December, 2015 8:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing

We're not going to BLANKET recommend System-Managed Duplexing for 
high-volume, high stringency structures such as LOCK1. SCA has little 
traffic.

But I've seen MANY customers (including the one I worked with yesterday 
here in Istanbul) that successfully use it. And I support their use of it. 
Other customers:

1) Have a failure-isolated CF for such structures.

Or

2) Take the risk of doing neither.

I've seen all 3 architectures even in the past 6 months. And your local 
IBMer is normally willing to give their view, hopefully backed up by data 
and people who know what they're talking about. :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   "Vernooij, CP (ITOPT1) - KLM" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 07:39
Subject:Re: [Bulk] Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



Of course 'it depends'.

At least on the distance between the CFs. Signals are delayed by 10 
usec/km. The number of signals traveling for SMCFSD have indeed been 
optimized since the beginning, but it still makes a difference if the CF's 
are 1 or 15 kms apart. Our latest researches from this year is that IBM 
still does not recommend SMCFSD for Lock and SCA.

What is your configuration? If a CEC fails, others DB2's in the group 
should do the recovery without delay. Did all your CECs and DB2s fail? Our 
experience is that a group-restart is very fast, at max. 2 - 3 minutes and 
that are also IBMs figures.
Altogether, we still see advantages in not using SMCFSD for Lock and SCA.

Why did you decide different?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Skip Robinson
Sent: 21 December, 2015 20:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing

I'm talking from experience. The two hours-long CEC failures we had--most 
recently in the fall of 2014--took down all CICS and DB2 applications as 
well as three ICFs on the box that failed. The secondary 'penalty' box 
stayed up and kept live copies of structures so that after hardware 
repair, all LPARs--host and CF--came up with no recovery needed. In 
particular, no DB2 log processing, which is the worst case for recovery.

As for processing overhead, that's why IBM delayed SMCFSD. We're as 
concerned with performance as any shop. Millions of CICS/DB2 transactions 
per hour. For DASD mirroring, we went with XRC (async) rather than PPRC 
(sync) for that reason. Today we see no visible delays from SMCFSD. This 
is predicated on having enough CF engines to do the job. As previously 
stated, beware of putting CF LPARs on hardware that's slower than the 
exploiters. Note that CF, ZIIP, and IFL engines run at full rated speed 
even on a box that's 'downsized' to run GP engines at less than maximum 
speed--to save software costs. That's why we're happy to put ICFs on 
otherwise slower penalty boxes. 
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler The
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Vernooij, CP (ITOPT1) - KLM
> Sent: Sunday, December 20, 2015 11:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Coupling Facility Structure Re-sizing
> 
> Your last statement is far too general in my opinion. SMCFSD is not 
free: besides
> memory, which indeed is cheap these days, it will cost performance, like 
PPRC
> does.
> So one must always make the decision about having high availability or 
high
> performance.
> Even without SMCFSD, Structure availability is very high. And in the 
rare event of
> a CF failure (when was you last one?) each exploiter of CF Structures 
should be
> able to recover from that failure. In my experience they all do, except 
MQ.
> If  you have a CF failure, the structures are recovered within seconds 
or minutes.
> If you can't bear the recovery delay, you can use Duplexing. Besides 
that, if you
> have a CF failure, what other problems do you have? Do you still need 
the zero
> recovery delay then?
> 
> Kees.
> 
> 

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Vernooij, CP (ITOPT1) - KLM]

Yes, u as a replacement of the greek letter mu, used to indicate the micro 
prefix, where the greek letter cannot be used.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 22 December, 2015 10:16
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing

Vernooij, CP (ITOPT1) - KLM wrote:

>One crucial parameter: at what distance are the CFs? 

Distance is indeed important.

>... 5 usecs  ... 150 usecs ...

First time I see 'usecs' here [1] on IBM-MAIM. After looking in Wikipedia, I 
want to know - is this microseconds? ( SI unit of time equal to one millionth 
of a second)?

Just curious please.

Groete / Greetings
Elardus Engelbrecht

[1] - from the context - this is not a Linux variable.

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

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

Re: S00C Slip trap for any Stc

[Mark A. Brooks]

The key piece of information missing from the discussion is the abend reason 
code that would have been issued with the XCF abend code 00C.  The reason codes 
meant for customer consumption will be documented with explanations in "MVS 
System Codes" book; anything else is likely an "internal error" for which an 
XCF dump should have been produced.  Can't really say much without that reason 
code.

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

Re: managing /tmp

[Jousma, David]

Kirk,

Thanks for that.  IBM also recommends using skulker.  If I were more adept in 
writing scripts, I'd take the current skulker script and modify it to include a 
few of the useful commands you noted in your item #3.  For example, skulker 
only looks at last access date, but not whether or not a process is still using 
the file, and will delete the entry anyway(I realize the process still has the 
inode allocated until it goes away).  But why not include logic to do a "fuser 
-u file"?  Even then many processes write .pid file that may be needed later.

In my case, for /tmp, I am going to continue to use a TFS, because it does 
start fresh and empty with every IPL, and at our shop that’s about once every 6 
months.   For the couple of my DB2 users that had trouble with space in /tmp 
using IDAA tool, I have created a .profile in their home directory, and added 
TMPDIR= specification that should redirect their /tmp usage to a different 
location.  And lastly I am going to up the size of my /tmp from 256M to 512M.  
At this time skulker just adds way too many issues to work around for the 
limited benefit at my shop.   If I hadn't implemented the automatic offload 
facility of SYSLOGD, I'd have used skulker to cleanup historical data from it 
in /var/logs as that data I *know* is typical log data, and once a new day 
starts, the prior is no longer allocated or in use.

Dave
_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Monday, December 21, 2015 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: managing /tmp

Here are some notes in the appendix of our quick-guide for setting up IBM 
Ported Tools OpenSSH that mention "Best practices" for managing /tmp space.

Any ideas or suggestions for improvement are appreciated.

http://dovetail.com/docs/pt-quick-inst/pto-inst-tmp.html

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Mon, Dec 21, 2015 at 10:15 AM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In
> <
> 4ee2851a2279b94cb70cd69b174106090149665...@s1flokydce2kx01.dm0001.info
> 53.com
> >,
> on 12/21/2015
>at 01:09 PM, "Jousma, David"  said:
>
> >Seems as though that tool wants to use /tmp space between copying 
> >data from DB2 filesystem to IDAA hardware.
>
> In what directory?
>
> >they claim there is no way to override what to use for temp space.
>
> Mount?
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> 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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

PTF error clarification

[Jake Anderson]

Hi,

I am applying few toleration fixes for a hardware but I a receiving the
below error message.

CAUSER SYSMOD SUMMARY REPORT FOR APPLY CHECK PROCESSING



CAUSER   FMID MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE CAUSES



UA90976  HBB7790  GIM35901I  2   ERROR HOLD AA49159 WAS NOT RESOLVED.

PAGE 0003  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
 SMP/E


UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK PROCESSING



NOTE: THE SYSMODS LISTED IN THIS REPORT ALSO APPEAR IN THE CAUSER SYSMOD
SUMMARY


 HOLD MISSING  HELD RESOLVING  RESOLVER

TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS

--  ---  ---  ---  ---  -  

ERROR   HBB7790  PE   AA48273  UA90976  UA78633NOGO(H)

UA78870NOGO(H)

  AA48642  UA90976  UA78971NOGO(H)

  AA48858  UA90978  UA78965NOGO(H)

  AA49159  UA90976

PAGE 0004  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
 SMP/E


SUMMARY OF BYPASSED AND UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK
PROCESSING


NOTE: SEE THE HOLDDATA REPORT OF UNRESOLVED HOLD REASON IDS TO DETERMINE
HOLDS C
  SEE THE HOLDDATA REPORT OF BYPASSED HOLD REASON IDS TO DETERMINE
HOLDS THA



Does that mean, I have to receive the APAR

MISSING
APAR
---
AA48273

AA48642
AA48858
AA49159

z/OS 2.1

Regards,
Jake

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

Re: managing /tmp

[Jousma, David]

Mark,

I asked IBM about that, but in their words, the timing of that command was hard 
to pin down.  It would have to be early enough in the startup or last thing in 
the shutdown (prior to F BPXOINIT,shutdown=filesys).  They didn't sound too 
keen on the idea.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Post
Sent: Monday, December 21, 2015 5:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: managing /tmp

>>> On 12/21/2015 at 08:09 AM, "Jousma, David"  wrote: 
> All,
> 
> We have for the longest time used a  256MB TFS for /tmp.  Beauty of that is 
> with every IPL, the transient data is wiped out, and start fresh again.   
> We've very rarely ever run into filesystem space problems.  However, 
> our DB2 sysprogs are running into problems when performing maintenance 
> activities on our IDAA appliances when loading new/updated code to it 
> via their gui interface.  Seems as though that tool wants to use /tmp space 
> between copying
> data from DB2 filesystem to IDAA hardware.   Some of these objects are 2G or 
> larger in size, so they have run into space problems, and they claim 
> there is no way to override what to use for temp space.
> 
> So, I've been contemplating making /tmp a standard ZFS of sufficient 
> size, but am wondering how you all setup controls to manage the space?

Aside from what others have mentioned, an additional thing you could do is with 
every IPL, do an "rm -rf /tmp/*" command.  This will replicate the previous 
behavior in that everything goes away with an IPL, so there shouldn't be a 
significant backlash from it.

If you were able to get by with a 256MB /tmp before, and are only doing this 
for one (mis-behaving) application, I'm not sure that skulker is really going 
to be that necessary.  Of course, time will tell.


Mark Post

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Mark A. Brooks wrote:

>The key piece of information missing from the discussion is the abend reason 
>code that would have been issued with the XCF abend code 00C.  The reason 
>codes meant for customer consumption will be documented with explanations in 
>"MVS System Codes" book; anything else is likely an "internal error" for which 
>an XCF dump should have been produced.  Can't really say much without that 
>reason code.

Good catch. I had to review the whole thread to refresh my memory.

The OP should say what z/OS level is he using, what reason code is he getting 
and what actions were done at all. 
For example were there any LOGREC records, were any D XCF,??? commands done, 
etc.

Mark, you are also right about reason code, because depending on it, you may 
get two dumps, not one. Or you get only a SVC dump or only a MVS dump or only a 
LOGREC dump. 

Depending on the reason code, the OP should post the IXC??? message(s) too.

I would also advise the OP to also check "z/OS MVS Diagnosis: Reference" for 
more background info.

Groete / Greetings
Elardus Engelbrecht

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

Re: PTF error clarification

[Lizette Koehler]

When an APAR has HOLD ERROR, you should not do anything until IBM resolves the 
error. So SMP/E is doing what it is supposed to do. Prevent you from installing 
fixes that could harm your system.

With these types of issues I raise an SR to IBM and ask when this error will be 
resolved.  I never put on fixes that have hold errors.  I wait until they are 
fixed.  And that means any PTFs affected by this issue do not go on.  Or if I 
am desperate to put on the fixes, I ask IBM how to do that.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Tuesday, December 22, 2015 5:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PTF error clarification
> 
> Hi,
> 
> I am applying few toleration fixes for a hardware but I a receiving the below
> error message.
> 
> CAUSER SYSMOD SUMMARY REPORT FOR APPLY CHECK PROCESSING
> 
> 
> 
> CAUSER   FMID MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE CAUSES
> 
> 
> 
> UA90976  HBB7790  GIM35901I  2   ERROR HOLD AA49159 WAS NOT RESOLVED.
> 
> PAGE 0003  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
>  SMP/E
> 
> 
> UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
> 
> 
> 
> NOTE: THE SYSMODS LISTED IN THIS REPORT ALSO APPEAR IN THE CAUSER SYSMOD
> SUMMARY
> 
> 
>  HOLD MISSING  HELD RESOLVING  RESOLVER
> 
> TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS
> 
> --  ---  ---  ---  ---  -  
> 
> ERROR   HBB7790  PE   AA48273  UA90976  UA78633NOGO(H)
> 
> UA78870NOGO(H)
> 
>   AA48642  UA90976  UA78971NOGO(H)
> 
>   AA48858  UA90978  UA78965NOGO(H)
> 
>   AA49159  UA90976
> 
> PAGE 0004  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
>  SMP/E
> 
> 
> SUMMARY OF BYPASSED AND UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK
> PROCESSING
> 
> 
> NOTE: SEE THE HOLDDATA REPORT OF UNRESOLVED HOLD REASON IDS TO DETERMINE HOLDS
> C
>   SEE THE HOLDDATA REPORT OF BYPASSED HOLD REASON IDS TO DETERMINE HOLDS
> THA
> 
> 
> 
> Does that mean, I have to receive the APAR
> 
> MISSING
> APAR
> ---
> AA48273
> 
> AA48642
> AA48858
> AA49159
> 
> z/OS 2.1
> 
> Regards,
> Jake

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

Re: PTF error clarification

[Richards, Robert B.]

View the APAR. It tells you exactly what you can do until a fixing PTF is 
available.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, December 22, 2015 7:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PTF error clarification

When an APAR has HOLD ERROR, you should not do anything until IBM resolves the 
error. So SMP/E is doing what it is supposed to do. Prevent you from installing 
fixes that could harm your system.

With these types of issues I raise an SR to IBM and ask when this error will be 
resolved.  I never put on fixes that have hold errors.  I wait until they are 
fixed.  And that means any PTFs affected by this issue do not go on.  Or if I 
am desperate to put on the fixes, I ask IBM how to do that.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jake Anderson
> Sent: Tuesday, December 22, 2015 5:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PTF error clarification
> 
> Hi,
> 
> I am applying few toleration fixes for a hardware but I a receiving 
> the below error message.
> 
> CAUSER SYSMOD SUMMARY REPORT FOR APPLY CHECK PROCESSING
> 
> 
> 
> CAUSER   FMID MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE CAUSES
> 
> 
> 
> UA90976  HBB7790  GIM35901I  2   ERROR HOLD AA49159 WAS NOT RESOLVED.
> 
> PAGE 0003  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
>  SMP/E
> 
> 
> UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK PROCESSING
> 
> 
> 
> NOTE: THE SYSMODS LISTED IN THIS REPORT ALSO APPEAR IN THE CAUSER 
> SYSMOD SUMMARY
> 
> 
>  HOLD MISSING  HELD RESOLVING  RESOLVER
> 
> TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS
> 
> --  ---  ---  ---  ---  -  
> 
> ERROR   HBB7790  PE   AA48273  UA90976  UA78633NOGO(H)
> 
> UA78870NOGO(H)
> 
>   AA48642  UA90976  UA78971NOGO(H)
> 
>   AA48858  UA90978  UA78965NOGO(H)
> 
>   AA49159  UA90976
> 
> PAGE 0004  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
>  SMP/E
> 
> 
> SUMMARY OF BYPASSED AND UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK 
> PROCESSING
> 
> 
> NOTE: SEE THE HOLDDATA REPORT OF UNRESOLVED HOLD REASON IDS TO 
> DETERMINE HOLDS C
>   SEE THE HOLDDATA REPORT OF BYPASSED HOLD REASON IDS TO DETERMINE 
> HOLDS THA
> 
> 
> 
> Does that mean, I have to receive the APAR
> 
> MISSING
> APAR
> ---
> AA48273
> 
> AA48642
> AA48858
> AA49159
> 
> z/OS 2.1
> 
> Regards,
> Jake

--
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: SNTP client on z/OS

[Jousma, David]

I don’t believe that would work.   The definitive answer would be to open a Q 
with IBM support.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Tuesday, December 22, 2015 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SNTP client on z/OS

Hi Craig,

Not quite the same question.  We already have NTP running on the windows boxes. 
 I was asked if the mainframe could participate as a client, getting its time 
from a windows based NTP server.

Thanks,

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Craig Pace
Sent: Tuesday, December 22, 2015 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SNTP client on z/OS

If I am understanding your question correctly, you are wanting the mainframe to 
be the NTP correct?  If this is the question, then the answer is yes.  In fact, 
we once ran the SNTP server in both OS/390 V2R10 and z/OS V1R4 for just this so 
that the distributed systems could use the mainframe as their time source.




Thanks,

Craig Pace
Senior Manager Technical Services
Fruit of the Loom, Inc.®

Direct: (270) 935-4397
Main:   (270) 781-6400 ext 4397
Cell:   (270) 991-7452
Fax:(270) 438-4430

E-mail:  craig.p...@fotlinc.com

Mailing Address:
One Fruit of the Loom Drive
PO Box 90015
Bowling Green, KY 42102-9015

Physical Address:
675 Hennessy Way
Bowling Green, KY 42101-7122

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Tuesday, December 22, 2015 09:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SNTP client on z/OS

Hello all,

I have what I hope will be a quick question.  I've seen older threads on this 
subject that are several years old, and even then, I saw a lot of "yes it can" 
versus "no it can't".  SO here's my scenario and question (based on management 
asking me).

We are running a zBC12, 2 LPARs, z/OS 1.13, no sysplex.  Can z/OS in this 
environment function as an NTP client without needing to buy/install/implement 
STP on the z?

I've done some research/reading on this but haven't found the definitive 
answer.  If somebody could point me to where the answer is, that would be much 
appreciated.

TIA

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

This e-mail transmission contains 

Re: SNTP client on z/OS

[John McKown]

On Tue, Dec 22, 2015 at 10:17 AM, Pommier, Rex 
wrote:

> Hi Craig,
>
> Not quite the same question.  We already have NTP running on the windows
> boxes.  I was asked if the mainframe could participate as a client, getting
> its time from a windows based NTP server.
>

​If you mean "steer the TOD clock" (i.e. speed it up or slow it down to
slowly synchronize it), then the answer is NO. That requires the STP
hardware to do. Even if you could do an SCK (Set Clock) instruction to set
the TOD clock, you would most likely cause z/OS to hard wait because there
is _NO_ API into z/OS to tell it you did it. If you set it backwards, you
are guaranteed to hard wait.

But you could use a custom NTP client to change the _local_ time by
adjusting the offset. The simplest way would be to just have your NTP
client code do a 'T CLOCK=' command. This doesn't change the TOD hardware
clock. It does not affect the TIME macro if you requiest "GMT" time. But it
will reset the local time. Oh, this is _not_ going to help if you problem
is that you are trying to get Kerberos or some other SSL process to work
because I'm fairly sure that they use the TOD hardware clock (STCK or STCKE
instruction).​



>
> Thanks,
>
> Rex
>

-- 
Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: SNTP client on z/OS

[Skip Robinson]

We use an external NTP server as time source for three CECs. However, we also 
have STP installed on all three, so I can't answer the question of whether you 
can do this without STP. As Dave said, you should probably take this question 
directly to IBM. Years ago we had some SHARE sessions from a user who had 
developed a homegrown solution. But those were the days of the 9037 sysplex 
timer. I'm not sure that his solution would have worked otherwise. The problem 
I believe is that you need a gizmo to process the NTP signal. For modern z 
boxes, that is STP. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jousma, David
> Sent: Tuesday, December 22, 2015 08:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: SNTP client on z/OS
> 
> I don’t believe that would work.   The definitive answer would be to open a 
> Q
> with IBM support.
> 
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pommier, Rex
> Sent: Tuesday, December 22, 2015 11:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SNTP client on z/OS
> 
> Hi Craig,
> 
> Not quite the same question.  We already have NTP running on the windows
> boxes.  I was asked if the mainframe could participate as a client, getting 
> its
> time from a windows based NTP server.
> 
> Thanks,
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Craig Pace
> Sent: Tuesday, December 22, 2015 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SNTP client on z/OS
> 
> If I am understanding your question correctly, you are wanting the mainframe 
> to
> be the NTP correct?  If this is the question, then the answer is yes.  In 
> fact, we
> once ran the SNTP server in both OS/390 V2R10 and z/OS V1R4 for just this so
> that the distributed systems could use the mainframe as their time source.
> 
> 
> 
> 
> Thanks,
> 
> Craig Pace
> Senior Manager Technical Services
> Fruit of the Loom, Inc.®
> 
> Direct: (270) 935-4397
> Main:   (270) 781-6400 ext 4397
> Cell:   (270) 991-7452
> Fax:(270) 438-4430
> 
> E-mail:  craig.p...@fotlinc.com
> 
> Mailing Address:
> One Fruit of the Loom Drive
> PO Box 90015
> Bowling Green, KY 42102-9015
> 
> Physical Address:
> 675 Hennessy Way
> Bowling Green, KY 42101-7122
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pommier, Rex
> Sent: Tuesday, December 22, 2015 09:58
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SNTP client on z/OS
> 
> Hello all,
> 
> I have what I hope will be a quick question.  I've seen older threads on this
> subject that are several years old, and even then, I saw a lot of "yes it can"
> versus "no it can't".  SO here's my scenario and question (based on management
> asking me).
> 
> We are running a zBC12, 2 LPARs, z/OS 1.13, no sysplex.  Can z/OS in this
> environment function as an NTP client without needing to buy/install/implement
> STP on the z?
> 
> I've done some research/reading on this but haven't found the definitive 
> answer.
> If somebody could point me to where the answer is, that would be much
> appreciated.
> 
> TIA
> 
> Rex

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

SNTP client on z/OS

[Pommier, Rex]

Hello all,

I have what I hope will be a quick question.  I've seen older threads on this 
subject that are several years old, and even then, I saw a lot of "yes it can" 
versus "no it can't".  SO here's my scenario and question (based on management 
asking me).

We are running a zBC12, 2 LPARs, z/OS 1.13, no sysplex.  Can z/OS in this 
environment function as an NTP client without needing to buy/install/implement 
STP on the z?

I've done some research/reading on this but haven't found the definitive 
answer.  If somebody could point me to where the answer is, that would be much 
appreciated.

TIA

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: SNTP client on z/OS

[Craig Pace]

If I am understanding your question correctly, you are wanting the mainframe to 
be the NTP correct?  If this is the question, then the answer is yes.  In fact, 
we once ran the SNTP server in both OS/390 V2R10 and z/OS V1R4 for just this so 
that the distributed systems could use the mainframe as their time source.




Thanks,

Craig Pace
Senior Manager Technical Services
Fruit of the Loom, Inc.®

Direct: (270) 935-4397
Main:   (270) 781-6400 ext 4397
Cell:   (270) 991-7452
Fax:(270) 438-4430

E-mail:  craig.p...@fotlinc.com

Mailing Address:
One Fruit of the Loom Drive
PO Box 90015
Bowling Green, KY 42102-9015

Physical Address:
675 Hennessy Way
Bowling Green, KY 42101-7122

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Tuesday, December 22, 2015 09:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SNTP client on z/OS

Hello all,

I have what I hope will be a quick question.  I've seen older threads on this 
subject that are several years old, and even then, I saw a lot of "yes it can" 
versus "no it can't".  SO here's my scenario and question (based on management 
asking me).

We are running a zBC12, 2 LPARs, z/OS 1.13, no sysplex.  Can z/OS in this 
environment function as an NTP client without needing to buy/install/implement 
STP on the z?

I've done some research/reading on this but haven't found the definitive 
answer.  If somebody could point me to where the answer is, that would be much 
appreciated.

TIA

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

Re: 4341 history typo [was: DOS descendant still lives]

[Neil Duffee]

Caveat:  as a daily digester, I'm sure someone else has already made the same 
observation, but...

*hee, hee*  I know it's probably a typo but it was a good'un for my last day of 
work this year...   gloating poin arithmetic 

>  signature = 8 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?"  Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent"  John Norgauer 2004
"Schrodinger's backup: The condition of any backup is unknown until a restore 
is attempted."  John McKown 2015


-Original Message-
From: Shmuel Metz (Seymour J.) [mailto:shm...@pat...net] 
Sent: December 21, 2015 14:35
Subject: Re: DOS descendant still lives was Re: slight reprieve on the z.

In <87egefr5wr@garlic.com>, on 12/21/2015
   at 10:52 AM, Anne & Lynn Wheeler  said:

>It showed 4341 was faster than 158&3031

Doesn't that depend on whether your benchmark is packed decimal or gloating 
poin arithmetic?

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

Re: PTF error clarification

[Pommier, Rex]

Jake,

The report is showing that you already have the fixes in house for most of the 
APARs being reported.  The only one that is missing is the one showing in the 
CAUSER report.  You need to go back to IBM and find out if the PTF that fixes 
APAR AA49159 is available and good (i.e. it doesn't have an open APAR against 
it as well).  If the fix is available, obtain it from IBM, and RECEIVE it.  
Then when you run the APPLY, the fixing PTF should be picked up and allow the 
code to get installed.  If the fix isn't available, then it is time to tread 
lightly.  :-)  I have on occasion researched open APARs against a PTF that I 
needed installed and have either bypassed the open APAR if I decided the bug in 
the APAR wasn't going to affect my installation, or I have held off on 
installing the PTF with the APAR against it deeming the bug introduced by the 
PE'ed PTF was worse than the bug being fixed by the original PTF.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Tuesday, December 22, 2015 6:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PTF error clarification

Hi,

I am applying few toleration fixes for a hardware but I a receiving the
below error message.

CAUSER SYSMOD SUMMARY REPORT FOR APPLY CHECK PROCESSING



CAUSER   FMID MESSAGE ID  PAGE   ERROR DESCRIPTION AND POSSIBLE CAUSES



UA90976  HBB7790  GIM35901I  2   ERROR HOLD AA49159 WAS NOT RESOLVED.

PAGE 0003  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
 SMP/E


UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK PROCESSING



NOTE: THE SYSMODS LISTED IN THIS REPORT ALSO APPEAR IN THE CAUSER SYSMOD
SUMMARY


 HOLD MISSING  HELD RESOLVING  RESOLVER

TYPEFMID CLASSAPAR SYSMOD   SYSMOD STATUS

--  ---  ---  ---  ---  -  

ERROR   HBB7790  PE   AA48273  UA90976  UA78633NOGO(H)

UA78870NOGO(H)

  AA48642  UA90976  UA78971NOGO(H)

  AA48858  UA90978  UA78965NOGO(H)

  AA49159  UA90976

PAGE 0004  - NOW SET TO TARGET ZONE TZN210   DATE 12/22/15  TIME 06:33:34
 SMP/E


SUMMARY OF BYPASSED AND UNRESOLVED HOLD REASON REPORT FOR APPLY CHECK
PROCESSING


NOTE: SEE THE HOLDDATA REPORT OF UNRESOLVED HOLD REASON IDS TO DETERMINE
HOLDS C
  SEE THE HOLDDATA REPORT OF BYPASSED HOLD REASON IDS TO DETERMINE
HOLDS THA



Does that mean, I have to receive the APAR

MISSING
APAR
---
AA48273

AA48642
AA48858
AA49159

z/OS 2.1

Regards,
Jake

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: [Bulk] Re: Coupling Facility Structure Re-sizing

[Shmuel Metz (Seymour J.)]

In
<2623328940257590.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 12/22/2015
   at 03:15 AM, Elardus Engelbrecht 
said:

>First time I see 'usecs' here [1] on IBM-MAIM.

I've never seen usec or Ásec[1] on IBM-MAIM. I have, however, seen
them on IBM-MAIN.

[1] That should come out sec


--
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: PTF error clarification

[Shmuel Metz (Seymour J.)]

In
,
on 12/22/2015
   at 05:32 PM, Jake Anderson  said:

>Does that mean, I have to receive the APAR

If there is a PTF that resolves the APAR, receive that. If not, and
there is an APAR fix, receive that. Either way, specify group extend.
But first check for PE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Where is SET allowed in JCL?

[Lizette Koehler]

Here is what the JCL manual  z/OS MVS JCL Reference SA23-1385-00 Location in 
the JCL states:

A SET statement can appear anywhere in the job after the JOB statement with the 
following restrictions:

It must appear in the job's JCL before the intended use of the symbolic 
parameter.
It must follow a complete JCL statement.
It cannot appear immediately after the first DD statement within a 
concatenation.

Examples: The following JCL will work.

//DD1   DD  DSN=dsnA,DISP=SHR
//  DD  DSN=dsnB,DISP=SHR
// SET  
//  DD  DSN=dsnC,DISP=SHR

The following JCL will fail.

//DD1   DD  DSN=dsnA,DISP=SHR
// SET  
//  DD  DSN=dsnB,DISP=SHR
//  DD  DSN=dsnC,DISP=SHR


The way I read it, the FIRST DD statement in a concatenation cannot have a SET 
following.  But the next one can.

So in your JCL you seem to have a concatenation of 
   //DD2DD   *
   //   DD   PATH='/dev/./null'

According to the text above, you would have to put the SET after the DD PATH or 
before the DD * but not immediately after the DD * statement. 

I would expect this to work: 
 
   // SET
   //DD2DD   *
   //   DD   PATH='/dev/./null'

I would also expect this to work: 
 
   //DD2DD   *
   //   DD   PATH='/dev/./null'
   // SET 
   //   DD   DISP=SHR,...

I would NOT expect this to work: 
 
   //DD2DD   *
   // SET
   //   DD   PATH='/dev/./null'

Though I could be wrong.  Sometimes IBM documentation is misleading.  To me the 
behavior is along the lines of this documentation.  To verify, you could change 
the DD * to a dataset and see if it still fails.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, December 22, 2015 8:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Where is SET allowed in JCL?
> 
> Sometimes within a DD concatenation; sometimes not.  For example:
> 
> 3 //STEP  EXEC  PGM=IEFBR14
>   //*
> 4 //DD1DD   *
> 5 //   DD   PATH='/dev/./null'
> 6 //  SET V1=WOMBAT
> 7 //   DD   PATH='/dev/./null'
>   //*
> 8 //DD2DD   *
> 9 //  SET V2=WOMBAT
>10 //   DD   PATH='/dev/./null'
>11 //
>  STMT NO. MESSAGE
>10 IEFC019I MISPLACED DD STATEMENT
> 
> Why does it report IEFC019I at statement 10, but not at statement 7?
> 
> I had grown accustomed to placing SET in complex concatenations, near a
> reference for clarity.  Today was the first time I tried it after DD *.
> 
> Should I submit an RCF requesting clarification or an SR for inconsistent
> behavior?
> 
> I hate JCL!
> 
> -- gil
> 

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

Re: Mainframe Capacity Planning

[Timothy Sipples]

I'm not sure why everyone (or almost everyone) has assumed Venkat asked
about *processor* capacity planning specifically. Quoting Venkat, he asked
about "mainframe hardware capacity planning and sizing." That includes
memory, storage, I/O, processors (including core counts, PCIs, and
specialty engines such as Coupling Facilities), processor features (e.g.
cryptography), accelerators (e.g. the IBM DB2 Analytics Accelerator),
machine and LPAR counts, and even perhaps data center-related factors such
as space, power, cooling considerations,cabling, and floor loading --
planning and sizing the cooling requirements for mainframe hardware
installations, for example. And I might only be scratching the surface.

Venkat, you've asked an *extremely* general question here -- broader than
even most respondents have assumed. What part or parts of these fairly
gigantic topics are you most interested in? What are your goals? Please
give us a few clues, at least. You've asked a question in this forum that
would be roughly similar to asking "How does life work?" in a biology
forum. :-)


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: ASG ZEKE Responding to program generated messages

[Clark, David]

Zeke can respond to WTOR messages from a job that Zeke submits.   I don't
believe it can monitor console for non-zeke job messages.

David Clark

Brown University
3 Davol Sq  Suite B 250
Providence,  RI  02912-1885

Phone (401) 863-7555
 Fax (401) 863-7329

On Tue, Dec 22, 2015 at 12:57 PM, Carl Edwards <
00df3759e3e7-dmarc-requ...@listserv.ua.edu> wrote:

> I have a client that is considering installing ZEKE. Said client has a
> fair amount of console diakaig that needs to be automated. The questions is
> Can ZEKE recognize console messages generated via a program(DISPLAY UPON
> CONSOLE) and respond to such?
>
>
> --
> 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: SRB And Enclave SRB

[Tom Marchant]

On Tue, 22 Dec 2015 20:38:10 +, Klein, Kenneth E wrote:

>We just enabled zPSaver Suite on an LPAR on a z12 z/os 2.1 as a 
>POC. We're getting 72.1 percent offloaded to zIIP on that LPAR. 
>There's a little savings in IEBGENER, too, but too little to matter.
>
>What I can't figure out is where the CPU time went, because I did 
>NOT see the 72.1 percent show up in the zIIP column. I know the 
>specialty engines are not hamstrung like the 2827-H43-407 general 
>purpose engines, but it looks the 1 zIIP on the CEC is 4 times faster! 
>Can that be true? Any form of reality check would be welcome here.

Yes, it can. Look at the LSPR data at 
https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprindex

There you will see, for example, that a 2827-401 (uniprocessor) is 30 MSU, 
while a 2827-701 is 1514 MSU.

-- 
Tom Marchant

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

Re: ASG ZEKE Responding to program generated messages

[Brian Westerman]

Zeke doesn't monitor the console or syslog for messages to respond to, but our 
SyzMPF/z product is built just for that.  It does what IBM's and CA's product 
does at about 1/10th the cost.  Also, SyzMPF/z (when used with SyzMail/z) will 
automatically send email (at job or stc end, or anytime in between) with the 
highest condition codes, and all step codes and processing information, (as 
well as the tasks JES output if you want), without any JCL changes to any job.  
The output can be sent as email or SMS (text) messages.

Sorry for the "marketing type" email but we just surpassed our 300th client 
this month and I wanted to brag a little.  http://www.syzygyinc.com/SyzMAILz.htm

Brian

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