in reply to Fast Recall

...no help to be found in this post... just formatting to prevent eye bleeding...

I have a perl script that gracious monks help me create that 'watches' a flat file without locking it and performs an action on each line written <CRLF> to the file. It has served me well.

Now a new file is writing about 6 lines per second, which the script can handle, but the new requirement is to remember past 'lines'.

The file is populated with the status of Big Iron jobs. Mainly Successfully completed jobs.

Successful jobs can be ignored IF the Job wasn't previous Failed. If a job is failed, the job name must be plucked and stored somehow.

Each Success Job needs to query the failed job store before it can be discarded.

Success Jobs that are found in the 'store' are acted upon to clear failed statuses previously acted upon and thus need to be purged from the 'store'.

Since I have limited access to this box (I had to beg to put the perl code on), I can't use a db to do this with, so I was wondering what would be my most efficient option to 'store' failed job names. The failed jobs would need to be purged in 8 hours (if success never occurs), since Job names are used again (daily).

Thanks

...no help, just formatting for readability.

OP: README

Replies are listed 'Best First'.
Re^2: Fast Recall
by Marshall (Canon) on Sep 03, 2010 at 02:47 UTC
    So it sounds like you just need some "lightweight" persistent storage for these failed jobs, where you can find some failed job name in the failed job list easily (and I guess probably containing some small amount of other info). Sounds like a hash structure.

    One idea is to just implement this with Config::Tiny. This is a module to fiddle with .ini files. This is a simple critter with no installation dependencies. So no fancy install is required, you could just put it in same directory as your new improved script.

    Anyway this thing implements HOH, for you to use as you see fit. Some very simple app code is attached.

    Update: OOps for posting at wrong level (the tidied up version instead of the original node..Ooops). Using a hash table may be overkill for just keeping track of "name => date/time", the idea BrowserUk would serve that purpose fine. I think there are other tied hash modules, but this was the simplest one that I could think of and avoids any potential installation hassles.