| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQPUT1 in Assembler |
« View previous topic :: View next topic » |
| Author |
Message
|
| RNStanich |
 Posted: Wed Mar 31, 2010 7:55 am Post subject: MQPUT1 in Assembler |
 |
|
Acolyte
Joined: 23 Apr 2002
Posts: 64
|
Hi, I seem to be struggling with simply using MQPUT1 in an Assembler program. I have BUFFER defined as a F'0' - sort of treating it as an address.
The basic game plan is to get an area (GETMAIN) and point the address to BUFFER or rather put the address in the BUFFER field. So in the MQPUT1 call BUFFER is an address pointing to the message data.
Should this work???
TY
_________________
Regards, Bob |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Mar 31, 2010 10:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You want to pass the address of the address of the buffer?
Did you look at the assembler examples in the APR?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RNStanich |
| Posted: Wed Mar 31, 2010 10:32 am Post subject: |
|
|
Acolyte
Joined: 23 Apr 2002
Posts: 64
|
Hi ,TY for the response. Yes I have reviewed the APR. In their examples they have a simple scenario with a fix length 80 byte buffer. If I define a CL20 field called BUFFER then I can successfully put the message. I'm trying to set this up so the size of the BUFFER is variable depending upon the size of the message data being put to the queue.
I knew I wasn't explaining this correctly. I want to put the address of the GETMAIN area in the BUFFER field. As an example if defined as a fullword, BUFFER might contain 00142878 which is the address of the GETMAIN area.
some code might be:
L R0,=A(1000)
GETMAIN R,LV=(0)
ST R1,BUFFER
Any clearer?
_________________
Regards, Bob |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 31, 2010 12:45 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
So, you want to dynamically allocate the buffer. You can do this, but why would you want to?
As the msg length changes, you will need to GETMAIN enough virtual storage to hold the message + MQMD. Will you FREMAIN when the put is done?
This seems to be a needless expense in SVCs. May I suggest that you GETMAIN enough storage to hold the largest message your app might need to put. If your message is 100Meg, then allocate 100Meg once at the start of the program, then use the same buffer for all subsequent puts.
[edit] I'm guessing that you are trying to conserve virtual storage by only allocating what you need, when you need it.
This may have been a rule of thumb (ROT) decades ago, when processors were slow, GETMAIN allocated real storage, and real storage was limited. GETMAIN allocates virtual storage, AND real storage isn't touched until your app touches the virtual addresses.
Thus, the old ROT has become an IROT (irrational rule of thumb) - makes no sense.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Mar 31, 2010 11:29 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i agree with bruce... do not do all those getmains freemains all the time, get storage for the biggest message, the length you really put is then controled by bufferlength.
however, to answer your question
| Quote: |
some code might be:
L R0,=A(1000)
GETMAIN R,LV=(0)
ST R1,BUFFER |
If you look into the programmers reference in the MQPUT1 section (SYSTEM/390 Assembler invocation) you see, that buffer should be defined with
| Quote: |
| BUFFER DS CL(n) Message data |
So "BUFFER" is the name of the starting address of the storage (buffer) and this is passed to the MQPUT1.
But what you are doing, is to store the address of the storage (buffer) in the first 4 bytes of something you defined as "BUFFER" and pass this to the MQPUT1. This will not be resolved by MQ, and MQ will put what is addressed by "BUFFER" and not what is addressed by the first 4 Bytes of "BUFFER"
_________________
Regards, Butcher |
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Thu Apr 01, 2010 6:08 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
| Admittedly, this is a side issue, but I think IBM could have done a better job when it came to how/where data is placed. In short, IBM should have supported the option of passing a pointer to the buffer where the message is residing, similar to the other IBM access methods, e.q. BSAM, QSAM, etc. I think it's a step backwards to force the user to provide the buffer. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 01, 2010 6:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Each MQI API calls create a request parameter list (RPL) that is passed to the qmgr, not unlike EXEC CICS calls, IMS calls, and SQL calls.
The WMQ APR manual describes the structure of the RPL; and your call must conform, or it will be rejected by the queue manager (agent). This is working as designed and documented.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RNStanich |
| Posted: Thu Apr 01, 2010 6:52 am Post subject: |
|
|
Acolyte
Joined: 23 Apr 2002
Posts: 64
|
Well then I appear to be clueless here... I do not know what this ==> REASON),VL,MF=(E,CALLLST) <== is referring to, 'cause I don't know what this ==> CALLLST CALL ,(0,0,0,0,0,0,0,0,0,0,0),VL,MF=L <== represents...
So I'm confused by your suggestions and the APR. Putting aside for a moment the merits of one large GETMAIN versus serveral the fact is I would like to execute a GETMAIN for my message data and have the BUFFER parameter in the MQPUT call use it.
I guess I only can envision this by using address pointers but that does not seem possible.
If one of you could supply the magical 5+ lines of code that takes that GETMAIN area and presents it to the MQPUT API I would be most grateful...
BTW if it matters this is NOT a CICS program - this is a batch program. I have written CICS MQ programs dynamically allocating storage without any issues - admitedly those were in COBOL - this effort is in Assembler...
_________________
Regards, Bob |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 01, 2010 7:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| 'cause I don't know what this ==> CALLLST CALL ,(0,0,0,0,0,0,0,0,0,0,0),VL,MF=L <== represents... |
Not sure where you found the above.
From the WMQ APR manual MQPUT1 System/390 assembler invocation CALL MQPUT1, HCONN,OBJDESC,MSGDESC,PUTMSGOPTS,BUFFERLENGTH, X BUFFER,COMPCODE,REASON)
Declare the parameters as follows:
HCONN DS F Connection handle
OBJDESC CMQODA , Object descriptor
MSGDESC CMQMDA , Message descriptor
PUTMSGOPTS CMQPMOA , Options that control the action of MQPUT1
BUFFERLENGTH DS F Length of the message in BUFFER
BUFFER DS CL(n) Message data
COMPCODE DS F Completion code
REASON DS F Reason code qualifying COMPCODE
[edit] Back to my question: why do you want to do a GETMAIN yourself? [edit]I rephrase: why do you want to do this dynamically? GETMAIN and STORAGE OBTAIN macros acquire virtual storage as described in the Assembler manuals.
[edit] ok. i found the CALLLST code. It's in the WMQ Security in an Enterprise Environment - Redbook.
[edit]I'm curious. How do you dynamically acquire virtual storage in COBOL.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RNStanich |
| Posted: Thu Apr 01, 2010 8:17 am Post subject: |
|
|
Acolyte
Joined: 23 Apr 2002
Posts: 64
|
I found the call list in the APG under the z/OS samples...
Honestly, I was planning on a GETMAIN because I did not think it to be a big deal - but because of the addressing I guess it is.
So from what you've noted and samples in the programming guides, I define a 1MB or larger constant called BUFFER?? That's what I take away from "BUFFER DS CL(n)" - I don't think the "(n)" will assemble and link so I imagine I need a number in there...
Of course I tried that and it was calling an assembly error...
_________________
Regards, Bob |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 01, 2010 10:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I found the call list in the APG under the z/OS samples... |
Yep. There it is
| Quote: |
| Honestly, I was planning on a GETMAIN because I did not think it to be a big deal - but because of the addressing I guess it is. |
The qmgr agent expects to receive the RPL as defined in the manuals. This means that the API parameters are passed in order, not by name.
Buffer is a pointer to the BUFFER in the address-space. You can call BUFFER anything you want in your application, but most developers call it BUFFER for simplicity. Again, parameters are passed in order, not by name.
| Quote: |
| So from what you've noted and samples in the programming guides, I define a 1MB or larger constant called BUFFER?? |
Yep.
| Quote: |
That's what I take away from "BUFFER DS CL(n)" - I don't think the "(n)" will assemble and link so I imagine I need a number in there...
Of course I tried that and it was calling an assembly error... |
n is a number. You might want to read up on GETMAIN and STORAGE OBTAIN macros. n is defined there.
You should read through the APR, too. Look at the size and shape of each of the parameters for the API calls - not just the MQPUT1 call. Their descriptions and usage are very specific.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 01, 2010 11:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I have written CICS MQ programs dynamically allocating storage without any issues - admitedly those were in COBOL |
I just reread this.
I'm guessing that you acquired virtual storage dynamically with an EXEC CICS GETMAIN call, not a COBOL verb. So, technically and more precisely, you didn't acquire storage in COBOL. Rather, you asked CICS to acquire storage for use by your COBOL application.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RNStanich |
| Posted: Thu Apr 01, 2010 12:15 pm Post subject: |
|
|
Acolyte
Joined: 23 Apr 2002
Posts: 64
|
Correct on the EXEC CICS GETMAIN - I just meant the program language was COBOL. This one is Assembler.
I'll regroup and bug some Assembler folks over here; you have been very patient following up with my questions. Thank you for your time.
I'm going outta town for a few days but once I get this resolved i'll post my solution in case anyone cares...
thanks again bruce2359
_________________
Regards, Bob |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 01, 2010 12:25 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Correct on the EXEC CICS GETMAIN - I just meant the program language was COBOL |
EXEC CICS GETMAIN is a RPL call to CICS, and is not in any way COBOL.
| Quote: |
| once I get this resolved i'll post my solution |
Please do.
| Quote: |
| in case anyone cares... |
We do.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Thu Apr 01, 2010 12:28 pm; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 01, 2010 12:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RNStanich wrote: |
I'm going outta town for a few days but once I get this resolved i'll post my solution in case anyone cares...
|
I for one care. Any mainframe assembler tips are always welcome... 
Enjoy your weekend.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
