| Author |
Message
|
| Veera B |
 Posted: Tue Jan 29, 2013 12:47 am Post subject: having different responses b/w WINDOWS and UNIX machines |
 |
|
Voyager
Joined: 16 Jan 2013
Posts: 76
|
Hi All,
I am having an interesting scenario where the response varies on a windows machine and UNIX, even thouch the code is exactly same.
I am having a input of 3 fields 1 int and other 2 charactes in the msg body. The length of integer Filed is 15, the unix code works only when i give all 15 digits, if i decrease it gvies me a input data too short error.
But on windows this does not happen, even if i decrease the number of digits in integer field, the code works fine.
windows -> local testing, UNIX -> SIT
can someone tell me why this happens on unix box and how can this scenario be avoided even if the lenght of the input is less (as we are giving padding characters in Mset) |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Jan 29, 2013 1:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Please quote the exact error codes - 'input data too short' could be a number of things.
Also, what steps you have already taken to eliminate obvious errors in your test methodology? ( e.g. are you sure that the difference is not in your Windows/Unix test harnesses )
| Quote: |
| windows -> local testing, UNIX -> SIT |
What does that mean? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jan 29, 2013 1:33 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| kimbert wrote: |
Windows/Unix test harnesses )
| Quote: |
| windows -> local testing, UNIX -> SIT |
What does that mean? |
System Integration Test ?
Off Topic Alternatives
System Idle Timeouts
Stand In Toilet
and plenty more (and often quite rude) ones as well
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Last edited by smdavies99 on Tue Jan 29, 2013 1:35 am; edited 1 time in total |
|
| Back to top |
|
|
| Veera B |
| Posted: Tue Jan 29, 2013 1:34 am Post subject: |
|
|
Voyager
Joined: 16 Jan 2013
Posts: 76
|
The innermost error code is 5503 with "CPI Text Buffer Input Data Too Short" description
I have deployed the same bar files to both the machines, windows and unix, have tested with same data for both.
What does Test Harnesses mean in your view ? |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 29, 2013 1:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
A test harness is a program/script that runs a set of tests. Sometimes defects can arise from the test harness. It sounds as if you are not using one, so that's probably not your problem 
| Quote: |
| I have deployed the same bar files to both the machines, windows and unix, have tested with same data for both. |
It can be quite difficult to diagnose this type of problem. Are you 100% sure that the message flows are getting *exactly* the same bytes? Have you actually checked?
Could it be a character encoding ( CCSID) problem? What is 'Length Units' set to in your message definition for the integer element? |
|
| Back to top |
|
|
| Veera B |
| Posted: Tue Jan 29, 2013 5:29 pm Post subject: |
|
|
Voyager
Joined: 16 Jan 2013
Posts: 76
|
The length units is set as Bytes, and it is set a signed integer.
I am not sure about encoding(CCSID) problem, usually there will be difference in this b/w a windows and unix machine right ?
but here its a problem with giving full integer lenght or not, if i give anything less than Msgset length it is throwing error in UNIX ( and working in windows). |
|
| Back to top |
|
|
| kash3338 |
| Posted: Tue Jan 29, 2013 7:38 pm Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
Just to clarify on your problem,
What Message Set do you have?
You have mentioned you have just 3 elements in your record, is it a fixed length Message Set?
What is your EOL specified in your Message Set?
Do you have multiple records coming in your Input message?
Whats the Min Occurs and Max Occurs set for your root element? |
|
| Back to top |
|
|
| Veera B |
| Posted: Tue Jan 29, 2013 8:11 pm Post subject: |
|
|
Voyager
Joined: 16 Jan 2013
Posts: 76
|
Its a fixed length message ..
only one record incoming,
Min and mx occurs 1 ..
Just to let u know , the difference b/w windows and Unix behaviour can be parked aside, but the thing thats bugging me is :-
Why is the Integer field not taking less digits than the max length defined ?
I am aware that this is not the default behaviour .. as we have given padding chars and left/right justify ... it should take what ever length until the max length, if it is less it should just pad it with the padding chars defined ..
its not accepting anything other than the max length ... is my understanding correct about message modelling or am i missing some key info ? |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jan 30, 2013 1:33 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I am aware that this is not the default behaviour .. as we have given padding chars and left/right justify ... it should take what ever length until the max length,.. |
If the field is a fixed length integer then your input data *must* contain 15 bytes of data. You cannot truncate the input field.
| Quote: |
| if it is less it should just pad it with the padding chars defined |
Your understanding is wrong. When parsing, the full 15 bytes must be present in the data. The padding character is then trimmed from the 15-character string before the remaining digits are converted to a logical integer value. When writing, the logical integer value is converted to a string of digits. It that string is less than 15 characters long then the padding character is added to the output data to fill any unused character positions in the fixed length output field. |
|
| Back to top |
|
|
| Veera B |
| Posted: Wed Jan 30, 2013 1:50 am Post subject: |
|
|
Voyager
Joined: 16 Jan 2013
Posts: 76
|
| Quote: |
| Your understanding is wrong. When parsing, the full 15 bytes must be present in the data. The padding character is then trimmed from the 15-character string before the remaining digits are converted to a logical integer value. When writing, the logical integer value is converted to a string of digits. It that string is less than 15 characters long then the padding character is added to the output data to fill any unused character positions in the fixed length output field. |
I got confused by reading your message, If i change the length units to charaters instead of bytes will this scenario not occur ? |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jan 30, 2013 3:35 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| If i change the length units to charaters instead of bytes will this scenario not occur ? |
It depends on whether you are using a multi-byte code page. If you are using a single-byte code page ( ASCII or EBCDIC ) then lengthUnits is probably not the problem.
| Quote: |
| I got confused by reading your message |
Yes - I was using the words 'bytes' and 'characters' as if they are the same thing. Sorry!
Read it again, and hopefully it will make sense this time. The main point is this: your input data must not be truncated. You must supply all 15 bytes, even if you have specified a padding character. |
|
| Back to top |
|
|
|
|
