|
Dominique -
Thank you very much for for entering your feedback on the Terminal Server
AM. Below is some information to address some of your questions/concerns.
- Lynne
====================================================================
1). I was surprised to find the ENABLE and DISABLE command on the TSAM:
DISABLE/ENABLE MCC 0 TERMSERVER_AM
No other acces module has this feature. What is the purpose of
this, compared to similar acceess modules (e.g. Bridge) which does not
have these commands?
** It is because of the way TSAM is implemented. Rather than rewriting
** the existing TSM (Terminal Server Manager) code, it was decided that
** TSAM would use the callable interface to the existing TSM product.
** Since the TSM code is AST-driven, it cannot be run directly within
** the MCC system. So, TSAM uses a detached process to perform the
** necessary TSM operation(s) to complete the MCC request. The Enable
** and Disable directives are used to start up and run down this
** server process.
2). Is there a good explanation why it take so long to make the
PORTS... expansion using the ICONIC MAP interface ? I measured abour 4
seconds per port, The terminal server was not very busy, and my
workstation was doing only this command!
** The Terminal Server AM polls each port (actually, any entity) instance
** before returning an identifier. Therefore, it needs to connect to the
** server and read the port information for each port. There is room
** for enhancing the performance for returning identifiers on a wildcard
** operation (for instance, on most servers, there are a fixed number of
** ports, so why ask the server for each identifier).
**
** Another aspect of the problem is that, on an entity expansion operation,
** the Iconic Map PM does not display any entity instance information
** until the AM has returned all information, which (depending on the
** number of entities, etc) can leave the user with a blank screen for
** a while. It may be nice to have entity instances pop up on the screen
** as they are returned by the AM.
The following are questions which goes beyond the scope of the TSAM,
but are applicable to the TSAM.
3). Whes e.g. SERVICE ... is expanded you can get A LOT of services,
specially in our environment. It is not uncommon to have more than 100
services available, sometimes 150 or 200. Trying to find a service is
very difficult. With the mouse on the window bar, you can browse
through the list but you do not know where to find the entity, because
these are not sorted e.g. ALPHABETICALLY. A multi column list could
perhaps be easier, or a window which automatically adapts to the number
of entities in the list.
** Digital's terminal servers return the service and node names in
** alphabetical order, and therefore, TSAM returns them in alphabetical
** order. I think that the Iconic Map PM actually returns them in the
** reverse order in which an AM returns them. The ordering could
** possibly be a problem for other entities which do not return instances
** in any particular order.
4). When some attributes of some entities are shown (e.g. SESSION) a lot
of attributes show "--Attribute not available". Also terminal servers
which do not have "TCP/IP" support shold not "SHOW" e.g. the INTERNET
entity.
This could be interesting for the "software developer" but is less
interesting for the "network manager". If these attributes does not
exist in the entity, why should we try to present something which is
not existing. I agree that this is perhaps a more easy way to program
the accres to different "types", but I think it's better to reduce
the amount of "unusable" information.
** This comment is actually TSAM-specific. Variants were not implemented
** in the first version of TSAM, due to time constraints. This means that
** when you expand a terminal server entity in the Iconic Map PM, all
** terminal server child entities are displayed, whether they are supported
** by the particular terminal server type, or not. It is also the
** reason that "attributes not available" is returned. The Terminal
** Server AM currently supports 7 different types of terminal servers,
** supporting around 18 software versions, so there is a lot of work
** to be done in the area of fully supporting variants.
5).Using TSM it is possible to give a the command "SHOW USERS". This
is very handy. It did not found out how it is possible to do this with
DECmcc. The only possible way using the ICONIC map is to do several
shows, one on each PORT, and look in the middle of each data window to
find whats beside "Username".
** This is a TSAM-specific problem. We decided not to implement a User
** entity, as the information displayed for the user entity is really
** just a summary of port status information for logged in ports. There
** was talk in the terminal server group about implementing "user-profiles"
** in future terminal servers, and we didn't want to define a "user"
** entity now, only to find it in conflict with a "real" user entity
** in the future.
Also a command like "SHOW SESSION" where important information can be
seen immediately, is not available as such.
It would be usefull to have a table where, for a few selected
attributes, these are displayed for all instances of the entity.
** The functionality is available in the Terminal Server AM
** (SHOW TERMINAL_SERVER svr-id PORT * SESSION * {attr}), but you want
** to be able to find it quicker in the Iconic Map PM (ie, without having
** to navigate through each using "next entity"), correct?
|
| RE: .1
If I may, I'd like to make a suggestion concerning:
** It is because of the way TSAM is implemented. Rather than rewriting
** the existing TSM (Terminal Server Manager) code, it was decided that
** TSAM would use the callable interface to the existing TSM product.
** Since the TSM code is AST-driven, it cannot be run directly within
** the MCC system. So, TSAM uses a detached process to perform the
** necessary TSM operation(s) to complete the MCC request. The Enable
** and Disable directives are used to start up and run down this
** server process.
Would it be possible for the TSAM to automatically start up this detached
process the first time a command that requires it is entered?
Also, could the process delete itself after a certain period of inactivity?
(15 minutes? 30?)
This is just a suggestion for a future version of TSAM. Sorry for adding
more work to your already long list, but I thought the idea should be
mentioned...
- Jerry
|
| RE: .4
> I happen to like the fact that you can startup and stop the background
process from within MCC. I find the dna4 event process a pain to remember
to do.
I agree that it is a "pain" to have to leave MCC do do any management
operation and on that basis, I agree that being able to start and stop
the process from within MCC is goodness. But, wouldn't it even be better
if it was all transparent?
Maybe I should also suggest that that the DNA4 sink automatically start
itself on the first occurrence of GET EVENT?? Sorry, Jim! ;)
> Personally I feel the answer is, if you can't remember, put it in your
MCC_INIT file.
If you know that each time that you enter MCC you will enter some TSAM
commands, then as a short term fix, this is a good idea, but what about
the users that have no intention of **always** entering TSAM commands.
It seems like a waste to start up the detached process for nothing!
|
|
Regarding
Also a command like "SHOW SESSION" where important information can be
seen immediately, is not available as such.
It would be usefull to have a table where, for a few selected
attributes, these are displayed for all instances of the entity.
** The functionality is available in the Terminal Server AM
** (SHOW TERMINAL_SERVER svr-id PORT * SESSION * {attr}), but you want
** to be able to find it quicker in the Iconic Map PM (ie, without having
** to navigate through each using "next entity"), correct?
Related to the last point of prevous note, You are right in saying
that,
even if something as SHOW SESSIONS is rather easy to generate in the
FCL module (also SHOW USERS), it is NOT POSSIBLE in the ICONIC MAP.
Isn't it strange that a sophisticated user interface is less functional
than the FCL interface ?
This functionality is certainly considered to be important in the Iconic Map
but has not yet been implemented due to time constraints.
Verna
|
|
Jerry -
Thanks for the suggestions.
To clarify, a user does not have to enable TSAM each time he/she
gets into MCC and wants to do TSAM operations. TSAM needs to be
enabled once on a system, and then is available to all MCC users
on that system, until TSAM is disabled. TSAM is automatically
enabled during the installation, which runs the startup procedure
MCC_STARTUP_TS_AM.COM.
One of the things to keep in mind about having the server process
automatically enabled when needed is that enabling the server
process requires additional privileges for a user, than is
required for performing the actual operations once the server
process has been enabled.
Also, having to start up a server process on any TSAM request
would certainly hurt the performance of that request, so perhaps
it is better to have it done explicitly with an ENABLE command.
Additional feedback on this is welcome...
Lynne
|
| RE: .7
Lynne:
> Also, having to start up a server process on any TSAM request
would certainly hurt the performance of that request, so perhaps
it is better to have it done explicitly with an ENABLE command.
Sorry if I was unclear, but I meant that the server should only be **started**
on the first command (from any MCC process) that required it. This could
be accomplished by special casing the error that is returned when the
server is not there. I'm assuming that there must be some way to determine
whether or not the server is operating - please correct me if this is not
true.
As far as privileges are concerned, isn't it a moot point? If I'm running
DECmcc and I enter a TSAM command while the detached process is not running,
I'm going to get a "No detached process" message (or something like that),
right? If I then try to enable the detached process, and I don't have
privileges, I'll get a "No privs" message, right?
If, however, I'm running DECmcc and I enter a TSAM command while the detached
process is not running and TSAM tries to start the detached process automat-
ically, then, if I don't have privileges, then I'll still get the "No privs"
message, right?
Seems to me that you still save the user one error message and one more
command to type in...
Most of the cases like this that I've seen boil down to how easy (or hard)
it is to check for the server process. The way you've done things in the
current version of TSAM is fine. It may occasionally cause a small annoyance,
but that is a small price to pay for being able to manage TSs from DECmcc!
I would just consider this to be a future "nice to have" feature.
- Jerry
|