Re: DTAARA Lock Issue?

Even if another program is incrementing the TMP#, it should not be an issue as the data area is locked in the interim.

But... Buck's response prompted me to look at the other programs using the data area. I need to dig deeper but I may have stumbled across something. There *may* be an inconsistency with another program or two as far as which value they're using - pre-increment or post-increment. It would have to be the right confluence of events but that is possible and would certainly explain it. As Buck said, I too have never seen an IN *LOCK not lock.

Thanks all for your suggestions and tips.

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power



From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxx> on behalf of Charles Wilt <charles.wilt@xxxxxxxxx>
Sent: Monday, April 17, 2017 9:51 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: DTAARA Lock Issue?
 
Think Buck is onto something...

Don't supposed the DTAARA is journaled?



On Mon, Apr 17, 2017 at 10:35 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 4/17/2017 11:33 AM, Roger Harman wrote:

Two jobs retrieved the same number.

NOTE:  Not my code - I just have to work with it.  Why it has the

add/z-add combo is unknown.

**  Data structure for next system number
**  & next temporary reference.
D NextNum       DS         14
D  NSYSNA                  1     7
D  NSYSNN                  1     7  0
D  TMPRNA                 8   14
D  TMPRNN                 8  14  0

C     SrGetSys      Begsr

C    *DTAARA      DEFINE    SYSNBR  NextNum

C     *LOCK         IN        NextNum
C     NSYSNA      IFEQ    *BLANKS
C                         Z-ADD     1             NSYSNN
C                         ENDIF

C     NSYSNN     ADD       1                 UPDNBR
C                         Z-ADD   UPDNBR    NSYSNN
C                        OUT        NextNum

C                        Endsr

Thanks for posting the code; I found it helpful.  As a preface, I've
used *LOCK IN in many dozens of programs; over the 3 decades or so
probably a few billion update cycles.  I've never, not once, seen an
issue with the OS.  It's always been the program.  That said, there is a
gotcha with this sample.

The data area is storing /two/ 'unique' numbers, right?  You've been
focussed on two jobs that are trying to get a unique NSYSNN, but what if
there's a third job that's trying to get a unique TMPRNN?  It could be
putting back an /old/ copy of NSYSNN as it increments TMPRNN.

Another possibility is a *PSSR/INFSR that somehow gets control between
the IN and the OUT.  Seems unlikely, but we're looking for something
non-obvious, so I bring it up.  The point is that job 1 might get number
555 and not increment it properly.

--
   --buck

Try wiki.midrange.com!

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

RPG400-L Info Page - midrange.com
lists.midrange.com
To unsubscribe from RPG400-L, get a password reminder, or change your subscription options enter your subscription email address:

or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD