IBM Mainframe Forum

There is a piece of code here (http://www.ibmmainframes.com/about42770.html) that is similar to my code. I cannot post to that forum because I have not yet been authorized.

My code is sending a message to IMS, but I receive this error:

16.26.04 STC28583 HWSP1440E INVALID LENGTH SPECIFIED IN MESSAGE PREFIX; L=538981944, M=SDRC

I understand that means my initial prefix is incorrect. The LLLL is 4 bytes, but I'm only sending two digits - 68 (total length in bytes of my message). I've tried padding 68 with two spaces to the left, or two to the right. I've tried prepending with zeros. None of which has worked. I can't find any specific reference in the documentation to address this.

Can someone offer a helpful suggestion?

I don't know IMS so I cannot help you there. But 538981944 decimal is 20203638 in hexadecimal, which is space space 6 8 in ASCII. Since IBM mainframes work in EBCDIC, using ASCII is not going to work. Furthermore, length fields on the mainframe are usually half-word or full-word binary fields so I would expect the hexadecimal value of the length to be 00000044 instead of 20203638.

Thank you Robert. That is actually very helpful. I thought that the connection information I received concerning my particular IMS Connect client said they send and receive ASCII, but I'm a bit skeptical at this point. I will verify with the support team.

Actually, they expect it all in ASCII. Not sure if that's a feature in the IMS Connect product configuration. But that's what support said.

So I'm back to my original problem. From the looks of it, space space 6 8 in ASCII should work but doesn't.

Is there anyone with experience in sending ASCII to IMS Connect familiar with the message prefix?

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:

LLLL
Fullword that specifies the total length of all data in the message.
IRM
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:

|Verify user
|The user ID and password.
Password change
The user ID, old password, and new password.
Who-am-I
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

04ZZ (optional)
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.

Robert,

Thank you for the help.

You are 100% right. I need to send x'00000044'. My problem is I have no idea how to convert that from a Windows .NET world.

Here's the sending line in my asynchronous socket prog:

byte[] byteData = Encoding.ASCII.GetBytes(data);
currentSocket.BeginSend(byteData, 0, byteData.Length, 0, new AsyncCallback(SendCallback), currentSocket);

Where 'data' is the string value of my message. I'm installing Biztalk to see if I can look under the hood and see how they do it. Biztalk has support for connecting to IMS connect and it's on a Windows platform.

Oh, and "they" are the support team controlling the IMS Connect to which I am attempting a connection. They give me the error messages from the logs and help guide me with general questions, but down to this detail.

My problem is I have no idea how to convert that from a Windows .NET world.

Figure out how to define a 32-bit integer field and set it to 68. The rest of the fields, however, may require some sort of structure -- you may need to contact IBM for help; alternatively, there may something in an IMS sample library that shows how to do this. In either case, research is called for.