| Author |
Message
|
| ydsk |
 Posted: Thu Mar 08, 2007 8:11 pm Post subject: LLZZTranCodeData - TranCode 8 characters always ?? |
 |
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Hi,
I know that the first segment of data in a message going to an IMS txn should be like this:
LLZZTranCodeData
But it isn't clear whether TranCode has to be 8 characters always. Some argue that IMS wouldn't be able to know where the Data actually starts if TranCode is less than 8 characters.
But I have seen a message extracted from mainframe that has just 5 characters for Trancode ( 4 characters for the IMS transaction name + a blank space ) after LLZZ.
Can someone pls tell me if the TranCode can be less than 8 characters ??
Appreciate any experienced suggestions.
thnx
ydsk. |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Thu Mar 08, 2007 10:51 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
yes, ithe trancode can be less then 8 characters.
afaik, you need a blank so IMS knows when llzztrancode ends
_________________
Regards, Butcher |
|
| Back to top |
|
|
| ydsk |
| Posted: Fri Mar 09, 2007 7:46 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Butcher,
Can you pls post a link or the reference material from IBM documentation where it says it can be less than 8 characters, and we need not fill in spaces to make it 8 characters ?
And where it says it recognises by a space delimiter ?
I just want to show it to our folks here.
Thank you for the response.
regds,
ydsk. |
|
| Back to top |
|
|
| ydsk |
| Posted: Mon Mar 12, 2007 11:51 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
I am still looking for some documentation on this.
Can someone pls help.
regds,
ydsk. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Mar 12, 2007 11:56 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
|
| Back to top |
|
|
| ydsk |
| Posted: Mon Mar 12, 2007 7:00 pm Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Kevin,
thank you very much for posting the link.
I am not an IMS guy but there is something in Table 11 at the bottom of the page you posted that says:
------------------------------------------
LLZZTRANCODEDATA n bytes
LL - length of segment
ZZ - set to binary zeros
TRANCODE - IMS 1-8 byte transaction code
DATA - user data
------------------------------------------
I think it serves the purpose.
regds,
ydsk. |
|
| Back to top |
|
|
| ydsk |
| Posted: Fri Mar 16, 2007 9:51 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
We tested it again and again successfully.
The txn code doesn't have to be 8 characters.
We don't need to pad it with spaces either to make it 8 characters, if it isn't already.
I am posting this for the benefit of others in the forum.
Thanks every one for their inputs.
regds,
ydsk. |
|
| Back to top |
|
|
| shusneimtahra |
| Posted: Thu Mar 29, 2007 5:23 am Post subject: |
|
|
Novice
Joined: 28 Mar 2007
Posts: 15
|
But, How does it know identify the transaction code if it is not a fixed length field??
Also, When I try posting a message from .net client application to the queue, it is going to the DLQ stating 'MQFB_DATA_LENGTH_NEGATIVE' as the reason. Can anyone tell me what is the cause for this. We are not setting the IMS header to the message.
Thanks |
|
| Back to top |
|
|
| shusneimtahra |
| Posted: Thu Mar 29, 2007 5:42 am Post subject: 'MQFB_DATA_LENGTH_NEGATIVE' error |
|
|
Novice
Joined: 28 Mar 2007
Posts: 15
|
Hi,
Should this LL and ZZ be written to the MQMessage object as only Short? Will it create an issue if it written as a normal string which is part of the data?
Assume that the data is being constructed as a string:
'00480000BEXHLLD SO98341 03983500 58648281070115 '
Where 00480000 is the LLZZ part.
I'm getting an error 'MQFB_DATA_LENGTH_NEGATIVE' in the DLQ.
Can someone let me know what could be the reason?
Thanks |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Mar 29, 2007 6:39 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| But, How does it know identify the transaction code if it is not a fixed length field?? |
It is a fixed length field it just doesn't have fill the full 8 characters it can have trailing blanks. |
|
| Back to top |
|
|
| shusneimtahra |
| Posted: Thu Mar 29, 2007 7:12 am Post subject: |
|
|
Novice
Joined: 28 Mar 2007
Posts: 15
|
Thanks Kevin..
Can you also let me know if there is a direct relation between setting LLZZ and this 'MQFB_DATA_LENGTH_NEGATIVE' error?? |
|
| Back to top |
|
|
| ydsk |
| Posted: Thu Mar 29, 2007 9:51 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Kevin,
Please note that we tested it successfully with a 4 character transaction name by padding just 1 space. So, it was a total of 5 characters ( 4 chars for txn and 1 space).
This answers the question as to how it recognizes the end of transaction name.....it recognizes the txn name with a trailing blankspace that we padded.
It need not be 8 chars always.
Thanks.
ydsk. |
|
| Back to top |
|
|
| tleichen |
| Posted: Fri Mar 30, 2007 10:13 am Post subject: Re: 'MQFB_DATA_LENGTH_NEGATIVE' error |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| shusneimtahra wrote: |
Hi,
Should this LL and ZZ be written to the MQMessage object as only Short? Will it create an issue if it written as a normal string which is part of the data?
Assume that the data is being constructed as a string:
'00480000BEXHLLD SO98341 03983500 58648281070115 '
Where 00480000 is the LLZZ part.
I'm getting an error 'MQFB_DATA_LENGTH_NEGATIVE' in the DLQ.
Can someone let me know what could be the reason?
Thanks |
You mean you're putting the llzz in as character data? No wonder you're getting an error! The llzz is binary! Also, if you are communicating between different codesets, you have to handle the encoding problem. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| shusneimtahra |
| Posted: Fri Mar 30, 2007 11:01 am Post subject: |
|
|
Novice
Joined: 28 Mar 2007
Posts: 15
|
Thanks a lot. But can u pls elaborate on the encoding problems??
We jus realized and we have rectified LLZZ part and attaching these 2 fields as Short before the TransCode.
But, again we are not setting the Encoding and CharacterSet to any values explicitly. When I read the message from the queue, each character in the message is seperated by a dot(.).
And the message length is exactly double the length of the proper message (like if actual length is 52, it displays as 104).
Should we set the encoding and characterset to any specific value?
Thanks,
shusneimtahra |
|
| Back to top |
|
|
| tleichen |
| Posted: Fri Mar 30, 2007 11:19 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
Theoretically, you should not need to mess with the encoding and ccsid values, specifically. However, if you are sending between different platforms, the conversion will not convert the encoding of the llzz field, as they are not part of an MQSeries header. Therefore, you need to alter the byte order of these fields on the originating platform before you send them. Not sure what language you are programming in, but in C/C++ there are some library functions to handle this.
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
|
|
