Many IBM Announcements on October 2, 2018

[Timothy Sipples]

IBM has a lot of system-related announcements, and I'm providing a quick
summary below. Many are no additional charge, and at least a couple are
even better than that. If you'd like the full announcement letters they're
available here:

https://www.ibm.com/common/ssi/rep_ca/5/897/ENUS118-075/ENUS118-075.PDF
https://www.ibm.com/common/ssi/rep_ca/2/897/ENUS218-152/ENUS218-152.PDF
https://www.ibm.com/common/ssi/rep_ca/7/897/ENUS118-077/ENUS118-077.PDF
https://www.ibm.com/common/ssi/rep_ca/4/897/ENUS218-324/ENUS218-324.PDF
https://www.ibm.com/common/ssi/rep_ca/5/897/ENUS218-325/ENUS218-325.PDF

Highlights:

* Various improvements in the IBM Common Cryptographic Architecture (CCA)
and in the Trusted Key Entry (TKE) Workstation.

* New OSA-Express7S 25 Gigabit Ethernet (GbE) SR (one port) and 25 GbE RoCE
Express 2 (two port) adapters.

* zHyperLink Writes to accelerate Db2 for z/OS log writes.

* Various Hardware Management Console (HMC) enhancements.

* Parallel Sysplex-related improvements including dynamic activation of I/O
configurations for stand-alone Coupling Facilities, Asynchronous Cache
Cross-Invalidation (XI), and nondisruptive Server Time Protocol (STP)
Coordinated Time Network (CTN) split and merge.

* Enhancements to Dynamic Partition Manager (DPM) including master storage
templates, dynamic FICON reconfiguration support, and support for more
hardware adapters.

* For customers that order the 16U Reserved feature in IBM z14 ZR1 and IBM
Rockhopper II machines (which provides reserved rack mount space within the
machine frame for installation of practically any rack mountable
equipment), the ability to change their minds and delete that feature
if/when they need additional I/O drawers.

* New IBM Adapter for NVMe, FCP Express32S LX, and FCP Express32S SX
features for LinuxONE Emperor II and Rockhopper II machines. The FCP
Express32S adapters support 32 Gb/s Fibre Channel Protocol (FCP), while the
IBM Adapter for NVMe allows customers to install independently acquired
Solid-State Drives (SSDs) directly into the I/O subsystem. Please note that
these particular NVMe SSDs do not support initial program load (IPL), so
this form of storage is (for now anyway) to augment rather than to replace
other storage.

* IBM Secure Service Container for IBM Cloud Private, which runs Docker
container-ized workloads in an isolated, extremely secure environment.

* Solution Consumption License Charges (SCLC), providing pay-as-you-go
pricing for new z/OS-based workloads ("NewApps") based on actual
consumption, regardless of hourly peaks and spikes. SCLC is available on
IBM z13 servers and higher, and with z/OS 2.1 and higher (2.2 or higher if
you'd like to avoid LPAR separation of workloads). Qualifying SCLC products
include CICS TS Version 5.1 and higher, Db2 Version 11 and higher, IMS
Version 14 and higher, MQ Version 8 and higher, NetView Version 6 and
higher, and z/OS itself.

* Enhancements to the IBM Application Development and Test Solution, which
allows you to increase your current z/OS-based DevTest capacity up to
triple its current size with zero additional Monthly License Charges (MLC).

* Statements of Direction: (a) The next generation of machines will have
HMCs that can manage that generation of machines and two prior generations
(not four prior generations as is current practice), which will make it
easier for IBM to deliver more HMC features more quickly. Of course you'll
still be able to use previous model HMCs you already have if you need to
reach back to manage older generation machines ("N-3" and older). (b) At
some point the "System (Sysplex) Time" task will be removed from the
Support Element since the HMC now has the "Manage System Time" task. (c)
The z14 machines will be the last to support Ensembles and zManager.


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

AW: Re: S106 abends after copying into LINKLIST

[Peter Hunkeler]

>Are you sure space is reclaimed for deleted members if the data set is open by 
>LNKLST?


Interesting question. Easy to test for someone with a sandbox system (I don't 
have any such to play with). Well, one could test with STEPLIB but that does 
not tell anything, if there was special code in PDSE processing to recognize 
the data set is in linklist usage (I doubt there is, but who knows?)
I would assume that the space is reclaimed not matter whether the data set is 
open or not.


--
Peter Hunkeler



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

Re: Doing DR on zVM

[Mike Schwab]

Using z/VM at DR we had differences in login commands, and the site
has to set up conversions for your addresses in z/VM config.  After
that it looks very similar.  Unless you own the DR site, you aren't
going to get to configure the LPAR as you want.  The cpu costs should
be included in your contract.  Unless you restore all systems and do
all production, your cpu bill should be quite a bit less than running
production.
On Tue, Oct 2, 2018 at 11:28 PM Peter  wrote:
>
> Hi Experts,
>
> I would like to get your opinion on performing DR using zVM(z/OS guest)
> instead of using a Native LPARS running on z hardware.
>
> We are monoplex shop(just one production LPAR and one Sandbox) and does
> performing DR on zVM saves any cost in terms of licensing ?
>
> Peter
>
> --
> 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

Doing DR on zVM

[Peter]

Hi Experts,

I would like to get your opinion on performing DR using zVM(z/OS guest)
instead of using a Native LPARS running on z hardware.

We are monoplex shop(just one production LPAR and one Sandbox) and does
performing DR on zVM saves any cost in terms of licensing ?

Peter

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

Re: S106 abends after copying into LINKLIST

[Ed Jaffe]

On 10/2/2018 12:32 PM, Carmen Vitullo wrote:

Got me, I've never had an issue with a PDS/E in the linklist, PDS/E's for me 
solved some issues with directory block allocation and having the ability to 
reuse space, when a member is deleted/modified or added


Are you sure space is reclaimed for deleted members if the data set is 
open by LNKLST?


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: S106 abends after copying into LINKLIST

[Ed Jaffe]

On 10/2/2018 8:43 AM, Seymour J Metz wrote:

I prefer to avoid the problem by never updating a live linklist library.


NEVER is a strong word. Too strong for the dynamic modern world, IMHO.

If there is some sort of *major* error that needs fixing NOW, then we 
will receive the fix and -- if it has no IPL hold -- stop LLA, apply the 
fix, bring LLA back up, and perform any documented DYNACT restart. 
Problem solved. No downtime whatsoever...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: S106 abends after copying into LINKLIST

[Carmen Vitullo]

Got me, I've never had an issue with a PDS/E in the linklist, PDS/E's for me 
solved some issues with directory block allocation and having the ability to 
reuse space, when a member is deleted/modified or added 



Carmen Vitullo 

- Original Message -

From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, October 2, 2018 2:01:27 PM 
Subject: Re: S106 abends after copying into LINKLIST 

On Tue, 2 Oct 2018 13:28:27 -0400, Carmen Vitullo wrote: 

>absolutely agree, my link list lib's are not SMS manged, but I'm the z/OS guy, 
>some on the team are not sysprogs and allocate based on the vendor doc and my 
>storage guy, likes to mis I mean manage everything, and they get burnt :( 
>I just recently forwarded a health check issue to a teammate, her PDS was 
>allocated with secondary space , SOMETIME THE VENDOR SUPPLIED in their 
>allocation JCL, she got burnt because she compressed the library without 
>knowing really what to do or without asking what to do first. 
> 
Aren't these problems of the sort that PDSE was invented to solve? Indexed 
directories 
facilitate searcn. LUW isolation facilitates live update and compress neither 
needed 
nor supported? 

What went wrong? 

-- 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: S106 abends after copying into LINKLIST

[Paul Gilmartin]

On Tue, 2 Oct 2018 13:28:27 -0400, Carmen Vitullo wrote:

>absolutely agree, my link list lib's are not SMS manged, but I'm the z/OS guy, 
>some on the team are not sysprogs and allocate based on the vendor doc and my 
>storage guy, likes to mis I mean manage everything, and they get burnt :(
>I just recently forwarded a health check issue to a teammate, her PDS was 
>allocated with secondary space , SOMETIME THE VENDOR SUPPLIED in their 
>allocation JCL, she got burnt because she compressed the library without 
>knowing really what to do or without asking what to do first.
> 
Aren't these problems of the sort that PDSE was invented to solve?  Indexed 
directories
facilitate searcn.  LUW isolation  facilitates live update and compress neither 
needed
nor supported?

What went wrong?

-- gil

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

Re: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

[Paul Gilmartin]

On Tue, 2 Oct 2018 17:35:54 +, Pew, Curtis G wrote:

>On Oct 2, 2018, at 12:27 PM, Richards, Robert B. wrote:
>> 
>> Unbiased? Not sure what you mean. 
>
>I think his point was that downloading a .exe file is pretty useless if you’re 
>not on a Windows machine. As someone who rarely uses Windows, I tend to cringe 
>when I see a .exe file offered for download.
>
>For what it’s worth, I was able to download the .zip version and open it on my 
>Mac, and then mount the .iso file it contained, without any problems.
> 
Why not a plain ol' .zip?  The greater the variety of nested envelopes, the 
greater
the chance of introducing an obstacle on any given system.  Almost any desktop
can handle .zip, and on z/OS "jar" handles it (unless it's 7-zip peculiar).

.iso?  OK for Mac and Linux.  Windows vacillates.  Some releases honor it; 
others
have it hidden, or not at all.  We used Virtual Clone drive for it.

Our Software Manufacturing and Distribution department used to do OK creating
CDs when I gave them .iso files.  Save once, when they created a CD containing
a .iso file.

-- gil

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

Re: ICSF crypto domain sharing

[Frank Swarbrick]

We're sharing keys between dev and sandbox, not dev and prod.

Thanks for the info!

Frank

From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Sunday, September 30, 2018 12:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ICSF crypto domain sharing

Frank,
You did your job by entering same master keys. Now, different domain are
"compatible" - then can share CKDS/PKDS.
You wanted to share domain, which is impossible (and that's good IMHO).

Of course there another story behind,: should one share crypto between
prod and dev?
We just answered how it's possible, not is it recommended.

Regards

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-09-28 o 20:34, Frank Swarbrick pisze:
> Let me explain a bit more what I was trying to ask.  We have 3 LPARs 
> (production, dev/test, sandbox) on the same CPC.  Sandbox up to this point 
> did not have master keys loaded.  We quickly needed to load some, so I 
> recommended we use the same keys as dev/test.  I had hoped that we could have 
> Sandbox use the same crypto domain as dev/test; thus the question.  I ended 
> up just loading the same keys, rather than attempting to "share" the same 
> domain.  But I still wondered if the latter could be done.  It sounds like 
> you are saying no.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> R.S. 
> Sent: Friday, September 28, 2018 8:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ICSF crypto domain sharing
>
> W dniu 2018-09-28 o 12:54, Jousma, David pisze:
>> Yes, they can be shared.   Our PROD lpars are all on the same domain.
> IMHO no, domains cannot be shared.
> Maybe your prod LPARs reside on different CPC each?
>
> Some remarks:
> 1. Single LPAR can have more than one domain, but z/OS ICSF can use only
> one at a time. However you can change domain number in PARMLIB and
> recycle ICSF.
>
> 2. Domain number cannot be assigned to more than one active LPAR.
> Deactivated LPARs could share domain id.
>
> 3. In the old days it was possible to have i.e. 40 LPARs and number of
> domains was 16. In that case More crypto engines were needed, for
> example Crypto 1 and 3 were assigned to LPARs 01-0F, Crypto engines 2
> and 4 were assigned to LPARs 10-1F and remaining LPARs had no access to
> Crypto engines (CPACF is not affected). In that case LPAR 01 and LPAR 11
> may have Domain Id 2 assigned, but on separated Crypto engines.
>
> 4. It is impossible to have i.e. Domain 12 on Crypto1 and Domain 07 on
> Crypto2 at a time.
>
> 5. It is also possible to have the same master keys on different domains
> (and even different CPCs) - in that case, CKDS/PKDS can be shared/copied
> between that systems.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub 
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może 
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia 
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza 
> prawo i może podlegać karze.
>
> 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, KRS 025237, 
> NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
> 01.01.2018 r. wynosi 169.248.488 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have 
> printed out or saved).
> This message may contain legally protected information, which may be used 
> exclusively by the addressee.Please be reminded that anyone who disseminates 
> (copies, distributes) this message or takes any similar action, violates the 
> law and may be penalised.
>


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

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, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this 

Re: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

[Richards, Robert B.]

Curtis,

Thanks for the enlightenment! 

My original and subsequent emails were dealing entirely with the Winzip link. 
As you have pointed out, there was also a link for an .iso file that apparently 
has worked fine from the jump. A visit to the SHARE site would have revealed 
that. 

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Tuesday, October 02, 2018 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

On Oct 2, 2018, at 12:27 PM, Richards, Robert B. 
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Unbiased? Not sure what you mean. 

I think his point was that downloading a .exe file is pretty useless if you’re 
not on a Windows machine. As someone who rarely uses Windows, I tend to cringe 
when I see a .exe file offered for download.

For what it’s worth, I was able to download the .zip version and open it on my 
Mac, and then mount the .iso file it contained, without any problems.


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


--
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: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

[Pew, Curtis G]

On Oct 2, 2018, at 12:27 PM, Richards, Robert B. 
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Unbiased? Not sure what you mean. 

I think his point was that downloading a .exe file is pretty useless if you’re 
not on a Windows machine. As someone who rarely uses Windows, I tend to cringe 
when I see a .exe file offered for download.

For what it’s worth, I was able to download the .zip version and open it on my 
Mac, and then mount the .iso file it contained, without any problems.


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: S106 abends after copying into LINKLIST

[Carmen Vitullo]

absolutely agree, my link list lib's are not SMS manged, but I'm the z/OS guy, 
some on the team are not sysprogs and allocate based on the vendor doc and my 
storage guy, likes to mis I mean manage everything, and they get burnt :( 
I just recently forwarded a health check issue to a teammate, her PDS was 
allocated with secondary space , SOMETIME THE VENDOR SUPPLIED in their 
allocation JCL, she got burnt because she compressed the library without 
knowing really what to do or without asking what to do first. 



Carmen Vitullo 

- Original Message -

From: "Steve Beaver"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, October 2, 2018 12:15:21 PM 
Subject: Re: S106 abends after copying into LINKLIST 

Never, ever let your LINKLST go into secondary's. Otherwise you will quickly 
learn how to 
Update your LNKLST dynamically. And never put your LNKLST datasets in SMS 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin 
Sent: Tuesday, October 2, 2018 12:10 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: S106 abends after copying into LINKLIST 

On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote: 

>Alas, your allocation can still get another extent, but I'd prefer that nobody 
>explain how; 
>somebody might think that it was a good idea and cause the obvious problems. 
> 
Since I don't encourage integrity by obscurity, I'll ask the question that 
occurs to me. 
Can an overriding SPACE option in a DD statement allow allocation of a 
secondary 
extent to a data set initially allocated with zero secondary? 

> 
>From: I Carmen Vitullo 
>Sent: Monday, October 1, 2018 11:55 AM 
> 
>There's the key, in the allocation, if I allocate space for a linklist library 
>I DO NOT specify any secondary allocation, zero zilch! a secondary extend can 
>be taken to get my primary space if needed, but my PDS cannot get another 
>extend due to my initial allocation of 100,0 for example , SMS or not, (as 
>long as an SMS dataclass is not getting me in trouble) 

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


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

Re: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

[Richards, Robert B.]

Gil,

Proceedings are primarily relevant to z/OS and Linux on Z.

Unbiased? Not sure what you mean. 

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, October 02, 2018 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

On Tue, 2 Oct 2018 17:05:19 +, Richards, Robert B. wrote:

>Just wanted to let all of you know that the issue has been resolved.
>
>Instead of downloading a zip file, you now download an .exe file. That file 
>works great.
>
z/OS?  Linux?  MacOS?  Solaris?

>Thanks to the SHARE folks for their prompt response.
> 
If it's unbiased.  

-- 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: S106 abends after copying into LINKLIST

[Carmen Vitullo]

I do also, every place has their own process and if it's a standard practice 
that works, that's great. 
I've worked at places that did as you, update live link listed libraries on a 
Friday afternoon before a scheduled IPL, crossing their fingers an in prompt-u 
IPL is not done before, or, oh well, my changes are in :) 
I've been in client sites that will not allow you to Stage changes prior to 
your downtime, this controlled by a change managment monitoring tool, if you do 
make a change beforehand, you're toast. 
I've been at site that control changes by keeping 2 sets of SMP/E target 
environments, and you flip from one to the other, this is done for CICS and DB2 
and MQ and.. 
this strategy worked best IMHO but a lot of folks don't like the thought of 
managing 2 target environments. so I think this time you (team) got burnt. tons 
of explanation here on how PDS's allocation should be done and what happens 
when a PDS is emptied/reloaded or compressed without an LLA refresh, all good 
stuff, I'll continue what works for me and NOT allocation secondary space for a 
link listed library and ensure my primary space is adequate for the install + 
maint, if possible. 
my .2 cents 




Carmen Vitullo 

- Original Message -

From: "Eileen Barkow"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, October 2, 2018 10:42:25 AM 
Subject: Re: S106 abends after copying into LINKLIST 

I agree that this maintenance strategy is no good but the MVS group does not 
want to have to change parmlib for new maintenance, so 
We now have to do the updates right before an IPL - usually about 4am on Sunday 
mornings. 
We used to at least keep separate linklist/lpa datasets for different releases 
of CICS - now the same datasets get overlaid for new releases as well as 
maintenance. 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz 
Sent: Tuesday, October 02, 2018 11:29 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: S106 abends after copying into LINKLIST 

> Perhaps someone can offer a plausible explanation for this, so that 
> the MVS group will stop blaming the CICS group for the problem. 

An explanation will not stop the MVS group from blaming the CICS group for a 
problem caused by the CICS group. Your current maintenance strategy is 
dangerous and is the cause of the problem. 


-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen  
Sent: Monday, October 1, 2018 10:09 AM 
To: IBM-MAIN@listserv.ua.edu 
Subject: S106 abends after copying into LINKLIST 

Hi MVS gurus. 
Perhaps someone can offer a plausible explanation for this, so that 
the MVS group will stop blaming the CICS group for the problem. 

Last friday morning we copied new CICS LINKLIST/LPA modules into the existing 
LINKLIST/LPA loadlibs 
in use (a rather new scenario in use here - we used to use alternative 
datasets), in anticipation of an IPL to 
be done sunday morning. 
anyway, around 6pm friday evening, an I/O error occured in linklist and other 
jobs started abending with S106 abends. 
the linklist library was not allocated with secondary extents and there was no 
LLA refresh issued during 
the day. I cannot find anything like this situation occurring on IBMLINK and we 
have no dump of the original failure. 

Does anyone have any idea of what could have caused the I/O error. 
both the input and output datasets have a max blksize of 32760. 

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE 
OF AN I/O ERROR. 
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE 
IEWFETCH ISSUED RC 0F AND REASON 40 
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24, 
REASON CODE 26080021, DDNAME *LNKLST* 





 

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 

-- 
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: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

[Paul Gilmartin]

On Tue, 2 Oct 2018 17:05:19 +, Richards, Robert B. wrote:

>Just wanted to let all of you know that the issue has been resolved.
>
>Instead of downloading a zip file, you now download an .exe file. That file 
>works great.
>
z/OS?  Linux?  MacOS?  Solaris?

>Thanks to the SHARE folks for their prompt response.
> 
If it's unbiased.  

-- gil

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

Re: S106 abends after copying into LINKLIST

[Steve Beaver]

Never, ever let your LINKLST go into secondary's.  Otherwise you will quickly 
learn how to 
Update your LNKLST dynamically.  And never put your LNKLST datasets in SMS

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, October 2, 2018 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote:

>Alas, your allocation can still get another extent, but I'd prefer that nobody 
>explain how;
>somebody might think that it was a good idea and cause the obvious problems.
>
Since I don't encourage integrity by obscurity, I'll ask the question that 
occurs to me.
Can an overriding SPACE option in a DD statement allow allocation of a secondary
extent to a data set initially allocated with zero secondary?

>
>From: I Carmen Vitullo
>Sent: Monday, October 1, 2018 11:55 AM
>
>There's the key, in the allocation, if I allocate space for a linklist library 
>I DO NOT specify any secondary allocation, zero zilch! a secondary extend can 
>be taken to get my primary space if needed, but my PDS cannot get another 
>extend due to my initial allocation of 100,0 for example , SMS or not, (as 
>long as an SMS dataclass is not getting me in trouble)

-- 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: S106 abends after copying into LINKLIST

[Paul Gilmartin]

On Tue, 2 Oct 2018 15:34:44 +, Seymour J Metz wrote:

>Alas, your allocation can still get another extent, but I'd prefer that nobody 
>explain how;
>somebody might think that it was a good idea and cause the obvious problems.
>
Since I don't encourage integrity by obscurity, I'll ask the question that 
occurs to me.
Can an overriding SPACE option in a DD statement allow allocation of a secondary
extent to a data set initially allocated with zero secondary?

>
>From: I Carmen Vitullo
>Sent: Monday, October 1, 2018 11:55 AM
>
>There's the key, in the allocation, if I allocate space for a linklist library 
>I DO NOT specify any secondary allocation, zero zilch! a secondary extend can 
>be taken to get my primary space if needed, but my PDS cannot get another 
>extend due to my initial allocation of 100,0 for example , SMS or not, (as 
>long as an SMS dataclass is not getting me in trouble)

-- gil

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

Re: SHARE St.Louis 2018 Proceedings Extraction Error - Solved!

[Richards, Robert B.]

Just wanted to let all of you know that the issue has been resolved.

Instead of downloading a zip file, you now download an .exe file. That file 
works great. Thanks to the SHARE folks for their prompt response.

Bob

From: Richards, Robert B.
Sent: Tuesday, October 02, 2018 7:20 AM
To: 'IBM Mainframe Discussion List'
Cc: SHARE HQ (shar...@share.org)
Subject: SHARE St.Louis 2018 Proceedings Extraction Error

I downloaded the self-extracting zip file, Proceedings.7z, and got the 
following error when it attempts to populate the abstracts folder:

Extracting abstracts   OK
Extracting css   OK
Extracting css\bootstrap   OK
Extracting css\bootstrap\css  OK
Extracting css\bootstrap\img  OK
Extracting css\bootstrap\js   OK
Extracting data  OK
Extracting files OK
Extracting img   OK
Extracting jsOK
Extracting lib   OK
Extracting lib\angular OK
Extracting partials OK
Extracting xml   OK
Extracting abstracts\32437.html   Unknown compression method

Anyone else experience this issue?

As far as I can tell, I had zero issues downloading the 1.7GB zip file.

Bob

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

Re: S106 abends after copying into LINKLIST

[Paul Gilmartin]

On Tue, 2 Oct 2018 09:01:02 -0400, John Eells wrote:
>
>*I expect most people to move to thin provisioned volumes over time
>because the business case is compelling.  On TP volumes, there is no
>reason not to use very large primary extents, which can obviate any
>advantage to secondary space allocation for system software volumes.
>"Just let the disk controller manage the actual real estate" is my (new)
>recommendation for system software volumes.
>
Does TP reclaim space from deleted members?

But I hope not while connections to those members persist?

Does any of this apply to program objects and other files in zFS?

-- gil

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

Re: S106 abends after copying into LINKLIST

[Barkow, Eileen]

I was not involved with this strategy and I do not want to point any fingers, 
but it was developed with the assistance of the MVS group.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, October 02, 2018 11:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Because otherwise you risk an S106. A better question is why you didn't consult 
with the MVS group and devise a bulletproof maintenance strategy.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Monday, October 1, 2018 10:21 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

The  whole idea was not to have to refresh LLA - we wanted to wait until the 
IPL.
Why should LLA have to be refreshed if we did not want the changes to take 
effect?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<
ebar...@doitt.nyc.gov>:

> Hi MVS gurus.
>  Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.
>
> Last friday morning we copied new CICS LINKLIST/LPA modules into the
> existing LINKLIST/LPA loadlibs
> in use (a rather new scenario in use here - we used to use alternative
> datasets), in anticipation of an IPL to
> be done sunday morning.
> anyway, around 6pm friday evening, an I/O error occured in linklist and
> other jobs started abending with S106 abends.
> the linklist library was not allocated with secondary extents and there
> was no LLA refresh issued during
> the day. I cannot find anything like this situation occurring on IBMLINK
> and we have no dump of the original failure.
>
> Does anyone have any idea of what could have caused the I/O error.
> both the input and output datasets have a max blksize of 32760.
>
> IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
> OF AN I/O ERROR.
> IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
> IEWFETCH ISSUED RC 0F AND REASON 40
> CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
> REASON CODE 26080021, DDNAME *LNKLST*
>
>
>
>
>
>   
>
> 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
>

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

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

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

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

Re: S106 abends after copying into LINKLIST

[Seymour J Metz]

I prefer to avoid the problem by never updating a live linklist library.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Ed 
Jaffe 
Sent: Tuesday, October 2, 2018 2:33 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:
> There are two separate problems here. (1) A link list library taking a new 
> extent after IPL. (2) An LLA-managed library having contents moved by either 
> compress or reload.
>
> (1) Can be avoided by simply not defining any secondary extent, i.e. 
> specifying a secondary of zero. Getting more than one extent to satisfy the 
> original allocation is not a problem as long as no additional extent is 
> allowed afterward. If a new extent is truly needed to hold enlarged content, 
> then link list update can be used.
>
> (2) Seems to be OP's issue. LLA REFRESH can handle the consequences of 
> dynamic update within the original (IPL time) extent(s). Note that REFRESH is 
> needed on all sharing systems.

I never liked defining secondary of zero. I realize it's IBM's recommendation, 
but it all but ensures a compress will be performed when the library fills up. 
I've had systems crash either during or after such a compress -- sometimes with 
disastrous consequences!

I would much rather take a new extent for one relinked module than risk 
corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR. Of 
course, periodic compress of LNKLST PDS libraries is not a bad idea when done 
under controlled circumstances: i.e., "quiet" time and LLA on all sharing 
systems has been shut DOWN. Also, I like to STEPLIB any IEBCOPY job to a recent 
*copy* of SYS1.LINKLIB to ensure IEBCOPY program parts are not moved during the 
compress... BTDTGTS!!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1q8GhGGjGwO5ssJJgtG_tT5WKJ_rYH8AUo2gsNSG8zHaWD8GRoN3t5cTibn5HAkwdZERfkLyrabLgeVrt9KBZCPT2SrOjk9ep2Hf2eQWbMWvftOuZ2ERmcHXpcAZ52N4fT0y0iizIs0dcaFmdLk6hAk_QRtJQO2-qDrVtaJEhhu13sZUCvmibSV7W6gjvtr4ceCEduqBgWlTBHwP115SaVENlRqaafahiX4TxFWBqbj6mVb2TAZiUZr5NuZqsxrAG0VVuAm0a0ceXJr4YXBxBuebUVMwd2a7NxyMj7c8qsD0iBH9mXpgyQYb6cCn5hy8whtD_gAqVkIGTVbteWe13MRs6L-dCer4i-W23-BA-XQXNkc-hI5nAlGrxSPUdTQa9qFBP1Ry-LavSEX56ptGDNovjGGZdoJlKJjPGgcEKHMOn8TKuyXI3BdlZ0P4JIGPt/https%3A%2F%2Fwww.phoenixsoftware.com%2F



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
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: S106 abends after copying into LINKLIST

[Barkow, Eileen]

I agree that this maintenance strategy is no good but the MVS group does not 
want to have to change parmlib for new maintenance, so
We now have to do the updates right  before an IPL - usually about 4am on 
Sunday mornings.
We used to at least keep separate linklist/lpa datasets for different releases 
of CICS - now the same datasets get overlaid for new releases as well as  
maintenance.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, October 02, 2018 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

> Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.

An explanation will not stop the MVS group from blaming the CICS group for a 
problem caused by the CICS group. Your current maintenance strategy is 
dangerous and is the cause of the problem.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Monday, October 1, 2018 10:09 AM
To: IBM-MAIN@listserv.ua.edu
Subject: S106 abends after copying into LINKLIST

Hi MVS gurus.
 Perhaps someone can offer a plausible explanation for this, so that
the MVS group will stop blaming the CICS group for the problem.

Last friday morning we copied new CICS LINKLIST/LPA modules into the existing 
LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative 
datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other 
jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no 
LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK and we 
have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*





  

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

--
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: S106 abends after copying into LINKLIST

[Seymour J Metz]

Why bother emptying the members if you're not doing a compress? Also, it sounds 
like you have installation programs in a system library, which is always cause 
for concern.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Monday, October 1, 2018 10:33 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

The dataset is a standard  pds (CICS SDFHLINK).
We used some sort of SAS proc/clists to empty out the members before copying 
the new ones in -
I am not sure what this proc does since someone else set it up -
but it does not appear to have compressed the dataset - just emptied out the 
members.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Massimo Biancucci
Sent: Monday, October 01, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

Hi,

only to better understand.

Is the loadlib a standard PDS ? Was it compressed ?

Is the loadlib a PDSE ? This could better explain the incident.

Best regards.
Max

Il giorno lun 1 ott 2018 alle ore 16:10 Barkow, Eileen <
ebar...@doitt.nyc.gov> ha scritto:

> Hi MVS gurus.
>  Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.
>
> Last friday morning we copied new CICS LINKLIST/LPA modules into the
> existing LINKLIST/LPA loadlibs
> in use (a rather new scenario in use here - we used to use alternative
> datasets), in anticipation of an IPL to
> be done sunday morning.
> anyway, around 6pm friday evening, an I/O error occured in linklist and
> other jobs started abending with S106 abends.
> the linklist library was not allocated with secondary extents and there
> was no LLA refresh issued during
> the day. I cannot find anything like this situation occurring on IBMLINK
> and we have no dump of the original failure.
>
> Does anyone have any idea of what could have caused the I/O error.
> both the input and output datasets have a max blksize of 32760.
>
> IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
> OF AN I/O ERROR.
> IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
> IEWFETCH ISSUED RC 0F AND REASON 40
> CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
> REASON CODE 26080021, DDNAME *LNKLST*
>
>
>
>
>
>   
>
> 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
>

--
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: S106 abends after copying into LINKLIST

[Seymour J Metz]

Alas, your allocation can still get another extent, but I'd prefer that nobody 
explain how; somebody might think that it was a good idea and cause the obvious 
problems.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Monday, October 1, 2018 11:55 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

There's the key, in the allocation, if I allocate space for a linklist library 
I DO NOT specify any secondary allocation, zero zilch! a secondary extend can 
be taken to get my primary space if needed, but my PDS cannot get another 
extend due to my initial allocation of 100,0 for example , SMS or not, (as long 
as an SMS dataclass is not getting me in trouble)



Carmen Vitullo

- Original Message -

From: "Michael Babcock" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, October 1, 2018 10:49:48 AM
Subject: Re: S106 abends after copying into LINKLIST

Secondary space and multiple extents are really two different things.
Initial primary space for a PDS can be allocated in up 5 extents (SMS may
change that though).

Secondary space (if defined) may add additional extents.

On Mon, Oct 1, 2018 at 10:33 AM Blake, Daniel J [CTR] <
00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote:

> Very interesting conversation. Kind of related, like a third cousin is
> what I found:
>
> ,SDSF OUTPUT DISPLAY CSV_LNKLST_SPACE LINE 0 COLUMNS
> ,COMMAND INPUT ===>, ,SCROLL ==
> * TOP OF DATA **
> CHECK(IBMCSV,CSV_LNKLST_SPACE)
> SYSPLEX:  SYSTEM: 
> START TIME: 10/01/2018 02:11:10.736219
> CHECK DATE: 20050720 CHECK SEVERITY: LOW
>
> CSVH0983I None of the data sets in LNKLST set LNKLST00 were allocated
> with secondary space defined.
>
> END TIME: 10/01/2018 02:11:11.449077 STATUS: SUCCESSFUL
>
>
> Looks great right? Unless you allocated a data set on a volume that does
> not have enough contiguous space. I that case you get this:
>
>
> SDSF LNK DISPLAY SYS1 SYS1 EXT 92 LINE 1-37 (91)
> COMMAND INPUT ===>, ,SCROLL
> ===>,CSR ,
> PREFIX=* DEST=(ALL) OWNER=* SORT=EXTENT/D SYSNAME=
> NP DSNAME Seq VolSer
> BlkSize Extent SMS APF LRecL
> SYS2.BMC.DB2BMCLINK 66 ISVM06 23476
> 2 NO YES 0 PO
> SYS2.GENER.LOAD 1 ISVM06
> 32760 1 NO NO 0 PO
>
>
> Dan
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barkow, Eileen
> Sent: Monday, October 01, 2018 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
>
> Thanks Lizette.
>
> The dataset is was emptied/copied in a different lpar than where it is
> used.
> But as was explained, the pds directory got altered by the empty member
> procedure and no LLA REFRESH was done.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Monday, October 01, 2018 10:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
>
> What the Dataset where the modules were staged shared among Plexes or are
> just
> allocated to one Plex (but shared among any members in that Plex)
>
> PDS/E datasets can be very touchy.
>
> Did you find an S213 abends on the libraries prior to the S106?
>
> Check the first module indicated in the first S106. Did it have an I/O
> errors
> when you browse it?
>
> Can you do an IEBCOPY of the PDS to a new one and see if IEBCOPY shows any
> I/O
> Errors
>
> Can you do a IEBPDSE Copy of the PDS/E to a new one and see if there are
> any I/O
> errors?
>
>
> https://secure-web.cisco.com/1wgF6g5gRw23P6g1rdufxDSxXTAzKlL0zoyYXNAXE-gwoYq_AybtuEaBCljakDCmPFvyAb1i2KnxT9z3jkF1ocSdsIAwFtCAjB6aTZ3-DLC3_88ZHo3zbLSd2NHWiqgYMrQTNRd__VJZ5rP8SYeuNPzGtkeQJ3KCWls9a3HFD6WXkk671HhMz6gLolqQEMrHD_NxNnwH1d6amRJa-dRDFawLh3zmjLH-XAM-zGisRXFvVKzC2wMIxLdL3slwBOWpydR9aR1yA2cSmJirLYaAZ5AeUliYkLOVeT_IZZzv51UqZo9lX8oa_8ZU43oD5MgpXAjnd1YVyTYwctDN4i9HjwavUw9myijsC6_bQn35rBHsAAQpkXYwrF8c2dLGp-nRWB_vF3syaiLC9-F-5HDCYDKhIXjQtk9fgKjOJmGiuMAIWc3Vk904gpbvCb7KQhaGj/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.ida
> u100/pdse.htm
> 
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > Barkow, 

Re: S106 abends after copying into LINKLIST

[Seymour J Metz]

Because otherwise you risk an S106. A better question is why you didn't consult 
with the MVS group and devise a bulletproof maintenance strategy.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Monday, October 1, 2018 10:21 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: S106 abends after copying into LINKLIST

The  whole idea was not to have to refresh LLA - we wanted to wait until the 
IPL.
Why should LLA have to be refreshed if we did not want the changes to take 
effect?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Monday, October 01, 2018 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You need to refresh lla.

בתאריך יום ב׳, 1 באוק׳ 2018, 16:10, מאת Barkow, Eileen ‏<
ebar...@doitt.nyc.gov>:

> Hi MVS gurus.
>  Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.
>
> Last friday morning we copied new CICS LINKLIST/LPA modules into the
> existing LINKLIST/LPA loadlibs
> in use (a rather new scenario in use here - we used to use alternative
> datasets), in anticipation of an IPL to
> be done sunday morning.
> anyway, around 6pm friday evening, an I/O error occured in linklist and
> other jobs started abending with S106 abends.
> the linklist library was not allocated with secondary extents and there
> was no LLA refresh issued during
> the day. I cannot find anything like this situation occurring on IBMLINK
> and we have no dump of the original failure.
>
> Does anyone have any idea of what could have caused the I/O error.
> both the input and output datasets have a max blksize of 32760.
>
> IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
> OF AN I/O ERROR.
> IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
> IEWFETCH ISSUED RC 0F AND REASON 40
> CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
> REASON CODE 26080021, DDNAME *LNKLST*
>
>
>
>
>
>   
>
> 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
>

--
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: S106 abends after copying into LINKLIST

[Seymour J Metz]

> Perhaps someone can offer a plausible explanation for this, so that
> the MVS group will stop blaming the CICS group for the problem.

An explanation will not stop the MVS group from blaming the CICS group for a 
problem caused by the CICS group. Your current maintenance strategy is 
dangerous and is the cause of the problem.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Barkow, Eileen 
Sent: Monday, October 1, 2018 10:09 AM
To: IBM-MAIN@listserv.ua.edu
Subject: S106 abends after copying into LINKLIST

Hi MVS gurus.
 Perhaps someone can offer a plausible explanation for this, so that
the MVS group will stop blaming the CICS group for the problem.

Last friday morning we copied new CICS LINKLIST/LPA modules into the existing 
LINKLIST/LPA loadlibs
in use (a rather new scenario in use here - we used to use alternative 
datasets), in anticipation of an IPL to
be done sunday morning.
anyway, around 6pm friday evening, an I/O error occured in linklist and other 
jobs started abending with S106 abends.
the linklist library was not allocated with secondary extents and there was no 
LLA refresh issued during
the day. I cannot find anything like this situation occurring on IBMLINK and we 
have no dump of the original failure.

Does anyone have any idea of what could have caused the I/O error.
both the input and output datasets have a max blksize of 32760.

IEW4009I FETCH FAILED FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- BECAUSE
OF AN I/O ERROR.
IEW4005I FETCH FOR MODULE DFHXCPRX FROM DDNAME -LNKLST- FAILED BECAUSE
IEWFETCH ISSUED RC 0F AND REASON 40
CSV031I LIBRARY ACCESS FAILED FOR MODULE DFHXCPRX, RETURN CODE 24,
REASON CODE 26080021, DDNAME *LNKLST*





  

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

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

Re: S106 abends after copying into LINKLIST

[John Eells]

John Eells wrote:

exceeding the link list extent limit the topic of this thread


That should read, "...exceeding the link list extent limit *and* the 
topic of this thread"


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: S106 abends after copying into LINKLIST

[John Eells]

Ed Jaffe wrote:

I never liked defining secondary of zero. I realize it's IBM's 
recommendation, but it all but ensures a compress will be performed when 
the library fills up. I've had systems crash either during or after such 
a compress -- sometimes with disastrous consequences!



Whether it's "IBM's" recommendation depends on who you talk to (smile). 
I believe Peter and I have disagreed about this for about 25 years.


There are two possible problems when using secondary extents for link 
list data saets, exceeding the link list extent limit the topic of this 
thread, everyone's favorite ABEND106-F RC40.  If your link list is not 
especially long, hitting the 255 limit will probably not happen; you can 
count extents before IPL after putting on PTFs and if necessary compress 
or reallocate.  In the meantime, you will have many fewer x37 abends 
while putting on PTFs.  This should be an informed choice, in my view, 
rather than a blanket recommendation.  But see below.*


If you don't update running systems, the second problem will never occur.

Likewise, whether it's IBM's recommendation to never update a copy of 
system software that is in use depends on who you talk to and whether 
DYNACT is specified for a particular PTF.  Here there be tygers, and my 
recommendation is never to do that unless you clearly and thoroughly 
scope out the probable result first and are prepared to IPL if you miss 
something (which is easy to do) and the change goes pear-shaped.


*I expect most people to move to thin provisioned volumes over time 
because the business case is compelling.  On TP volumes, there is no 
reason not to use very large primary extents, which can obviate any 
advantage to secondary space allocation for system software volumes. 
"Just let the disk controller manage the actual real estate" is my (new) 
recommendation for system software volumes.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: S106 abends after copying into LINKLIST

[Allan Staller]

I use 60 % free space. In this way, the entire contents can be replaced (if 
needed) and also allows for some growth.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Blake, Daniel J [CTR]
Sent: Tuesday, October 2, 2018 5:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

When building a new system or adding maintenance I go back through all LNK, LPA 
and APF libraries making sure they all have at least 20% free space. If for no 
other reason getting setup for the next maintenance cycle.  When I'm bored, 
which is almost never, I'll check every data set on the RES volume for free 
space.


;-D an


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, October 02, 2018 2:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You can also avoid both by allocating it large enough: calculate what you need 
during the life of the IPL, double, triple or whatever it and you can sleep 
quietly. What do a few 1000 cyls cost these days?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: 02 October, 2018 8:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
>
> On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:
> > There are two separate problems here. (1) A link list library taking
> > a
> new extent after IPL. (2) An LLA-managed library having contents moved
> by either compress or reload.
> >
> > (1) Can be avoided by simply not defining any secondary extent, i.e.
> specifying a secondary of zero. Getting more than one extent to
> satisfy the original allocation is not a problem as long as no
> additional extent is allowed afterward. If a new extent is truly
> needed to hold enlarged content, then link list update can be used.
> >
> > (2) Seems to be OP's issue. LLA REFRESH can handle the consequences
> > of
> dynamic update within the original (IPL time) extent(s). Note that
> REFRESH is needed on all sharing systems.
>
> I never liked defining secondary of zero. I realize it's IBM's
> recommendation, but it all but ensures a compress will be performed
> when the library fills up. I've had systems crash either during or
> after such a compress -- sometimes with disastrous consequences!
>
> I would much rather take a new extent for one relinked module than
> risk corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR.
> Of course, periodic compress of LNKLST PDS libraries is not a bad idea
> when done under controlled circumstances: i.e., "quiet" time and LLA
> on all sharing systems has been shut DOWN. Also, I like to STEPLIB any
> IEBCOPY job to a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY
> program parts are not moved during the compress... BTDTGTS!!
>
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .phoenixsoftware.com%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7Ce
> 5b22f96eb864d1712df08d62855ad14%7C189de737c93a4f5a8b686f4ca9941912%7C0
> %7C0%7C636740745807628066sdata=%2Bq5m1B%2BWqBPQLMrX%2BwfqTsTuniUY
> PzuVswtZNlub6i8%3Dreserved=0
>
>
> --
> --
> 
> This e-mail message, including any attachments, appended messages and
> the information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination,
> distribution, review, storage or copying of this e-mail message and
> the information contained therein is strictly prohibited. If you are
> not an intended recipient, please contact the sender by reply e-mail
> and destroy all copies of this email message and do not otherwise
> utilize or retain this email message or any or all of the information
> contained therein. Although this email message and any attachments or
> appended messages are believed to be free of any virus or other defect
> that might affect any computer system into which it is received and
> opened, it is the responsibility of the recipient to ensure that it is
> virus free and no responsibility is accepted by the sender for any
> loss or damage arising in any way from its opening or use.
>
> --
> 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: 

Reporting zOS and USS based data with Tableau software

[Karlheinz Koch]

Maybe some of you know the reporting software Tableau which is used in a lot of 
companies in the meantime.
Tableau has a rich set of data source connectors to join data from various 
technologies for reporting and analytics purposes.
Here the URL www.tableau.com

Currently Tableau Desktop and Server application only supports an IBM Db2 
connection and does not cover other data formats like VSAM, QSAM etc. which are 
used on z/OS side.

We have submitted a Tableau feature request to also allow the read connection 
for other data formats than Db2 on z/OS or USS.

Here the link to the Tableau feature request.
https://community.tableau.com/ideas/9283


If you think this makes sense for your mainframe installation as well please 
vote for the request.

Regards
Karlheinz

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

Re: S106 abends after copying into LINKLIST

[Peter Relson]

The most likely explanations are those that were mentioned:
-- a LNKLST data set did, despite your thought, go into a secondary 
extent.
Does the output of the CSV_LNKLST_SPACE health check agree that you 
have no secondary extents in LNKLST data sets?
-- a LNKLST data set was compressed
If you properly avoid compress without getting the proper (DISP=OLD, 
exclusive) serialization, the allocations done on the LNKLST data sets 
will prevent that.
But if you simply use DISP=SHR, you're on your own.

There is no reason that I can think of to refresh LLA as long as you have 
not done of those things.

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

SHARE St.Louis 2018 Proceedings Extraction Error

[Richards, Robert B.]

I downloaded the self-extracting zip file, Proceedings.7z, and got the 
following error when it attempts to populate the abstracts folder:

Extracting abstracts   OK
Extracting css   OK
Extracting css\bootstrap   OK
Extracting css\bootstrap\css  OK
Extracting css\bootstrap\img  OK
Extracting css\bootstrap\js   OK
Extracting data  OK
Extracting files OK
Extracting img   OK
Extracting jsOK
Extracting lib   OK
Extracting lib\angular OK
Extracting partials OK
Extracting xml   OK
Extracting abstracts\32437.html   Unknown compression method

Anyone else experience this issue?

As far as I can tell, I had zero issues downloading the 1.7GB zip file.

Bob

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

Re: S106 abends after copying into LINKLIST

[Blake, Daniel J [CTR]]

When building a new system or adding maintenance I go back through all LNK, LPA 
and APF libraries making sure they all have at least 20% free space. If for no 
other reason getting setup for the next maintenance cycle.  When I'm bored, 
which is almost never, I'll check every data set on the RES volume for free 
space.


;-D an 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Tuesday, October 02, 2018 2:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

You can also avoid both by allocating it large enough: calculate what you need 
during the life of the IPL, double, triple or whatever it and you can sleep 
quietly. What do a few 1000 cyls cost these days?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Jaffe
> Sent: 02 October, 2018 8:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
> 
> On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:
> > There are two separate problems here. (1) A link list library taking a
> new extent after IPL. (2) An LLA-managed library having contents moved
> by either compress or reload.
> >
> > (1) Can be avoided by simply not defining any secondary extent, i.e.
> specifying a secondary of zero. Getting more than one extent to satisfy
> the original allocation is not a problem as long as no additional extent
> is allowed afterward. If a new extent is truly needed to hold enlarged
> content, then link list update can be used.
> >
> > (2) Seems to be OP's issue. LLA REFRESH can handle the consequences of
> dynamic update within the original (IPL time) extent(s). Note that
> REFRESH is needed on all sharing systems.
> 
> I never liked defining secondary of zero. I realize it's IBM's
> recommendation, but it all but ensures a compress will be performed when
> the library fills up. I've had systems crash either during or after such
> a compress -- sometimes with disastrous consequences!
> 
> I would much rather take a new extent for one relinked module than risk
> corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR.
> Of course, periodic compress of LNKLST PDS libraries is not a bad idea
> when done under controlled circumstances: i.e., "quiet" time and LLA on
> all sharing systems has been shut DOWN. Also, I like to STEPLIB any
> IEBCOPY job to a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY program
> parts are not moved during the compress... BTDTGTS!!
> 
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
> 
> 
> 
> 
> This e-mail message, including any attachments, appended messages and
> the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination,
> distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all
> copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although
> this
> email message and any attachments or appended messages are believed to
> be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the
> recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or
> use.
> 
> --
> 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 

IBM-MAIN

[Klaus Klein]

 - 



To view this newsletter in a browser, visit:
http://listserv.ua.edu/cgi-bin/wa?A2=IBM-MAIN;4f5eed5f.1810p

To ensure that this newsletter is delivered to your inbox, add
IBM-MAIN@LISTSERV.UA.EDU to your address book.



In this Newsletter:

* 
* 
* Subscription Details













Subscription Details

You are subscribed to . To unsubscribe, visit:
http://LISTSERV.UA.EDU/cgi-bin/wa?SUBED1=IBM-MAIN=1




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

FCP channel type activation

[Peter]

Hi

I have added few IO Devices with unit FCP and I have activated the IODF
dyanamically.

When I do Q EDEVICE from zVM I get NONE of emulated devices found but I can
see them available as FCP using QUERY 7800.

Has anyone undergone this similar situation ?

Peter

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

Re: S106 abends after copying into LINKLIST

[Vernooij, Kees (ITOPT1) - KLM]

You can also avoid both by allocating it large enough: calculate what you need 
during the life of the IPL, double, triple or whatever it and you can sleep 
quietly. What do a few 1000 cyls cost these days?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Jaffe
> Sent: 02 October, 2018 8:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S106 abends after copying into LINKLIST
> 
> On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:
> > There are two separate problems here. (1) A link list library taking a
> new extent after IPL. (2) An LLA-managed library having contents moved
> by either compress or reload.
> >
> > (1) Can be avoided by simply not defining any secondary extent, i.e.
> specifying a secondary of zero. Getting more than one extent to satisfy
> the original allocation is not a problem as long as no additional extent
> is allowed afterward. If a new extent is truly needed to hold enlarged
> content, then link list update can be used.
> >
> > (2) Seems to be OP's issue. LLA REFRESH can handle the consequences of
> dynamic update within the original (IPL time) extent(s). Note that
> REFRESH is needed on all sharing systems.
> 
> I never liked defining secondary of zero. I realize it's IBM's
> recommendation, but it all but ensures a compress will be performed when
> the library fills up. I've had systems crash either during or after such
> a compress -- sometimes with disastrous consequences!
> 
> I would much rather take a new extent for one relinked module than risk
> corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR.
> Of course, periodic compress of LNKLST PDS libraries is not a bad idea
> when done under controlled circumstances: i.e., "quiet" time and LLA on
> all sharing systems has been shut DOWN. Also, I like to STEPLIB any
> IEBCOPY job to a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY program
> parts are not moved during the compress... BTDTGTS!!
> 
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
> 
> 
> 
> 
> This e-mail message, including any attachments, appended messages and
> the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination,
> distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all
> copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although
> this
> email message and any attachments or appended messages are believed to
> be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the
> recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or
> use.
> 
> --
> 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: S106 abends after copying into LINKLIST

[Ed Jaffe]

On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote:

There are two separate problems here. (1) A link list library taking a new 
extent after IPL. (2) An LLA-managed library having contents moved by either 
compress or reload.

(1) Can be avoided by simply not defining any secondary extent, i.e. specifying 
a secondary of zero. Getting more than one extent to satisfy the original 
allocation is not a problem as long as no additional extent is allowed 
afterward. If a new extent is truly needed to hold enlarged content, then link 
list update can be used.

(2) Seems to be OP's issue. LLA REFRESH can handle the consequences of dynamic 
update within the original (IPL time) extent(s). Note that REFRESH is needed on 
all sharing systems.


I never liked defining secondary of zero. I realize it's IBM's recommendation, 
but it all but ensures a compress will be performed when the library fills up. 
I've had systems crash either during or after such a compress -- sometimes with 
disastrous consequences!

I would much rather take a new extent for one relinked module than risk corrupting the *ENTIRE 
LIBRARY* with a "live" compress using DISP=SHR. Of course, periodic compress of LNKLST 
PDS libraries is not a bad idea when done under controlled circumstances: i.e., "quiet" 
time and LLA on all sharing systems has been shut DOWN. Also, I like to STEPLIB any IEBCOPY job to 
a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY program parts are not moved during the 
compress... BTDTGTS!!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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