RE: Timestamps

[Klein Ron <ron.klein@xxxxxxxxxx>]

Hi All,
Thanks to those who replied.  The writes actually are occurring in the same
program and in the same commit cycle.

We were able to get it to work.  As it turns out, in the d spec, if you
initialize the field to the default value (0001-01-01.01.01.01.000000) then
it will fill the microseconds in.  One seemingly strange thing happens
though the far right 3 positions are always zero and in the manuals it even
states this.  Just seems odd to have the place if they aren't being used or
can't be used.

But all in all it fixed our problem.

Ron

        -----Original Message-----
        From:   Peter Connell [SMTP:peterc@baycorp.co.nz]
        Sent:   Tuesday, November 21, 2000 3:48 PM
        To:     'RPG400-L@midrange.com'
        Subject:        RE: Timestamps

        I toyed with this as well. There was a way, I can't recall at
present, but I
        since I couldn't guarantee against the remote possiblity of 2
separate
        processes simultaneously retrieving the same timestamp before
writing a
        record, I opted for using the job number as well to achieve
uniqueness.
        Unless multiple writes occur together in the same pgm with almost no
delay
        the jobno/timestamp would be unique.    

        -----Original Message-----
        From: Klein Ron [mailto:ron.klein@brctsg.com]
        Sent: Wednesday, November 22, 2000 9:05 AM
        To: 'RPG400-L@midrange.com'
        Subject: RE: Timestamps


        David,
        The reason for the accuracy is for duplicate records.  If a
maintenance
        program tries to update multiples records at one time and the
timestamp is
        our key field, we get a duplicate key message.  And yes adding one
to a
        counter certainly would work, but we are using an API to get our
timestamp
        and therefore we would have to track if the call to the API was
initiated
        from this commit cycle or it is a new cycle.  I just thought that
using
        milli seconds we might have a easier time.

        Ron

                -----Original Message-----
                From:   David Morris [SMTP:dmorris@plumcreek.com]
                Sent:   Tuesday, November 21, 2000 1:35 PM
                To:     RPG400-L@midrange.com
                Subject:        Re: Timestamps

                Ron,

                Why does it have to be that accurate?  It is difficult to
set a
        timestamp in a trigger  
                to the full precision allowed.  As this is an update, it is
        obviously not being used as a 
                unique key field.  By the time you get a full length
timestamp in a
        trigger and set your 
                update time, it won't be the actual update time anyway.  I
would
        think you would be 
                just as well off to add .000001 to the time, assuming this
is
        occurring in one process.

                David Morris

                >>> ron.klein@brctsg.com 11/21/00 11:26AM >>>
                Hi All,

                We have a trigger program which updates a timestamp field in
the
        data file
                with the last changed time.  When a commit is done and 3
records are
                committed to the same file, all 3 have the same timestamp.
How do I
                retrieve the system time with the milliseconds in it?

                Thanks

                Ron


                +---
                | This is the RPG/400 Mailing List!
                | To submit a new message, send your mail to
RPG400-L@midrange.com.
                | To subscribe to this list send email to
RPG400-L-SUB@midrange.com.
                | To unsubscribe from this list send email to
        RPG400-L-UNSUB@midrange.com.
                | Questions should be directed to the list owner/operator:
        david@midrange.com
                +---
        +---
        | This is the RPG/400 Mailing List!
        | To submit a new message, send your mail to RPG400-L@midrange.com.
        | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
        | To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
        | Questions should be directed to the list owner/operator:
        david@midrange.com
        +---

        This communication is confidential and may be legally privileged. 
        If it is not addressed to you, you are on notice of its status. 
        Please immediately contact us at our cost and destroy it.  
        Please do not use, disclose, copy, distribute or retain any of it 
        without our authority - to do so could be a breach of confidence. 
        Thank you for your co-operation.  
        Please contact us on (09) 356 5800 if you need assistance.
        +---
        | This is the RPG/400 Mailing List!
        | To submit a new message, send your mail to RPG400-L@midrange.com.
        | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
        | To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
        | Questions should be directed to the list owner/operator:
david@midrange.com
        +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---