|
midrange.com
Record locking.....
Hi,
My first mail to the mailing list. Since I have seen the record locking
problem, here is the
most simple way to find the record lock.
Key chain 9091
dow *91=*off
Key chain 9091
enddo
The technique is that the indicator 91 returns the error status of the op-code
(chain return code)
and the program keeps on reading the record, if the operation fails( most of
the times it fails
because of the record lock condition).
-Ramkumar G
-----Original Message-----
From: rpg400-l-request@xxxxxxxxxxxx
[mailto:rpg400-l-request@xxxxxxxxxxxx]
Sent: Tuesday, September 30, 2003 10:32 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG400-L Digest, Vol 2, Issue 723
Send RPG400-L mailing list submissions to
rpg400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/rpg400-l
or, via email, send a message with subject or body 'help' to
rpg400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
rpg400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of RPG400-L digest..."
Today's Topics:
1. Re: Detecting Record Lock Conditions
(Pete Clifford (ariadne software))
2. Re: Detecting Record Lock Conditions (fkany@xxxxxxxxxxxxxxxxxx)
3. Re: Detecting Record Lock Conditions (James Rich)
4. Re: Detecting Record Lock Conditions (Booth Martin)
5. Re: When is %EOF not an %EOF (Simon Coulter)
6. error messages list (Murali dhar)
7. RE: Detecting Record Lock Conditions (Walden H. Leverich III)
8. Re: error messages list (Buck)
----------------------------------------------------------------------
message: 1
date: Mon, 29 Sep 2003 22:27:57 +0100
from: "Pete Clifford \(ariadne software\)"
<pete@xxxxxxxxxxxxxxxxxxxxx>
subject: Re: Detecting Record Lock Conditions
Hi Frank.
I'm not convinced there's much point having the wait in there at all since
the read will wait the amount of time specified by the file's WAITRCD
attribute before returning an error condition in any case. If the record
becomes available during this time, the read will succeed and return
immediately. Your way, you always have to wait n seconds whether the record
becomes available while you're waiting or not.
If you do decide to wait a while, consider using "sleep":
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/sigsleep.htm.
Perhaps neater than calling DLYJOB via QCMDEXC?
Pete
----- Original Message -----
From: <fkany@xxxxxxxxxxxxxxxxxx>
To: <RPG400-L@xxxxxxxxxxxx>
Sent: Monday, September 29, 2003 10:03 PM
Subject: Detecting Record Lock Conditions
>
> I'm trying to have a program detect if a record is locked. If the program
> does find that the record it's trying to read is locked, it will wait 10
> seconds before retrying to read the same record from the file.
>
> Will placing the ITER operation accomplish this task in the code below?
> Should it wait 15 seconds then SETLL on the record it was trying to read
> then ITER?
>
> Is there an easier alternative for checking for locked records?
>
> Thanks,
>
> Frank
>
>
> =================================================
> F Customer UF E DISK
>
> D RecordLocked C CONST( 01218 )
> *
> /FREE
>
> KeyFld1 = %DEC(Field1:3:0);
> KeyFld2 = %DEC(Field2:7:0);
>
> // Read CUSTOMER File
> SETLL Custkey Customer;
> DOU %EOF(Customer);
> READ(E) Customer;
>
> // Record Locked
> IF %ERROR;
>
> // Record IS Locked
> IF %STATUS = RecordLocked;
> *WAIT 15 SECONDS
> ITER;
> ENDIF;
>
> ENDIF;
>
> ENDDO;
>
> ===================================================
>
> _______________________________________________
> 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.
>
>
------------------------------
message: 2
date: Mon, 29 Sep 2003 16:42:33 -0500
from: fkany@xxxxxxxxxxxxxxxxxx
subject: Re: Detecting Record Lock Conditions
Would using an OVRDBF FILE(CUSTOMER) WAITRCD(*NOMAX) in the CL that calls
the RPG work? I wouldn't have to change the RPG if I did it that way.
------------------------------
message: 3
date: Mon, 29 Sep 2003 15:47:54 -0600
from: James Rich <james@xxxxxxxxxxx>
subject: Re: Detecting Record Lock Conditions
fkany@xxxxxxxxxxxxxxxxxx wrote:
> I'm trying to have a program detect if a record is locked. If the program
> does find that the record it's trying to read is locked, it will wait 10
> seconds before retrying to read the same record from the file.
>
> Will placing the ITER operation accomplish this task in the code below?
> Should it wait 15 seconds then SETLL on the record it was trying to read
> then ITER?
>
> Is there an easier alternative for checking for locked records?
Here is what we do (not too fancy since we are on older releases):
FPROCHP UF A E K DISK INFDS(infds)
(skip infds definition)
Dallocate_record PR LIKE(ERA_errno)
Dprocnum 4S 2 VALUE
...
C eval err = allocate_record(proc)
C err ifeq FAIL
C select
C when ifstatus = RECORDLOCKED
C eval message = 'The procedure you selected is ' +
C 'in use.'
C when ifstatus = RECORDNOTFOUND
C eval message = 'The procedure you selected is ' +
C 'not found.'
C other
C eval message = 'Could not allocate record.'
C endsl
...
Pallocate_record B
Dallocate_record PI LIKE(ERA_errno)
Dprocnum 4S 2 VALUE
C prochkey klist
C kfld procnum
C prochkey chain PROCHR 1919
C *in19 ifeq *on
C return FAIL
C endif
C return SUCCESS
Pallocate_record E
We have some constants defined in a header file (like SUCCESS, FAIL,
etc.). Basically you use the infds to tell you if the record is locked
and then do something with that info (in this case send a message).
James Rich
------------------------------
message: 4
date: Mon, 29 Sep 2003 16:57:22 -0500 (Central Daylight Time)
from: "Booth Martin" <Booth@xxxxxxxxxxxx>
subject: Re: Detecting Record Lock Conditions
please consider condemning a record lock for over a second or two as an
error situation. Find the programs that have an extended lock and repair
them. Do not accept extended record locking as acceptable behavior. If a
record lock is encountered, send a message to yourself and fix the
circumstance that allowed it.
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
-------Original Message-------
From: RPG programming on the AS400 / iSeries
Date: Monday, September 29, 2003 16:14:41
To: RPG400-L@xxxxxxxxxxxx
Subject: Detecting Record Lock Conditions
I'm trying to have a program detect if a record is locked. If the program
does find that the record it's trying to read is locked, it will wait 10
seconds before retrying to read the same record from the file.
Will placing the ITER operation accomplish this task in the code below?
Should it wait 15 seconds then SETLL on the record it was trying to read
then ITER?
Is there an easier alternative for checking for locked records?
Thanks,
Frank
=================================================
F Customer UF E DISK
D RecordLocked C CONST( 01218 )
*
/FREE
KeyFld1 = %DEC(Field1:3:0);
KeyFld2 = %DEC(Field2:7:0);
// Read CUSTOMER File
SETLL Custkey Customer;
DOU %EOF(Customer);
READ(E) Customer;
// Record Locked
IF %ERROR;
// Record IS Locked
IF %STATUS = RecordLocked;
*WAIT 15 SECONDS
ITER;
ENDIF;
ENDIF;
ENDDO;
===================================================
------------------------------
message: 5
date: Tue, 30 Sep 2003 09:00:57 +1000
from: Simon Coulter <shc@xxxxxxxxxxxxxxxxx>
subject: Re: When is %EOF not an %EOF
On Tuesday, September 30, 2003, at 12:19 AM, DeLong, Eric wrote:
> I find it very interesting that by simply changing a reade to a read
> and then testing the keys manually can improve performance so
> dramatically.
>
The secret is blocking. Fixing the I/O is the single best thing you can
do to fix performance problems (presuming there are no physical
constraints like insufficient main storage, or a gutless processor).
As an example I changed a conversion process at a previous employer to
reorganise the work files into keyed sequential order, used a large
blocking factor, and dropped the run time from 3 days to 12 hours.
I wouldn't suggest that you religiously use "READ and test" in place of
READE especially if the values you want are widely separated (i.e., a
sparse key) but whenever you are processing large amounts of data
sequentially by key a good old-fashioned sort followed by sequential
reads can significantly improve the run time.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software AS/400 Technical Specialists
http://www.flybynight.com.au/
Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\
Fax: +61 3 9419 0175 mailto: shc@xxxxxxxxxxxxxxxxx \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
------------------------------
message: 6
date: 30 Sep 2003 12:39:44 -0000
from: "Murali dhar" <hydchap1@xxxxxxxxxxxxxx>
subject: error messages list
--------------------------------------------------------------------
(1)Job: RBYBADGDSC
Msg:-Cannot allocate object GDSCPRF1
Pgm:-YBADGDSC (C D I R)
--------------------------------------------------------------------
2)Job:-R1285X
Msg:-Duplicate keys were found while adding record to file
GFTBKRA.
RPG9036 Options (0 23F)
--------------------------------------------------------------------
3)Program YALT00020C errored out with options (C I 9999) as
YALT00020W was at maximum size.
--------------------------------------------------------------------
4)Job:-Journal
cmd:-STRBKUBRM
Msg:-End of volume ASP002 reached on device MLB3494.
No media of class JRNL_CLS is available at location MLB3494. (C
G)
Job 558787/ARAMBR/JOURNAL changed by QSYSOPR.
----------------------------------------------------------------------
hi all ,above are few errors and options you can take like C,D,I
etc,i want to know all such errors list?where can I see and get
such list of error messages and what are remedial actions (like
C,G,I,9999 etc ,explaining me in what situation i ve to take
C/G/I etc)I can take to nullify such erros in production
support.
Can anybody suggest me any notes available on net on this erros
messages.I wont be able to see all errors on system now unless i
experience them in future,i Know i can take help there and see for
the remedial actions..do we have any notes on list of all such
errors and remedial actions .....
Can anybody let me know for all 4 jobs
what exactly these letters stand for& what happens if i take
either of these for particular job?
C D I R
0 23F
C I 9999
C G
Thanks in adv,
Murali.
___________________________________________________
Television meets Accounts; Jyoti Weds Rajaram.
Rediff Matchmaker strikes another interesting match !!
Visit http://matchmaker.rediff.com?1
------------------------------
message: 7
date: Tue, 30 Sep 2003 09:58:19 -0400
from: "Walden H. Leverich III" <WaldenL@xxxxxxxxxxxxxxx>
subject: RE: Detecting Record Lock Conditions
>please consider condemning a record lock for over a second or two
>as an error situation.
In general I agree, but I think 1-2 seconds is a little fast. For online
programs I can't imagine a lock > 1-2 seconds, but for batch programs with
commitment control I could see wait times of > 10 seconds.
-Walden
------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
-----Original Message-----
From: Booth Martin [mailto:Booth@xxxxxxxxxxxx]
Sent: Monday, September 29, 2003 5:57 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Detecting Record Lock Conditions
please consider condemning a record lock for over a second or two as an
error situation. Find the programs that have an extended lock and repair
them. Do not accept extended record locking as acceptable behavior. If a
record lock is encountered, send a message to yourself and fix the
circumstance that allowed it.
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
-------Original Message-------
From: RPG programming on the AS400 / iSeries
Date: Monday, September 29, 2003 16:14:41
To: RPG400-L@xxxxxxxxxxxx
Subject: Detecting Record Lock Conditions
I'm trying to have a program detect if a record is locked. If the program
does find that the record it's trying to read is locked, it will wait 10
seconds before retrying to read the same record from the file.
Will placing the ITER operation accomplish this task in the code below?
Should it wait 15 seconds then SETLL on the record it was trying to read
then ITER?
Is there an easier alternative for checking for locked records?
Thanks,
Frank
=================================================
F Customer UF E DISK
D RecordLocked C CONST( 01218 )
*
/FREE
KeyFld1 = %DEC(Field1:3:0);
KeyFld2 = %DEC(Field2:7:0);
// Read CUSTOMER File
SETLL Custkey Customer;
DOU %EOF(Customer);
READ(E) Customer;
// Record Locked
IF %ERROR;
// Record IS Locked
IF %STATUS = RecordLocked;
*WAIT 15 SECONDS
ITER;
ENDIF;
ENDIF;
ENDDO;
===================================================
_______________________________________________
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.
------------------------------
message: 8
date: Tue, 30 Sep 2003 10:28:06 -0400
from: "Buck" <buck.calabro@xxxxxxxxxxxx>
subject: Re: error messages list
Hi Murali!
-snip CPF/RPG messages-
> hi all ,above are few errors and options you
> can take like C,D,I etc,i want to know all
> such errors list?
The list of messages changes (grows) with each release of OS/400. You can
look at the message files to find the text of the messages (try WRKMSGF) but
that might not be very helpful. Do keep in mind that we can create our own
message files and our own messages; not just IBM.
> and what are remedial actions (like C,G,I,9999 etc ,
> explaining me in what situation i ve to take
> C/G/I etc)I can take to nullify such erros in production
> support.
Nobody can tell you the answer to this question because it depends entirely
on the job, the error and the database; all of these are unique to you. The
only thing we can tell you is to put the cursor on the message and press F1
to see the extended help. Read it carefully before answering the message,
because the text of the message explains what each choice means.
One bit of advice I can give you is that when you post error messages to a
mailing list or web forum, be sure to post the message ID: like RPG9036.
Also post what happened to cause the message (in this case, it would be a
WRITE.) That way other people can look up the message (in their message
file) and give you better advice. Speaking of which, if this advice didn't
help, try the MIDRANGE-L list. Any program can produce error messages, not
just RPG, so there may be some other advice people there can give to you.
--buck
------------------------------
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) digest 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.
End of RPG400-L Digest, Vol 2, Issue 723
****************************************
As an Amazon Associate we earn from qualifying purchases.
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.
