wricks
9th November 2004, 17:07
Hello all,
I am trying to set up the Session Startup and/or Key map settings. I have created the groups and added the sessions.
I used ttaad2105m000 Maintain User Settings to assign them to the user.
But when I log in as that user nothing happens. I do run Convert to Runtime
I am not sure what I am missing. :confused:
Thanks for your help.
Steve
dave_23
9th November 2004, 17:17
Those do not work if your bshell isn't called "bshell".
So if you modified your ipc_info to do a bshell script, that would probably
be the problem..
Dave
wricks
9th November 2004, 17:24
That makes sense we have modified our Bshell because of Vertex.
dave_23
9th November 2004, 17:46
yeah, so you probably call it "bshelltax" or something.
Kind of a weird limitation though.
Dave
NPRao
9th November 2004, 20:10
Steve,
I am not sure in your BaaN version. I had similar issue and there was a fix in the porting sets.
Here is my case info-
SITUATION IDENTIFIED IN:
Startup Sessions
ATTACHMENTS:
SITUATION DESCRIPTION:
Startup session groups not working
SOLUTION DESCRIPTION:
1 Make sure "Session Groups" option is checked when "convert changes to Runtime DD" for the user datra.
2 Get the latest portingset (sol. 134945). It has the fix for the Startup session defect.
3 Please note that, Startup sessions usually only work when the Bshell Name is "bshell" in the BW configuration. If you use something else, here are 2 workarounds:
When doing a conversion to runtime the following entry is created in the userfile by the 4GL (Tools):
bshell.sessions:<name of the session file>
so, the Bshell name has to be "bshell". If not, the startup sessions are not executed.
The idea behind this is, that normal users have Bshell name "bshell". And administrative users might have another bshell name, and don't want to have the startup sessions.
Further it seemed to be a problem for the 4GL to retreive the Bshell name.
The workarounds if they use something other than bshell in their BW is:
==================================================
workaround 1.:
Suppose the Bshell name is bshell_corelli;
1. Create a file $BSE/lib/defaults/bshell_corelli
2. Put the following line in this file:
bshell_corelli.sessions:sta_sessions
3. Create a file $BSE/lib/user/sta_sessions
4. Put the sessioncodes of the startup sessions in this file, eg.:
ttaad2100m000
ttaad2500m000
workaround 2.:
Another workaround is (but this one has to be applied per Baan user):
After creating a Session Group, Assigning Startup Sessions to this group, and linking this Group to a Baan user + Convert to Runtime,
the following entry is created in the file $BSE/lib/user/u<baan user>:
e.g.:
bshell.sessions:sta_sessions
Now modify this line to:
bshell_corelli.sessions:sta_sessions
SITUATION IDENTIFIED IN:
Startup Sessions
ATTACHMENTS:
SITUATION DESCRIPTION:
Startup session groups not working
SOLUTION DESCRIPTION:
1 Make sure "Session Groups" option is checked when "convert changes to Runtime DD" for the user datra.
2 Get the latest portingset (sol. 134945). It has the fix for the Startup session defect.
3 Please note that, Startup sessions usually only work when the Bshell Name is "bshell" in the BW configuration. If you use something else, here are 2 workarounds:
When doing a conversion to runtime the following entry is created in the userfile by the 4GL (Tools):
bshell.sessions:<name of the session file>
so, the Bshell name has to be "bshell". If not, the startup sessions are not executed.
The idea behind this is, that normal users have Bshell name "bshell". And administrative users might have another bshell name, and don't want to have the startup sessions.
Further it seemed to be a problem for the 4GL to retreive the Bshell name.
wricks
9th November 2004, 20:55
I tried some of your workarounds but they do not seem to help me. We are on Baan IV c4. I even tried renaming my Bshell back to standard just for me but it still does not work. Maybe I need a new porting set.
:confused:
Hitesh Shah
10th November 2004, 14:20
Did u convert to runtime . Are k / sessions file in $BSE/lib/user created.
shaboo
10th December 2004, 21:26
Read Solution # 166397
I was able to to startup the session using workaround #1 in the above mentioned solution
Markus Schmitz
13th December 2004, 13:55
Hi,
some time ago, we had the same problem.
If I remember correctly, we created a link from bshell to bshell6.1 and in the bshell wrapper we call this link instead of the baan binary directly.
Strange, but it worked!
Kingsto88
27th November 2006, 08:48
Hi,
I dont think it is the portingset problem. Or is it???
My situation is I could not get the startup session working when using bw client 077. But another computer on bw client 062 could get the startup session to work. So the portingset is the same at that point of time. So it seems that the portingset is not the cause of the problem.
Is there a solution to ensure that my new bw client 077 activate the startup session too? I wish to use the new client and also the session startup.
thanks n regards,