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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steven Harris
Sent: Friday, May 02, 2008 9:06 PM
To: ADSM-L AT VM.MARIST DOT 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.
|
