Hi everybody,

After strugling with all the basic things about Linux/ATE/A-Shell Linux and a lot of help from Jack and Steve (many thanks to both), by now, I'm able to run my first program under this environment but, of course, with a lot of little things to fix and improve.

The first thing I'd like to comment is about performance.
This program I tried is a problematic one that, under Windows working in single-user mode runs perfectly but, as soon as a second user access, it slows down something like 50% less.
Under Linux (and considering that's a first installation with a lot of things to fix), the same program runs without loosing performance 4 users (that's what I tried until now).

So, thank you Ken, Maurice, Frank, Steve and Denis for encouraged me to try this.

These are the good news but, now I need to start refining my installation and I'll apreciate to know from all the expertise on this environment what to do about:
- enable function keys under my program, PageUp/Down on VUE or even at the a-shell prompt (PageDown doesn't repeat the last command) well, what I know is that, a lot of things doesn't work as expected about keyboard so, I guess, something is missing there that will solve all the cases
- using AM62CG for terminal emulation, I almost get a "clean" screen but, still some little strange things appear on my program. What I'd like to know is, if there is anything more to consider about terminal emulation or these strange things could be something I must fix on my program.

And it's all for now.
Once again, thanks to all that gave me all the useful informations about A-Shell/Linux.

Regards

Well done Jorge! and after all your hard work, plenty of bed time book reading and a long weekend I bet your glad it ran as fast as we all said it would! and im sure as you say will go even quicker once a few linux servies are disabled.

So happy with the performance then?

In no Liunx expert as most of our customers are AIX, so hopefully someone else will point you in the right direction here.

I cant remember what files you need/change to get the function keys etc working under am62cg, but Jack sure remind us. Do you set the am6cg driver under unix when you login? if not try 'export TERM=am62cg' at the $ before running Ashell.

Have fun and well done!

Hi Jorge,

Nice to see that you have come over to the Linux side! Now, at least Jack will pay more attention to ATE compatibility issues as he does with straight windows!

I'm sure that you will find Linux to be a very robust, efficient, economical, super-fast alternative to windows. We have had good luck running Crt's, Zterm PC's and ATE PC's on it.
Under ATE, we are using the AM75G emulation, and I'm not aware of any special driver requirements on the Linux side.

If you can explain what sort of screen issues you are having, I might be able to give a better answer. We have had some handshake/emulation issues with Crt's, but I don't beleive that is your issue.

Just a hint to get you started, something that still gets me, linux is case-sensitive, and most commands and filenames are in lower case. So, if you are going to host a command make sure that it is in lower case.

Good Luck!

Regards,
Frank

You'll need an IFX and VUX file for either am62cg or am75g (depending on which version you prefer) in the LIB: directory. If not already there, you can copy them from the AM62C and AM75 IFX/VUX files already there.

There also has to be a LIB:AM62CG.PFK (or LIB:AM75G.PFK) on the client side. This will have been installed by ATE, but if you are just running telnet.lit from a normal A-Shell/Windows installation (like I said you could) then you may need to copy the AM*.PFK files from the [7,0] directory where ATE was installed to the one where you are actually running telnet from.

As for the "strange little things", if you think it could be related to mode vs. field emulation, try switching to am75g instead. (Change it in your ATE configuration, then restart an ATE session.) A-Shell/Windows normally acts like a "mode" terminal, but am62cg is a "field" emulation - the difference can cause some strange effects if your programs are written to assume one kind of operation vs. the other, although this would only relate to the use of field attributes such as underline and reverse video.

If that doesn't help, the next step is to capture a log file (see the Misc. page of the ATE configuration) and take a screen shot, so we can see what codes are being sent and what is being displayed.

The Master spoke and the problem solved.
Yes Jack, after copy the files as you suggested, even without exit A-Shell, the PageUp/Down as the Function keys started working, thanks.

About the strange things on the screen, after choose the AM62CG most of those things disappeared except one case where we use a reverse video on a entire line to show the position when scrolling on a list (I'm not talking about PCKLST). I'm going to look into the code to see if there is something out of place.

Of course, I tested the "agenda" and, it works 95% well, just some labels with strange characters but I think it's because something already reported before to be carefull under ATE that, obviously I didn't consider at the time.

What I noticed is, everything about display is slower than in Windows and I understand why but, I thought it wouldn't be so noticeable as it is.
By now, I don't know if it's my Linux configuration that is not yet adequate or if that's the way it is.
Obviously that, it's much fast for data processing but, in general, looks slower for the simple tasks like display a screen even if not crouded with GUI objects.

Thanks guys for the support.
Regards

Jack do you think your ATE super tweak where your going to pass any GUI controls in a 2nd channel will speed Jorges apps up, in theory it should.

First, regarding the reverse video problem, probably you coded it assuming a mode device, so you should probably use am75g rather than am62cg.
Or change the logic to work for both mode and field (although this is usually more of a problem when going from field to mode.)

Now, as for the speed of displaying screens, there is no way ATE (or any telnet) can be as fast for display as a local Windows workstation, since the ATE/telnet client has to do all of the same work, PLUS transfer the display data from the server to the client. And the transfer over the network will always be slower than just writing to video memory.

So that's the tradeoff between Windows and UNIX. The former gives you fast screen display, but relatively slow file I/O due to the network. The latter gives you fast file I/O, but slower screen I/O. The decision of which to is more important will help decide which OS to use.

That said, display speed is generally not an issue except in the case of a screen with many GUI objects. But the main delay here is not so much the sending of the object information from the server to the client, but the sending back of status. If the server can just send out a screen full of GUI commands, that would be quick. But if it has to wait for a response to each command before sending another, that is where the slowdown is.

In the case of ATE commands, whenever you use MIAMEX,119 (or AUI,"CONTROL") to create a GUI object, ATE will send back a status code and the object ID. UNLESS you set replace the STATUS parameter with "", or don't even specify the STATUS parameter. In that case, it does not send back a status, which allows the server to keep sending commands without waiting.

Unfortunately, you do need to get back the object ID if it is needed for subsequent objects which will be children to that first object. So sometimes you have to wait for the return status. But probably on average, 75% or more of the GUI objects you do not really need any return status code for. So if you go through your code and figure out how to eliminate that, it will be a big difference. You can take it one step further by creating batches (see MIAMEX,119 opcodes 8 and 9), but that requires some more effort than you may want to try just now.

A program like AGENDA is an extreme case - a personal productivity tool with a GUI intensive user interface. I don't know if we will ever be able to get "good enough" performance for that kind of program using the current model, but the improvement I'm working on will help. It isn't going to eliminate the fundamental problem though of waiting for returned object IDs. We might need to take it one step further and allow the entire screen to be created and saved locally on the workstation, rather than objects being created dynamically under the server's control.

Or, although I haven't tried this, it might actually make sense to use a combination of Samba and telnet. That is, use Samba (i.e. treat the Linux server as a Windows file server) to allow you to run GUI intensive programs like AGENDA just as you would under Windows, and use a telnet connection to run data-intensive programs directly on the server. Aside from the obvious complications, what needs to be determined is how much the server-based file I/O will be slowed down if there are Samba connections on the files it is accessing.

I'll try to get the ATE separate channel improvement done this week...