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



I quit using anything timestamp related for temp file names years ago when
collisions started happening. Not often, but they did.

Now I just create a data area for my application and create a function to
get the next ID (ie, read in the data area value, lock it, add one to it,
then unlock it).

Just an idea. Works slick and it's always unique (until it rolls over, but
I make most of them 13,0).

Brad
www.bvstools.com

On Wed, Oct 15, 2014 at 9:11 AM, Jan Grove Vejlstrup <jgv@xxxxxxxx> wrote:

Have you considered using _GENUUID to generate an UUID (Universally Unique
Identifier) and using it as the name of your temporary file?

If wanted, I could provide you with an example of a procedure generating
an UUID.

Best regards

Jan

Am 15.10.2014 um 11:16 schrieb McGovern, Sean:

Many thanks for the information.


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott
Hanson
Sent: 14 October 2014 17:29
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: tmpnam() not unique


The filename is generated using a hash function based on the current job
number and the system clock. Because the IFS filename which is generated
contains only six characters for uniqueness, the hash function is not a
perfect hash and thus has potential collisions (more than one set of input
values that maps to the same hash value and thus the same filename). The
collisions should be very, very unlikely but are possible and may be within
the same job or a different job.

Scott Hanson

message: 4
date: Tue, 14 Oct 2014 14:52:21 +0000
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: RE: tmpnam() not unique

Thanks Scott.

You say tmpnam() already uses current job number but it is still
possible for a collision to occur (with another job) ?


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Scott Hanson
Sent: 14 October 2014 15:40
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: tmpnam() not unique


The code for the IFS version of tmpnam() uses both the current job
number and the current clock (timestamp) to generate a unique
filename. Once the name is generated, the code uses stat() to make
sure a filename does not already exist with that name. If the file
already exists, it will generate another name. The name generated by
tmpnam() is unique to the system at time of generation.

It is possible for a collision to occur with the filename such that
the same filename is generated twice. The caller of the tmpnam()
routine should test that some other process has not created an
equivalently named file in the lag time between name generation and
file creation. Some applications can use the tmpfile() function to
avoid this issue.

Your solution of adding the job number as a prefix/suffix should work
well and avoid any potential issues.

Scott Hanson

message: 5
date: Tue, 14 Oct 2014 13:19:57 +0000
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: tmpnam() not unique

I've believe I have encountered an issue with my use of tmpnam().

If 2 jobs use tmpnam() at the same timestamp moment, I *think* the
same filename is returned (though I don't know how to test this

scenario).

I haven't coded to handle this possibility, and end up with two jobs
trying to create the same temporary IFS file.

I was thinking that a solution could be just prefix/suffix the job
number to the filename returned by tmpnam().

Does that seem like a feasible solution ?

--

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



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.