Automatic Script Execution

The Standard Edition of Really Random Numbers executes a fully customizable VBScript file each time the data file is updated.

The script file is saved as RandomData.vbs in your Really Random Numbers program folder. You may customize it with any VBScript code of your choosing using a standard text editor. You can test the script using WScript or any other VBScript execution tool.

The advantages of having a script file execute after each data update are numerous:

• Using VBScript, you can move the data to a network server as it is created. This allows multiple licenses of Really Random Numbers operating on multiple PCs to create more data faster.
• You can write scripts that automatically FTP or e-mail files to wherever they are needed.
• You can use the scripts to create multiple data files by copying or moving the existing data file.
• You can use the script to post updates of the status of Really Random Numbers generation to a central server.

The following advice is helpful to those writing scripts:

• The script file can move the RANDOM.DAT file or delete it, as long as it does it before the next write is attempted.
• Script execution does not block data generation. That means if your scripts take too long to execute, they may be called again while they are still executing. Follow good design principles to avoid this. Since data generation takes place in real-time, there is a natural time delay of many seconds between data file writes and this issue should not concern writers of short scripts.
• Any error in the script file will result in the script file not executing again until generation is stopped and restarted. This can be a serious problem if you have an error in your script and you are using the COM interface to retrieve data. The COM interface will restart data generation when it removes data from the buffer, and this will restart script generation. To avoid problems, implement error-handling routines within the scripts.
• The script file is allowed to create a RandomNumbers.Generator object and use the COM interface. Using the interface within the scripts can create vicious error cycles if error-handling is not implemented. For example, the script runs, uses the COM interface, and then has an error. The COM interface restarts data collection and the script runs again when the data file is written, again an error is thrown, and the cycle repeats. Avoid such problems by implementing error-handling routines.