With a little searching, I found the IMS Connect Extensions
manual in the IMS Information Library at IBM's web site. This manual gives
Figure 92 shows the following:
Fullword that specifies the total length of all data in the message.
The IMS request message (IRM). Use IRM_ID=*CEXSVC* in this segment. The IRM layout is defined by the HWSIMSCB macro. For additional information on this macro, see IMS Connect Guide and Reference.
Service request header
Specifies the type of service requested and the number of requests that follow. Each request is one segment, and all segments must request the same type of service.
Service request segment (one or more)
Specifies the length of the segment and the segment number and additional information depending on the type of service:
|The user ID and password.
The user ID, old password, and new password.
The field queried. The client can request one of the following per segment:
* Client ID
* The IMS Connect system identifier of the server
* IP version (IPv6 or IPv4)
* Client IP address
* Port number
* Socket type
* Event key
The end of message marker.
I don't know who "they" are that you refer to, but be aware that if you do not follow the message specification laid out here, you're going to have trouble. A fullword length field (LLLL) means just that -- it is not ASCII, it is not EBCDIC, it is 32 bits of length and if your data is 68 bytes long then you must
set these 4 bytes to x'00000044' or, as you found out, your message has problems. When IBM says "CEXSVC" in the next piece of the message, they are saying EBCDIC "CEXSVC" not ASCII "CEXSVC".
I suspect you are dealing with people not familiar with the way things are done on the mainframe, and you either need to renegotiate -- now -- or expect a very long, very involved, and very difficult development cycle.
But on the bright side your original problem is resolved. You need to send x'00000044' instead of what you are sending and the length will be okay, allowing you to get the next error message that is going to show up (probably something about not having an IRM).
Side note: properly written specifications can be a life saver here. I was in a similar situation with a customer once where the consultant was writing a network interface to our CICS program. After they had trouble getting it running, I was called in to trouble shoot. I got a data trace on the line and got to say, "Here on page 2 of our specifications we state that all communications will be in EBCDIC. You are sending us ASCII data. Correct your programs to specification." It makes figuring out who fixes what so much easier! Of course, we had almost 200 pages of specifications so it takes time to do it right.