ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Mq Client app moving to a new home

Post new topic  Reply to topic
 Mq Client app moving to a new home « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Fri Mar 13, 2009 1:18 pm    Post subject: Mq Client app moving to a new home Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

It’s a C app running on Solaris. The current server has just the MQ Client installed and is 5.3 CSD5. The new server will be just the MQ Client at 6.0.2.5 I referred them to the below link, which talks about them having to recompile their app. Is this true? They came back to me with:

"Peter:

Is it possible to ask IBM if the application can be re-linked to pick up the new SO's? This would eliminate the need to perform a full compilation.

Thanks ..."

I'm not a C guy and the app expert was not on the call - just me and a bunch of PMs and managers. So, to move this app to the new server, do they need to recompile? Or relink? Or is that the same thing? Or can they just move their app as is over to the new server and have it work with MQ 6.0.2.5?




http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaf.doc/cs12610_.htm
Quote:

Linking C applications with the WebSphere MQ client code
Having written your WebSphere MQ application that you want to run on the WebSphere MQ client, you must link it to a queue manager. You can do this in two ways:

Directly, in which case the queue manager must be on the same machine as your application
To a client library file, which gives you access to queue managers on the same or on a different machine
WebSphere MQ provides a client library file for each environment:
AIX®

libmqic.a library for non-threaded applications, or libmqic_r.a library for threaded applications.
HP-UX
libmqic.sl library for non-threaded applications, or libmqic_r.sl library for threaded applications.
Linux®
libmqic.so library for non-threaded applications, or libmqic_r.so library for threaded applications.
Solaris
libmqic.so.
If you want to use the programs on a machine that has only the WebSphere MQ client for Solaris installed, you must recompile the programs to link them with the client library:


$ /opt/SUNWspro/bin/cc -o <prog> <prog> c -mt -lmqic \
-lmqmcs -lsocket -lc -lnsl -ldl
The parameters must be entered in the correct order, as shown.
Windows®

MQIC32.LIB.

_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Mar 13, 2009 2:33 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Linking is, in theory, a separate step than compiling.

But you generally all do it from one makefile, and in order to do it you need the .o files from the compile step. Those are usually not kept around (any time anyone tells you to run "make clean", it's getting rid of the .o flies).

The steps you will find in the APG for building C applications include both compiling and linking in a single cc command.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Mar 13, 2009 4:09 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mqjeff wrote:
Linking is, in theory, a separate step than compiling.

But you generally all do it from one makefile, and in order to do it you need the .o files from the compile step. Those are usually not kept around (any time anyone tells you to run "make clean", it's getting rid of the .o flies).

The steps you will find in the APG for building C applications include both compiling and linking in a single cc command.




In theory you could just relink and be confident it would work, but it relies on them having the objects to use as input to the link. It's very unusual to keep them but who knows?

Tell the PM a full recompilation isn't as onerous as he seem to think.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Mar 13, 2009 4:47 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

Quote:
Linking C applications with the WebSphere MQ client code
Having written your WebSphere MQ application that you want to run on the WebSphere MQ client, you must link it to a queue manager.

Unclear statement. I would have chosen another term instead of link because it has multiple meanings, therefore has no concise meaning.

Some mainframe references follow to aid in clarity.

A programmer writes an application in a source language like C or COBOL or Fortran or an assembly language. This source code is input to a language translator - a compiler for high-level languages, or assembler. Output from the language translator (besides the program listings) is an object ('object deck' for those who recall what an 80-column Hollerith card is or was).

The object contains machine instructions (add, subtract, etc.) and references to other objects that will be needed at execution, but are not part of this compile. Many vendors, including IBM, distributes object-code only, meaning that you don't get source for WMQ, DB2, the C compiler; rather, you get object code.

The linkage-editor binder program reads my object, and searches for the other objects from other (usually product-specific) libraries. Output from the binder is an executable that contains my program and the other stuff.

So, application objects will need to linked (linkedited, bound) with an MQ object to form our executable. Two choices: in-memory or client. In this reference, link means bind.

When the author says that ...you want to run on the WebSphere MQ client, you must link it to a queue manager, I'm guessing that he/she really meant to say that something outside of the executable will establish (and complete) the appropriate pathing to connect to the queue manager. Think MQSERVER= or the environment variables that allow for use of the client channel table. Clearly, applications do not link to qmgrs, except in the broadest (and least concise) definition of the term link.

So, if your application is staying on the same o/s, you can export the executable without compile and bind; or you can compile and bind; or you can just bind - no harm, no foul. If you are moving from one o/s to another (AIX to Windows or z/OS, for example), you will need to both compile and bind, to get an o/s- and platform-specific executable.

Of course, Java is different.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Mar 13, 2009 6:25 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Bruce, thanks for the background info. I like to know the how/why rather than just "Do this".

So when this app was compiled and bound / linked at MQ 5.3, it was linked with some "thing" that aimed it at the MQ Client libraries installed on the server.

On the new server the link "thing" in the executable program will still aim it at the MQ libraries, but it will come across the MQ 6.0.2.5 libs instead, and the app will start using MQ 6.0.2.5 with no changes required.

Obviously if they wanted to take advantage of new features only available in the newer version of the software, they would have to recode and recompile.

So this magic link thingie - its version independent? From MQ 5.2 to 5.3 to 6.0 to 7.0 to x, as long as IBM keeps the paths to all the MQ libs the same, the app won't need to recompile or even relink?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Mar 14, 2009 5:22 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

UICLMM, bindings libraries are only used at bind time. Once bound with client-bindings, the client application connects to a qmgr channel. Same for a memory-bindings app, but it connects cross-memory to a qmgr. No aiming; just ready, fire.

Bindings libraries are versioned; but, unless stated otherwise, WMQ allows older/newer version bindings apps to coexist with older/newer version qmgrs.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Mar 14, 2009 6:46 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The risk you face is this.

If the app is linked against an older version of the client libraries, it expects that certain routines in the client libraries will load into certain "known" chunks of memory - that's what the linking does, it adds those locations to the place where the program execution looks to find the implementation.

If the newer version has moved those locations, then the program will try to go to the old one, and die (in a best case - in a worst case it will do something "like" what you want, but not really what you want).

Again, in order to relink you need to have the output of the compile step. It's not likely that you actually *do* have the output of the compile step.

Best and safest option is to rebuild from source on a machine with the right compiler and the right version of the client.

In general, the MQ client doesn't change very much inside major versions - but it does change between major versions (v6 to v7). So don't trust a v5.2 linkage against a v7 qmgr, nor very much against a v5.3 or v6 qmgr even.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Sun Mar 15, 2009 2:36 pm    Post subject: Reply with quote

Jedi Knight

Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia

It is likely your MQ 5.3 client C app will work if the executable is run on a MQ 6.0 system. On Solaris, the MQ code linked into the executable (libmqic_r.so) actually does a dynamic link at run time to other MQ libraries, via the system library search path (LDPATH), so it will pick up the MQ 6 libraries. So, you may not even need to relink the app.

However, don't trust what I say, do more research.
_________________
Glenn
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Mar 15, 2009 8:21 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

gbaddeley wrote:
It is likely your MQ 5.3 client C app will work if the executable is run on a MQ 6.0 system. On Solaris, the MQ code linked into the executable (libmqic_r.so) actually does a dynamic link at run time to other MQ libraries, via the system library search path (LDPATH), so it will pick up the MQ 6 libraries. So, you may not even need to relink the app.

However, don't trust what I say, do more research.


However owing for the fact that with 5.3 source executable you are forced to stay within the 32 bit model and all the memory constraints it puts on the qmgr and its shared memory, you might "WANT" to have the code recompiled as a 64 bit application...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
gbaddeley
PostPosted: Mon Mar 16, 2009 5:09 pm    Post subject: Reply with quote

Jedi Knight

Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia

fjb_saper wrote:
However owing for the fact that with 5.3 source executable you are forced to stay within the 32 bit model and all the memory constraints it puts on the qmgr and its shared memory, you might "WANT" to have the code recompiled as a 64 bit application...

Have fun


Yes, I would actually recommend relinking all MQ apps when upgrading to a new version, to at least minimise risk of exposure to unknown compatibility problems and to take in efficiency improvements in the MQ libraries (such as the memory model and IPC). But its not always practical for app dev teams to do that, so they generally don't both to relink unless they really have to. They should always test the app under the new version (before it gets to production), and if it works as expected, don't bother to relink.
_________________
Glenn
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Mar 16, 2009 5:15 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

My PMR told me nothing will probably be fine, a relink might be needed, and recompile is highly unlikely to be needed.

The app will try moving to the new server without a relink and we'lll see what happens.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Mar 16, 2009 5:30 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

Quote:
My PMR told me nothing will probably be fine...

You mean everything (antonym of nothing) will be unsatisfactory (antonym of fine)?

Color me lost...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Mq Client app moving to a new home
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.