Re: Why _TZ put times 7 minutes off?
Linux guests will get the time from the LPAR in which they run. In most cases Linux guests running on the same CEC will have synchronized clocks unless some sort of clock synch event occurred in between IPLs of various LPARs on the same CEC. You should consider NTP when Linux guests need to stay in synch across CECs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Mon, 5 Mar 2012 14:17:07 -0700, Mark Post wrote: > >Most Linux operating systems read the hardware clock during the startup >process, and use that to set the system clock. NTP takes over from there, but >only affects the system clock, not the hardware clock. The system only tries >to set the hardware clock when shutting down. > But that "system clock" needs some sort of frequency reference. I wouldn't imagine that polling NTP provides fine enough granularity. What does it use? >There is only one source of time on Linux, and that's from the kernel via the >gettimeofday syscall. So, all processes go to the same place to get their >time information. > What a concept! You mean none of them do STCK(E) and variously apply corrections from the CVT, sometimes correctly; sometimes not? What if they're running in SRB or whatever mode, and can't issue SVC? (Never mind!) >There were some changes to the kernel a while ago that made it aware of >ETR/STP. I never looked at the code to see if it involved any attempts at >modifying the hardware clock. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
I thought all the game boxes were running the G6 chipset until the last version and one or more converted over to Intel. Don't keep up with it. In a message dated 3/5/2012 3:48:45 P.M. Central Standard Time, john.mck...@healthmarkets.com writes: supposedly, no z/OS, z/VM, or VSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
One guy compiled Hercules to run on Arm processors and he installed it on about 30-50 Network Attached Storage devices (hard drives with a ethernet port). On Mon, Mar 5, 2012 at 3:47 PM, McKown, John wrote: > There are definitely z OS's running on Intel, using Hercules/390. I am sure > of MVT, VS1, VM/370, DOS (some version) and z/Linux. I've even heard that > there is a 31 bit version MVS 3.8j, called MVS/380. But, supposedly, no z/OS, > z/VM, or VSE. > > John McKown > Systems Engineer IV -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
There are definitely z OS's running on Intel, using Hercules/390. I am sure of MVT, VS1, VM/370, DOS (some version) and z/Linux. I've even heard that there is a 31 bit version MVS 3.8j, called MVS/380. But, supposedly, no z/OS, z/VM, or VSE. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Finnell > Sent: Monday, March 05, 2012 2:07 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Why _TZ put times 7 minutes off? > > I still think, there's a zImage running on an Xbox > somewhere-just for fun. > Look at the Raspberry Pi and the enthusiasm they're trying to > encourage-as a programming exercise. > > _http://www.bbc.co.uk/news/technology-17190918_ > (http://www.bbc.co.uk/news/technology-17190918) > > > In a message dated 3/5/2012 9:28:09 A.M. Central Standard Time, > john.mck...@healthmarkets.com writes: > > And this is what is helping to destroy IBM's historic base. > IMO, the IBM > "X series" is just another Dell machine, or other "first > tier" supplier. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
>>> On 3/3/2012 at 01:12 PM, Paul Gilmartin wrote: > What does Linux for z use for clock steering? I understand it > was never ETR-savvy (nor was z/VM?) I imagine it might be > done by letting the ETOD clock run free and allowing NTP to > update parameters of a software offset used by all system time > services (kinda like CVTLSO). Most Linux operating systems read the hardware clock during the startup process, and use that to set the system clock. NTP takes over from there, but only affects the system clock, not the hardware clock. The system only tries to set the hardware clock when shutting down. There is only one source of time on Linux, and that's from the kernel via the gettimeofday syscall. So, all processes go to the same place to get their time information. There were some changes to the kernel a while ago that made it aware of ETR/STP. I never looked at the code to see if it involved any attempts at modifying the hardware clock. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
I still think, there's a zImage running on an Xbox somewhere-just for fun. Look at the Raspberry Pi and the enthusiasm they're trying to encourage-as a programming exercise. _http://www.bbc.co.uk/news/technology-17190918_ (http://www.bbc.co.uk/news/technology-17190918) In a message dated 3/5/2012 9:28:09 A.M. Central Standard Time, john.mck...@healthmarkets.com writes: And this is what is helping to destroy IBM's historic base. IMO, the IBM "X series" is just another Dell machine, or other "first tier" supplier. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Mon, 5 Mar 2012 10:19:03 -0500, Steve Conway wrote: >Ed Jaffe said: >IMHO, STP should be included in the price of the machine. > >I totally agree. There should also be an option to use NTP. Not every >shop needs the granularity of STP, and they damn sure don't want to pay >for functionality that comes free on every other piece of hardware in the >house.. > >Right now, the choices are either to pay $BIGNUM for time keeping software >unique to the hardware platform or to have no time keeping software. > >When I'm trying to advocate a zBox as cost effective, this does not help. > Would your argument from TCO be any more effective if IBM bundled the STP and raised the base system price by the now cost of the STP? (It's possible; the number of line items has negative weight regardless of the bottom line.) But what's the business case for IBM? Would increased revenue per sale offset loss of sales in the non-STP niche market? And if an ISV provided clock steering software based on NTP, would this, Neon-like, violate any IBM legal constraints? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
I agree about the z needing to be cost effective. However, can you say "cash cow"? IBM, et al., are killing the goose that laid their golden egg. What is "amusing" to me is that the IBM PC is what took Intel, and others, from the home hobbist into the enterprise. And this is what is helping to destroy IBM's historic base. IMO, the IBM "X series" is just another Dell machine, or other "first tier" supplier. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Conway > Sent: Monday, March 05, 2012 9:19 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Why _TZ put times 7 minutes off? > > Ed Jaffe said: > IMHO, STP should be included in the price of the machine. > > I totally agree. There should also be an option to use NTP. > Not every > shop needs the granularity of STP, and they damn sure don't > want to pay > for functionality that comes free on every other piece of > hardware in the > house.. > > Right now, the choices are either to pay $BIGNUM for time > keeping software > unique to the hardware platform or to have no time keeping software. > > When I'm trying to advocate a zBox as cost effective, this > does not help. > > > Steven F. Conway, CISSP > LA Systems > z/OS Systems Support > Phone: 703.295.1926 > steve_con...@ao.uscourts.gov > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
Ed Jaffe said: IMHO, STP should be included in the price of the machine. I totally agree. There should also be an option to use NTP. Not every shop needs the granularity of STP, and they damn sure don't want to pay for functionality that comes free on every other piece of hardware in the house.. Right now, the choices are either to pay $BIGNUM for time keeping software unique to the hardware platform or to have no time keeping software. When I'm trying to advocate a zBox as cost effective, this does not help. Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On 3/3/2012 12:13 PM, Paul Gilmartin wrote: On Sat, 3 Mar 2012 10:39:32 +0100, R.S. wrote: W dniu 2012-03-03 07:34, Edward Jaffe pisze: IMHO, STP should be included in the price of the machine. Or at least "STP light" which would allow to use ETS (NTP). However it's NOT incluted. :-( I like that idea. Is the hardware associated with STP physically disabled until the customer pays for the feature? If not, is the hardware sufficiently described in the PoOp (PrOp) that such an interface to NTP could be developed by an ISV, or even privately and contributed to cbttape? (No, I'm not volunteering.) If I understand the PoOp correctly, the clock steering instructions are not available to LPAR mode, but only to BASIC mode. For some time now only LPAR mode has been available to customers, so clock steering can't be done by customer code. If there is some way to switch to BASIC mode (maybe a DIAG) then perhaps it could be done. I would also vote to make STP a standard feature, but I don't think IBM is taking votes right now. :-) -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Sat, 3 Mar 2012 10:39:32 +0100, R.S. wrote: >W dniu 2012-03-03 07:34, Edward Jaffe pisze: >> >> IMHO, STP should be included in the price of the machine. > >Or at least "STP light" which would allow to use ETS (NTP). >However it's NOT incluted. :-( > I like that idea. Is the hardware associated with STP physically disabled until the customer pays for the feature? If not, is the hardware sufficiently described in the PoOp (PrOp) that such an interface to NTP could be developed by an ISV, or even privately and contributed to cbttape? (No, I'm not volunteering.) What does Linux for z use for clock steering? I understand it was never ETR-savvy (nor was z/VM?) I imagine it might be done by letting the ETOD clock run free and allowing NTP to update parameters of a software offset used by all system time services (kinda like CVTLSO). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Edward Jaffe > Sent: Friday, March 02, 2012 10:35 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Why _TZ put times 7 minutes off? > > On 3/2/2012 8:25 PM, Joel C. Ewing wrote: > > Particularly now that STP is just a matter of code rather than > > hardware, it makes less and less sense (from the customer's viewpoint > > of course) for this to be a chargeable feature, which was still the > > case when I last checked. As long as it is a chargeable feature it > is > > hard to cost-justify unless you are running a multi-system sysplex > > environment that requires it or you have some unusual requirement > that > > really demands your TOD clock be that accurate. That it is the "best > > practice" and the only sure way for keeping the TOD clock accurate > > makes it nice to have for a number of reasons; but if management asks > > if it is a "must have" additional expense or a feature you can live > without, in many cases the latter response must be given. > > IMHO, STP should be included in the price of the machine. > Agreed. The fact that syncing time cost money is one of the more egregious difficulties in explaining why mainframes are a good idea. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
W dniu 2012-03-03 07:34, Edward Jaffe pisze: On 3/2/2012 8:25 PM, Joel C. Ewing wrote: Particularly now that STP is just a matter of code rather than hardware, it makes less and less sense (from the customer's viewpoint of course) for this to be a chargeable feature, which was still the case when I last checked. As long as it is a chargeable feature it is hard to cost-justify unless you are running a multi-system sysplex environment that requires it or you have some unusual requirement that really demands your TOD clock be that accurate. That it is the "best practice" and the only sure way for keeping the TOD clock accurate makes it nice to have for a number of reasons; but if management asks if it is a "must have" additional expense or a feature you can live without, in many cases the latter response must be given. IMHO, STP should be included in the price of the machine. Or at least "STP light" which would allow to use ETS (NTP). However it's NOT incluted. :-( -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On 3/2/2012 8:25 PM, Joel C. Ewing wrote: Particularly now that STP is just a matter of code rather than hardware, it makes less and less sense (from the customer's viewpoint of course) for this to be a chargeable feature, which was still the case when I last checked. As long as it is a chargeable feature it is hard to cost-justify unless you are running a multi-system sysplex environment that requires it or you have some unusual requirement that really demands your TOD clock be that accurate. That it is the "best practice" and the only sure way for keeping the TOD clock accurate makes it nice to have for a number of reasons; but if management asks if it is a "must have" additional expense or a feature you can live without, in many cases the latter response must be given. IMHO, STP should be included in the price of the machine. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
Doesn't hurt to train the OPER's on 'What NOT to DO' either. In a message dated 3/2/2012 10:26:18 P.M. Central Standard Time, jcew...@acm.org writes: but if management asks if it is a "must have" additional expense or a feature you can live without, in many cases the latter response must be given. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On 03/02/2012 09:41 PM, George Kozakos wrote: On 02/03/2012 08:36 PM, Joel C. Ewing wrote: In absence of sysplex timer or the like, the processor TOD clock is set only at POR and is set based on the HMC clock, which may in turn sync once a day with the SE clock. The SE is sync'd to the CEC TOD and the HMC is sync'd to the SE. The SE is sync'd to the CEC TOD every 24 hours, 4 hours or 1 hour depending on MCL level. The current best practice is to keep the CEC TOD accurate via an external time source which in turn keeps the SE and HMC accurate. This requires STP or sysplex timers. George Kozakos z/OS Software Service, Level 2 Supervisor The CEC sync on more recent machines had slipped my memory. On those systems, to see a significant jump in TOD time at POR, one would have to manually set the SE time, do a poor job of it, and do it close enough to POR so SE time doesn't get reset by the CEC TOD, yet far enough away (several minutes?) to be sure it propagated to HMC. Particularly now that STP is just a matter of code rather than hardware, it makes less and less sense (from the customer's viewpoint of course) for this to be a chargeable feature, which was still the case when I last checked. As long as it is a chargeable feature it is hard to cost-justify unless you are running a multi-system sysplex environment that requires it or you have some unusual requirement that really demands your TOD clock be that accurate. That it is the "best practice" and the only sure way for keeping the TOD clock accurate makes it nice to have for a number of reasons; but if management asks if it is a "must have" additional expense or a feature you can live without, in many cases the latter response must be given. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On 02/03/2012 08:36 PM, Joel C. Ewing wrote: > In absence of sysplex timer or the like, the processor TOD clock is set > only at POR and is set based on the HMC clock, which may in turn sync > once a day with the SE clock. The SE is sync'd to the CEC TOD and the HMC is sync'd to the SE. The SE is sync'd to the CEC TOD every 24 hours, 4 hours or 1 hour depending on MCL level. The current best practice is to keep the CEC TOD accurate via an external time source which in turn keeps the SE and HMC accurate. This requires STP or sysplex timers. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On Fri, 2 Mar 2012 19:31:55 -0600, Joel C. Ewing wrote: >On 03/02/2012 06:44 PM, Charles Mills wrote: >> And the answer from those who know is >> >> "It happened during the POR last Thursday and we're talking with IBM to >> figure out why a POR would do that to us." >> >> Thanks all for your patience with YATQ (yet another time question). >> >> Charles >> > >In absence of sysplex timer or the like, the processor TOD clock is set >only at POR and is set based on the HMC clock, which may in turn sync >once a day with the SE clock. If you don't have any procedure to sync >the HMC/SE clocks to UTC or verify they are reasonably accurate when you >know a POR is imminent, odds are they have drifted from reality and a >POR will propagate that error to the processor TOD clock, which in turn >propagates to all LPAR TOD clocks as they are activated. It would seem >your operators must be setting local time explicitly at IPL (rather than >using a fixed offset from TOD), or the error would have been more >obvious after the IPL.My recollection is it has worked this way ever >since IBM mainframes have had HMCs for control. > And the fun part is, I think it takes another POR to get things all synched up. Does anyone else see anything wrong with this picture? -- gii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
On 03/02/2012 06:44 PM, Charles Mills wrote: And the answer from those who know is "It happened during the POR last Thursday and we're talking with IBM to figure out why a POR would do that to us." Thanks all for your patience with YATQ (yet another time question). Charles In absence of sysplex timer or the like, the processor TOD clock is set only at POR and is set based on the HMC clock, which may in turn sync once a day with the SE clock. If you don't have any procedure to sync the HMC/SE clocks to UTC or verify they are reasonably accurate when you know a POR is imminent, odds are they have drifted from reality and a POR will propagate that error to the processor TOD clock, which in turn propagates to all LPAR TOD clocks as they are activated. It would seem your operators must be setting local time explicitly at IPL (rather than using a fixed offset from TOD), or the error would have been more obvious after the IPL.My recollection is it has worked this way ever since IBM mainframes have had HMCs for control. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
And the answer from those who know is "It happened during the POR last Thursday and we're talking with IBM to figure out why a POR would do that to us." Thanks all for your patience with YATQ (yet another time question). Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
Local time is right. The hardware clock is 7 minutes fast. CLOCK00: OPERATOR NOPROMPT TIMEZONE W.05.07.00 ETRMODE YES ETRZONE NO ETRDELTA 10 SIMETRID 00 Why would a shop do this? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Don Poitras Sent: Friday, March 02, 2012 4:14 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why _TZ put times 7 minutes off? It probably means that an operator reset the local time at the console. Or someone placed an odd value in your SYS1.PARMLIB(CLOCKxx) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
It probably means that an operator reset the local time at the console. Or someone placed an odd value in your SYS1.PARMLIB(CLOCKxx) In article <07f601ccf8d1$6c093da0$441bb8e0$@mcn.org> you wrote: > 12062 19:01:40.12 TSU02110 0090 IEE136I LOCAL: TIME=19.01.40 > DATE=2012.062 UTC: TIME=00.08.40 > DATE=2012.063 > Well, by George, I think you've got it. They have UTC set 7 minutes ahead of > reality. > Does this make sense to anyone? > I will inquire of our powers that be. > I only wasted about two hours on this thinking it was my bug somehow. > Charles > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf > Of Bob Rutledge > Sent: Friday, March 02, 2012 3:55 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Why _TZ put times 7 minutes off? > What does the "d t" command return? -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
12062 19:01:40.12 TSU02110 0090 IEE136I LOCAL: TIME=19.01.40 DATE=2012.062 UTC: TIME=00.08.40 DATE=2012.063 Well, by George, I think you've got it. They have UTC set 7 minutes ahead of reality. Does this make sense to anyone? I will inquire of our powers that be. I only wasted about two hours on this thinking it was my bug somehow. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bob Rutledge Sent: Friday, March 02, 2012 3:55 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why _TZ put times 7 minutes off? What does the "d t" command return? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
FWIW, if I set _TZ to "EST5:07EDT" then all of my output is correct. ??? Makes no sense. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Friday, March 02, 2012 2:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why _TZ put times 7 minutes off? Charles, I was curios about what was going on...it could be a bug .. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
Charles Mills wrote:
Sorry if people feel that times have been beaten to death.
Environment is started task.
In accordance with an earlier thread I am setting _TZ to 'EST5EDT' rather
than the configured null so that strftime("%z") works as expected.
I just discovered that that is throwing my local times off by 7 minutes.
Does that make ANY sense to anyone?
The times in question are coming from the following logic:
tm* tmStruct;
struct timeb timebuffer;
ftime(&timebuffer);
tmStruct = localtime(&timebuffer.time);
I use ftime because I am also using the milliseconds. (I have a exactly the
same problem with times derived from STCK, so the ftime is not the problem.)
Initially the times are correct. However, after I issue
int seRes = setenv("_TZ", "EST5EDT", 1);
the times are off by exactly seven minutes. (Result time 7 minutes later or
greater than actual.)
Does that make sense to anyone? Any clues?
What does the "d t" command return?
Bob
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
Charles, I was curios about what was going on...it could be a bug .. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 2, 2012, at 5:43 PM, Charles Mills wrote: > PST -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
> Whats happening in your code between the two Darned little. I can parametize whether I set _TZ or not and what I set it to and so it is easy to run debugging experiments. I can run the code with or without setting _TZ, and it works fine if I do not set _TZ. There is nothing else that I do "along with" setting _TZ. It's a pretty pure situation. Do bugs happen? Have I ever been wrong before? Do I know about "but I didn't touch that part of the code"? Yes, of course. But I don't know what I could be doing to make my times 7 minutes off with some stupid internal bug. There is almost nothing between the ftime and the strftime. I would have to have a += 420 or a += 7 in there to account for it. I don't do any arithmetic at all between ftime and strftime. I just ran an experiment it which I ran through all of my setenv logic but set _TZ to "" -- no effect on the times; the times are correct. I tried setting it to PST8PDT -- same problem, seven minutes ahead of PST. I tried setting it to FOO -- no effect on times; the times are correct. It seems pretty unlikely that it is some side-effect in my code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Friday, March 02, 2012 2:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why _TZ put times 7 minutes off? Charles, Whats happening in your code between the two -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
Charles, Whats happening in your code between the two Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 2, 2012, at 4:58 PM, Charles Mills wrote: > off? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
> I would suggest that the HW clock is 7 minutes off of GMT
What then would account for my times being right before I issue the setenv,
and the times being right everywhere else (such as system message
timestamps).
That's a serious question -- how could that be?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Staller, Allan
Sent: Friday, March 02, 2012 1:40 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why _TZ put times 7 minutes off?
In accordance with an earlier thread I am setting _TZ to 'EST5EDT'
rather
than the configured null so that strftime("%z") works as expected.
I just discovered that that is throwing my local times off by 7 minutes.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
> Are you comparing your results to the time in the system console?
I'm comparing my results to the timestamps on the system messages in the job
log (and also comparing my "after setenv" times to my "before setenv"
times).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Mike Schwab
Sent: Friday, March 02, 2012 1:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why _TZ put times 7 minutes off?
Are you comparing your results to the time in the system console?
On Fri, Mar 2, 2012 at 3:33 PM, Charles Mills wrote:
> Sorry if people feel that times have been beaten to death.
>
> Environment is started task.
>
> In accordance with an earlier thread I am setting _TZ to 'EST5EDT'
> rather than the configured null so that strftime("%z") works as expected.
>
> I just discovered that that is throwing my local times off by 7 minutes.
> Does that make ANY sense to anyone?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
I would suggest that the HW clock is 7 minutes off of GMT
In accordance with an earlier thread I am setting _TZ to 'EST5EDT'
rather
than the configured null so that strftime("%z") works as expected.
I just discovered that that is throwing my local times off by 7 minutes.
Does that make ANY sense to anyone?
The times in question are coming from the following logic:
tm* tmStruct;
struct timeb timebuffer;
ftime(&timebuffer);
tmStruct = localtime(&timebuffer.time);
I use ftime because I am also using the milliseconds. (I have a exactly
the
same problem with times derived from STCK, so the ftime is not the
problem.)
Initially the times are correct. However, after I issue
int seRes = setenv("_TZ", "EST5EDT", 1);
the times are off by exactly seven minutes. (Result time 7 minutes
later or
greater than actual.)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
Are you comparing your results to the time in the system console?
On Fri, Mar 2, 2012 at 3:33 PM, Charles Mills wrote:
> Sorry if people feel that times have been beaten to death.
>
> Environment is started task.
>
> In accordance with an earlier thread I am setting _TZ to 'EST5EDT' rather
> than the configured null so that strftime("%z") works as expected.
>
> I just discovered that that is throwing my local times off by 7 minutes.
> Does that make ANY sense to anyone?
>
> The times in question are coming from the following logic:
>
> tm* tmStruct;
> struct timeb timebuffer;
> ftime(&timebuffer);
> tmStruct = localtime(&timebuffer.time);
>
> I use ftime because I am also using the milliseconds. (I have a exactly the
> same problem with times derived from STCK, so the ftime is not the problem.)
>
> Initially the times are correct. However, after I issue
>
> int seRes = setenv("_TZ", "EST5EDT", 1);
>
> the times are off by exactly seven minutes. (Result time 7 minutes later or
> greater than actual.)
>
> Does that make sense to anyone? Any clues?
>
> Charles
--
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...@bama.ua.edu with the message: INFO IBM-MAIN
Why _TZ put times 7 minutes off?
Sorry if people feel that times have been beaten to death.
Environment is started task.
In accordance with an earlier thread I am setting _TZ to 'EST5EDT' rather
than the configured null so that strftime("%z") works as expected.
I just discovered that that is throwing my local times off by 7 minutes.
Does that make ANY sense to anyone?
The times in question are coming from the following logic:
tm* tmStruct;
struct timeb timebuffer;
ftime(&timebuffer);
tmStruct = localtime(&timebuffer.time);
I use ftime because I am also using the milliseconds. (I have a exactly the
same problem with times derived from STCK, so the ftime is not the problem.)
Initially the times are correct. However, after I issue
int seRes = setenv("_TZ", "EST5EDT", 1);
the times are off by exactly seven minutes. (Result time 7 minutes later or
greater than actual.)
Does that make sense to anyone? Any clues?
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
