Re: Local time in C on z/OS
On Sat, 17 Aug 2019 23:43:34 +, Jon Perryman wrote: > If time were as simple to solve as UTC and a 1 byte UTC offset, then this > problem would have been solved a long time ago. As I said before, everyone > assumes the time zone is fixed. What happens when the time zone is at the > time the data is reference instead of created. > This is addressed by: https://www.iana.org/time-zones >As for localtime better than the z/OS implementation, that's silly. First, bad >is still bad. Second, C local time is a language feature instead of OS >feature. > Only because you call it so. The TIME macro is a language (HLASM) feature instead of OS feature. Third, it was designed around a specific Unix feature (environment variables). It needs redesign for use in CICS, IMS and most z/OS components. > There are other ways to pass such a parameter. It could be a PARMLIB entry. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
If time were as simple to solve as UTC and a 1 byte UTC offset, then this problem would have been solved a long time ago. As I said before, everyone assumes the time zone is fixed. What happens when the time zone is at the time the data is reference instead of created. As for localtime better than the z/OS implementation, that's silly. First, bad is still bad. Second, C local time is a language feature instead of OS feature. Third, it was designed around a specific Unix feature (environment variables). It needs redesign for use in CICS, IMS and most z/OS components. Jon. On Friday, August 16, 2019, 07:42:44 AM PDT, Seymour J Metz wrote: IMHO the right way is to log both the time in UTC and the local zone offset. From: Paul Gilmartin On Thu, 15 Aug 2019 23:11:48 +, Jon Perryman wrote: > >C offer's localtime and UTC but not z/OS time. The OP wants the z/OS time. > As the OP observed, localtime is not well defined; worst on z/OS. >"where are you" is too simplistic. Time is relative to the problem being >solved. C and z/OS take the simplistic approach that there is a single time >zone involved. C assumes this time zone is customizable where as z/OS has a >single timezone for the system. The C assumption works well for Unix where >user's run their programs in a process. This paradigm starts having problems >in products such as SAP, Peoplesoft and others. I suspect IBM decided on a >single timezone because z/OS encounters these types of issues. > "single"? Doesn't z/OS provide two? There's a right way to address this problem. Such products should log UTC, which is always available. Conversion for display at the users' discretion. Enforcing standards for such as printed reports is a management issue, not a systems issue. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TGIF
Anyone ever notice that macro DCBD produces a DSECT named IHADCB, and that macro IHADCBE produces a DSECT named DCBE? Go figure. Did you "figure" that you might be doing something wrong that led you to think that that is strange? You should probably be using IHADCB which internally invokes DCBD. Then we have "macro IHADCB produces a DSECT named IHADCB". Then you can choose to think about why some produce a DSECT without the component prefix and some with, as Charles observed. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOCASCB STOKEN=
The OP's question was why the parameter was an address of a word containing another address, rather than just taking that other address directly as a parameter. Actually, it was why the parameter was an address of the STOKEN rather than the parameter being the STOKEN in a register. Jim Mulder provided that answer. I hope that the OP was not passing in an address provided by someone else if that someone else was not authorized and they were. That would be a system integrity error in almost all cases. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
