We are facing a problems when trying to print reports in our ERP LN 6.1 Installation.

When trying to print a report hangs and couldn´t print it. No error messages are displayed and users must to kill a session in order to get back control.
This problem occurs randomly(lately very often!!)

I thought could it be tmp directory's issue , but verified and tmp's size is only 1 GB and about 35 Gb of free space on server's hard disk.

Also thought could it be permissions or quota disk problem, but verified and everything looks fine and even when we tried to print logged as user baan(also local server administrator who has full control in tmp directory) got same the results.

The same problem occurs trying to print in all device types (Local Printer, ASCII Files, Notepad, etc.), sometimes when 2 or more users prints to notepad, the records from both reports are "mixed" into one single file.

Our environment:

S.O. Windows 2003
Database SQL Server 2005
ERP LN 6.1
Portingset 8.4.1

Any Clue or something had experienced same problem before?

Thanks in advance and sorry about my poor English

do you, by chance, have your tools company in a separate database?
and maybe that database's transaction log is full?

set this in your bw.confg and print something
-- -set DBSLOG=01570

then look at the dbs.log that's generated in $BSE/tmp

see if it's hanging on an execute of a query.

Dave

Dave , no, i have all companies in a single databas but i didnt check out transaction log. I will do that you suggested.

Thanks in advance

could be table specific then, dbslog will tell if you can't insert into the device history table.

otherwise it may just be something goofy in 'doze which would be solved by the traditional "reboot" =)

Dave

Could it be, don´t forget after all , Its Windows :)!!!, and 99% percent of those errors could be solved with just rebooting. Anyway , i have to wait tomorrow to perform both tasks(tracing or/and rebooting). i will tell you then what happened.

Thanks

Maybe stupid, but... check your disk space. I've seen a case, where even "select device" screen did not show up when disk space was low. They had a batch to remove tmp files at reboot, so after reboot printing was fine, but after several hours problem was always back :).

Sorry for not having read your first post attentively enough. You have checked it already.

Greg, i thought the same in fisrt place , but checked and there are 35 GB free in hard disk, also delete all tmp files in $BSE/tmp and the problems still remains

Additionally, I've found all those non-printed reports are in premature status in ttaad3521m000.

Also generated dbs.log

For which table should i look in dbs.log file?.
Could it be usefull if i attach (compressed) file?

yeah, just attach it, explaining what to look for isn't very easy =)

Dave

Dave , here is the file. Please watch out , unzipped size is about 17 Mb.

Thanks

Sorry - I forgot to tell you to save off the dbs.log before you killed your session (i.e., so the last thing in there was the hang.)

that makes interpreting it a little difficult.

The last thing it did was:
SQL> DELETE FROM dbo.tttadv997000 WHERE dbo.tttadv997000.t_applid=?

this would be the record it's trying to delete:
----- DBMS Output Row ----
Bind 1 : applid : long : 0xf83258 : 4 : <1488>
Bind 2 : user : string : 0xf8325c : 8 : 'mceriott\0\0\0\0'
Bind 3 : term : string : 0xf83269 : 4 : 'CON:\0\0\0\0'
Bind 4 : Refcntd : long : 0xf83274 : 4 : <0>
Bind 5 : Refcntu : long : 0xf83278 : 4 : <0>

But it makes it to a commit

<7488> mceriott [1]--------- D_COMMIT on session ------------

>>msql_exec_session id: 1, com_code: 1 COMMIT conn id 22551072 done msql_exec_session done...<


and then from there it starts detaching and rolling back transactions (so that must be where you killed it).

That doesn't seem like a "hang" situation to me. I suspect that the problem is outside of the database.

Dave

Dave , a few minutes after i sent you dbs file, The server was rebooted . So far now, no problems were reported but i don't really have a good feel about this "hard-reset" solution. I suspect could be a latency problem a couple of days ago and users ended their sessions using (CTRL-ALT-DEL) method :). Since there are about 200 users and server didn´t reboot this action could cause an overload in server's performance (i just guessing).

Also, a couple of minutes ago an user gaves me an error message refering sorterror -128, from print session. I know about sorterror -1 , -11, or -6 but not about -128(i guess could it be adition of several errors). Thats indicates me an error over $BSE/tmp could it be happens.

Now i will try to catch if new hanging errors will be reported and then i let you know.

Thank You very much for your help

As i suspected before, problems happened again. This time sessions could not open ttstpsplopen.

so still revolving around reporting.

so sort file issues and problems with reporting. sounds like $BSE/tmp is messed up.

set

-- -set BSE_TMP=/some/other/directory in your BW and see if you can open up a report.

you might have too many tmp* files in $BSE/tmp or the directory might be hozed at the OS level.

Dave

good one !. I will try that you suggested

If there are several problems with this directory, but everytime it is a writing action,
it sounds like a hardware failure to me.
If one or more harddisks are defect, you will be getting more and more write errors and, in worst case,
get an inconsistent system.

So please check out the syslog or other logfiles and watch for errors there.

Dave , tried that you suggested but problems continues. We did the following

1) Create another tmp , called tmp1 in $BSE directory.
2) In BSE Client configuration(for only one test user set up as server´s local administrator) put -- -set BSE_TMP=<BSE Directory>\tmp1
3) User tried to finalize integration transactions via tfgld1519m000 but again session hangs.

I dont know if its really usefull, but i attach a log for this session.

Another thing i discovered , there are no ttstp, ttdsk nor ttdll objects set up in shared memory. Could it help if we put those objects in shm?

that seems to say that the process crashed in ottgbfprocess.

you could try running with

-- -dbgobj -dbgfun -dbgflow -keeplog -logfile c:\functions.txt

save the file off before you kill the session (i.e., while it's hanging).

I'm running out of ideas though, you might want to get support involved if you haven't already.

Dave

well, support is involved since yesterday evening. They make us to install a bunch of tools solutions. But..nothing..

Dont worry , you have been a lot of help to us.

Regards

Ok, good that support is involved because the next step involves getting a debug object from them =)

(for whatever object the debugging output shows you're hanging on)

Dave

We got our printing problems solved. Infor support people were involved and they installed about 60 solutions. Until now , no new printing problems were reported. I´ll try to get al solution´s numbers installed and posts here

Thanks you very much for all your help, guys