Author |
Message
|
rajeevreddy |
Posted: Tue Dec 23, 2008 8:41 pm Post subject: Variable OCCURS in COBOL Copy book |
|
|
Apprentice
Joined: 07 Sep 2004 Posts: 39
|
I need your help in handling COBOL Copy book OCCURS .... below is the element from my CC book.
05 Bank_Address_Info OCCURS 125
INDEXED BY ITEM
My question is,
.How to handle OCCURS if the in coming message doesn't repeats Bank_Address_Info 125 times.
.What properties do i need to set at the message set level to handle variable occurs clause.
.How to handle if some of the Bank_Address_Info occurs with NULL values or spaces.
Thanks in advance.
[/quote] |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Dec 23, 2008 9:53 pm Post subject: Re: Variable OCCURS in COBOL Copy book |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
rajeevreddy wrote: |
I need your help in handling COBOL Copy book OCCURS .... below is the element from my CC book.
05 Bank_Address_Info OCCURS 125
INDEXED BY ITEM
My question is,
.How to handle OCCURS if the in coming message doesn't repeats Bank_Address_Info 125 times.
.What properties do i need to set at the message set level to handle variable occurs clause.
.How to handle if some of the Bank_Address_Info occurs with NULL values or spaces.
Thanks in advance.
|
OK.
1st you need to make sure when you import the cobol copy book to always click next and go to the last panel before clicking finish. On the 3rd panel you can set default values for null fields, padding and so on.
In the ESQL loop 125 times mapping the fields.
If there is nothing to map use SET field VALUE = NULL;
This way your loop is initialized.
The message set will take care of substituting the null values with the default null as defined during the copy book import.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
rajeevreddy |
Posted: Tue Dec 23, 2008 10:24 pm Post subject: |
|
|
Apprentice
Joined: 07 Sep 2004 Posts: 39
|
Thanks for your response,
My total length of the CC book shows 3681 bytes from RHFUTIL. But when i check the msg from the rfhutil, i see after 546 bytes the data is all 4040's till 3681 bytes HEX value. As you said i have made chages to my cc book while importing...i have selected 0x00 for NULL and SPACE for strings...but still i get below error
ConversionException BIP5505E: A data conversion failed because the data was invalid.
Type of data being read: 'External decimal - Invalid Positive sign code'
Data: 64
Can you suggest me how to handle when i get all spaces (40404040 after 546 bytes)
Thanks |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Dec 24, 2008 4:05 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
rajeevreddy wrote: |
Thanks for your response,
My total length of the CC book shows 3681 bytes from RHFUTIL. But when i check the msg from the rfhutil, i see after 546 bytes the data is all 4040's till 3681 bytes HEX value. As you said i have made chages to my cc book while importing...i have selected 0x00 for NULL and SPACE for strings...but still i get below error
ConversionException BIP5505E: A data conversion failed because the data was invalid.
Type of data being read: 'External decimal - Invalid Positive sign code'
Data: 64
Can you suggest me how to handle when i get all spaces (40404040 after 546 bytes)
Thanks |
The content of your message suggests you should have chosen SPACE as null value in your import instead of hex 00.
The data you get needs to conform. _________________ MQ & Broker admin |
|
Back to top |
|
 |
rajeevreddy |
Posted: Wed Dec 24, 2008 9:14 am Post subject: |
|
|
Apprentice
Joined: 07 Sep 2004 Posts: 39
|
As you suggested i have made changes to messageset by selecting SPACE for NUL values. But still i get below error,
See the following errors for more details.
2008-12-24 09:09:34.807346 10204 ConversionException BIP5505E: A data conversion failed because the data was invalid.
Type of data being read: 'packed decimal, no sign found '
Data: '0x0000' .
Its failing at the element
25 SOA1-ACTUAL-YR PIC 999 COMP-3.
Thanks. |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Wed Dec 24, 2008 2:43 pm Post subject: |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
Welcome to dealing with COBOL messages where programmers do not bother with initializing data fields that they do not use.
I expect that is what is happening to the COMP-3 field.
My recommendation is that you take a sample message from the mainframe and try to read it using RFHutil - and have RFUutil process it with the COBOL copybook. Then you can see just how many fields are not properly initialized. _________________ Bill Matthews |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Dec 24, 2008 6:48 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Bill.Matthews wrote: |
Welcome to dealing with COBOL messages where programmers do not bother with initializing data fields that they do not use.
I expect that is what is happening to the COMP-3 field.
My recommendation is that you take a sample message from the mainframe and try to read it using RFHutil - and have RFUutil process it with the COBOL copybook. Then you can see just how many fields are not properly initialized. |
Bill, if the field is declared as nillable and the null value is marked as spaces (0x40 in ebcdic) shouldn't the parser be able to get passed the point if the field is filled with spaces? _________________ MQ & Broker admin |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Thu Dec 25, 2008 8:56 am Post subject: |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
I can see several potential problems here.
The original question describes a COBOL definition with an OCCURS 125. The parser will require that all 125 copies will be present. On 12/24, he states that the message (of length 3681) has 546 bytes of valid data and the rest is blank (i.e. x'40' in EBCDIC).
I suspect that the CICS application (my assumption) has done a EXEC CICS Getmain with an Initimg of x'40'. This would explain why the remainder of the message is blank.
What we do not know at this time is if the repeating structure is at the end of the message (but it probably is) of if there is more data following. Should it be at the end --- and if the host application could be changed and there are no other applications that are dependent on the structure --- than a OCCURS DEPENDING ON could be a possible solution.
At a minimum, the host application should be changed to loop through all unused "segments" and initialize all of the COMP fields to a proper value.
One of these is the proper solution.
If the above is not possible then processing of the message is going to be a challenge.
The CWF (Binary) parser requires that these fields be in the proper format.
................................
Personally I have never used the nillable attributes with a COBOL message - it would be very nice if there were a set of attribute specifications that would solve this problem.
The good news is that the CICS application did initialize the buffer - It can get very contact admin when that is not done and there is leftover data there.
.......................
Perhaps the TDS parser might help - if the broker is at a 6.1 level. _________________ Bill Matthews |
|
Back to top |
|
 |
kimbert |
Posted: Thu Jan 01, 2009 4:26 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Bill: Your last post was not correct. fjp_saper's advice is mostly correct. The null handlng feature of the MRM parser was designed for scenarios like this one, where the incoming data is not valid for the physical type.
rajeevreddy: You need to set the properties of SOA1-ACTUAL-YR as follows:
- Encoding Null Numeric should be set to 'Null Literal Fill'
- Encoding Null Value should be set to 0x40
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ad15390_.htm
If that does not work, please take a user trace and post the relevant section of it here. |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Thu Jan 01, 2009 4:37 pm Post subject: |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
I'm pleased to be corrected... _________________ Bill Matthews |
|
Back to top |
|
 |
|