No, you did not that way.
Probably you added some memory to LPAR profile, but this is not an LPAR
itself. It is LPAR definition which is used during LPAR activation. For
active LPAR it has no meaning. To compare: it is like change in JES2PARM
member after JES2 is started.
BTW: LPAR definition
W dniu 25.06.2020 o 21:57, Nightwatch RenBand pisze:
We have a 10 year old Hitachi RAID box which Hitachi tells us is going out
of support. Only two applications are left of the old z9 machine but they
are critical. Latest estimate from programmers is that they will migrate
off in 12 to 18 mont
W dniu 17.06.2020 o 20:09, Frank Swarbrick pisze:
What FTP client do you use to access MVS data sets? Do you like it?
I personally use the FTP Client that is part of Micro Focus (formerly
Attachmate) Reflection Desktop for IBM (Reflection Workspace). Being an
application suite dedicated to m
W dniu 17.06.2020 o 22:35, Steely.Mark pisze:
Anyone on this list have experience upgrading Compuware ISPW from v17 to v18?
Is there a listserv for Compuware and / or ISPW ?
What problem do you have?
--
Radoslaw Skorupka
Lodz, Poland
=
You are right. We added it to the LPAR image profile And that took an
act/deact to add. We had no other memory allocated to that LPAR (reserved
or otherwise). How else could we have added the additional memory without
act/deact?
On Fri, Jun 26, 2020 at 3:54 AM R.S. wrote:
> No, you did not
Proper Planning Prevents Poor Performance.
Let's start from scratch or from CPC Activate process.
Now it is good moment to properly define LPARs. First, give reserved
memory to each one. It is just a definition, it is clause like "I expect
I will add memory in the future".
And when your system
Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?
On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.
Terri,
The CPU% in the title line is always for the local system, regardless of the
SYSNAME setting - this has always been the case.
You might be noticing the difference more because the DA data in 2.4 is
collected centrally by the data gathering task in SDSFAUX, whereas in previous
releases
Interesting because that's not what I am seeing..
SDSF DA ACWA (ALL)PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS
2.4 LPAR
COMMAND INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,DP,Real,Paging,
Terri
You have SYSNAME set to "*" - which means the rows are for all address spaces
on all systems.
The title line only shows CPU% for the local system.
You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA
code uses the same methods as 2.2.
I see that you have a PMR ope
Rob,
My question, was does anyone else see this behavior? And yes that was my
point of sysname=* I think it should total all lpars, like I see in my z/OS 2.2
lpar and display.
But you can see in my z/OS 2.4 lpar, I only get an lpar view.
And yes I opened up the SR because it looked like an i
Terri,
The native SDSF 2.2 code populates the title line from the local system CPU
usage.
A couple of possibilities exist that could explain what you are seeing :
1. You have an ISFUSER exit that alters the title line (possible - but not
common)
2. You have a local replacement/modificat
Thanks Rob,
So NO to the first 2, as we run with hardly any usermods or customizations.
Number 3 is partially true. The 2 UBS2T* Jobs are running on ACW5, But that
is reflected by the 45/29 number is my display. 45 is my total across the
sysplex and 29 is the local lpar.
Ms Terri E Shaffer
On 6/26/20 3:16 AM, R.S. wrote:
3. 18 months is close to half of typical service contract for new dasd
array. Still we don't know how sure is 18 months - maybe it would be 36
months? Even 12 months means the dasd array would have some residual value.
n00b questions:
1) Is it possible to migr
Terri,
I think the SDSF doc could be a bit clearer in this area, but the numbers you
quoted do not mean what you think they mean.
There is some extra help text in the "CPU and SIO fields" section of the help
for the DA command (at the end of the help for the content of the fields).
Taking the
One issue that you may encounter with going to a new storage system on a z9
processor is the speed of the ficon cards and whether the new unit can z9
cards. I am not sure the new Hitachi's can work with 4GB ficon.
I would make sure that if you replace it, with whichever vendor, that the new
un
There are several OEM products such as FDR from Innovation, and CA, which
can speedily migrate between different disk drive architectures. I think
IBM utilities can do it as well, but my experience has been with the
OEM's. In general, migration is easily solved.
On Fri, Jun 26, 2020 at 8:04 AM G
it's not that difficult and most vendor will provide a migration solution
depending on your requirements .
some provide a tool to replicate the data, flip the switch (figuratively) and
you are now running on the new DASD subsystem.
(once DASD is cabled and new GEN is activated)
I've been a p
Source RMF fields in the help text would be, ahem, helpful. :-) And if
they derive from MVS control blocks those field names would be useful,
too. And if MVS gets them from indeed Diagnose 204... :-)
Cheers, Martin
Martin Packer
zChampion, Systems Investigator & Performance Troubleshooter, IBM
You might be better off to look at "Mainframe as a Service" from one of
the smaller providers that can keep it on the z9 but attach it to newer
dasd.
The company I work for specializes in such, but you did not give enough
information to even know if you are candidate for our services.
For ex
On 6/26/20 9:09 AM, Bill Bishop (TMNA) wrote:
One issue that you may encounter with going to a new storage system on
a z9 processor is the speed of the ficon cards and whether the new unit
can z9 cards. I am not sure the new Hitachi's can work with 4GB ficon.
I would naively assume that the F
W dniu 26.06.2020 o 17:04, Grant Taylor pisze:
On 6/26/20 3:16 AM, R.S. wrote:
3. 18 months is close to half of typical service contract for new
dasd array. Still we don't know how sure is 18 months - maybe it
would be 36 months? Even 12 months means the dasd array would have
some residual val
My units are all directed connected, no switches.
The issue is how far down can the newer storage units go down on the speed
charts as they are designed to run at 8 and 16 GB. I don't know that all of
the newer units can slow do to 4 GB.
Thanks
Bill Bishop
Consultant, Mainframe Engineer
Mai
On 6/26/20 9:18 AM, Carmen Vitullo wrote:
it's not that difficult and most vendor will provide a migration
solution depending on your requirements .
Do the vendors support migrating between vendors? Or is this vendor
specific?
some provide a tool to replicate the data, flip the switch
(fig
Simply no.
4Gbps can work with 4, 8 and 16Gbps interface on the other end. I think
even current newest Hitachi DASD boxes may have 16Gbps interfaces, not
32Gbps as the only choice.
Last, but not least: DIRECTOR. FICON switch allows to connect any to any
speed. Yes, including 1Gbps to 32Gbps.
Carmen Vitullo
- Original Message -
From: "Grant Taylor" <023065957af1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, June 26, 2020 10:33:02 AM
Subject: Re: DASD migration -- Re: Hitachi RAID box going out of support
On 6/26/20 9:18 AM, Carmen Vitullo
I find is odd in my 34 years as a sysprog this has always been true or pretty
close and now its not. Not saying I don't believe that you are telling me just
not what I am seeing..
Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-259
Wow. What a lot of pushback.
This is (IMHO) precisely what’s wrong with the (generic average) mainframe
community. New is bad. Different is bad.
Dudes (m/f) : it’s not the 80s anymore.
That being said : here’s a little “why” for the existence of the thing :
https://zdevops.tumblr.com/post
Not all change is progress, nor does an ad hominem argument bolster your case.
Neither does constructing straw dummies. "New is bad. Different is bad." is a
free construct of your imagination, unrelated to anything that anybody here
wrote.
Are their objections valid? I don't know, but misrepre
We do this fairly frequently because we typically replace DASD at end of
warranty so that cost is capital expense rather than O&M. It's never trivial
but has gotten easier over the decades. There two main areas of complexity
depending on your configuration.
1. If you share DASD subsystems amon
Hi.
If you are interested in upgrading your dasd, you may want to consider the
visara VI-8810. It’s rack mounted, SSD drives, compatible with all IBM OS and
processors. Will certainly work with your Z9
Contact me offline and you can tell me what you require in terms of channels
and stora
I was referring to the generic average. Not to anything anyone wrote here.
I already regret replying.
/EOT
> On 26 Jun 2020, at 19:30, Seymour J Metz wrote:
>
> Not all change is progress, nor does an ad hominem argument bolster your
> case. Neither does constructing straw dummies. "New i
I know this is off topic but what does IMHO stand for?
Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Henri Kuiper
Sent: Friday, June 26, 2020 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject:
On Jun 26, 2020, at 1:43 PM, McCabe, Ron wrote:
>
> I know this is off topic but what does IMHO stand for?
>
In My Humble Opinion.
--
Pew, Curtis G
curtis@austin.utexas.edu
--
For IBM-MAIN subscribe / signoff / archive
In my humble opinion
joe
On Fri, Jun 26, 2020 at 1:44 PM McCabe, Ron
wrote:
> I know this is off topic but what does IMHO stand for?
>
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw
>
> -Original Message-
> From: IBM Mainframe Discussion List On Beh
IMHO - In My Humble Opinion
IMNSHO - In My Not So Humble Opinion
😊
Lionel B. Dyck <
Website: https://www.lbdsoftware.com
"Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are." - John Wooden
-Original Message-
F
Inscrutable mostly harmless offal.
btw, there's this new thing, Google. It's free to try.
sas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-
On 2020-06-26 12:57, Henri Kuiper wrote:
here’s a little “why” for the existence of the thing
:https://zdevops.tumblr.com/post/620908065704853504/mainframe-community-mattermost
I read the above, and then headed over to see https://mainframe.community/
I see that the privacy policy and terms a
On Fri, 26 Jun 2020 at 12:57, Henri Kuiper wrote:
>
> Wow. What a lot of pushback.
>
> This is (IMHO) precisely what’s wrong with the (generic average) mainframe
> community. New is bad. Different is bad.
No one has said anything remotely like that.
> Dudes (m/f) : it’s not the 80s anymore.
>
My favorite method of migrating to new DASD works for almost all the datasets.
Define the new Disk volumes to your DFSMS Storage Group configuration(s).
Change the old Disk volumes in each Storage Group to "DISNEW". This method
ensures that as each dataset is moved/copied/reorg/created it wil
On advice from Michael Brennan I created the smaller ZFS dataset and used PAX
to copy into it (instead of IDCAMS REPRO). That worked great! Now I'm ready
to IPL...
--
For IBM-MAIN subscribe / signoff / archive access instructi
Henri Kuiper wrote:
>Wow. What a lot of pushback.
Well, nobody has offered any problem that this new forum is going to solve. Nor
does that web page you cite: it says "I did this technically interesting
thing", but that isn't solving a *problem*. That's my objection: we have a
solution to t
There *are* IMHO some problems with IBMMAIN but it is not clear to me that
they are significant enough to worry about nor that some new forum would
necessarily be better overall.
- Searchability. The archives leave a lot to be desired in this regard IMHO.
- Topic drift. There is something of tende
Try google or google is trying? Every time they improve google it gets harder
to use.
A lot of times I get better results using Wikipedia as a search engine than I
get from google, and the thing that I depended on most, the Usenet archive
they took over from DejaNews, they've destroyed.
--
S
On Fri, 26 Jun 2020 13:46:06 -0700, Charles Mills wrote:
>There *are* IMHO some problems with IBMMAIN but it is not clear to me that
>they are significant enough to worry about nor that some new forum would
>necessarily be better overall.
>
>- Searchability. The archives leave a lot to be desired
Of course Charles is correct-I did not mean to imply that I thought IBM-MAIN
was the zenith of information sharing. It's still on LISTSERV, which is
near&dear to my heart as a long-time VMer, but whose day has largely come and
gone, due to the issues Charles mentions (and more).
Now, if some
Be aware that virtual SHARE sessions will apparently be 40 minutes long. Don't
blame the messenger: not my idea, nor was I particularly thrilled to discover
it, since the session I'm giving was, surprise, targeted at 60 minutes. I'll
just have to talk real fast :)
I guess the good news is th
+1 on redundant replies.
> wish is that the WWW interface supported composing in a
> monospaced font
What's the difference? It shows up for the recipient in whatever font they
choose, typically monospaced.
> that submitters turn off "smart" quotes
Why? Because "pure" ASCII is ordained somewhe
On Fri, 26 Jun 2020 15:33:36 -0700, Charles Mills wrote:
>+1 on redundant replies.
>
>> wish is that the WWW interface supported composing in a
>> monospaced font
>
>What's the difference? It shows up for the recipient in whatever font they
>choose, typically monospaced.
>
But I'm the composer.
No, I know of no computer language that treats "smart" quotes as equivalent to
"dumb" quotes. Did not know you were referring to code samples. You meant smart
quotes in code samples in IBM manuals? That is just flat out wrong, wrong,
wrong. It's just as wrong as if they used ENQUEUE rather than
Don't forget the 5 minutes of live Q/A at the end of your session, Phil...
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Phil Smith III
Sent: Friday, June 26, 2020 4:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Virtual SHARE
Be aware that virtual SHARE
On Fri, 26 Jun 2020 16:06:56 -0700, Charles Mills wrote:
>No, I know of no computer language that treats "smart" quotes as equivalent to
>"dumb" quotes. Did not know you were referring to code samples. You meant
>smart quotes in code samples in IBM manuals? That is just flat out wrong,
>wrong,
> underscored blanks nearly vanished
Wouldn't bolding each underscore be a better solution?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f0
I have used FDRPAS, TDMF which were all vendor compatible, and Dell
z/OS Migrator which must have their hardware as the target. Most
movement was done with the system running at full speed. The
different software packages did require different software products to
be down to SWAP their files. Di
> Why? Because "pure" ASCII is ordained somewhere?
Stop with the straw dummies. Rebut arguments that somebody actually made and
people will take you more seriously.
> Should they turn off their Hebrew or Chinese names too?
Yes, for variables names in code samples where the language doesn't al
On Sat, 27 Jun 2020 00:21:08 +, Seymour J Metz wrote:
>
>> Should they turn off their Hebrew or Chinese names too?
>
>Yes, for variables names in code samples where the language doesn't allow
>them.
>Consider these two lines in a PL/I program for a compiler that supports
>Unicode.
>The fir
We currently have a Strong Supportive group. Opinions are freely given and
taken period. Banter and brainstorming lead to ideas that when given the space
to grow are fortuitous for all.
Continue as we have and we will still be a great group!
Participants in the ‘new community’ are trying to comm
On Fri, 26 Jun 2020 22:28:02 -0400, Doug wrote:
>We currently have a Strong Supportive group. Opinions are freely given and
>taken period. Banter and brainstorming lead to ideas that when given the space
>to grow are fortuitous for all.
>Continue as we have and we will still be a great group!
>
I Manifest Hostile Opinions
On Sat, Jun 27, 2020 at 1:05 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Fri, 26 Jun 2020 22:28:02 -0400, Doug wrote:
>
> >We currently have a Strong Supportive group. Opinions are freely given
> and taken period. Banter and brainsto
> I'll go further and advance the modest proposal that a compiler that supports
> UTF-8
> should treat non-ASCII characters as honorary alphabetic.
I would support a new ANSI standard (way overdue anyway) for PL/I that allowed
any Unicode alphabetic character in identifiers, but I am leery abou
60 matches
Mail list logo
