Question PS Timer question time

B

BobyIsProgress

Member
Hello everyone,

I have some issue with a program is supposed to make stock movement according to a Bill Of Material.
99% of the time it's working perfectly. But without warning for some reason we don't know about, we have the first movement and not the other. It's not linked to product setting cause, if close everything and try again it worked.

We aren't able to replicate this situation.

I have two ideas:

1. We have another program that is runing in the user session that has a PS Timer that tick every 5 min. So is it possible that the tick can interfer with a program actually processed by the session . I know that it's procedural and not managing multitasking but can this make an issue ?

2. Our issue is that the following says not available:
Code: 
DO TRANSACTION:
 FIND FIRST myWorkTable EXCLUSIVE-LOCK NO-ERROR .
 IF NOT AVAILABLE myWorkTable THEN "ERROR".
 END.

This instruction is in a cascade of two programs by using a shared work table
Program parents :
Code: 
DEFINE NEW SHARED WORK-TABLE myWorkTabke NO-UNDO
field myField AS CHAR ....

DO:
  create myWorkTable.
  ASSIGN
           myWorkTable.myField = "some value" .

    run childProc.p .
END.

and childProc.p
Code: 
DEFINE SHARE WORKTABLE myWorkTable NO-UNDO
field myField AS CHAR.

DO TRANSACTION:

 FIND FIRST myWorkTable EXCLUSIVE-LOCK NO-ERROR .
 IF NOT AVAILABLE myWorkTable THEN "ERROR".
 END.


So I was thinking that we have issue with the shared work-tabke but not sure about it also.

We are running OE11.7 on windows 2022 server. We have the same issue on OE10.2.0b and same windows server .

Thanks in advance
 
It has been years since I used work-tables and cannot remember if they had this problem.

The following rules for work-tables are listed here - one rule is finding with EXCLUSIVE-LOCK is disregarded - and is it possible the timer is resulting in the work-table being affected by applying one of these rules?:

Progress Documentation

docs.progress.com docs.progress.com
 
A few suggestions you could try:

1. Use a buffer for the worktable in all places this is referenced. I have seen it solve problems in a lot of places where strange behaviour occurred
2. Use a temp-table instead of worktables. Not likely to be the cause of your issue, but at least it pulls you out of the 20th century
3. Pass the record as a buffer parameter to childProc.p
 
Presumably your sample code is simplified for our benefit so maybe my comments do not apply but...

1) As has been pointed out work-tables do not participate in record locking.

2) When you FIND FIRST ... NO-ERROR you are, basically, checking to see if any records at all exist in that work-table. Is there some reason to think that that it is wrong when it reports "ERROR"? If your sample code is less simple than what we are seeing then it seems quite possible that the CREATE may have not happened (for whatever reason) or that an UNDO may have undone any records that were created.

3) If you are doing something more sophisticated than FIND FIRST, maybe a FIND WHERE, then, again, what is your evidence that the reported "ERROR" is incorrect?
 
Its duct-tape programming, but since you're using worktables and locking them exclusively, the code is already basically lost, so (end of rant) you could try this:

Code: 
DEFINE SHARE WORKTABLE myWorkTable NO-UNDO
field myField AS CHAR.

DO TRANSACTION:

 FIND FIRST myWorkTable NO-ERROR .
 IF NOT AVAILABLE myWorkTable THEN FIND FIRST myWorkTable NO-ERROR.
 IF NOT AVAILABLE myWorkTable THEN "ERROR".
 END.

Basically you're repeating the find. Kind of: if not succesful, try again....
 
TomBascom said:
Presumably your sample code is simplified for our benefit so maybe my comments do not apply but...

1) As has been pointed out work-tables do not participate in record locking.

2) When you FIND FIRST ... NO-ERROR you are, basically, checking to see if any records at all exist in that work-table. Is there some reason to think that that it is wrong when it reports "ERROR"? If your sample code is less simple than what we are seeing then it seems quite possible that the CREATE may have not happened (for whatever reason) or that an UNDO may have undone any records that were created.

3) If you are doing something more sophisticated than FIND FIRST, maybe a FIND WHERE, then, again, what is your evidence that the reported "ERROR" is incorrect?
Click to expand...
1) Ok so the fact that maybe It was the recod locked is to be put aside

2/3) It's as simple as written. The aim is to check if we have something to do. If not it will go back with an error message . So it's a FIND FIRST EXLCUSIVE-LOCK NO-ERROR. If I have understand well, because WORK-TABLES doensn't participate in locking, if the FIND FIRST return NOT AVAILABLE, it means that there is no record in the WORK-TABLE.

So Could it be that the link between the NEW SHARED (in the program parent) and the SHARED (in the child proc) has been cut off ? Could the tick of the PS Timer responsible of that ?

Best Regards
 
PatrickTingen said:
Its duct-tape programming, but since you're using worktables and locking them exclusively, the code is already basically lost, so (end of rant) you could try this:

Code: 
DEFINE SHARE WORKTABLE myWorkTable NO-UNDO
field myField AS CHAR.

DO TRANSACTION:

 FIND FIRST myWorkTable NO-ERROR .
 IF NOT AVAILABLE myWorkTable THEN FIND FIRST myWorkTable NO-ERROR.
 IF NOT AVAILABLE myWorkTable THEN "ERROR".
 END.

Basically you're repeating the find. Kind of: if not succesful, try again....
Click to expand...
I know and maybe I'm working and spending time of something that will not exist in the near future but has for now, it's causing us terrible issue so I have to found the cause and fix it :)
 
Just out of curiosity, what application is this, an (old) version of MFG/Pro?
You say another process is running a pstimer. Does that program do something with the worktable?

Is there an option to rewrite this part to work with a buffer parameter?
Your code would then look something like this:
Code: 
/* parentProc.p
*/
DEFINE NEW SHARED WORK-TABLE myWorkTable NO-UNDO
  FIELD myField AS CHAR.

DO TRANSACTION:
  CREATE myWorkTable.
  ASSIGN myWorkTable.myField = "some value".
 
  RUN childProc.p(BUFFER myWorkTable).
END.
Code: 
/* childProc.p
*/
DEFINE SHARED WORK-TABLE myWorkTable NO-UNDO
  FIELD myField AS CHAR.

DEFINE PARAMETER BUFFER bWorkTable FOR myWorkTable.

DO TRANSACTION:
  FIND FIRST bWorkTable EXCLUSIVE-LOCK NO-ERROR .
  IF NOT AVAILABLE bWorkTable
    THEN MESSAGE "ERROR" VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.
    ELSE MESSAGE bWorkTable.myField VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.
END.
 
You must log in or register to reply here.
Back
Top