Pfiles Get/Put

The IBM 7094 PROCSY system allowed users to manipulate local files but would discard them when the user logged out. I simplified this process of saving and retrieving files by developing more syntactic macros that could handle multiple files at once.

Semipermanent storage was accessed through the pfiles copy command, one file at a time.

PFILES GET name password account PFILES PUT name password account

I used a recently added mechanism that would allow a macro to detect the separator characters used on the command line. I used / to separate file access info so that multiple files could be listed in one command.

GET name1 name2 ... PUT name1 name2 ...

Accounts were three-letter codes. Mine was ACD. If someone wanted to play my Interactive Football they would first get it from my account along with what ever else they might need.

GET FOOTBALL//ACD

It was computing center policy to discard pfiles that had not been accessed in 15 days. Users would 'tickle' files by getting them even when they would not be used.

The policy suggested that users needing longer term storage could purchase a 7-track magnetic tape which the university would store. Operators would mount the tape when requested. Users would be on their own to manage the sequential storage tapes provide.

I designed a system where, rather than discarding old files, they would be written sequentially to a university owned daily archive tape. As these tapes aged they would be consolidated into more compact archives with thankfully retrieved files omitted. This would turn our limited disk capacity into a tape index system with a LRU cache online.

Saul Rosen, the center director, agreed it was a workable scheme and probably better than users tickling files they might not ever need. He didn't suggest how such a project might be started. I didn't know myself so we kept on deleting peoples files.

As I think about it now, I should have written a simulator that would show recovery performance with varying numbers of tapes mounted and suggest the amount of duplication required for reliable recovery in the presence of tape errors.

Storage policy could be reduced to decision tables that could be tested in advance and updated as user habits changed and storage system characteristics evolved.