| The future does not look bright for TSAM right now. I was the
project leader at the time it shipped, but I am working on TSM now
(the old character cell based terminal server management product.)
My management in the long run wants to get out of the business of
doing terminal server network management. I work for the group in NAC
which develops terminal servers (DS300, DS700, S/w for DS90TL, etc.)
They view their business as Network Access Servers, a new name
and a new market focus. These products will be managed by SNMP or whatever
open method the market flocks to next.
Although I've spent over a year on TSAM, and I liked working on it a
lot more than working on TSM, and wish that I could go the extra mile for
TSAM, but I am hard put not to agree with them.
TSAM sold 20 licences last quarter. TSM probably sold 300. Digital needs
money, and my group lost 5 out of ~25 people this summer. We will loose
at least 3 more next week. If you were in management would you pull people
off money-making products to work on a product that people screamed was
essential, and then only sold 20 copies of? When you are loosing sleep over
who to lay off next, you don't make high risk lo-gain bets like that.
Given that track record, would you put 3 to 5 man-years into porting to
unix when by the time you get to market, all terminal servers will be
SNMP based, not MOP? I don't think it can be justified. Just for my own
information though I would be very happy if I knew what percentage of
DECmcc licenses are on Ultrix Vs. VMS, and what the numbers are.
We can all argue about what might have been, and why this decision
was not made long ago before I got here, but after hearing last quarter's
results (both for TSAM and Digital), I have slowly been trying to pry
my hands off of this boulder.
Now maybe just opening TSAM up to 3rd party terminal servers would have saved
its life by quadrupling its sales, maybe having it on Ultrix already would have
doubled its sales. Maybe maybe maybe. Those two features would have cost
Digital even more money than it has already spent on TSAM. It certainly would
not have been to market any earlier. (And it was REAL late.)
Dominique, I hope I understand where you are coming from. You see customers
with certain needs, and those needs are not being met. You are loosing,
and in the end Digital is loosing. This note has not even dealt with your
issues. I'll quickly list some answers, but they won't help.
TSAM uses a LAN-based protocol (MOP) to communicate with terminal servers.
To go area-wide would still require a local process to issue the commands,
and a medium to major change in TSAM to provide the communications to
the remote process.
TSAM is written in C and SCAN, VAX SCAN is not on unix: 25,000 lines of code
to port. TSAM calls TSM which is written in BLISS and Macro. It is heavily
VMS-dependant, probably another 25,000 lines to re-write. In other words:
very unlikely.
TSAM already supports the DECserver 90L, just not the DS90L+.
> Also one of the most crucial questions about termianls servers is
> how to be able to force a load of the Tserver with predefined server
> and port characteristics, and be able to check actual charcteristics
> with the preset characteristics ?
If I understand you right, this is already handled by the MCC_TS_AM_GETCHAR
utility, albeit slowly. To do the checking part you talk about, run the
getchar procedure again, and do differences between the orginal setup file
and the new setup file to see if any of the settings have been changed.
You can always do a SHOW ALL INITIAL ATTRIBUTES to show preset characteristics.
In addition to the products Bill mentioned, I understand the
Onehub (unannounced?) product will have some sort of
network management of terminal servers.
I'm very bitter about all of this if you can't tell. I look back and see
all of the forks in the road that this product has taken, and wonder
if it would have been any better any other way. Although I am less than
happy with my management, they have put a lot of money into a product
which which will never be recovered. In a way this in a nutshell is the
typical half-assed kind of thing that happens at Digital, and why we are
oozing money like sweat from bullet-sized pores.
My group got wrangled into doing this product that they really didn't
want to do. In retrospect, this a bad idea for a lot of reasons.
Management should be excited and convinced that this is an essential
product. If they are not convinced, they really don't care if the product
succeeds of not. Although the idea that the group who makes the network
product should know best how to manage it, in this specific case, it didn't
work.
TSAM needed support for 3rd party terminal servers. Doing this would
have been nearly impossible technically, but more importantly, until
very recently, I believe that it was proably considered 'bad-thinking'.
This was the one big mistake I made in the last year, but it took me
6 months to appreciate the issue, and find out that adding 3rd party
support probably would not have doomed me in the eyes of the big boss.
By then we were in 2nd release of field test. Way too late!
When you are going to add support for products that every quarter are
taking a bigger chunk out of your group's bottom line, it is awfully
hard to put 110% effort into daring unconvententional solutions to 'help'
you competitors. TSAM should have been taken over by what has become
the DECmcc applications group, there would not have been that mental split.
Those folks were convinced of the need for ultrix, those folks probably
would have been convinced earlier of the need for 3rd party support,
but they have as yet been unwilling to put their money where their mouth
is. (And by the way my own group has. They will never cost-recover the
amount spent on TSAM at the current rate of sales.)
By the way, this cuts the other way too; to truely succeed, we should have a
terminal server management products which run on DECmcc, Sun Netman, and HP
OpenView and knocks the poop out of all competition, but I can't imagine the
DECmcc group funding that!
I might also add that sales figures in Digital are too well protected;
so all developers like me have to go on are the glowing press-releases written
to blow smoke up other peoples you-know-whats. Reading that stuff rots your
brain. Instead we should be forced to look
at sales figures every month, instead of having to go through a pleading
process trying to find out who even knows who can get us the sales figures
on one single product.
Anyway I've said too much,
Dave
|