| Author |
Message
|
| mikav |
 Posted: Tue Jan 08, 2013 8:59 am Post subject: Use of External Decimal |
 |
|
Newbie
Joined: 08 Jan 2013
Posts: 8
|
WMB v7.0.0.3
We have a mainframe file which is composed of PIC X, PIC 9, PIC S9 and PIC S9V99 for which we have a copybook.
We've built a message set by importing the copybook and the PIC S9V99 have come out as External Decimal with Trailing Overpunched as Sign Orientation. This seems to match what is in the Info Center.
When we try and parse the file, we're getting an error:
| Code: |
ConversionException BIP5505E: A data conversion failed because the data was invalid.
Type of data being read: 'decimal'
Data: '0.0;'
Data conversion when reading or writing a message failed because the input data was invalid for the output data type. |
While this file originates in the mainframe, it has been converted to ASCII, and the field in question contains the following data:
(Hex 30s followed by a Hex 7B)
We think the field definition is correct; is it? Should we change either encoding and/or codepage to a specific value? We've tried broker default and 819 codepage with the same error.
Any suggestions are welcome. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Jan 08, 2013 9:42 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I would change the Input node to Input Message Parsing type BLOB, trim the '{' character off the data, then parse the data in a Compute node according to the message set.
I would also open a PMR to get IBM's opinion regarding other options that may avoid the error.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 08, 2013 9:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| I would change the Input node to Input Message Parsing type BLOB, trim the '{' character off the data, then parse the data in a Compute node according to the message set. |
Given that the '7B' appears to be the representation of an overpunched sign on the last digit of the number chopping it off (even assuming there's only one such number convieniently located at the end of the file) seems rather an unwise thing to do or advise.
@mikva
What is the target OS?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| NealM |
| Posted: Tue Jan 08, 2013 9:54 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
You are dealing with signed decimal, so you really shouldn't be chopping off the last (signed) digit. But, two questions:
1. When you built your message set, did you remember to set your Source platform to "Z/OS" on the Import options page of the wizard?
2. Where are you doing your conversion to ASCII? In the MQ channel or in the flow? The latter is preferable. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 08, 2013 9:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| NealM wrote: |
| 2. Where are you doing your conversion to ASCII? In the MQ channel or in the flow? The latter is preferable. |
The OP said "file", so I suspect that WMQ does not appear in this drama.
Assuming that, it would follow that the conversion is being done by the ftp / transfer process from the mainframe.
I'm sure the OP will confirm or deny shortly. Once he's recovered from being advised to hack a digit off.
"If thy last byte offends thee, pluck it off". 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mikav |
| Posted: Tue Jan 08, 2013 11:27 am Post subject: |
|
|
Newbie
Joined: 08 Jan 2013
Posts: 8
|
Hi everybody. Thank you for quick answers.
| Vitor wrote: |
| lancelotlinc wrote: |
| I would change the Input node to Input Message Parsing type BLOB, trim the '{' character off the data, then parse the data in a Compute node according to the message set. |
Given that the '7B' appears to be the representation of an overpunched sign on the last digit of the number chopping it off (even assuming there's only one such number convieniently located at the end of the file) seems rather an unwise thing to do or advise.
@mikva
What is the target OS? |
Yes. You are correct. I would not like to truncate the data, because of the reason above.
The target OS? At the moment I'm developing on Windows, but it will eventually run on Solaris.
| NealM wrote: |
You are dealing with signed decimal, so you really shouldn't be chopping off the last (signed) digit. But, two questions:
1. When you built your message set, did you remember to set your Source platform to "Z/OS" on the Import options page of the wizard?
2. Where are you doing your conversion to ASCII? In the MQ channel or in the flow? The latter is preferable. |
1. I can't be absolutely sure that I did, but I can try recreating the message set momentarily and make sure I set the above option.
2. We're dealing with a file and the conversion is done by the transfer process from the mainframe.
| Vitor wrote: |
| NealM wrote: |
| 2. Where are you doing your conversion to ASCII? In the MQ channel or in the flow? The latter is preferable. |
The OP said "file", so I suspect that WMQ does not appear in this drama.
Assuming that, it would follow that the conversion is being done by the ftp / transfer process from the mainframe.
I'm sure the OP will confirm or deny shortly. Once he's recovered from being advised to hack a digit off.
"If thy last byte offends thee, pluck it off". |
As mentioned above, you are correct.  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 08, 2013 11:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mikav wrote: |
| NealM wrote: |
You are dealing with signed decimal, so you really shouldn't be chopping off the last (signed) digit. But, two questions:
1. When you built your message set, did you remember to set your Source platform to "Z/OS" on the Import options page of the wizard?
2. Where are you doing your conversion to ASCII? In the MQ channel or in the flow? The latter is preferable. |
1. I can't be absolutely sure that I did, but I can try recreating the message set momentarily and make sure I set the above option.
2. We're dealing with a file and the conversion is done by the transfer process from the mainframe. |
Particularly since you are going to be developing on Windows and running on Solaris, it is a much better idea to disable the conversion in the transfer process, and allow the file to move as binary data. Then make sure that the FileInput node that is reading the file and the message set that is parsing the file have sufficient information to understand the file in it's mainframe format.
That way you won't run into issues where you can process the file when it's converted to Windows but not when it's converted to Solaris by the transfer process.... |
|
| Back to top |
|
|
| mikav |
| Posted: Tue Jan 08, 2013 11:40 am Post subject: |
|
|
Newbie
Joined: 08 Jan 2013
Posts: 8
|
| mqjeff wrote: |
| mikav wrote: |
| NealM wrote: |
You are dealing with signed decimal, so you really shouldn't be chopping off the last (signed) digit. But, two questions:
1. When you built your message set, did you remember to set your Source platform to "Z/OS" on the Import options page of the wizard?
2. Where are you doing your conversion to ASCII? In the MQ channel or in the flow? The latter is preferable. |
1. I can't be absolutely sure that I did, but I can try recreating the message set momentarily and make sure I set the above option.
2. We're dealing with a file and the conversion is done by the transfer process from the mainframe. |
Particularly since you are going to be developing on Windows and running on Solaris, it is a much better idea to disable the conversion in the transfer process, and allow the file to move as binary data. Then make sure that the FileInput node that is reading the file and the message set that is parsing the file have sufficient information to understand the file in it's mainframe format.
That way you won't run into issues where you can process the file when it's converted to Windows but not when it's converted to Solaris by the transfer process.... |
Yes, I do see your point. However, the reason the file is being converted in the first place is so that it will be readable by the support people who have no access to tools that can read EBCDIC or encoded binary formats. |
|
| Back to top |
|
|
| NealM |
| Posted: Tue Jan 08, 2013 11:46 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
| However, the reason the file is being converted in the first place is so that it will be readable by the support people who have no access to tools that can read EBCDIC or encoded binary formats. |
Well, are these support people somehow looking at the file in transit to the Broker? Once it has arrived at the Broker, the flow can safely convert it to whatever format and/or CCSID you want. And if a signed decimal value is bothersome, then you will need to do some more conversion beyond just a CCSID change. In COBOL, that +/- sign is sharing the low end byte of the numeric field. To just show the sign at the beginning of the field adds a byte to the field's length on the file. If it is support people reading it, why not give them XML to read instead? |
|
| Back to top |
|
|
| mikav |
| Posted: Tue Jan 08, 2013 1:41 pm Post subject: |
|
|
Newbie
Joined: 08 Jan 2013
Posts: 8
|
| NealM wrote: |
| Quote: |
| However, the reason the file is being converted in the first place is so that it will be readable by the support people who have no access to tools that can read EBCDIC or encoded binary formats. |
Well, are these support people somehow looking at the file in transit to the Broker? Once it has arrived at the Broker, the flow can safely convert it to whatever format and/or CCSID you want. And if a signed decimal value is bothersome, then you will need to do some more conversion beyond just a CCSID change. In COBOL, that +/- sign is sharing the low end byte of the numeric field. To just show the sign at the beginning of the field adds a byte to the field's length on the file. If it is support people reading it, why not give them XML to read instead? |
They may, but mostly because they may need to examine processed files in the mqsiarchive folder once processing has been completed to aid downstream diagnostics.
XML? We're actually producing XML from this input file, which is then put on an MQ. They have access to this as well, but may want to compare the produced XML to the input file.
Did you have any particular kind of conversion or CCSID in mind? |
|
| Back to top |
|
|
| NealM |
| Posted: Tue Jan 08, 2013 4:46 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
| Did you have any particular kind of conversion or CCSID in mind? |
No, not really. If you are converting to XML and using an .xsd, then you already are likely using the decimal datatype and (if not using the mapping node) casting as Char, so the +/- sign is taken care of.
And regarding CCSIDs, this always works:
| Code: |
SET OutputRoot.Properties.CodedCharSetId=1208;
SET OutputRoot.Properties.Encoding=546;
|
|
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jan 09, 2013 4:59 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| 2. We're dealing with a file and the conversion is done by the transfer process from the mainframe. |
That is the source of your problem. The COBOL importer assumes that the file will be in EBCDIC. Have you tried using the 'Sign EBCDIC Custom Overpunched' option in the CWF properties? |
|
| Back to top |
|
|
| mikav |
| Posted: Thu Jan 17, 2013 8:54 am Post subject: |
|
|
Newbie
Joined: 08 Jan 2013
Posts: 8
|
Sorry for being slow on replying. I managed to get sick and spent a lot of time lying in bed doing nothing.
| kimbert wrote: |
| Quote: |
| 2. We're dealing with a file and the conversion is done by the transfer process from the mainframe. |
That is the source of your problem. The COBOL importer assumes that the file will be in EBCDIC. Have you tried using the 'Sign EBCDIC Custom Overpunched' option in the CWF properties? |
Thank you very much! This solved the problem. It takes a while to go through all the elements in the message set to find all signed decimals and integers and making sure the option is selected, but once it is done, it actually works as expected.
Thanks again.  |
|
| Back to top |
|
|
|
|
