Something like readline used for the command line client, so we could get vi-style-editing (ok, fine, or emacs for the heathens) & history search/recall/edit.
Why embed? Instead of just Ruby, how about the ability for the server to execute a given shell- or perl- (or even ruby- :-) script. Then you can use any scripting language you like. Heck, or even compiled executables from other languages. And you could have admin schedules that execute those scripts rather than using client schedules or having an admin schedule define a clientaction to execute a script. Maybe use the EDITOR environment variable to do seamless script editing. "edit cancelprocs" spawns vi/emacs/nano/whatever, then "run cancelprocs" to execute. "define script cancelprocs type=external path=/dir/cancelprocs" maybe. I'd like to see dsmulog wrap sanely. I second the intelligent application of SQL to commands. I'd like to see the ability to define aliases in the command-line. Add the ability to track file/filetree moves and update hl_name rather than expire and rebackup in new location. Or if not track, allow us to "update hl_name where hl_name=xxx". I wonder if we'll be able to do that after the DB2 change, or if the schema will be too complicated. This was fun. Great thread, Steven. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Steven Harris Sent: Friday, May 02, 2008 9:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Fantasy TSM More years ago than I want to remember (ok ok mid 80's to mid 90's) I was a CICS sysprog in an MVS mainframe shop. Now somewhere about CICS' 21st birthday the developers decided that the old assembler code had become unmaintainable and so to improve reliability they re-specified it using something called Z language (from memory... and strange that it was never heard of again if it was so good), and recoded it from scratch. This then became a reliable platform upon which enhancements could be built. TSM is about that old now. I assume that it was translated from assembler to C about the time it began to be supported on multiple platforms, and now with V6 and DB2 there is a database back end that will allow significant DB changes with little development cost. So, lets assume that TSM is to be redeveloped - as-is in V 7.1 but providing significant improvements in 7.2. While still retaining the basic flavour of TSM, - progressive incremental backups, storage pools, copypools - what features and capabilities would you like to see? Me? On the server I'd like : Migrate Inactive on primary storage pools. A scratch pool concept so that TSM never lost track of a tape or its last use, and its tape stats. Better tape library integration - maybe an abstract library that is mapped onto a real library Instant creation of weekly/monthly/yearly incremental backups from the current state of a node, by means of a logical operation on the DB, with no new copying required. Intelligent application of sql in commands eg cancel sess where session_number in (select session_number from sessions where session_type='NORMAL') More intelligent script and macro languages. I'd really like to see something like Ruby embedded for this purpose. On the Client Ability to manipulate API objects from a command/line and gui interface Ability to backup/restore via stdin/stdout Subfile backup to be extended to work on huge files. API interfaces to perl/python/TCL and supplied SWIG files for binding other languages Fully functional Admin API with the same interfaces as the backup API Encouragement from IBM for third parties to develop backup interfaces for niche/obscure databases such as Reality-X, Cache, Firebird and other applications not well suited to file level backup eg Cyrus mailserver. Maybe a directory of user contribs in the client distribution. API to permit intelligent client/or server level incrementals. eg RMAN sends entire DB, TSM sends and stores only the changed blocks. What would you line to see? Regards Steve Steven Harris TSM Admin, Sydney, Australia This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.
