0

Since upgrading MQ to "IBM MQ Explorer V9.1", the XMS libraries that always worked in previous versions have started behaving differently.

Essentially, the code still recognises the messages as IBytesMessage type, and successfully writes them to file via a Byte array, but the file itself, which is a split zip file, fails to reconstitute itself.

Here's the lions share of that code:


Dim FactoryFactory As XMSFactoryFactory = XMSFactoryFactory.GetInstance(XMSC.CT_WMQ)

            'Create a ConnectionFactory Object
            cfConnectionFactory = FactoryFactory.CreateConnectionFactory()

            'this variable will contain the full path of any file downloaded from MQ
            Dim strMQMessageOutputFileDestinationFilePath As String = ""

            'This variable will be used to evaluate whether the MQ Message Output file exists
            Dim fiMQMessageOutputFile As FileInfo = Nothing


            'Set various Connection Factory properties
            cfConnectionFactory.SetStringProperty(XMSC.WMQ_HOST_NAME, Me.HostName)
            cfConnectionFactory.SetIntProperty(XMSC.WMQ_PORT, 1414)
            cfConnectionFactory.SetStringProperty(XMSC.WMQ_CHANNEL, "SYSTEM.DEF.SVRCONN")
            cfConnectionFactory.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, 1)


            cfConnectionFactory.SetStringProperty(XMSC.WMQ_QUEUE_MANAGER, Me.QueueManager)
            cfConnectionFactory.SetIntProperty(XMSC.WMQ_BROKER_VERSION, 0)


            'Create a new Iconnection object via the Connection Factory
            connection = cfConnectionFactory.CreateConnection()

            'Create a sesion via the Connection Object, using ClientAcknowledge mode
            'ClientAcknowledge is being used because it allows us to control precisely 
            'when a message should be removed from the queue
            session = connection.CreateSession(False, AcknowledgeMode.ClientAcknowledge)


            'Create a destination using the Session Object
            destination = session.CreateQueue(Me.mstrDestinationURI)

            destination.SetIntProperty(XMSC.DELIVERY_MODE, 1)

            'Create a consumer using the Session & Destination Objects
            Consumer = session.CreateConsumer(destination)

            connection.Start()

            'IMessage is the base class that is returned from the Consumer's Receive method
            Dim recvMsg As IMessage = Nothing

            ' Retrieve message from Queue
             recvMsg = Consumer.ReceiveNoWait

                     strFileNameFromMsg = If(Not recvMsg.PropertyExists("fileName"), "",
                     recvMsg.GetStringProperty("fileName"))

                    If TypeOf (recvMsg) Is IBytesMessage Then
                        'Binary Message
                        Dim msg As IBytesMessage = CType(recvMsg, IBytesMessage)
                        Dim buffer(msg.BodyLength) As Byte

                        msg.ReadBytes(buffer)
                        Dim content As String = Text.Encoding.UTF8.GetString(buffer)

                        'The PrepareDestinationFile Function will generate a unique file name for the new file
                        'and ensure that the file does not already exist on the drive
                        strMQMessageOutputFileDestinationFilePath = PrepareDestinationFile(strFileNameFromMsg)


                        'A FileStream object is needed to write a binary array to a file
                        Dim fsZipFile As FileStream = New FileStream(strMQMessageOutputFileDestinationFilePath, FileMode.Create)

                        'Write the contents of the Byte Array to the File via the FileStream object
                        fsZipFile.Write(buffer, 0, buffer.Length)
                        fsZipFile.Close()


                    End If

So, the code doesn't throw any kind of exception - the code still recognises the messages as IBytesMessage, but the files won't unzip correctly.

Oddly, If we use rfhutilc.exe, we can manually pull files provided we set the Write options as No Headers and not Include MQMD - but the code above always worked in the previous version of MQ / XMS

Any assistance you can provide would be very much appreciated.

king_moot
  • 1
  • 2
  • Sorry, to clarify, the client I'm being told corresponds to the server component is: IBM MQ Explorer V9.1 – king_moot Jan 27 '20 at 16:43
  • You can right click on the IBM MQ dll and check the version it is from. It would be good to understand the version of the "working" dll and the version from the "non-working" dll. – JoshMc Jan 27 '20 at 16:46
  • If those are internal IPs at your company I would suggest you edit them out. If you are concerned long term since even things you edit out are available in the edit history, you can flag the question for "in need of moderator intervention" and ask them to redact the private information that you accidentally posted. – JoshMc Jan 27 '20 at 16:48
  • The "IBM.XMS.dll" that is referenced by the .NET project is at version 9.0.0.8. – king_moot Jan 27 '20 at 16:49
  • I assume you have two dlls. You are giving only one version. If one works and one does not, then please edit the question (easy to do, just click the "edit" link under the question) and add the version above for the old and new and as stated remove the IP addresses which have nothing to do with this question. – JoshMc Jan 27 '20 at 16:51
  • The previous IBM.XMS.dll we used (that worked correctly) is the one that came bundled with "Websphere MQ fix pack 7.0.1.3" – king_moot Jan 27 '20 at 16:54
  • ">> If one works and one does not" The problem with that comment is that this upgrade is both a server and client upgrade. So, to be clear, the previous combination of MQ Server and MQ Client together worked using the code in the original post. – king_moot Jan 27 '20 at 16:55
  • @chughts thank you and done. So it worked with 7.0.1.3 but not with 9.0.0.8. – JoshMc Jan 27 '20 at 16:56
  • "IBM MQ Explorer V9.1" is a tool to managed IBM MQ queue managers from MQ v9.1, how does this associate with your problem since it would not directly related to XMS. – JoshMc Jan 27 '20 at 16:57
  • To be clear, the client install from IBM is described as V9.1 but the DLL's version is marked as 9.0.0.8 – king_moot Jan 27 '20 at 16:57
  • "how does this associate with your problem" It associates because the XMS DLL (and code samples) come bundled with the "IBM MQ Explorer V9.1" installer. – king_moot Jan 27 '20 at 16:58
  • Ok. So you have IBM MQ v9.1.?.? installed on your windows machine, but you are associating your compile against a DLL that is from 9.0.0.8. The first thing I would try is to associate with the DLLs from 9.1.?.? that is associated with your client install. Mixed versions can cause problems. – JoshMc Jan 27 '20 at 17:03
  • The DLL that is bundled with the V9.1 installer is 9.0.0.8. – king_moot Jan 27 '20 at 17:05
  • Here's some more build info - this might be relevant. - The previous MQ Client, and MQ QMgr Version and fixpack level. 7 – fix pack 7.0.1.8 - The current MQ Client, and MQ QMgr Version and fixpack level. 9 – 9.1.3 not sure any fix packs have been applied - The Hosting OS version and maintenance level for the MQ Client, and MQ QMgr. Windows 2012 R2 – not sure what you mean by maintenance level; Windows is patched up to latest level – king_moot Jan 27 '20 at 17:05
  • - The previous XMS Version. The XMS will have been the version 7 library used with VB.net - The current XMS Version. The XMS is the version 9 library, still being used with VB.net – king_moot Jan 27 '20 at 17:05
  • Unless IBM MQ messed up in packaging things the 9.1.3 version of mq would come with a xms dll that shows version 9.1.3, not 9.0.0.8. I think you are referencing a version of the dll that is not found under the full IBM MQ client install location. Check under bin directory of the client install for the associated IBM.XMS.dll files and associated other files. – JoshMc Jan 27 '20 at 17:08
  • 3
    @king_moot - Used RFHUTIL to write a zip file to a queue. Received the message using the application built using your code and referencing IBM.XMS.DLL of MQ 9.1.4 CD release. I am able to unzip the file successfully. – Shashi Jan 28 '20 at 04:47
  • Another point (not related to the issue): You are using ClientAcknowledge mode while creating session. But I don't see a message.Acknowledge() being called. If Acknowledge is not called, the same message can be redelivered to your application. – Shashi Jan 28 '20 at 05:07
  • @Shashi - I didn't include the full code sample but it ends with recMsg.Acknowledge() – king_moot Jan 28 '20 at 09:15
  • Hi, I am commenting here just to clarify that we still have this same problem. Can anyone advise if they've used the iBytesMessage object recently, and with SPLIT zip files? It's an odd file format, granted, but interesting that the files only download correctly with the rfhutilc. What is the equivelent of rfhutil's "Write options as No Headers and not Include MQMD" in the API? – king_moot Apr 07 '22 at 09:38

0 Answers0