Re: Interesting - NODE for z/OS

[Timothy Sipples]

The IBM SDK for Node.js probably won't run on your z9BC machine, but you're
welcome to try it. (Please let us all know.) The latest trial download is
available here:

https://developer.ibm.com/node/sdk/ztp/

APAR UI46658 is surely required, so check for that.

If you're looking for a JavaScript implementation (without Node) for a z9BC
machine, I believe HostBridge's HB.js is compatible.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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

Re: Interesting - NODE for z/OS

[David Crayford]

We've been using Node for internal tooling and IBM have done a good job. 
The Node eco-system is the fast growing of any language/runtime. Like 
I've said before the most exciting thing from my perspective is the 
clang compiler that ships with it.


One important feature that makes Node so scalable is libuv and it's 
async I/O. IBM have emulated epoll using standard poll so I can't see 
how it's ever going to scale like it does on other platforms. It's 
curious why they didn't use aio like the pollsets in the z port of the APR?



On 21/02/2018 9:12 PM, Jerry Callen wrote:

You don't have to build from source; you can get a downloadable SDK:

https://www.ibm.com/us-en/marketplace/sdk-nodejs-compiler-zos

There is a DeveloperWorks forum for node.js on IBM platforms (including z/OS 
and Linux on Z):
  
https://www.ibm.com/developerworks/community/groups/service/html/communitystart?communityUuid=39f4d6be-d936-4a36-8fbf-874bf4bde113


-- Jerry

--
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: The Beauty of the COBOL Programming Language - DevOps.com

[David Crayford]

On 22/02/2018 11:53 AM, Jack J. Woehr wrote:

On 2/20/2018 10:31 PM, Gabe Goldberg wrote:

https://devops.com/the-beauty-of-the-cobol-programming-language-v2/


 * Docs  »
 * What’s New?
 * Edit on GitHub



No longer maintained 
https://github.com/OpenCobolIDE/OpenCobolIDE/issues/439. The author 
makes a good point that there is no real point to writing a bespoke IDE 
when you can just write a plug-in for cool new editors like VS Code and 
Atom. I wish IBM would do the same so were weren't lumbered with flabby 
Eclipse!








 What’s New?

** OpenCobolIDE is no longer maintained **



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

Re: The Beauty of the COBOL Programming Language - DevOps.com

[Jack J. Woehr]

On 2/20/2018 10:31 PM, Gabe Goldberg wrote:

https://devops.com/the-beauty-of-the-cobol-programming-language-v2/


 * Docs  »
 * What’s New?
 * Edit on GitHub
   






 What’s New?

** OpenCobolIDE is no longer maintained **

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


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

Re: The Beauty of the COBOL Programming Language - DevOps.com

[Warren Brown]

Cool

  From: Gabe Goldberg 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Wednesday, February 21, 2018 12:32 AM
 Subject: The Beauty of the COBOL Programming Language - DevOps.com
   
https://devops.com/the-beauty-of-the-cobol-programming-language-v2/

-- 
Gabriel Goldberg, Computers and Publishing, Inc.      g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042          (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegold           Twitter: GabeG0

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

Two summer time change questions

[Charles Mills]

First though, apologies for asking what perhaps has been covered before --
perhaps even asked by me. I am having no luck searching the archives. I
search on CVTTZ and get no hits even though I have IBM-MAIN messages in my
own Outlook that contain CVTTZ.

1. Humor a guy with almost no operations experience with the world's most
newbie operations question. If you are a shop in North America, how will you
"convert" your z/OS instances to summer time next month? Do you or does your
console automation software have to enter a SET command, or does it happen
automagically internally to z/OS on some pre-configured schedule? (I
remember I had a P/390 back in the day and VM had an internal table that did
the time change automagically but I recall I had to re-IPL OS/390 to pick up
the change.)

2. When the above happens, will CVTTZ and CVTLDTO get updated on the fly? If
I inspected them one second would I see an offset of, e.g., 8 hours (in TOD
or "TOD-high word" format as appropriate) and if I inspected them a second
later I would see 7 hours?

Charles 

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

Re: Any issues with $ACTIVATE,LEVEL=Z22 command

[Allan Staller]

Actually seconds, (<10) not minutes.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, February 21, 2018 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command

We need to do something similar. My recommendation for 'at the same time' is to 
first allow CYL_MANAGED by command, then when the dust has settled, activate 
the new level. This can be done during the same Change Management window, 
minutes only, but it might minimize the churn.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Wednesday, February 21, 2018 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Any issues with $ACTIVATE,LEVEL=Z22 command

if your checkpoint can support it I say go for it.


from the $DACTIVATE



$DACTIVATE
JES2 CHECKPOINT MODE IS CURRENTLY Z11
THE CURRENT CHECKPOINT:
-- CONTAINS 13099 BERTS AND BERT UTILIZATION IS 5 PERCENT.
-- CONTAINS 1296 4K RECORDS.
z22 CHECKPOINT MODE ACTIVATION WILL:
-- EXPAND CHECKPOINT SIZE TO 1366 4K RECORDS.



I've never hear any issues once any issues with CKPT and SPOOLDEF have been 
resolved


Carmen Vitullo

- Original Message -

From: "Todd Burrell" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:41:43 PM
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command

Yeah - we're planning on doing both at the same time ($TSPOOLDEF and $ACTIVATE).


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Wednesday, February 21, 2018 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command

forgot to mention CYL_MANAGED support can be changed dynamically


$T SPOOLDEF,CYL_MANAGED=ALLOWED



Carmen Vitullo

- Original Message -

From: "Carmen Vitullo" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:34:58 PM
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED.
I'm in no rush right now to get to z22 mode







Carmen Vitullo

- Original Message -

From: "Todd Burrell" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:27:11 PM
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time.
Thanks
Todd Burrell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

Re: Any issues with $ACTIVATE,LEVEL=Z22 command

[Jesse 1 Robinson]

We need to do something similar. My recommendation for 'at the same time' is to 
first allow CYL_MANAGED by command, then when the dust has settled, activate 
the new level. This can be done during the same Change Management window, 
minutes only, but it might minimize the churn. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Wednesday, February 21, 2018 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Any issues with $ACTIVATE,LEVEL=Z22 command

if your checkpoint can support it I say go for it. 


from the $DACTIVATE 



$DACTIVATE
JES2 CHECKPOINT MODE IS CURRENTLY Z11
THE CURRENT CHECKPOINT: 
-- CONTAINS 13099 BERTS AND BERT UTILIZATION IS 5 PERCENT. 
-- CONTAINS 1296 4K RECORDS. 
z22 CHECKPOINT MODE ACTIVATION WILL: 
-- EXPAND CHECKPOINT SIZE TO 1366 4K RECORDS. 



I've never hear any issues once any issues with CKPT and SPOOLDEF have been 
resolved 


Carmen Vitullo 

- Original Message -

From: "Todd Burrell" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:41:43 PM
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

Yeah - we're planning on doing both at the same time ($TSPOOLDEF and 
$ACTIVATE). 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Wednesday, February 21, 2018 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

forgot to mention CYL_MANAGED support can be changed dynamically 


$T SPOOLDEF,CYL_MANAGED=ALLOWED 



Carmen Vitullo 

- Original Message - 

From: "Carmen Vitullo" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:34:58 PM
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get 

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED. 
I'm in no rush right now to get to z22 mode 







Carmen Vitullo 

- Original Message - 

From: "Todd Burrell" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:27:11 PM
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command 

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks
Todd Burrell 

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

Re: Any issues with $ACTIVATE,LEVEL=Z22 command

[Jesse 1 Robinson]

I've never been in a pickle, but I've had to do a cold start. Much colder than 
a pickle (or so I imagine). 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Wednesday, February 21, 2018 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Any issues with $ACTIVATE,LEVEL=Z22 command

just some food for thought, once you're z22 mode there's no EASY way back 
that's the biggest reason I've delayed this on my prod plex, I'm comfortable 
now but for any reason I had to revert back to z/OS 2.1, I'd be in a pickle :) 



Carmen Vitullo 

- Original Message -

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:41:43 PM 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

Yeah - we're planning on doing both at the same time ($TSPOOLDEF and 
$ACTIVATE). 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Wednesday, February 21, 2018 1:39 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

forgot to mention CYL_MANAGED support can be changed dynamically 


$T SPOOLDEF,CYL_MANAGED=ALLOWED 



Carmen Vitullo 

- Original Message - 

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:34:58 PM 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get 

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED. 
I'm in no rush right now to get to z22 mode 

Carmen Vitullo 

- Original Message - 

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:27:11 PM 
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command 

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks 
Todd Burrell 

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

Re: Any issues with $ACTIVATE,LEVEL=Z22 command

[Carmen Vitullo]

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get 

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED. 
I'm in no rush right now to get to z22 mode 







Carmen Vitullo 

- Original Message -

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:27:11 PM 
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command 

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks 
Todd Burrell 

-- 
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: Any issues with $ACTIVATE,LEVEL=Z22 command

[Carmen Vitullo]

just some food for thought, once you're z22 mode there's no EASY way back 
that's the biggest reason I've delayed this on my prod plex, I'm comfortable 
now but for any reason I had to revert back to z/OS 2.1, I'd be in a pickle :) 



Carmen Vitullo 

- Original Message -

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:41:43 PM 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

Yeah - we're planning on doing both at the same time ($TSPOOLDEF and 
$ACTIVATE). 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Wednesday, February 21, 2018 1:39 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

forgot to mention CYL_MANAGED support can be changed dynamically 


$T SPOOLDEF,CYL_MANAGED=ALLOWED 



Carmen Vitullo 

- Original Message - 

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:34:58 PM 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get 

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED. 
I'm in no rush right now to get to z22 mode 







Carmen Vitullo 

- Original Message - 

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:27:11 PM 
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command 

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks 
Todd Burrell 

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


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


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



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email. 


-- 
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: Any issues with $ACTIVATE,LEVEL=Z22 command

[Carmen Vitullo]

if your checkpoint can support it I say go for it. 


from the $DACTIVATE 



$DACTIVATE 
JES2 CHECKPOINT MODE IS CURRENTLY Z11 
THE CURRENT CHECKPOINT: 
-- CONTAINS 13099 BERTS AND BERT UTILIZATION IS 5 
PERCENT. 
-- CONTAINS 1296 4K RECORDS. 
z22 CHECKPOINT MODE ACTIVATION WILL: 
-- EXPAND CHECKPOINT SIZE TO 1366 4K RECORDS. 



I've never hear any issues once any issues with CKPT and SPOOLDEF have been 
resolved 


Carmen Vitullo 

- Original Message -

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:41:43 PM 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

Yeah - we're planning on doing both at the same time ($TSPOOLDEF and 
$ACTIVATE). 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Wednesday, February 21, 2018 1:39 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

forgot to mention CYL_MANAGED support can be changed dynamically 


$T SPOOLDEF,CYL_MANAGED=ALLOWED 



Carmen Vitullo 

- Original Message - 

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:34:58 PM 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get 

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED. 
I'm in no rush right now to get to z22 mode 







Carmen Vitullo 

- Original Message - 

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:27:11 PM 
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command 

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks 
Todd Burrell 

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


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


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



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email. 


-- 
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: Any issues with $ACTIVATE,LEVEL=Z22 command

[Allan Staller]

At this point in time I would not expect any. I just updated an LPAR this past 
weekend w/no issues.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Todd Burrell
Sent: Wednesday, February 21, 2018 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this?  I've checked our CHECKPOINT's and 
they have plenty of room.  We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time.
Thanks
Todd Burrell

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Any issues with $ACTIVATE,LEVEL=Z22 command

[Carmen Vitullo]

forgot to mention CYL_MANAGED support can be changed dynamically 


$T SPOOLDEF,CYL_MANAGED=ALLOWED 



Carmen Vitullo 

- Original Message -

From: "Carmen Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:34:58 PM 
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get 

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED. 
I'm in no rush right now to get to z22 mode 







Carmen Vitullo 

- Original Message - 

From: "Todd Burrell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 21, 2018 12:27:11 PM 
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command 

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks 
Todd Burrell 

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


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


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

Re: Any issues with $ACTIVATE,LEVEL=Z22 command

[Burrell, Todd]

Yeah - we're planning on doing both at the same time ($TSPOOLDEF and 
$ACTIVATE).  


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Wednesday, February 21, 2018 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command

forgot to mention CYL_MANAGED support can be changed dynamically 


$T SPOOLDEF,CYL_MANAGED=ALLOWED 



Carmen Vitullo 

- Original Message -

From: "Carmen Vitullo" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:34:58 PM
Subject: Re: Any issues with $ACTIVATE,LEVEL=Z22 command 

no problems on my test system after expanding my checkpoint but my production 
systems MAS I get 

$HASP895 z22 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER. 
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION: 
$HASP895 -- CYL_MANAGED SUPPORT MUST BE ACTIVATED. 
I'm in no rush right now to get to z22 mode 







Carmen Vitullo 

- Original Message - 

From: "Todd Burrell" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, February 21, 2018 12:27:11 PM
Subject: Any issues with $ACTIVATE,LEVEL=Z22 command 

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this? I've checked our CHECKPOINT's and 
they have plenty of room. We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks
Todd Burrell 

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


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


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



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


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

Any issues with $ACTIVATE,LEVEL=Z22 command

[Todd Burrell]

We've done the $ACTIVATE,LEVEL=Z22 command on our test system and seen no 
issues, but I wanted to run it by this group to see if there have been any 
issues that anyone has seen when doing this?  I've checked our CHECKPOINT's and 
they have plenty of room.  We will also be doing the 
$TSPOOLDEF,CYL_MANAGED=ALLOWED command at the same time. 
Thanks 
Todd Burrell

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

Re: Interesting - NODE for z/OS

[Martin Packer]

But in that case isn't the javascript running on the client? With node 
it's running on the server.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA

IBM Mainframe Discussion List  wrote on 
21/02/2018 15:01:53:

> From: "Barkow, Eileen" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 21/02/2018 15:02
> Subject: Re: Interesting - NODE for z/OS
> Sent by: IBM Mainframe Discussion List 
> 
> CICS DOCTEMPLATES can include javascript code.
> 
> So NODE Is not the only thing that allows it.
> 
> 
> 
> -Original Message-
> 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of John McKown
> 
> Sent: Wednesday, February 21, 2018 8:05 AM
> 
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Subject: Interesting - NODE for z/OS
> 
> 
> 
> I haven't really had a chance to look at this yet. But I thought others
> 
> here might be interested. It is NODE for z/OS. NODE is a "server side"
> 
> JavaScript engine. That is, it allows you to run JavaScript programs on
> 
> z/OS.
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__github.com_ibmruntimes_node_releases_tag_ibm-2D6.13.0.
> 0=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-
> 
WOWZjlZ0NwmcFSpQCLphNznBSDQ=x85RBflm3aMlm0FgBnkL4MExpjplPK_JEo0P0ANp4bE=aG5MvbKXog2YDJWhNK27zF5mpM7pM5vbwKfw6KZooUg=
> 
> 
> 
> Source only, no executable.
> 
> 
> 
> --
> 
> I have a theory that it's impossible to prove anything, but I can't 
prove
> 
> it.
> 
> 
> 
> Maranatha! <><
> 
> John McKown
> 
> 
> 
> --
> 
> For IBM-MAIN subscribe / signoff / archive access instructions,
> 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This e-mail, including any attachments, may be confidential, 
> privileged or otherwise legally protected. It is intended only for 
> the addressee. If you received this e-mail in error or from someone 
> who was not authorized to send it to you, do not disseminate, copy 
> or otherwise use this e-mail or its attachments. Please notify the 
> sender immediately by reply e-mail and delete the e-mail from your 
system.
> 
> 
> 
> --
> 
> For IBM-MAIN subscribe / signoff / archive access instructions,
> 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: Dr. John Ehrman

[Phil Smith III]

Can't add anything meaningful to what others have said other than to echo
that this is a huge loss to the community, both as a person and as a
technical resource.

 

.phsiii


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

Re: Interesting - NODE for z/OS

[John McKown]

On Wed, Feb 21, 2018 at 7:12 AM, Jerry Callen  wrote:

> You don't have to build from source; you can get a downloadable SDK:
>
> https://www.ibm.com/us-en/marketplace/sdk-nodejs-compiler-zos


​Thank you for that link. One difference that I can see is that the above
mentions a "Free 90 day trial"​ and I must sign in to ShopZ to get it.
Whereas the source pointed to in my original messages does not have any
mention of a "free trail" period or any requirement to use my IBM id to get
the software. Not that it matters to me personally, because it is unlikely
that the IBM offering will run on my company's ancient z9BC. I'm running
into that a lot any more. And management here basically refuses to get a
more current machine.



>
>
> There is a DeveloperWorks forum for node.js on IBM platforms (including
> z/OS and Linux on Z):
>
> https://www.ibm.com/developerworks/community/groups/service/
> html/communitystart?communityUuid=39f4d6be-d936-4a36-8fbf-874bf4bde113
>
> -- Jerry
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: Interesting - NODE for z/OS

[Barkow, Eileen]

CICS DOCTEMPLATES can include javascript code.
So NODE Is not the only thing that allows it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, February 21, 2018 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Interesting - NODE for z/OS

I haven't really had a chance to look at this yet. But I thought others
here might be interested. It is NODE for z/OS. NODE is a "server side"
JavaScript engine. That is, it allows you to run JavaScript programs on
z/OS.

https://github.com/ibmruntimes/node/releases/tag/ibm-6.13.0.0

Source only, no executable.

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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




This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

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

Re: DASD problem

[Tommy Tsui]

Star


Allan Staller  於 2018年2月21日 星期三寫道：

> GRS- Ring or Star?
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tommy Tsui
> Sent: Wednesday, February 21, 2018 2:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DASD problem
>
> We use HDS instead not Ibm, we report this case to Ibm and perform the
> same operation on monoplex lpar the result is around 7mins write 28gb data
> using utility IEBDG, but use 12 mins while in sysplex lpar with same DASD,
> only can find is high disconnect time from RMF report
>
> Ron hawkins  於 2018年2月21日 星期三寫道：
>
> > Tommy,
> >
> > The RTD at 30km is quite small, and the benefit of write spoofing will
> > be small.
> >
> > There is an option to turn on write spoofing with the FCP PPRC links
> > on IBM storage, but you should check with them that it is a benefit at
> > small distances on your model of storage at all write rates.
> >
> > Ron
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Tommy Tsui
> > Sent: Tuesday, February 20, 2018 8:22 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] DASD problem
> >
> > Is there any way to improve the pprc command latency and round trip
> > delay time?
> > Anything can tune on DASD Hardware or switch side?
> > Anything can tune on os side? BUFNO,
> >
> > Rob Schramm  於 2018年2月21日 星期三寫道：
> >
> > > It used to be 20 or 25 buffers to establish the I/o sweet spot.
> > > Maybe with the faster dasd the amount is different.
> > >
> > > Rob
> > >
> > > On Tue, Feb 20, 2018, 7:53 PM Tommy Tsui  wrote:
> > >
> > > > Hi Ron,
> > > > You are right when I changed BUFNO to 255,  The overall elapsed
> > > > time reduce from 12mins to 6 mins, So what can I do now,? Change
> > > > BUFNO only ? How about vsam or db2 performance?
> > > >
> > > >
> > > > Ron hawkins  於 2018年2月21日 星期三寫道：
> > > >
> > > > > Tommy,
> > > > >
> > > > > With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed
> > > > > are independent of one another, but the stepped down speed
> > > > > elongate the
> > > > Remote
> > > > > IO.
> > > > >
> > > > > In simple terms a block that you write from the host to the
> > > > > P-VOL takes 0.5ms to transfer on 16Gb FICON, and but then you do
> > > > > the synchronous
> > > > write
> > > > > on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to
> > > transfer.
> > > > > This time is in addition to command latency and round-trip delay
> > time.
> > > As
> > > > > described below, this impact will be less for long, chained
> > > > > writes
> > > > because
> > > > > of the Host/PPRC overlap.
> > > > >
> > > > > I'm not sure how you simulate this on your monoplex, but I
> > > > > assume you
> > > set
> > > > > up a PPRC pair to the remote site. If you are testing with BSAM
> > > > > or QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the
> > > > > single block
> > > impact.
> > > > If
> > > > > you are using zHPF, I think you can vary the BUFNO or NCP to get
> > > > > up to
> > > > 255
> > > > > chained blocks.
> > > > >
> > > > > I'm not aware of anything in GRS that adds to remote IO
> > > > > disconnect
> > > time.
> > > > >
> > > > > Ron
> > > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List
> > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > > On
> > > > > Behalf Of Tommy Tsui
> > > > > Sent: Tuesday, February 20, 2018 2:42 AM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: [IBM-MAIN] DASD problem
> > > > >
> > > > > Hi Ron,
> > > > > What happens to if our ficon card is 16gb, and fcp connection is
> > > > > 2gb, I try to do the simulation on monoplex  lpar , the result
> > > > > is fine, now we
> > > > are
> > > > > suspect the GRS or other system parm which will increase the
> > > > > disconnect
> > > > time
> > > > >
> > > > > Ron hawkins  於 2018年2月
> > > > >
> > > > > 15日 星期四寫道：
> > > > >
> > > > > > Tommy,
> > > > > >
> > > > > > This should not be a surprise. The name "Synchronous Remote Copy"
> > > > > > implies the overhead that you are seeing, namely the time for
> > > > > > the synchronous write to the remote site.
> > > > > >
> > > > > > PPRC will more than double the response time of random writes
> > > > > > because they the Host write to cache has the additional time
> > > > > > of controller latency, round trip delay, and block transfer
> > > > > > before the write is complete. On IBM and HDS (not sure with
> > > > > > EMC) the impact is greater
> > > for
> > > > > > single blocks, as chained sequential writes have some overlap
> > > > > > between the host write, and the synchronous write.
> > > > > >
> > > > > > Some things to check:
> > > > > >
> > > > > > 1) Buffer Credits on ISLs between the sites. If no ISLs then
> > > > > > settings on the storage 

Re: Dr. John Ehrman

[Don Poitras]

I worked with John back in the 90s when I was part of the languages
group that he headed at Share. I always made it a point to attend
his pitches as they were full of information that I could use and
the hand-outs were always excellent. I just found that he had updated
his excellent "Assembler Language Programming for IBM z System Servers"
book:

http://idcp.marist.edu/enterprisesystemseducation/assemblerlanguageresources-1.html

I'm proud to say that I contributed to this. I found what I think 
is the smallest error possible in the version one of the book. There
was a table where the bits were described for floating point values
and one of the bits was wrong. :)

He will be very missed.

In article <5a8c8a7e.3060...@vse2pdf.com> you wrote:
> Those of you who have followed this list for years know well that Dr. John 
> Ehrman was the motivating force behind the development of the High-Level 
> Assembler (I often referred to him as the God Father of HLASM).
> I am deeply saddened to report that John passed away this morning (Tuesday, 
> 20 February 2018) following a protracted battle with cancer.  His wife, 
> Tineke, reports: "He died in his sleep, and is now at peace and pain free. 
> John will be cremated; in the near future there will be a memorial service at 
> our church in Palo Alto."
> I will convey any further information on the memorial to this listing.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Dr. John Ehrman

[Dave Jones]

"John was an exceedingly gracious individual without whom a lot of us would 
have been lost."
Amen to that.
DJ

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

Re: DASD problem

[Allan Staller]

GRS- Ring or Star?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tommy Tsui
Sent: Wednesday, February 21, 2018 2:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DASD problem

We use HDS instead not Ibm, we report this case to Ibm and perform the same 
operation on monoplex lpar the result is around 7mins write 28gb data using 
utility IEBDG, but use 12 mins while in sysplex lpar with same DASD, only can 
find is high disconnect time from RMF report

Ron hawkins  於 2018年2月21日 星期三寫道：

> Tommy,
>
> The RTD at 30km is quite small, and the benefit of write spoofing will
> be small.
>
> There is an option to turn on write spoofing with the FCP PPRC links
> on IBM storage, but you should check with them that it is a benefit at
> small distances on your model of storage at all write rates.
>
> Ron
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tommy Tsui
> Sent: Tuesday, February 20, 2018 8:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] DASD problem
>
> Is there any way to improve the pprc command latency and round trip
> delay time?
> Anything can tune on DASD Hardware or switch side?
> Anything can tune on os side? BUFNO,
>
> Rob Schramm  於 2018年2月21日 星期三寫道：
>
> > It used to be 20 or 25 buffers to establish the I/o sweet spot.
> > Maybe with the faster dasd the amount is different.
> >
> > Rob
> >
> > On Tue, Feb 20, 2018, 7:53 PM Tommy Tsui  wrote:
> >
> > > Hi Ron,
> > > You are right when I changed BUFNO to 255,  The overall elapsed
> > > time reduce from 12mins to 6 mins, So what can I do now,? Change
> > > BUFNO only ? How about vsam or db2 performance?
> > >
> > >
> > > Ron hawkins  於 2018年2月21日 星期三寫道：
> > >
> > > > Tommy,
> > > >
> > > > With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed
> > > > are independent of one another, but the stepped down speed
> > > > elongate the
> > > Remote
> > > > IO.
> > > >
> > > > In simple terms a block that you write from the host to the
> > > > P-VOL takes 0.5ms to transfer on 16Gb FICON, and but then you do
> > > > the synchronous
> > > write
> > > > on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to
> > transfer.
> > > > This time is in addition to command latency and round-trip delay
> time.
> > As
> > > > described below, this impact will be less for long, chained
> > > > writes
> > > because
> > > > of the Host/PPRC overlap.
> > > >
> > > > I'm not sure how you simulate this on your monoplex, but I
> > > > assume you
> > set
> > > > up a PPRC pair to the remote site. If you are testing with BSAM
> > > > or QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the
> > > > single block
> > impact.
> > > If
> > > > you are using zHPF, I think you can vary the BUFNO or NCP to get
> > > > up to
> > > 255
> > > > chained blocks.
> > > >
> > > > I'm not aware of anything in GRS that adds to remote IO
> > > > disconnect
> > time.
> > > >
> > > > Ron
> > > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On
> > > > Behalf Of Tommy Tsui
> > > > Sent: Tuesday, February 20, 2018 2:42 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: [IBM-MAIN] DASD problem
> > > >
> > > > Hi Ron,
> > > > What happens to if our ficon card is 16gb, and fcp connection is
> > > > 2gb, I try to do the simulation on monoplex  lpar , the result
> > > > is fine, now we
> > > are
> > > > suspect the GRS or other system parm which will increase the
> > > > disconnect
> > > time
> > > >
> > > > Ron hawkins  於 2018年2月
> > > >
> > > > 15日 星期四寫道：
> > > >
> > > > > Tommy,
> > > > >
> > > > > This should not be a surprise. The name "Synchronous Remote Copy"
> > > > > implies the overhead that you are seeing, namely the time for
> > > > > the synchronous write to the remote site.
> > > > >
> > > > > PPRC will more than double the response time of random writes
> > > > > because they the Host write to cache has the additional time
> > > > > of controller latency, round trip delay, and block transfer
> > > > > before the write is complete. On IBM and HDS (not sure with
> > > > > EMC) the impact is greater
> > for
> > > > > single blocks, as chained sequential writes have some overlap
> > > > > between the host write, and the synchronous write.
> > > > >
> > > > > Some things to check:
> > > > >
> > > > > 1) Buffer Credits on ISLs between the sites. If no ISLs then
> > > > > settings on the storage host ports to cater for 30km B2B
> > > > > credits
> > > > > 2) Channel speed step-down - If your FICON channels are 8Gb,
> > > > > and the FCP connections are 2Gb, then PPRC writes will take up
> > > > > to four times longer to transfer. It dep[ends on the block size.
> > > > > 3) Unbalanced ISLs - ISLs do not automatically 

Re: Data sets incorrectly cataloged to HSM MIGRAT2

[Allan Staller]

DCOLLECT and you favorite editor/language

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, February 20, 2018 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Data sets incorrectly cataloged to HSM MIGRAT2

We have situation where a lot of data sets are incorrectly cataloged to HSM 
MIGRAT2. For an individual case, I can try HDELETE. If I get the message that 
data set is not migrated, I can issue DEL NSCR.

However we have thousands of these. We can CSI list them by data set name 
pattern. I don't really want to DEL NSCR if a data set is actually migrated. 
Any suggestions for how to handle an enormous number of these?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Dr. John Ehrman

[Elardus Engelbrecht]

Tony Thigpen wrote:

>Those of you who have followed this list for years know well that Dr. John 
>Ehrman was the motivating force behind the development of the High-Level 
>Assembler (I often referred to him as the God Father of HLASM).

>I am deeply saddened to report that John passed away this morning (Tuesday, 20 
>February 2018) following a protracted battle with cancer.  His wife, Tineke, 
>reports: "He died in his sleep, and is now at peace and pain free. John will 
>be cremated; in the near future there will be a memorial service at our church 
>in Palo Alto."

Oh no, I am sad about this bad news. Thanks Tony. 

Dr. J Ehrman was very good and he is THE Assembler King! He also wrote many 
books which were very educational!

Please be kind to send all of us condolences to Tineke.

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: Interesting - NODE for z/OS

[Jerry Callen]

You don't have to build from source; you can get a downloadable SDK:

https://www.ibm.com/us-en/marketplace/sdk-nodejs-compiler-zos

There is a DeveloperWorks forum for node.js on IBM platforms (including z/OS 
and Linux on Z):
 
https://www.ibm.com/developerworks/community/groups/service/html/communitystart?communityUuid=39f4d6be-d936-4a36-8fbf-874bf4bde113

-- Jerry

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

Interesting - NODE for z/OS

[John McKown]

I haven't really had a chance to look at this yet. But I thought others
here might be interested. It is NODE for z/OS. NODE is a "server side"
JavaScript engine. That is, it allows you to run JavaScript programs on
z/OS.

https://github.com/ibmruntimes/node/releases/tag/ibm-6.13.0.0

Source only, no executable.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: Dr. John Ehrman

[Jerry Callen]

I knew John from my involvement with SHARE assembler committee, and through 
work with IBM's Federal Systems Division in the 1980s. He was a true gentleman, 
always kind, very smart, and an absolute pleasure to work with. I was delighted 
to have been able to chat with him (for the first time in years) at SHARE in 
Providence last year. He seemed very at peace.

-- Jerry

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

Re: Data sets incorrectly cataloged to HSM MIGRAT2

[willie bunter]

Is the HSM cds shared among LPARS?  If so, check if there is an alias for these 
dsns on the LPAR which has the problem.  I had a similar problem.  

  From: Jesse 1 Robinson 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Tuesday, February 20, 2018 4:31 PM
 Subject: Data sets incorrectly cataloged to HSM MIGRAT2
   
We have situation where a lot of data sets are incorrectly cataloged to HSM 
MIGRAT2. For an individual case, I can try HDELETE. If I get the message that 
data set is not migrated, I can issue DEL NSCR.

However we have thousands of these. We can CSI list them by data set name 
pattern. I don't really want to DEL NSCR if a data set is actually migrated. 
Any suggestions for how to handle an enormous number of these?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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

   

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

Re: DASD problem

[Tommy Tsui]

After I switched the zhpf to No , the elapsed time reduce from 12 to 7
mins? How comes, is it the switch or director no support the concurrent i/o
from zhpf?

Tommy Tsui  於 2018年2月21日 星期三寫道：

> We use HDS instead not Ibm, we report this case to Ibm and perform the
> same operation on monoplex lpar the result is around 7mins write 28gb data
> using utility IEBDG, but use 12 mins while in sysplex lpar with same DASD,
> only can find is high disconnect time from RMF report
>
> Ron hawkins  於 2018年2月21日 星期三寫道：
>
>> Tommy,
>>
>> The RTD at 30km is quite small, and the benefit of write spoofing will be
>> small.
>>
>> There is an option to turn on write spoofing with the FCP PPRC links on
>> IBM storage, but you should check with them that it is a benefit at small
>> distances on your model of storage at all write rates.
>>
>> Ron
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Tommy Tsui
>> Sent: Tuesday, February 20, 2018 8:22 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: [IBM-MAIN] DASD problem
>>
>> Is there any way to improve the pprc command latency and round trip delay
>> time?
>> Anything can tune on DASD Hardware or switch side?
>> Anything can tune on os side? BUFNO,
>>
>> Rob Schramm  於 2018年2月21日 星期三寫道：
>>
>> > It used to be 20 or 25 buffers to establish the I/o sweet spot.  Maybe
>> > with the faster dasd the amount is different.
>> >
>> > Rob
>> >
>> > On Tue, Feb 20, 2018, 7:53 PM Tommy Tsui  wrote:
>> >
>> > > Hi Ron,
>> > > You are right when I changed BUFNO to 255,  The overall elapsed time
>> > > reduce from 12mins to 6 mins, So what can I do now,? Change BUFNO
>> > > only ? How about vsam or db2 performance?
>> > >
>> > >
>> > > Ron hawkins  於 2018年2月21日 星期三寫道：
>> > >
>> > > > Tommy,
>> > > >
>> > > > With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed
>> > > > are independent of one another, but the stepped down speed
>> > > > elongate the
>> > > Remote
>> > > > IO.
>> > > >
>> > > > In simple terms a block that you write from the host to the P-VOL
>> > > > takes 0.5ms to transfer on 16Gb FICON, and but then you do the
>> > > > synchronous
>> > > write
>> > > > on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to
>> > transfer.
>> > > > This time is in addition to command latency and round-trip delay
>> time.
>> > As
>> > > > described below, this impact will be less for long, chained writes
>> > > because
>> > > > of the Host/PPRC overlap.
>> > > >
>> > > > I'm not sure how you simulate this on your monoplex, but I assume
>> > > > you
>> > set
>> > > > up a PPRC pair to the remote site. If you are testing with BSAM or
>> > > > QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the single
>> > > > block
>> > impact.
>> > > If
>> > > > you are using zHPF, I think you can vary the BUFNO or NCP to get
>> > > > up to
>> > > 255
>> > > > chained blocks.
>> > > >
>> > > > I'm not aware of anything in GRS that adds to remote IO disconnect
>> > time.
>> > > >
>> > > > Ron
>> > > >
>> > > > -Original Message-
>> > > > From: IBM Mainframe Discussion List
>> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> > On
>> > > > Behalf Of Tommy Tsui
>> > > > Sent: Tuesday, February 20, 2018 2:42 AM
>> > > > To: IBM-MAIN@LISTSERV.UA.EDU
>> > > > Subject: Re: [IBM-MAIN] DASD problem
>> > > >
>> > > > Hi Ron,
>> > > > What happens to if our ficon card is 16gb, and fcp connection is
>> > > > 2gb, I try to do the simulation on monoplex  lpar , the result is
>> > > > fine, now we
>> > > are
>> > > > suspect the GRS or other system parm which will increase the
>> > > > disconnect
>> > > time
>> > > >
>> > > > Ron hawkins  於 2018年2月
>> > > >
>> > > > 15日 星期四寫道：
>> > > >
>> > > > > Tommy,
>> > > > >
>> > > > > This should not be a surprise. The name "Synchronous Remote Copy"
>> > > > > implies the overhead that you are seeing, namely the time for
>> > > > > the synchronous write to the remote site.
>> > > > >
>> > > > > PPRC will more than double the response time of random writes
>> > > > > because they the Host write to cache has the additional time of
>> > > > > controller latency, round trip delay, and block transfer before
>> > > > > the write is complete. On IBM and HDS (not sure with EMC) the
>> > > > > impact is greater
>> > for
>> > > > > single blocks, as chained sequential writes have some overlap
>> > > > > between the host write, and the synchronous write.
>> > > > >
>> > > > > Some things to check:
>> > > > >
>> > > > > 1) Buffer Credits on ISLs between the sites. If no ISLs then
>> > > > > settings on the storage host ports to cater for 30km B2B credits
>> > > > > 2) Channel speed step-down - If your FICON channels are 8Gb, and
>> > > > > the FCP connections are 2Gb, then PPRC writes will take up to
>> > > > > four times longer to transfer. It dep[ends on 

Problem moved to an outage by XCF recovery?

[Vernooij, Kees (ITOPT1) - KLM]

Hello Group,

Last week we had a problem which ended in a full Sysplex outage. 
After extensive searching, I think it was XCF recovery that moved the Sysplex 
to the total outage.

We run a 2 site Sysplex, with PPRC mirroring between the sites, with Primary 
Dasd in SITE1, with our main production LPARs at SITE1 and GDPS to monitor the 
sites.

Due to a 'mistake' all Ficon connections between the 2 sites were removed, but 
the InfiniBand connections remained active. So DASD mirroring was interrupted, 
but XCF communication remained working.  
This result unexpectedly in: all SITE1 LPARs down and all SITE2 LPARs full with 
unrecoverable problems.

After analyzing all logs, we think the following happened:
- After the last connection between the centers was removed, SITE1 LPARS still 
had access to the Primary Dasd and SITE2 LPARs lost access to the Primary Dasd. 
InfiniBand and XCF connections were not hit. There were several hang in 
applications, e.g. JES2 Checkpoint Locked etc., but nothing fatal yet.
- GDPS declared a FREEZE AND GO. This did not change much, SITE1 still had 
access to the Primary Dasd and SITE2 remained disconnected from the Primary 
Dasd.

But then:
- XCF on the SITE2 LPARs detected it lost access to the Primary CDSs and moved 
to the Alternate CDSs.
- XCF on the SITE1 LPARs were notified of the CDS switches but since they had 
no access to the new Primary CDSs, they all loaded a Waitstate 0A2, reason code 
010: XCF lost access to all couple data sets.
Now we ended up with a situation, where our main SITE1 LPARs which still had 
access to the Primary Dasd were brought down and the SITE2 LPARs without access 
to Dasd were left over.
The only thing remaining was to RESET all SITE2 LPARs and re-IPL the SITE1 
LPARs.

Evaluating this makes us conclude that:
- XCF helped the Sysplex into a total down, because of the SITE2 reaction on 
the loss of access to the Primary CDSs.
- In SFM we specify that our SITE1 LPARs have a much higher weight than the 
SITE2 LPARs, but XCF does not make an SFM analyses, but simply reacts directly 
to the CDS loss event.
- If the Primary CDSs were located in SITE2, the opposite would have happened: 
SITE1 lost the Primary CDSs (in SITE2), switched to the Alternates (in SITE1), 
which were inaccessible to SITE2 LPARs and they would then load a Waitstate 
0A2-010. 
This is the way we would have liked the situation was solved.

The GDPS manuals have some statements about the location of Primary and 
Alternate CDSs, but does not declare a hard recommendation, only a 'logical 
configuration'. 
However, in the GDPS CDS configuration panels, the NORMAL configuration defines 
the Primary CDSs at SITE1 and the Alternates at SITE2. We did not find how we 
can change this.
Furthermore, GDPS Monitor1 checks the CDS orientation and from Hyperswap tests 
we know that it complains with GEO2643W if we do not change the CDS orientation 
after Hyperswap.

Should it become a CDS configuration requirement to locate the Primary CDSs at 
the Secondary Dasd site and Alternate CDSs at the Primary Dasd site?
Did I overlook something?

Regards,
Kees.




For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

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


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

Re: DASD problem

[Tommy Tsui]

We use HDS instead not Ibm, we report this case to Ibm and perform the same
operation on monoplex lpar the result is around 7mins write 28gb data using
utility IEBDG, but use 12 mins while in sysplex lpar with same DASD, only
can find is high disconnect time from RMF report

Ron hawkins  於 2018年2月21日 星期三寫道：

> Tommy,
>
> The RTD at 30km is quite small, and the benefit of write spoofing will be
> small.
>
> There is an option to turn on write spoofing with the FCP PPRC links on
> IBM storage, but you should check with them that it is a benefit at small
> distances on your model of storage at all write rates.
>
> Ron
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tommy Tsui
> Sent: Tuesday, February 20, 2018 8:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] DASD problem
>
> Is there any way to improve the pprc command latency and round trip delay
> time?
> Anything can tune on DASD Hardware or switch side?
> Anything can tune on os side? BUFNO,
>
> Rob Schramm  於 2018年2月21日 星期三寫道：
>
> > It used to be 20 or 25 buffers to establish the I/o sweet spot.  Maybe
> > with the faster dasd the amount is different.
> >
> > Rob
> >
> > On Tue, Feb 20, 2018, 7:53 PM Tommy Tsui  wrote:
> >
> > > Hi Ron,
> > > You are right when I changed BUFNO to 255,  The overall elapsed time
> > > reduce from 12mins to 6 mins, So what can I do now,? Change BUFNO
> > > only ? How about vsam or db2 performance?
> > >
> > >
> > > Ron hawkins  於 2018年2月21日 星期三寫道：
> > >
> > > > Tommy,
> > > >
> > > > With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed
> > > > are independent of one another, but the stepped down speed
> > > > elongate the
> > > Remote
> > > > IO.
> > > >
> > > > In simple terms a block that you write from the host to the P-VOL
> > > > takes 0.5ms to transfer on 16Gb FICON, and but then you do the
> > > > synchronous
> > > write
> > > > on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to
> > transfer.
> > > > This time is in addition to command latency and round-trip delay
> time.
> > As
> > > > described below, this impact will be less for long, chained writes
> > > because
> > > > of the Host/PPRC overlap.
> > > >
> > > > I'm not sure how you simulate this on your monoplex, but I assume
> > > > you
> > set
> > > > up a PPRC pair to the remote site. If you are testing with BSAM or
> > > > QSAM (like OLDGENER), then set SYSUT2 BUFNO=1 to see the single
> > > > block
> > impact.
> > > If
> > > > you are using zHPF, I think you can vary the BUFNO or NCP to get
> > > > up to
> > > 255
> > > > chained blocks.
> > > >
> > > > I'm not aware of anything in GRS that adds to remote IO disconnect
> > time.
> > > >
> > > > Ron
> > > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On
> > > > Behalf Of Tommy Tsui
> > > > Sent: Tuesday, February 20, 2018 2:42 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: [IBM-MAIN] DASD problem
> > > >
> > > > Hi Ron,
> > > > What happens to if our ficon card is 16gb, and fcp connection is
> > > > 2gb, I try to do the simulation on monoplex  lpar , the result is
> > > > fine, now we
> > > are
> > > > suspect the GRS or other system parm which will increase the
> > > > disconnect
> > > time
> > > >
> > > > Ron hawkins  於 2018年2月
> > > >
> > > > 15日 星期四寫道：
> > > >
> > > > > Tommy,
> > > > >
> > > > > This should not be a surprise. The name "Synchronous Remote Copy"
> > > > > implies the overhead that you are seeing, namely the time for
> > > > > the synchronous write to the remote site.
> > > > >
> > > > > PPRC will more than double the response time of random writes
> > > > > because they the Host write to cache has the additional time of
> > > > > controller latency, round trip delay, and block transfer before
> > > > > the write is complete. On IBM and HDS (not sure with EMC) the
> > > > > impact is greater
> > for
> > > > > single blocks, as chained sequential writes have some overlap
> > > > > between the host write, and the synchronous write.
> > > > >
> > > > > Some things to check:
> > > > >
> > > > > 1) Buffer Credits on ISLs between the sites. If no ISLs then
> > > > > settings on the storage host ports to cater for 30km B2B credits
> > > > > 2) Channel speed step-down - If your FICON channels are 8Gb, and
> > > > > the FCP connections are 2Gb, then PPRC writes will take up to
> > > > > four times longer to transfer. It dep[ends on the block size.
> > > > > 3) Unbalanced ISLs - ISLs do not automatically rebalance after
> > > > > one
> > > drops.
> > > > > The more concurrent IO there is on an ISL, the longer the
> > > > > transfer time for each PPRC write. There may be one opr more ISL
> > > > > that are not being used, while others are overloaded
> > > > > 4) Switch board