RE: Data Area Locking

Hmm...We do this all the time.  This may be pointing out the obvious,
but are you doing it in a loop?

e. g.

dou NOT %error;
    in (e) *lock data_darea;
enddo;
//code to use the data area value....

Among other things, we use this for order numbers. The probability of
contention for the data area is high. We've never had a problem.

Do you have ghost sessions?  Someone's pc crashes when the emulation
session has a lock on the data area or someone clicks the close box on
an emulation session.

BTW, if the id number is necessary, the program should halt if it's
impossible to get at the data area. 



> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Brown,
> Keith (MAN-Corporate)
> Sent: Monday, May 09, 2005 11:31 AM
> To: 'rpg400-l@xxxxxxxxxxxx'
> Subject: Data Area Locking
>
> We use a data to maintain an unique ID number - Application
> RPG programs call a dedicated RPG program that uses the data
> area to generate a new ID.
> The RPG program to generate the ID uses the data area in the following
> manner:  1.) retrieve the data-area to import the current ID
> number 2.) increment the current ID number by one to generate
> a new ID and 3.) update the data-area for the new ID number
> 4.) release the data area.
>
> On occasion we get the following sequence of messages when
> the RPG program that locks the data-area is unable to execute
> the IN operation against the
> data-area:
> MCH5802       20     Lock operation for object &1 not satisfied.
> RNQ0431       99     Data area &6 was allocated to another
> process (C G D F)
> 
> The RPG program will go into MSGW until the RNQ0431 message
> is answered.  I have tried to use the Error Indicator and
> Error extender on the IN operation to prevent the message
> wait state be no such luck.  What can I do to prevent the
> programs from going into the message wait state when unable
> to allocate the data area?  I thought using the error
> indicator/extender on the IN operation would prevent the
> MSGW; much like what happens on database file I/O operations.
>
> Thanks,
> Keith
> --
> 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.
>
>

*****************************
NOTICE:
All e-mail sent to or from this e-mail address will be received or otherwise 
recorded by
The Sharper Image corporate e-mail system and is subject to archival, 
monitoring,
and review by and/or disclosure to Sharper Image security and other management.
This message is intended only for the use of the addressee and may contain 
information
that is privileged and confidential.

The contents of this message may contain personal views which are not the views 
of The Sharper Image.
If you are not the intended recipient, dissemination of this communication is 
prohibited.
*****************************