Re: What does "Performance implications" signify?

[Hobart Spitz]

IIRC, the S/370s were somewhat affected by non-aligned doublewords, and the
impact has decreased with newer hardware, possibly to zero or nearly so.
If I had to guess, micro code advances, faster multi-level cache, and/or
out of order execution, have made any impact negligible.

On Oct 7, 2017 3:10 PM, "scott Ford"  wrote:

> Peter,
>
> Loved the answer.. Would you agree how the macros is used and purpose being
>  factors in performance, speaking very
> Generically..
>
>
> Scott
>
> On Sat, Oct 7, 2017 at 9:01 AM Peter Relson  wrote:
>
> > It signifies what you expect it to signify, but not down to the level of
> > micro-managing. I would view the difference between doubleword alignment
> > and not-so-aligned to be micro-managing,
> >
> > > I don't recall ever seeing a value other than "None,"
> > There are some (maybe even many).  GQSCAN, for example.
> >
> > Primarily I would think it might apply to operational differences between
> > choices when it seems important to let the user know.
> >
> > 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
> >
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: DLIB volume for SAD

[Jesse 1 Robinson]

I agree that SAD should be rebuilt after every upgrade. The question is whether 
to maintain older levels to match every system in the enterprise and associate 
them without manual intervention. My earlier point was that we are configured 
to take SAD to the latest SAD version even though it might be a release (or 
more) higher than the failing system. 

We run two separate data centers connected via DWDM. I'm not thrilled at the 
idea of writing a Mod-54's worth of data to a device 100+ kilometers away, 
especially as re-IPL of a failed system is waiting with drumming fingers for 
SAD to finish. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Thursday, September 28, 2017 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: DLIB volume for SAD



Mr. Murphy taught me a very long time ago that I should always ensure I have a 
working SADUMP that matches the OS level requiring it.



Agree. That's why I always rebuilt it after every zOS maintenance cycle, cause' 
ya never know.

Mark Jacobs

> Mark Zelden 
> September 28, 2017 at 12:27 PM
> I didn't respond to the "last time you took an SAD". It has been 
> probably 1.5 years at least since a prod / dev LPAR crashed and took 
> an SAD via AUTOIPL, but it does happen every few years it seems.
>
> The other 2 times were more recent and involved sandbox LPARs. One was 
> just a week ago when someone had removed a data set from LPA involving 
> CICS VR because the sandbox LPAR did not run CICS. The LPAR hadn't 
> been IPLed in over a month and the person who removed it didn't think 
> that was the reason for the wait state at IPL time. I was able to look 
> at the SADUMP and figure it out. IBM supplies SYS1.SDWWDLPA with a 
> dummy CICSVR module that NIP looks for at IPL time and I had to add 
> that back into LPA.
>
> Mr. Murphy taught me a very long time ago that I should always ensure 
> I have a working SADUMP that matches the OS level requiring it.
>
> Regards,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL 
> v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
> http://www.mzelden.com/mvsutil.html
> 
> Systems Programming expert at
> http://search390.techtarget.com/ateExperts/
> 
>
>
>
>
> On Thu, 28 Sep 2017 11:16:47 -0500, Mark Zelden  wrote:
>
> >I always put SADUMP for each OS release on the 2nd volume of my
> maintenance
> >sysres for each OS release (still using 3390-9s). I create an HMC 
> >profile on each CPC for SADUMP at that time. If I was using a mod-27
> or anything
> >large enough where I didn't have a multi-volume sysres set, I would
> just put it on
> >the dlib volume instead (this is what I did years ago).
> >
> >Part of my migration / cut over plan for after a "GO" decision when
> migrating
> >releases is to update the HMC SADUMP profile for that LPAR and to 
> >verify AUTOIPL SADMP has been updated in DIAGxx to point to that 
> >proper volume as well (this is staged already in a "migration parmlib"
> concatenated ahead
> >of the normal parmlib concatenation. So at any given time during OS
> upgrade
> >migration, some LPARs are pointing to one level of SADUMP and other 
> >LPARs pointing to another level. It always matches the SADUMP for the 
> >OS
> version.
> >
> >Regards,
> >
> >Mark
> >--
> >Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL 
> >v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
> >http://www.mzelden.com/mvsutil.html
> 
> >Systems Programming expert at
> http://search390.techtarget.com/ateExperts/
> 
> >
> >
> >
> >
> >
> >==
> >
> >On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson
>  wrote:
> >
> >Invitation for early Friday war stories.
> >
> >When implementing (OS-moniker-du-jour) 1.6, we had several
> catastrophic failures that required back out to previous level. We 
> took some SADs during that stormy period.
> >
> >When implementing z/OS 1.13, we had several instances of running
> clean out of real storage! System hit a wait state, took SAD 
> automatically, then re-IPLed itself. That was entertaining.
> >
> >We more recently (under 2.1) took SAD and re-IPLed a hung system that
> would probably have recovered if we had held off a bit longer. Heck, 
> Game of Thrones was on. How long were we supposed to wait? ;-)
> >
> >.
> >.
> >J.O.Skip Robinson
> >Southern California Edison Company
> >Electric Dragon Team Paddler
> >SHARE MVS Program Co-Manager
> >323-715-0595 Mobile
> >626-543-6132 Office ⇐=

Re: Time on one LPAR on CEC

[Clark Morris]

[Default] On Sun, 8 Oct 2017 12:09:54 -0700 (PDT), in
bit.listserv.ibm-main Andy  wrote:

>Hi - I'm not a hardware person, but we have a CEC z13 with multiple LPARS we 
>want 3 of the 6 to run on a different time zone. The system gets STP time 
>through our external CFs. 

Run all of the LPARs on UTC Universal Time something formerly GMT and
set the time zone offset by LPAR.  While there will be problems with
the cutover due to overlapping dates and times, after that most SMF
records will be consistent since most will use the hardware time and
be immune to DST changes.  People facing times can be used by the
applications.

Clark Morris 
>
>I'm being told by operations staff who handles the hardware we have to 
>deactivate and reactivate the LPARS running on JAPAN time. These are 3 LPARS 
>we want to be on Japan time since they don't change to daylight savings like 
>the US.
>
>if it helps all the LPARS in question are running z/OS 2.2, they are not all 
>in the same sysplex, two the japan lpars are in a sysplex. One is standalone, 
>the last 3 LPAR(s) are in a sysplex with other systems from other CECs running 
>US time.
>
>
>In the past the past these LPARS were on their own CEC so this wasn't an 
>issue. This is the first clock change they are all on the same CEC with LPARS 
>running US time, is this how other places handles it with twice the year with 
>the deactivate/activate?
>
>Thanks
>Andy

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

CAVMEN Meeting October 19, 2017 - SECOND NOTICE

[Jack H. Slavick]

Hello,
The second quarter meeting of the Chicago Area VM (and Linux) Enthusiasts
will be held on Thursday, October 19, 2017. PLEASE NOTE: we are setting
aside some time before lunch to celebrate the 45th anniversary of VM
operating system (thanx to the folks at MVMUA for the idea/reminder). There
will be cake in the afternoon.

Meeting Location: 
This quarter's meeting will once again be held at the AON Hewitt 'West
Campus' located at 4 Overlook Point, in Lincolnshire, IL. 
Attendees are asked to enter through the Building A North Wing entrance.
Please use the stated entrance.  Please be attentive to where you park and
where you attempt to enter the building.Security has been instructed to
send you to the correct entrance should you ignore this warning and show up
at the wrong entrance. 
If you have not attended a meeting at this location before and do not know
the location of this entrance, please Click here: http://www.cavmen.org .
Check the links out!!!
There is a lot of information on the this site for your benefit!!!   

Attendance: 
We would like to request a count of expected attendees by the Monday before
the meeting, so that we may plan appropriately for arranging the facilities.
If you are planning to attend, PLEASE send an E-Mail by that date to
jslav...@comcast.net with the subject "Meeting Attendance".  

This is meant to be a facilities planning aid and should not be interpreted
as a registration requirement. If you suddenly become available at the last
minute, please feel free to attend even if you have not responded. 

Thank you in advance for your cooperation in this matter.  It is only
necessary to reply once concerning attendance.   


Meeting Agenda:

Posted at: http://www.cavmen.org 

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

AW: Re: Time on one LPAR on CEC

[Peter Hunkeler]

>While there will be problems with the cutover due to overlapping dates and 
>times, after that most SMF records will be consistent since most will use the 
>hardware time and be immune to DST changes.  People facing times can be used 
>by the applications.

SMF record header timestsmps contain *local* date and time values, not UTC!
-- Peter Hunkeler







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