Summertime and the Living is Easy
Article Date: 6/95
A typical summer here in Massachusetts is hot and humid. Working when you're hot and sticky is no fun, so in this issue, let's take a look at letting someone else handle security controls for us - the VOS batch processor. If you use FTX, look for the comparable UNIX facilities to use in a similar way.
Batch is really useful for turning things on and off at preset times, so it's a great way to allow and deny access to system resources at the appropriate times. The basic technique is to write a command macro to perform the action and then resubmit itself for the next time, using the -defer_until argument on the batch command. For instance, I might set up my_macro.cm like this:
& Do the work
. . .
batch my_macro.cm &+
-defer_until (date_time 17:30 +1 day)
&return
When this macro runs, the last thing it does is resubmit itself to batch to run at 5:30 PM the next day. Using the (date), (time), and (date_time) command functions makes this a powerful feature. By using date_time with a specific time, rather than just adding one to the date, you can avoid having the launch time "creep" forward each day by the length of time it takes the macro to execute.
Now, how can I use this to save myself effort? If all of your users go home at the end of the day, you might want to disable their accounts overnight, then re-enable them the next morning so they can't be misused. The -restrict user_name argument on login_admin can be run at night to block out the appropriate users, while -unrestrict user_name will turn them back on in the morning.
If you allow dialup access at certain times, you can use update_channel_info -no_login to prevent anyone from gaining remote access over the specified line. Using -login will allow them back in again.
On the module we use for testing, we have a number of test users. While testing is going on, we give these accounts weak passwords to simplify logging in and out repeatedly during the day. However, every night a batch job runs set_registration_info against our test account ids to set strong passwords on each one. In this way, we are protected between periods of testing.
Think about tasks involving security controls which you must (or should) perform on a regular basis. Write some self-submitting macros now, and you can spend the summer in a hammock watching batch manage your security controls.
| 
