Setting aside the question of whether it might make more sense for the initial server to talk to the secondary one (i.e. the Alpha in the example above) via a TCP connection, and also setting aside my better judgment in revealing this interface, which for better or worse, has somehowe escaped being documented, here's a trick you can use to launch a new ATE session and pass it all the parameters you want...

First, it depends on having done a regular 6.4 ATE installation, which as a side effect defined a new custom URL 'scheme' named 'ashell-ate:'. (If you don't have this piece, when you try to launch the URL, you'll get a Windows message saying you need an app, or it otherwise doesn't understand 'ashell-ate:'.)

The trick involves the fact that this new custom URL scheme understands all the ATE configuration parameter names (the same ones that appear in an exported ATE configuration). Aside from all the standard configuration parameters needed to connect to the auxiliary server (IP, name, password, etc.), you can also load up the LoginText parameter with a command line or series of them (each terminated with a "^M"). Then just launch this URL via the MX_SHELLEX function.

Here's a sample program:

Note that in the example, the "dyncfg" is the name we are assigning to the on-the-fly ATE configuration built from the parameter list. (The parameter list shown is rather minimal; you can specify all the parameters needed for your situation, just like you would in the configuration dialog.)

The configuration name must be followed by a slash, followed by a series of parameter=value pairs delimited with "&".

Note that this mechanism is also potentially very useful for launching an ATE session from a web page.

Update: it may be that the 6.4 ATE installer didn't defined the ashell-ate: scheme. I'm investigating and may need to post an updated version later tonight.

It's now in the latest 6.4 installer:

ate-6.4.1557.0-web.exe

(Or use Help > Check for Updates)

This looks good. Thanks.

In order to use this I will need to change other settings too. I need to define an ftp user and password. I want to Close the window on Disconnect without the warning - which hangs up the process so the session never ends.

If this information is somewhere in the documentation I haven't found it.

I tried changing these connection properties on a profile and saving it figuring that this call would use the existing profile settings but I think a new profile is being created each time.

Indeed it is being created anew each time. But as for the names of all the attributes...
In other words, create a configuration manually with all of the settings you want. Then use the Export button in the configuration dialog to export it to a text file. You can then display the text file to see the names of all the attributes. (You'll also see the encrypted encrypted passwords which you can use in place of the plain ones so as to not expose them to the ATE trace capability.)

That's clever. Thanks.

Here's yet another variation on the technique of creating an ATE configuration on the fly from the server and then forcing the client to open a second connection using the new configuration. It's similar to the above scheme, but doesn't actually require that the custom ashell-ate: URL scheme be predefined. But it does require TELNET.LIT 2.2(147) or higher (installed as part of ATE in %ATE%\dsk0\001004).

The technique consists of replacing the ATE configuration name with a URL-formatted string containing the name along with all the attributes, as illustrated in this example:

Note that the critical difference between this version and the one shown at the top of this thread is that instead of using MX_SHELLEX to launch URL object (ashell-ate:dyncfg/attr=value&...), we are instead using it to explicitly launch an ATE command line (made up of the command object $ATE and the parameter list -atecfg ....)

The trick here is that TELNET will accept the URL syntax in place of the normal configuration name (as the argument to the -atecfg switch). In this case, it ignores the URL scheme: (atex: in the above example). Note that the purpose of the custom scheme is to associate the URL (which might be resident on a web page out in the cloud somewhere) with the ATE app installed on the local computer, in a way that is browser compatible. (Web pages cannot contain explicit references to local executables, for obvious security reasons.) But if we are already within an ATE session, then we can launch it again explicitly via the special $ATE command macro.

The other thing to note is the need for an extra pair of single quotes around the entire string, e.g.

A couple of security-related notes:

1. If embedding the password info into the string, you should probably encrypt it so that it can't be captured by some kind of terminal logger (such as the one built into ATE!) Actually, ATE will make this easy for you since it automatically encrypts the passwords in the configuration and writes them that way when exporting, so you can just copy the encrypted string into the URL as is.

2. Both variations of the build-a-configuration-on-the-fly technique result in the specified configuration being created and stored on the local ATE workstation using the name specified (cfgname or dyncfg in the examples above). If, for whatever reason, you don't want to leave the working profile resident on the workstation after the session ends, you can modify it or remove it using a remote SBX call containing MX_REGISTRY calls. The SOSLIB contains a handy ATEREG.SBX routine in the [907033] directory that you may find useful for that kind of thing. Also see the ATEREGTST and SETATEREG programs in the same directory for examples of usage.