Dynamic Configuration Files?
Printed From: Rocket Software
Category: AccuTerm Knowledge Base (read only)
Forum Name: Green Screen
Forum Description: General terminal emulation questions
URL: https://forum.asent.com/forum_posts.asp?TID=2701
Printed Date: March 26 2026 at 5:07pm
Software Version: Web Wiz Forums 12.03 - http://www.webwizforums.com
Topic: Dynamic Configuration Files?
Posted By: TonyG
Subject: Dynamic Configuration Files?
Date Posted: November 05 2018 at 11:43am
|
I was just doing a side-by-side compare of two .atcf files to see why they were displaying colors differently. I found two differences, fixed them in the anomalous file, and the world became a better place. But as I look at the files, the only difference is the IP address. So I was thinking... Wouldn't it be cool to have a single default .atcf, and then have others reference that and only provide their override values? Example: InternalMaster.atcf should be consistent for all local connections, with colors, key mapping, term types, etc. Dev1.atcf inherits that and just has one additional line to set the IP address for the target server. Prod1.atcf looks exactly the same as Dev1 but with a different IP. Format: [AccuTerm] Template=Internal.Master.atcf HostName=192.168.999.999 Put the template file on a network server and we can change configs for the entire office with one file change. How cool is that? Extra credit: If the Template value begins with a reserved character like @, then rather than opening the file, execute a program. Pass in the name of the requested .atcf and possibly other values like the current OS login name, and get back the contents in stdout of the default .atcf values. This will allow for code that builds the .atcf from various sources. For example, if the name of the ATCF begins with D3, we know to return D3-specific config details, but with standard keys and colors. But if it begins with UV, we'll return Universe-specific details with the same colors. All the local .atcf file needs is the hostname/IP. If the site only has one DBMS, the config doen't need to specify the host, it will come in as the default. This reduces the workstation .atcf to two lines: [AccuTerm] Template=@//netserver/apps/GetAccuTermConfig.exe Executed command to retrieve default template values: //netserver/apps/GetAccuTermConfig.exe Prod1 tgravagno Actually all of this can be avoided if all .atcf and .atly files are stored in a network drive. Then the admin can create one config which can be referenced by all users. Or, one folder can contain the configs for all users, and the admin can easily modify configs with some automation in that one spot when required. Of course that means that all of the config files can be generated (even from MV) and replace the existing files at any time. (So, one-shot generation of the .atcf rather than dynamic building of the .atcf with a template.) While this is a very elegant solution, I don't think I've seen it employed anywhere. Sites just install AccuTerm and deal with tens or hundreds of workstation-located config files. That makes genral environment changes a real pain, especially with remote users. My intent here is to present ideas to facilitate maintenance in a larger installation. Thanks! ------------- Tony Gravagno Nebula Research & Development TG@ Nebula-RnD . com http://Nebula-RnD.com/blog http://Twitter.com/TonyGravagno http://groups.google.com/group/mvdbms https://www.linkedin.com/groups/64935 |
Replies:
Posted By: Shrek59
Date Posted: November 06 2018 at 11:49am
|
Hi Tony, I've approached this from a different angle. Basically, "lots" of things happen when a user logs in. One of these involves loading a standard palette into the current AccuTerm session. The palette is stored as an MV item in UniVerse, and loaded using the palette property of the settings object. A matching process makes sure that all the visual styles are defined the same (the colors property of the settings object). Additionally, we have multiple palettes. Which palette gets loaded depends on an environment identifier (TEST, LIVE, or STANDALONE), and then we allow for specific accounts to have their own palette (archived accounts). That is (mostly) invisible to the user. They DO see the palette change on login if the palette in their saved atcf file is different, but that is about it. We also set the changed property to false after these changes so that the user isn't prompted to save their Accuterm configuration when they exit. Historically, we also defined function keys on login, but I now take the reverse approach of letting users define their function keys, and reading those definitions on login so that applications can respond to them. So, different approach, but probably a similar outcome. Cheers, Brian Speirs
|
Posted By: TonyG
Date Posted: November 06 2018 at 12:16pm
|
Brian, that's a good solution that makes good use of the tools. Yes, there are many ways to skin the poor kitty. With that solution the user needs to be logged in first and the configs come from MV code. What I was describing was a non-MV mechanism which can be used to get to a Linux server too. With the @program reference we could even use code that generates a script that gets loaded with the config to login to the system being targeted. Sure that screams security violation, unless the script invokes a 2FA mechanism that requires the user's phone. Anyway, I can see your solution being used in combination with this one. For example, let's say you're using IP addresses to hosts rather than hostnames. With dynamic config files we can get the new IP of a server and other details, the user gets in, and then they execute your MV code to load their preferences. It's all good. Just looking to do more here. Really, as I think about this we could do this without changes to AT configs... Use a separate executable that's invoked with a shortcut similar to AT. Pass it the desired .atcf name. It will get the user's ID and other details then pass it to some other routine which generates a config file. Save that into the .atcf and then invoke AT as normal. Voilà! Dynamic configs with no changes to the product. OK, now does anyone want to buy that?      ------------- Tony Gravagno Nebula Research & Development TG@ Nebula-RnD . com http://Nebula-RnD.com/blog http://Twitter.com/TonyGravagno http://groups.google.com/group/mvdbms https://www.linkedin.com/groups/64935 |
Posted By: TonyG
Date Posted: December 19 2018 at 12:57pm
|
I just had another scenario where a server was moved and all of the .atcf files needed manual updates. Emails were sent to workstation users to explain how to make the changes. And of course, some users didn't get it quite right. Really, all of this can be avoided, and based on this thread I now know how to do it. We can easily and dynamically get AccuTerm to accommodate changes to IP addresses, enhancements for function keys, key-remapping for TCL users, macros, and anything else that usually requires a manual change on multiple workstations. Please let me know if you are interested in a solution to this problem of configuration file maintenance across unweildy numbers of workstations or in a distributed environment. ------------- Tony Gravagno Nebula Research & Development TG@ Nebula-RnD . com http://Nebula-RnD.com/blog http://Twitter.com/TonyGravagno http://groups.google.com/group/mvdbms https://www.linkedin.com/groups/64935 |