jp.aalders
22nd December 2004, 13:00
Hi all
I'm currently developing an AFS session to maintain the delivery date in maintain production orders [tisfc0101m000]. AFS is working fine but the tisfc0101m000 session is executing the session tisfc0505m000 autmatically. When AFS is finished these tisfc0505m000 sessions are not closed which results in a lot of running tisfc0505m000 sessions. I've tried to close down these sessions using stpapi.end.session(tisfc0505m000) and the stpapi.handle.subproc but none of these closes down the tisfc0505m000 sessions. Any ideas about closing down the sessions would be very helpful.
Thanks and a merry x-mas to all of you :D
kbartelds
22nd December 2004, 14:53
stpapi.handle.subproc("tisfc0101m000","tisfc0501s000", kill) might solve the problem. I have made some afs scripts on sfc (including changing delivery date) and don't bother about the subsessions involved and it works fine. So maybe trying to close this subsession is causing the problem.
Klaas
mark_h
22nd December 2004, 15:14
Hi jp.alders!
I toned down the size on your original post. It almost blinded me when I first pulled it up - not a good thing this early in the morning. :)
Also, if what Klaas posted does not work, maybe you could post your code. That might help someone else see where to insert the stpapi.handle.subproc. Once you get control of the session then stpapi.end should work.
Mark
jp.aalders
23rd December 2004, 09:33
Hi Klaas and Mark,
Both thanks for your reply. Below you'll find the part of the source which causes the tisfc0505m000 session open. Be aware that not tisfc0505s000 remains open but tisfc0505m000. I've tried to close this session both using the stpapi.handle.subproc("tisfc0101m000","tisfc0505s000","kill"), stpapi.handle.subproc("tisfc0101m000","tisfc0505m000","kill") and stpapi.end.session("tisfc0505m000") but in all cases the tisfc0505m000 session is not killed. As many updates are executed a lot of the tisfc0505m000 sessions stay open.
Any ideas would be welcome.
Thanks in advance,
JP
|* Search productionordernumber for rescheduling message
stpapi.put.field("tisfc0101m000","tisfc001.pdno",str$(afs.pdno))
stpapi.get.field("tisfc0101m000","tisfc001.pdno",pdno.found)
retval_fnd = stpapi.find("tisfc0101m000",error.msg.find)
|* If found, change delivery date ( tisfc010.dldt ).
IF retval_fnd = 1
THEN
|* Check production order date.
IF timrp030.date < tisfc001.prdt
THEN
stpapi.put.field("tisfc0101m000","tisfc001.prdt",str$(new.prdt))
ENDIF
stpapi.put.field("tisfc0101m000","tisfc001.dldt",str$(timrp030.date))
retval_upd = stpapi.update("tisfc0101m000",1,error.msg.upd)
stpapi.handle.subproc("tisfc0101m000","tisfc0505s000","kill")
| stpapi.end.session("tisfc0505m000") |< has no result
stpapi.end.session("tisfc0101m000")
kbartelds
23rd December 2004, 10:58
If you debug your script, can you see in afs.log when the subsession (tisfc0505m000 or tisfc0505s000) is activated?
According to your script:
stpapi.put.field
stpapi.get.field
stpapi.find
This should be:
stpapi.put.field
stpapi.find
stpapi.get.field to check the ordernumber found
Also missing are the stpapi.recover actions in case the find or update doesn't succeed.
This is the script I use:
function update.delivery.date()
{
stpapi.put.field("tisfc0101m000","tisfc001.pdno",str$(tisfc001.pdno))
retval1 = stpapi.find("tisfc0101m000",find.mess)
if retval1 then
stpapi.enum.answer("tisfc0101m000","tisfc01016",tcyesno.no)
stpapi.put.field("tisfc0101m000","tisfc001.dldt",str$(new.dldt))
if new.prdt <> 0 then
stpapi.put.field("tisfc0101m000","tisfc001.prdt",str$(new.prdt))
endif
retval2 = stpapi.update("tisfc0101m000",true, update.mess)
if not retval2 then
retval3 = stpapi.recover("tisfc0101m000",recover.mess)
endif
else
stpapi.recover("tisfc0101m000",recover.mess)
endif
stpapi.end.session("tisfc0101m000",end.sess.mess)
}
jp.aalders
23rd December 2004, 13:30
Hi Klaas,
Thanks for your assistance again. You're right about the "put" and "get" sequences so I changed them. Futhermore I've executed the session with an AFS log but the only thing about tisfc0505m000 that occured in the log is the handle.sub.proc. as set up in the script.
I've also run the AFS session in debug mode and checked when the tisfc0505m000 session is started using the BW option-dialog. ( ps ). It occured that the tisfc0505m000 session is directly started as soon as the order is searched in AFS ( stpapi.find ). Closing down the tisfc0505m000 session using handle.sub.proc or stpapi.end.session does not result in stopping the session. In the meanwhile I discovered that there the script for tisfc0101m000 is customer specific ( Atos Origin development ) and so I strongly suspect this to be the cause of the trouble.
Ant other ideas are off course very welcome!
Regards,
JP
kbartelds
23rd December 2004, 13:40
If you want, you can call me so we can see if we can work this one out, at the office 073 5441234
Klaas