OSIsoft: PINet Automatic Startup. v2.2
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.