Anyone who writes scripts for others knows that issues can arise after you’ve shared them out with your users - despite your best attempts to make your scripts "bulletproof".
Of course, with Arbutus, the command language we script in is the audit industry standard, but we’ve also added quite a number of capabilities that are designed to improve the robustness of your scripts that can really help avoid issues downstream. You can take your existing scripts and add these capabilities with little or no re-write required.
The biggest single failure point in most scripts is the Esc key inadvertently getting pressed. This is why Arbutus allows you to turn off the Esc key, with SET ESC OFF. When your script is running, pressing Esc will be ignored. Just as importantly, if you have a dialog command for user input, then the 'Cancel' button is also disabled. There is no way for a user to interrupt the script through either of these methods.
Speaking of Dialog boxes, a significant source of script errors is poor user input. This is why we have upgraded the Dialog command to support different types of user input edit boxes. Rather than just character input, which can be challenging to completely validate, we also offer Date, Numeric and even Filename types. Numeric edits will (of course) only allow numbers, dates include an embedded date picker right in your user dialog (and return a date type), and filenames even include a Windows file browser, to improve the likelihood (and ease) of selecting the correct file.
Set the type of acceptable input:
When the script executes:
Scripts can also fail because one of the required pieces is missing. Most complex processes involve multiple scripts that call each other. If any one is missing, the script will fail when it tries to call the missing piece. The more complex the process (or the more pieces), the more likely one gets lost. This is why Arbutus includes the ability to include multiple procedures in a single script, using callable sub-procedures. The sub-procedures are just like independent scripts, but because they are included in the same script they can't get lost.
Another problem, particularly with complex processes, is accidentally running a 'helper' script, rather than the main entry point. This usually results in a quick error, but sometimes not before doing damage, and always results in user confusion. This risk is also eliminated with callable sub-procedures, as there is only one script, and no possibility of starting with the wrong one.
Regarding the scripts themselves, it’s only human nature that some downstream users will want to look at the script they are running or make the occasional adjustment. Unfortunately, this can sometimes lead to unintended changes or other issues that negatively impact your script.
This is why Arbutus includes the ability to 'Protect' your scripts. Once protected, the script can't be viewed or edited by the user (only yourself), ensuring that what you wrote is what runs.
See the Online Help for setting the protection key:
Finally, despite our best efforts we are all still human. We occasionally make mistakes, the required inputs aren't available, there are any number of ways a process can go sideways. This is why Arbutus includes fatal error processing. Even when the worst happens, you can still control what happens next, using the SET FATAL command. Fatal error processing offers a wide range of possibilities, to react to a fatal error and either continue or shut down gracefully. You might even email yourself an error report.
Writing bulletproof scripts is something we all strive for, and Arbutus gives you a wide range of tools to help make this a reality.