Hi,
I have a strange problem with some AFS calls.

I have a session say X and I am calling session Y through AFS from session X which in-turn calls session Z (session Y calls session Z through AFS). Everything works fine but the session X hangs after all the work and I have to manually kill session Y to get the control back to session X.

Is there anything wrong with calling sessions through AFS that in-turn calls another session using AFS?

Any advice? Appreciate your help.

Thanks,
NS

There is nothing wrong with this as long as you close the sessions in the correct order. I have add to manually kill sessions to get control back - the code is in this forum(probably a search on kill would find it). Other things I have done is to clone sessions so I could control them - not sure what sessions you are talking about, but the actual session names might help.

Mark,
Thanks for the quick response.

I have written a session that takes an Engineering Item and a Revision as input and releases that revision using the session tiedm1101m000 (Maintain Engineering Item Revisions). I have also modified the session tiedm1101m000 to do the following when a revision gets released.

- Generate EBOM copy data (tiedm1230m000)
- Finalize Engineering data (tiedm3240m000)
- Update Sales Orders lines (tdsls4102s000)

Each of the above session is closed as soon as they are done. The problem I am having is that the control hangs after executing the above three sessions at session tiedm1101m000 and the control never returned to the original session that called the session tiedm1101m000. If I kill the session tiedm1101m000, the control is returned to the original session.

Like you said, I am thinking of adding a line in the session tiedm1101m000 to kill it if it’s running in the api mode.


Thanks,
NS

Something to try is to remove tdsls4102s000 and see if control returns to tiedm1101m000. I am wondering if one of these three sessions is leaving something "open" and this causes tiedm1101m000 to appear hung after they have completed. Just a guess, but I usually do not run sub-sessions directly and you do not mention tdsls4101m000 which I think is used to launch tdsls4102s000. Just curious if this might be what is causing the problem.

Another thing I have run into using sub-sessions like tdsls4102s000 is that they use a display session to do the top part of the form. I have seen problems when I try to end these display sessions. In the last service pack release I had to go thru and remove the stpapi.end for these sessions. Just some thoughts.

Mark,
Thanks again for your response. I tried running the session without updating the sales order lines and it still ended up hanging.

To reconfirm what’s happing I just wrote a little script with entirely different sessions and it also gave me the same results.

Here’s what I did:
Custom session (the following code gets executed on cont.process)
_____________________________________________________________________
stpapi.put.field("tccom1101m000", "tccom010.cuno", "505641")
ret = stpapi.find("tccom1101m000")
if ret = 1 then
stpapi.put.field("tccom1101m000", "tccom010.namf", str$(date.num()) & str$(time.num()))
stpapi.update("tccom1101m000", true, err.msg)
endif
stpapi.end.session("tccom1101m000")
_____________________________________________________________________

Now, in the session tccom1101m000, I have added this piece of code under choice.update.db (also tried it under after.update.db.commit section)
_____________________________________________________________________
stpapi.put.field("tcmcs0145m000", "tcmcs045.creg", "ACG")
ret = stpapi.find("tcmcs0145m000")
if ret = 1 then
stpapi.put.field("tcmcs0145m000", "tcmcs045.dsca", str$(date.num()) & str$(time.num()))
stpapi.update("tcmcs0145m000", true, err.msg)
endif
stpapi.end.session("tcmcs0145m000")
_____________________________________________________________________

So, when I run my custom session, it goes into tccom1101m00, updates the description, then it calls tcmcs0145m000, updates the description there but when it executes line stpapi.update("tcmcs0145m000", true, err.msg) it just hangs. When I kill the session tccom1101m000, the control comes back to the custom session.

I am not sure if I am overlooking something simple.

Thanks,
NS

One interesting note is that, if I put the AFS code that is in the session tccom1101m000 in any of the sections that deals with updating the table (such update.db, after.update.db.commit, before.rewrite) it hangs. If I put the same code say in init.form or choice.end.program it works fine. I tried to play with the true/false flag in the stpapi.update function without any luck.

I put this code into a program today:

choice.update.db:
after.choice:
| check.all.input()
| 110 Expense Order
stpapi.put.field("tcmcs0145m000", "tcmcs045.creg", "110")
ret = stpapi.find("tcmcs0145m000")
if ret = 1 then
stpapi.put.field("tcmcs0145m000", "tcmcs045.dsca", str$(date.num()) & str$(time.num()))
stpapi.update("tcmcs0145m000", true, err.msg)
endif
stpapi.end.session("tcmcs0145m000")
stpapi.put.field("tccom1101m000", "tccom010.cuno", "000100")
ret = stpapi.find("tccom1101m000")
if ret = 1 then | CA
stpapi.put.field("tccom1101m000", "tccom010.namf", str$(date.num()) & str$(time.num()))
stpapi.update("tccom1101m000", true, err.msg)
endif
stpapi.end.session("tccom1101m000")


It ran just fine for me - we are on service pack 19, porting set 6.1c.07.04 - not sure what tools version.

The procedure in EDM module can often indeed be too lengthy. I've used AFS to create shortcuts too, but I use different method. Instead of using AFS to control tiedm1101m000 which in turn controls tiedm1230m000, tiedm3240m000 and tdsls4102s000, how about creating an AFS-based program that controls all four directly? It may sounds less daunting from technical programming point of view, but, as for me, I like it simple. I did it in BaanERP, by the way, not in BaanIV like what you have

Rgds,
Paul