HP3000-L Archives

November 2004, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Vance, Jeff H (Cupertino)" <[log in to unmask]>
Reply To:
Vance, Jeff H (Cupertino)
Date:
Mon, 8 Nov 2004 22:14:08 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (100 lines)
...
> Feel free to offer any other idea for assessing how udc files 
> and command files add overhead to the system.  

Having many UDCs to catalog adds overhead every time you logon.  Reading
below you mention that sometimes you logon on 200 times in a single day.
A large UDC file (or many smaller UDC files) will significantly hurt
logon performance.

I've seen several customer sites where they still have very simple UDC.
For instance, a UDC named "R" with invokes RUN !file.PUB.SYS.  MPE/iX
from day 1 has provided an easy mechanism to qualify filenames with
PUB.SYS and other groups and accounts (and even directory names). With
that many logons it is definitely worth reviewing your active UDCs to
see how many can easily be deleted.

CPU overhead is slightly higher for a command file compared to a UDC
simply because the command file must be opened, executed and the closed;
whereas the UDC is already opened, so it just needs to be executed (and
left open until logoff).  In my experience I have not noticed this
overhead except comparing recursive command files with similar UDCs.

UDCs will typically consume less disk space since you have multiple user
commands contained in a single file.  Since each command file is a
separate file (and even the smallest file uses up 1 page, 4k bytes, of
disk space) they require more disk.  This requirement is usually
overshadowed by the ease of maintaining command files compared to UDCs.

There is a PowerPoint slideset with notes on Jazz which goes into more
details. See: 
 
http://jazz.external.hp.com/papers/SolSymposium_03/CIProgramming_files/f
rame.htm
in particular slides 4-14.  The notes section should also be read.

> Our environment is such that over the years, folks have created a 
> bunch of command files and udc's at the system level that 
> have become so engrained that the users actually think they 
> are operating system commands.

With care I would guess that most of these UDCs could easily be
converted to command files with a noticeable reduction in logon time.

> I know from past CRUG 
> (Chicago Regional User Group) meetings that udc/command files 
> can be your friend, and can also be abused and add lots of 
> overhead to the system.  We are a very heavy batch 
> environment, and also over 1000 accounts.  During the day, an 
> analyst may need to do a hello command up to 200 times.  
> Since we just implemented security, it's like they are now 
> counting key strokes.  I know you can go into mpex and do a 
> chlogon to a different group and account without being asked 
> a password again.  

MPE/iX has the CHGROUP command but this does not let you change
accounts. However, it will log you into the target group and perform all
of the accounting as if you had logged off and back on.

The POSIX shell and the CI also support a "change directory", CD,
command. This command merely moves your current location in the
directory to a different location.

> We have not assessed how these other 
> command files would work given this method.  We will probably 
> have to assess it at some time, I'm sure we will be asked if 
> there are ways to not have to enter the password so much.  

An advantage of UDCs is that the UDC file can be protected by a lockword
but the users do not need to supply the lockword in order to execute the
UDC. If a command file has a lockword then the user will be prompted for
the lockword before the file is executed.

> The savvy uses have all ready figured out how to map it to a 
> key combination with minisoft, so if you know their key map, 
> so much for security...

no comment... dangerous (ok, 1 comment).

> Just wanted to thank you all for your helpful information in 
> the past, and would like to know the values of your 
> hpcpumsecs variable, and any other helpful tidbits for 
> assessing udc/command file good/bad performance.

I don't think comparing initial values of HPCPUMSECS across different
systems will be useful.  Maybe this will provided better data:
  1) create a new user.acct with a typical mix of UDCs cataloged
  2) time (with a watch) how long it takes to logon from the time you
press <enter> after typing the HELLO command, to the time you see the CI
prompt
  3) un-catalog all of this user's UDCs.
  4) repeat 2) and compare.


Hope this provides a start,
 
 Jeff Vance, vCSY

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2