Browse Prior Art Database

Method for Performing Event Recordings in Accordance with a Calendar Event

IP.com Disclosure Number: IPCOM000104547D
Original Publication Date: 1993-May-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 79K

Publishing Venue

IBM

Related People

Heyen, JG: AUTHOR [+3]

Abstract

A methodology is described which permits a convenient method for scheduling an automatic sequence of processing in advance of the time it is scheduled for execution. The method interfaces with a calendar service or service used for scheduling.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for Performing Event Recordings in Accordance with a Calendar Event

      A methodology is described which permits a convenient method
for scheduling an automatic sequence of processing in advance of the
time it is scheduled for execution.  The method interfaces with a
calendar service or service used for scheduling.

      Often there are reasons to perform actions at some future date
and time that are known well ahead of time.  For example, personnel
paychecks come out twice a month, the 15th and last day of each
month.  It is desirable for a manager to send out a note the 15th and
last day of each month wherein the note states to pick up paychecks
if they have not already been picked up.  An important meeting is
scheduled 2 weeks in advance.  It may be desirable to have a note
automatically sent out 3 hours prior to the meeting reminding people
to attend.  Yet another example is an employee has given 2 weeks
notice to terminate employment.  It is desirable to set up having the
employee's user ids automatically removed from systems when the time
has come for the employee to leave the company.

      A service is provided to the user's local requesting machine.
The service allows setting up an arbitrary scenario and assigning it
to a name.  The scenario is recorded similarly to a desktop recorder
in that it records all user input in order to recreate the scenario
steps at a future time.  Upon scenario build completion, the user
saves the scenario to a name at a destination (e.g.
c:\dir1\dir2\name).  The scenario is saved in an internalized form
such that all user activity in a scenario is mapped to strings in a
file.  The file is flat and can be edited later with a flat file
editor.  This allows performing scenarios which produce an
internalized form that can be edited later.  Maximum flexibility is
achieved by allowing an edit on the internalized form without forcing
a re-recorded scenario.  For example, in the remove user id example
above, a security officer can record steps to delete some arbitrary
user id and then save the internalized form to a name.  The officer
can then go into the internalized form and replace the user id string
entered with the appropriate user id string.  Thus, the exact
scenario with live data need not be used.  Post internalized form
edits allow making...