We had a situation where a coder change the print outbound session, then went on family leave. We did not change the script, but the report. This was done about 6-8 weeks ago and I made a few other changes two-three weeks ago. The users were complaining that all of a sudden when they entered a production order range, all outbound would be printed (or in the other case released). So naturally our coding was causing the problem. I requested screen prints and other documentation, but never got any.

Today the complaint was resolved. It just so happened that one our function Baan experts was out in inventory area when it happened today. She made some screen prints to take back an look at them. The problem - the user was putting the production order range into the customer range. And filling everything else wide open(we do not have defaults available). So the solution I was to implement was to take customer number range off the forms - we do not need it. My first question was how will they make them fill things out correctly???

I have others, but this one was most recent.

Mark

I had one user working the night shift who could not get the shipping log for a particularly customer to print correctly.

I eventually tracked him down during daylight hours and watched him run the report. After a few attempts I was also mystified until on the third I watched his hands on the keyboard only to find out that he was typing "Mo13" as opposed to "M013" in the customer field.

He swore almost as loudly as I did when I told him what he was doing wrong.

Once a user from shop floor complained that his production batch was missing in the system. He said he was not able to locate it. I asked him to use the find button and search for production batch number. But he said it is not coming in his sytem.

I went all the way to his place and found that Num Lock was not on.

Heard from one of our consultants: by mistake they left a particular session in debug mode after the implementation live date. They were stunned to return after 6 months and found the user saying: "oh sure, that is not a problem, it is just how this session works; when I press 'continue' this black window opens, I have to type <c><enter> and then it works"

R.

I once had a complaint from a user that something went wrong during the invoice run. I asked here if I could reproduce the problem. That was possible, but only on fridays: that's when she did the invoice run.
So, the next friday I called her again and asked her if she was ready to test the invoice run. I guided her through all the steps to make a mirror of her screen on my terminal via a modem setup. This costed almost 20 minutes. Now I could see what she was typing and follow the response of the system. So right before the great moment was there, I said to her: "now you have to do what you always do during an invoice run and I will watch and see what you are doing".
Then I heard "boink" (she laid down the receiver) and the next 15 minutes: nothing happened. I got no response from the telephone and nothing happened on my mirrored screen.
After 15 minutes she picked up the phone and said: "this time it was OK".
I was puzzled. I said to her that I hadn't seen anything on the screen and asked her what she had done. Her answer was both simple and stunning: " I did what you asked me to do: do as always. I went to the other terminal (not the one that was mirrored) and started the process ............"
You know, I really had some difficulty to suppress my laughter. I put my hand on the receiver and it took me some time before I was able to speak again.
The next week, we found the simple problem.

This was my contribution, let me hear yours.

Regards,
Jaap Zwaan

Hey Jaap, what a patience! I would've dumped the receiver back after 5 minutes!

My worst was a new implementation of a customization, where we told the user to wait till all other users were off the system. So it was scheduled to Friday night, around 21:00. All batch processes were rescheduled, and everything looked fine. At 21:30 I got the first call: there was still a user in Baan, reported by the licence daemon. And there was a bshell. Thus I told them to issue the bshcmd command. At 22:00 another call. Still no luck! And they were getting agitated! At 22:30 a call from my manager: they had escalated the case. I had to go there immediately. Thus, after driving there (took me an hour and a half) I had a look at the system. The logged in bshell was the user's own, the one to be used to import the solution!

One of our new friend stop Baan Service by mistake

what happened was administrator was not on his seat & a user rang up to kill his licence from server. There was another friend who uses Red Hat linux so frequently, received the phone & tries to kill the login..

Instead of typing bshcmd -e ?????? he type kill -9 ??????. (Here ?????? is the process no). Kill -9 command is used to kill processes in Linux server.

All of a sudden BaaN services stopped, but fortunately all users keep on running. We have to start services again..

This may be the way baan users can be increased without buying licences from BaaN..... GOD knows previous users will enter data through dummy licences....

:D :D :D Great, I love this thread!

Greetz
Thomas

Not directly related to Baan but here's another cool one:

Someone trying to check whether an automatic reboot is scheduled through UNIX cron:

# crontab -l | shutdown

instead of:

# crontab -l | grep shutdown

You can imagine the result :D

Good one Pat, how about "kill -9 0" Hey why did the lights turn off?

Regards,
Rupert

Not directly user related, but user group related:

In South Africa we did not have a section of the Baan World Users, but we had our own version, namely the Triton User Group.

Now, since this is always abbreviated, we called it the TUG. But then, in 1996 (?) the new release was called BaanIV. This posed a difficulty to the user group: should they change the name? It would become the Baan User Group, which abbreviated to ...

So yes, we implemented "SESSION_TIMEOUT" on our production server. So our users got used to being kicked out of baan every once in a while, they could handle that. Easy click the window and reconnect.

So when the server failed serious memory problems, causing bshells to be aborted and coredumped, noone was keen enough to notify the sysadmin...

... except for the one on the financial department with session_timeout:0 in the user file...

Good posts and loved the stories. Glad to see I am not the only one with difficult users.

And Pat made me think of a trainer we had for tools training. He was discussing the kill command and said - "Never do this". He typed in the command to kill the license daemon and hit return by habit. Right after the return - all he could say was - Ooops. It was great.


Mark

Turn about is fair play, so here is a user story about IT support. We had an operator accidently kill a regular nightly job and re-start it again under a different user, instead of the user assigned to the job. Monitoring the job under the user it was supposed to be they didn't see the job getting any time so they killed it again and called the application support. Not knowing that the operator had killed the job, Application support went into the job and started it in the next step to get at least what had processed to this point in the outbound to feed to the warehouse managment system. When I got in the next morning the warehouse manger was screaming in my office because where they normally got 2000 lines to pick they got 400. I called IT and asked them what they were doing to fix the isseue from the night before and suggested that we run the job to make sure it would run correctly so that we wouldn't have the same issue again the next day. The programer started the job again and was seeing no output, stop the job to try and fix it. The reason he was seeing no output was because he didn't understand the process that he was running, but we will get back to that). He went in and made a change and started again and was getting output so they stopped the job thinking it would run on schedule that night. Operations we left instructions to not cancel the job as long as it was getting time. Now the job normally runs in 1.5 hours. So I come in the next morning again to a screaming manager because this time there is no work and 40 people standing around doing nothing. Of course the warehouse starts at 6:00 and IT starts at 8:00. I call operations and my key support and have them stop the job that has now been running for 12 hours ( but we didn't kill or call anyone because it was still getting time) and had them start the job at the next step, so we could get work to the warehouse. After a meeting with the manager of operations and her key people we finally find out that the only reason the job went bad is because it was accidently killed, started wrong, killed because of that. because of that we screwed up the job by playing with the program going from 1.5 hours to never finishing. In the middle of this we had another programer look at the job and made a selection change which made the job run in 12 minutes.

So on behalf of the users, we aren't the only nitwits on the system, we have our share of programers, analyst, and managers in IT to keep pace with us.

Seriously though, for those of you who are in IT, you should show this site to your users to get them more involved. You would be amazed what a good user can do to help IT. We have 3-4 key users that understand the functionality of the system better than anyone in IT and our IT loves it. We make their life much easier by being able to tell them that the systems is supposed to do this and that it is supposed to write to that table. The combination or or functional ability and there programming ability has made us able to get the most out of the system and made the migrations for Triton to B4b to B5b and soon to B5c much smoother.

If your IT and going to the Baan Conference bring a user or two it will be to your advantage. The more they know the better they can help you.

My favorite story comes from a customer (right Mark?).

Someone in IT ordered supplies through Baan. They need Qtips to clean some item. So, they went into Baan and ordered three boxes of Qtips. Unfortunately, they used the wrong unit of measure and received three BOXCARS of Qtips. This customer had people calling them from all over -- hospitals, etc -- as they had cornered the market on Qtips in the Eastern US.

So, make sure to check the UM...

-- Jim

The one I like the most is when users call screaming because someone is locking a certain Sales order. Usually it's the user calling that in the middle of 10 baan windows as that order open.
When this happens I quickly broadcast a message to the user saying: "Sales order xxxxxx is open by you." Most of the times I can only see users say Opps! but some get pissed off and just hang up. ;)

Another typical. A particular User Generates Outbounds for every order. After 5 minutes we get phone calls from all over the place (finance, logistics, shop floor) saying they can't generate outbound. Hopefully the user never released the whole thing. When we call him he always says the problem is with Baan because he is sure he did everything the right way.

You will be amazed how many times still users call our IT department because they try to print something in BaaN, nothing comes out, either because of a program error or just 'No Data Within Selection', and they mention "I've already tried to reboot my pc, but it didn't solve it...."


R.

Mike your story triggered a memory... It was a dark and stormy night when one of my fellow programmers decided to add a new field to 'gld106 (finalized transactions) and for good measure he thought it would be a good idea to add an index by this new field of course allowing duplicates on this new key was never considered [I can already here all the DBA's out there shout NOOOOOOO......] and the convert to runtime was scheduled for the wee hours of the morning... Of course the DBA was hugely impressed by the transaction compression on this table... overnight 10 million rows became 1 row! (she promptly asked the programmer to look at all the other tables too - lol)

... be careful when adding indices!

Regards,
Rupert

Jim V - sorry if I mis-led you in class it was in our pre-Baan days that our IT manager cornered the market on qtips. :) But it was still a UOM conversion problem.

Mike - you are correct also, but being an IT person I usually refrain from telling stories on our department. About 2-3 years prior to Baan, our coders routinely crashed our HP3000 system. Being the system admin I had to fight to take away permissions, nothing more troubling than having to explain that to a user. I will have to think about my worst one. :)

Mark

There is this guy from Support... working on one of his first NT cases... working with PC-Nowhere over a 14k4 telephone line. There was some delay in the response, he was not used to. So he clicked some to make the %BSE%\bin dir his current dir.

Then the sysadmin on the other side of the telephone line: Hey, something odd seems to have happened... I cannot start this session... It took only some minutes for the users to find out too. The system was not able to start any session from within Baan.

It took some 10 minutes to discover the error. %BSE%\tmp\application instead of %BSE%\application...

By the way: I use the DOS prompt on slow links nowadays...

:mad:
Well, this was really embarassing;
one of our functional staff thought he was good in Unix and promptly did

chown bsp:bsp *.*

unfortunately, he was in root directory and he had logged-in as root.....

Fox,

I have to reply to that one that I did that kind of mistake. I have the root access.

I have my own login with my preferred settings, bin, shell scripts etc.

Once I was logged in as myself then sudo to root and after a while I forgot I was root and then I set my enviornment and executed my personal environment settings.


$ cat m
chmod 755 *
chmod 755 $HOME/.exrc
chmod 755 $HOME/.rhosts
chmod 755 $HOME/bin
chmod 755 $HOME/.profile
chmod 755 $HOME/.sh_history
chmod 700 $HOME/bin/*
chown -R nprao:bsp *
$


Guess what everyone complained that their processes stopped, no one can print in baan or write to their home directories. Obviously, I was caught RED-HANDED with my name on every thing.

Now I use hard coded path, than $HOME which is '/" when I sudo to the root.

Another interesting experience, was when I was making the shell script which misfired into a process chain reaction. Guess what the shell script is ?

Sending broadcast message in GUI (http://www.baanboard.com/baanboard/showthread.php?s=&threadid=5634&highlight=grep)

As I mentioned in the posting -

for i in `ps -ef | grep bshell_abcd | grep -v "grep bshell_abcd"|awk '{print $2}' `
# add another grep before awk if based on user id

That was really a bad experience with a silly mistake in a Unix shell script which broke the process limits set(500) for our Unix box.

Well, I never wanted to try to break the BaaN process limits. If you want to do something like that in BaaN tool, just write a 3-GL code in an infinite loop, starting up another session or 3-GL code.

I would not advise you to do that and get into trouble :D

You cant open a ksh or telnet session when your process-limit breaker program starts that you can monitor the process list. You need to open another session, as other user, preferably as a root or with sudo access so that you can kill the processes and get the system back to the normal speed.

you might find these error codes if you try to access ksh/telnet/baan when that program is executing -

9 EBADF Bad file number This indicates either that a file descriptor does not refer to an open file, or that a write request has been made to a file that is opened only for reading, or that a read request has been made to a file that is opened only for writing

11 EAGAIN No more processes This indicates that a fork has failed, either because the system's process table is full or because the user is not allowed to create any more processes.

12 ENOMEM Not enough space This occurs during an exec or sbrk, when a program asks for more space than the system is able to supply. This is not a temporary condition. The maximum space size is a system parameter. This error can also occur when the arrangement of text, data, and stack segments requires too many segmentation registers, or if there is not enough swap space during a fork.

oh well...!!! no one is perfect :)

One day, mine CE shouting to my HOD - "In the last month we have purchased new UPS and still viruses are coming, Why?" :D

-Suhas