One of the last things to resolve before the 6.0 release is the methodology for updating ATE. (Despite the idea that 6.0 will be the next "stable" release, there will no doubt be plenty of minor updates over the next year or two, and it makes sense to do a little planning now to make those as painless as possible to install.)

Because updating touches on a lot of issues about which dealer/developers have differing opinions, it seems worthwhile to describe the general plan we have and to solicit feedback before it gets solidified. So here goes...

We've identified three different frameworks for how ATE updates might be managed: user-controlled, site-controlled, and dealer-controlled.

The user-controlled model is the most typical, with a "Check for Updates" option on the Help menu. But it's the one we're least sure is useful for ATE. Does it make sense to allow individual users to autonomously update this way? The feature could be enabled or limited via a CFG file, but if disabled by default, who would set it up, other than a dealer or site administrator? And why wouldn't they prefer one of the other two update models? Based on that reasoning, it seems that the feature would mainly be used if it were enabled by default (and perhaps subject to being disabled by an application-level command sent by the host). But would that be a burden on dealers?

The site-controlled model is the one we introduced in 5.0, where you can place the update package in the %MIAME%/atesetup directory on the application server, where A-Shell will automatically detect it and prompt any affected users to update using it. The main improvement we propose to this model is a new packaging option to avoid having to download the huge update package from the server to the client (particularly cumbersome in with Windows servers that don't have FTP). (More about this under packaging below.)

similar, except without the dealer's off-site manifest, and without the need for the ASHUPDATE.LIT utility to be executed automatically. In most cases, the site administrator just downloads the install package into the atesetup directory whenever they want to roll out an update. The ASHUPDATE utility might however be used by the site administrator to periodically check for, and optional download updates directly from the MicroSabio update server (i.e. cutting the dealer out of the loop). This model has already been in place since 5.0, although we have some improvements to it (discussed later).

The dealer-controlled model seems to have the most potential for streamlining the update process in cases where many sites are under control of a single dealer (who presumably would like to keep them all on a common version). It uses the same mechanism as the site-controlled model to detect users who need an update and to get it to them. But rather than rely on a site administrator to put the update package into the server's atesetup directory, a new utility, ASHUPDATE.LIT can be inserted into the application startup process to have it automatically query an update control file maintained offsite by the dealer (i.e. on the dealer's web server). When the dealer decides to promote an update, they update that one offsite file, after which the ASHUPDATE utility will detect the change and will download the install package into the atesetup directory where it will get forwarded to the individual users as they connect. This model does require that the dealer have a web (HTTP) server where they can place their own control file, but the update packages could still be downloaded from the MicroSabio server (or any other server chosen by the dealer). (If the dealer doesn't have access to their own web server, we could probably make space available on ours, since the control files are only a 100 bytes or so, and the utility to access it is smart enough to not check more than once every 5 minutes or so.)

The model also requires a configuration file to be set up (once) on each application server, directing the ASHUPDATE utility to the location of the dealer's update control file. But that seems easier than having to send out the actual update package to every site, every time the dealer wants to promote an update. (Unless of course you already have an automated procedure for doing this, perhaps in conjunction with updates to your application.)

So, would anyone be likely to use one or more of these methods? Or is this the kind of thing that doesn't need to hold up the release, since you already have the tools available to configure such processes yourselves?

Two other update improvements/issues unrelated to the framework:

Packaging:: "Monolithic" (all-in-one-file) vs. web-based "granular" (where only the pieces that are needed get pulled down from the Internet). Because the monolithic package is now getting quite large (nearly 20MB), it seems that the granular web-based version will be the most convenient in most cases. But it of course depends on each workstation having good Internet access. Is this a reasonable assumption these days? Is there reason to prefer the monolithic package anyway? Should we support both, with a choice made at the site or user level? Or perhaps a run-time decision based on probing the client's Internet capabilities?

Updating shared (in-use) installations: Previously we simply didn't allow this. Now, after some testing, we are reasonably convinced that it is possible to rename the current bin directory while users are running from it, and install a new bin directory in its place. The process is not 100% foolproof, since an existing instance might conceivably try to load a DLL later, getting a newer version than expected. Or it might be adversely affected by a subtle conflict between a newer LIT module and the older EXE. But such incompatibilities would be extremely rare, especially in minor updates. Still, it will always be preferable to install when no users are running, so the installer will warn about it. But we can now give the user the option of proceeding with the installation anyway. And that should be a huge time-saver for sites where many users are loading ATE (or A-Shell/Windows for that matter) from a shared server.

Comments/feedback welcome.

We mostly use thesite-controlled updated placing the latest install EXE in %MIAME%/atesetup (thats if our customer trusts their users to update them self when logging in) otherwise we just give the system admin the latest install EXE and they roll it out themself. - its their choice.
All it working very well, simple, and just one file.

Morning Capn,

Thanks for laying out all the options.

As you know we like to be in control of the rollouts. We do have our field version of ATE on our website that we tell the user to download.

However, something more of an automatic trigger would be nice too. I don't know how the system would know an updated ATE was on the website, unless as you said, the server performs some task to grab the latest ATE from the website then loads it locally.

I do have a question on the server based update, are you saying its possible to have ATE loaded native on the linux side and have it copied up to the workstation? Most of our sites are not mapped (via samba) to the linux server.

Also, what are the Ashell/Server requirements for the new ATE 6.0?

Thanks.

Frank thats what the site-controlled option does, just ftp your ate-x.x.x.x-zoom.exe to %MIAME%/atesetup on your Linux server and Ashell/ATE will check/compare this with your current version when the user logs in, if it needs updating Ashell FTP's it locally and launches the install...(as if you double clicked on it)

Your also need ate.txt in %MIAME%/atesetup this contains what the user sees if an update is required.

Well put Steve, I couldn't have said it better myself.

Just to clarify or expand on a few implied questions...

The mechanism behind the dealer-controlled model is that you would insert an ATEUPDATE.LIT command line into your application startup command file, and it would check your (i.e. the dealer's) web site for the update control file in order to see if there was a new, approved update available. If so, it would pull down the install package .exe and copy it into the %MIAME%/atesetup directory (as Steve is doing manually in the site-controlled model).

Note that checking the web site for an update to the update control file shouldn't be much of a performance hit, because the utility caches the control file locally and only downloads a fresh copy if it is more than 5 minutes old, and that process should only take a second. The only significant delay would be if there was an update to download, in which case if you're using the monolithic package, the 20 MB download could easily take quite a few seconds, or even minutes, depending on the speed of the connection. (The granular package solves that problem, as the only package needing to be downloaded initially is the 200K setup launcher - the rest gets downloaded only as needed while actually running the update.)

Regarding the ate.txt file, although it is highly advisable that you edit it to say something appropriate for your users, if no ate.txt file is present, a default message is used.

Thanks for the clarification Steve and Jack.

(And Steve, nice to know your not out there causing trouble in the streets of London )

well, i have a lot to say about this subject, but i'll be brief here.

First ...
Steve, thanx for the %MIAME%/ate.txt hint, that works great!

I dont believe that we would utilize the current idea of the 'dealer-controlled' method due to the fact that i can very easily send the necessary updates to our clients %MIAME%/atesetup directory and have more control of who gets what and when.

Packaging: "Monolithic" vs. "granular"
Does the "granular" method also copy the update files to the server %MIAME%/atesetup directory?
it sounds like a no brainer to me, if you can successfully update the client with a smaller package, why not?

what about a method called Web-only, where the client checks the web like in 'dealer-controlled', but instead of sending the package to the server, it drops it right on the PC for the install. yes, each client will download the package from the website, but many of our clients have ATE on remote sites that connect via the internet to the server anyway, so, we're not really saving any bandwidth by putting it on the server to begin with. plus, with the "granular" packaging, it might not be too bad of an idea even for Local users.

Jason

The granular method just requires that the ate-#.#.#.#-*-web.exe file (about 200K) be in the %MIAME%/atesetup directory. After it gets transferred to the ATE client (and launched), it will pull the rest of the modules directly from the Internet to the client/workstation, and only those that are needed. I can't think of any down-side to that method, vs. the "monolith", except in cases where the clients do not have Internet access.

But you are right that we can take it one step farther and have the client download even the -web.exe file directly from the Internet, rather than from the application server. In fact, that method is already supported in 1227. Instead of putting the -web.exe file in the atesetup directory, put or create a file called:

%MIAME%/atesetup/ate-#.#.#.#-*-web.txt

(i.e. same naming convention as for the exe files, but with a .txt extension instead)

which contains, on the first line, the URL of the corresponding ate-#.#.#.#-web.exe file. For example:

http://www.microsabio.net/dist/51rel/ate/ate-5.1.1227.4-web.exe

In this case, the server will simply force the client to do a Shell Execute operation on the URL. This does eliminate the 200K transfer of the -web.exe file from the application server (which can be a significant improvement if there are obstacles to such transfers, e.g. FTP not supported or not available). But, at present the down side is that the user will have to be trusted to complete the download of the setup executable and then launch it. (Depending on the browser, version of Windows, and security settings, this could involve one or more confirmation dialogs.)

We could perhaps work around that minor annoyance, but it would require putting some kind of module on the client to perform the download and launch the setup program without questions. And that would require a preliminary update, makes for a bit of a chicken-and-egg routine, or at least a merry-go-round.

BTW, there is a -web setup package for 5.1.1227.4 (at the URL shown above), so feel free to experiment with this on your own server.

i installed ATE 1227.4 onto my computer, then i tried to use the %MIAME%/atesetup/ate-5.1.1228.1-web.txt with the URL to the ~1228.1-web.exe on your distribution site. I was prompted to run the update, the ATE window closed (as it should), and then the ~1-web.txt file was executed and come up on my screen. ATE did not execute the URL that was inside (unless i did it wrong)
file attributes:
-rw-rw-rw- 1 datad user 64 Aug 17 11:02 ate-5.1.1228.1-web.txt

file content:
http://www.microsabio.net/dist/51dev/ate/ate-5.1.1228.1-web.exe


But, the real reason i'm posting is to say that, for me (the dealer) the process for getting the update to the client machines is really the same between each Model. I have to send a file to each and every one of my customer's servers and put it into the %MIAME%/atesetup. it may be the 20MB installer, or the 64k web.txt, at that point it really doesn't matter, i still have to touch each server.

I'm just brainstorming here when i ask: would there be a way to have a file: %MIAME%/atesetup/ate-update.txt which would include a URL of a directory, of which ATE would check to see if there is a new version of ATE, and if so, download it directly to the client PC and install it.

you wouldn't have to touch every customer server each time there is an update, and you wouldn't have to setup any kind of extra authentication if you didn't want to (http defaults to annonymous)

jason

The desire to avoid having to touch each system each time you want to schedule an update is exactly the reason for the ATEUPDATE.LIT utility (which I haven't yet released). True, it would still require a CFG file on each site that would point it to the web location where the information about available/recommended updates would be kept (either at the dealer's web server, or perhaps ours). But once the CFG was set up, from that point on, you would only have to touch the one central file on the designate web server in order to set in motion updates at all your controlled sites.

The idea is that you would insert an ATEUPDATE command line into your application startup so that it was executed regularly (if not necessarily on every new instance launch). It would check the local CFG file, and also check to see if we had a recently cached copy of the web update control file, and if not, then it would download a fresh one. Then it would check to see if the version recommended by you (the dealer) matched the version the user was currently running. If not, it would download corresponding the ate-#.#.#.#{-web}.exe file into the atesetup directory (unless of course it was already there). After that the updates would occur as they are now with the atesetup directory scheme.

Note that I'm thinking of just using the http: protocol to download the update control file, so unless you deliberately put the thing in a password-controlled web directory, no authentication would be needed. You would, however, need to have an actual web server. (Although as I mentioned elsewhere, we would probably be willing to give you a special directory on our web server to store your update control files, so you wouldn't need to do anything but email us an updated control file whenever you wanted to post it.)

As for the problem launching the URL from the .txt file, let me re-check that. What's supposed to happen is that the server tells ATE to do a shell executed on the CONTENTS of the txt file, not the txt file itself. But offhand, I don't think that approach will be the best one, due to the extra step of having to launch the browser to download the exe. It seems cleaner for the server to download the -web.exe file (all 200K of it) and then launch it directly on the client.

Ah, now it makes sense! That sounds like a good idea. I agree, having the client execute a browser open to download the files might not be the best solution.

I know there are issues when updated from a Really Old version like 5.0.997. can you say what version of ATE would have to already be installed to be able to execute the Full Install versions?

jason

There are only really three complicating issues I can think of when updating from 5.0 that I can think of:

1. ATSD %MIAME%\atesetup: The first only applies to updates triggered from an ATSD server (via the atesetup directory mechanism). Since FTP is typically not available in that environment, it uses the raw aux port transfer mechanism to send the setup program from the server to the client. But that mechanism wasn't completely reliable in 5.0 for very large transfers. (This is why the ate-#.#.#.#-web.txt scheme for having the client launch the URL directly was implemented.) But all of that could also be avoided by just manually pointing each client at the setup program.

2. Installation Directory: The second problem isn't related to the server platform so potentially affects everyone. Under 5.0, the default ATE installation location was C:\Program Files\MicroSabio\ATE. But we later decided that was a bad place to put it due to UAC limitations which started to appear in XP and became nearly unavoidable in Vista and W7. We considered splitting the installation up into a read-only program component and a writable data component, but no one seemed to like that idea, preferring instead the simplicity of having all of ATE in one directory tree. So instead we decided to default to C:\ATE. I believe the setup program simply acts like it doesn't see the original installation if it was in c:\program files, so it only offers the "Full Install" option, proposing C:\ATE as the directory. So I think if you just hit NEXT, NEXT, etc., it will update from 5.0 to 5.1/6.0 without any drama. It does find your existing configurations, since they are in the Registry.

3. The last problem is the shortcut that the user launches ATE with. At this point, it is impossible to know for sure where any such 5.0 shortcuts are, so the installation program cannot easily remove them. The installer will optionally create a new shortcut on the desktop, or just leave it in the program menu under ATE. But the user may well not notice either, and instead continue to launch the old connection. Since ATE 5.1/6.0 can operate side-by-side with5.0, there is no particular problem with the user launching the old version. In fact, it could be considered a feature. But some thought might be needed into how to make sure the users realize to start running the new version.

(BTW, for anyone with a lot of ATE installations, we can help you customize the install package so that it uses your icon and/or perhaps displays some user instructions during the installation that are specific to your user base.)

I cannot get the site-update method to work on my in-house test system.

Current version of ATE client: 5.1.1235.2
Current version of A-Shell (Linux): 5.1.1235.0

ATE client is launched via a shell script which contains:
export MIAME = /data/nif/miame
exec ashell -i /data/nif/miame/nif.ini
(Please remind me which of these statements determines the value of %MIAME%.)

There is a directory:
/data/nif/miame/atesetup

which contains:
ate.txt
ate-5.1.1235.5-web-exe

Both of these files and their atesetup directory have permissions of 770 and are owned by the common A-Shell user, "ashusr".

When I launch ATE, I do not see any update prompt. Why not?

I don't know. But if you add TRACE=ATE to the /data/nif/miame/nif.ini (or, create a copy of the ini to avoid other users activating the trace), the resulting traces might provide some kind of clue...

(Note: I renamed the ate-...exe setup program so as to force it to think it was an updated version, which is a good way of testing the facility over and over again.)

These are the results from ashlog after adding TRACE=ATE to the ATE's ini file:

I launched ATE and checked the log:
This left me at an ashell dot prompt. I logged out of ashell and checked the log:
Then I logged out of linux and checked the log. Nothing appeared at first. So I exited the log and went back in and these lines were added:

A point of confusion: There seem to be 2 ATE ini's: as seen in ATE's "help|about A-Shell" menu option, there's one on the client PC (C:\ate\miamei.ini) and another on the connected ashell system (/data/nif/miame/nif.ini). I notice in your example references to both a Linux atesetup directory (/vm/miame/atesetup/) and a Windows atesetup directory (atesetup\ate-6.0.1227.0-web.exe):

Where exactly are the /atesetup directory and its files supposed to be located?

The main problem here is that because your terminal driver is set to AM62CZ, A-Shell/Linux does not believe you are connecting with an ATE client. (Yes, it could probe to find out, but that would produce an annoying delay for terminal/clients that didn't respond to the probe, so unless your terminal driver ends in "G" - AM62CG for example - it just assumes a non-ATE driver and skips the ATE updating logic.)

Presumably you are hard-coding the TERM variable to am62cz in the login script, since ATE does not offer that emulation as a choice. Ultimately, it would be best to not hard-code the driver and instead have the client set it automatically during the telnet handshake. But, as a quick test, if you can get to the Linux shell prompt, just manually execute export TERM=am62cg and re-launch ashell. (Note that the actual TERM definitions should always be in lower case, even though A-Shell may display it as upper case in some displays.)

Regarding the confusion in the paths, the backslashes in the last 2 trace lines in your previous post are hard coded in the trace message and do not reflect the reality, which in this case is that they should be forward slashes. (I'll fix that in the next patch.) But the first line, which shows /vm/miame/atesetup, is displaying the actual directory that it is checking. It determines that from the %MIAME% environment variable. So apparently, to add to the confusion, although you are apparently defining MIAME=/data/nif/miame, when queried, it is coming back as /vm/miame. My guess is that there are links between the two directories.

Our ATE startup invokes a shell script which includes "export TERM=am62cz", a driver I believe we determined we needed in the past (though I cannot recall the reason). When I typed in the script's commands other than the "export TERM", the automatic update process worked.

The question now is, if we need the am62cz driver for certain program features to work, but ATE needs the am62cg driver for the automatic update to work, is there a way to have ATE automatically change the driver fm cg to cz after it finishes checking for or doing its updates?

BTW, you are correct that /nif is a symlink to /data/nif. It has been around forever, so I am reluctant to get it rid of it.

I don't think the link should cause you any problems - the actual atesetup directory will be the same physical directory regardless of how many different ways you can name it.

As for the terminal driver name, my guess is that you used am62cz in order to activate certain ZTERM extensions to am62c. But I suspect that any such extensions would also be covered by am62cg, since it attempts to handle pretty much all of the ZTERM stuff as well as the ATE/GUI extensions. The only two caveats would be:

1. Any application software that specifically checks for the driver name in order to make some decision. (Unfortunately there is no easy way of universally checking for that, other than perhaps a scan of all your source code.)

2. Outside of A-Shell, the terminal handling is dependent on either a TERMINFO or TERMCAP database entry associated with the terminal name. But, if you run the standard A-Shell/Linux install (even into a dummy directory) it will create TERMINFO and TERMCAP entries for am62cg, so you probably already have them. You can explicitly check via:

# grep am62cg /etc/termcap
# ls /usr/share/terminfo/a/am62cg

That said, yes, you can change the driver name from within A-Shell after logging in, using MX_SETENV .

However, all of this begs the question of how you will know whether the terminal really should be am62cz or am62cg or something else. The "proper" way to handle that is to let the terminal client just tell the server what it's emulation is when it logs in, which both ATE and ZTERM will do. (Although in the case of ZTERM, you will need to plug am62cz into the "Telnet identity" field in the Configuration > Emulator dialog.

But, if we are otherwise content with hard-coding the TERM variable (and hence the emulation) to am62c? (z or g), we could detect whether the client is actual ATE (and hence 'g') by checking for the AGF_ATE flag in AUI_ENVIRONMENT or for any of the ate'xxx fields returned from MX_GETVER . The shortcoming of this approach is that it provides no way of detecting if the client (ATE or ZTERM) is actually set to some other emulation, like WYSE5? or AM75?. The only way of doing that is to let the client set the TERM variable automatically in the telnet/ssh login.