Hello,

I have a spooky problem with an afs-function for a standard session (tdilc4202m000).

For background information:
We would like to optimize our "sales/delivery-process" and therefore I have to automate some baan-standard sessions, so that they will be executed one after another (in an own session).

It should work as follows:
1) create outbound data for one or some position(s) of a sales order (tdilc4201m000)
2) create picking list (not the baan-standard; it is an own development, that only saves the picking number in the field "tdsls045.pino")
3) release outbound data for the combination sales order (orno) / picking list (pino) (tdilc4202m000)
4) deliver cost items with Session tdsls4120m000
5) create delivery note for the combination sales order (orno) / picking list (pino) (tdsls4403m000)
6) create invoice for sales order (tdsls4404m000)

This six steps/sessions should be handled complete by AFS. All works fine, except the AFS-call of the session tdilc4202m000 (release outbound data). In some cases the session only returns the error "no data found for report, no report is printed (message code: tccoms0024)", although the session got the right values and the tdilc401 has "unreleased records" for the corresponding order position. Executing the session manually with the same values works without an error ...

Code for the AFS-function of tdilc4202m000:

function extern tdlubilc401.release.outbound.data.for.pino(domain tcmcs.st12 runnumber,
domain tcorno orno,
domain tcpino pino,
domain tcyesno deliver.costitem,
domain tilub.devc device,
ref domain tcmcs.str14 msg.code,
ref domain tcmcs.str215 error.msg)
{
DLLUSAGE
Function to release outbound data (sls)
ENDDLLUSAGE

sessioncode = "tdilc4202m000"

if deliver.costitem = empty then
deliver.costitem = tcyesno.no
endif

stpapi.put.field(sessioncode, "runnumber.f", str$(runnumber))
stpapi.put.field(sessioncode, "runnumber.t", str$(runnumber))
stpapi.put.field(sessioncode, "koor.f", str$(tdilc.koob.act.sls))
stpapi.put.field(sessioncode, "koor.t", str$(tdilc.koob.act.sls))
stpapi.put.field(sessioncode, "cuno.f", "")
stpapi.put.field(sessioncode, "cuno.t", "ZZZZZZ")
stpapi.put.field(sessioncode, "orno.f", str$(orno))
stpapi.put.field(sessioncode, "orno.t", str$(orno))
stpapi.put.field(sessioncode, "pino.f", str$(pino))
stpapi.put.field(sessioncode, "pino.t", str$(pino))
stpapi.put.field(sessioncode, "opno.f", "0")
stpapi.put.field(sessioncode, "opno.t", "999")
stpapi.put.field(sessioncode, "prdt.f", "")
stpapi.put.field(sessioncode, "prdt.t", str$(date.num()+500))
stpapi.put.field(sessioncode, "ddat.f", str$(date.num()-500))
stpapi.put.field(sessioncode, "ddat.t", str$(date.num()+500))
stpapi.put.field(sessioncode, "cprj.f", "")
stpapi.put.field(sessioncode, "cprj.t", "ZZZZZZ")
stpapi.put.field(sessioncode, "item.f", "")
stpapi.put.field(sessioncode, "item.t", "ZZZZZZZZZZZZZZZZ")
stpapi.put.field(sessioncode, "cntr.f", "")
stpapi.put.field(sessioncode, "cntr.t", "ZZZ")
stpapi.put.field(sessioncode, "cwar.f", "")
stpapi.put.field(sessioncode, "cwar.t", "ZZZ")
stpapi.put.field(sessioncode, "crte.f", "")
stpapi.put.field(sessioncode, "crte.t", "ZZZZZ")
stpapi.put.field(sessioncode, "deliver.costitem", str$(etol(deliver.costitem)))
stpapi.put.field(sessioncode, "prnt.error.report", str$(etol(tcyesno.no)))
stpapi.set.report(sessioncode, "rtdilc420201000", device, error.msg)
if isspace(error.msg) then
stpapi.continue.process(sessioncode, error.msg)
msg.code = stpapi.get.mess.code(sessioncode, error.msg)
else
msg.code = stpapi.get.mess.code(sessioncode, error.msg)
endif
stpapi.end.session(sessioncode)
}


Hint: The function will be only executed when the corresponding outbound data is not yet released. (query of tdilc401.proc)

Unfortunately I have no explanation for this "error" as it seems to me that there is no error. According to a created logfile (afs.log) the session will be called correctly, but inexplicably returns the mentioned error, although there is data for continuing.

I hope I haven't violated rules (in my first post) and someone can help me.

Thanks for your time in advance.

Regards,
Dennis Koester

P.S. Our baan-system is baan4 c4 on hp-ux 11i v3 (B.11.31)

Have you confirmed the fields? I did not see anything right off the top that is incorrect. Can you duplicate the problem? If so try this - run the release code a second time. I am wondering if you are running these routines one after another and in some cases the previous routine, which I assume generates the outbound, might not have completed in the background. I have had to use suspend before to slow things up a little. Not sure this is the case.

Good morning mark,

thanks for the fast reply.

Yes I've confirmed the field values by debugging the scripts and logging the afs-function (command "-set AFSLOG=1" in the bw configuration) with checking the created file for a wrong given value. Could not find anything conspicuous ...

Interestingly the error occurs irregular that means that I had for example different situations:

1) 1 process*: ok
2) 1 process: error
3) 2 processes: first ok, second error (and vice versa)
4) 3 processes: first ok, second and third error (and different constellation)
*process: a try to release outbound data for the combination orno/pino

Your idea to use the suspend command to "slow down the script" sounds not bad. It's still worth a try. :) I'm even pretty sure that I didn't get an error when I debugged the whole background session including the afs-library ... and that would confirm your assumption.

The automation of the session for generating outbound data (tdilc4201m000) didn't return any errors till now, so that the tdilc401 is always filled correctly.

Unfortunately I forgot to mention that the AFS-functions for "generating outbound data" and "creating a picking list" (which based on the created outbound data!) is called at a different time. We need this data for a transfer in an "external picking-system" where the data will be processed and returned to baan. That only for background. ;)

I've already changed the printer and reset the user defaults ("ttstpdeldeflt" for root-account, which starts our background-jobs) too, just to exclude it.

Greetings,
Dennis

I forgot about user defaults - one of the reasons I always try to make sure I put all the fields. On our system we do generate and release back to back in a batch job - this is all production orders. I know at one point in time a couple of our AFS routines would error out after processing x number of records - x varied. When that happened we would just restart them where they left off(this was by hand not in batch). The issue slowly went away as we applied SP's.

Last week I have experienced that user-defaults will be queried/used although all form fields were filled with values, i.e. I wanted to generate an invoice (with AFS), but got the error that "the invoice date is not correct" (or s.th. like that), cause I saved an old date from 2009. No idea why, but after deleting the user-defaults for this session, it worked. :)

For our production we developed a session a long time ago, where an user can create or release outbound data for one entered production order by using a button. That works till now without any problems and the call/use of AFS is nearly the same, the only difference is just the order type and of course the runnumber. But the runnumber is only for further information or filtering isn't it?

Because of the effect that even one automatic release-try (in the background-job) can return an error, it might be not very easy to create a workaround so that the process won't be interrupted by an error. By the way in a second (equal) baan-system (for "testing", devolpment) the background session throws no errors. Perhaps I should mention it too. :rolleyes:

What do you mean with "applied SP's"?

Last week I have experienced that user-defaults will be queried/used although all form fields were filled with values, i.e. I wanted to generate an invoice (with AFS), but got the error that "the invoice date is not correct" (or s.th. like that), cause I saved an old date from 2009. No idea why, but after deleting the user-defaults for this session, it worked. :)

I hate saving defaults in some cases. I have turned this option off on a few sessions.


That works till now without any problems and the call/use of AFS is nearly the same, the only difference is just the order type and of course the runnumber. But the runnumber is only for further information or filtering isn't it?

The order type could be activating something in the code that is throwing the error. I don't see how it could be runnumber.


Because of the effect that even one automatic release-try (in the background-job) can return an error, it might be not very easy to create a workaround so that the process won't be interrupted by an error. By the way in a second (equal) baan-system (for "testing", devolpment) the background session throws no errors. Perhaps I should mention it too. :rolleyes:

What do you mean with "applied SP's"?
It means service packs - this problem occured on an early service pack. We are now on something like Service pack 28(I think) and the issue is gone. What this tells me (1 system works and 1 does not) is that they are not equal somewhere. It could be porting set, STPAPI libraries, service pack release or even a 1 off patch on the session. The first this I would check is the session if possible. Then I would get the latest stpapi patches or libraries available. And yes even the porting set might need to updated to fix the problem.

hello mark,

sry for the late feedback, i'm very stressed with different Problems at the moment.

The order type could be activating something in the code that is throwing the error. I don't see how it could be runnumber.

I'll try to check it. But in theory every AFS call (for the same combination orno/pino), which throws once an error should throw an error again or? On Wednesday I implemented your proposal with the "suspend-command" (with 1000 ms) and then the background job could released two picking lists without problems. I already thought that your suggestion was the solution but yesterday I got the same error again ...
As an workaround I created a Session where a user can choose one picking list (which got an afs error) and start another try. In the session I use the same afs call of course. It worked. :rolleyes:

It means service packs - this problem occured on an early service pack. We are now on something like Service pack 28(I think) and the issue is gone. What this tells me (1 system works and 1 does not) is that they are not equal somewhere. It could be porting set, STPAPI libraries, service pack release or even a 1 off patch on the session. The first this I would check is the session if possible. Then I would get the latest stpapi patches or libraries available. And yes even the porting set might need to updated to fix the problem.

I have talked about the situation with our system administrator, cause I'm "only the" developer. :) Currently sp22 is installed and because of no critical problems, which would "justify" a newer SP, we didn't touch the system since the end of 2007. Due to the fact that the second system, our test-system, is a restore of the live-system they are technically identical except some new developments. Both system have the porting set 6.1c.09 (one with PA.3846, the other with PA.3847 because of different hardware) installed. Therefore the stpapi libraries must be equal too. But on the other hand something must be different what explains that the error only occur in the live-system. What about permissions? The background job will be executed by a root user (system-user: bsp).

greetings,
Dennis

edit: I forgot to mention that I've checked the session tdilc4202m000 with the session "ttstpsessinfo". At first glance I saw no difference.

Well you would think the same record would error out, but like I mentioned that one problem we had would process a random number of records before the error would show up. I always thought it was something in the background that was not getting cleaned up correctly. One of the reasons I almost always start and end a session for each record.

Yes - system admins. :) Yes - it could be permissions, but I just can't imagine where. I mean one works and then the next doesn't. It seems to me it could be system related, but I have no clue as to where. Just too weird and I can't think anything to true.

ok, if I understand you correctly you recommend to change the script/session, so that only one record will be found and processed. After that the session should be closed and then I've to start the session again to find the next record. Right?

greetings
Dennis

ok, if I understand you correctly you recommend to change the script/session, so that only one record will be found and processed. After that the session should be closed and then I've to start the session again to find the next record. Right?

greetings
Dennis

It is just something I do. So if I have a file with 200 parts to transfer from one bin to another. I open inventory session, transfer part, close inventory session, get next part - start again. This does add overhead, but my own opinion is that it makes it cleaner(nothing floating around in the background that might confuse things). So for out bound they can only process one order at a time in my session - so basically they enter the order, then it generate, then it releases. And I always close all the sessions after they run. I have just followed this from early on - it helped when doing inventory adjustments on(we have to add pegging data) our A&D system. That was the killer that would abort with some generic error - by closing things it seemed to process more records before this abort.

I can only think of a couple places where I process more records leaving sessions open. I know 2 of them are delete grp purchase and grp production orders. Those sessions might process 10 or 1000 records before one errors out. These sessions only IT people run. We have to cleanup orders every so often(once a quarter) or GRP starts taking days to run.

Come to think of it I have had somethings work in dev/test and not in production. Including AFS code - usually I debugged them in production and the new code worked in test. ANother aggrevating error still occurs(as far as I know) - in dev/test I can take a double and say "if x>0 then". It works there, but move the code to production and it will not work consistently. We had several programs fail in production that were running okay for years. And of course - nobody did anything to cause this. I had to change several programs use double.cmp() to get them working again.

hey mark,

It is just something I do. So if I have a file with 200 parts to transfer from one bin to another. I open inventory session, transfer part, close inventory session, get next part - start again. This does add overhead, but my own opinion is that it makes it cleaner(nothing floating around in the background that might confuse things). So for out bound they can only process one order at a time in my session - so basically they enter the order, then it generate, then it releases. And I always close all the sessions after they run. I have just followed this from early on - it helped when doing inventory adjustments on(we have to add pegging data) our A&D system. That was the killer that would abort with some generic error - by closing things it seemed to process more records before this abort.
Your approach sounds logical and sensible. I prefer the same way but I always thought that the first call of
stpapi.put.field(sessioncode, sessionfield, value)
and the call (at the end of AFS) of
stpapi.end.session(sessioncode)
would exactly do what you mentioned:

open session
fill the fields with data
press button(s)
close the session

and that for each case, just as I would use the session manually. But for testing I have changed the script, so that only one picking list will be processed in the whole session. To handle more than one list, I've edited the background job and insert some copies of the session. The result should be rather the same ... but unfortunately not. I still got an error.

Before I tried it again, I looked for equal calls to release outbound for production orders in other (and older) scripts. I found s.th. I can not explain, but it works:
stpapi.put.field(sessioncode, "runnumber", str$(runnumber))
The field doesn't exist, only "runnumber.f" and "runnumber.t" ... The session is scary.

Come to think of it I have had somethings work in dev/test and not in production. Including AFS code - usually I debugged them in production and the new code worked in test. ANother aggrevating error still occurs(as far as I know) - in dev/test I can take a double and say "if x>0 then". It works there, but move the code to production and it will not work consistently. We had several programs fail in production that were running okay for years. And of course - nobody did anything to cause this. I had to change several programs use double.cmp() to get them working again.
Very interesting hint. Fortunately I was not confronted with such a situation till now, and I really hope that not "s.th. stupid" is the cause for the irregular errors.

Actual I put my hope on Infor respectively the support-case our external support has opened. I'll get slowly crazy with the situation. :(

greetings
Dennis

Glad you found the solution. I believe if you search around you will see some boi.call variables that have to be set for some sessions to work. This process can be tough to figure out solutions.