VMS 7.2-1 Upgrading TCPIP

[Surya Rao]

Hi,

I have VMS 7.1 and am upgrading to 7.2-1. Have procured the CD and it comes with TCPIP 5.0a. Now I need to upgrade TCPIP to 5.1.

I found below patch where it says OLD PRODUCT is 5.1 and NEW PRODUCT is 5.1 ECO5

So does this mean I can't apply this patch to TCPIP 5.0a?



ECO NUMBER: TCPIPALP_E05A51
-----------
KIT NAME: DEC-AXPVMS-TCPIP_ECO-V0501-155-4
---------
OLD PRODUCT: Compaq TCP/IP Services for OpenVMS Alpha 5.1
------------
NEW PRODUCT: Compaq TCP/IP Services for OpenVMS Alpha 5.1 ECO 5



If so, where can I find patch to upgrade from 5.0a to 5.1? I've searched as best as I could and had no luck. PLease advise

Surya

[Uwe Zessin · Accepted solution]

Surya,

I am afraid that you need to get a complete TCPIP V5.1 kit, first. It is on the OpenVMS V7.3 operating system CD-ROM, for example. Then you can upgrade from V5.0a to V5.1 and finally patch it up to V5.1 ECO 5. As far as I can tell such version jumps were never available as patches for TCPIP.

[Lokesh_2]

Hi Surya,

I agree with Uwe. Contact your HP support representative for this.

Thanks & regards,
Lokesh Jain

[Brad McCusker]

Are you aware that V7.2-1 is no longer supported?

V7.2-2 will be supported until June 2004.

So long as you are going through the work of upgrading, have you considered upgrading to a supported version (e.g. V7.3-2)

[Martin P.J. Zinser]

Hello Surya,

you first need a 5.1 kit before you can upgrade to ECO 5. This will be part of any reasonably old OS or CSLG distribution. I >>might<< have one of these at home. If you run out of luck contact me privatly at zinser@zinser.no-ip.info and we should be able to work out something.

I do second Brads suggestion to at least upgrade to 7.2-2 (which is essentially a roll-up of all the 7.2-1 ECOs with addtional QA applied). If your apps are qualified for 7.2-1 there should be no issue going to 7.2-2 . Obviously 7.3-1/2 would give you even more breathing room until the next upgrade is required.

Greetings, Martin

[Surya Rao]

Hi All,

Thanks for the quick and excellent replies. Yes, I've decided to move to VMS 7.3-2 which would cover the TCPIP 5.1 which is what I need. Thanks again!

Surya

[Surya Rao]

Hi,

On second thought, I have some concerns. Mine is a VMS 7.1 cluster (2 nodes) on Alpha 2100. I already have 2 other systems running a cluster on VMS 7.2-1 and they are stable.

I am paranoid if the new version 7.3-2 would introduce new issues with clustering. ANyone have a cluster working fine with 7.3-2?

Any idea how long 7.3-2 has been around for?

Surya
=====

[Martin P.J. Zinser]

Hello Surya,

classical answer: Depends on ;-) First shipment of 7.3-2 is about 6 months, serious exposure to users in my opinion rathe something like 3 months. Our production clusters are still all at 7.3-1, but otoh our shop is very conservative. I do have 7.3-2 on my system at home (right now under my desk) and do have no complaints. Also the number of ECOs against 7.3-2 (and TCP/IP 5.4 that goes with it) is pretty low (I would install UPD 1).

Greetings, Martin

[Surya Rao]

Hi Martin,

OK, thanks. So it would seem safe enough to go for 7.3-2 with the updates applied, (I guess). I am planning to apply all the critical patches and updates (not too many of them for 7.3-2)

Just to clarify my background. we have a powerful Sun Solaris system running Oracle and the Solaris system sends/receives files from the afore mentioned VMS system using RCP. The VMS system is in fact just used for that! Just to send and receive files to/from the Sun system. The VMS system is a sort of a gateway from where OTHER more critical VMS systems (about 6 of them) access the files which were copied from the Sun System. The VMS system holds the files in its own disks and the other critical VMS systems access these files by their own logicals pointing to my VMS system via DecNet Phase IV.

The problem we have now is that with VMS 7.1 we have UCX 4.1 and we see very slow file transfer performance and also occasional RCP failures. That is in fact the only reason we are upgrading to a higher version. So my area of expertise is more with the Oracle and Solaris though I've been administering the VMS system for the past several years (even done an earlier upgrade on it from 6.2 to 7.1).

Any thoughts you'd like to share based on above info?

Surya

Thanks!
Surya

[Surya Rao]

Hi,

One more issue. I just found that I can't upgrade directly from 7.1 to 7.3-2. I would need to first upgrade to either 7.2-2 or 7.3 and then to 7.3-2.

So makes it more complicated.

So based on my above usage of the system and the concerns I mentioned, please suggest what I should do.

Also my VMS 7.1 system has UCX 4.1 ECO9. So if I upgrade it to 7.2-2 and then to 7.3-2 do I need to upgrade TCPIP separately for each of the above upgrade steps or it would be taken care of as part of the layered product upgrades?

Surya
=====

[Martin P.J. Zinser]

Hello Surya,

you will be asked if you want to upgrade to TCP/IP 5.4 during the 7.3-2 installation. They will also try to convice you to "upgrade" to
DECnet Plus. You do not need to do this. Decline to install Phase V and the next question will be to install Phase IV.

Greetings, Martin

[Uwe Zessin]

Surya,

when I upgraded to VMS V7.2-1 a long time ago the procedure automatically migrated from UCX to TCPIP. It looked a bit strange, if I recall, because there was some 'transitional kit' involved, but in the end it went almost smooth (there was a problem with a token ring card, but that is another story).

The last weekend I have upgraded a cluster from V7.2-1 to V7.3-2. Most things went smooth again - we only had to raise some system parameters.

We also upgraded to newer compilers and the owner recompiled his software. He was really amazed about the speed! The XFC (eXtended File Cache) used 200 MBytes of 512 MBytes main memory and the compiles and links went almost instantaneous on the otherwise idle system.

I strongly recommend that you make a backup of the system disk and be prepared to revert to the old system in case there are problems you can not fix in time.

[Ian Miller.]

When you upgrade to VMS V7.2-2 the process will upgrade UCX to V5.x and ask about DECnet-Plus (DECnet Phase V). Then you upgrade to VMS V7.3-2 and it will upgrade TCPIP again, this time to to V5.4.

Then you will apply patches (a couple for VMS and one for TCPIP). Remember to allow time for pre upgrade backup and parhaps backups at keypoints along the way.

[Jan van den Ende]

Surya (and everyone else interested):

be prepared for a "little" side effect of a 7.2(x) or earlier VMS upgrade to 7.3 or later:
User accounts that actually used most of their allowed BYTLM and/or PGFL quota might fail with INSVIRMEM in their more demanding apps.
General solution: just double or quadruple them in SYSUAF. At current going physical memory sizes the extra overhead is not even noticeable.
You MAY have issues with detached processes that get started specifying their own params, bypassing SYSUAF. You may need to adapt THOSE.
We ran into that issue wit SYBASE OmniConnect, which actually specifies these params in an (as far as I know) undocumented file, and uses THOSE.

Bottom line: INSVIRMEM? then look into BYTLM & PGFLQUO

hth,


Jan

[Uwe Zessin]

BYTLM too small can cause SS$_INSVIRMEM? Are you sure? I thought the usual symptom is I/Os failing or processes ending up in MUTEX wait state...

[Jan van den Ende]

Uwe,

you're right.
I'm doing this from memory (at home), and I mixed up two things. Too little BYTLM generated MUTEX hang.

Someone know how to get a bio-memory upgrade?

:-(

Jan

[Uwe Zessin]

Me too! Me too!
I have lots of documentation that I like to just 'slurp in' and be done with.

[Surya Rao]

Hi All,

Thanks for all the responses. Now I have one last question and advice to ask before I can close this thread.

Once I upgrade VMS, an AUTOGEN needs to be done. For my current system I have a very old MODPARAMS.DAT which has not been updated for quite some time. Hence I am not even sure if it is in sync with the SYSGEN or not.

So what is the recommended approach to do AUTOGEN on such a system?

Also I understand that I have to subject my system to intensive application usage so that the AUTOGEN can generate proper recommendations for value changes. I can do simulate application usage on my testbeds only. so how do I use this to generate a MODPARAMS.DAT for my live system?

Please advice.

surya
=====

[Jan van den Ende]

Surya:

AFAIK, you will have to do your MODPARAMS checking 'by hand'.
Print out your modparams, and activate SYSGEN

USE CURRENT

and SHOW every param that is mentioned in MODPARAMS.
If you use any AGEN$INCLUDE_FILE, then act like you are processing them (work though them at the point where called). If AUTOGEN meets the same param multiple times, only the last time is used.
If needed, increase your MODPARAMS values.
Then, the upgrade also creates a new MODPARAMS, it includes the existing MODPARAMS, and then adds MIN_ where needed.
This SHOULD get you pretty safe (as long as your MODPARAMS is good, but that is what you were going to check.

So:

Success, & enjoy.

Jan

[Surya Rao]

Hi Jan,

Understood the part of checking MODPARAMS with current SYSGEN. You mentioned increasing MODPARAMS if necessary. How can I decide which ones to increase and to what value? (ps: I've not used AUTOGEN much and though I've read the manuals I am looking for some real life tips on how to use it)

You also said the upgrade also includes MIN_

[Jan van den Ende]

Surya,

when comparing SYSGEN & MODPARAMS values,
if SYSGEN > MODPARAMS then replace (by editor) in MODPARAMS.

(perhaps you can first run AUTOGEN with P1 = SAVPARAMS & P2 = GENPARAMS, then you get a AGEN$PARAMS.REPORT file in SYS$SYSTEM.
This at least shows you every parameter that it encountered more than once -> you ignore all but the last time.)

Yes, the MIN_ (and Maybe MAX_ also, allthough I don't remember any) are added at the bottom. Doing a DIFFERENCE will only be confusing, just read the result file and you 'll know why: it is already much more readable then any diff I ever saw.

(I'm not saying you should, but:) we run (at EACH cluster-node) a batch every week that does @AUTOGEN SAVPARAMS TESTFILES.

Then read the AGEN$REPORT, and if some 'serious' reason pops up, only THEN we plan & execute AUTOGEN including setting params & reboot.

Doing a system stress & AUTOGEN shortly after the upgrade probably WILL help you to a very reasonable setup.

hth,

Jan

[Surya Rao]

Thanks to all.

we've done the upgrade on our testbed.

please see the background of my application as I mentioned in my update of Mar 10, 2004 03:02:40 GMT

Now the rcp's and ftp's are FOUR times faster.

But Now, the rcp's and rsh's from the UNIX box to the VMX box fail randomly with this message

Protocol error, XXXX closed connection

where XXXX is my VMS host name. this error is received when I do CONCURRENT rcp's from multiple UNIX sessions to the VMX box

My network engineers say they can't see any errors in the network links or routers. so what should I do now?

HP says it can't help me unless I upgrade to a supported version which is VMS 7.3

I am really in a fix!

Please suggest what could cause this error and has anyone seen it happen. The key thing to note is that it happens when MULTIPLE rcp's are running. some may go through and some may give this error.

driving me nuts! as I am not getting any help from either HP or my ESTEEMED network professionals....and VMS is not my area of expertise.

surya