× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The 8-byte TOD value returned by MATTOD is unique because the system
adds "uniqueness bits" to guarantee it. But when converted to other
formats, values may be rounded and not unique. See:

http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzatk/MININ.htm#HDRTIMEFMT

under "Standard Time Format".

and MATMDATA options x0000 and x0004:

http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=/rzatk/MATMDATA.htm


--Dave

On 11/19/2010 06:44 AM, dieter.bender@xxxxxxxxxxxx wrote:
MATTOD seems not to be guaranteed to be unique:
http://www-01.ibm.com/support/docview.wss?uid=nas186213a22df7617f886256c25005de629

Dieter
--------------------------------------------------
From: "Vern Hamberg" <vhamberg@xxxxxxxxxxx>
Sent: Friday, November 19, 2010 2:47 PM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: time/date as key fields

Yep, even timestamps on modern fast boxes will not guarantee uniqueness,
even down to the microsecond. There is an MI timestamp, TOD, that is 8
bytes long and guaranteed to be unique - pretty easily retrieved
(MATTOD) and converted to a 16-character value (CVTHC, or CVTCH - i
forget!) that sorts by date/time. Or you can leave it as its 8-byte
value, that'll still sort just fine.

Vern

On 11/19/2010 4:47 AM, dieter.bender@xxxxxxxxxxxx wrote:
...uniqueness is not guaranteed and the sequence might not be strict. A
transaction number could be addedd automatically and using a view it
could
be unvisable to the application.

Dieter



--------------------------------------------------
From: "David FOXWELL"<David.FOXWELL@xxxxxxxxx>
Sent: Friday, November 19, 2010 10:21 AM
To: "Midrange Systems Technical Discussion"<midrange-l@xxxxxxxxxxxx>
Subject: time/date as key fields

Is there anything wrong in using date and time of creation fields
already
existing in a transaction table to keep track of transaction history or
would it be advisable to add a separate field transaction_number? The
latter means a lot more program changes.

Thanks

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.