Re: duplicate record Id's in multi user environment -- RPG400-L

Hi Booth,

The date, time and time stamp fields are not as excessive as DSPPFM would
lead you to believe. Given the following file:

File: ADATE       Test date, time & timestamp data types
Libr: CC#PGMPCD   Fmt: TESTREC
Mbr : ADATE                                    Scan:
 Seq Pg K Field      T  Len Fd Dd  From   To Text
   5  1   DATE1      L   10           1   10 DATE
  10  1   TIME1      T    8          11   18 TIME
  15  1   TSTMP      Z   26          19   44 TIMESTAMP

the SQL HEX function shows that the lengths are not actually what they seem:

....+....1....+....2....+....3....+....4....+...
DATE1     HEX ( DATE1 )
05/14/97    00256497        actual length 4 bytes

TIME1     HEX ( TIME1 )
15:02:45     150245         actual length 3 bytes

TSTMP                       HEX ( TSTMP )
1997-05-14-15.02.45.000000  00256497150245000000  actual length 10 bytes

At some level they're playing tricks, and it's apparently a pretty low level
since DSPPFM shows the formatted date, time and timestamp.

Another way to prove it is to create a file with a single date field and
initialize it with 1000 records. Subtract the overhead (size of the file
with no records) and you'll see that it comes out to about 4 bytes per
record. I say about because I think there are some other housekeeping bits
or bytes in there like the deleted record flag.

Regards,
Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax




----- Original Message -----
From: <booth@martinvt.com>
To: <RPG400-L@midrange.com>
Sent: Monday, October 16, 2000 2:52 PM
Subject: Re: duplicate record Id's in multi user environment


> If your ID field is going to have the sort of excessive size-to-need ratio
> that a timestamp provides  then lets just have a large numeric field. Then
> a random number generator can create random numbers as needed, and chain
> to see if it exists.  The performance hit would be slight because the odds
> are that only 1 out of a dozen or more attempts would have to take two
> tries.  Almost none would need a third try.   There is no rule that says
> ID numbers have to be in ascending order and matching arrival sequence is
> there?
>
> _______________________
> Booth Martin
> Booth@MartinVT.com
> http://www.MartinVT.com
> _______________________
>
>
>
>
> rob@dekko.com
> Sent by: owner-rpg400-l@midrange.com
> 10/16/2000 12:53 PM
> Please respond to RPG400-L
>
>
>         To:     RPG400-L@midrange.com
>         cc:
>         Subject:        Re: duplicate record Id's in multi user
environment
>
>
> And your trigger program can have a time delay on the receive from data
> queue.  If it times out then it can run the batch process to fill it
> again.
>
> Why wait until 999999999?  If you use hex shouldn't it go from 000000009
> to
> 00000000A, and so forth?  Or you could roll your own hex, and use all
> letters instead of stopping at F.  Regular hex may be easier because of
> existing hex math.
>
>
> Rob Berendt
>
> ==================
> Remember the Cole!
>
>
>
>                     Jim Langston
>                     <jimlangston@conexfr        To: RPG400-L@midrange.com
>
>                     eight.com>                  cc:
>                     Sent by:                    Subject:     Re: duplicate
> record Id's in multi user environment
>                     owner-rpg400-l@midra
>                     nge.com
>
>
>                     10/16/00 10:51 AM
>                     Please respond to
>                     RPG400-L
>
>
>
>
>
>
> Hmm... This sounds like an idea...  If the batch job keeps the data queue
> filled with, say, at least 1000 entries, it shouldn't be a problem.  It
> would be possible for a program to grab an entry and not use it (the job
> bombs out, user turns off tube, etc...) but this shouldn't be a problem
> as we are not really looking for sequential numbers, just unique ones.
>
> Of course, the key field in the data files should be declared as character
> fields and not numeric (no math is ever going to be performed on them)
> which
> gives us a lot of advantage.  One of the biggest ones being that once you
> hit
> 999999999 you can start over at, say, A000000001.
>
> And even at this, a trigger program can be used to pull the number from
> the
> data queue, so you only have one place to modify the changes.
>
> Regards,
>
> Jim Langston
>
> Steve Brazzell wrote:
> >
> > Seth,
> >
> > Remarkable, but I was just thinking the same thing.  Also, if after each
> > receive from the queue an increment and send were done, even the batch
> > feeder job wouldn't be needed.  Of course, that brings up the problem of
> a
> > program somehow failing between the receive and send, but still an
> > interesting idea, imo.
> >
> > Steve Brazzell
> > Innovatum, Inc.
> >
> > -----Original Message-----
> > From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
> > Behalf Of Seth.D.Shields@blum.com
> > Sent: Monday, October 16, 2000 1:45 PM
> > To: RPG400-L@midrange.com
> > Subject: Re: Re[2]: duplicate record Id's in multi user environment
> >
> > Just an idea.  How about a batch job feeding sequential Order #'s to a
> data
> > queue.  When a job needs a Order number, it just pulls
> > the next one from the queue.
> >
> > Regards,
> > Seth Shields
> > Julius Blum, Inc
> +---
> | 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 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
+---