Re: Where am I going wrong with XLC __TIMESTAMP__ ?

And the answer is ... Although it is not so documented, apparently __TIMESTAMP__ is a C (not C++) -only feature. I am further informed that __TIMESTAMP__ is not part of the C standard, so I am out of luck. Charles On Sat, 1 Jul 2023 16:52:20 -0500, Charles Mills wrote: >I am using XLC

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On 7/2/2023 10:50 AM, Itschak Mugzach wrote: Yes. We are an is. (IronSphere). Every zPDT has a unique CPU type/serial. It makes sense IBM could open up this entitlement for zPDT users. I'm still puzzled how RDC customers in Dallas could do so. I'm not saying it can't be done, but am

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

This is the link where I open tickets with IBM (zPDT 1090-L01 box) : https://www.ibm.com/mysupport/s/createrecord/NewCase?productId=flatitem=en_US Best, ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Itschak, Ok. We received no such letter and we are partnerworld members and an ISV using the ADCD on a zPDT system. This is news to us. I see that it is for use only to report defects in the ADCD system. Thanks for that info. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sun,

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Mike Since then I opened tickets directly at ibm support portal and not from partner world ITschak בתאריך יום א׳, 2 ביולי 2023 ב-20:50 מאת Itschak Mugzach < i_mugz...@securiteam.co.il>: > Yes. We are an is. (IronSphere). Last week was not the first time we > opened a ticket. Below is the

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Yes. We are an is. (IronSphere). Last week was not the first time we opened a ticket. Below is the letter I received from IBM before opening the first ticket: Dear zPDT user, The entitlement of your PartnerWorld location ID has been updated to include the ability to report defects in z/OS

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Itschak, How? Calling the support center? They always ask for a CPU serial number. Are you an ISV? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sun, Jul 2, 2023 at 1:18 PM ITschak Mugzach wrote: > Not true. ZPDT users can open tickets and access shops for ptfs. > > ITschak > >

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Not true. ZPDT users can open tickets and access shops for ptfs. ITschak בתאריך יום א׳, 2 ביולי 2023 ב-19:59 מאת Mike Shaw : > Ed is correct. If you don't license IBM mainframe hardware, you can't get > full z/OS support. ISVs using zPDT as their sole z/OS development host > can't report

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Ed is correct. If you don't license IBM mainframe hardware, you can't get full z/OS support. ISVs using zPDT as their sole z/OS development host can't report problems OR get formal tech support for z/OS. We adapt... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sun, Jul 2, 2023 at

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

zPDT clients can open tickets and order PTFs. I just did it last week for the certificate issue we had. ITschak -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon *

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On 7/2/2023 7:52 AM, David Crayford wrote: That's interesting. I was of the understanding that PDT customers were IBM business partners, in which case had to have access to Partnerworld and had full access to services to open cases. I now that's certainly the case for other ISVs that use

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Yes, @David, perhaps the PDT entitles us to search cases. I shall look into that. I am pretty certain that we cannot open cases nor even order PTFs. We have to wait for the "bucket" that comes out from time to time. I am also quite certain that a Dallas contract give us no access to APARs --

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On 2/7/2023 8:41 pm, Charles Mills wrote: @David: Looks like a but with XL C++. I would open a case with IBM Alas, I am but a red-headed stepchild. Dallas and PDT customers cannot even search APARs (which makes NO sense to me) much less open cases. That's interesting. I was of the

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Thanks for merging replies. It's irritating when a contributor replies to multiple plies, in sequence, oblivious that the question has already been subsequently answered. On Sun, 2 Jul 2023 07:41:11 -0500, Charles Mills wrote: >It is a user header. They are both uploaded more or less at the

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Thanks all. Attempting to reply to everyone in one note so as not to add to the noise. @Gil: > 8 seconds after the source. That's astonishing if it's a system header. It is a user header. They are both uploaded more or less at the same time, with FileZilla, which I think sets a new timestamp

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On Sat, 1 Jul 2023 21:34:25 -0500, Charles Mills wrote: > >Seriously, the IBM doc lists it as the value returned if no timestamp is >available. > They should specify which timestamp: ISPF, UNIX, FAMS, ... and which dominates if they disagree. RCF. >>What is the timestamp of the "one

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Looks like a but with XL C++. I would open a case with IBM > xlC -o posts posts.cpp && ./posts blah blah, Built Jul 2 2023 10:51:48, Source timestamp Mon Jan 1 0:00:01 1990 > ibm-clang++64 -o posts posts.cpp && ./posts blah blah, Built Jul 2 2023 10:52:08, Source timestamp Sun Jul 2

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On Sat, 1 Jul 2023 20:24:04 -0500, Paul Gilmartin wrote: >Does "Mon Jan 1 0:00:01 1990 mean anything to you? I was in Paris for New Year's. It was fantastic. We drank champagne until it ran out, and then moved on to homemade grappa. We sang songs from West Side Story. I slept until noon.

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On Sat, 1 Jul 2023 21:00:34 -0500, Paul Gilmartin wrote: >On Sun, 2 Jul 2023 11:52:43 +1000, Attila Fogarasi wrote: > >>Jan 1 1990 is POSIX epoch start in USS, so you are getting 0 for the time >>value somehow. >> >WTF?!

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On Sun, 2 Jul 2023 11:52:43 +1000, Attila Fogarasi wrote: >Jan 1 1990 is POSIX epoch start in USS, so you are getting 0 for the time >value somehow. > WTF?! -- gil

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

Jan 1 1990 is POSIX epoch start in USS, so you are getting 0 for the time value somehow. On Sun, Jul 2, 2023 at 11:24 AM Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Sat, 1 Jul 2023 16:52:20 -0500, Charles Mills wrote: > >... > >The message is displaying as >

Re: Where am I going wrong with XLC __TIMESTAMP__ ?

On Sat, 1 Jul 2023 16:52:20 -0500, Charles Mills wrote: >... >The message is displaying as > >blah blah, Built Jul 1 2023 14:12:35, Source timestamp Mon Jan 1 0:00:01 >1990 > >There is one i#include ahead of the char[] and it is also a UNIX file with a >timestamp. > Does "Mon Jan 1

Where am I going wrong with XLC __TIMESTAMP__ ?

I am using XLC __TIMESTAMP__ for the first (!) time. The source file is in UNIX and definitely has a timestamp. Here is the code static const char versionMsg[] = "blah blah, Built " __DATE__ " " __TIME__ ", Source timestamp " __TIMESTAMP__ ; The message is displaying as blah blah, Built Jul