OneGate supports using different configurations using the same program set name, so that one may interchangeably use live code and development code at the same point in time This can be useful if you're testing new features that are modular and simply want one module to work in test code, or if you want to use an entire copy of all relevant configurations as a testbed, and alter those configurations to protect your production environment.

By way of example, let us assume that the same command lines, fields, etc., are all required for an entire project, but we don't want to affect live data. Assume that an environment variable triggers the change in which data your application actually utilises (filePro users, consider PFDIR by way of example). You can keep your live system running, and also run a development testbed at the same time without having to have multiple servers. The following illustrates the steps required to do so:

1. You will be copying the onegate program in your CGI directory to another name. This name is arbitrary. You could call it "onetest", "onealternate", or even something highly cryptic such as "lkjabwlouz". The name doesn't matter, so long as it's a valid filesystem and URL filename. Choose your name at this time, and remember it for the following steps.

2. Copy the CGI program onegate to the name you chose, in the same CGI directory. Make sure your ownerships and permissions are correct on the new executable (ie., cgiwrap is very picky, if you're using that).

3. Change directories to the directory that contains the main onegate directory.

4. Copy the entire onegate directory tree to a directory of the same name as the CGI program you chose in step 1. (Note to users who install and use their programs with the .pl suffix: The directory name should not include the .pl suffix--only the main name of the program.) Make sure all ownerships are changed to correct values throughout this tree.

To use an alternate testbed, simply call the new CGI name you picked in step 1 above in your URL.

When OneGate sees that it is not called "onegate" or "onegate.pl", it will check for a configuration directory with the same name with which it was invoked, at the same directory depth that the main onegate directory resides. (eg., If your onegate directory is /usr/local/lib/onegate, your directory for a testbed named "onetestbed1" would be /usr/local/lib/onetestbed1.) If said directory is both present and readable, it will use this directory for all configuration values. The one thing to ensure is that you maintain the same max_session_count configuration in all testbeds, as OneGate will use the same lock directory for all lockfiles in order to maintain an accurate count of instances, whether one is using one production environment or a production environment and five different testbeds. The [maindir]/locks directory (in this specific case, [maindir] being what you installed into, rather than the testbed version of it) is always used for all locks, no matter whether you're running production or any one of several testbeds.

You may alter your testbed configurations at will, changing field requirements, configuration options, and all other manner of functionality.

In order to ensure that you can go back through a complete product chain with one testbed or another, it is recommended you utilise the %p cookie on the command line, or the ONEGATE_CGINAME environment variable. Instead of hardcoding onegate into place in a URL (eg., http://somehost.com/cgi-bin/onegate) throughout your application code, you should use the value obtained from the cookie or variable instead. This will let you chain through an entire product using the same production code or testbed as you start with. You may of course use hardwired values for production and simply insert specific testbed names in the URL's for certain modules if you're just adding functionality modularly.

Any testbed whose name ends with _ajax will automatically have all default MIME types set to application/xml and the cache setting defaulted to no.

NOTE: The ogconfig and ogclone tools will work on alternate testbeds if you supply the name of the testbed (the name from step 1 above) as the first argument to either program.