HP3000-L Archives

August 2001, 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:
"HOFMEISTER,JAMES (HP-USA,ex1)" <[log in to unmask]>
Reply To:
HOFMEISTER,JAMES (HP-USA,ex1)
Date:
Mon, 13 Aug 2001 01:14:30 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (160 lines)
Hello folks @ 3000-l,

Re: Telnet/Network Question (way off topic from the original post)...

----------------------------------------------------Ken Sletten writes--
....  so we've got the newer 6.5 versions just where James indicated.

....  But:  As y'all can see we also still have the old versions hanging
around in NSRV0000.  I suppose there are arguments either way for this,
but at least from our perspective in most if not all cases for SYS,
TELESUP, and other HP accounts we would prefer that when programs like
above are "moved" by an update, that it really is done as a MOVE;
i.e.:  The old versions "become disappeared" as part of the update
process...
------------------------------------------------------------------------

I have heard several arguments on this point... and I am a bit out of my
focus as I am a network guy... but... in a past life as a system manager
for multiple machines I can give you my procedures & my 2 cents.

One of the difficulties one runs into with purging old copies of files
is that when removing a file you might break an existing application
which relies on that file/program existing in that specific location, or
you might purge a customer program or data file erroneously created with
that name or in a wrong group.

I think it would be cool for the update process to start by performing
a :purge @[log in to unmask], @[log in to unmask], @[log in to unmask], @[log in to unmask], (minus specific
configuration files), but more than once I have seen a file called
PAYROLL.PUB.SYS and thought a more conservative approach is best.

Another of the difficulties is the only current means to purge a file in
the patch process is to implement a "IFH" file.  Once a patch includes
an "IHF" file it can be installed with Autopat and Patch/iX but it can
not be installed with Stage/iX.  As far is deleting files in the update
process, the same risk as described above plus adding additional
complexity to the update process.   Note: When a file is "moved", it
almost always first done in a patch and then rolled into a future
release.

In the past I walked 2 miles up hill in the snow (opp's wrong story). In
the past, prior to performing an update on my test machines I would start
by cleaning up the machine by performing a store of @[log in to unmask], @[log in to unmask]
and @[log in to unmask] and then any other accounts built by HP install routines
and then I would selectively purge the files in most of these accounts
and as in the case of SYS I would selectively purge the files in most of
the groups (not PUB).  Note:  This is even easier today with
Store-To-Disk.

Upon performing an update the necessary files for the current O.S.
release would be restored to the correct HP accounts and groups by the
HP install routines and the files no longer needed have been purged by
the earlier cleanup.

I also evaluated the files in PUB.SYS after the update and compared the
listf to the list of files on the tapes and determined if any files
could be individually purged.  Note: One of the tricks I use to avoid
corrupting files or leaving junk in PUB.SYS with the MANAGER.SYS logon
is to build a WORK group, home MANAGER.SYS to WORK and password the
group PUB.

I then would build the tapes for my other production systems from this
system after I had run for a few weeks and had a chance to verify
operation of any of the tools used on the past release.

Now in the future (moved to Atlanta where it never snows) one method I
have tried is as part of the update procedure... is to perform an
install (reload) off of the SLT created by the update process and then
allow the remaining update process to reinstall all of the FOS/Subsys.
Once the system is back up I restore all of my applications.  Yes, I
know this may not sound realistic for the typical production shop (keep
in mind my logon banner says "Data loaded on this machine is *NOT*
backed up and is purged on sight!" followed by the warning
"Unauthorized use is prohibited by law and people with sticks").. but
even so, this is one possible solution for smaller machines.

Another trick I use today with my diagnostic systems is I have a group
of programs that I point to with the "newlink".  These are typically
tools that I use that are part of TELESUP or installed by patches.
Having all of my "links" to tools which are possibly O.S. specific in a
single group gives me a easy identified list of programs that need to be
checked out on when a new O.S. release is installed.

For the programs that I pickup that are "unsupported freeware" I take
ownership of them by moving them to a MYTOOLS group and once again I
have an easy identified list of programs that need to be checked out
when a new O.S. release is installed.

Oh, and one other trick is since I now have a bunch of tools in
different groups/accounts... I modified my HPPATH to include the groups
that I store my utilities in:

:showvar hppath
HPPATH = !HPGROUP,PUB,PUB.SYS,ARPA.SYS,NET.SYS,LINKS.SYS,NETTOOLS.SYS,
SYSTOOLS.SYS

----------------------------------------------------Ken Sletten writes--
SIDEBAR hmmm...:  ABORTCON and SHOWCONN are in PRVXL.TELESUP.  FSCHECK &
etc. are in MPEXL.TELESUP...  Was there / is there any rhyme or reason
why HP puts some programs in PRVXL or MPEXL.TELESUP;  other than (I
thought) that PRIV mode programs were generally supposed to go in
PRVXL ??.....   I don't even have to run ACAP to know that FSCHECK has
PM....
------------------------------------------------------------------------

Sorry, I can't help much here... I use PUBXL.TELESUP (for programs),
PRIVXL.TELESUP (for priv programs), DOCXL.TELESUP (for documentation).
We don't use "MPEXL.TELESUP" for network tools.

I hope this helps.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.



























Regards,

     _/       James Hofmeister  WCSO SSD - WW Network Tech Expert Center
    _/              Mail        2124 Barrett Park Drive Suite B. M/S F2
   _/_/_/  _/_/_/               Kennesaw, GA   30144   U.S.A.
  _/  _/  _/  _/    Phone/Fax   Telnet (770) 795-6426  /  (770) 795-5707
 _/  _/  _/_/_/     E-Mail      [log in to unmask]
       _/           Web         http://wtec.cup.hp.com/~netmpe/
                    VRC Chat    musketeer_mpenet

Joined EC_NET_MPE Musketeer ?
check out  http://wtec.cup.hp.com/~netmpe/documents/musketeer.htm

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

ATOM RSS1 RSS2