Migrate HP UX apps to Windows

[Bill.Jordan]

Hi, I am looking at different options to convert our older HP UX 11 apps/scripts to either RH Linux or Windows. We currently have a Risc 9000 series w/HPUX 11. I want to replace it with an intel platform (HP box) (less expensive then risc) and migrate to a more modern, common and versatile environment. I am comfortable with converting to Linux, but I need to compare it to converting it to Windows (costs/portability etc). All existing apps in unix are compiled in Fortran 77 or 90, and i'm looking at ideas/costs/time/effort to convert them to Windows. We have 100's of programs/scripts that use HP Unix commands. Does anyone have any thoughts or ideas?

[James R. Ferguson · Accepted solution]

Hi Bill:

I think you might be better asking this question in a Windows forum.

If the port is to Linux, the GNU compilers should do admirably.

If the port is to Windows, you might look at things like:

http://software.intel.com/sites/products/collateral/hpc/compilers/compiler_suite_win_brief.pdf

Everything depends on what kind of code you are converting. Code that relies on UNIX system calls is going to be more difficult to port than pure "application" code in whatever language.

Specific examples of the "programs/scripts that use HP Unix commands" might yield more definitive comments here.

Good luck. I think you will need it, especially if you move to Windows.

Regards!

...JRF...

[TwoProc]

Years ago, I moved a bunch of fortran from f66 to f77, from MPE to HPUX. As far as the coding goes, the hard part was the fortran change from f66 to f77. The change in machine was pretty simple once you went in and changed the formatting and pathing for file names. Other than that, it was pretty simple.

As for being "easier" or not; you'll need to focus on the *screen I/O*. If I/O is stdin/stdout/stderr and is manipulated/mangled/batched with things like awk, sed, etc. Then, no question you'd be MUCH better off with Linux.

If the screen I/O is delivered in a screen editable package deliverable to a text screen using HPUX or vt100 emulation, or curses, then once again - Linux.

If the screen I/O is some totally purchased package then you should check with the vendor to see what offerings they have. They may offer you a Windows library replacement, or a Linux one, in which case, I'd go with Linux if they have a library, or Windows if no Linux is available. If neither is available, then you'll be faced with replacing all screen I/O yourself. Annnnnd, then you'll have your work cut out for you, and you get to choose, in which case I'd choose whichever one gives me the easiest task of moving my screen logic to another screen library similar to mine.

If the screen I/O is Xwindows - then without a doubt, use Linux.

As far as metrics if everything is same/same on both platforms for availability of screen I/O then the differentiator becomes the file I/O. If you've got loads of it, then Linux will make that process easier because you can leave practically ALL of it intact. If per program you've got just one or two files, then a Windows port becomes a minor issue per program, and only an issue to see if all works systemically well together.

If you manage to stay on a UNIX platform I think your chances for success coupled with the fewer chances of having problems would be the faster port - but that's only if screen I/O choices are fungible.

Most historical fortran apps are plain text screen based, probably vt100 or hpterm. If this is what your programs are; stick with Linux. And if this is true, your effort to port to the new platform would be at least 1/2 the effort of Windows.

Lastly, regardless of platform. To make your life easier - try to use the same "size" machine for the replacement. If your old code is running on a 32 bit system (which it probably isn't) make sure to use the new apps on a 32 bit system. If your old code is running on a 64bit OS (which is probably your case on a HPUX11 server), then port to a 64 bit machine and compiler/fortran run time environment. This save you a lot of grief with programs that reuse variable spaces (much like UNIONs in C). When you change to a new size architecture format, the padding characteristics can/will change between sizes.


Besides padding issues, you can/will run into precision issues when changing platforms, especially if you went from 64 bit to 32 bit programs. And, since folks use Fortran specifically for precision, this could easily be a problem when you're trying to verify routines and results betweens systems, as I can guess that your Fortran programs are probably scientific and exacting in nature.

Also, you know that going from PARisc to Intel based chips will change you from big endian to little endian architecture. If you're reading old binary files in Fortran, you will probably have problems. You may have to read in old data files, and convert them all to text on your PARISC box before you make the move. Or, you may have to write prefetch utility routines that move bits around into the right order before copying them over to corrected files for processing. You'll have to read the code and test to see.

I'd suggest grabbing one of the smallest/simplest programs and do one conversion on each platform(Windows/Linux) for your metrics of effort to port between the two platforms.

Here is a nice resource for you from Linux Journal about a port of a bunch of Fortran code from HPUX to Linux and Windows. However, the article is very old:
http://www.linuxjournal.com/article/2942
but, your code is probably old too, so probably still relevant, :-)


Here's another nice link pointing to an online book for porting Unix apps to Linux:
http://my.safaribooksonline.com/0131871099
also in print:
http://www.amazon.com%2FUNIX-Linux-Porting-Comprehensive-Reference%2Fdp%2F0131871099&rct=j&q=port+fortran+from+HPUX+to+Linux&ei=UMcGTOWiFoOdlgfP86jVCg&usg=AFQjCNF3t__iJ7LtZHcsH3tIAHlvQifg_Q

Another tip: in reviews, Absoft seems to have climbed a lot of these mountains. And, they have a "try it" link on their page:
http://www.absoft.com/
I'd recommend doing this, AND, their software runs on both Linux and Windows. And, they have 64 bit support; AND I saw somewhere that have support big endian/little endian conversion - so you may have your choice of which way to go as merely a point of preference.

Good luck!

[Bill.Jordan]

Hi guys. Thanks for all of your input - excellent advise. I do plan on converting from HP UX to RH Linux, but this gives me more options. If anyone has more thoughts i'd always be happy to read them. Thanks - Bill

[Steven E. Protter]

Shalom Bill,

You will be maintaining a different code base for Windows. A substantial difference exists in how those OS and Unix/Linux interact with users.

If you can find out how Oracle was developed, they do a pretty good job having the same core code base, minus the UI work on multiple platforms.

How they develop might be of use to you in this endeavor.

SEP