Re: RE-IPL for the Daylight to Standard time conversion?
On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote: > >Since UNIX and Windows platforms handle DST by just forcing the local >time discontinuity, if an application has a problem with that, you don't >have a choice other than tolerating the result or trying to find and fix >any intolerable problems the discontinuity causes for the application. >I'm sure there are cases on those platforms where a rare "strangeness" >at time zone changes is just tolerated, since users in those environment >traditionally seem to expect a higher level of s--- happens and some >occasional apparent non-determinism.. > I'm trying to imagine my UNIX-oriented colleagues' snickering at the idea of shutting down a system at the DST transition. When they stopped giggling, I'd expect them to ask, "But which time zone; which country? All? Northern or Southern Hemisphere? Both?" UNIX systems run their system clocks on UTC and an input to localtime() is a time zone chosen by the programmer. It would be absurd to expect an hour's outage for each of several dozen time zones in the world. z/OS has a peculiar tunnel vision in its belief that there are only two time zones. Leap seconds are a different issue. z/OS shuts down all applications during a leap second. Google and Amazon both steer their clocks slow (less than 0.01 percent) for several hours centered on a leap second. And the two have chosen different steering durations. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RE-IPL for the Daylight to Standard time conversion?
>From the SYSTEMS Side, were I work. In the FALL-BACK poses a lot of issues >for things that reply upon a valid system time. If we all relied on GMT the would be no real issue, but just about everyone likes Local Time. Plus its mostly political If you are in the Retail Business like Walmart is. You have lots of little laws that vary from state to state. I love spring forward, do a SET CLOCK and you are done and the folks that process SMF will see a 1 hour gap. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, October 26, 2015 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RE-IPL for the Daylight to Standard time conversion? On Mon, 26 Oct 2015 14:28:14 -0700, Charles Mills wrote: > >Can anyone enlighten me? Why might our datacenter need or want to IPL >for the Daylight to Standard time conversion? > Atavistic applications. I doubt there's any such residue in the OS. -- 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: RE-IPL for the Daylight to Standard time conversion?
On 10/26/2015 04:28 PM, Charles Mills wrote: > I'm a developer, not an operations guy. My boss has asked me why a > datacenter we use would need to IPL for the daylight to standard time > transition. He asks if the box does not use UTC, and I said that yes, the > hardware clock is generally set to UTC but that perhaps the LPAR time zone > change required an IPL. > > Can anyone enlighten me? Why might our datacenter need or want to IPL for > the Daylight to Standard time conversion? > > Thanks, > > Charles > > This is primarily a "political" and resource allocation issue, not a z/OS issue as z/OS itself can tolerate the jump without an IPL, provided it's done like it's supposed to be by just changing the local offset from the hardware TOD clock, either automatically or manually. If important, most-loved applications are known to record and use local time in a number of contexts and no one is willing to expend resources to research whether they will produce unacceptable results across a discontinuity in local time; nor willing to just "try" the jump see if anything breaks and if so fix it, then the least risky and most politically acceptable recourse may be to shut down all regions supporting that application. When that means shutting down the most significant parts of a z/OS system, sometimes the least disruptive way to do that is to just shut down the entire z/OS system and re-IPL -- which also provides a window to install any pending system changes that might be easiest or safest to install across an IPL. One reason why there may be low political motivation to seek to eliminate a time change IPL is that when the primary user community has become long accustomed to expect and accept a service disruption at such times, this can provides a system or hardware maintenance window subject to minimal end-user objection. Obviously, any new application that manipulates or stores local times should do so in a way that that somehow preserves time zone offset as an integral part of local time and takes care to also use that offset in any context when local time is used to order events by time or to compute duration between events; and any interfaces used by applications to obtain those local time values should be designed to give consistent time and time offset values across a local-time discontinuity. To verify after the fact that any large existing application that was not designed with those rules in place can tolerate a local time discontinuity may not be a trivial exercise. Since UNIX and Windows platforms handle DST by just forcing the local time discontinuity, if an application has a problem with that, you don't have a choice other than tolerating the result or trying to find and fix any intolerable problems the discontinuity causes for the application. I'm sure there are cases on those platforms where a rare "strangeness" at time zone changes is just tolerated, since users in those environment traditionally seem to expect a higher level of s--- happens and some occasional apparent non-determinism.. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RE-IPL for the Daylight to Standard time conversion?
Ditto. Ed On Oct 26, 2015, at 6:33 PM, Chris Hoelscher wrote: We also shutdown for 1 hour - even oif there were no system issues (and I believe there are not) - our friends in development cannot tell us if there are any apps they rely upon/depend upon/require a non-overlapping timing sequence (would a duplicate time violate any physical integrity(keys) or logical integrity (app expectations) - without such explicit clearance, it is prudent to shutdown for 1 hour . Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services : humana.com 123 East Main Street Louisville, KY 40202 Humana.com (502) 714-8615, (502) 476-2538 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: (External):Re: RE-IPL for the Daylight to Standard time conversion?
It is not *my* shop or our shop. It is a site to which we outsource certain processing. I do not know if the issue is that the hardware clock is set to local time. CharlesSent from a mobile; please excuse the brevity Original message From: J O Skip Robinson Date: 10/26/2015 5:45 PM (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: (External):Re: RE-IPL for the Daylight to Standard time conversion? OP did not state whether GMT is set to UTC or local. I would have thought by now shops would have converted to UTC. I understand that the hit is much bigger for shops located in the Eastern Hemisphere because the change requires shutting down--once--for a prodigious period, but in the Western Hemisphere there should be little or no extended down time. If OP's shop is already running UTC, then he's dealing with fear and uncertainty in the application community. My standard (flippant) response is that the local apothecary has formulations to soothe the troubled psyche. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Monday, October 26, 2015 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RE-IPL for the Daylight to Standard time conversion? At 23:33 + on 10/26/2015, Chris Hoelscher wrote about Re: RE-IPL for the Daylight to Standard time conversion?: >We also shutdown for 1 hour - even oif there were no system issues (and >I believe there are not) - our friends in development cannot tell us if >there are any apps they rely upon/depend upon/require a non-overlapping >timing sequence (would a duplicate time violate any physical >integrity(keys) or logical integrity (app expectations) - without such >explicit clearance, it is prudent to shutdown for 1 hour . That is the fallout of using Local not UT/GMT timestamps. -- 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: (External):Re: RE-IPL for the Daylight to Standard time conversion?
OP did not state whether GMT is set to UTC or local. I would have thought by now shops would have converted to UTC. I understand that the hit is much bigger for shops located in the Eastern Hemisphere because the change requires shutting down--once--for a prodigious period, but in the Western Hemisphere there should be little or no extended down time. If OP's shop is already running UTC, then he's dealing with fear and uncertainty in the application community. My standard (flippant) response is that the local apothecary has formulations to soothe the troubled psyche. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Monday, October 26, 2015 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RE-IPL for the Daylight to Standard time conversion? At 23:33 + on 10/26/2015, Chris Hoelscher wrote about Re: RE-IPL for the Daylight to Standard time conversion?: >We also shutdown for 1 hour - even oif there were no system issues (and >I believe there are not) - our friends in development cannot tell us if >there are any apps they rely upon/depend upon/require a non-overlapping >timing sequence (would a duplicate time violate any physical >integrity(keys) or logical integrity (app expectations) - without such >explicit clearance, it is prudent to shutdown for 1 hour . That is the fallout of using Local not UT/GMT timestamps. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RE-IPL for the Daylight to Standard time conversion?
I've been wondering how long it would take for time-change questions to start. It's a little later this year. - -teD - Original Message From: Charles Mills Sent: Monday, October 26, 2015 17:29 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: RE-IPL for the Daylight to Standard time conversion? I'm a developer, not an operations guy. My boss has asked me why a datacenter we use would need to IPL for the daylight to standard time transition. He asks if the box does not use UTC, and I said that yes, the hardware clock is generally set to UTC but that perhaps the LPAR time zone change required an IPL. Can anyone enlighten me? Why might our datacenter need or want to IPL for the Daylight to Standard time conversion? Thanks, Charles -- 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: RE-IPL for the Daylight to Standard time conversion?
At 23:33 + on 10/26/2015, Chris Hoelscher wrote about Re: RE-IPL for the Daylight to Standard time conversion?: We also shutdown for 1 hour - even oif there were no system issues (and I believe there are not) - our friends in development cannot tell us if there are any apps they rely upon/depend upon/require a non-overlapping timing sequence (would a duplicate time violate any physical integrity(keys) or logical integrity (app expectations) - without such explicit clearance, it is prudent to shutdown for 1 hour . That is the fallout of using Local not UT/GMT timestamps. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RE-IPL for the Daylight to Standard time conversion?
We also shutdown for 1 hour - even oif there were no system issues (and I believe there are not) - our friends in development cannot tell us if there are any apps they rely upon/depend upon/require a non-overlapping timing sequence (would a duplicate time violate any physical integrity(keys) or logical integrity (app expectations) - without such explicit clearance, it is prudent to shutdown for 1 hour . Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services : humana.com 123 East Main Street Louisville, KY 40202 Humana.com (502) 714-8615, (502) 476-2538 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown Sent: Monday, October 26, 2015 7:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] RE-IPL for the Daylight to Standard time conversion? How does one handle a 1 hour back time change within a monoplex or sysplex. We have always had in issue with the SYS1 xcf , wlm and logr files and the fall time change. We just shutdown, wait one hour and come back up. I would like to see how others handle this! Tim Brown Sent from my Verizon Wireless 4G LTE smartphone Original message From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Date: 10/26/2015 5:35 PM (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RE-IPL for the Daylight to Standard time conversion? On Mon, 26 Oct 2015 14:28:14 -0700, Charles Mills wrote: > >Can anyone enlighten me? Why might our datacenter need or want to IPL >for the Daylight to Standard time conversion? > Atavistic applications. I doubt there's any such residue in the OS. -- 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 The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Redirect or hide IEBCOPY output when using the TSO RECEIVE Command
At 03:57 -0500 on 10/26/2015, Norbert Friemel wrote about Re: Redirect or hide IEBCOPY output when using the TSO RECE: On Mon, 26 Oct 2015 00:34:13 -0400, Robert A. Rosenberg wrote: At 09:51 -0500 on 10/25/2015, Shmuel Metz (Seymour J.) wrote about Re: Redirect or hide IEBCOPY output when using the TSO RECE: In , on 10/23/2015 at 09:25 PM, "Robert A. Rosenberg" said: WAD is often a misspelling of BAD (Broken As Designed) Yes, but it is not even close to PRS, which acknowledges that there is a defect. What does PRS stand for? Permanent ReStriction https://www-304.ibm.com/support/customercare/sas/f/handbook/acronyms.html Which reads "A programming error was found but will not be corrected. The error will be a permanent restriction in the product." Which is not even the same as WAD. WAD says the coding does what the specs say it should while PRS says, in effect, that due to a coding error the code does not match the specs so instead of fixing the problem we are altering the specs to match the behavior of the bad code. Neither of these cases cover my suggested BAD case where it is the design that is defective/inadequate. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RE-IPL for the Daylight to Standard time conversion?
How does one handle a 1 hour back time change within a monoplex or sysplex. We have always had in issue with the SYS1 xcf , wlm and logr files and the fall time change. We just shutdown, wait one hour and come back up. I would like to see how others handle this! Tim Brown Sent from my Verizon Wireless 4G LTE smartphone Original message From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Date: 10/26/2015 5:35 PM (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RE-IPL for the Daylight to Standard time conversion? On Mon, 26 Oct 2015 14:28:14 -0700, Charles Mills wrote: > >Can anyone enlighten me? Why might our datacenter need or want to IPL for >the Daylight to Standard time conversion? > Atavistic applications. I doubt there's any such residue in the OS. -- 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: (External):Re: RE-IPL for the Daylight to Standard time conversion?
(What's the antonym for atavistic) data centers should not need to IPL for autumn fallback. This means reasonably current hardware with some kind of exo-OS clock (sysplex timer or STP) with current OS and middle-ware: CICS, DB2, automation product, job scheduler, etc. Or it could be personal discomfort with duplicate local time stamps. It might be worth a question to the data center manager as to why IPL is necessary. We are not planning on any overt action. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, October 26, 2015 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RE-IPL for the Daylight to Standard time conversion? On Mon, 26 Oct 2015 14:28:14 -0700, Charles Mills wrote: > >Can anyone enlighten me? Why might our datacenter need or want to IPL >for the Daylight to Standard time conversion? > Atavistic applications. I doubt there's any such residue in the OS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RE-IPL for the Daylight to Standard time conversion?
If you use local time and ESDS for logging (key is timestamp), you can't go backward in time and you have to be down that one hour a year. On Mon, Oct 26, 2015 at 4:28 PM, Charles Mills wrote: > I'm a developer, not an operations guy. My boss has asked me why a > datacenter we use would need to IPL for the daylight to standard time > transition. He asks if the box does not use UTC, and I said that yes, the > hardware clock is generally set to UTC but that perhaps the LPAR time zone > change required an IPL. > > Can anyone enlighten me? Why might our datacenter need or want to IPL for > the Daylight to Standard time conversion? > > Thanks, > > Charles > > -- > 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
Re: RE-IPL for the Daylight to Standard time conversion?
On Mon, 26 Oct 2015 14:28:14 -0700, Charles Mills wrote: > >Can anyone enlighten me? Why might our datacenter need or want to IPL for >the Daylight to Standard time conversion? > Atavistic applications. I doubt there's any such residue in the OS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RE-IPL for the Daylight to Standard time conversion?
I'm a developer, not an operations guy. My boss has asked me why a datacenter we use would need to IPL for the daylight to standard time transition. He asks if the box does not use UTC, and I said that yes, the hardware clock is generally set to UTC but that perhaps the LPAR time zone change required an IPL. Can anyone enlighten me? Why might our datacenter need or want to IPL for the Daylight to Standard time conversion? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 4-hour MSU rolling average
I use the following, which is similar to the REXX provided earlier in this thread (and liberally stolen from Mark Zelden). /* REXX */ CVT = C2D(STORAGE(10,4)) RMCT = C2D(STORAGE(D2X(CVT+604),4)) RCT = C2D(STORAGE(D2X(RMCT+228),4)) RCTLACS = C2D(STORAGE(D2X(RCT+196),4)) RCTIMGWU = C2D(STORAGE(D2X(RCT+28),4)) RCTCECWU = C2d(Storage(D2x(RCT+32),4)) IF RCTCECWU <> 0 THEN DO say 'The MSU capacity for this CEC is' rctcecwu'.' say 'The defined MSU capacity for this LPAR is' rctimgwu'.' END IF RCTLACS <> 0 THEN DO say 'The 4 hour msu average usage is' rctlacs'.' IF RCTLACS = RCTIMGWU & RCTIMGWU <> RCTCECWU THEN , say ' ** LPAR may currently be "soft capped". **' IF RCTLACS > RCTIMGWU & RCTIMGWU <> RCTCECWU THEN , say ' ** LPAR is currently "soft capped". **' END Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, David Allen,Jr Sent: Monday, October 26, 2015 2:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 4-hour MSU rolling average Thank you. That is the total capacity of the CEC, 28 on my machine. For SCRT purposes, I cap at 16. Is there a variable which I can look at to see how far under this cap I am, or when I am experiencing capping? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 4-hour MSU rolling average
Thank you. That is the total capacity of the CEC, 28 on my machine. For SCRT purposes, I cap at 16. Is there a variable which I can look at to see how far under this cap I am, or when I am experiencing capping? > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Werner Kuehnel > Sent: Monday, October 26, 2015 6:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 4-hour MSU rolling average > > David, > sorry for the late reply, I was a bit behind with reading ibm-main mails. > The R4H average for the LPAR is in variable MSU_4H. > The overall CEC value is in the same control block (RCT) in variable > RCTCECWU (displacement dec'32' x'20'). > > Hth, > Werner > > > > Von:"Gibney, David Allen,Jr" > An: IBM-MAIN@LISTSERV.UA.EDU, > Datum: 20.10.2015 20:54 > Betreff:Re: Antwort: 4-hour MSU rolling average > Gesendet von: IBM Mainframe Discussion List m...@listserv.ua.edu> > > > > Which is the value for the LPAR. Is there a similar way to get the overall CEC > value? > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Werner Kuehnel > > Sent: Tuesday, October 20, 2015 6:21 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Antwort: 4-hour MSU rolling average > > > > Here's a little REXX subroutine to get the values: > > > > get4hrAvgMSU: > >MSU_4H = 0 > >MSU_GRP = 0 > >CVT = C2d(Storage(10,4)) /* point to CVT */ > >RMCT= C2d(Storage(D2x(CVT+604),4))/* point to RMCT*/ > >RCT = C2d(Storage(D2x(RMCT+228),4)) /* Resource Ctrl Tbl*/ > >MSU_4H = C2d(Storage(D2x(RCT+196),4))/* 4 hr MSU average */ > >MSU_GRP = C2d(Storage(D2x(RCT+28),4)) /* Group Limit */ > > > > return > > > > Werner > > > > > > > > > > Von:Steve Austin > > An: IBM-MAIN@LISTSERV.UA.EDU, > > Datum: 20.10.2015 14:17 > > Betreff:4-hour MSU rolling average > > Gesendet von: IBM Mainframe Discussion List > m...@listserv.ua.edu> > > > > > > > > Hi, > > > > Is there an API to return this value(s). I'd expected a WLM call, but > I've not > > found it yet. > > > > Thanks > > > > Steve > > > > -- > > This e-mail message has been scanned and cleared by Google Message > > Security and the UNICOM Global security systems. This message is for > > the named person's use only. If you receive this message in error, > > please > delete it > > and notify the sender. > > > > -- > > 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: (External):Re: Unicode Query
No relation to Paul Harvey. If there was, I would have used And now for the rest of the story - Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John Eells > Sent: Monday, October 26, 2015 7:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: (External):Re: Unicode Query > > Lizette Koehler wrote: > > John, > > There are two flavors of COPYGROUP/COPYGRP with z/OS V2.1 > > > Spot on. They say memory is the second thing to go; I'd quite forgotten the > details > and I wrote the announcement text about this function! > Sorry about that, all. > > (Lizette, was Paul Harvey a relative?) ;-) > > -- > John Eells > z/OS Technical Marketing > 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
IBM Redbooks | IBM z/OS V2R2: Serverpac
http://www.redbooks.ibm.com/redpieces/abstracts/sg248500.html?Open -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: (External):Re: Unicode Query
John - Thank you ! That quip will be used to good effect Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 925 738 9443 Corporate Tieline - 89443 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Monday, October 26, 2015 7:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: (External):Re: Unicode Query Lizette Koehler wrote: > John, > There are two flavors of COPYGROUP/COPYGRP with z/OS V2.1 Spot on. They say memory is the second thing to go; I'd quite forgotten the details and I wrote the announcement text about this function! Sorry about that, all. (Lizette, was Paul Harvey a relative?) ;-) -- John Eells z/OS Technical Marketing 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 "Email Firewall" made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately.. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Create zIIP workload
On Fri, 23 Oct 2015 20:18:39 -0400, Tony Harminc wrote: > >IBM also has rules (published following the Neon Systems legal action >a few years ago) that describe what workloads IBM allows to be run on >the various kinds of processors: >http://www-947.ibm.com/systems/support/machine_warranties/machine_code/aut.html >And, like Facebook, they get to change the rules any time they want. > Of course it depends on what IBM and the ISV notice. Things can slip through the cracks. To wit: IO11698 5 years ago which whitewashed (not repaired) a side-door integrity exposure, now pretty well described in a Users Guide, that may have persisted for years or decades without IBM' s noticing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Create zIIP workload
On Mon, 26 Oct 2015 08:27:29 -0400, Tony Thigpen wrote: > >It has to do with how the other guy prices his software. For example, if >he is mips based on a specific box, and you then start running his >software on a much faster zIIP, he would be loosing revenue and the >customer could be in violation of the use agreement. > I see. But if the "other guy" charges a flat rate or even supplies FOSS and doesn't care, this creates a side door to the zIIP and I'd expect IBM to care, as IBM surely cared about Neon zPrime. >> On Sun, 25 Oct 2015 20:53:13 -0400, Peter Relson wrote: >> >>> Once properly licensed, I believe that there is very little of your own >>> code that you are not allowed to make zIIP eligible. >>> >>> The main thing that you are not allowed to do is to make someone else's >>> code zIIP-eligible (which includes calling them from a zIIP-eligible >>> state), without their approval. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Create zIIP workload
Awesome, thanks for all the info everyone, helpful as always. I don't know what the mainframe community would be without this list. Thanks and Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Friday, October 23, 2015 8:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Create zIIP workload On 23 October 2015 at 10:12, Leonardo Vaz wrote: > I could not find documentation on how to create an enclave SRB that would > make use of the zIIP processor. > Is this documented anywhere? As Bob said, it's available to ISVs. If you can convince IBM that you are one (perhaps CN sells software, even if it's not your main business. Heh - Ruby on Rails...?) then maybe they'll tell you. Start here for the ISV route: http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.PT217.HTML(INDEX)' If you want to not be an ISV and still get the info, you'd have to take it up with, as Timothy Sipples is fond of saying, "your friendly IBM representative", by which I assume he means your IBM sales person. How "friendly" he or she will be when you want to reduce the amount you pay IBM by moving cycles to a cheaper CPU, I don't know. Maybe if you can convince them that you will otherwise move the workload onto a non-IBM system... I have no knowledge of the IBM rules in practice, but it doesn't hurt to ask. IBM also has rules (published following the Neon Systems legal action a few years ago) that describe what workloads IBM allows to be run on the various kinds of processors: http://www-947.ibm.com/systems/support/machine_warranties/machine_code/aut.html And, like Facebook, they get to change the rules any time they want. Even ISVs with access to the means of dispatching work on a zIIP have to conform to these rules. So if what you propose to run on your zIIP doesn't conform in the first place, I can't imagine there's any way they'll tell you how. And don't forget the one documented and supported way to get your own program to run on a zAAP/zIIP: write it in Java. Good luck. Tony H. -- 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: (External):Re: Unicode Query
Lizette Koehler wrote: John, There are two flavors of COPYGROUP/COPYGRP with z/OS V2.1 Spot on. They say memory is the second thing to go; I'd quite forgotten the details and I wrote the announcement text about this function! Sorry about that, all. (Lizette, was Paul Harvey a relative?) ;-) -- John Eells z/OS Technical Marketing 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: Shopz Receive Order failing this morning
Thanks for confirming the problem appears to be on IBM's side Doug. I also saw the message you reported too. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Henry Sent: Monday, October 26, 2015 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Shopz Receive Order failing this morning On Mon, 26 Oct 2015 12:56:56 +, Jousma, David wrote: >Tried both the primary (Boulder), and backup (Rochester), and both are failing: > >GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - com.ibm.smp.GIMJVEXC: > com.ibm.smp.GIMJVEXC: java.net.ConnectException: EDC8127I > CONNECTION TIMED OUT. >GIM69188S ** RECEIVE PROCESSING HAS FAILED. AN ERROR WAS FOUND IN THE RESPONSE > RECEIVED FROM THE SERVER AT > https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. >GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. > > >Just wanting to verify its IBM and not something at my end. > >Thanks, Dave Hi Dave, With all the problems in Boulder we have our daily job going to Rochester and ours failed this morning with one of those "usual" type failures. GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - com.ibm.smp.GIMJVEXC: com.ibm.smp.GIMJVEXC: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shopz Receive Order failing this morning
On Mon, 26 Oct 2015 12:56:56 +, Jousma, David wrote: >Tried both the primary (Boulder), and backup (Rochester), and both are failing: > >GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - com.ibm.smp.GIMJVEXC: > com.ibm.smp.GIMJVEXC: java.net.ConnectException: EDC8127I > CONNECTION TIMED OUT. >GIM69188S ** RECEIVE PROCESSING HAS FAILED. AN ERROR WAS FOUND IN THE RESPONSE > RECEIVED FROM THE SERVER AT > https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. >GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. > > >Just wanting to verify its IBM and not something at my end. > >Thanks, Dave Hi Dave, With all the problems in Boulder we have our daily job going to Rochester and ours failed this morning with one of those "usual" type failures. GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - com.ibm.smp.GIMJVEXC: com.ibm.smp.GIMJVEXC: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 4-hour MSU rolling average
David, sorry for the late reply, I was a bit behind with reading ibm-main mails. The R4H average for the LPAR is in variable MSU_4H. The overall CEC value is in the same control block (RCT) in variable RCTCECWU (displacement dec'32' x'20'). Hth, Werner Von:"Gibney, David Allen,Jr" An: IBM-MAIN@LISTSERV.UA.EDU, Datum: 20.10.2015 20:54 Betreff:Re: Antwort: 4-hour MSU rolling average Gesendet von: IBM Mainframe Discussion List Which is the value for the LPAR. Is there a similar way to get the overall CEC value? > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Werner Kuehnel > Sent: Tuesday, October 20, 2015 6:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Antwort: 4-hour MSU rolling average > > Here's a little REXX subroutine to get the values: > > get4hrAvgMSU: >MSU_4H = 0 >MSU_GRP = 0 >CVT = C2d(Storage(10,4)) /* point to CVT */ >RMCT= C2d(Storage(D2x(CVT+604),4))/* point to RMCT*/ >RCT = C2d(Storage(D2x(RMCT+228),4)) /* Resource Ctrl Tbl*/ >MSU_4H = C2d(Storage(D2x(RCT+196),4))/* 4 hr MSU average */ >MSU_GRP = C2d(Storage(D2x(RCT+28),4)) /* Group Limit */ > > return > > Werner > > > > > Von:Steve Austin > An: IBM-MAIN@LISTSERV.UA.EDU, > Datum: 20.10.2015 14:17 > Betreff:4-hour MSU rolling average > Gesendet von: IBM Mainframe Discussion List m...@listserv.ua.edu> > > > > Hi, > > Is there an API to return this value(s). I'd expected a WLM call, but I've not > found it yet. > > Thanks > > Steve > > -- > This e-mail message has been scanned and cleared by Google Message > Security and the UNICOM Global security systems. This message is for the > named person's use only. If you receive this message in error, please delete it > and notify the sender. > > -- > 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
Shopz Receive Order failing this morning
Tried both the primary (Boulder), and backup (Rochester), and both are failing: GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ - com.ibm.smp.GIMJVEXC: com.ibm.smp.GIMJVEXC: java.net.ConnectException: EDC8127I CONNECTION TIMED OUT. GIM69188S ** RECEIVE PROCESSING HAS FAILED. AN ERROR WAS FOUND IN THE RESPONSE RECEIVED FROM THE SERVER AT https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. Just wanting to verify its IBM and not something at my end. Thanks, Dave _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Create zIIP workload
Paul, It has to do with how the other guy prices his software. For example, if he is mips based on a specific box, and you then start running his software on a much faster zIIP, he would be loosing revenue and the customer could be in violation of the use agreement. Tony Thigpen Paul Gilmartin wrote on 10/26/2015 07:16 AM: On Sun, 25 Oct 2015 20:53:13 -0400, Peter Relson wrote: Once properly licensed, I believe that there is very little of your own code that you are not allowed to make zIIP eligible. The main thing that you are not allowed to do is to make someone else's code zIIP-eligible (which includes calling them from a zIIP-eligible state), without their approval. Wouldn't IBM's approval be required also, or even instead? -- 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: Create zIIP workload
On Sun, 25 Oct 2015 20:53:13 -0400, Peter Relson wrote: >Once properly licensed, I believe that there is very little of your own >code that you are not allowed to make zIIP eligible. > >The main thing that you are not allowed to do is to make someone else's >code zIIP-eligible (which includes calling them from a zIIP-eligible >state), without their approval. > Wouldn't IBM's approval be required also, or even instead? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Redirect or hide IEBCOPY output when using the TSO RECEIVE Command
On Mon, 26 Oct 2015 00:34:13 -0400, Robert A. Rosenberg wrote: >At 09:51 -0500 on 10/25/2015, Shmuel Metz (Seymour J.) wrote about >Re: Redirect or hide IEBCOPY output when using the TSO RECE: > >>In , on 10/23/2015 >>at 09:25 PM, "Robert A. Rosenberg" said: >> >>>WAD is often a misspelling of BAD (Broken As Designed) >> >>Yes, but it is not even close to PRS, which acknowledges that there is >>a defect. > >What does PRS stand for? > Permanent ReStriction https://www-304.ibm.com/support/customercare/sas/f/handbook/acronyms.html Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
