× 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.



And that's not on any of the following, (yet):
Title                                 Group Level      Last Updated 
 SF99529: 530 Group Hiper Level            6           07/06/2004 
 SF99503: 530 DB2 UDB for iSeries Level    1           06/15/2004 

Nor on
SF99530: Current Cumulative PTF Package                7/9/2004 9:24:02 AM 


Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Bruce Vining <bvining@xxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
07/13/2004 08:14 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: Fastest way to get a unique identifier/tracking column change s










This was a bug and has been corrected.  The PTFs are MF33189 for V5R1,
MF33191 for V5R2, and MF33190 for V5R3.

Bruce



 
             CWilt@xxxxxxxxxxx 
             m 
             Sent by:                                                   To 

             midrange-l-bounce         midrange-l@xxxxxxxxxxxx 
             s@xxxxxxxxxxxx                                             cc 

 
                                                                   Subject 

             07/12/2004 03:50          RE: Fastest way to get a unique 
             PM                        identifier/tracking column change s 

 
 
             Please respond to 
             Midrange Systems 
                 Technical 
                Discussion 
 
 




Just a quick FYI, but GENUUID may not guarantee a unique ID.

Check out this thread in the newsgroup:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=9nu8eb.dt1.ln%40m


odula.bender-dv.de&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm

%3D9nu8eb.dt1.ln%2540modula.bender-dv.de

Seems as if duplicates can occur on a multi-processor system when multiple
processes are using it at the same time.
Unless it turned out to be a bug that was corrected.


HTH,
Charles


> -----Original Message-----
> From: Kevin Mohondro [mailto:kevin.mohondro@xxxxxxxxxxxxxxx]
> Sent: Monday, July 12, 2004 1:29 PM
> To: 'Midrange Systems Technical Discussion'
> Subject: RE: Fastest way to get a unique identifier/tracking column
> change s
>
>
> You could get a UUID (Universally Unique IDentifier). This
> will give you a
> unique ID that you could use.
>
> D getUUID         PR                  ExtProc('_GENUUID')
> D  UUID_DS                        *   Value
>
> D UUID_DS         DS
> D  BytPrv                       10u 0 Inz(%size(UUID_DS))
> D  BytAvl                       10u 0
> D  Hold                          8a   Inz(*allx'00')
> D  UUID                         16a
>
> C                   CallP     getUUID(%addr(UUID_DS))
> C                   Eval      Key = UUID
>
> -Kevin
> -=-=-=-=-=-=-=-=-
> Kevin R Mohondro
> Programmer/Analyst
> Ashworth, Inc
>
> -----Original Message-----
> From: Reeve Fritchman [mailto:reeve.fritchman@xxxxxxxxxx]
> Sent: Monday, July 12, 2004 7:22 AM
> To: 'Midrange Systems Technical Discussion'
> Subject: Fastest way to get a unique identifier/tracking
> column changes
>
>
> I'm designing a new system with a requirement for detailed
> tracking of, and
> inquiry into, column-level changes.  I've decided to build a
> single file
> with before and after values, etc. for all the tables by
> using triggers.
> Some of the tables have complex keys (order number/SKU/shipper
> location/consignee location/release number), and I don't want
> to burden my
> historical tracking file with a nasty key structure to
> support inquiry into
> the details of the changes.  I'm not going to track added records or
> date-of-last-change timestamps in the tables; the majority of
> the changes
> will be on a limited number of columns (of the status and
> date nature).
>
>
>
> My design is to assign every row an "entity number"; the
> entity number would
> be like a record serial number, would be unique on a
> system-wide basis, and
> would be the key to the historical tracking table.  When a
> user wants to see
> the details of the changes to a specific row, the row's
> entity number would
> allow simple access to the tracking file.  Using SQL's AS
> IDENTITY with the
> table name could work to provide a key to a specific record.
>
>
>
> The challenge is to determine a way to get the entity number quickly.
> Having a control file is okay but probably limiting performance-wise;
> another possibility is a journaled data area.  Is there a system API
> providing a guaranteed unique sequential number?  Or is there a better
> approach for tracking column-level changes?
>
>
>
> Thanks,
>
> Reeve
>
>
>
>
>
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> ##############################################################
> #######################
> Attention:
> The information contained in this message and or attachments
> is intended
> only for the person or entity to which it is addressed and may contain
> confidential and/or privileged material.  Any review, retransmission,
> dissemination or other use of, or taking of any action in
> reliance upon,
> this information by persons or entities other than the
> intended recipient
> is prohibited. If you received this in error, please contact
> the sender and
> delete the material from any system and destroy any copies.
>
> Thank You.
> ##############################################################
> #######################
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.