HP3000-L Archives

March 1998, 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:
Scott Mcclellan <[log in to unmask]>
Reply To:
Date:
Wed, 11 Mar 1998 16:33:47 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (189 lines)
> Date:          Tue, 10 Mar 1998 11:13:15 -0800
> Reply-to:      Jeff Vance <[log in to unmask]>
> From:          Jeff Vance <[log in to unmask]>
> Subject:       Re: version.pub.sys limited?
> To:            [log in to unmask]

[stuff deleted...]
> There is a freeware VERSION on jazz that bumps up the 100 limit imposed
> by the program.
Then new limit for VERION is 1000. That is VERSION.PUB.SYS was
changed to be able to display version strings for up to 1000 SOMs
within a single executable file (or library).

I don't know why the limit was 100 originally. I did verify that the
MPE/iX LOADER thinks the limit on the number of SOMs per executable
(library) is 1000. I did not have access to the Linkeditor source to
verify the limit there (hopefully the same).

NOTE: Just because I set the new limit in VERSION to be 1000, does
not mean that I think putting 1000 SOMs in one library is a "good
idea". As Stan menition "intra-SOM" procedure calls are less
expensive than "inter-SOM" procedure calls. I believe that
"inter-SOM" procedure calls equivalent to "inter-Library" procedure
calls with respect to the number of instructions. So if I truly had
1000's of executables, I would tend to favor linking separate
executables into a single SOM, and/or splitting up stuff into
separate libraies (grouped in some logical manner). I would not tend
to dump everything into a single library. Among the reasons to not do
that is the fact that if anything in the library is loaded, you can't
modify the contents of the library.

> Scott McClellan gets the credit.  See
>    jazz.external.hp.com/src/src.html  under "misc".

Technically, VERSION.PUB.SYS is one of the files included in SYSFILEP
and therefore one of the files that is on a CSLT tape. This would
imply that the standard way to replace the file is to create an SLT
with the new version of VERSION.PUB.SYS (using SYSGEN), and to UPDATE
the system with the CSLT tape. A couple of you said they would not
want to UPDATE just to put on a new version of VERSION.

There are alternatives to doing an UPDATE. One alternative would be
to just rename VERSION.PUB.SYS to some save location, and rename the
new version downloaded off the net to VERSION.PUB.SYS. There are
potential problems with this approach. Specifically, if you do not
take special precautions to insure that the new version of VERSION is
restricted to LDEV 1 then most likely it will not be entirely on LDEV
1. The net effect of this is that, down the road, if you do another
UPDATE for some reason then the UPDATE utility will not be able to
delete VERSION.PUB.SYS and will complain about this fact. UPDATE will
remove the old entry in the directory for VERSION.PUB.SYS, but will
not be able to release the disk space (as it is not on LDEV 1 and
UPDATE only has access to LDEV 1). As a result the disk space
associated with VERSION.PUB.SYS will be "lost" (wasted) until the
system manager runs FSCHECK to recover it.

The above problems could be avoided (with file equations etc.), but
that would prevent me from using this as an opportunity to show-off
what Stage/iX can do. :-)

Basically, the Stage/iX facility, which is part of FOS as of release
5.5 is capable of replacing any system file(s) with a single reboot,
without using any tapes. The old versions of the files are
automatically archived, and the system can be put back into its
original state with a simple reboot (no UPDATE or tapes necessary).
Stage/iX is primarily intended to be used by Patch/iX when patching
the system, but all of the stuff below is docmented and as such is a
legitimate usage of Stage/iX.

The basic steps you would follow woudl be:

* Download VERSION from Jazz
* Uncompress the file and put the uncompressed verrion of VERSION
somewhere convenient (like VERSION.TEMP.SYS).
* Use the Stage/iX staging area management utility, STAGEMAN.PUB.SYS,
to create a staging area, to put the new version of VERSION into that
staging area, and to set the default for the next boot to be the
newly created staging area.
* At some convenient time, simply reboot the system. The system will
automatically boot from the staging area indicated. The new version
of VERSION will be "installed" into .PUB.SYS. The old version of
VERSION will be "archived" and can be "re-installed" with a simple
reboot.

To use Stage/iX you will simply have to use a few STAGEMAN commands.
All of these commands are documented in detail in the STAGEMAN online
help facility.

* INIT. This command initializes the STAGE/iX facility. This is not
necessary if Stage/iX is already initialized, but doing an 'init' is
not harmful in any case.
* CREATE. This will create the new staging area.
* EXPERT. This will put STAGEMAN into "expert mode" which is
necessary to alter the contents of a staging area. You will be adding
a file to the staging area below. NOTE: the prompt changes when
you are in "expert mode" from "STAGEMAN>" to "STAGEMAN$".
* STAGEFILE. This command is used to put the new version of VERSION
into the staging area. NOTE: read the online help for this command
carefully. The file names are case sensitive if you use HFS file
name.
* COMPLETE. This command will indicate that you finished modifying
the staging area. * VALIDATE. This command will "validate"
the staging area. Staging areas must be marked as "valid" before you
can boot from them.
* SET. This command will set the default for the next boot to be the
staging area you just created.

Some other useful commands:

* STATUS. To show the current status of Stage/ix. Is it initialized?
What staging area was the sytem last booted from? What staging area
will be used for the next boot?
* LIST. To display the staging areas and their contents.
* LOG. Which was used to log the output of the STAGEMAN session below
to a file so that I could post it to this list.
* CHANGE. Which can be used to rename a staging area or to change the
"description" associcated with a staging area.

The following text is the output from STAGEMAN when I create a
staging area and put the new version of VERION into it on my system.
The new version of VERSION was called VERSION.TEMP.SYS. The staging
area I created was called "version_stage". NOTE: staging area names
are cases sensitive.

------------- OUTPUT FROM STAGEMAN. ---------------------------

STAGEMAN> init
Successfully initialized the HP Stage/iX environment.
STAGEMAN> list
*Warning: No staging areas exist. (STAGEMAN 1016)
STAGEMAN> create version_stage
Successfully created staging area "version_stage".
STAGEMAN> list

STAGING AREA NAME   MOD DATE  V  DESCRIPTION
------- ---- -----  --------  -  ----------------------------------------------
version_stage       03/10/98  I

STAGEMAN> change version_stage;desc="This staging area will contain the new vers
ion of VERSION.PUB.SYS"
Successfully changed staging area "version_stage".
STAGEMAN> list

STAGING AREA NAME   MOD DATE  V  DESCRIPTION
------- ---- -----  --------  -  ----------------------------------------------
version_stage       03/10/98  I  This staging area will contain the new
                                 version of VERSION.PUB.SYS

STAGEMAN> expert on
STAGEMAN$ sf version_stage version.abuild00.scott, VERSION.PUB.SYS
Staging file "version.temp.sys" as "VERSION.PUB.SYS"...
Successfully staged file "version.temp.sys" to staging area
"version_stage ".
STAGEMAN$ list version_stage;files

STAGING AREA NAME   MOD DATE  V  DESCRIPTION
------- ---- -----  --------  -  ----------------------------------------------
version_stage       03/10/98  I  This staging area will contain the new
                                 version of VERSION.PUB.SYS

  ** FILE INFO FOR "version_stage":

  FILE NAME                           REST    DISP  FCODE  EOF       LIMIT
  ----------------------------------  ------  ----  -----  --------  ----------
  VERSION.PUB.SYS                     LDEV1   REPL  NMPRG       154         154

  *** NUMBER OF FILES IN "version_stage": 1


STAGEMAN$ complete version_stage
Staging area "version_stage" marked as complete.
STAGEMAN$ validate version_stage
Successfully validated staging area "version_stage".
STAGEMAN$ set stage=version_stage
Set staging area for next boot to "version_stage".
STAGEMAN$ exit

                                 Scott McClellan
     ___   ___   _________       Hewlett-Packard
    /_ /| /_ /| /_______ /|      Commercial Systems Division
   |##| | ##| ||########| |      19447 Pruneridge Ave
   |##| |_##| ||##| |_##| |      Cupertino, CA
   |##|/__##| ||##|/__##| |
   |########| ||########|/       E Mail: [log in to unmask]
   |##| | ##| ||##| |            Phone : (919) 969-7870
   |##| | ##| ||##| |            Fax   : (919) 969-7871
   |##| | ##|/ |##|/
    --    --    --               Voice Mail : 447-6067

ATOM RSS1 RSS2