Re: Coupling Facility Structure Re-sizing

[Martin Packer]

Skip, I'd share your scepticism about 100+ km apart. I don't know of 
anybody doing anything remotely stressful in CF terms over that distance.

All my customers who are doing e.g. Data Sharing over distance plan and 
measure extremely carefully - and they're doing it over a very few tens of 
km.

I've heard of something called something like a "fibre suitcase" for 
measuring in test.

Could someone who has such a thing tell me its proper name and a little 
more about it? Thanks!

I've actually blogged extensively about the RMF 74-4 latency number 
(relatively new) - which I think is useful in checking distance and 
hinting at routing. While not wanting to advertise the posts I think this 
latency number is one people should check occasionally.

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:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 23:59
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



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:

Re: ASG ZEKE Responding to program generated messages

[Elardus Engelbrecht]

Brian Westerman wrote:

>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

Congratulations! This is a great achievement! Now hurry up to 300 millionth 
client, so you can buy yourself a luxury yacht...

 ;-D

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

[Vernooij, CP (ITOPT1) - KLM]

The 'fiber-suitecase' is nothing more than a cable reel with 10 or 20 km of 
fiber. You plug this in your fiber configuration and start measurements for the 
what-if situation you are interested in.

Kees.

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

Skip, I'd share your scepticism about 100+ km apart. I don't know of 
anybody doing anything remotely stressful in CF terms over that distance.

All my customers who are doing e.g. Data Sharing over distance plan and 
measure extremely carefully - and they're doing it over a very few tens of 
km.

I've heard of something called something like a "fibre suitcase" for 
measuring in test.

Could someone who has such a thing tell me its proper name and a little 
more about it? Thanks!

I've actually blogged extensively about the RMF 74-4 latency number 
(relatively new) - which I think is useful in checking distance and 
hinting at routing. While not wanting to advertise the posts I think this 
latency number is one people should check occasionally.

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:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 23:59
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



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 withou

Re: Coupling Facility Structure Re-sizing

[Martin Packer]

And did I get the right name, Kees?

And I also hear of a reflectometer for measuring signalling latency - to 
independently confirm what the Infiniband / ICA-SR cards are saying. 
"Every home should have one." :-)

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:   23/12/2015 08:33
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



The 'fiber-suitecase' is nothing more than a cable reel with 10 or 20 km 
of fiber. You plug this in your fiber configuration and start measurements 
for the what-if situation you are interested in.

Kees.

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

Skip, I'd share your scepticism about 100+ km apart. I don't know of 
anybody doing anything remotely stressful in CF terms over that distance.

All my customers who are doing e.g. Data Sharing over distance plan and 
measure extremely carefully - and they're doing it over a very few tens of 

km.

I've heard of something called something like a "fibre suitcase" for 
measuring in test.

Could someone who has such a thing tell me its proper name and a little 
more about it? Thanks!

I've actually blogged extensively about the RMF 74-4 latency number 
(relatively new) - which I think is useful in checking distance and 
hinting at routing. While not wanting to advertise the posts I think this 
latency number is one people should check occasionally.

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:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 23:59
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



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

Re: Coupling Facility Structure Re-sizing

[Elardus Engelbrecht]

Martin Packer wrote:

>And I also hear of a reflectometer for measuring signalling latency - to 
>independently confirm what the Infiniband / ICA-SR cards are saying.

Or this thing? https://en.wikipedia.org/wiki/Optical_time-domain_reflectometer

PS: of course I never handled it or observed someone handling those toys.

>"Every home should have one." :-)

Including fridges of course. ;-D

Your favourite drinks must have a nice cold and dark place to hide from thirsty 
people... ;-D

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

[Vernooij, CP (ITOPT1) - KLM]

I don't think the cable reel has a fancy name. It just delivers you distance.

Besides that, there are devices that measure the quality of the cable 
connection, like number and distance of welds and their delays, attenuation in 
the fiber etc. etc. DWDM devices seem to be able to do so too. 

Still don't have a name, nor have I seen one. I know we used them.

Kees.


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

And did I get the right name, Kees?

And I also hear of a reflectometer for measuring signalling latency - to 
independently confirm what the Infiniband / ICA-SR cards are saying. 
"Every home should have one." :-)

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:   23/12/2015 08:33
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



The 'fiber-suitecase' is nothing more than a cable reel with 10 or 20 km 
of fiber. You plug this in your fiber configuration and start measurements 
for the what-if situation you are interested in.

Kees.

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

Skip, I'd share your scepticism about 100+ km apart. I don't know of 
anybody doing anything remotely stressful in CF terms over that distance.

All my customers who are doing e.g. Data Sharing over distance plan and 
measure extremely carefully - and they're doing it over a very few tens of 

km.

I've heard of something called something like a "fibre suitcase" for 
measuring in test.

Could someone who has such a thing tell me its proper name and a little 
more about it? Thanks!

I've actually blogged extensively about the RMF 74-4 latency number 
(relatively new) - which I think is useful in checking distance and 
hinting at routing. While not wanting to advertise the posts I think this 
latency number is one people should check occasionally.

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:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 23:59
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



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

Re: Coupling Facility Structure Re-sizing

[Vernooij, CP (ITOPT1) - KLM]

Of course the cable reel provides you with xx km of ideal fiber. The real world 
fiber will have welds, attenuation etc. as mentioned below and therefor more 
delay.

Kees.

-Original Message-
From: Vernooij, CP (ITOPT1) - KLM 
Sent: 23 December, 2015 11:17
To: IBM Mainframe Discussion List
Subject: RE: Coupling Facility Structure Re-sizing

I don't think the cable reel has a fancy name. It just delivers you distance.

Besides that, there are devices that measure the quality of the cable 
connection, like number and distance of welds and their delays, attenuation in 
the fiber etc. etc. DWDM devices seem to be able to do so too. 

Still don't have a name, nor have I seen one. I know we used them.

Kees.


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

And did I get the right name, Kees?

And I also hear of a reflectometer for measuring signalling latency - to 
independently confirm what the Infiniband / ICA-SR cards are saying. 
"Every home should have one." :-)

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:   23/12/2015 08:33
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



The 'fiber-suitecase' is nothing more than a cable reel with 10 or 20 km 
of fiber. You plug this in your fiber configuration and start measurements 
for the what-if situation you are interested in.

Kees.

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

Skip, I'd share your scepticism about 100+ km apart. I don't know of 
anybody doing anything remotely stressful in CF terms over that distance.

All my customers who are doing e.g. Data Sharing over distance plan and 
measure extremely carefully - and they're doing it over a very few tens of 

km.

I've heard of something called something like a "fibre suitcase" for 
measuring in test.

Could someone who has such a thing tell me its proper name and a little 
more about it? Thanks!

I've actually blogged extensively about the RMF 74-4 latency number 
(relatively new) - which I think is useful in checking distance and 
hinting at routing. While not wanting to advertise the posts I think this 
latency number is one people should check occasionally.

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:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 23:59
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



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
> 

Re: IXGLOGR on RSM usage

[Andrew Metcalfe]

Do you have SMF in Logstream mode? 
If so how many logstreams are defined? Each logstream has its own 
dataspace/buffers.
There are some parameters which govern Logstream/SMF real storage requirements 
that you may need to tune.


Andrew

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: 22 December 2015 16:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IXGLOGR on RSM usage

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

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

Re: IXGLOGR on RSM usage

[Elardus Engelbrecht]

Andrew Metcalfe wrote:

>Do you have SMF in Logstream mode?  

The OP said he has SMF in Logstream in thread 'Re: S00C Slip trap for any Stc'.

He wrote: "Our SMF logstream has been defined in IXGLOGR with dasdonly. "


>If so how many logstreams are defined? Each logstream has its own 
>dataspace/buffers. There are some parameters which govern Logstream/SMF real 
>storage requirements that you may need to tune. 

Good questions. Thanks for asking.

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: Where is SET allowed in JCL?

[R.S.]

W dniu 2015-12-23 o 04:41, Paul Gilmartin pisze:

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!

Just curious: why do you need to insert SET into DD concatenation?

Regards
--
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: Where is SET allowed in JCL?

[Hardee, Chuck]

The reason is that the Converter/Interpreter is expecting data as a result of 
the "//DD2 DD *".
It found none so it is now looking for a new "starting" JCL statement.
It found one, the "// SET" statement. 
After processing the "// SET" statement it again looks for a new "starting" 
statement.
It didn't find one, at least not syntactically correct. It recognized the next 
statement "//  DD " as a DD statement, but since the previous DD had been 
terminated by the "// SET", the JCL rules call for the first DD in a 
concatenation (even a concatenation of 1 DD statement) to have a label. This DD 
does not have a label so it is assumed to be a continuation, but there is no 
logically "active" DD in effect so, you get the "misplaced DD statement" error.

Make sense?

Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, December 23, 2015 7:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is SET allowed in JCL?

W dniu 2015-12-23 o 04:41, Paul Gilmartin pisze:
> 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!
Just curious: why do you need to insert SET into DD concatenation?

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

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

[Ed Gould]

WARNING not current information**

About 15 years ago I worked for a bank that mirrored more than 100  
3390 type volumes at 1000+ mile distances.
It sort of worked most of the time but when it didn't nobody noticed  
it and things began to get interesting (politically) and I think the  
government got involved.
I left in the middle of the mess and never found out what had  
happened (mostly rumors).


Ed
On Dec 23, 2015, at 2:17 AM, Martin Packer wrote:


Skip, I'd share your scepticism about 100+ km apart. I don't know of
anybody doing anything remotely stressful in CF terms over that  
distance.


All my customers who are doing e.g. Data Sharing over distance plan  
and
measure extremely carefully - and they're doing it over a very few  
tens of

km.

I've heard of something called something like a "fibre suitcase" for
measuring in test.

Could someone who has such a thing tell me its proper name and a  
little

more about it? Thanks!

I've actually blogged extensively about the RMF 74-4 latency number
(relatively new) - which I think is useful in checking distance and
hinting at routing. While not wanting to advertise the posts I  
think this

latency number is one people should check occasionally.

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:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 23:59
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List m...@listserv.ua.edu>




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 m...@listserv.ua.edu>




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 yo

Re: ASG ZEKE Responding to program generated messages

[Chuck Arney]

ZEKE DOES monitor the console messages for a scheduled job and provides 
Automatic Reply support.  I added that facility to ZEKE myself a mere 30 years 
ago.  It was available in the first release of ZEKE for MVS and it became 
available for VSE in version 3. 

Chuck Arney
Arney Computer Systems
Web: http://zosdebug.com
Facebook: http://www.facebook.com/arneycomputer

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carl Edwards
Sent: Tuesday, December 22, 2015 11: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: PTF error clarification

[Kurt Quackenbush]

... Hasn't there been a recent enhancement so BYPASS can get RC=0?


"Recent" is relative, but yes there was a change, in SMP/E V3.5, way 
back in z/OS V1.10, 2008.  Doesn't really affect the current subject, 
but BYPASSed HOLDs will get RC=0 instead of RC=4.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.gim3000/gimusr5384.htm

BTW, I'm with Skip on this; there's nothing wrong with RC=8.

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: SNTP client on z/OS

[Ken Smith]

Here, our processor's HMC gets time from one of our routers, which gets
time from NIST (the HMC can go directly to NIST but I found firewalls were
troublesome).  The HMC then steers the processor's time.  zOS doesn't know
what's going on, I think, other than seasonal time changes. This has been a
very stable config for many years.

I've used plain language above instead of the jargon and complexity "Time
people" seem to love.  See Redbook: Server Time Protocol Implementation
Guide
http://publib-b.boulder.ibm.com/abstracts/sg247281.html?Open

Ken Smith
State of Maryland

On Tue, Dec 22, 2015 at 1:05 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2015 10:28:38 -0600, John McKown wrote:
> >
> >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).​
> >
> What about fudging CVTLSO which ought to get TIME GMT correct?  If
> Kerberos,
> etc. need to avoid UTC skew they must be CVTLSO-savvy even if they STCK.
>
> -- 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

Re: PTF error clarification

[Kurt Quackenbush]

Is a return code of 4 more appropriate for PTFs not applied because of
error hold?


This is an interesting idea, which I'm curious to hear opinions on.  If 
doing a mass APPLY (not using the SELECT operand), and PTFs are stopped 
because of a PE (ERROR HOLD), either directly or in a requisite chain 
that is stuck because of a PE, what RC should be used to identify this 
condition?  RC=8?  4?  0?  Other ideas?


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: SNTP client on z/OS

[Pommier, Rex]

Hi Ken,

Does your configuration have/use STP on the z frame in conjunction with the HMC 
to keep the time in sync?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ken Smith
Sent: Wednesday, December 23, 2015 7:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SNTP client on z/OS

Here, our processor's HMC gets time from one of our routers, which gets
time from NIST (the HMC can go directly to NIST but I found firewalls were
troublesome).  The HMC then steers the processor's time.  zOS doesn't know
what's going on, I think, other than seasonal time changes. This has been a
very stable config for many years.

I've used plain language above instead of the jargon and complexity "Time
people" seem to love.  See Redbook: Server Time Protocol Implementation
Guide
http://publib-b.boulder.ibm.com/abstracts/sg247281.html?Open

Ken Smith
State of Maryland

On Tue, Dec 22, 2015 at 1:05 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2015 10:28:38 -0600, John McKown wrote:
> >
> >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).​
> >
> What about fudging CVTLSO which ought to get TIME GMT correct?  If
> Kerberos,
> etc. need to avoid UTC skew they must be CVTLSO-savvy even if they STCK.
>
> -- 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


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: Where is SET allowed in JCL?

[Paul Gilmartin]

On 2015-12-23, at 05:44, R.S. wrote:
>> 
>> I hate JCL!
> Just curious: why do you need to insert SET into DD concatenation?
>  
No "need" just style for clarity.  I could have put all my SET
statements a hundred lines earlier, immediately after JOB.  Instead
I thought my JCL would be easiest to read if I placed each as close
as possible to the references to its value.  See modified example
below.


On 2015-12-23, at 05:55, Hardee, Chuck wrote:

> The reason is that the Converter/Interpreter is expecting data as a result of 
> the "//DD2 DD *".
> It found none so it is now looking for a new "starting" JCL statement.
> It found one, the "// SET" statement. 
> After processing the "// SET" statement it again looks for a new "starting" 
> statement.
> It didn't find one, at least not syntactically correct. It recognized the 
> next statement "//  DD " as a DD statement, but since the previous DD had 
> been terminated by the "// SET", the JCL rules call for the first DD in a 
> concatenation (even a concatenation of 1 DD statement) to have a label. This 
> DD does not have a label so it is assumed to be a continuation, but there is 
> no logically "active" DD in effect so, you get the "misplaced DD statement" 
> error.
> 
> Make sense?
>  
No.

I routinely code empty SYSIN, perhaps just to save keystrokes, as in:

//STEP  EXEC  PGM=IEBGENER
//SYSIN  DD   *  # Nothing here; works fine.
//SYSPRINT  DD  SYSOUT=(,)
...
And my rewritten example:
  //*
3 //STEP  EXEC  PGM=IEFBR14
  //*
4 //DD1DD   *   # "DD *" with no data is just fine.
5 //   DD   *
  //*
6 //  SET V1=WOMBAT
7 //   DD   PATH='/tmp/&V1'
  //*
  IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
8 //  SET V2=XYZZY
9 //   DD   PATH='/tmp/&V2'
  //*
  IEFC653I SUBSTITUTION JCL - PATH='/tmp/XYZZY'
   10 //DD2DD   *
   11 //  SET V3=WOMBAT
   12 //   DD   PATH='/tmp/&V3'
  IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
   13 //
 STMT NO. MESSAGE
   12 IEFC019I MISPLACED DD STATEMENT
 BOTTOM OF DATA **

All the assertions you make should have been equally true of the empty
instream data sets at line 4 or line 5.  Why does the C/I accept those
but reject the one at line 12?

I invite, even challenge, any IBM representative to provide a plausible
rationale for the restriction in the Reference that Lizette and I cited.
How does that rule benefit customers?  Rather, it makes the Reference
thicker, increases the learning burden on programmers, and engenders an
unpleasant Astonishment Factor.  I suspect it arose througn no purposeful
design, but through developer ineptitude and indolence.  It didn't work
as intended, so they documented it and called it a feature.

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: IEAVAPE2/IEAVPSE2 for SRB

[Peter Relson]

>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

I see no "fact" here that is correct. There is no STOKEN returned. There 
is no STOKEN on the IEAVPSE2 interface at all.

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

Besides the fact that "from address space" has no intrinsic meaning (are 
you talking about a work unit with home of "a"? are you talking about a 
work unit with current primary of "a"?), and "suspend" has nothing to do 
with IEAVAPE2 or IEAVPSE2 since the latter is "pause", as was discussed 
very recently you pause *yourself* -- the system pauses the work unit that 
issued the "pause" request. So to your question "no".

Peter Relson
z/OS Core Technology Design


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

[Ken Smith]

I'm not running SNTP on z/OS.  z/OS issues a console message when seasonal
time changes occur, but I don't know if z/OS knows when the HMC steers the
processor time.  CLOCK00 looks like this:

OPERATOR NOPROMPT  /* Prompt for time at IPL when TOD set ?  */
TIMEZONE W.05.00.00/* Local offset from GMT - 04=EDT, 05=EST */
ETRMODE  NO/* Using a Sysplex Timer ?*/
STPMODE  YES   /* Using Server Time Protocol ?   */
TIMEDELTA 10   /* Seconds from Stratum 1 Server tolerated*/
STPZONE  YES   /* Use STP to set the time zone offset?   */

On Wed, Dec 23, 2015 at 9:09 AM, Pommier, Rex 
wrote:

> Hi Ken,
>
> Does your configuration have/use STP on the z frame in conjunction with
> the HMC to keep the time in sync?
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ken Smith
> Sent: Wednesday, December 23, 2015 7:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SNTP client on z/OS
>
> Here, our processor's HMC gets time from one of our routers, which gets
> time from NIST (the HMC can go directly to NIST but I found firewalls were
> troublesome).  The HMC then steers the processor's time.  zOS doesn't know
> what's going on, I think, other than seasonal time changes. This has been a
> very stable config for many years.
>
> I've used plain language above instead of the jargon and complexity "Time
> people" seem to love.  See Redbook: Server Time Protocol Implementation
> Guide
> http://publib-b.boulder.ibm.com/abstracts/sg247281.html?Open
>
> Ken Smith
> State of Maryland
>
> On Tue, Dec 22, 2015 at 1:05 PM, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 22 Dec 2015 10:28:38 -0600, John McKown wrote:
> > >
> > >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).​
> > >
> > What about fudging CVTLSO which ought to get TIME GMT correct?  If
> > Kerberos,
> > etc. need to avoid UTC skew they must be CVTLSO-savvy even if they STCK.
> >
> > -- 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
>
>
> 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
>

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

Gil,
For the DD * statement, have you tried this?

//DD2   DD *
/*
//   SET
//  DD PATH= 

Maybe the terminator /* after a DD * might work?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, December 23, 2015 7:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Where is SET allowed in JCL?
> 
> On 2015-12-23, at 05:44, R.S. wrote:
> >>
> >> I hate JCL!
> > Just curious: why do you need to insert SET into DD concatenation?
> >
> No "need" just style for clarity.  I could have put all my SET statements a
> hundred lines earlier, immediately after JOB.  Instead I thought my JCL would
> be easiest to read if I placed each as close as possible to the references to
> its value.  See modified example below.
> 
> 
> On 2015-12-23, at 05:55, Hardee, Chuck wrote:
> 
> > The reason is that the Converter/Interpreter is expecting data as a result
> of the "//DD2 DD *".
> > It found none so it is now looking for a new "starting" JCL statement.
> > It found one, the "// SET" statement.
> > After processing the "// SET" statement it again looks for a new "starting"
> statement.
> > It didn't find one, at least not syntactically correct. It recognized the
> next statement "//  DD " as a DD statement, but since the previous DD had
> been terminated by the "// SET", the JCL rules call for the first DD in a
> concatenation (even a concatenation of 1 DD statement) to have a label. This
> DD does not have a label so it is assumed to be a continuation, but there is
> no logically "active" DD in effect so, you get the "misplaced DD statement"
> error.
> >
> > Make sense?
> >
> No.
> 
> I routinely code empty SYSIN, perhaps just to save keystrokes, as in:
> 
> //STEP  EXEC  PGM=IEBGENER
> //SYSIN  DD   *  # Nothing here; works fine.
> //SYSPRINT  DD  SYSOUT=(,)
> ...
> And my rewritten example:
>   //*
> 3 //STEP  EXEC  PGM=IEFBR14
>   //*
> 4 //DD1DD   *   # "DD *" with no data is just fine.
> 5 //   DD   *
>   //*
> 6 //  SET V1=WOMBAT
> 7 //   DD   PATH='/tmp/&V1'
>   //*
>   IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
> 8 //  SET V2=XYZZY
> 9 //   DD   PATH='/tmp/&V2'
>   //*
>   IEFC653I SUBSTITUTION JCL - PATH='/tmp/XYZZY'
>10 //DD2DD   *
>11 //  SET V3=WOMBAT
>12 //   DD   PATH='/tmp/&V3'
>   IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
>13 //
>  STMT NO. MESSAGE
>12 IEFC019I MISPLACED DD STATEMENT
>  BOTTOM OF DATA **
> 
> All the assertions you make should have been equally true of the empty
> instream data sets at line 4 or line 5.  Why does the C/I accept those but
> reject the one at line 12?
> 
> I invite, even challenge, any IBM representative to provide a plausible
> rationale for the restriction in the Reference that Lizette and I cited.
> How does that rule benefit customers?  Rather, it makes the Reference thicker,
> increases the learning burden on programmers, and engenders an unpleasant
> Astonishment Factor.  I suspect it arose througn no purposeful design, but
> through developer ineptitude and indolence.  It didn't work as intended, so
> they documented it and called it a feature.
> 
> 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

[Shmuel Metz (Seymour J.)]

In <5679d5c0.3090...@bremultibank.com.pl>, on 12/22/2015
   at 11:59 PM, "R.S."  said:

>It is kind for recipients to use "lowest common denominator"

The least common denominator is ASCII, but as long as you have the
right MIME header fields pretty much everybody can read the ISO 8859-*
pages. Whether they can read non-English words is a sepate issue.

While my e-mail client can't handle UTF-8, it's clearly the direction
things are going.
 
-- 
 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 10:55 PM, Clark Morris  said:

>Are there holds that should be bypassed 

Yes.

>such as Action after noting the action

And doc hold after reading the documentation

There are some that I automatically bypass, e.g., CLPA: I don't apply
servie to a live system and these days most shops do CLPA on every
IPL. 

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

[Lizette Koehler]

Kurt,

For a HOLD ERROR that prevents other PTFs going on, I am good with an RC04.  An
RC08 or higher, to me means that there is something terribly wrong with the
SMP/E Process.  So I would probably Panic.  However, I always review an RC04 and
higher and look at the CAUSER Report to see what might be the issue.  

To me a HOLD ERROR with RC04 would be a reasonable expectation.  It would just
mean that something could not go on.  For a condition code higher than 4 would
mean a severe error occurred (space, corrupted PTF, etc...) and needs to be
checked.  I do not see a need for a hold error to fall in that category.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Kurt Quackenbush
> Sent: Wednesday, December 23, 2015 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PTF error clarification
> 
> > Is a return code of 4 more appropriate for PTFs not applied because of
> > error hold?
> 
> This is an interesting idea, which I'm curious to hear opinions on.  If doing
> a mass APPLY (not using the SELECT operand), and PTFs are stopped because of a
> PE (ERROR HOLD), either directly or in a requisite chain that is stuck because
> of a PE, what RC should be used to identify this condition?  RC=8?  4?  0?
> Other ideas?
> 
> Kurt Quackenbush -- IBM, SMP/E Development
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Where is SET allowed in JCL?

[Paul Gilmartin]

On Wed, 23 Dec 2015 07:41:15 -0700, Lizette Koehler wrote:

>Gil,
>For the DD * statement, have you tried this?
>
>//DD2   DD *
>/*
>//   SET
>//  DD PATH= 
>
>Maybe the terminator /* after a DD * might work?
> 
It makes no difference.

>> On 2015-12-23, at 05:44, R.S. wrote:
>> >>
>> >> I hate JCL!
>> > Just curious: why do you need to insert SET into DD concatenation?
>> >
Reversing the rhetoric, why does IBM need to prohibit SET between the
first and second DD statements in a concatenation while it's allowed
between any two others?

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: Where is SET allowed in JCL?

[Shmuel Metz (Seymour J.)]

In <5763936936315627.wa.paulgboulderaim@listserv.ua.edu>, on
12/22/2015
   at 09:59 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>YTF!? 

ITYM "WTF?".

>Does anyone believe it was specified that way,

C2H5OH.

I coined the term Broken As Desiged (BAD); ISAGN for "Broken As
Stochastically Designed (BASD)". Historically, IBM has done a very bad
job on orthogonality.

I'd recommend an SR followed by an ER, if you can make a business
case.
 
-- 
 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?

[Vernooij, CP (ITOPT1) - KLM]

There are many "why doesn't IBM" cases (why don't they uppercase my JCL when I 
forgot to do so?
I guess it was tons of work more to make this enhancement 10 years ago in 60 
year old code, than to document not to do so.

At least it is well documented, what you cannot say of other 
software/platforms: "something went wrong".

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 23 December, 2015 16:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is SET allowed in JCL?

On Wed, 23 Dec 2015 07:41:15 -0700, Lizette Koehler wrote:

>Gil,
>For the DD * statement, have you tried this?
>
>//DD2   DD *
>/*
>//   SET
>//  DD PATH= 
>
>Maybe the terminator /* after a DD * might work?
> 
It makes no difference.

>> On 2015-12-23, at 05:44, R.S. wrote:
>> >>
>> >> I hate JCL!
>> > Just curious: why do you need to insert SET into DD concatenation?
>> >
Reversing the rhetoric, why does IBM need to prohibit SET between the
first and second DD statements in a concatenation while it's allowed
between any two others?

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

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

[Shmuel Metz (Seymour J.)]

In , on 12/22/2015
   at 11:54 PM, "Robert A. Rosenberg"  said:

>On a Mac it is Option-m.

On a PC there are multiple keyboard layouts. On OS/2 with the US
International layout, Right-Alt-M gets µ. Depending on the layout R.S.
is using, it may or may not be easy. I wouldn't consider Alt-ddd to be
easy.
 
-- 
 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?

[Jakubek, Jan]

>>>
Just curious: why do you need to insert SET into DD concatenation?

Regards
Radoslaw Skorupka
Lodz, Poland
>>>

To override a value of a symbol from this point on?

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

This a pointless driftaway from the case (besides the fact that the case was 
actually CF structure sizes). 
I was not asking for all the possibilities on all possible platforms, I was 
trying to ensure that it was readable and understandable on each platform that 
the message could appear on. The most simple characters make the most chance 
then. Unless someone can assure me that there is a form of mu will always be 
displayed correctly on every platform.
Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: 23 December, 2015 16:16
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [Bulk] Re: Coupling Facility Structure Re-sizing

In , on 12/22/2015
   at 11:54 PM, "Robert A. Rosenberg"  said:

>On a Mac it is Option-m.

On a PC there are multiple keyboard layouts. On OS/2 with the US
International layout, Right-Alt-M gets µ. Depending on the layout R.S.
is using, it may or may not be easy. I wouldn't consider Alt-ddd to be
easy.
 
-- 
 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 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: PTF error clarification

[Clifford McNeill]

PE Error  RC8


From: IBM Mainframe Discussion List  on behalf of 
Kurt Quackenbush 
Sent: Wednesday, December 23, 2015 7:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PTF error clarification

> Is a return code of 4 more appropriate for PTFs not applied because of
> error hold?

This is an interesting idea, which I'm curious to hear opinions on.  If
doing a mass APPLY (not using the SELECT operand), and PTFs are stopped
because of a PE (ERROR HOLD), either directly or in a requisite chain
that is stuck because of a PE, what RC should be used to identify this
condition?  RC=8?  4?  0?  Other ideas?

Kurt Quackenbush -- IBM, SMP/E Development

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

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

Re: Where is SET allowed in JCL?

[Robinson, Dave (GE Capital NonGE)]

As a slight aside, lower case JCL is flagged up with the HILITE function in 
v2.1 onwards.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: 23 December 2015 15:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is SET allowed in JCL?

There are many "why doesn't IBM" cases (why don't they uppercase my JCL when I 
forgot to do so?

I guess it was tons of work more to make this enhancement 10 years ago in 60 
year old code, than to document not to do so.



At least it is well documented, what you cannot say of other 
software/platforms: "something went wrong".



Kees.



-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin

Sent: 23 December, 2015 16:00

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Where is SET allowed in JCL?



On Wed, 23 Dec 2015 07:41:15 -0700, Lizette Koehler wrote:



>Gil,

>For the DD * statement, have you tried this?

>

>//DD2   DD *

>/*

>//   SET

>//  DD PATH= 

>

>Maybe the terminator /* after a DD * might work?

> 

It makes no difference.



>> On 2015-12-23, at 05:44, R.S. wrote:

>> >>

>> >> I hate JCL!

>> > Just curious: why do you need to insert SET into DD concatenation?

>> >

Reversing the rhetoric, why does IBM need to prohibit SET between the

first and second DD statements in a concatenation while it's allowed

between any two others?



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


For information, services and offers, please visit our web site: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.klm.com&d=CwIGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=e3tYBLyxxv2bm6qKB_Bu6i8laFMVOfQGTujvsDqIvKU&m=AuKYph8T7s38Yg7z3GAlbn9Q0s4Cn27Yn2PdyE88fbY&s=69uXSa1kmLLI6yCIEd1Yg8G5mc_Tu5JQhupRJbWm-pI&e=
 . This e-mail and any attachment may contain confidential and privileged 
material intended for the addressee only. If you are not the addressee, you are 
notified that no part of the e-mail or any attachment may be disclosed, copied 
or distributed, and that any other action related to this e-mail or attachment 
is strictly prohibited, and may be unlawful. If you have received this e-mail 
by error, please notify the sender immediately by return e-mail, and delete 
this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286






--

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

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: Where is SET allowed in JCL?

[Stevet]

I hate, eschew, despise, software that is so poorly documented that I have to 
hack at it for hours or days to finally figure out, it's broken.   

And then, I have to battle some bug reporting system to report the bug, and 
then it is 2 or more years before it gets fixed (assuming it gets fixed). 

How many examples would you like from Linux distributions?

How about FF?

We won't touch Winderz. 

So get a grip. JCL is documented. And if you find its doc is in error, report 
it and it gets  fixed. 

Since I am allergic to milk, I really can't offer you some cheese to go with 
your whine. 

Sent from iPhone - small keyboard fat fingers - expect spellinf errots.

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

[Shmuel Metz (Seymour J.)]

In , on 12/22/2015
   at 11:59 PM, "Robert A. Rosenberg"  said:

>Via Email just go UTF-8. The same for Web Pages or just use the 
>Unicode codepoint (µ) or µ.

Using µ for µ is appropriate for web pages, but not for text in
e-mail. HTML in e-mail is the sin for which there is no forgiveness,
althogh multipart/alternative with a proper text/plain subpart is
okay.
 
-- 
 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

[Clark Morris]

On 23 Dec 2015 05:50:44 -0800, in bit.listserv.ibm-main you wrote:

>> Is a return code of 4 more appropriate for PTFs not applied because of
>> error hold?
>
>This is an interesting idea, which I'm curious to hear opinions on.  If 
>doing a mass APPLY (not using the SELECT operand), and PTFs are stopped 
>because of a PE (ERROR HOLD), either directly or in a requisite chain 
>that is stuck because of a PE, what RC should be used to identify this 
>condition?  RC=8?  4?  0?  Other ideas?

I believe that return code 4 is supposed to mean warning,  8
significant error, 12 - severe error didn't work, 12 an even more
severe error and 16 critical error.  Thus PTFs not being applied
because of error holds should not raise a significant error flag.
Looking at the other HOLD types, I can see where a return code of 8
would be appropriate for many of them.  I assume the CAUSER report
which came after when I was doing SMP work will or can group the holds
by type for ease of review.

Clark Morris
>
>Kurt Quackenbush -- IBM, SMP/E Development
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Coupling Facility Structure Re-sizing

[Mike Schwab]

On Tue, Dec 22, 2015 at 5:58 PM, Skip Robinson  wrote:
> 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

One wrong swipe from a backhoe could have a cross - campus / city /
state / country / continent sysplex down for a day or two.  A phone
company building fire could be a month or more.

(1988 Hinsdale, IL fire).
http://articles.chicagotribune.com/1989-03-11/news/8903250918_1_state-fire-marshal-alarm-electrical-power

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: PTF error clarification

[Richards, Robert B.]

Kurt,

As long as it is non-zero, I do not particularly care except for the legacy 
understanding of what the various codes normally mean. 

I do tend to recognize a RC=8 as something more critical to investigate, but as 
a practical matter, I review anything non-zero.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Wednesday, December 23, 2015 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PTF error clarification

> Is a return code of 4 more appropriate for PTFs not applied because of 
> error hold?

This is an interesting idea, which I'm curious to hear opinions on.  If doing a 
mass APPLY (not using the SELECT operand), and PTFs are stopped because of a PE 
(ERROR HOLD), either directly or in a requisite chain that is stuck because of 
a PE, what RC should be used to identify this condition?  RC=8?  4?  0?  Other 
ideas?

Kurt Quackenbush -- IBM, SMP/E Development

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

Datacom Programming Guide PDF?

[Jon Butler]

Does anyone have a CA Datacom Programming Guide in PDF format they could share 
with me?

This seems to be one of the few restricted manuals on the CA site.

TIA,

Jon.

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

Is there a source for detailed, instruction-level performance info?

[Jerry Callen]

I'm in the process of hand-tuning a small, performance critical algorithm on a 
Z13, and I'm hampered by the lack of detailed information on the 
instruction-level performance of the machine. Back in the day, IBM used to 
publish a "Functional Characteristics" manual for each CPU model that provided 
this information; those seem to have been discontinued. I'm looking for things 
like:

* Is register renaming used for GPRs and/or FPRs? (affects the need for loop 
unrolling)
* Are there any ways to bypass the L1 cache on moves of less than a page, when 
simply moving data without looking at it?
* Does LMG/STMG outperform a linear sequence of LG/STG? Under what 
circumstances?

At the very least, compiler maintainers need this information to select the 
right instruction sequences for each model. Does anyone know of a source for 
this information, other than writing test kernels and trying things out? I 
already have the SHARE presentations by David Bond and Bob Rogers, which 
contain some of this information, but it's not enough.

I was really excited by the addition of vector registers on the Z13 (yippee, an 
additional 512 bytes of high speed scratch storage!), but the load/store 
performance hasn't turned out to be what I had hoped for. I may well be using 
the facility "the wrong way"; having detailed implementation information would 
sure help.


-- Jerry Callen
   Rocket Software

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

[Richard Pinion]

To make everybody happy, make this a user controlled option, you decide
what causes RC=xx.



--- robert.richa...@opm.gov wrote:

From: "Richards, Robert B." 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PTF error clarification
Date: Wed, 23 Dec 2015 10:44:24 -0500

Kurt,

As long as it is non-zero, I do not particularly care except for the legacy 
understanding of what the various codes normally mean. 

I do tend to recognize a RC=8 as something more critical to investigate, but as 
a practical matter, I review anything non-zero.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Wednesday, December 23, 2015 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PTF error clarification

> Is a return code of 4 more appropriate for PTFs not applied because of 
> error hold?

This is an interesting idea, which I'm curious to hear opinions on.  If doing a 
mass APPLY (not using the SELECT operand), and PTFs are stopped because of a PE 
(ERROR HOLD), either directly or in a requisite chain that is stuck because of 
a PE, what RC should be used to identify this condition?  RC=8?  4?  0?  Other 
ideas?

Kurt Quackenbush -- IBM, SMP/E Development

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




_
Netscape.  Just the Net You Need.

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

[Jakubek, Jan]

<<<

> Is a return code of 4 more appropriate for PTFs not applied because of 
> error hold?

This is an interesting idea, which I'm curious to hear opinions on.  If doing a 
mass APPLY (not using the SELECT operand), and PTFs are stopped because of a PE 
(ERROR HOLD), either directly or in a requisite chain that is stuck because of 
a PE, what RC should be used to identify this condition?  RC=8?  4?  0?  Other 
ideas?

Kurt Quackenbush -- IBM, SMP/E Development


My personal preference:

PTF not applied RC=8 (unchanged)

HOLDSYSTEM:
RC=4 for the following IDs: MULTSYS, IOGEN, FULLGEN, EXRF, EXIT, EC, DEP, 
DDDEF, DB2BIND, ACTION, DOWNLD, DELETE.

I normally review the above IDs. RC=0 for other HOLDSYS IDs.

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

Re: Datacom Programming Guide PDF?

[Jon Butler]

Santa came early !!!

Thanks to the person (nameless unless he wants to publish) for sending me the 
Guide.

Happy Christmas to all.

Jon.

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

[Mike Schwab]

On Wed, Dec 23, 2015 at 9:41 AM, Clark Morris  wrote:
> On 23 Dec 2015 05:50:44 -0800, in bit.listserv.ibm-main you wrote:
>
>>This is an interesting idea, which I'm curious to hear opinions on.  If
>>doing a mass APPLY (not using the SELECT operand), and PTFs are stopped
>>because of a PE (ERROR HOLD), either directly or in a requisite chain
>>that is stuck because of a PE, what RC should be used to identify this
>>condition?  RC=8?  4?  0?  Other ideas?
>
> I believe that return code 4 is supposed to mean warning,  8
> significant error, 12 - severe error didn't work, 12 an even more
> severe error and 16 critical error.  Thus PTFs not being applied
> because of error holds should not raise a significant error flag.
> Looking at the other HOLD types, I can see where a return code of 8
> would be appropriate for many of them.  I assume the CAUSER report
> which came after when I was doing SMP work will or can group the holds
> by type for ease of review.
>
> Clark Morris
>>
>>Kurt Quackenbush -- IBM, SMP/E Development

I agree with list of the normal return codes.  But here, we need to
decide if we need to do additional work to install a PTF or wait for
it to be fixed.

A return code of 4 might not be investigated, so that would be my
choice for something that should not be installed (as of the last
retrieve).

A return code of 8 should be investigated, so a PTF that is OK to
install (as of the last retrieve) but needs work other than installing
should have this return code.

A return code of 0 is good for any PTF that can be installed (as of
the last retrieve) and does not need any additional work.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

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

[Shmuel Metz (Seymour J.)]

In
<874b151289704e46a874bf2ae6fdd8d1310d6...@kl126r4b.cs.ad.klmcorp.net>,
on 12/23/2015
   at 03:18 PM, "Vernooij, CP (ITOPT1) - KLM" 
said:

>I was not asking for all the possibilities on all possible platforms,
>I was trying to ensure that it was readable and understandable on
>each platform that the message could appear on.

What current platform won't display µ (µ) if the MIME header
fields are correct and the charset is one of the ISO-8859 character
sets? How many currently supported platforms can't handle
charset=UTF8?
 
-- 
 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: Is there a source for detailed, instruction-level performance info?

[Jerry Callen]

BTW - I applaud IBM's provision of the non-privileged ECAG instruction for 
obtaining cache characteristics. Here's the output of a little program I wrote 
to format the information it provides (on a Z13):

level 0: private
  data: line size=256, set associativity=8, total size=128K
  instruction: line size=256, set associativity=6, total size=96K

level 1: private
  data: line size=256, set associativity=8, total size=2048K
  instruction: line size=256, set associativity=8, total size=2048K

level 2: shared
  unified: line size=256, set associativity=16, total size=65536K

level 3: shared
  unified: line size=256, set associativity=30, total size=491520K

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

[Chris Hoelscher]

I guess I have a basic question - is a return code intended to indicate that 
success of a process doing what it is supposed to do? Or the meaningfulness of 
the results of the process to the person who makes uses of the results of the 
process?

If the former - then should EVERY run of APPLY return a RC=0 unless there is 
malformed input where SMP/e could NOT do what it is supposed to do (on the 
assumption of well-formed input)

If the latter - then are return codes ever meaningful - every result set should 
be reviewed with equal diligence without regard to the RC (smp/e can't guess 
what is acceptable or meaningful to YOU)

If seems that in either case - the RC is not as important as the results; does 
a RC-9 mean that SMP/E did what YOU wanted it to? Or just that the process 
ended without what SMP/E considers to be problems ...

 
Back to my hole 

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538
ctions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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

[Pinnacle]

On 12/23/2015 8:50 AM, Kurt Quackenbush wrote:

Is a return code of 4 more appropriate for PTFs not applied because of
error hold?


This is an interesting idea, which I'm curious to hear opinions on.  If
doing a mass APPLY (not using the SELECT operand), and PTFs are stopped
because of a PE (ERROR HOLD), either directly or in a requisite chain
that is stuck because of a PE, what RC should be used to identify this
condition?  RC=8?  4?  0?  Other ideas?

Kurt Quackenbush -- IBM, SMP/E Development



Kurt,

I'm OK with the 08.

Regards,
Tom Conley

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

[Chris Hoelscher]

does a RC-9 mean that SMP/E did what YOU wanted it to? Or just that the process 
ended without what SMP/E considers to be problems ...


should have said

does a RC=0 mean that SMP/E did what YOU wanted it to? Or just that the process 
ended without what SMP/E considers to be problems ...


Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Wednesday, December 23, 2015 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] PTF error clarification

I guess I have a basic question - is a return code intended to indicate that 
success of a process doing what it is supposed to do? Or the meaningfulness of 
the results of the process to the person who makes uses of the results of the 
process?

If the former - then should EVERY run of APPLY return a RC=0 unless there is 
malformed input where SMP/e could NOT do what it is supposed to do (on the 
assumption of well-formed input)

If the latter - then are return codes ever meaningful - every result set should 
be reviewed with equal diligence without regard to the RC (smp/e can't guess 
what is acceptable or meaningful to YOU)

If seems that in either case - the RC is not as important as the results; does 
a RC-9 mean that SMP/E did what YOU wanted it to? Or just that the process 
ended without what SMP/E considers to be problems ...

 
Back to my hole 

Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology Solution 
Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538
ctions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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

Re: Is there a source for detailed, instruction-level performance info?

[Shmuel Metz (Seymour J.)]

In <8970116796168447.wa.jcallennarsil@listserv.ua.edu>, on
12/23/2015
   at 09:46 AM, Jerry Callen  said:

>I'm in the process of hand-tuning a small, performance critical
>algorithm on a Z13,

Lather, rinse, repeat every time you change processors. 

>and I'm hampered by the lack of detailed
>information on the instruction-level performance of the machine.

Be careful what you ask for; you might get it.

>Back in the day, IBM used to publish a "Functional Characteristics" 
>manual for each CPU model that provided this information;

Except when it was in a separate timing manual.

Every time that IBM introduced a new processor the timing formulæ
became more  complicated. I suspect that a timing manual for the z13
would be massive.
 
-- 
 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?

[Tom Marchant]

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

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

No, it wasn't. I looked in a JCL reference for MVS/ESA V5 and found simply:


25.6 Location in the JCL 
 
  A SET statement can appear anywhere in the job after the JOB statement.
 
  Place a SET statement in the job's JCL before the intended use of the
  symbolic parameter.


-- 
Tom Marchant

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

[Staller, Allan]

I hate JCL!


You're working in z/OS... Deal with it! 

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: IEAVAPE2/IEAVPSE2 for SRB

[michelbutz]

So when that unit of work is paused 
The NSI after the BASR to IEAVPSE2 is not executed till after the release 
correct ?

Thanks 

Sent from my iPhone

On Dec 23, 2015, at 9:26 AM, Peter Relson  wrote:

>> 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
> 
> I see no "fact" here that is correct. There is no STOKEN returned. There 
> is no STOKEN on the IEAVPSE2 interface at all.
> 
>> 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"
> 
> Besides the fact that "from address space" has no intrinsic meaning (are 
> you talking about a work unit with home of "a"? are you talking about a 
> work unit with current primary of "a"?), and "suspend" has nothing to do 
> with IEAVAPE2 or IEAVPSE2 since the latter is "pause", as was discussed 
> very recently you pause *yourself* -- the system pauses the work unit that 
> issued the "pause" request. So to your question "no".
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> 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: Where is SET allowed in JCL?

[R.S.]

W dniu 2015-12-23 o 16:00, Paul Gilmartin pisze:



Just curious: why do you need to insert SET into DD concatenation?


Reversing the rhetoric, why does IBM need to prohibit SET between the
first and second DD statements in a concatenation while it's allowed
between any two others?

You are right, but this is adressed to IBM, not me ;-)
I would be happy to many JCL enhancements, but IBM decide.
From the other hand - I teach JCL, I have my own polish course manual 
for that (BTW: It's probably the most pirated mainframe-related 
material/manual in Poland :-) ), so I don't have to update it to much, 
since the changes are not revolutionary :-)))



I hate JCL!

:-)))
This is typical when someone tries to do something NOT intented for JCL. 
JCL is NOT shell script, it is NOT programming language, shouldn't be 
compared to CLIST, REXX, bash, etc.

Of course you are aware of that .

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

[Tom Marchant]

On Wed, 23 Dec 2015 15:54:52 +, Jakubek, Jan > Is a return code of 4 more appropriate for PTFs not applied because of 
>> error hold?
>
>This is an interesting idea, which I'm curious to hear opinions on.  If doing 
>a mass APPLY (not using the SELECT operand), and PTFs are stopped because of a 
>PE (ERROR HOLD), either directly or in a requisite chain that is stuck because 
>of a PE, what RC should be used to identify this condition?  RC=8?  4?  0?  
>Other ideas?
>
>Kurt Quackenbush -- IBM, SMP/E Development
>
>
>My personal preference:
>
>PTF not applied RC=8 (unchanged)
>
>HOLDSYSTEM:
>RC=4 for the following IDs: MULTSYS, IOGEN, FULLGEN, EXRF, EXIT, EC, DEP, 
>DDDEF, DB2BIND, ACTION, DOWNLD, DELETE.

I'm sure we'll get lots of disagreement.

My preference, if anything were to change, is just the opposite. RC=8 for 
system holds that have not been bypassed. My reasoning is that the 
sysprog should review the system holds and bypass them. Otherwise, 
important maintenance may never be applied. RC=4 if they have been 
bypassed. I'm not sure how I'd like to see the return code set if system 
holds were bypassed selectively.

RC=4 for PTFs that didn't apply because of an unresolved error hold, at least 
on a mass apply. RC=8 probably makes more sense for an APPLY SELECT if a 
selected PTF didn't apply because of an error hold.

-- 
Tom Marchant

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

[R.S.]

W dniu 2015-12-23 o 10:42, Martin Packer pisze:

And did I get the right name, Kees?


It's just "distance in the suitcase". :-)
It is NOT an electronic device, it is PURE FIBRE OPTIC CABLE.
Of course you can stack several suitcases to get desired distance.
Note - welding or connectors can be substituted with additional distance.
Note2 - quality of FO cable should not be checked during PoC tests. 
Reason: during PoC we analyze delays, cable quality should be just OK. 
If it's not, the problem is in quite diffrerent layer - whether the link 
is reliable.


BTW: there are electronic devices for copper lines, you can set delay 
using some knob. AFAIR other parameters like signal attenuation are also 
customisable.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc 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
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.840.228 zotych.


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

IODF Catalog

[Mainframe Mainframe]

Hello ,
Hope you are doing good. we have system in sysplex and
for different versionz/OS system in sysplex we have different master
catalog.
 Now i created IODF from one z/OS system and its catalog under this system
master catalog. But to access this same IODF from different system, I want
to catalog this IODF on other system master catalog as well.

So, I am using below JCL

//RECAT   JOB (654),'MAINFRAME',CLASS=A,
//   MSGCLASS=A,NOTIFY=&SYSUID
//S1  EXEC  PGM=IDCAMS
//SYSPRINT  DD  SYSOUT=*
//SYSINDD  *
  DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
VOLUME(PTF001) -
 RECATALOG   -
)   CAT(ZOS13.MASTER.CATALOG)
/*

and output is as below

IDCAMS  SYSTEM SERVICES   TIME:
09:31:59

  DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
VOLUME(PTF001) -
 RECATALOG   -
)   CAT(ZOS13.MASTER.CATALOG)
IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 86 - REASON CODE IS IGG0CLEY-6
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12


I checked for this IDC3009I code in manual, but not much information I
could  find to solve this .

Any suggestion will help me .

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

Re: IODF Catalog

[Craig Pace]

You still need to have your DATA statement.

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mainframe Mainframe
Sent: Wednesday, December 23, 2015 11:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IODF Catalog

Hello ,
Hope you are doing good. we have system in sysplex and
for different versionz/OS system in sysplex we have different master
catalog.
 Now i created IODF from one z/OS system and its catalog under this system 
master catalog. But to access this same IODF from different system, I want to 
catalog this IODF on other system master catalog as well.

So, I am using below JCL

//RECAT   JOB (654),'MAINFRAME',CLASS=A,
//   MSGCLASS=A,NOTIFY=&SYSUID
//S1  EXEC  PGM=IDCAMS
//SYSPRINT  DD  SYSOUT=*
//SYSINDD  *
  DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
VOLUME(PTF001) -
 RECATALOG   -
)   CAT(ZOS13.MASTER.CATALOG)
/*

and output is as below

IDCAMS  SYSTEM SERVICES   TIME:
09:31:59

  DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
VOLUME(PTF001) -
 RECATALOG   -
)   CAT(ZOS13.MASTER.CATALOG)
IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 86 - REASON CODE IS IGG0CLEY-6 IDC3003I 
FUNCTION TERMINATED. CONDITION CODE IS 12

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12


I checked for this IDC3009I code in manual, but not much information I could  
find to solve this .

Any suggestion will help me .

--
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: PTF error clarification

[Pommier, Rex]

Chris,

I was having similar thoughts as you, although not to the extent of yours.  I 
tend to think along the first of your ideas about the purpose of the RC, that 
being to indicate the success of the process doing what it is supposed to do.  
But I would disagree with your idea of everything being RC=0.  In my mind, if 
SMP/E decides a PTF shouldn't go on because of a hold (whether error hold or 
other reason like ACTION), it shouldn't throw a RC=8, because that is SMP/E 
doing what it should.  However, if a utility fails, then SMP/E did NOT do what 
it was supposed to do, that is install the software or maintenance or whatever. 
 In any case of SMP/E deciding that something should APPLY/ACCEPT/whatever, and 
it doesn't, a RC=8 (or higher) is warranted.  

Maybe in way of compromise, SMP/E should set a RC=6 instead of 8 where 
maintenance is stopped due to an error hold.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Wednesday, December 23, 2015 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PTF error clarification

I guess I have a basic question - is a return code intended to indicate that 
success of a process doing what it is supposed to do? Or the meaningfulness of 
the results of the process to the person who makes uses of the results of the 
process?

If the former - then should EVERY run of APPLY return a RC=0 unless there is 
malformed input where SMP/e could NOT do what it is supposed to do (on the 
assumption of well-formed input)

If the latter - then are return codes ever meaningful - every result set should 
be reviewed with equal diligence without regard to the RC (smp/e can't guess 
what is acceptable or meaningful to YOU)

If seems that in either case - the RC is not as important as the results; does 
a RC-9 mean that SMP/E did what YOU wanted it to? Or just that the process 
ended without what SMP/E considers to be problems ...

 
Back to my hole 

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538
ctions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

--
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: IODF Catalog

[Craig Pace]

Sorry, meant to paste an example.

You need something like this.

//DEFINEEXEC PGM=IDCAMS
//SYSPRINT  DD   SYSOUT=*
//DDIODFXX  DD   DISP=OLD,UNIT=SYSDA,VOL=SER=IODFXX
//SYSIN DD   *
   DEFINE  CLUSTER( -
  NAME(SYS1.IODFA3.CLUSTER) -
  FILE(DDIODFXX) -
  VOLUME(IODFXX) -
  LINEAR -
  RECATALOG -
  ) -
   DATA(-
  NAME(SYS1.IODFA3))

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mainframe Mainframe
Sent: Wednesday, December 23, 2015 11:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IODF Catalog

Hello ,
Hope you are doing good. we have system in sysplex and
for different versionz/OS system in sysplex we have different master
catalog.
 Now i created IODF from one z/OS system and its catalog under this system 
master catalog. But to access this same IODF from different system, I want to 
catalog this IODF on other system master catalog as well.

So, I am using below JCL

//RECAT   JOB (654),'MAINFRAME',CLASS=A,
//   MSGCLASS=A,NOTIFY=&SYSUID
//S1  EXEC  PGM=IDCAMS
//SYSPRINT  DD  SYSOUT=*
//SYSINDD  *
  DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
VOLUME(PTF001) -
 RECATALOG   -
)   CAT(ZOS13.MASTER.CATALOG)
/*

and output is as below

IDCAMS  SYSTEM SERVICES   TIME:
09:31:59

  DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
VOLUME(PTF001) -
 RECATALOG   -
)   CAT(ZOS13.MASTER.CATALOG)
IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 86 - REASON CODE IS IGG0CLEY-6 IDC3003I 
FUNCTION TERMINATED. CONDITION CODE IS 12

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12


I checked for this IDC3009I code in manual, but not much information I could  
find to solve this .

Any suggestion will help me .

--
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: PTF error clarification

[Shmuel Metz (Seymour J.)]

In <567aa6b1.8050...@us.ibm.com>, on 12/23/2015
   at 08:50 AM, Kurt Quackenbush  said:

>This is an interesting idea, which I'm curious to hear opinions 
>on.  If  doing a mass APPLY (not using the SELECT operand), and 
>PTFs are stopped  because of a PE (ERROR HOLD), either directly 
>or in a requisite chain  that is stuck because of a PE, what RC 
>should be used to identify this  condition?  RC=8?  4?  0?  

I favor 4.

>Other ideas?

HOLDCC=foo and ERRORHOLDCC=bar options.
 
-- 
 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?

[Shmuel Metz (Seymour J.)]

In
,
on 12/23/2015
   at 12:55 PM, "Hardee, Chuck"  said:

>Make sense?

No. That would explain failing on a // SET anywhere in the
contatenation, but not failing only after the first // DD.
 
-- 
 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: IODF Catalog

[John McKown]

On Wed, Dec 23, 2015 at 11:09 AM, Mainframe Mainframe <
mainframe1...@gmail.com> wrote:

> Hello ,
> Hope you are doing good. we have system in sysplex and
> for different versionz/OS system in sysplex we have different master
> catalog.
>  Now i created IODF from one z/OS system and its catalog under this system
> master catalog. But to access this same IODF from different system, I want
> to catalog this IODF on other system master catalog as well.
>
> So, I am using below JCL
>
> ​​
> //RECAT   JOB (654),'MAINFRAME',CLASS=A,
> //   MSGCLASS=A,NOTIFY=&SYSUID
> //S1  EXEC  PGM=IDCAMS
> //SYSPRINT  DD  SYSOUT=*
> //SYSINDD  *
>   DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
> VOLUME(PTF001) -
>  RECATALOG   -
> )   CAT(ZOS13.MASTER.CATALOG)
> /*
>

​The problem is that the above uses the IDCAMS default VSAM type of
"INDEXED". That is, you're saying it is a KSDS data set. Which it is not.
It is a LINEAR data set. Which means that you need the LINEAR keyword.​

​
​
//RECAT   JOB (654),'MAINFRAME',CLASS=A,
//   MSGCLASS=A,NOTIFY=&SYSUID
//S1  EXEC  PGM=IDCAMS
//SYSPRINT  DD  SYSOUT=*
//PTF001 DD DISP=OLD,UNIT=SYSALLDA,VOL=SER=PTF001
//SYSINDD  *
  DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
VOLUME(PTF001) -
LINEAR FILE(PTF001) -
 RECATALOG   -
)   CAT(ZOS13.MASTER.CATALOG)/*
​

​Note the addition of the LINEAR keyword and the FILE(PTF001) on the
inserted line. I'm not totally sure that the FILE(PTF001) and DD are
required, but that's how I do it and it works for me.



>
> and output is as below
>
> IDCAMS  SYSTEM SERVICES   TIME:
> 09:31:59
>
>   DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
> VOLUME(PTF001) -
>  RECATALOG   -
> )   CAT(ZOS13.MASTER.CATALOG)
> IDC3014I CATALOG ERROR
> IDC3009I ** VSAM CATALOG RETURN CODE IS 86 - REASON CODE IS IGG0CLEY-6
> IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
>
> IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12
>
>
> I checked for this IDC3009I code in manual, but not much information I
> could  find to solve this .
>
> Any suggestion will help me .
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
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: PTF error clarification

[Skip Robinson]

I routinely counsel people not to freak out over RC 8, but that advice is
based on how SMPE actually works, not on how I would like it to work. Kurt
has opened up a review of the process. Assuming that the latest HOLDDATA has
been pulled just before APPLY--best practice--then unresolved hold errors
are par for the course and probably deserve only a 4. There is nothing for
the user to do except to re-verify that yup, a needed PTF is not available.
Unless it's available but not RECEIVEd. The cases where user action is
mandatory involve errors such as

-- Insufficient space (allocation or directory blocks)
-- Missing DDDEF
-- Actual compile or bind error

In these situations, RC 8 is certainly in order. Nonetheless, I maintain
that examination of the CAUSER report will quickly distinguish the oh-darn
cases from the oh-sh*ts. 

.
.
.
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 Pommier, Rex
> Sent: Wednesday, December 23, 2015 09:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: PTF error clarification
> 
> Chris,
> 
> I was having similar thoughts as you, although not to the extent of yours.
I tend
> to think along the first of your ideas about the purpose of the RC, that
being to
> indicate the success of the process doing what it is supposed to do.  But
I would
> disagree with your idea of everything being RC=0.  In my mind, if SMP/E
decides
> a PTF shouldn't go on because of a hold (whether error hold or other
reason like
> ACTION), it shouldn't throw a RC=8, because that is SMP/E doing what it
should.
> However, if a utility fails, then SMP/E did NOT do what it was supposed to
do,
> that is install the software or maintenance or whatever.  In any case of
SMP/E
> deciding that something should APPLY/ACCEPT/whatever, and it doesn't, a
RC=8
> (or higher) is warranted.
> 
> Maybe in way of compromise, SMP/E should set a RC=6 instead of 8 where
> maintenance is stopped due to an error hold.  :-)
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Chris Hoelscher
> Sent: Wednesday, December 23, 2015 10:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PTF error clarification
> 
> I guess I have a basic question - is a return code intended to indicate
that
> success of a process doing what it is supposed to do? Or the
meaningfulness of
> the results of the process to the person who makes uses of the results of
the
> process?
> 
> If the former - then should EVERY run of APPLY return a RC=0 unless there
is
> malformed input where SMP/e could NOT do what it is supposed to do (on the
> assumption of well-formed input)
> 
> If the latter - then are return codes ever meaningful - every result set
should be
> reviewed with equal diligence without regard to the RC (smp/e can't guess
what
> is acceptable or meaningful to YOU)
> 
> If seems that in either case - the RC is not as important as the results;
does a RC-
> 9 mean that SMP/E did what YOU wanted it to? Or just that the process
ended
> without what SMP/E considers to be problems ...
> 
> 
> Back to my hole 
> 
> Chris Hoelscher
> Technology Architect, Database Infrastructure Services Technology Solution
> Services
> : humana.com
> 123 East Main Street
> Louisville, KY 40202
> Humana.com
> (502) 714-8615, (502) 476-2538

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

ZEKE and Console dialog

[Carl Edwards]

 I have a client that is considering installing ZEKE. Said client has a fair 
amount of console dialog  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: ZEKE and Console dialog

[Lucas Rosalen]

Hi Carl,

Maybe you should look for an Operations Autmoation tool instead of a
job/event scheduler.
CA-OPS, IBM-Tivoli System Automation, BMC-AutoOperator are some examples.

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 792 809 198


2015-12-23 17:13 GMT-02:00 Carl Edwards <
00df3759e3e7-dmarc-requ...@listserv.ua.edu>:

>  I have a client that is considering installing ZEKE. Said client has a
> fair amount of console dialog  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
>


Este
e-mail foi enviado por um computador sem vírus e protegido pelo Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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

[Jakubek, Jan]

> Is a return code of 4 more appropriate for PTFs not applied because of 
> error hold?

This is an interesting idea, which I'm curious to hear opinions on.  If doing a 
mass APPLY (not using the SELECT operand), and PTFs are stopped because of a PE 
(ERROR HOLD), either directly or in a requisite chain that is stuck because of 
a PE, what RC should be used to identify this condition?  RC=8?  4?  0?  Other 
ideas?

Kurt Quackenbush -- IBM, SMP/E Development

>
Adding a keyword to SMP/E commands that would assign a CC to a (list) of HOLDs 
could satisfy different tastes.
The new keyword would be an override to the current SMP/E processing.

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

[Tom Brennan]

I'm somewhat involved in a distance test scheduled for next month, and I 
believe it will be using the "Fiber Lab Flex" box on this page:

http://www.m2optics.com/fiber-test-boxes/multi-spool-enclosures

The main plan is to check 20km+ between two machines currently right 
next to each other.


Martin Packer wrote:
Skip, I'd share your scepticism about 100+ km apart. I don't know of 
anybody doing anything remotely stressful in CF terms over that distance.


All my customers who are doing e.g. Data Sharing over distance plan and 
measure extremely carefully - and they're doing it over a very few tens of 
km.


I've heard of something called something like a "fibre suitcase" for 
measuring in test.


Could someone who has such a thing tell me its proper name and a little 
more about it? Thanks!


I've actually blogged extensively about the RMF 74-4 latency number 
(relatively new) - which I think is useful in checking distance and 
hinting at routing. While not wanting to advertise the posts I think this 
latency number is one people should check occasionally.


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:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/12/2015 23:59
Subject:Re: Coupling Facility Structure Re-sizing
Sent by:IBM Mainframe Discussion List 



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 

Re: ZEKE and Console dialog

[Greg Shirey]

You asked this same question yesterday and received several replies.  If they 
weren't satisfactory, perhaps you need to rephrase the question. 

Regards,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carl Edwards
Sent: Wednesday, December 23, 2015 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ZEKE and Console dialog

 I have a client that is considering installing ZEKE. Said client has a fair 
amount of console dialog  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: PTF error clarification

[Shmuel Metz (Seymour J.)]

In
<29b16432403d6c45a9bee5f0302d191779b9f...@vss-exchmb1.sfg.corp.LOCAL>,
on 12/23/2015
   at 05:27 PM, "Pommier, Rex"  said:

>Maybe in way of compromise, SMP/E should set a RC=6 instead of 8
>where maintenance is stopped due to an error hold.  :-)

How does an error hold differ from a system hold? 

I'd like an RC08 if a sysmod in SELECT can't go on do to a hold of any
type, and an RC04 if a sysmod not in a SELECT can't go on due to a
hold, regardless of the type of hold. PARM options to control cc
setttings wouldn't hurt.
 
-- 
 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

[Mike Schwab]

On Wed, Dec 23, 2015 at 4:30 PM, Shmuel Metz (Seymour J.)
 wrote:
> In
> <29b16432403d6c45a9bee5f0302d191779b9f...@vss-exchmb1.sfg.corp.LOCAL>,
> on 12/23/2015
>at 05:27 PM, "Pommier, Rex"  said:
>
>>Maybe in way of compromise, SMP/E should set a RC=6 instead of 8
>>where maintenance is stopped due to an error hold.  :-)
>
> How does an error hold differ from a system hold?
>
Where a PTF has an ERROR worse than the problem it fixes and IBM
recommends NOT installing.

> I'd like an RC08 if a sysmod in SELECT can't go on do to a hold of any
> type, and an RC04 if a sysmod not in a SELECT can't go on due to a
> hold, regardless of the type of hold. PARM options to control cc
> setttings wouldn't hurt.
>
> --
>  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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: PTF error clarification

[Shmuel Metz (Seymour J.)]

In
,
on 12/23/2015
   at 04:52 PM, Mike Schwab  said:

>On Wed, Dec 23, 2015 at 4:30 PM, Shmuel Metz (Seymour J.)
> wrote:
>> In
>> <29b16432403d6c45a9bee5f0302d191779b9f...@vss-exchmb1.sfg.corp.LOCAL>,
>> on 12/23/2015
>>at 05:27 PM, "Pommier, Rex"  said:
>>
>>>Maybe in way of compromise, SMP/E should set a RC=6 instead of 8
>>>where maintenance is stopped due to an error hold.  :-)
>>
>> How does an error hold differ from a system hold?
>>
>Where a PTF has an ERROR worse than the problem it fixes and IBM
>recommends NOT installing.

Let me rephrase that: How is refusing to apply a PTF with an error
hold worse than refusing to apply a PTF with a system hold? The ones
to worry about are the ones that *do* go on.
 
-- 
 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?

[Clem Clarke]

Gil, if you hate JCL, why not look at Jol? With simple English like syntax.

It does more than JCL, run in backgound/batch or you can execute jobs 
under TSO.


It has a simple PANEL instruction to make interactive screens.

You can pass Symbolic Parameters from job to job.

It has a Scheduling Facility.

There are versions that run under Z/OS, Windows and Linux - even OS/2.  
The Windows and Linux versions will create JCL or TSO pseudo code OR 
execute programs on Windows and Linux.


See http://start.oscar-jol.com/

Cheers,

Clem Clarke

much what JCLPaul Gilmartin wrote:

On 2015-12-23, at 05:44, R.S. wrote:

I hate JCL!

Just curious: why do you need to insert SET into DD concatenation?
  

No "need" just style for clarity.  I could have put all my SET
statements a hundred lines earlier, immediately after JOB.  Instead
I thought my JCL would be easiest to read if I placed each as close
as possible to the references to its value.  See modified example
below.


On 2015-12-23, at 05:55, Hardee, Chuck wrote:


The reason is that the Converter/Interpreter is expecting data as a result of the 
"//DD2 DD *".
It found none so it is now looking for a new "starting" JCL statement.
It found one, the "// SET" statement.
After processing the "// SET" statement it again looks for a new "starting" 
statement.
It didn't find one, at least not syntactically correct. It recognized the next statement "//  DD " as a 
DD statement, but since the previous DD had been terminated by the "// SET", the JCL rules call for the first 
DD in a concatenation (even a concatenation of 1 DD statement) to have a label. This DD does not have a label so it is 
assumed to be a continuation, but there is no logically "active" DD in effect so, you get the "misplaced 
DD statement" error.

Make sense?
  

No.

I routinely code empty SYSIN, perhaps just to save keystrokes, as in:

//STEP  EXEC  PGM=IEBGENER
//SYSIN  DD   *  # Nothing here; works fine.
//SYSPRINT  DD  SYSOUT=(,)
 ...
And my rewritten example:
   //*
 3 //STEP  EXEC  PGM=IEFBR14
   //*
 4 //DD1DD   *   # "DD *" with no data is just fine.
 5 //   DD   *
   //*
 6 //  SET V1=WOMBAT
 7 //   DD   PATH='/tmp/&V1'
   //*
   IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
 8 //  SET V2=XYZZY
 9 //   DD   PATH='/tmp/&V2'
   //*
   IEFC653I SUBSTITUTION JCL - PATH='/tmp/XYZZY'
10 //DD2DD   *
11 //  SET V3=WOMBAT
12 //   DD   PATH='/tmp/&V3'
   IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
13 //
  STMT NO. MESSAGE
12 IEFC019I MISPLACED DD STATEMENT
 BOTTOM OF DATA **

All the assertions you make should have been equally true of the empty
instream data sets at line 4 or line 5.  Why does the C/I accept those
but reject the one at line 12?

I invite, even challenge, any IBM representative to provide a plausible
rationale for the restriction in the Reference that Lizette and I cited.
How does that rule benefit customers?  Rather, it makes the Reference
thicker, increases the learning burden on programmers, and engenders an
unpleasant Astonishment Factor.  I suspect it arose througn no purposeful
design, but through developer ineptitude and indolence.  It didn't work
as intended, so they documented it and called it a feature.

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




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

[Vince Coen]

Still waiting for a reply on my requesting the sources from some 2+
months ago.


Vince

On 23/12/15 23:54, Clem Clarke wrote:
> Gil, if you hate JCL, why not look at Jol? With simple English like
> syntax.
>
> It does more than JCL, run in backgound/batch or you can execute jobs
> under TSO.
>
> It has a simple PANEL instruction to make interactive screens.
>
> You can pass Symbolic Parameters from job to job.
>
> It has a Scheduling Facility.
>
> There are versions that run under Z/OS, Windows and Linux - even
> OS/2.  The Windows and Linux versions will create JCL or TSO pseudo
> code OR execute programs on Windows and Linux.
>
> See http://start.oscar-jol.com/
>
> Cheers,
>
> Clem Clarke
>
> much what JCLPaul Gilmartin wrote:
>> On 2015-12-23, at 05:44, R.S. wrote:
 I hate JCL!
>>> Just curious: why do you need to insert SET into DD concatenation?
>>>   
>> No "need" just style for clarity.  I could have put all my SET
>> statements a hundred lines earlier, immediately after JOB.  Instead
>> I thought my JCL would be easiest to read if I placed each as close
>> as possible to the references to its value.  See modified example
>> below.
>>
>>
>> On 2015-12-23, at 05:55, Hardee, Chuck wrote:
>>
>>> The reason is that the Converter/Interpreter is expecting data as a
>>> result of the "//DD2 DD *".
>>> It found none so it is now looking for a new "starting" JCL statement.
>>> It found one, the "// SET" statement.
>>> After processing the "// SET" statement it again looks for a new
>>> "starting" statement.
>>> It didn't find one, at least not syntactically correct. It
>>> recognized the next statement "//  DD " as a DD statement, but
>>> since the previous DD had been terminated by the "// SET", the JCL
>>> rules call for the first DD in a concatenation (even a concatenation
>>> of 1 DD statement) to have a label. This DD does not have a label so
>>> it is assumed to be a continuation, but there is no logically
>>> "active" DD in effect so, you get the "misplaced DD statement" error.
>>>
>>> Make sense?
>>>   
>> No.
>>
>> I routinely code empty SYSIN, perhaps just to save keystrokes, as in:
>>
>> //STEP  EXEC  PGM=IEBGENER
>> //SYSIN  DD   *  # Nothing here; works fine.
>> //SYSPRINT  DD  SYSOUT=(,)
>>  ...
>> And my rewritten example:
>>//*
>>  3 //STEP  EXEC  PGM=IEFBR14
>>//*
>>  4 //DD1DD   *   # "DD *" with no data is just fine.
>>  5 //   DD   *
>>//*
>>  6 //  SET V1=WOMBAT
>>  7 //   DD   PATH='/tmp/&V1'
>>//*
>>IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
>>  8 //  SET V2=XYZZY
>>  9 //   DD   PATH='/tmp/&V2'
>>//*
>>IEFC653I SUBSTITUTION JCL - PATH='/tmp/XYZZY'
>> 10 //DD2DD   *
>> 11 //  SET V3=WOMBAT
>> 12 //   DD   PATH='/tmp/&V3'
>>IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
>> 13 //
>>   STMT NO. MESSAGE
>> 12 IEFC019I MISPLACED DD STATEMENT
>>  BOTTOM OF DATA **
>>
>> All the assertions you make should have been equally true of the empty
>> instream data sets at line 4 or line 5.  Why does the C/I accept those
>> but reject the one at line 12?
>>
>> I invite, even challenge, any IBM representative to provide a plausible
>> rationale for the restriction in the Reference that Lizette and I cited.
>> How does that rule benefit customers?  Rather, it makes the Reference
>> thicker, increases the learning burden on programmers, and engenders an
>> unpleasant Astonishment Factor.  I suspect it arose througn no
>> purposeful
>> design, but through developer ineptitude and indolence.  It didn't work
>> as intended, so they documented it and called it a feature.
>>
>> 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
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
- IMPORTANT –

This email and the information in it may be confidential, legally
privileged and/or protected by law.
It is intended solely for the use of the person to whom it is addressed.
If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium. Please
also delete all copies of this email & any attachments from your system.

If this is an encrypted email it is your responsibility to maintain the
1024 byte key system even for one-use keys. O

Re: IODF Catalog

[retired mainframer]

Is the IODF actually on volume PTF001?

The third bullet for the reason code mentions the need to specify LINEAR and 
possibly NONINDEXED.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mainframe Mainframe
> Sent: Wednesday, December 23, 2015 9:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IODF Catalog
> 
> Hello ,
> Hope you are doing good. we have system in sysplex and
> for different versionz/OS system in sysplex we have different master
> catalog.
>  Now i created IODF from one z/OS system and its catalog under this system
> master catalog. But to access this same IODF from different system, I want
> to catalog this IODF on other system master catalog as well.
> 
> So, I am using below JCL
> 
> //RECAT   JOB (654),'MAINFRAME',CLASS=A,
> //   MSGCLASS=A,NOTIFY=&SYSUID
> //S1  EXEC  PGM=IDCAMS
> //SYSPRINT  DD  SYSOUT=*
> //SYSINDD  *
>   DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
> VOLUME(PTF001) -
>  RECATALOG   -
> )   CAT(ZOS13.MASTER.CATALOG)
> /*
> 
> and output is as below
> 
> IDCAMS  SYSTEM SERVICES   TIME:
> 09:31:59
> 
>   DEFINE CLUSTER(NAME(SYS1.IODF05.WORK1.CLUSTER) -
> VOLUME(PTF001) -
>  RECATALOG   -
> )   CAT(ZOS13.MASTER.CATALOG)
> IDC3014I CATALOG ERROR
> IDC3009I ** VSAM CATALOG RETURN CODE IS 86 - REASON CODE IS
> IGG0CLEY-6
> IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
> 
> IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE
> WAS 12
> 
> 
> I checked for this IDC3009I code in manual, but not much information I
> could  find to solve this .
> 
> Any suggestion will help me .

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

Re: Is there a source for detailed, instruction-level performance info?

[Thomas Kern]

Perhaps what might be useful would be an assembler program to run loops 
of individual instructions and output some timing information.


/Tom

On 12/23/2015 11:20, Shmuel Metz (Seymour J.) wrote:

In <8970116796168447.wa.jcallennarsil@listserv.ua.edu>, on
12/23/2015
at 09:46 AM, Jerry Callen  said:


I'm in the process of hand-tuning a small, performance critical
algorithm on a Z13,

Lather, rinse, repeat every time you change processors.


and I'm hampered by the lack of detailed
information on the instruction-level performance of the machine.

Be careful what you ask for; you might get it.


Back in the day, IBM used to publish a "Functional Characteristics"
manual for each CPU model that provided this information;

Except when it was in a separate timing manual.

Every time that IBM introduced a new processor the timing formulæ
became more  complicated. I suspect that a timing manual for the z13
would be massive.
  


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

[Pinnacle]

On 12/23/2015 2:53 PM, Tom Brennan wrote:

I'm somewhat involved in a distance test scheduled for next month, and I
believe it will be using the "Fiber Lab Flex" box on this page:
http://www.m2optics.com/fiber-test-boxes/multi-spool-enclosures

The main plan is to check 20km+ between two machines currently right
next to each other.

Martin Packer wrote:

Skip, I'd share your scepticism about 100+ km apart. I don't know of
anybody doing anything remotely stressful in CF terms over that distance.

All my customers who are doing e.g. Data Sharing over distance plan
and measure extremely carefully - and they're doing it over a very few
tens of km.

I've heard of something called something like a "fibre suitcase" for
measuring in test.

Could someone who has such a thing tell me its proper name and a
little more about it? Thanks!



Martin,

Check out Meral Temel's presentation on distance testing (WTW):

https://share.confex.com/share/125/webprogram/Handout/Session17920/SHAREOrlandoMeralv5.pdf

Regards,
Tom Conley

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

[Robert A. Rosenberg]

At 08:50 -0500 on 12/23/2015, Kurt Quackenbush wrote about Re: PTF 
error clarification:



Is a return code of 4 more appropriate for PTFs not applied because of
error hold?


This is an interesting idea, which I'm curious to hear opinions on. 
If doing a mass APPLY (not using the SELECT operand), and PTFs are 
stopped because of a PE (ERROR HOLD), either directly or in a 
requisite chain that is stuck because of a PE, what RC should be 
used to identify this condition?  RC=8?  4?  0?  Other ideas?


Kurt Quackenbush -- IBM, SMP/E Development


I think that RC=4 is the correct RC for a MASS APPLY. I see a MASS 
APPLY as a request to install all RECEIVED SYSMODS that have not yet 
been APPLY'ed. Thus a PE HOLD is a warning that an SYSMOD can not be 
APPLY'ed due to the PE status.


For a SELECT APPLY then issue a RC=8. In this case I am saying to 
specifically APPLY the SYSMOD (as opposed to the MASS case where it 
APPLYs IF there is no reason to not APPLY such as due to a PE status) 
so the PE HOLD says that the SYSMOD should not be APPLY'ed and thus 
the SELECT is an error.


In the MASS case I am asking to APPLY all SYSMODs that can 
potentially be APPLY'ed (so long as there are not reasons to not 
APPLY) that thus the RC=4/Warning that some did not get APPLY'ed. In 
the SELECT case I say I want a designated SYSMOD APPLY'ed and the 
RC=8/ERROR says I selected a SYSMOD that should not have been 
SELECT'ed.


Note that a PE (or other) HOLD is not the only reason for a failure 
to APPLY. Missing IFREQs and PREs are also reasons for blocking the 
APPLY (either MASS selected or specifically SELECT'ed).


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

Well stated. I would expand 'mass APPLY' to include apply by source id,
especially (but not necessarily limited to) SRCID(). I'm liking the improved
future SMPE better and better. ;-) Still, I expect the CAUSER report to be
the sysprog's BFF.


.
.
.
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 Robert A. Rosenberg
> Sent: Wednesday, December 23, 2015 09:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: PTF error clarification
> 
> At 08:50 -0500 on 12/23/2015, Kurt Quackenbush wrote about Re: PTF error
> clarification:
> 
> >>Is a return code of 4 more appropriate for PTFs not applied because of
> >>error hold?
> >
> >This is an interesting idea, which I'm curious to hear opinions on.
> >If doing a mass APPLY (not using the SELECT operand), and PTFs are
> >stopped because of a PE (ERROR HOLD), either directly or in a requisite
> >chain that is stuck because of a PE, what RC should be used to identify
> >this condition?  RC=8?  4?  0?  Other ideas?
> >
> >Kurt Quackenbush -- IBM, SMP/E Development
> 
> I think that RC=4 is the correct RC for a MASS APPLY. I see a MASS APPLY
as a
> request to install all RECEIVED SYSMODS that have not yet been APPLY'ed.
Thus
> a PE HOLD is a warning that an SYSMOD can not be APPLY'ed due to the PE
> status.
> 
> For a SELECT APPLY then issue a RC=8. In this case I am saying to
specifically
> APPLY the SYSMOD (as opposed to the MASS case where it APPLYs IF there is
no
> reason to not APPLY such as due to a PE status) so the PE HOLD says that
the
> SYSMOD should not be APPLY'ed and thus the SELECT is an error.
> 
> In the MASS case I am asking to APPLY all SYSMODs that can potentially be
> APPLY'ed (so long as there are not reasons to not
> APPLY) that thus the RC=4/Warning that some did not get APPLY'ed. In the
> SELECT case I say I want a designated SYSMOD APPLY'ed and the RC=8/ERROR
> says I selected a SYSMOD that should not have been SELECT'ed.
> 
> Note that a PE (or other) HOLD is not the only reason for a failure to
APPLY.
> Missing IFREQs and PREs are also reasons for blocking the APPLY (either
MASS
> selected or specifically SELECT'ed).

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