Thanks Mark S for making me reread this elegant solution. Will submit the idea.
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Bruce Vining
Envoyé : mercredi 19 novembre 2008 17:56
À : RPG programming on the AS400 / iSeries
Objet : RE: problem with duplicate records
The quick fix:
Have a separate job generating available reference numbers. This job puts N reference numbers on a *DTAQ. GetTheGodDamNo() then retrieves the number to be used from this *DTAQ.
To replenish the queue you could either have the provider *PGM wake up periodically, determine the current number of entries on the queue (Retrieve Data Queue Description API QMHQRDQD) and add sufficient entries to get to a known safe number (given the request arrival rate and the duration between wakeups). Alternatively, if GetTheGodDamNo() receives 'no message available' it sends a message to wake up the replinisher and then retries the receive operation, this time looping on a 'no message available'. If the loop exceeds some limit then the replinisher job is probably dead and you can recover in a variety of ways (restart it, inform the operator, ...).
If I understand your search approach for an available number (calculate, setll, and read until record not found) then I doubt you want that logic in every job anyway. This is not going to scale well at all... Isolating the "find available" logic in a background job, running asynchronously, will at least hide the search time from the client jobs.
This approach should accomplish two things -- 1) avoid duplication and 2) speed up the perceived performance of the application.
Bruce
Bruce Vining Services 507-206-4178
--- On Wed, 11/19/08, David FOXWELL <David.FOXWELL@xxxxxxxxx> wrote:
From: David FOXWELL <David.FOXWELL@xxxxxxxxx>
Subject: RE: problem with duplicate records
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Date: Wednesday, November 19, 2008, 8:30 AM
Everyone, thanks for the help. The problem is nothing to do with the time. In fact I can't say how long the operation took for sure.
2 jobs use the same code to look for the next available reference number.
CALLP GetTheGodDamNo ()
CALLP WriteTOFile ( )
Which does
CHAIN myfile
IF %FOUND
RETURN *OFF
ENDIF
WRITE MyFile
Now perhaps the first procedure is too long : Theoretically, the refNo can be between AA00001 and ZZ99999 so only used numbers are stored in the file. These numbers correspond to a physical emplacement in our archives. Numbers can become liberated for use by another client. The first available number might be AB00020 and the next PG00035. The program scans for the first available number using SETLL to stop when the number calculated doesn't exist in the file.
I can't use a DATAAREA as suggested because each calcul starts at AA00001.
The user wants to reuse all available emplacements. But, that gives me an idea.
When the program requests a reference number to be created, it uses a DATAAREA to prevent other jobs from calculating until it's finished. How about that?
It still doesn't explain to me why the two jobs come up with the same answer AND both WRITEs worked. Could it be a serious problem in performance?
Should I have used FRCRATIO on OVRDBF?
The two jobs in question are identical except for some of the files used. These are client files in separate libraries with identical layouts. The files of one of the jobs are much, much lighter. I say this because I am rather concerned at the size of the programs ( all bound by copy ), lots of large files opened lots of times, ( not the file in question above ). Often, when leaving the application by F3 for example, a second or two passes before getting back to the menu.
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Alan Shore Envoyé : mercredi 19 novembre 2008 14:36 À : RPG programming on the AS400 / iSeries Objet : RE: problem with duplicate records
Not too sure if the problem is that 2 different records have 1. the same Ref#, or 2. the same time or
3 .the same Ref#/time
Be that as it may
Why don't you create logicals and have them as keyed unique on whichever of the above scenarios you do NOT want duplicates of
Of course the applicable programs will need to be changed to monitor for an attempt to write a duplicate key
Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
rpg400-l-bounces@xxxxxxxxxxxx wrote on 11/19/2008 06:17:15 AM:
Sorry, the contents of my file are misleading. The time isn't part of
the reference number.
ArchiveFile
Product Client Ref Time
Product1 Client1 RefNo1 10:41:57
Product2 Client2 RefNo1 10:41:57
Summing up, 2 jobs writing to the same file. One job is quicker than
the other. The first job calculates the data to write, tests to see it
doesn't already exist and writes the data. In RPG, how should we
prevent another job from doing the same and writing the same data
before the first one?
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-
bounces@xxxxxxxxxxxx] De la part de David FOXWELL Envoyé : mercredi 19
novembre 2008 09:33 À : RPG programming on the AS400 / iSeries Objet :
problem with duplicate records
Hi,
Two users have managed to create the same archive reference number
while creating two different clients.
Like this :
ArchiveFile
Product1 Client1 RefNo1 10:41:57(time)
Product2 Client2 RefNo1 10:41:57
The program would crash if the problem occurred with the same product.
As it is 2 users in different services created the records at the same
time.
The user enters the client details and hits the enter key.
The program writes the client to the client file then calls an
external procedure to find an unused archive number then write this
number to the archive file.
The client files look like this
Product1_clients
Client1 created at 10:41:53
Product2_clients
Client2 created at 10:41:56
I'm assuming that the creation of client1 took so long that the
creation of client2 caught up. The same time in the ArchiveFile is
just a hazard.
I can think of ways to fix it, but I'd rather ask what are we doing
wrong?
Thanks.
--
This is the RPG programming on the AS400 / 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 AS400 / 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 AS400 / 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 AS400 / 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 AS400 / 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.
midrange.com
