2

I am migrating a project and we need to migrate ESQL/C source files from HP-UX to Red Hat Linux.

What may be the incompatibilities while moving these ESQL/C files to Linux?

j0k
  • 22,600
  • 28
  • 79
  • 90
user1716079
  • 69
  • 1
  • 1
  • 9

1 Answers1

0

There are two parts to the answer:

  1. The embedded SQL material.
  2. The rest of the code.

Embedded SQL

For the most part, unless you've gone out of your way to write system-specific SQL code, I would expect to transfer the ESQL/C source direct from HP-UX to Red Hat Linux with no more than a recompile. While you probably can write code that is not portable between the systems, I'm not really sure how you'd achieve that as long as you've accounted for 32-bit vs 64-bit code (if that is in fact necessary). I've multiple major programs that port between Linux and HP-UX (or AIX or Solaris or Mac OS X) with no changes to the embedded SQL code.

Rest of the code

The porting problems here are independent of the ESQL/C code. There are differences between the shared library handling, for example, or function calls that are specific to HP-UX that are not available in Linux (or, worse, the same function is available on both but behaves differently). These problems should be attributed to the correct cause — which is the C code around the ESQL/C and not the ESQL/C per se.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • As of now my concern is only for embedde SQL. Will it be working fine without throwing any issue? Will it be a simple re-compile only? – user1716079 Jan 03 '13 at 05:39
  • I'd expect so; I'd be surprised if it wasn't a simple recompile. If you've been careful, there won't be a problem. Were you using 32-bit or 64-bit ESQL/C on HP-UX (the letter U in the version indicates 32-bit; the letter F indicates 64-bit; IIRC, the letter H is HP-UX specific and indicates 32-bit ESQL/C that can talk to a 64-bit server via shared memory)? Are you migrating to 32-bit or 64-bit Linux (U vs F)? If they're the same 'bittiness', you'll probably have no difficulty; if they're different, you may have some problems if you've not been careful enough, but it is still fairly unlikely. – Jonathan Leffler Jan 03 '13 at 06:11
  • I have to migrate for 32 to 64 and 32 to 32 bits machine. ? – user1716079 Jan 03 '13 at 06:14
  • I can, and have, written ESQL/C code that moves transparently between 32-bit and 64-bit systems. It's not particularly hard; it requires a small modicum of care — primarily not using `long` where you need `int` on the 32-bit side. I _am_ asking you, indirectly, what version of CSDK (ESQL/C) are you moving from on the HP-UX system, and which version of CSDK (ESQL/C) are you moving to on the Linux side. Unless your C code does something odd, like using the HP-UX shared library loading code, I expect it to be recompile and go. I can't promise that; I don't know how much of a mess the code is in. – Jonathan Leffler Jan 03 '13 at 06:21
  • the version (CSDK/ESQL/C) would be equal or higher at linux end than unix end. – user1716079 Jan 03 '13 at 06:24
  • That isn't a very helpful answer, but if it is all you are willing to tell me, then I've told you all I'm willing to tell you. If you don't know, say so; I can respect that (but you can probably fix the lack of knowledge on the next business day). – Jonathan Leffler Jan 03 '13 at 07:06
  • Apart from the word size (32/64), is there any other case that you can think of that would be system specific enough to warrant manual intervention during a migration? For example File I/O, user admin stuff, etc.? And sorry about not providing versions; at this stage I am not sure what either version (i.e. source/target) is. – user1716079 Jan 03 '13 at 09:22