| Author |
Message
|
| climber |
 Posted: Thu Oct 13, 2005 6:34 am Post subject: COBOL app on z/OS sending RFH2 to web app |
 |
|
Newbie
Joined: 27 Sep 2005
Posts: 7
Location: Indiana
|
I converted a perfectly good MQ COBOL application to do a "proof of concept". This involves building the RFH2 and then dropping the message in the queue for the web application. MQ works fine. It's the content of the mcd, jms, and usr that may be the problem. The response queue has WSWS3021E: THE REQUIRED TARGETSERVICE PROPERTY WAS NOT PRESENT IN THE INBOUND JMS REQUEST MESSAGE. Since the mcd, jms, and usr segments were taken almost literaly from something that was purported to run fine from the web server side, I'm running out of things to try. It doesn't look like it's ever getting far enough to even consider the xml "payload".
Any questions or suggestions would be greatly appreciated.
I'll happily supply a copy of the RFH2 layout and content along with the corresponding MQPUT routine, if anyone wants to see the actual code. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 13, 2005 6:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You wrote COBOL code to create an MQRFH2?
You know this is a dynamic length structure, right?
Can you post the results of amqsbcg on the output message from your cobol program, at least up to the end of the RFH2?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| climber |
| Posted: Thu Oct 13, 2005 6:49 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2005
Posts: 7
Location: Indiana
|
It wasn't fun, but it's possible. Since the mcd, jms, and usr portions are fairly static, the really dynamic portion will be creating the xml "payload" at the end ... always assuming that I can get the web side to recognize everything.
I've got to run off to another @#$# meeting, but I'll post what I got from the web side (the message as it looks in their queue) as soon as I get done ... probably 45 minutes. |
|
| Back to top |
|
|
| climber |
| Posted: Thu Oct 13, 2005 7:56 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2005
Posts: 7
Location: Indiana
|
Since I haven't been able to track down the mid-tier wizard, here's one that I had on file. Content down to the end of the usr.
StrucId : 'MD ' Version : 1
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 785 CodedCharSetId : 500
Format : 'MQHRF2 '
Priority : 0 Persistence : 1
MsgId : X'C3E2D840D4D8E3F14040404040404040BDB7317BCFA88923'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
StrucId : 'MD ' Version : 1
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 785 CodedCharSetId : 500
Format : 'MQHRF2 '
Priority : 0 Persistence : 1
MsgId : X'C3E2D840D4D8E3F14040404040404040BDB7317BCFA88923'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : 'CP.OFAC.RESPONSE.ALIAS '
ReplyToQMgr : 'MQT1 '
** Identity Context
UserIdentifier : 'GIPIJXY '
AccountingToken :
X'05F9F4F3F7F00000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '2'
PutApplName : 'GIPIJXYA '
PutDate : '20051005' PutTime : '14412880'
ApplOriginData : ' '
**** Message ****
length - 1090 bytes
00000000: 5246 4820 0000 0002 0000 0446 0000 0111 'RFH .......F....'
00000010: 0000 04B8 4D51 5354 5220 2020 0000 0000 '....MQSTR ....'
00000020: 0000 04B8 0000 0020 3C6D 6364 3E3C 4D73 '....... <mcd><Ms'
00000030: 643E 6A6D 735F 7465 7874 3C2F 4D73 643E 'd>jms_text</Msd>'
00000040: 3C2F 6D63 643E 2020 0000 0084 3C6A 6D73 '</mcd> ....<jms'
00000050: 3E3C 4473 743E 7175 6575 653A 2F2F 2F52 '><Dst>queue:///R'
00000060: 4D2E 4350 2E4F 4641 432E 512E 5245 5155 'M.CP.OFAC.Q.REQU'
00000070: 4553 542E 442E 414C 4941 533C 2F44 7374 'EST.D.ALIAS</Dst'
00000080: 3E3C 5274 6F3E 7175 6575 653A 2F2F 2F52 '><Rto>queue:///R'
00000090: 4D2E 4350 2E4F 4641 432E 512E 5245 5350 'M.CP.OFAC.Q.RESP'
000000A0: 4F4E 5345 2E44 2E41 4C49 4153 3C2F 5274 'ONSE.D.ALIAS</Rt'
000000B0: 6F3E 3C54 6D73 3E31 3132 3737 3632 3536 'o><Tms>112776256'
000000C0: 3538 3832 3C2F 546D 733E 3C44 6C76 3E32 '5882</Tms><Dlv>2'
000000D0: 3C2F 446C 763E 3C2F 6A6D 733E 2020 0000 '</Dlv></jms> ..'
000000E0: 0038 3C75 7372 3E3C 7461 7267 6574 5365 '.8<usr><targetSe'
000000F0: 7276 6963 653E 534F 4150 4A4D 5350 6F72 'rvice>SOAPJMSPor'
00000100: 743C 2F74 6172 6765 7453 6572 7669 6365 't</targetService'
00000110: 3E3C 2F75 7372 3E20 2020 3C3F 786D 6C20 '></usr> |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 13, 2005 10:42 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| 00000000: 5246 4820 0000 0002 0000 0446 0000 0111 'RFH .......F....' |
That's wrong. It's saying that the length of the RFH2 plus the "folders" is 1090 bytes. If you really have given all the header plus "folders", then it's only 282 (x'11a') bytes.
| Quote: |
| 00000040: 3C2F 6D63 643E 2020 0000 0084 3C6A 6D73 '</mcd> ....<jms' |
That looks worng too. The <jms> folder is 150 (x'96') bytes.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| climber |
| Posted: Thu Oct 13, 2005 10:57 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2005
Posts: 7
Location: Indiana
|
| This is indeed only the first part of the message, from the initial field of the header down to the ending of the usr data. There is a lot more that follows. Sorry about the confusion. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 13, 2005 12:34 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| This is indeed only the first part of the message, from the initial field of the header down to the ending of the usr data |
Which was exactly what I wanted to confirm. I wasn't sure if:
| Quote: |
| 00000110: 3E3C 2F75 7372 3E20 2020 3C3F 786D 6C20 '></usr> <?XML |
Was the start of the data. Which, now I've decoded it  , it obviously is. 
So, the comments I made earlier stand. You have 2 length fields set wrongly.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| climber |
| Posted: Thu Oct 13, 2005 1:18 pm Post subject: |
|
|
Newbie
Joined: 27 Sep 2005
Posts: 7
Location: Indiana
|
Thanks. It isn't unusual, not with all the iterations I've been through. :D
Here's the actual layout as of this instant. If I'm fortunate enough to trap the web wizard during tomorrow morning's conference call, we can drop one in the queue and then he can get us a new picture with AMQSBCG0:
01 MQ-HEADER-VERSION-2.
*
* SEE MQSERIES APPLICATION PROGRAMMING REFERENCE
* CHAPTER 16, RULES AND FORMATTING HEADER VERSION 2
*
* RFH2 base portion IS 40 CHARACTERS, i.e. 36 (default) + 4 for
* for the NAMEVALUELENGTH field
*
03 MQRFH-STRUCID PIC X(04) VALUE 'RFH '.
03 MQRFH-VERSION PIC S9(9) BINARY VALUE 2.
*
* MQRFH-STRUCLENGTH is the MQRFH-NAMEVALUELGTH + the length of
* everything from MQRFH-STRUCID through MQRFH-NAMEVALUELGTH
* i.e. 248 + 40 = 288
*
03 MQRFH-STRUCLENGTH PIC S9(9) BINARY value 288.
03 MQRFH-ENCODING PIC S9(9) BINARY.
03 MQRFH-CODEDCHARSETID PIC S9(9) BINARY value 500.
03 MQRFH-FORMAT PIC X(08) VALUE 'MQSTR '.
03 MQRFH-FLAGS PIC S9(9) BINARY VALUE 0.
03 MQRFH-NAMEVALUECCSID PIC S9(9) BINARY VALUE 1208.
03 MQRFH-NAMEVALUELENGTH PIC S9(9) BINARY VALUE 248.
*
* MQRFH-NAMEVALUEDATA is the next 248 characters.
*
03 MQRFH-NAMEVALUEDATA.
*
* The mcd segment is 32 characters in length + 4 = 36 CHARACTERS
*
05 RFH2-MCD-LENGTH PIC S9(9) BINARY VALUE 32.
05 FILLER PIC X(32) VALUE
'<mcd><Msd>jms_text</Msd></mcd> '.
*
* The jms segment is 148 characters in length + 4 = 152 CHARACTERS
*
* 05 RFH2-JMS-LENGTH PIC S9(9) BINARY VALUE 148.
05 FILLER PIC X(19) VALUE
'<jms><Dst>queue:///'.
*
05 RFH2-DST-QUEUE PIC X(28) VALUE
'XX.YY.ZZZZ.Q.REQUEST.D.ALIAS'.
*
05 FILLER PIC X(20) VALUE
'</Dst><Rto>queue:///'.
*
05 RFH2-RTO-QUEUE PIC X(29) VALUE
'XX.YY.ZZZZ.Q.RESPONSE.D.ALIAS'.
*
05 FILLER PIC X(11) VALUE
'</Rto><Tms>'.
*
* It would be nice to know HOW to get this date-time string
* from a COBOL program; but, since it's apparently not a
* "real" date time but rather a number related to some past
* time (such as the number of days since 1/1/1900 and other
* stupid programming tricks used on both mainframe and other
* platforms) we'll just leave it for now.
*
05 FILLER PIC X(13) VALUE
'1127762565882'.
05 FILLER PIC X(28) VALUE
'</Tms><Dlv>2</Dlv></jms> '.
*
* The usr segment is 56 characters in length + 4 = 60 CHARACTERS
*
05 RFH2-USR-LENGTH PIC S9(9) BINARY VALUE 56.
05 FILLER PIC X(31) VALUE
'<usr><targetService>SOAPJMSPort'.
05 FILLER PIC X(25) VALUE
'</targetService></usr> '.
*
* The following "payload" is 804 CHARACTERS in length
*
03 RFH2-PAYLOAD-START.
05 FILLER PIC X(20) VALUE
'<?xml version="1.0" '.
For those who gasp in horror at the idea of doing this in COBOL, it isn't my choice. I'm just a mercenary. After I get it working, pasting all the various bits and pieces together to produce a single output message, it'll be one of the ugliest pieces of code around. Sorry 'bout your duck. The client wants it this way and won't entertain any other notions. AND, just for general information, the format of the mcd, jms, usr, xml parts is stolen from an example given to us as "the way" to get this done. :( |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 1:47 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| climber wrote: |
| For those who gasp in horror at the idea of doing this in COBOL, |
I'm just impressed you've gotten *this* far.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 13, 2005 1:58 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I'm just impressed you've gotten *this* far. |
So am I.
OK, lets walk through this:
| Quote: |
* RFH2 base portion IS 40 CHARACTERS, i.e. 36 (default) + 4 for
* for the NAMEVALUELENGTH field |
Actually no, it's 36. There's no absolute reason that you have to have any name/value pairs following the header. Although, then it would be pointless having the header. 
| Quote: |
* MQRFH-STRUCLENGTH is the MQRFH-NAMEVALUELGTH + the length of
* everything from MQRFH-STRUCID through MQRFH-NAMEVALUELGTH
* i.e. 248 + 40 = 288 |
It's everything from the start of STRUCID through the end of the last NAMEVALUEDATA, which in this example is 248 + 36 = 284.
| Quote: |
| * 05 RFH2-JMS-LENGTH PIC S9(9) BINARY VALUE 148. |
Was that really supposed to be commented out. Or just a cut/paste error.
Also, it doen't match what you had in the example above. That had a length field of 132, and the data following it was 146. (The 150 above was my mistake  ). And the 146 is yet another problem. The lengths of the NAMEVALUEDATA fields must be a multiple of 4 bytes.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 13, 2005 3:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
All, Gasp a little more in Horror. I don't remember CCSID 500 being one of the accepted CCSIDs for RFH headers.... (check with the search button as the list of accepted CCSIDs has been posted before....
Enjoy  |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 13, 2005 3:13 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| 03 MQRFH-CODEDCHARSETID PIC S9(9) BINARY value 500. |
Is quite valid, as that's the data following the RFH2.
But:
| Quote: |
| 03 MQRFH-NAMEVALUECCSID PIC S9(9) BINARY VALUE 1208. |
Which can only be one of 1200, 13488, 17584, or 1208. How are you going to write data in one of these code pages from a COBOL program. 
And I didn't spot it before, but the MQMD says CCSID 500, which is EBCDIC, but the RFH2 is in ASCII. Duhhhhh.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| climber |
| Posted: Thu Oct 13, 2005 6:21 pm Post subject: |
|
|
Newbie
Joined: 27 Sep 2005
Posts: 7
Location: Indiana
|
This is the question I've been asking the "experts" for the last week. If I can still manage to read a manual (even though we all know I can't count), I've been asking "doesn't part of this garbage need to be in something other than EBCDIC". "Duh". "Like ASCII perhaps".
If I had my druthers, I'd have somebody write a JAVA program that would take care of this link between the mainframe and the web app, so that I'd just have to hand it the data I wanted checked and it would take care of all this nonsense. Oh well.
Of course, if it were done right (in my view), we wouldn't be worried about COBOL or JAVA or web apps or MQ. The data would be in a database, replicated to each of the platforms. No fuss. Mo muss. I'll take my java with sugar and make that a dark roast, please.
We'll see what the wizards have to say after the morning call.
BTW, I actually left out the one field in the RFH2 header and left the count at 36, but was told to put it back. Maybe I could order a double Jack with that java? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 6:43 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Databases are not an application to application communication mechanism.
MQ Series is.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| climber |
| Posted: Fri Oct 14, 2005 5:08 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2005
Posts: 7
Location: Indiana
|
Nope. It's not a communication mechanism, but it would resolve my immediate problem. 
Now, as to the "ASCII conversion effort", I took a few minutes last night a put the following together. I'm still working on it, but I'm trying to see if it's the right direction. If I have to, I suppose I could convert this to bit strings, divide it back up into hex, and string it together with the RFH2 header base and the xml "payload". contact admin. Realize that I haven't applied any of the "length" issue resolutions from yesterday ... yet. I'm still gathering enough bodies so I have sufficient fingers available to count.
03 RFH2-PART-2.
*
* The mcd segment is 32 characters in length
*
05 RFH2-MCD-LENGTH PIC S9(9) BINARY VALUE 32.
05 FILLER PIC X(16) VALUE
X'3C6D63643E3C4D73643E6A6D735F7465'.
* '<mcd><Msd>jms_te'.
05 FILLER PIC X(16) VALUE
X'78743C2F4D73643E3C2F6D63643E2020'.
* 'xt</Msd></mcd> '.
*
* The jms segment is 148 characters in length
*
05 RFH2-JMS-LENGTH PIC S9(9) BINARY VALUE 148.
05 FILLER PIC X(19) VALUE
X'3C6A6D733E3C4473743E71756575653A2F2F2F'.
* '<jms><Dst>queue:///'.
05 FILLER PIC X(14) VALUE
X'524D2E43502E4F4641432E512E52'.
* 'RM.CP.OFAC.Q.R'.
05 FILLER PIC X(14) VALUE
X'4551554553542E442E414C494153'.
* 'EQUEST.D.ALIAS'.
05 FILLER PIC X(20) VALUE
X'3C2F4473743E3C52746F3E71756575653A2F2F2F'.
* '</Dst><Rto>queue:///'.
05 FILLER PIC X(15) VALUE
X'524D2E43502E4F4641432E512E5245'.
* 'RM.CP.OFAC.Q.RE'.
05 FILLER PIC X(14) VALUE
X'53504F4E53452E442E414C494153'.
* 'SPONSE.D.ALIAS'.
05 FILLER PIC X(11) VALUE
X'3C2F52746F3E3C546D733E'.
* '</Rto><Tms>'.
05 FILLER PIC X(13) VALUE
X'31313237373632353635383832'.
* '1127762565882'.
05 FILLER PIC X(14) VALUE
X'3C2F546D733E3C446C763E323C2F'.
* '</Tms><Dlv>2</'.
05 FILLER PIC X(14) VALUE
X'446C763E3C2F6A6D733E20202020'.
* 'Dlv></jms> '.
*
* The usr segment is 56 characters in length
*
05 RFH2-USR-LENGTH PIC S9(9) BINARY VALUE 56.
05 FILLER PIC X(12) VALUE
X'3C7573723E3C746172676574'.
* '<usr><target'
05 FILLER PIC X(16) VALUE
X'536572766963653E534F41504A4D5350'.
* 'Service>SOAPJMSP'
05 FILLER PIC X(16) VALUE
X'6F72743C2F7461726765745365727669'.
* 'ort</targetServi'
05 FILLER PIC X(12) VALUE
X'63653E3C2F7573723E202020'.
* 'ce></usr> '.
* |
|
| Back to top |
|
|
|
|
