In order to run a ba6.1 session in detached mode you need the enclosed tool maslat(d). Running a ba6.1 in the detached mode (meaning with no terminal connected to it) can be usef ul when connecting through a slow, instable dial-up line. It allows the user to perform critical operations (e.g. create data dictionary) even in such circumstances.

How to use maslat?:

a. copy the maslat and maslatd binaries in your $BSE/bin directory

b. start a maslat shell by execting the maslatd with following options:

maslatd <I/O directory> <hostname>

e.g. maslatd /tmp baanserver

This will create a set of pipes in the /tmp directory and start a new login shell. If you do not het the shell, try to use the IP address of the server instead of the hostname

c. login as the user you want to connect to the ba6.1 and start the ba6.1 session

d. activate your (critical) Baan session and press <CTRL-]> to quit the ba6.1 client. You can now save log off from the server

f. reconnect to your detached ba6.1 client by executing following command:

maslat <I/O directory>

e.g.: maslat /tmp

This will re-attach the background ba6.1 process to your current terminal. The screen will be garbled but can be refreshed pressing F6 and then selecting 'Rebuild displays'

Note:

You cannot use the sam <I/O directory> for multiple maslat shells.

Another very nice tool to use for this is the GNU screen (http://www.gnu.org/software/screen/screen.html) program . It can be built on most Unix systems -- I keep a library of just the compiled main program (not the source or man pages) built for the major platforms (Sun, HP, Digital, IBM, and Linux) on my notebook so I have a copy when working at customer sites.

The nice thing about screen is it provides multiple virtual ASCII windows that you can switch between and understands VT terminal escape codes. Due to the later you rarely have to refersh the contents of the ASCII window. All this and you can disconnect and reconnect at will.

I had written a program a long time ago that worked much like maslat (long before I started working with Baan) and had used that for years until coming across screen. Much, much nicer.

Too bad Baan has moved to a nearly exclusively GUI environment with BaanERP since these nifty utilities cannot be used.

Have fun!

Kevin Brock

Please note that maslat and maslatd are OS specific, you need different versions for e.g. HP, IBM, Digital etc.

Rgrds,

yes sorry, my previous attachment is for HP-UX environments

Hi all,

The other versions of maslat are in the attachment. Someone of Baan support has sent me these files. He searched a long time and found this.

Greetz,

Marc

The attachment did not appear. Sorry.

Have been searching my complete archive, including floppy's (yeah, still have them!), CD's and old hard disks for this! :o

Should have known better: FIRST search the board! ;)

Hmmm, learned a lesson again...

Have a problem that I've never seen before with maslat! Running on AIX 5.2, trying to start maslatd with an existing directory where I have rights (777). The program comes back with:

All named pipes in use.

Does the program need a sticky bit? Or some tuned kernel parameter? Please help!

Alternatively, is there another (free) tool available with the same functionality? Specifically for AIX 5.2, with only a normal Telnet/SSH interface, no graphics.

Nico, have a look at the UNIX 'screen' command. It can also attach/detach terminal sessions.

Thanks Patrick. Am doing that right now! (At 22:49, still at work! :( )

In order to run a ba6.1 session in detached mode you need the enclosed tool maslat(d). Running a ba6.1 in the detached mode (meaning with no terminal connected to it) can be usef ul when connecting through a slow, instable dial-up line. It allows the user to perform critical operations (e.g. create data dictionary) even in such circumstances.


I don't understand why a special program is required to run ba6.1 "detached" mode. On AIX we run some special jobs every few minutes from cron. the at command would also run jobs from the command line input but not connected to a terminal. Furthermore, Baan starts its job daemons from script also ( ba6.1 ttaad5206m000 2>${BSE_TMP}/rc.startjobdmerr & )

Terry

Hi Terry,

sure you are right, Baan uses this mechanism to start jobs and job daemons. But both do not have human interactions. With the tools above, you can start ba6.1, interact, enter some values etc,press "go" and then detach and come back some hours later. This is a nice feature, for example for long running "convert to runtime" and other activities, where you do not or can not create a job.

Regards

Markus

Markus

Thanks for the explanation. makes sense now.

Terry

Obviously there are many alternatives out there, how to achieve the same thing:

- You could install VNC on the unix server and work in X-Windows

- You could install a Remote Admin Tool (PC Duo, PC Anywhere, ...) on a windows PC and connect to this one.

- You could use windows terminal services to connect to a PC and start a terminal or GUI there.

The last two options are usefull, if you either are a GUI user or your Baan server is windows based. But the screen or maslat approach should be especially usefull for low bandwidth (ie modem) connections.

Regards

Markus

Markus, you're absolutely right, but also terribly wrong! I'm working in a pure UNIX environment most of the times, and, with customers (and governments) being as paranoid as they are, we are lucky if we get a dail-up into the UNIX machine directly. Don't even mention Remote Admin or teminal services, or they kick you out immediately! Thus, with only a direct connection to UNIX, (and no X either!), my only hope is something like maslat or screen.

By the way, anybody have a link to screen? I found two myself: one for KDE, and one where AIX 5.x is explicitly excluded!

Markus,
This is a nice feature, for example for long running "convert to runtime" and other activities, where you do not or can not create a job.
The sessions ttadv5210m000 and ttadv5215m000 can be added to the jobs. The issue is when you have any errors or table lock issues or corrupted DDs or wrong table definitions, a question or message will popup. We use it as job so that the session/job settings are always consistent for our deployment team, who start the job and watch it run.