What is the impact on existing code to migrate from WebSphere MQ V6 to V7?
Can we make simply the change?
Like all good questions, the answer here is "it depends."
First of all, don't go to v7.0, go to V7.1 at least, better yet to V7.5.
Using client or bindings mode connections? You can upgrade the QMgr without touching a client-based app in most cases. Any version of WMQ client can talk to any version of WMQ server, however its best not to leave apps on an unsupported version of WMQ client. Of course, the app running on the old client won't get the new function such as automatic reconnect or performance improvements, even though the QMgr is at V7.5.
Using SSL? The SSLPEER element order changed and the commands to manage certificates changed. Good news, cert management is now performed with runmq*km commands living in the {mq install}/bin directory so you don't need to hunt down the GSKit directory and figure out whether to use gsk6*, gsk7* or gsk8* commands.
If you go from 32 to 64 bit, you may need to recompile programs or exits.
Correct settings for PATH, CLASSPATH and LIBPATH change across versions.
There's much more and it's well covered in the Infoceenter. Each Infocenter has a section on migration. Within that section, there's subsections by version and within those there are subsections by platform. Pick the target version of WMQ (that's V7.5, right? Say yes!) and and drill down. Start here:
Migration from V6.0 to V7.5
Migration from V6.0 to V7.1
Migration from V6.0 to V7.0
Related
Planning to Migrate the Websphere from 7.0 to 9 and 8.5 to 9.
Can anyone help me getting the detailed Process
Migration here is "In place". (Migration will be done on the same servers, where the old Installation are in)
if at all any migration tools need to be used, please provide the clear info on them.
any documental references, or any video references for the questioner is appreciated.
OS used : RHEL
CUrrent version: WAS 7x and 8.5
Migrating to : WAS 9.0
It sounds like you're in the very beginning stages of doing this migration. Therefore, I highly recommend you take some time to plan this out, especially to figure out the exact steps you'll be taking and how you'll handle something going wrong. For WebSphere, there is a collection of documents from IBM that discuss planning and executing the upgrade. Look around there for documentation on the tools and step by step guides for different kinds of topologies. The step by step guide for an in place migration of a cell is here.
You should make sure to take good backups before you start the process so you can restore back to before the migration if you need to.
In addition to doing the upgrade, an important part is to also make sure your applications are going to work on the new version if you haven't already. IBM provides this tool to scan applications and identify potential issues that developers will have to fix. There is documentation for the tool at that link as well.
If you are in the planning phase, I'd strongly suggest you to consider migrating to WebSphere Liberty instead of traditional WAS v9. All these migration tools (toolkit for binaries, Eclipse migration toolkit) support both migration scenarios.
Choosing Liberty might be a bit more work at the beginning, but you will gain more deployment flexibility and speed up future development. Liberty is also much better fitted for any cloud/containers environments, as it is much more lightweight, so in the future, if you would like to move to containers, it would be much easier.
Check this tutorial Migrate traditional WebSphere apps to WebSphere Liberty on IBM Cloud Private by using Kubernetes, although it shows the steps to migrate to Liberty on ICP, beginning is the same - analyzing of the application whether they are fit for Liberty and migrating. If you don't have access to IBM Cloud or ICP, you can use stand alone version of the Transformation Advisor that was released recently - IBM Cloud Transformation Advisor.
Having said all that, some apps include old or proprietary traditional WebSphere APIs and in that case it may be easier and cheaper to temporary migrate them to WAS v9, and modernize in the future.
I need to connect a WinCE6.0 device to a web based server using HTTPS.
The problem: WinCE6.0 uses WinInet v6 which supports SSL2, SSL3 and TSL1.0 None of which are supported in the current (2018) best practices due to their security flaws.
I doubt I can drop in a newer version of WinInet and expect it to run.
I had thoughts of porting CURL to WinCE.
I'm thinking this issue has already been addressed by the CE community, but I'm not seeing an available solution.
How can I get an old embedded device to securely connect to the WWW?
From GuruCE:
If you want to use TLS 1.1 and 1.2 on CE a suitable solution is to use mbedTLS library from ARM. It has a BSD-like license, so not too restrictive. Only one change to the makefiles is needed to get it to work on CE.
Does anyone have any idea how this can be done?
It's my understanding that WebSphere 8.5 traditional is not compatible or will not run on OSX. I am looking for solutions for developers to develop with a WebSphere 8.5 traditional server locally.
Could we setup some servers on a windows machine so they can be used remotely during development?
I downloaded the Eclipse plugin but it gives me the warning saying OS X is not compatible with WebSphere traditional and to give it a remote server address. I tried to point eclipse to a server on a windows PC but it still wants a runtime installation directory.
I found a single thread on WASDev with a similar question talking about runtime stubs with a dead link.
I tried using a liberty server but I get nothing but null pointer exceptions and JMX errors, I don't think this is a valid alternative in my corporate environment.
For developing against WebSphere traditional on OSX, you could try Docker! We've published developer edition versions of 8.5.5.9 and 9.0.0.0, see:
https://developer.ibm.com/wasdev/blog/2016/06/15/websphere-traditional-ibm-http-server-docker-hub/
https://hub.docker.com/r/ibmcom/websphere-traditional/
The Dockerfiles used to produce these images are here, should you want to try building your own instead:
https://github.com/WASdev/ci.docker.websphere-traditional
However, your question is more specific to getting the tools working.
The last I read (and I'll try to confirm/update the answer when I do find it), is that the stubs are part of the full product install for RAD (selectable via Installation Manager).
You're correct that traditional WAS doesn't run on OSX. Remote servers are an option but traditional WAS is considered by some developers to be heavy and slow to restart, so your developers might appreciate something local and more nimble. Liberty is supposed to run on OSX, and things that run on Liberty -usually- will run on traditional, so getting to the bottom of your Liberty problems might be useful. If you haven't already, posting your question on WASDev might reach someone that has a better answer than this one.
I am asked to upgrade IBM WebSphere application server 8.0 to 8.5.5 on linux environment. Could you please give me a step by step guide for this migration?
thanks,
Kumar
The simplest method (assuming your WebSphere instances have enough spare CPU/disk/etc) is to build a second WebSphere cell at the new level and migrate applications across one at a time. Access to the application servers should be controlled by either a web server (using the WAS plugin) or an IP sprayer product and which version of app server used should be controlled in that layer. Updating in place has many pitfalls and can be difficult to recover from if something goes wrong which can lead to extended down time for your applications.
I tried the integration of these products based on this article and I hit the same problem already documented in the article.
"invocation of javascript function 'getRSSFeeds' has failed: Could not initialize class com.ibm.websphere.objectgrid.ObjectGridManagerFactory
FWLSE0101E: Caused by: [project ExtremeScaleInWorklight]java.lang.NoClassDefFoundError: Could not initialize class com.ibm.websphere.objectgrid.ObjectGridManagerFactory"
It seems that it is caused by a Java class collision of log4j.
My solution was to create a separate Liberty server and install the WXS client for Liberty. This solved the problem, but then I cannot use the WL Development Server anymore which turns the development less efficient.
What is the best way to develop this kind of solution?
I have seen this integration of products on several slides, but I can't find an official guide on how to achieve this. Is there any?
Have You tries to get the IBM WebSphere eXtremeSCale Liberty profile developer tools 8.6 also installed in your WL Development Server ?
SO WXS has two components Client ( libraries) and Serer side components. They can be housed in the same JVM -- for tests, in production this does not really make sense. Serer side hosts storing of objects and enforcing the 'grid management' policies that you may employ using the xml confg files.
perhaps you can use IBM WebSphere eXtremeSCale Liberty profile developer tools 8.6 also installed in your WL Development Server and include then in the classpath.