Let's enable the automatic
start-up of PINet with
VMS. We will do that by editing
the site specific start-up file for VMS which can be
found in the sys$manager directory.
Normally PINet is the last
thing started up. So we will jump down to the end of this
file. And you can see I have added the command in here
already. I was a good citizen and I put
in a comment that says what I was doing and the date and my initials
here so somebody knows who to ask or blame for this.
We are using a submit command.
The submit command allows us to run this in the background
so we do not hold up the start up and
hold up the ability to log into the machine for other applications.
Another advantage of using the submit command
is it allows us to delay the start up of
PINet and this may be important,
because the site specific start up
file executes in a different thread
for the VMS start up than things like the network and X Windows.
PINet depends on the network in X Windows, so it does not
make sense to start PINet until those other things are completed.
So by inserting a little delay here by about three minutes
to five minutes
on a VAX could be as little as 30 seconds or a minute
on an Alpha computer. This
delay here assures that the other thread of processing
where the network is gets done before the PINet attempts to start up.
What other options do I use here?
I ran this as a
user system. So the submit command allows me to control who runs this.
You need to be the system user of VMS, the administrator
to run this. And I have disabled printing
a trace of the execution of the start up file.
But I did enable
a bell character being sent to the console to let people know
PI was started up. And for troubleshooting purposes,
I kept the log of the start
up. The logs are being set to the sys$manager directory
Some system managers send this to the PINet
directory instead, it's your choice.
Be careful to ensure that you get the disk name for your
installation correctly. Our computer
has a disk called DKA300 where we installed
PINet. So I use this as the command to start up PINet.
You will also want to make sure that
PINet is automatically shut down whenever VMS is shut down.
We will accomplish this by editing
the site specific shut down procedure for VMS.
This is called SYShutdwn.com
and it's in the sys$manager directory.
In the same way that PINet was normally the last thing
that was started up, normally PINet is the first thing shut down.
So I will open up a couple of lines
here and as before I will put in some sort of
comment that says
stopping PINet
and put in the date.
My initials so somebody knows who to ask questions
to or blame if there is a problem with this.
And the command we are going to use is very simple.
We can use the PINet logical name because
the PINet logical name will be established because
PINet is running. On start up though we had to type in the fully qualified
path to the command file. But here
I can just use the PINet module name.
.com here at the end is optional.
One of the things that you will want to do is give some thought to the
behaviour of over-range and under-range on our PINet node.
The default is that there is no
over-range or under-range checking for snap shot values being written
to the PINet node. If you want to change that,
what you can do is edit this command file
that PINet comes with and set snap check
range. And if we type this out, we will see
that there is a symbol
here and a parameter passed to it.
You can see this is hard coded here. The reason why this is hard coded
is PINet runs this during the start up
each time. So if you want
to change the default behaviour from no range checking
to having range checking, you have got to
change this 0 to a 1 and save the file.
At that point then, whenever there is a put snap
snap for real tags, the values will be
checked against the configured range for the
point. And if the range is within the allowed range,
you will write a good value. And if the range is over or under,
then it will be recorded as a bad quality event instead.
PINet, like almost all pieces of software today,
as new versions come out and
so on, have small changes in their
resource requirements. By this I mean disk and memory
and other resources of the computer. We strongly
recommend that you document
the cost of a couple of system resources
as part of your installation and upgrade of
PINet that you monitor this over time so that you can be aware
of the creep in the cost of these resources.
In the PINet build directory,
there is a couple of executable programs that are
named PINet something.exe
and
there the global pages
program and the virtual page count program.
So what we recommend is that you run these
and document the settings
reported there and keep that in a safe place.
Most people have a log book that they keep with the
systems or perhaps a file folder that
contains notes and
significant events like upgrades and software installs-- that's where you want to keep this stuff.
What we can see here is the PINet
that we are running costs us 6403 global pages.
Yours will probably be
different than this. The cost of global pages for PINet
depends on a number of system variables, including
things like the license limit,
the tags and whether we are on VAX and Alpha and other things.
Also note here that depending on the interface, you may need additional
global pages. Here we see that our
system currently has 62,000 global pages
and that there are 21,000 free global pages.
So our system is pretty healthy in the global pages configuration area.
On a VAX, we recommend that you
have got 4000-6000 free global pages.
So after installing and running
PINet, if you do not have at least 4000 or 6000 global
pages, that's something you should probably address.
The other program,
monitors virtual page count,
and we see here that our PINet
node needs about 40,000 virtual pages.
Virtual pages are
the virtual memory needs by a program
or a process for its code and
data. The virtual page count will
vary from system to system. In older versions of
VMS, virtual page count corresponds directly to
a system parameter of the Operating
system that you can set. In newer versions of
VMS, this has been replaced by a couple of other parameters.
It turns out you can still set this in
ModParams.Dat and use AutoGen to configure
it and the system will figure out the differences here.
Typically
I try to use
the virtual page count parameter so that it
is large enough
and even larger than required. So I might have
set virtual page count on this machine to 70,000 pages instead of
the 40,000 that is asked for here. One thing to watch though
is your pagefile is large enough to accommodate
all the virtual memory that you are going to be asking for.