Question of UTC vs Local Time
Has anyone moved from Local time (EST) to UTC with zLinux?? Any comments or experiences to share? One of our upper level managers want us to look at what it will take to move everything that is on Local time (Linux zOS) to UTC. From a systems point of view I cannot think of an impact, just on in house applications., that have self written timestamps. James Chaplin Systems Programmer, MVS, zVM zLinux -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Question of UTC vs Local Time
On Tue, 29 Nov 2011 12:37:56 -0500 CHAPLIN, JAMES (CTR) james.chap...@cbp.dhs.gov wrote: Has anyone moved from Local time (EST) to UTC with zLinux?? Any comments or experiences to share? Linux has no real notion of local time in the kernel or system. Local time is a conversion handled in userspace and the conversions are done based upon the users own time settings. System time is seconds since 1/1/70 midnight. It's done this way because you can often have users in multiple time zones on the box at the same time. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Question of UTC vs Local Time
If you're application is requesing local time and you set up the TIMEZONE information correctly, then I doubt you'd see any problem. The problems occur if the application requests GMT time or does the assembler STCK or STCKE instruction to get the TOD clock from the hardware directly. You mentioned z/OS, which I'm better at than z/Linux. The only problem that I can foresee is if you change the TOD clock to move backwards and your running in a z/OS sysplex. You __cannot__ back up the TOD clock in a sysplex. Period. End of discussion. There are two things which you can do. One is to simply wait for n hours for the GMT version of the TOD clock to move forward from the local TOD clock time (US EST would be a 5 hour wait). This is not likely to go over well with management. grin. The reasonable thing to do is to create an entirely new, and unused, version of all your couple datasets and use the new versions on the IPL after the TOD is set to GMT. Oh, and watch out for database software such as DB2. It uses TOD timestamps instead of local time. But I don't know enough about DB2 to know what happens if the TOD backs up. I will allow the gurus of Linux to talk about the impact in Linux. I'm too ignorant. -- 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: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of CHAPLIN, JAMES (CTR) Sent: Tuesday, November 29, 2011 11:38 AM To: LINUX-390@VM.MARIST.EDU Subject: Question of UTC vs Local Time Has anyone moved from Local time (EST) to UTC with zLinux?? Any comments or experiences to share? One of our upper level managers want us to look at what it will take to move everything that is on Local time (Linux zOS) to UTC. From a systems point of view I cannot think of an impact, just on in house applications., that have self written timestamps. James Chaplin Systems Programmer, MVS, zVM zLinux -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Question of UTC vs Local Time
The sysplex is a big issue at our shop, so this will be interesting, more so than the Y2K eleven years ago ;-). Thanks for responding. James Chaplin Systems Programmer, MVS, zVM zLinux Base Technologies, a CA Technologies Company -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of McKown, John Sent: Tuesday, November 29, 2011 2:05 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question of UTC vs Local Time If you're application is requesing local time and you set up the TIMEZONE information correctly, then I doubt you'd see any problem. The problems occur if the application requests GMT time or does the assembler STCK or STCKE instruction to get the TOD clock from the hardware directly. You mentioned z/OS, which I'm better at than z/Linux. The only problem that I can foresee is if you change the TOD clock to move backwards and your running in a z/OS sysplex. You __cannot__ back up the TOD clock in a sysplex. Period. End of discussion. There are two things which you can do. One is to simply wait for n hours for the GMT version of the TOD clock to move forward from the local TOD clock time (US EST would be a 5 hour wait). This is not likely to go over well with management. grin. The reasonable thing to do is to create an entirely new, and unused, version of all your couple datasets and use the new versions on the IPL after the TOD is set to GMT. Oh, and watch out for database software such as DB2. It uses TOD timestamps instead of local time. But I don't know enough about DB2 to know what happens if the TOD backs up. I will allow the gurus of Linux to talk about the impact in Linux. I'm too ignorant. -- 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: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of CHAPLIN, JAMES (CTR) Sent: Tuesday, November 29, 2011 11:38 AM To: LINUX-390@VM.MARIST.EDU Subject: Question of UTC vs Local Time Has anyone moved from Local time (EST) to UTC with zLinux?? Any comments or experiences to share? One of our upper level managers want us to look at what it will take to move everything that is on Local time (Linux zOS) to UTC. From a systems point of view I cannot think of an impact, just on in house applications., that have self written timestamps. James Chaplin Systems Programmer, MVS, zVM zLinux -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Howto automagically configure for Layer 2 or 3
On 11/24/2011 at 09:59 AM, Agblad Tore tore.agb...@volvo.com wrote: Hi again. I have these tricky things showing up all the time :) I have looked here and there but I don't find the answer to this question: /etc/udev/rules.d contains rules, but as they have persistent in the name I get suspicious. and I don't fully understand how these rules are used and when All udev rules are used when the kernel generates events that udev listens for and then processes. The persistent in the name means that those rules will ensure that a given device will be given the same name across a reboot. In the past, that was not guaranteed, so during one boot, a NIC could be eth0, and the next eth1, and so on. When a RHEL6 starts and activates the network adapter, does it know if it is layer 2 or 3 and is that info used to update /etc/sysconfig/network-scripts/ifcfg-eth0 ? I doubt it very much. Typically, the knowledge of whether a NIC is layer 2 or 3 is provided by whomever does the installation, and the installer records that in ifcfg-eth?, or in the udev rules (depending on what level of the OS you're running) for future reference. For example, on my SLES11 guest, I have a /etc/udev/rules.d/51-qeth-0.0.0800.rules, and inside is this line (among many others): ACTION==add, SUBSYSTEM==ccwgroup, KERNEL==0.0.0800, ATTR{layer2}=1 My /etc/sysconfig/network/ifcfg-eth? file does _not_ have any reference to layer2 at all. -snip- Maybe we will switch to layer 2 later, and if so we want the servers to automagically configure itself. I would strongly recommend that any such change should be made manually, not automatically. Too much potential for problems. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Question of UTC vs Local Time
On Tue, 29 Nov 2011 14:23:37 -0500 CHAPLIN, JAMES (CTR) james.chap...@cbp.dhs.gov wrote: The sysplex is a big issue at our shop, so this will be interesting, more so than the Y2K eleven years ago ;-). Thanks for responding. If you are doing a review of time handling in your Linux/Unix apps as part of this you might also want to look at anything 32bit using Unix type time, or anyone storing a unix time in a 4 byte field. Four byte (ie 32bit) unix time ends in 2038 and the chances are it's going to be as unpleasant as Y2K if not more so because it'll be all the embedded old stuff that keels over along with any 32bit apps. 64bit Unix time will be good till long after the milky way crashes into our neighbour galaxy and a bit more. Alan -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Question of UTC vs Local Time
On Tue, 29 Nov 2011 13:04:55 -0600 McKown, John wrote: One is to simply wait for n hours for the GMT version of the TOD clock to move forward from the local TOD clock time (US EST would be a 5 hour wait). This is not likely to go over well with management. grin. - We looked at this (in a z/OS not zLinux context) a few years back - n in this case was 10. No-go; even looked at 2 or 3 smaller jumps. All too hard. Not much later the site took a significant outage - redundant power feeds to a DASD controller were found not to be. Several hours later it all came back online. If only we could co-ordinate these things ;-) Shane ... -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/