CRAM, DataCell, and 3850 4016

datacell was direct access .... i.e. applications selected records on strip (using BBHHCCR convention) and directly read-wrote the records.

3850(-MSS) were virtualized 3330 disk drives. there was pool of real 3330 disk drives ... managed as some larger number of virtual 3330 disk drives. access to a non-staged cylinder ... would result in a "fault" analogous to a page-fault. system then staged data from tape-to-disk. faults could be handled as either six cylinder units or full tape. virtual 3330 data was staged to-from 3850 tape reels ... managed by 3850 tape robot.

the 3850 tape reels were wide tape wrapped around a cylinder looking shape (2in diameter, 4in long, with 4in x 770in tape) ... which were managed by the 3850 tape robot and these "cylinder" tape reels resided in honycomb looking structure (a tape could hold half a 3330-1 or 1-4th of a 3330-11). part of the 3850 problem was tracking newer generation of disk drives. a later 3850 model was made available with faster and higher capacity 3350 drives but they were used to still simulate virtual 3330 drives.

emerging in that some time frame was purely software HSM ... i.e. hiearchical storage manager ... with (stk) tape robot systems using more traditional shapped tape reels. operating system HSM support would stage data to-from tape at a higher level abstraction (basically on per file bases) rather than at the lower level (virtual) hardware level.

I had done a backup-archive system that was deployed at several internal locations. This was eventually repackaged with a lot of PC and workstation clients and marketed as workstation datasave ... which then morphed into ADSM (adstar storage manager) and is now marketed as TSM (tivoli storage manager). misc. past posts:

HSM evolved to include SMS (system managed storage) and newer generations of tape robots. SMS reference:

In the same time frame, STK's "iceberg" virtual disk technology emerged, sort of a technology update of the 3850-mss. 3850-mss had been done by the Boulder lab ... so it is possible that some of the same people had moved down the road to STK and worked on iceberg. san jose had compebreastive effort with codenames like seastar and seahorse that had various schedule problems. a few posts mentioning iceberg, seastar, etc

Several gov. labs. developed various kinds of storage management systems. LANL developed one using IBM mainframe managing tape library and staging to large pool of disks ... non-IBM processors could access disks using HYPERChannel thru "remote device adapters". As part of the increased "technology transfer" activities in the late 80s and and early 90s (trying to get technology out of gov. installations and into commercial operation), the LLNL was marketed by General Atomics as "DataTree".

LLNL had developed a hierarchical storage management system ... and we ... in our cluster activities part of ha-cmp

had funded the port to standard unix platforms and it was marketed on several platforms as "UniTree".

NCAR also had developed a storage system somewhat similar to LANL's. In addition to working with LLNL in the porting and marketing of "UniTree" ... we also worked with a NCAR spin-off called "Mesa Archival" to port NCAR's system to unix platform and market it.

I've also commented that NCAR's original implementation might be considered the original SAN (storage area network).

misc. past posts mentioning mesa archival, datatree, and-or unitree: