Dear Board members

I am facing this problem while using AFS on session "tdilc4202m000". The changes doesnot get reflected in the database until I close the calling session.
On inspecting current process status I found that the process "ottstpapiserv" is still active even after execution of "stpapi.end.session"

I am attaching screenshot of process status window which I took after executing the AFS.

That should not be the problem - I was just testing and it stays running for me. The process that concerns me is the ottstpmsg. What message is it trying to give? And what do you mean close the calling session - are you talking the the tdcus0162m000 session?

Dear Mark

Thanks for a prompt reply.

Actually this session (tdilc4202m000) generates two reports - a success report(tdilc420201000) and another an error report (tdilc420103000). In case it does not find any replenishment orde to release for outbound, it gives message " No records Found".

The calling session - is the tdcus0162m000 session, I am using function containing AFS code from this session.

This is a "Maintain" type session(customized). which uses data updated by this AFS to populate table tdcus062. But since the change by AFS is not reflected we need to restart the session.

There have always been issues with sessions that generate two reports. Below is what I do - this code has been running since 2004. The get last message code should get the "no records found" message. I still do not see where ottstpapiserv is the problem. Once my code hits the continue the outbound is released and reflected in the database.

After calling the tdilc4202m000 is control not returning to tdcus0162m000 session? I still do not understand what you have to restart - if the api code does not work then why do you need to restart tdcus0162m000? If the api code works, but something in tdcus0162m000 is hanging then the problem is not in the api code. What change is not reflected where in which table? As far as I can tell you code would release outbound - which would be reflected in the baan tables.



function extern release_outbound( domain tcmcs.str12 runnumber.f,
domain tcmcs.str12 runnumber.t,
domain tcorno run.order.f,
domain tcorno run.order.t,
domain tcpono run.oper.f,
domain tcpono run.oper.t,
domain tcitem run.item.f,
domain tcitem run.item.t,
domain tccwar run.cwar.f,
domain tccwar run.cwar.t,
domain tcmcs.str14 run.sess,
ref string msg())
{
msg = ""
stpapi.put.field("tdilc4202m000","runnumber.f",runnumber.f)
stpapi.put.field("tdilc4202m000","runnumber.t",runnumber.t)
stpapi.put.field("tdilc4202m000","koor.f",str$(tdilc.koob.act.sfc))
stpapi.put.field("tdilc4202m000","koor.t",str$(tdilc.koob.act.sfc))
stpapi.put.field("tdilc4202m000","orno.f",str$(run.order.f))
stpapi.put.field("tdilc4202m000","orno.t",str$(run.order.t))
stpapi.put.field("tdilc4202m000","opno.f",str$(run.oper.f))
stpapi.put.field("tdilc4202m000","opno.t",str$(run.oper.t))
stpapi.put.field("tdilc4202m000","prdt.t",str$(date.num()+1000))
stpapi.put.field("tdilc4202m000","ddta.f",str$(date.num()-1000))
stpapi.put.field("tdilc4202m000","ddta.t",str$(date.num()+1000))
stpapi.put.field("tdilc4202m000","item.f",run.item.f)
stpapi.put.field("tdilc4202m000","item.t",run.item.t)
stpapi.put.field("tdilc4202m000","cwar.f",run.cwar.f)
stpapi.put.field("tdilc4202m000","cwar.t",run.cwar.t)
stpapi.put.field("tdilc4202m000","gcid.f","")
stpapi.put.field("tdilc4202m000","gcid.t","ZZZZZZZZZZZZZZZZZZZZZZ")
stpapi.put.field("tdilc4202m000","pino.f","0")
stpapi.put.field("tdilc4202m000","pino.t","999999")
stpapi.put.field("tdilc4202m000","cuno.f","")
stpapi.put.field("tdilc4202m000","cuno.t","ZZZZZZ")
stpapi.put.field("tdilc4202m000","cprj.f","")
stpapi.put.field("tdilc4202m000","cprj.t","ZZZZZZ")
stpapi.put.field("tdilc4202m000","cntr.f","")
stpapi.put.field("tdilc4202m000","cntr.t","ZZZ")
stpapi.put.field("tdilc4202m000","crte.f","")
stpapi.put.field("tdilc4202m000","crte.t","ZZZZZ")
stpapi.put.field("tdilc4202m000","deliver.costitem",str$(etol(tcyesno.no)))
|20050225 - all sessions calling this routine now run its own release outbound report
| if strip$(run.sess) = "tdapi4201m000" or
| strip$(run.sess) = "tdapi4135m000" then
spool.fileout = creat.tmp.file$(bse.tmp.dir$())
stpapi.set.report("tdilc4202m000","rtdilc440201000","ASCIF",msg)
| else
| stpapi.set.report("tdilc4202m000","rtdilc440201000",spool.device,msg)
| endif
if isspace(msg) then
stpapi.continue.process("tdilc4202m000",msg)
some.msg = stpapi.get.mess.code("tdilc4202m000",msg)
endif
stpapi.end.session("tdilc4202m000")
}

Dear mark_h

Thanks again for your valuable comments

Let me clarify your queries :

"After calling the tdilc4202m000 is control not returning to tdcus0162m000 session?" - The control indeed returns to tdcus0162m000, but the process istpapiserv is still active and the table field tdilc401.proc shows value "No" (It seems changes are not commited yet)

I still do not understand what you have to restart - if the api code does not work then why do you need to restart tdcus0162m000? - Once I close the session tdcus0162m000, the changes are visible in table tdilc401 and process istpapiserv is closed. There is a report on print button which works only when this field(tdilc401.proc) is set to "yes", that is why either I need to restart the session or I need to start the report independently.

Thanks and Regards

Now I understand better. Okay - it could be as simple as updating you stpapi libraries. When I run one of my api sessions ottstpapiserv stays open after it completes and after the session is completed or ended. So I am not sure why you need to kill the ottstpapiserv process. Now I have had timing issues - for example open a session process a record, THEN I suspend for a few seconds to let the record process, then I end the session. I do not think this is the case - I would first look at updating stpapi libraries. OR if you have session code, put the session it debug mode and see if anything is being missed.

Dear Mark_h

Thanks for your observation and patience

I dont have the code for the session, hence I think I would first check out by updating STPAPI libaries, Can you just give a brief idea about it, is it related to updating porting set?.

We are currently working on Baan IV C4, Porting set 6.1C.7.13

I would check with info - they can provide the lastest libraries and portingset. I am not positive about how the portingset interacts with API libraries. All I know is that once a new portingset broke several of my sessions. I believe baan just provided us stpapi library updates and it resolved most of the problems.

Hello all,

I am running in a problem that when I run an stpapi.* and complete the session by stpapi.end.session... all is fine but, the ottstpapiserv doesn't end and remains active, this makes the next transaction in the calling session to hangs.

I tried to kill it after calling stpapi.end.session; by finding the process id of ottstpapiserv and kill it but, my next transaction to process the stpapi.* doesn't do anything and ottstpapiserv doesn't wakes up.

Any ideas, I will appreciate your help.

I ran some sample code just to confirm - ottstpapiserv starts on the first stpapi command like a put field. The I run some test code. I do a stpapi.end on two sessions. Now I can run this multiple times - but ottstpapiserv does not close until I close the session itself. Once it starts it stays up until I close my session out all together. So I am thinking unless you are having issues with other sessions hanging like this with ottstpapiserv then it might be something else causing the problem. It could be the session being called. I am assuming you do not see anything else running after ending the session. What session are you calling? Are you like looping thru a set of records and running same sessions over and over quickly(I have had to use suspend to get some of them to work and not hang)? Can you post the code?

Hello Mark,

session is tdpur4120, maintain receipts

As I said, it does work but when next receipt, will hang because ottstpapiserv remains active.


after.update.db.commit:
if choice = 15 or choice = 21 then
if other statemens...... ... then
do.all.occ(maintain.approval,tdpur045.reno,tdpur045.orno,tdpur045.pono,
tdpur045.srnb,tdpur045.dqua)
endif
endif

functions:

function maintain.approval(domain tcrcno i.reno, domain tcorno i.orno, domain tcpono i.pono,
domain tcsrnb i.srnb, domain tcqrd1 i.dqua)
{
tdpur.dll9000.maintain.approval(i.reno,i.orno,i.pono,i.srnb,i.dqua)
}


library:


function extern domain tcbool tdpur.dll9000.maintain.approval(domain tcrcno i.reno,domain tcorno i.orno, domain tcpono i.pono, domain tcsrnb i.srnb, domain tcqrd1 i.dqua)
{
domain tcmcs.str300m error.mess

stpapi.put.field("tdpur4121m000","tdpur045.reno",str$(i.reno))
stpapi.put.field("tdpur4121m000","tdpur045.orno",str$(i.orno))
stpapi.put.field("tdpur4121m000","tdpur045.pono",str$(i.pono))
stpapi.put.field("tdpur4121m000","tdpur045.srnb",str$(i.srnb))
if stpapi.find("tdpur4121m000") = 1 then
stpapi.put.field("tdpur4121m000","tdpur045.quap",str$(i.dqua))
stpapi.update("tdpur4121m000",true,error.mess)
if not isspace(error.mess) then
message(error.mess,0)
stpapi.recover("tdpur4121m000",error.mess)
stpapi.end.session("tdpur4121m000")
return(false)
endif
endif
stpapi.end.session("tdpur4121m000")
return(true)
}


thanks in advance,

Have you tested other api code to see if it ottstpapiserve stays up after the last session.end?

Your code basically looks like mine except I have 2 questions I answer before the find. Those could be because we use ilc module. Also sequence is not part of our find - so when I run it manually I only get 3 fields. I don't think that would be it, but just wanted to mention it.

rc = stpapi.enum.answer("tdpur4121m000","tdilc41230",tcyesno.yes) | 20050509.end
rc = stpapi.enum.answer("tdpur4121m000","tdilc41231",tcyesno.yes)
stpapi.put.field("tdpur4121m000","tdpur045.reno",str$(receipt.number))
stpapi.put.field("tdpur4121m000","tdpur045.orno",str$(purchase.order))
stpapi.put.field("tdpur4121m000","tdpur045.pono",str$(purchase.pono))
rc = stpapi.find("tdpur4121m000",msg)

Hello Mark,

found the problem. Does not have anything to do with the ottstpapiserv, basically the first time is fine becasue, a library call is
before I call the FS. next time ottstpapiserv is active but in a library, there is a brp.close(brp.id) where brp.id = 0 and hangs there.
after I modified this, all goes well, even the ottstpapiserv remains active.

thank you for your help.

Never thought would have thought of that...makes me wonder if one day I might run into this because I have some code that starts in a session and then calls libraries to do other api routines. Thanks for posting the solution.

Thanks Mark,

What I don't know is if ottstpapiserv shall remains active once is called, I believe is sort of service that once is on, doesn't have to be called again till session closes. When multiple calls in same session to AFS, no need to restart ottstpapiserv every time. I just want to know if this is the case for my own understanding of this.

Thanks again,

Well I can't say for sure, but what you state sounds like how it should work.