Re: Efficient conversion of GMT to/from local time from COBOL?
Is it too soon to pat ourselves on our collective back for surviving the fall back from xDT to xST with nary a post on the subject? My cellphone provider finally changed the network time at around 0600 this morning. My cable provider was ahead of the game; its network time never did spring forward 8 months ago, so no fall back was required. ;-) Date: Thu, 30 Oct 2008 19:06:33 -0400 From: [EMAIL PROTECTED] Subject: Re: Efficient conversion of GMT to/from local time from COBOL? To: IBM-MAIN@BAMA.UA.EDU But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. The more I think about this, the less sense it makes. The thing that saves the children from going to school in the dark is *standard time*, not DST. So, if we stayed on standard time all year, the kids would be alright. It's DST that screws everything up! What DST does is get us out of bed an hour earlier in the spring and summer months. That's the daylight saved -- the hour that we would otherwise spend lying in bed sleeping (or whatever). So DST shifts an hour of daylight from the early morning to the afternoon/evening. Standard time gives the kids their best chance of going to school and coming home in daylight during the months when daylight is at its shortest. Date: Thu, 30 Oct 2008 16:17:26 + From: [EMAIL PROTECTED] Subject: Re: Efficient conversion of GMT to/from local time from COBOL? To: IBM-MAIN@BAMA.UA.EDU Heck, I wish Daylight Savings Time would go away, and wouldn't be averse if local time would go away. China is on one time zone and it doesn't hurt them. So, is India. But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. - Too busy driving to stop for gas! _ When your life is on the go—take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of J R But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. [ snip ] Standard time gives the kids their best chance of going to school and coming home in daylight during the months when daylight is at its shortest. When I was a child in Fairbanks, we went to school in the dark and came home in the dark. Heck, we even ate lunch in the dark! -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
When I was a child in Fairbanks, we went to school in the dark and came home in the dark. Heck, we even ate lunch in the dark! Uphill both ways? Date: Fri, 31 Oct 2008 07:18:44 -0500 From: [EMAIL PROTECTED] Subject: Re: Efficient conversion of GMT to/from local time from COBOL? To: IBM-MAIN@BAMA.UA.EDU -Original Message- From: IBM Mainframe Discussion List On Behalf Of J R But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. [ snip ] Standard time gives the kids their best chance of going to school and coming home in daylight during the months when daylight is at its shortest. When I was a child in Fairbanks, we went to school in the dark and came home in the dark. Heck, we even ate lunch in the dark! -jc- _ When your life is on the go—take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
On Fri, 2008-10-31 at 08:25 -0400, J R wrote: When I was a child in Fairbanks, we went to school in the dark and came home in the dark. Heck, we even ate lunch in the dark! Uphill both ways? Shoebox ... shoebox - did some-one mention a shoebox ???. . . . And you try and tell the young people of today that . they won't believe you. :0) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of J R When I was a child in Fairbanks, we went to school in the dark and came home in the dark. Heck, we even ate lunch in the dark! Uphill both ways? Of course! It was COLD, too! -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
Alright Shane! What does the shoebox have to do with anything? Eric Shane [EMAIL PROTECTED] wrote: On Fri, 2008-10-31 at 08:25 -0400, J R wrote: When I was a child in Fairbanks, we went to school in the dark and came home in the dark. Heck, we even ate lunch in the dark! Uphill both ways? Shoebox ... shoebox - did some-one mention a shoebox ???. And you try and tell the young people of today that . they won't believe you. -- Eric Bielefeld Systems Programmer Washington University St Louis, Missouri 314-935-3418 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
It's from a Monty Python skit about how tough things were when I were a boy. Date: Fri, 31 Oct 2008 08:44:11 -0600 From: [EMAIL PROTECTED] Subject: Re: Efficient conversion of GMT to/from local time from COBOL? To: IBM-MAIN@BAMA.UA.EDU Alright Shane! What does the shoebox have to do with anything? Eric Shane [EMAIL PROTECTED] wrote: On Fri, 2008-10-31 at 08:25 -0400, J R wrote: When I was a child in Fairbanks, we went to school in the dark and came home in the dark. Heck, we even ate lunch in the dark! Uphill both ways? Shoebox ... shoebox - did some-one mention a shoebox ???. And you try and tell the young people of today that . they won't believe you. -- Eric Bielefeld _ Want to read Hotmail messages in Outlook? The Wordsmiths show you how. http://windowslive.com/connect/post/wedowindowslive.spaces.live.com-Blog-cns!20EE04FBC541789!167.entry?ocid=TXT_TAGLM_WL_hotmail_092008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
On Thu, 30 Oct 2008 10:48:29 -0400, J R wrote: I wish all computers did time-date stamps in Zulu, and only translated to local time as needed. Hear, hear! +1 (Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away.) Hear, hear! Unrealistic. When in Rome (or Indiana, or Arizona), ... BTW, I always feel sorry for the Zulus -- there's a time zone out there with their name on it and it's not theirs. :-( Date: Thu, 30 Oct 2008 08:06:41 -0600 From: howard.brazee On 30 Oct 2008 03:11:32 -0700, (Paul Gilmartin) wrote: Will these get the Daylight Saving Time offset correct for dates both before and after 2006 (in the U.S.)? Will these get the Leap Second offset correct for dates back to 1972 when leap seconds were instituted? (How do Lilian seconds account for Leap Seconds? If done correctly there's a simple affine conversion from (E)TOD values to Lilian seconds.) I'm curious. What business needs do you have that require past Daylight Savings Times and leap seconds? I'm not on the business side so I can only conjecture. But I can readily imagine legal consequences depending on whether a prior event occurred before or after midnight. The conversion is not rocket science. Most Unix systems with which I have worked correctly convert GMT to civil time for dates back to 1970, and for time zones around the world. z/OS Unix is correct only back to 2007 (in the U.S.), and Classic z/OS knows only the current offset, and for only a single time zone other than GMT (or does LE do better, nowadays?) Leap seconds are a PITA. I'd like to reflect your question to IBM: What customers' business needs was IBM addressing in choosing to run the TOD clock on IAT (minus ten seconds), rather than on UT1 which would avoid the discontinuities of leap seconds. While IBM is ahead of the crowd in recognizing leap seconds, the implementation is lackadaisical. An enthusiastically faithful implementation would, when TIME was called in the middle of a leap second, return 23:59:60.500, the correct UTC. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Leap Seconds, was Efficient conversion of GMT to/from local time from COBOL?
Maybe leap seconds won't be an issue: http://tycho.usno.navy.mil/leap_second_poll.html Alan Leap seconds are a PITA. I'd like to reflect your question to IBM: What customers' business needs was IBM addressing in choosing to run the TOD clock on IAT (minus ten seconds), rather than on UT1 which would avoid the discontinuities of leap seconds. While IBM is ahead of the crowd in recognizing leap seconds, the implementation is lackadaisical. An enthusiastically faithful implementation would, when TIME was called in the middle of a leap second, return 23:59:60.500, the correct UTC. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Leap Seconds, was Efficient conversion of GMT to/from local time from COBOL?
The origin of the leap second is the moon, blame Mother Nature. Our clocks are too accurate. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Field, Alan C. Sent: Friday, October 31, 2008 10:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Leap Seconds, was Efficient conversion of GMT to/from local time from COBOL? Maybe leap seconds won't be an issue: http://tycho.usno.navy.mil/leap_second_poll.html Alan Leap seconds are a PITA. I'd like to reflect your question to IBM: What customers' business needs was IBM addressing in choosing to run the TOD clock on IAT (minus ten seconds), rather than on UT1 which would avoid the discontinuities of leap seconds. While IBM is ahead of the crowd in recognizing leap seconds, the implementation is lackadaisical. An enthusiastically faithful implementation would, when TIME was called in the middle of a leap second, return 23:59:60.500, the correct UTC. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Leap Seconds, was Efficient conversion of GMT to/from local time from COBOL?
On Fri, 31 Oct 2008 10:06:17 -0500, Field, Alan C. wrote: Maybe leap seconds won't be an issue: http://tycho.usno.navy.mil/leap_second_poll.html The referenced document: Linkname: Memorandum and white paper URL: http://tycho.usno.navy.mil/Discontinuance_of_Leap_Second_Adjustments.pdf ... mentions 3 requirements: 1) Atomic accuracy 2) Continuity 3) Agreement with earth's rotation. IAT satisfies (1) and (2) but not (3). UTC satisfies (1) and (3) but not (2). UT1 satisfies (2) and (3) but not (1). It's logically impossible to satisfy all three at once. Of the three approaches, I see the least need for UTC. I'd favor abolishing UTC rather than freezing it and abolishing the sporadic insertion of leap seconds. Leap seconds are a PITA. I'd like to reflect your question to IBM: What customers' business needs was IBM addressing in choosing to run the TOD clock on IAT (minus ten seconds), rather than on UT1 which would avoid the discontinuities of leap seconds. In that case, the [E]TOD clock should run on UT1, with system calls available to convert to IAT in the past and for as far in the future as the offset can be known with satisfactory accuracy. How about a chordwise rather than a stepwise approximation to UT1, retaining the current 4-month advance notification of parameter updates, where there would be 2 parameters, slope and offset, rather than the current offset only? IBM could even do this unilaterally for [E]TOD purposes. The earth's equatorial rotational velocity is about 500 m/sec. The guaranteed maximum UT1-UTC offset is 0.9 seconds. So using UTC for geolocation could result in an error of 400 meters; inferior to GPS accuracy. What use UTC? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
Peter Farley writes: ...recently it has become more prudent to consider the maintenance costs and available knowledge down the road after our generation retires. Using documented, standard LE functions may not be as efficient as the assembler solution, but won't require an assembler programmer to maintain it 10 years hence. That makes a lot of sense to me. Avoid needless coding. At least as something to think about, could you turn these date conversion functions into enterprise services, so that they're available universally to anyone in your organization in their applications, regardless of language or environment? If you do not want to reinvent a common function, chances are excellent others have the same issue. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
On Wed, 29 Oct 2008 14:19:27 -0500, John McKown wrote: Is there a z/OS-supplied function to convert GMT to local time (or back again)? Yes. Look in the Language Environment manual, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3100/CCONTENTS watch out for the wrap!! CEECBLDY will convert various character representations of dates into COBOL Integer Date formats. CEEGMTO will tell you the difference between GMT and LOCAL time. CEESECS will convert date+time to a timestamp in Lilian seconds (since 00:00:00 14 Oct 1582) which you can then manipulate and convert back. Will these get the Daylight Saving Time offset correct for dates both before and after 2006 (in the U.S.)? Will these get the Leap Second offset correct for dates back to 1972 when leap seconds were instituted? (How do Lilian seconds account for Leap Seconds? If done correctly there's a simple affine conversion from (E)TOD values to Lilian seconds.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
On 30 Oct 2008 03:11:32 -0700, [EMAIL PROTECTED] (Paul Gilmartin) wrote: Will these get the Daylight Saving Time offset correct for dates both before and after 2006 (in the U.S.)? Will these get the Leap Second offset correct for dates back to 1972 when leap seconds were instituted? (How do Lilian seconds account for Leap Seconds? If done correctly there's a simple affine conversion from (E)TOD values to Lilian seconds.) I'm curious. What business needs do you have that require past Daylight Savings Times and leap seconds? I wish all computers did time-date stamps in Zulu, and only translated to local time as needed. (Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away. China is on one time zone and it doesn't hurt them). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
I wish all computers did time-date stamps in Zulu, and only translated to local time as needed. Hear, hear! (Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away.) Hear, hear! BTW, I always feel sorry for the Zulus -- there's a time zone out there with their name on it and it's not theirs. :-( Date: Thu, 30 Oct 2008 08:06:41 -0600 From: [EMAIL PROTECTED] Subject: Re: Efficient conversion of GMT to/from local time from COBOL? To: IBM-MAIN@BAMA.UA.EDU On 30 Oct 2008 03:11:32 -0700, [EMAIL PROTECTED] (Paul Gilmartin) wrote: Will these get the Daylight Saving Time offset correct for dates both before and after 2006 (in the U.S.)? Will these get the Leap Second offset correct for dates back to 1972 when leap seconds were instituted? (How do Lilian seconds account for Leap Seconds? If done correctly there's a simple affine conversion from (E)TOD values to Lilian seconds.) I'm curious. What business needs do you have that require past Daylight Savings Times and leap seconds? I wish all computers did time-date stamps in Zulu, and only translated to local time as needed. (Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away. China is on one time zone and it doesn't hurt them). _ Store, manage and share up to 5GB with Windows Live SkyDrive. http://skydrive.live.com/welcome.aspx?provision=1?ocid=TXT_TAGLM_WL_skydrive_102008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Thursday, October 30, 2008 4:20 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Efficient conversion of GMT to/from local time from COBOL? Peter Farley writes: ...recently it has become more prudent to consider the maintenance costs and available knowledge down the road after our generation retires. Using documented, standard LE functions may not be as efficient as the assembler solution, but won't require an assembler programmer to maintain it 10 years hence. That makes a lot of sense to me. Avoid needless coding. At least as something to think about, could you turn these date conversion functions into enterprise services, so that they're available universally to anyone in your organization in their applications, regardless of language or environment? If you do not want to reinvent a common function, chances are excellent others have the same issue. Well, probably not *entirely* regardless of environment. A common GMT conversion subroutine that used the LE functions to accomplish its task would certainly be possible and probably desireable. An enterprise service in the sense of SOA and/or CICS and/or Websphere would be overkill at this point. One client's input format for one batch process does not (yet) require an enterprise-wide solution. Now if *two* clients need it, then you begin to consider wider-area services. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away. China is on one time zone and it doesn't hurt them. So, is India. But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Efficient conversion of GMT to/from local time from COBOL?
There have been lots of replies referencing the LE callable date routines. Depending upon what type of date you are looking for, these may well be your best answer. HOWEVER, If all you want to do is know what the offset is from GMT of where your application is running, then you can easily just use native COBOL. See the CURRENT-DATE intrinsic function at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/7.1.15 Positions 17-21 will give you the exact offset from GMT. Unless your application is running in one of the time zones with 15 or 30 minute offsets from GMT, then converting from/to GMT becomes trivial without resorting to an LE callable service (much less a C or Assembler subroutine). If you are working with arbitrary times (not the current time) in odd or arbitrary formats, then the LE callable services are probably better and more flexible. Farley, Peter x23353 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]. .. Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? Now, I don't yet know in what format the GMT is arriving for conversion, but it is very likely NOT in STCK(E) format but rather in some external character format. I know I can write a small C routine to convert character format GMT to time.h format and then use localtime(clock) to perform the conversion from GMT to local time, or gmtime(clock) to go the other way. BUT the question is, when called from COBOL will that small C routine set up and tear down the C environment every time it's called? If so, is there a way to make those calls to a C function from COBOL more efficient? Or am I barking up the wrong tree because there's another/better/simpler way to do this conversion? Obviously I could also write assembler to convert the character format GMT to STCK(E) format with CONVTOD and then use the CVT fields to convert that value to local time and then STCKCONV to go back to character format, but I am hoping there is a simpler HLL-based solution. TIA for any help/info/RTFM you can provide. Environment is Enterprise COBOL 3.4, z/OS 1.8 if it matters. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Thursday, October 30, 2008 12:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Efficient conversion of GMT to/from local time from COBOL? Snipped If you are working with arbitrary times (not the current time) in odd or arbitrary formats, then the LE callable services are probably better and more flexible. Yes, that is the original requirement. Externally supplied (somewhat) arbitrary GMT input dates, probably within + or - 30 days of the current date, exact format yet to be determined. Thanks for the pointer to the COBOL function though. I'll keep that one in mind for other needs. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. But DST is not the only solution to that problem. Different hours of business depending on the time of year would also work. Date: Thu, 30 Oct 2008 16:17:26 + From: [EMAIL PROTECTED] Subject: Re: Efficient conversion of GMT to/from local time from COBOL? To: IBM-MAIN@BAMA.UA.EDU Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away. China is on one time zone and it doesn't hurt them. So, is India. But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. - Too busy driving to stop for gas! _ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
But DST is not the only solution to that problem. Different hours of business depending on the time of year would also work. People are mostly happy if the routine is not changed. DST is very disruptive to computers, but not to people. People would be much happier, if (for example) school always started at 9:00. DST plays to that lower common denominator. Me? I don't care. When I was employed, I always worked flexible hours. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
On 30 Oct 2008 09:20:03 -0700, [EMAIL PROTECTED] (Ted MacNEIL) wrote: Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away. China is on one time zone and it doesn't hurt them. So, is India. But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. Those problems are based upon stupid bureaucracy. Don't change the clocks, change the stated time they should be at school. I get up in the dark - so I have more daylight after work. Some people live by ESPN time now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
Those problems are based upon stupid bureaucracy. NO. As I stated earlier people like routine. Especially children. Don't change the clocks, change the stated time they should be at school. Won't work. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
On 30 Oct 2008 10:34:56 -0700, [EMAIL PROTECTED] (Ted MacNEIL) wrote: But DST is not the only solution to that problem. Different hours of business depending on the time of year would also work. People are mostly happy if the routine is not changed. DST is very disruptive to computers, but not to people. Even with DST, businesses that care about daylight - such as golf courses, change their hours. People would be much happier, if (for example) school always started at 9:00. DST plays to that lower common denominator. Me? I don't care. When I was employed, I always worked flexible hours. 9:00 starts kill the whole day, and they often mean parents have to figure how to get to work even later. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. The more I think about this, the less sense it makes. The thing that saves the children from going to school in the dark is *standard time*, not DST. So, if we stayed on standard time all year, the kids would be alright. It's DST that screws everything up! What DST does is get us out of bed an hour earlier in the spring and summer months. That's the daylight saved -- the hour that we would otherwise spend lying in bed sleeping (or whatever). So DST shifts an hour of daylight from the early morning to the afternoon/evening. Standard time gives the kids their best chance of going to school and coming home in daylight during the months when daylight is at its shortest. Date: Thu, 30 Oct 2008 16:17:26 + From: [EMAIL PROTECTED] Subject: Re: Efficient conversion of GMT to/from local time from COBOL? To: IBM-MAIN@BAMA.UA.EDU Heck, I wish Daylight Savings Time would go away, and wouldn't be adverse if local time would go away. China is on one time zone and it doesn't hurt them. So, is India. But, it can/does cause some problems with things like young children going to (or coming from) school in the dark. - Too busy driving to stop for gas! _ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Efficient conversion of GMT to/from local time from COBOL?
Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? Now, I don't yet know in what format the GMT is arriving for conversion, but it is very likely NOT in STCK(E) format but rather in some external character format. I know I can write a small C routine to convert character format GMT to time.h format and then use localtime(clock) to perform the conversion from GMT to local time, or gmtime(clock) to go the other way. BUT the question is, when called from COBOL will that small C routine set up and tear down the C environment every time it's called? If so, is there a way to make those calls to a C function from COBOL more efficient? Or am I barking up the wrong tree because there's another/better/simpler way to do this conversion? Obviously I could also write assembler to convert the character format GMT to STCK(E) format with CONVTOD and then use the CVT fields to convert that value to local time and then STCKCONV to go back to character format, but I am hoping there is a simpler HLL-based solution. TIA for any help/info/RTFM you can provide. Environment is Enterprise COBOL 3.4, z/OS 1.8 if it matters. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
BUT the question is, when called from COBOL will that small C routine set up and tear down the C environment every time it's called? If so, is there a way to make those calls to a C function from COBOL more efficient? For different values of efficient. But (having never done it, myself), my understanding is that C is LE compliant, it can be done. You will probably have to read the LE reference manual (true name escapes me) to find out exactly how to do it. Sorry if this answer is incomplete. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
On Wed, 29 Oct 2008 15:04:46 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? Yes. Look in the Language Environment manual, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3100/CCONTENTS watch out for the wrap!! CEECBLDY will convert various character representations of dates into COBOL Integer Date formats. CEEGMTO will tell you the difference between GMT and LOCAL time. CEESECS will convert date+time to a timestamp in Lilian seconds (since 00:00:00 14 Oct 1582) which you can then manipulate and convert back. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
Perhaps CEEISEC http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.4 5?SHELF=CEE2BK71DT=20060629134445 followed by CEEGMTO http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.3 9?SHELF=CEE2BK71DT=20060629134445 followed by adding the offset_seconds returned by the latter to the output_seconds returned by the former. Perhaps followed by CEEDATM http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.2 6?SHELF=CEE2BK71DT=20060629134445. No doubt there is much wrap to beware of in the above URLs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
2008/10/29 Farley, Peter x23353 [EMAIL PROTECTED]: Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? CEEGMTO is an LE function that will give you the offset between GMT and local time. It is directly callable from COBOL, and there is a COBOL example in the LE Programming Reference book. CEEGMTO doesn't do the actual conversion, but once you have the offset, you can presumably do it yourself in COBOL. The overhead should be negligible, since the LE environment is already set up. Or am I barking up the wrong tree because there's another/better/simpler way to do this conversion? I think so... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
Thanks John. I didn't realize that the LE date conversion subroutines were so flexible. These should do the trick. Thanks for the pointer! Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John McKown Sent: Wednesday, October 29, 2008 3:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Efficient conversion of GMT to/from local time from COBOL? On Wed, 29 Oct 2008 15:04:46 -0400, Farley, Peter x23353 [EMAIL PROTECTED] wrote: Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? Yes. Look in the Language Environment manual, http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CEEA3100/CCONTENTS watch out for the wrap!! CEECBLDY will convert various character representations of dates into COBOL Integer Date formats. CEEGMTO will tell you the difference between GMT and LOCAL time. CEESECS will convert date+time to a timestamp in Lilian seconds (since 00:00:00 14 Oct 1582) which you can then manipulate and convert back. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
Yes, these will do very nicely. I also read in that same manual that I can use CEEDAYS/CEEGMTO/CEEDATE with an appropriate picture string describing the character date/time. Thanks for the pointers! Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schneiderwent, Craig Sent: Wednesday, October 29, 2008 3:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Efficient conversion of GMT to/from local time from COBOL? Perhaps CEEISEC http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.4 5?SHELF=CEE2BK71DT=20060629134445 followed by CEEGMTO http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.3 9?SHELF=CEE2BK71DT=20060629134445 followed by adding the offset_seconds returned by the latter to the output_seconds returned by the former. Perhaps followed by CEEDATM http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.2 6?SHELF=CEE2BK71DT=20060629134445. No doubt there is much wrap to beware of in the above URLs. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
You are right, and there are other LE functions to perform the conversions between various character formats and Lillian seconds for adding or subtracting the CEEGMTO value. Thanks for the help. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Harminc Sent: Wednesday, October 29, 2008 3:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Efficient conversion of GMT to/from local time from COBOL? 2008/10/29 Farley, Peter x23353 [EMAIL PROTECTED]: Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? CEEGMTO is an LE function that will give you the offset between GMT and local time. It is directly callable from COBOL, and there is a COBOL example in the LE Programming Reference book. CEEGMTO doesn't do the actual conversion, but once you have the offset, you can presumably do it yourself in COBOL. The overhead should be negligible, since the LE environment is already set up. Or am I barking up the wrong tree because there's another/better/simpler way to do this conversion? I think so... Tony H. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
At the risk of exciting the ire of other list members, I think you'd better start coding the Assembler solution. You can use some shortcuts, 64-bit arithmentic, etc. that may further help speed the process. Farley, Peter x23353 wrote: Hi all, A question has been asked of me to which I think I know the answer, but not how (in)efficient it would be: Is there a z/OS-supplied function to convert GMT to local time (or back again)? Now, I don't yet know in what format the GMT is arriving for conversion, but it is very likely NOT in STCK(E) format but rather in some external character format. I know I can write a small C routine to convert character format GMT to time.h format and then use localtime(clock) to perform the conversion from GMT to local time, or gmtime(clock) to go the other way. BUT the question is, when called from COBOL will that small C routine set up and tear down the C environment every time it's called? If so, is there a way to make those calls to a C function from COBOL more efficient? Or am I barking up the wrong tree because there's another/better/simpler way to do this conversion? Obviously I could also write assembler to convert the character format GMT to STCK(E) format with CONVTOD and then use the CVT fields to convert that value to local time and then STCKCONV to go back to character format, but I am hoping there is a simpler HLL-based solution. TIA for any help/info/RTFM you can provide. Environment is Enterprise COBOL 3.4, z/OS 1.8 if it matters. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Efficient conversion of GMT to/from local time from COBOL?
That would once have been my first and only reply to the question (plus I love coding useful utility functions like these), but recently it has become more prudent to consider the maintenance costs and available knowledge down the road after our generation retires. Using documented, standard LE functions may not be as efficient as the assembler solution, but won't require an assembler programmer to maintain it 10 years hence. YMMV Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Wednesday, October 29, 2008 5:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Efficient conversion of GMT to/from local time from COBOL? At the risk of exciting the ire of other list members, I think you'd better start coding the Assembler solution. You can use some shortcuts, 64-bit arithmentic, etc. that may further help speed the process. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
