UNIX to OpenVMS guidelines

[rbhagwat]

I am porting a big piece of software from UNIX to OpenVMS. I am totally lost in this and help would be much appreciated.
1. For a total novice to OpenVMS, but an ok
experience with UNIX, how much time would it
take to port a complex UNIX software
involving client-server, process
synchronization, file access etc.
2. Are we supposed to use GNV or not. It looks
half cooked.
3. I am going back and forth between OpenVMS
manual, GNV porting manuals etc. Is there
any correct sequence to tackle this ?

Thanks,
Rahul

[Hein van den Heuvel]

Welcome to the OpenVMS ITRC forum.

Congrats on the assignment and I hope you will have a successful port. Myself and many other participants here really love to see new application.

I'm worried though. While meaning no disrespect at all to you and your skills, WHY would anyone choose an OpenVMS novice for this task unless they kind of want it to fail?!

Surely solid knowledge of the target platform is much more important than any knowledge of the source. An intelligent engineer can typically figure out what something existing is doing and how on just any source platform.

But to select the best target implementation really requires a good bit of up front experience.

I have to question the management decision to select you for the job, again no disrespect intended.

Would you happen to be able to explain WHY this is ported to OpenVMS? That may also help guide you to the right 'how'.

>> how much time would it
take to port a complex UNIX software
involving client-server, process
synchronization, file access etc.

5 times longer than estimated.

>> 2. Are we supposed to use GNV

This is NOT an all or nothing decision.
You can opt to try port some (bash?) scripts to gnv, and recode other tasks as DCL procedures.

It also depends on whether the focus/bulk of the works is in (C ?) program and file code or shell scripts and such.

With a lot of hand waving, I would suggest the more code focus, the less relevant GNV is as just the C language libraries will offer many functions close to the unix ones.

3> I am going back and forth between OpenVMS manual, GNV porting manuals, Is there any correct sequence to tackle this ?

I would suggest one needs to first and foremost learn the OpenVMS architecture and approaches, and would encourage you to somehow engage someone with prior experience.

Best of luck!
Hein

[Steven Schweda]

> [...] how much time would it take [...]

It depends. We non-psychics have
approximately no idea what kinds of things
this "big piece of software" actually does.
Or how big "big" is.

> 2. Are we supposed to use GNV or not. It
> looks half cooked.

It depends. I tend to avoid it, but I also
tend to avoid very large projects. It may be
helpful, or it may just waste your time.

> [...] Is there any correct sequence to
> tackle this ?

Probably not, but it depends.

In some cases, it may be easier and/or better
to try to create a new VMS development
environment, but if GNV works on your code,
then using it could save much time and
effort. If the code does many things in a
UNIX way, and VMS doesn't have the required
C run-time features, then it may be a big job
no matter how you approach it.

[John Gillings]

Rahul,

The most important thing to remember, and keep reminding yourself.

OpenVMS is NOT Unix and Unix is NOT OpenVMS

Just because they're different doesn't necessarily mean one or the other is better or worse. They're just different. Accept this so you're not constantly going against the grain.

Lots of questions:

Why are you doing it?
What are your goals in doing the port?
What do you hope to improve by porting OpenVMS?
Are you intending, or hoping, to maintain common source between the two (or more?) environments?

One approach is to drop all the Unix sources into GNV and run it on OpenVMS as if it were just another Unix system. This may be the easiest path (or not), but what would be the point?

On the other hand, exploiting OpenVMS features may involve more changes, or even some fairly fundamental redesign, but the final result may be a better product (possibly faster, more resiliant, more scalable etc...)

[rbhagwat]

Thanks for your replies. I will answer in
reverse order. First Johns post

Rahul,

Lots of questions:

Why are you doing it?
-> We have to port a commercial backup software to add to it's product portfolio.
What are your goals in doing the port?
-> The goal is to have atleast a prototype
working on OpenVMS. This involves learning
OpenVMS, differences with UNIX, translate
the build structure to OpenVMS, develop an
installation package.
What do you hope to improve by porting OpenVMS?
-> As it is a commercial software, the hope
is to reach more wider customer base.
Are you intending, or hoping, to maintain common source between the two (or more?) environments?
-> Yes, as much as possible, we need a common
source base.

One approach is to drop all the Unix sources into GNV and run it on OpenVMS as if it were just another Unix system. This may be the easiest path (or not), but what would be the point?
-> This does not seem very easy either. As
an example, I am stuck as of now in finding
where longlong_t is (inttypes.h given by GNV
does not seem to have it).

On the other hand, exploiting OpenVMS features may involve more changes, or even some fairly fundamental redesign, but the final result may be a better product (possibly faster, more resiliant, more scalable etc...)
-> This seems ideal. Any pointers for this.
Do I need to first learn OpenVMS programming
manual completely ?

[Jeremy Begg]

You should probably read the OpenVMS Programming Concepts Manual as it describes a lot of the OpenVMS system interfaces.

Given your application is for doing backups, you had better read up on the OpenVMS filesystem too. The OpenVMS System Manager's Manual and the Guide to OpenVMS File Applications would be a reasonable place to start.

The OpenVMS filesystem is very different to UNIX and any backup application has to be able to preserve a multitude of file characteristics.

So I think you're going to have to do a fair bit of code customisation.

Regards,
Jeremy Begg

[Steven Schweda]

> The OpenVMS filesystem is very different to
> UNIX and any backup application has to be
> able to preserve a multitude of file
> characteristics.

This is pretty fundamental. Many normal
applications can be ported to VMS without
worrying about most of the file system
details, but backup software is in a
different category. Basic sequential file
I/O is one thing, but dealing with every
possible VMS file organization and record
format is not something which generic
UNIX-style I/O will be able to do.

To get a rough idea of what needs to be done,
you might look at the VMS-specific code in
the Info-ZIP Zip and UnZip programs. I'd
guess that your big problems would not be in
the client-server communication, but in
dealing with all the characteristics in file
systems which differ so greatly from any
normal UNIX file system. Not a trivial task,
especially for a newcomer.

[Shriniketan Bhagwat]

Hi,

Please refer the below link for UNIX, Linux to OpenVMS Porting Guidelines Document. May be help full.

http://h71000.www7.hp.com/portability/index.html

Regards,
Ketan

[Robert Gezelter]

Rahul,

Welcome to the OpenVMS ITRC Forum!

I agree wholeheartedly with John's comment that "OpenVMS is not UNIX; and UNIX is not OpenVMS". In many ways, they do equivalent things, but equivalent does not mean "in the same way". Backup utilities in particular need to consider precise details of the underlying system, particularly the file system.

Some things port more directly than others. I have moved very large applications codes from one platform to another with few changes. I have seen other code bases where the state of affairs was not so convenient. In those cases, pervasive presumptions about the host platform required multitudes of changes and rewrites. Without reviewing the code in question, there is no way to know the state of the underlying UNIX implementation in this respect.

I would also second Hein's suggestion to retain good expertise in OpenVMS. [Disclosure: we provide consulting services in this area, as do others who contribute to this forum.] It is an almost academic point, but in 30+ years of porting software between multiple platforms, I have seen far more successful outcomes when those doing the port understood the target platform well than when they were unfamiliar with the target platform. Some UNIX techniques simply translate poorly to OpenVMS, and vice versa; others are easily dealt with.

- Bob Gezelter, http://www.rlgsc.com

[GuentherF]

I did port part of a Unix application (Data Protector) to VMS. We had a small team for that. All code changes were wrapped with ifdefs to maintain a close common code base.

Most of the Unix file access functions had to be replaced by VMS callng functions. No big deal for us because new VMS.

All ioctl functions had to be replaced with VMS QIO calls so access to tape drives and libraries worked. But no problem we new the VMS QIO interface very well.

And then the always big surprise: redesigning code that spawned subprocesses (systen an friends). This is a major differnce between Unix and VMS. But we knew VMS well and it still needed quite some efforts.

And my gosh! no shmem on VMS. We to completly add a system level functiom to support Unx style shared memory access.

One engineer was "fishing" through Unix make files to implement the development and build environment on VMS. But we new all the VMS tools very well from previou projects so this was more a mechanical proccess.

And then we got a big hand from one of the engineers who worked on the Unix based aplication.

And voila... months later a prototype was running (all DP servers needed to backup locally on VMS and talk to a DP coordinator on a Windows system).

I hope with this brief story you get the idea.

/Guenther