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
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:
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
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
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
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
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:
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
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
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
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
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
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:
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
> 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
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
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
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
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
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
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
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
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
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
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"
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 :(
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
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
>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
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
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:
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
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
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.
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
-
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
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
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
38 matches
Mail list logo
