Calculate GMT

[Guest.Visitor]

I need to know if there is any way to get GMT time from the AS400 or I have to calculate it manually. If you can help me would be great! Thanks Brian

[B.Myrick]

Brian, There is a system value for the GMT to your_timezone offset in HH:MM format. This only gives you the +/- offset, not the actual GMT, so the answer is yes (as far as I know) you still have to calculate the time. I suggest a called program or sub-procedure. Remember though, sub-procedures are new and nice, but a subroutine is still a bit faster. I would set this up as a /copy member in a utility source file and import it when required. Hope this helps, Bret Myrick P.S. Peers, prove me wrong, please. I'd like to know if there is already a systemagic way of doing this.

[D.Handy]

Bret, Remember though, sub-procedures are new and nice, but a subroutine is still a bit faster. The actual branch to a subroutine may be nominally faster than a call to a subprocedure, but if you need to pass information to and/or from the routine the difference largely gets lost in the moves around the exsr. And I'd argue the code is less readable than a subprocedure call. I think the way Barbara Morris once likened the speed advantage is that it is like standing on a chair to get closer to the moon. (Or maybe that was in reference to some other comparison, but I think it is just as apt here.) Even if you could measure the difference, who cares? This isn't a function which would be repeated millions of times where that slight of a difference could possibly matter. I would set this up as a /copy member in a utility source file and import it when required. Whereas I would make it a subprocedure in a service program. P.S. Peers, prove me wrong, please. I'd like to know if there is already a systemagic way of doing this. Use the api CEEUTC (Get Univeral Time Cooridinated) or its alias CEEGMT (Get Current Greenwhich Mean Time), both documented in the CEE API's manaual. This will return the lilian date plus the number of seconds since 00:00:00 14 October 1582. Then use CEEDATE to convert the lilian date to a character format. But also remember that this implies the system value for the UTC offset is set correctly. I suspect that way too many systems still have QUTCOFFSET at zero. I'd still put it in a subprocedure, and let it do both the CEEUTC and CEEDATE calls. Doug

[Guest.Visitor]

You could use the C library function gmtime() to convert from local time to the equivalent UTC value. This would avoid the need to do the conversion yourself (though the conversion is not difficult). gmtime() does, by default, depend on the QUTCOFFSET system value being set correctly.

[Guest.Visitor]

Thank for the quick responce an help. I found this http://www.as400.ibm.com/developer/p...xample9.html/* Program that is replacement for gettimeofday() This function will populate the timeval structure at the address passed to it with the seconds and microseconds (for Greenwich time) since the epoch. Note that this workaround has only one parameter to the function and it populates the timeval struct with the current Greenwich time. It does not return any timezone information. It retrieves the local time of day using the AS/400 MI instruction MATTOD. The MI TOD is laid out with the leftmost 42 bits defined as the value and the remaining 22 bits undefined. The 42 bits are essentially a binary number that is incremented every 1,024 microseconds. The low order bits of the 42 bits must be extracted from char8 field and multiplied by 1024 to obtain the correct number of microseconds. This will be done by clearing the 10 bits to the right of the 42 bits (10 bits=1024) and then shifting the 20 low order bits (existing 10 + clear 10) right until the remaining reserved bits are removed. The result is the time in microseconds. A similar value exists for the epoch (Jan. 1, 1970), and this value will be subtracted from the value for the time retrieved to populate the timeval struture. Another system API CEEUTCO is used to get the offset from Greenwich time and this offset is used to adjust the seconds calculated above for current time to get UTC (Universal Time Coordinated) time. Choose your browser's option to save to local disk and then reload this document to download this code example. Send the program to your AS/400 and compile it using the development facilities supplied there. This program was developed and tested on V3R1, V3R2 and V3R6 systems. Define macro OS400_V3R1_OR_V3R2 for V3R1 or OS400_V3R6 for V3R6 while compiling. This small program that is furnished by IBM is a simple example to provide an illustration. This example has not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of this program. All programs contained herein are provided to you "AS IS". THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. */

[B.Myrick]

Doug, Thanks. I put the stuff in about the sub procedures mainly because of what IBM has published and I don't want anyone to blame me for slowing their system down. I agree with sub procedures over sub programs because of the flexibility of the callb and callp in ile. I like /copy modules as well because they are a simple concept and many people grasp them better than the new fangled sub procedures. I actually had a client who used JDE software and wanted /copy members only, even if were new non-JDE like programs. Wanted consistency. Also, my comments on other subjects are: Don't forsake readabilty/re-usability for just to gain a small bit of speed or performance. If the source has to be maintained, then make it easy for the next person to understand. Prove me wrong. Okay, okay. I figured I was wrong, but now I know for sure. Drums are playing, swords are broken and those in the know, avert their eyes, 'cause I'm Branded...... Told you all, I was getting old.. Later and thanks, Bret "Wrongway Feldman" Myrick

[D.Handy]

Bret, I put the stuff in about the sub procedures mainly because of what IBM has published I know the comment in the RPG manual you're referring to, and I think it is unfortunate that it is there. There just isn't that much difference. I'm pretty sure the last Redbook on RPG strongly encourages subprocedures over subroutines, and downplays the performance issue. That redbook should be required reading for every RPG programmer! Twenty years ago I cared alot more about efficiency for its own sake, and studied the machine instruction timings on the S/34 and the code the RPG compiler generated. Now experience has taught me how imporatant readability and maintainability and code reuse are, even if at the expense of some performance. On a typical business app that is I/O bound, or mostly waiting on think time for an interactive user, my vote goes for readability. Doug

[Guest.Visitor]

Unfortunately that entry is rather out of date (for RISC anyway). Two dated areas I notice right off are that the gettimeofday() API was implemented in OS/400 with V4R2 and the TOD clock has 8-microsecond granularity rather than 1024. Hopefully we can get this entry updated (or removed).

[B.Myrick]

Doug, The blurb came from the IBM redbook Who Knew You Could Do That With RPG IV? A Sorcerer's Guide to System Access and More. Page 39 (3.4.1) explains this. I have done testing when I was the only person on, and found the difference to be very slight. I too, cut my teeth on the '34 beginning in 1982. Then, as I've said in another thread, system degredation could be seen by everyone if you used a read vs chain operation multiple times. Again though, give up the cutesy tricks and too small to measure performance programming if it means creating code that is not clear. One of these days we will be able to write self documenting code, but until then..... Thanks for the comments, Bret Myrick

[Guest.Visitor]

Make sure you adjust the system value QUTCOFFSET if and when you begin and end Daylight Saving Time. In the USA, DST begins on the first Sunday in April at 2am and ends on the last Sunday in October at 2am. Chris