| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Client 7.0.1.12, MQCONNX and COBOL - Lethal combination? |
« View previous topic :: View next topic » |
| Author |
Message
|
| TheAndroid |
 Posted: Sun May 24, 2015 7:52 pm Post subject: MQ Client 7.0.1.12, MQCONNX and COBOL - Lethal combination? |
 |
|
Novice
Joined: 04 Dec 2007
Posts: 23
|
All,
I have a COBOL program on Linux 64-bit which is attempting to do a simple MQCONNX using the channel definition table and a UserID and Password.
If I do not set the MQCNO-SECURITYPARMSOFFSET or MQCNO-SECURITYPARMSPTR, the call is successful, but winds up using my ID for the connection. What I am trying to do is use a service ID in a large enterprise environment.
When I set MQCNO-SECURITYPARMSOFFSET to the offset of my MCSP, I invariably receive:
# SIGSEGV (0xb) at pc=0x00007fe86e82b4e3, pid=17685, tid=140636516181760
# Problematic frame:
# C [libmqiz.so+0x514e3] reqDuplicateCno+0x6c3
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
From the call to libmqicb.so. When I set the MQCNO-SECURITYPARMSPTR, the call does not blow up, but it does always return a reason code 2278.
I have these areas defined one after the other within an 01 level (MQCNO then MQCSP). The listing from the compile shows them to be contiguous. So, I calculate the offset for MQCSP to be the LENGTH of MQCNO. I only ever set either the offset or the pointer.
I've looked on the MQ Support Site at IBM and they don't mention anything about this, so I don't know if I've stumbled on a bug or am just doing something incredibly stupid. Here is the source:
| Code: |
* 00000100
IDENTIFICATION DIVISION. 00000200
* 00000300
PROGRAM-ID. SECTEST. 00000400
* 00000500
ENVIRONMENT DIVISION. 00006200
* 00006300
CONFIGURATION SECTION. 00006400
* 00006500
INPUT-OUTPUT SECTION. 00006600
* 00006700
FILE-CONTROL. 00006800
* 00006900
******************************************************************00019300
* WORKING STORAGE 00019400
******************************************************************00019500
* 00019600
WORKING-STORAGE SECTION. 00019700
* 00019800
01 WORKING-STORAGE-AREA PIC X(80) 00019900
VALUE ' BEGINING OF WORKING-STORAGE '. 00020000
* 00020100
01 MQI-MQ-PUT-API-PARMS. 00047700
05 MQI-PUT-QMGR PIC X(48) VALUE SPACES. 00047800
05 MQI-PUT-HCONN PIC S9(09) BINARY VALUE 0. 00047900
05 MQI-PUT-HOBJ PIC S9(09) BINARY VALUE 0. 00048000
05 MQI-PUT-OPEN-OPTIONS PIC S9(09) BINARY. 00048100
05 MQI-PUT-COMPCODE PIC S9(09) BINARY. 00048200
05 MQI-PUT-REASON PIC S9(09) BINARY. 00048300
05 MQI-PUT-DATA-LGTH PIC S9(09) BINARY VALUE 0. 00048400
* 00048500
******************************************************************00052300
* MQI CONTROL BLOCKS 00052400
******************************************************************00052500
* 00052600
01 MQI-MQOD-OBJECT-DESCRIPTOR. 00052700
COPY CMQODV. 00052800
* 00052900
01 MQI-MQMD-MESSAGE-DESCRIPTOR. 00053000
COPY CMQMDV. 00053100
* 00053200
01 MQI-MQGMO-GET-MESSAGE-OPTIONS. 00053900
COPY CMQGMOV. 00054000
* 00054100
01 MQI-MQPMO-PUT-MESSAGE-OPTIONS. 00054200
COPY CMQPMOV. 00054300
01 MQI-MQCONNX-DATA.
COPY CMQCNOV.
* COPY CMQCDV.
COPY CMQCSPV.
10 MQCSP-USERID PIC X(48) VALUE SPACES.
10 MQCSP-PASSWORD PIC X(48) VALUE SPACES.
01 ANUMBER PIC 9(12).
* 00054400
******************************************************************00054500
* NVDS CONTAINS THE NAME.VALUE.DATA.STRING 00054600
* 00054700
******************************************************************00054800
* 00054900
* 00055000
******************************************************************00055100
* CMQV CONTAINS CONSTANTS (FOR FILLING IN THE CONTROL BLOCKS) 00055200
* AND RETURN CODES (FOR TESTING THE RESULT OF A CALL) 00055300
******************************************************************00055400
* 00055500
01 MQI-CONSTANTS. 00055600
COPY CMQV. 00055700
COPY CMQXV.
* 00055800
/ -------------------------------------------------------------- *00058200
* PROCEDURE DIVISION 00058300
* -------------------------------------------------------------- *00058400
* 00058500
PROCEDURE DIVISION. 00058600
MOVE 'WPDMQ851C' TO MQI-PUT-QMGR.
MOVE 'svc.casmDMQ1' TO MQCSP-USERID.
MOVE 'WdRGP24q' TO MQCSP-PASSWORD.
*
* MQCNO Setup
*
MOVE MQCNO-STANDARD-BINDING TO MQCNO-OPTIONS.
MOVE MQCNO-VERSION-5 TO MQCNO-VERSION.
*
* MQCD Setup
*
* MOVE MQI-PUT-QMGR TO MQCD-QMGRNAME.
* MOVE 'CASM.WPDMQ851C' TO MQCD-CHANNELNAME.
* MOVE 'WPQMQ851a.ads.z.com(1416)' TO MQCD-CONNECTIONNAME.
* MOVE MQCHT-CLNTCONN TO MQCD-CHANNELTYPE.
* MOVE MQXPT-TCP TO MQCD-TRANSPORTTYPE.
* MOVE LENGTH MQCNO TO MQCNO-CLIENTCONNOFFSET.
*
* MQCSP Setup
*
MOVE LENGTH MQCNO TO MQCNO-SECURITYPARMSOFFSET.
* ADD LENGTH MQCD TO MQCNO-SECURITYPARMSOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPUSERIDOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPPASSWORDOFFSET.
* ADD LENGTH MQCSP-USERID TO
* MQCSP-CSPPASSWORDOFFSET.
* MOVE ADDRESS OF MQCSP-USERID TO
* MQCSP-CSPUSERIDPTR.
* MOVE ADDRESS OF MQCSP-PASSWORD TO
* MQCSP-CSPPASSWORDPTR.
* MOVE MQCSP-AUTH-USER-ID-AND-PWD TO
* MQCSP-AUTHENTICATIONTYPE.
* MOVE 12 TO MQCSP-CSPUSERIDLENGTH
* MOVE 8 TO MQCSP-CSPPASSWORDLENGTH
CALL 'MQCONNX' USING MQI-PUT-QMGR,
MQI-MQCONNX-DATA,
MQI-PUT-HCONN,
MQI-PUT-COMPCODE,
MQI-PUT-REASON
END-CALL.
* 00203100
IF MQI-PUT-COMPCODE = MQCC-OK 00203200
DISPLAY 'CALL OK'
MOVE MQCC-OK TO RETURN-CODE
ELSE
MOVE MQI-PUT-REASON TO ANUMBER
DISPLAY 'CALL FAILED ' ANUMBER
END-IF. 00205500
STOP RUN.
|
At the moment, this is setup to use the MQCNO-SECURITYPARMSOFFSET. I am passing an initialized MQCSP. There is no USERID or PASSWORD set. It doesn't matter, because when I call this, it SIGSEV's. Even when I do set them.
I initially thought I might have to provide the MQCD, but I don't think that is true.
Thanks in advance! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun May 24, 2015 9:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Code: |
MOVE LENGTH MQCNO TO MQCNO-SECURITYPARMSOFFSET.
* ADD LENGTH MQCD TO MQCNO-SECURITYPARMSOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPUSERIDOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPPASSWORDOFFSET.
* ADD LENGTH MQCSP-USERID TO
* MQCSP-CSPPASSWORDOFFSET.
|
This is where I believe you are going wrong.
The first line seems fine.
Why would you move the full length of MQCSP to userID offset when the userid is a field of MQCSP??? This should probably be the length from the begin of the MQCSP structure to the start of the MQCSP-USERID field....
The same way you need to determine what the point of origin is to calculate accurately the offset for the password field.
Then there is the point of whether the offset applies to the field length or to the pointers... Trial and error will tell.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| TheAndroid |
| Posted: Mon May 25, 2015 9:21 am Post subject: |
|
|
Novice
Joined: 04 Dec 2007
Posts: 23
|
| fjb_saper wrote: |
| Code: |
MOVE LENGTH MQCNO TO MQCNO-SECURITYPARMSOFFSET.
* ADD LENGTH MQCD TO MQCNO-SECURITYPARMSOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPUSERIDOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPPASSWORDOFFSET.
* ADD LENGTH MQCSP-USERID TO
* MQCSP-CSPPASSWORDOFFSET.
|
|
The MQI API help states the MQCNO-SECURITYPARMOFFSET is a positive or negative value from the beginning of the MQCNO proper. In my case, I have declared them right after each other. So, the COBOL compiler is making them contiguous in memory which puts the start of the MQCSP immediately after the MQCNO. That's why I use the length of the MQCNO.
Now, the API also states that the offsets within the the MQCSP are positive or negative but it doesn't state if that's from the beginning of the MQCSP or the MQCNO. In this example, it doesn't matter because I've commented out all of the field setting in the MQCSP and I am only sending an initialized structure which at least should net me an successful call with a non-zero REASON-CODE, not a complete abend.
| Quote: |
Then there is the point of whether the offset applies to the field length or to the pointers... Trial and error will tell.
|
I'm not entirely sure what you mean here. I thought one used either the PTR or the OFFSET, not both. Is that incorrect?
Thanks! |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon May 25, 2015 9:44 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| TheAndroid wrote: |
| In my case, I have declared them right after each other. So, the COBOL compiler is making them contiguous in memory which puts the start of the MQCSP immediately after the MQCNO. |
Did you confirm from the COBOL compiler output that they are contiguous in memory? You can not always assume that. Sometimes the compiler needs to insert "padding" bytes in order for variables to be properly memory aligned.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| TheAndroid |
| Posted: Mon May 25, 2015 3:24 pm Post subject: |
|
|
Novice
Joined: 04 Dec 2007
Posts: 23
|
Initially, I worried about that too. Here is the output from the cross reference portion of the listing:
| Code: |
*> 48 MQI-MQCONNX-DATA 0 352 Wor G AlphNum
*> 42 MQCNO 0 200 Wor G AlphNum
*> 44 MQCNO-STRUCID 0 4 Wor E AlphNum
*> 46 MQCNO-VERSION 4 4 Wor E Comp
*> 48 MQCNO-OPTIONS 8 4 Wor E Comp
*> 51 MQCNO-CLIENTCONNOFFSET 12 4 Wor E Comp
*> 53 MQCNO-CLIENTCONNPTR 16 8 Wor E Pointer
*> 56 MQCNO-CONNTAG 24 128 Wor E AlphNum
*> 59 MQCNO-SSLCONFIGPTR 152 8 Wor E Pointer
*> 61 MQCNO-SSLCONFIGOFFSET 160 4 Wor E Comp
*> 64 MQCNO-CONNECTIONID 164 24 Wor E AlphNum
*> 66 MQCNO-SECURITYPARMSOFFSET 188 4 Wor E Comp
*> 68 MQCNO-SECURITYPARMSPTR 192 8 Wor E Pointer
*> 42 MQCSP 200 56 Wor G AlphNum
*> 44 MQCSP-STRUCID 200 4 Wor E AlphNum
*> 46 MQCSP-VERSION 204 4 Wor E Comp
*> 48 MQCSP-AUTHENTICATIONTYPE 208 4 Wor E Comp
*> 50 MQCSP-RESERVED1 212 4 Wor E AlphNum
*> 52 MQCSP-CSPUSERIDPTR 216 8 Wor E Pointer
*> 54 MQCSP-CSPUSERIDOFFSET 224 4 Wor E Comp
*> 56 MQCSP-CSPUSERIDLENGTH 228 4 Wor E Comp
*> 58 MQCSP-RESERVED2 232 8 Wor E AlphNum
*> 60 MQCSP-CSPPASSWORDPTR 240 8 Wor E Pointer
*> 62 MQCSP-CSPPASSWORDOFFSET 248 4 Wor E Comp
*> 64 MQCSP-CSPPASSWORDLENGTH 252 4 Wor E Comp
*> 52 MQCSP-USERID 256 48 Wor E AlphNum
*> 53 MQCSP-PASSWORD 304 48 Wor E AlphNum
|
As can be seen, they are all collected under the 01 MQI-MQCONNX-DATA area and do appear to be contiguous. For fun, I wrote a little C .so that mimcs the signature of MQCONNX for COBOL and the pointer it receives for MQCNO does show the bytes contiguous. It also shows the offsets being set correctly.
The copybooks for this installation define the MQENC_NATIVE to be 273 which is standard COBOL Binary Integers, Decimal and IEEE Floats. (All high endian).
By all rights, this should work. I simply cannot figure out why it does not. |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon May 25, 2015 3:59 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
The next step I would do is run a client trace (i.e. strmqtrc -t api -p prgmName) and see what value is being passed to the MQ MQCONNX API for that MQCNO-SECURITYPARMSOFFSET field. In the trace, does the endianess of the Version field in your CNO structure match the endianess of this MQCNO-SECURITYPARMSOFFSET field?
You mentioned that this is Linux 64 bit. Do you know what is the environment (i.e. x86, Linux on Z, etc.)?
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue May 26, 2015 12:08 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Some of your 'MOVE's don't make any sense.
| TheAndroid wrote: |
| Code: |
MOVE LENGTH MQCNO TO MQCNO-SECURITYPARMSOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPUSERIDOFFSET.
* MOVE LENGTH MQCSP TO MQCSP-CSPPASSWORDOFFSET.
* ADD LENGTH MQCSP-USERID TO
* MQCSP-CSPPASSWORDOFFSET. |
|
I can't find any COBOL samples right now using MQCNO & MQCSP, but you should be keeping the offsets to 0 (unless you are doing something wierd).
Here is a snippet of MQCNO & MQCSP using C :
| Code: |
MQCNO CNO = {MQCNO_DEFAULT};
MQCD CD = {MQCD_CLIENT_CONN_DEFAULT};
MQCSP CSP = {MQCSP_DEFAULT};
MQHCONN Hcon;
MQLONG CompCode;
MQLONG Reason;
char QMgrName[MQ_Q_MGR_NAME_LENGTH+1];
strncpy(QMgrName, argv[1], MQ_Q_MGR_NAME_LENGTH);
QMgrName[MQ_Q_MGR_NAME_LENGTH] = '\0';
strncpy(CD.ChannelName,
argv[2],
MQ_CHANNEL_NAME_LENGTH);
strncpy(CD.ConnectionName,
argv[3],
MQ_CONN_NAME_LENGTH);
CSP.AuthenticationType = MQCSP_AUTH_USER_ID_AND_PWD;
CSP.CSPUserIdPtr = &myUserId;
CSP.CSPUserIdOffset = 0;
CSP.CSPUserIdLength = strlen(myUserId);
CSP.CSPPasswordPtr = &myPassword;
CSP.CSPPasswordOffset = 0;
CSP.CSPPasswordLength = strlen(myPassword);
CNO.CDPtr = &CD;
CNO.Version = MQCNO_VERSION_5;
CNO.SecurityParmsPtr = &CSP;
CNO.SecurityParmsOffset = 0;
MQCONNX(QMgrName, &CNO, &Hcon, &CompCode, &Reason); |
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| TheAndroid |
| Posted: Wed May 27, 2015 7:43 am Post subject: |
|
|
Novice
Joined: 04 Dec 2007
Posts: 23
|
All,
It turns out this IS a problem with IBM's implementation of libmqicb.so. Or the documentation. Or the CMQCSPV copybook. Take your pick.
The MQCSP documentation states that the offsets and lengths within the MQCSP must be in the format native to the "local MQ server". I'm using the MQClient, but I think this means whatever is doing the validation. In my case, that is a Windows WebSphere server. The documentation further states to look at the MQENC_DEFAULT to determine what that format should be.
In the COBOL copybooks, MQENC_DEFAULT is set to 273. Which means MQENC_INTEGER is NORMAL (high endian). But, as I am on an I64-x86 platform talking to a Windows MQ Server, the "local MQ Server" is really little endian.
However, CMQCSPV declares all of the fields to be BINARY which for most COBOL compilers means COBOL format integers. By the language spec, those are high endian regardless of the platform.
libmqicb.so's job is to convert these values into something the C version of the API can use. It apparently doesn't do this for all of MQCSP's fields.
The final solution?
| Code: |
REPLACE ==BINARY== BY ==COMP-5==.
COPY CMQSPV.
REPLACE OFF.
|
This will get the offsets and lengths in platform native format. Which for me is mostly correct. However, you STILL can't use the offsets. You have to use COBOL POINTERS to make the call. The MQCSP-CSPUSERIDLENGTH and MQCSP-CSPPASSWORDLENGTH are now correct, but the offsets are not. They apparently need to be truly in COBOL format. Either way, using pointers and COMP-5 in combination works.
Many, many thanks to Mr. Millington for figuring this out for me. What a nightmare! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 27, 2015 8:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| It's not unreasonable to expect that all MQ documentation that talks about COBOL expects you to be running on zed. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed May 27, 2015 8:37 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
You might want to open a PMR with IBM to confirm how this should work for a COBOL MQ Client running on a x86 platform.
In the MQ Encoding constant documentation ->http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ref.dev.doc/q091390_.htm
It does have this "odd" scenario of Microfocus COBOL on Windows being "normal" or big endian (17 = x'11') on a little endian platform (Windows is x86 which is little endian). This is a very odd scenario, for sure.
You shouldn't really have to play games with the MQ copybooks, to get this to work, I would think.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed May 27, 2015 12:33 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
One other thought. When you built your COBOL client program, you linked with the correct MQ shared object file (i.e. lmqicb)?
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| TheAndroid |
| Posted: Wed May 27, 2015 2:02 pm Post subject: |
|
|
Novice
Joined: 04 Dec 2007
Posts: 23
|
I did use libmqicb.so. So, I know the COBOL interfaces were in force.
I agree that I shouldn't "have" to mess about with the copybooks.
If IBM did not want COBOL to be used on platforms other than z/OS, why would they offer 64bit copybooks for them with the various clients?
This sounds like a bit of collusion on IBM and MicroFocus parts. There are more than just one COBOL compiler for Open Systems. However, that "odd" scenario is an artifact of how the COBOL language spec defines the format for BINARY. It is always, always, High Endian. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed May 27, 2015 2:25 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Based on the MQ manual, IBM does support COBOL on other platforms than z/OS. For example, Micro Focus COBOL on Linux, like you are doing.
Based on my reading, Micro Focus COBOL has this "odd" behavior where they keep BINARY fields as big endian (regardless of the endianness of the processor), and then allow you to use the COMP-5 field when you need to match the endianness of the processor.
On Linux x86, it looks to me that MQ is expecting you to use the COBOL MQ copybooks where the binary integer fields are BINARY or big endian. Their shared object files (i.e. mqicb) would then be expecting the binary integer data in big endian and acting on it accordingly.
My two cents, I would not play with the endianness of those COBOL copybooks, and if your program does not work as intended, I would go the PMR route, as this could be a bug.
Also, if you haven't already, it would be very interesting to go back to your original program and run the MQ client trace (strmqtrc -t api -p PrgmName). Especially, does the endianness of the Version field of the MQCNO structure match the endianness of the offset field that you were having issue with. If not, I would think that would be good evidence where the IBM client code didn't properly handle the endianness switching from big to little endian before passing the data into their MQCONNX API.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu May 28, 2015 4:42 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
One other comment on the client tracing. You would need to do "strmqtrc -t all -p prgmname" to get the trace data that you need.
In your original post, you mentioned the followiong error:
| Quote: |
# SIGSEGV (0xb) at pc=0x00007fe86e82b4e3, pid=17685, tid=140636516181760
# Problematic frame:
# C [libmqiz.so+0x514e3] reqDuplicateCno+0x6c3
|
This is a SIGSEGV in the reqDuplicateCno function of the libmqiz.so shared object file. The reqDuplicateCno function should appear in your client trace (with -t all) and look somethig as follows:
| Code: |
18:13:18.064987 5683.1 RSESS:000001 ---{ reqDuplicateCno
18:13:18.064990 5683.1 RSESS:000001 ----{ xcsGetMemFn
18:13:18.064993 5683.1 RSESS:000001 component:20 function:860 length:200 options:0 cbmindex:-1 *pointer:0x62c3d0
18:13:18.064995 5683.1 RSESS:000001 ----} xcsGetMemFn rc=OK FunctionTime=5
18:13:18.064997 5683.1 RSESS:000001 Copying CNO (0x7fff0439e4a0) v(5) to CNO (0x62c3d0)
18:13:18.064999 5683.1 RSESS:000001 ----{ reqGetMQCDLen
18:13:18.065001 5683.1 RSESS:000001 ----} reqGetMQCDLen rc=OK FunctionTime=2
18:13:18.065002 5683.1 RSESS:000001 ----{ xcsGetMemFn
18:13:18.065005 5683.1 RSESS:000001 component:20 function:860 length:1984 options:0 cbmindex:0 *pointer:0x62cb40
18:13:18.065006 5683.1 RSESS:000001 ----} xcsGetMemFn rc=OK FunctionTime=4
18:13:18.065009 5683.1 RSESS:000001 Copying MQCD (0x7fff0439e880) v(6) to MQCD (0x62cb40)
18:13:18.065010 5683.1 RSESS:000001 ----{ xcsGetMemFn
18:13:18.065013 5683.1 RSESS:000001 component:20 function:860 length:56 options:0 cbmindex:-1 *pointer:0x62c4c0
18:13:18.065014 5683.1 RSESS:000001 ----} xcsGetMemFn rc=OK FunctionTime=4
18:13:18.065016 5683.1 RSESS:000001 ----{ xcsGetMemFn
18:13:18.065019 5683.1 RSESS:000001 component:20 function:860 length:8 options:0 cbmindex:-1 *pointer:0x629070
18:13:18.065028 5683.1 RSESS:000001 ----} xcsGetMemFn rc=OK FunctionTime=12
18:13:18.065030 5683.1 RSESS:000001 ----{ xcsGetMemFn
18:13:18.065032 5683.1 RSESS:000001 component:20 function:860 length:8 options:0 cbmindex:-1 *pointer:0x621db0
18:13:18.065034 5683.1 RSESS:000001 ----} xcsGetMemFn rc=OK FunctionTime=4
18:13:18.065036 5683.1 RSESS:000001 ---} reqDuplicateCno rc=OK FunctionTime=49
|
This was taken of a trace of the amqscnxc program. What the above trace snippet is showing is that the reqDuplicateCno function is taking the CNO that amqscnxc passed into the MQCONNX call and copying its contents to another memory location. The address 0x7fff0439e4a0 is the CNO in the amscnxc program (i.e. on the main function stack frame) and the address 0x62c3d0 that the CNO is being copied to is on the heap. So basically MQ is stepping through the CNO that is being passed into MQCONNX and allocating memory on the heap and copying the passed in CNO onto these memory allocations on the heap.
This line is where MQ allocates the memory on the heap for the MQCSP structure. The MQCSP is 56 bytes in length.
| Quote: |
18:13:18.065013 5683.1 RSESS:000001 component:20 function:860 length:56 options:0 cbmindex:-1 *pointer:0x62c4c0
18:13:18.065014 5683.1 RSESS:000001 ----} xcsGetMemFn rc=OK FunctionTime=4
18:13:18.065016 5683.1 RSESS:000001 ----{ xcsGetMemFn
|
If you get the SIGSEGV around that point, it may point to the possibility that this MQ function had problems with handling your passed in offset. An strace would probably show if it interpreted the offset with the wrong endianess and was trying to access memory in the wrong place.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
