A question of migration.....

[Brian Reiter]

Hi Folks,

Just a request for some info.

Currently we develop 5 of our 6 VMS systems on a VMS 7-1-2 Alpha and run 3 of them on DS15s running VMS 7-3-2. The remaining system is developed on a DS10 under VMS 7-3-2 and runs on a DS15 under VMS 7-3-2. So far so good. Things do seem to work.

However, I've been asked to put together a case for retiring the 7-1-2 system and doing all the development on 1 or more DS10s (freed up during the roll-out of DS15s). This of course will cost money and we need to convince the customer that this is good business (as well as technical) sense.

The question is: is there any information regarding the benefits of developing on and running on VMS 7-3-2 which are hedged in a form which our customer (government based and not necessarily technically aware) will understand?

I can give a lot of technical reasons based on new features etc. but will always end up having to answer the question, if it aint broke why fix it?

Hope you can help



Brian

[Ian Miller.]

You could argue that V7.1-2 is no longer supported and therefore moving to a supported version would reduce risk.

The new features would allow the development of new business functionality.

I have found that VMS V7.3-2 is faster than V7.1 so system performance may be improved.

[Willem Grooters]

Additionally you could mention that 7.3-2 will be the "Landing zone" for 7.x and will enter "Previous Version Support", to be continued "until eternity". Another point might be that upgrade to the next version of VMS is easier. It gives them even more time and more facilities (at least, the developers and system managers) because the enhancements in DCL.



Good attitude, but: do they drive their cars until they fall apart?

[Brian Reiter]

Ian,

Fair point. However the systems in question are best described as soft-real time control systems. They aren't really business critical in the understood sense - but have to work.

What I am trying to do is get all the development onto 7-3-2 fairly soon before I have to consider the move to 8-2. I don't really want to migrate 5 systems to VMS 8-2 in one go.

The migration of the system developed under 7-3-2 to 8-2 (on Itanium) took about a day from initial re-compilation to full system startup. So I'm happy that the effort at that point is minimal.


cheers

Brian

[Brian Reiter]

Willem,

Being able to test the new features on the development machine (DCL or system services) will be a bonus. At the moment engineers need to find spare production units to test on.

A performance increase (going to new hardware and OS) is one selling point. A build which took 2 hours to complete is now done in 10 minutes (60+ exes).

Hmmm food for thought anyway.

[Willem Grooters]

Brian,
You don't have to do two things (7.3-2 -> 8.2 and Alpha -> Itanium) in one go. You can go for 8.2 on Alpha first and when you're happy with that, migrate to Itanium - officialy AXP is to be supprted until 2011 - 2012 but my (and other's) guess it will extent beyond that timeframe ;-)

Willem

[Brian Reiter]

Hi Willem,

I'm already proposing that as a solution. 7-1-2 > 7-3-2 > 8-2 (Alpha) with the jump from 7-1-2 > 7-3-2 being the biggest problem. 7-3-2 to 8-2 (Alpha or Itanium has been easy so far).

cheers

Brian

[comarow]

There are several points to bring out.

Maintenance costs on new systems are much cheaper. Old systems keep going up.

7.3-2 has XFC which is a great file caching program which really helps I/O.

Good luck.

[Camiel]

Keeping track of patches, ECO's etc. is a lot easier when all your systems arfe running the same version.

Camiel.

[Brian Reiter]

True, but our IT department have zero interest in doing that.....

Its down to the individual engineers (OK me) to keep the systems up to date.

[Willem Grooters]

Depends on your position ;-) but if these engineers know what they're doing, it should be Ok.
But some care should be taken. Don't let them run free! The systems where software maintenance is done should at the same OS level, or LOWER, than production systems the software will run on. That may include patches within the system or layered products (think about libraries and shared images) but in most cases, these are no problem.
Thoughtless update to a higher OS version, and, in some cases, higher versions of layeered products like TCPIP can cause serious trouble if production systems ar NOT upgraded.
Someone has to keep things organized ;-)

[Brian Reiter]

Still me :) So far no problems have occurred and I always trial patches etc. on a spare system for a couple of weeks before even thinking about upgrading the other spares and the live systems (scattered round the UK). This can take several weeks to organise. I don't really want a trip to SW England to undo a patch upgrade :)

cheers

Brian

[Andy Bustamante]

>> I don't really want a trip to SW England to undo a patch upgrade :)

One of the nice 7.3-2 features is the added save/undo functionality for patch change control.

There are are some feature updates, including ssh and ssl which I used as selling points to get my last customer to make the upgrade to 7.3-2.

You also upgrade the the systems very easily (7.1-2 to 7.2x to 7.3-2). As previousily pointed out, 7.3-2 is the landing zone and will stay in extended support as the last version 7 release.


Andy

[Hein van den Heuvel]

You did not give us much chance to help.
It the currently solution really runnng just fine, or could it use a little more performance? Is it running nice and stable, or is there any flakyness?
Storage adequatly sized & performing well?

How about a hint as to what the application does?
- web serving? Email? Heavy tcp usage?
- interactive, batch or mix?
- RMS, RDB, Oracle?


My main arguments would be:
- supportability
- XFC: major IO performance enhancements, major reporting potential.
- RMS: 1) Global buffers 1A) hash lookups allowing many more without contention 1B) concurrent read locking for still more concurrency. 2) NQL --> avoid record locking where possible. 3) Directory caching
- ODS5 ssupport.
- TCP stack improvements (more concurrency)
- ...

hth,
Hein.

[Brian Reiter]

Hein

The application(s) (4 different systems - working co-operatively) are soft real-time control systems. Communication between the systems and the controlling PC based operator interfaces is TCP/IP. The main system runs 120 cooperating processes to manage all this, all task communication is via mailboxes. The smaller systems run betwen 12 and 50 processes, again communicating via mailboxes.

The main driving factor behind the upgrade is to make my life easier :) and make use of the new features of the system, as well as allowing us to adapt to new methods. As yet there is no RDB or WebServer, but that is about to change.

Any more info - let me know :)


Regards

Brian

[Hein van den Heuvel]

Ah, so filesystem and IO improvements are not so important.
Improving scaling/concurrency has been a focus of vms engineer over the past several versions, but that's really mostly critical with larger SMP systems which is not your case
- tcp/ip stack using multiple (spin)locks instead of just 1
- mailbox io using per mailbox lock, instead of one for all

Your arguments are already valid, but I'm afraid i personally can not add to them. Someone else?

Hein.