ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Record Lock condition on update

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Record Lock condition on update

    HELLO everyone,


    I have an interactive session and a batch job in RPG STYLE both are accessing the same file.

    the batch job does a setll,reade(e) with EOF indicator and then an updates the file.

    I have two questions.

    The interactive job locked one of the records that the batch was trying to access.However the batch job cancelled the interactive job .i wanted to know at what statement this happens and how is this happening.
    why did the the batch job cancelled the interactive job.

    The batch job failed at the update statement because it was unable to acquire the lock.so it must have passed through the reade before .How did it pass the reade operation without acquireing the lock inside the loop to do the update and failed here ?




  • #2
    There is no way that I know of where a batch job can cancel an interactive job on it's own unless it ran come code that determined which job had a lock on the record and cancelled it, but that has to be programmed so you would see it.

    The program passed through the READE because it was coded with the (E) extender on it which will trap any file errors and continue with the next statement. If you want to detect that a file error occurred, then use the %ERROR built in function after the READE.

    Comment


    • #3
      Originally posted by Brian Rusch View Post
      There is no way that I know of where a batch job can cancel an interactive job on it's own unless it ran come code that determined which job had a lock on the record and cancelled it, but that has to be programmed so you would see it.

      The program passed through the READE because it was coded with the (E) extender on it which will trap any file errors and continue with the next statement. If you want to detect that a file error occurred, then use the %ERROR built in function after the READE.

      Hello Brian,

      I will try to explain the flow

      1. reade e 51 eof ind
      2. check for record lock using check status and %error send a warning msg if record is locked
      3. then do a reade(e) without any indicators and check again for %error and status
      3.if record locked then ends the job.
      4.does a reade again without any indicators
      5.dow *in51 =0
      6.update
      7.enddo

      i am trying to understand why the record was not locked on the last reade and the program processed the update.

      Comment


      • #4
        Well wouldn't that be because the interactive job that had the lock was cancelled, thus releasing the lock and allowing the update?

        Canceling the interactive job seems Draconian to me - we have a process that reacts to any record in use message (RPG1218/RNQ1218) hitting QSYSOPR message queue, and it sends a break message and an email to the interactive user locking the record...then, after 30 seconds, sends a "R" reply to the lock message. Has worked extremely well.

        Cheers,

        Emmanuel

        Comment


        • #5
          I agree with Emmanuel - cancelling the job is overly draconian.

          I'm also concerned by the fact that you appear to be using a mix of old-style indicators <shudder> - the (E) extender and BIFs. Frankly at best that is a recipe for confusion and at worst an accident waiting to happen. Use the %EOF BIF if you want to check for end of file and use (E) and %Error for errors. Don't mix them - you're asking for trouble.

          Comment


          • #6
            Originally posted by satya View Post
            4.does a reade again without any indicators
            5.dow *in51 =0
            6.update
            7.enddo

            i am trying to understand why the record was not locked on the last reade and the program processed the update.
            If you're not using any indicators on the READE, at step 4, what is setting *IN51? It's still got the condition from the first READE at step 1 so your code would suggest the UPDATE is in an infinite loop and should error on the 2nd attempt.
            You mention that the job is ended but does that mean you've checked if the job has actually ended or have you just issued an ENDJOB command? If you just issue an ENDJOB command, it takes time for the system to deallocate resources etc so the record may still be locked if your program tries to read the record again. You're not checking for a successful READE at step 4. And what happens if another job locks the record in the meantime?

            As JonBoy has suggested, mixing indicators and BIFs makes code harder to read and I've always thought indicators have had their day long ago...

            Comment

            Working...
            X