Operating System - HP-UX
1751888 Members
4811 Online
108783 Solutions
New Discussion юеВ

Re: HP-UX 10 32 bit to HP itanium 11 ia 64 migration

 

HP-UX 10 32 bit to HP itanium 11 ia 64 migration

Hi, we are migrating embeded sql aand ingres used application from Hp ux 10 to itanium.When we run the binary moved from hp-ux , it created a core file .
[HP ARIES32]: Core file for 32-bit PA-RISC application
[HP ARIES32]: /uj/essff/bin/a_cosoft64 saved to /uj/essff/bin/core.a_cosoft64.

(gdb) bt
#0 0xc81908e8 in kill+0x10 () from /lib/libc.0
#1 0x3fa2c in + 0x17c ()
#2 0x3f830 in + 0x290 ()
#3
#4 0xa0724 in ()
#5 0x4b070 in + 0x70 ()
#6 0x16dec in + 0x27c ()
#7 0x168d4 in + 0xb0 ()
#8 0x167b8 in + 0x40 ()
#9 0x1676c in + 0x10 ()
#10 0xb9bc in ()
#11 0x8a80 in + 0x114 ()


Please advise.
3 REPLIES 3

Re: HP-UX 10 32 bit to HP itanium 11 ia 64 migration

Have you reviewed the ARIES troubleshooting help here:

http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801/?ciid=c935c7b31d779110VgnVCM100000275d6e10RCRD

Main point is, are you _sure_ you copied over _all_ the libraries the executables use?

HTH

Duncan

I am an HPE Employee
Accept or Kudo
TwoProc
Honored Contributor

Re: HP-UX 10 32 bit to HP itanium 11 ia 64 migration

Man - I'd be looking to see if you could find an embedded sql and ingres binary source that's already 64bit Itanium base, and check with the providers to see what steps would be required in the migration of the data files. It's quite possible that there are no steps on the data files, just copy them over and fire up the database binaries against the data files. If that works, it's a big win for you and your team in terms of your software horizon and how long that applications remains a long term asset or a long term "gotcha" liabilitiy/worry you'll have to be on the lookout for.
We are the people our parents warned us about --Jimmy Buffett
Dennis Handly
Acclaimed Contributor

Re: HP-UX 10 32 bit to HP itanium 11 ia 64 migration

Because the application is stripped, you can't get much info from your stack trace. If you can recreate the application without stripping it, it would help.

If you can run the application in the debugger, you could at least find out the first signal.

You could also try:
(gdb) frame 4
(gdb) info reg
(gdb) disas 0xa0724-4*20 0xa0724+4*8