Updated the samples with respect to ibmmq version 2.0.2

[tanaysingh3484]

I have updated the samples with the required changes so that they can run with the latest version of the ibmmq package, i.e. version 2.0.2

The changes which I have made are :

• Updated the README to add windows commands for setting the debugger and running the samples.
• Updated the boilerplate.js file with changes specific to the working of the sampleget, samplesubscribe, samplerequest and sampleresponse files. With the sampleget and samplesubscribe files, the getMessagesFromQueue function was updated with setting the tuning parameters to be as useCtl:false, following which the get callback function was successfully invoked. With the samplerequest and sampleresponse files, while running the request-response scenario, the mqrc 2500 error was being thrown, which after some research I found that it is due to two threads trying to connect to the same queue manager and queue. The solution for this was to add the mq.Ctl(hConn,mq.MQC.MQOP_SUSPEND) statement , which suspended one of the inactive threads trying to connect to the QM, so that only one thread was connecting to the QM, before starting a Put or Get in the req-rep scenario, and then once the action was performed I added the mq.Ctl(hConn,mq.MQC.MQOP_RESUME); which resumed the other thread to perform the next action.
• Some of the other samples had a debug_warn statement missing in the catch block so I added that.
• Updated the Copyright years of the files I modified.
• Corrected the debug_warn and debug_info display in the samplesubscribe file from debug_info(sameget:info) and debug_warn(sampleget:warn) to debug_info(samplesub:info) and debug_warn(samplesub:warn)

[chughts]

RE:

the mqrc 2500 error was being thrown, which after some research I found that it is due to two threads trying to connect to the same queue manager and queue. The solution for this was to add the mq.Ctl(hConn,mq.MQC.MQOP_SUSPEND)

Looks like this is happening in the responder, and the code is not waiting for the get promise to complete before attempting the put response.

We need to trace without the mq.MQC.MQOP_SUSPEND and mq.MQC.MQOP_RESUME to verify if the put promise is being resolved too early.

[chughts]

Needs significant rework.