| Author |
Message
|
| mqjeff |
 Posted: Thu Jun 10, 2010 6:08 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqdogsbody wrote: |
| My answer has been "Call in IBM" but I have been ignored. |
Then escalate your issue through your IBM account rep. You pay good money for the license and are entitled to at least a response. |
I read this as mqdogsbody saying that he/she has told management that they should be talking to IBM and managment has said "figure it out yourself" or not responded at all, and NOT that mqdogsbody has contacted IBM and IBM has not responded.
But perhaps that is my institutional bias again. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jun 10, 2010 6:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
I read this as mqdogsbody saying that he/she has told management that they should be talking to IBM and managment has said "figure it out yourself" or not responded at all, and NOT that mqdogsbody has contacted IBM and IBM has not responded.
But perhaps that is my institutional bias again. |
No, I agree that it's a plausible alternative interpretation, and perhaps more plausible than IBM ignoring a customer.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Jun 10, 2010 8:19 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| Vitor wrote: |
| Then escalate your issue through your IBM account rep. You pay good money for the license and are entitled to at least a response. |
Maybe I am wrong but I suspect IBM's response will be to ask for a lot more "good money". As I a dogsbody I cannot authorize the spending of such money. I was hoping my boss would escalate the the question to someone who has the power.
_________________
-- mqDB -- |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 10, 2010 8:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqdogsbody wrote: |
| I was hoping my boss would escalate the the question to someone who has the power. |
Bosses are often unpredicatable & disapointing.
You could, without additional spending, raise a PMR and ask about the TSH. Even if the answer is "it depends" or "it's not documented" that will tell you something.
You could also point out to your boss that as it stands, this requirement will be met with code by a dogsbody (using your term and you should work on those self esteem issues) with the assistance of a bunch of (admittedly talented) volunteers on the Internet. Given that his career could be adversly affected if this all goes a bit wrong, he might want to consider loosening the purse strings a bit.
It's a method I've found effective in the past, though I don't use the term "dogsbody" personally.
Of course, if the purse strings are loosened you would be well advised to measure carefully the cost of bringing in IBM to help with your problem against the 3 off the shelf solutions Roger mentioned earlier in this thread, for the reasons he gave at the time.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Jun 10, 2010 8:48 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| Vitor wrote: |
| You could, without additional spending, raise a PMR and ask about the TSH. Even if the answer is "it depends" or "it's not documented" that will tell you something. |
I may be wrong but I am fairly confident that the anwer will be "it's not documented" ... perhaps followed by comments about the difference between support and training (as has happened before).
| Vitor wrote: |
| using your term and you should work on those self esteem issues |
The term reflects my assessment of the work I have been asked to do, rather than of my skills. (But things have got more interesting recently.)
Still, as Roger and others have pointed out, exits are definitely "advanced" and there is no way I can claim to be advanced when it comes to MQ.
_________________
-- mqDB -- |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 10, 2010 8:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqdogsbody wrote: |
| I may be wrong but I am fairly confident that the anwer will be "it's not documented" ... perhaps followed by comments about the difference between support and training (as has happened before). |
Not saying you're wrong, just saying it gives you something else to present to your boss as a justification of why the current path leads to pain & misery and those purse strings need to be moving.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Jun 10, 2010 11:35 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| mqdogsbody wrote: |
| RogerLacroix wrote: |
| mqdogsbody wrote: |
| What's the role of ExitSpace then? |
It is documented in the WMQ Intercommunication manual. |
Well, I just came across this sentence (on the "ExitSpace (MQLONG)" page): "The exit space in the buffer is provided following the existing data." Must have missed that before. |
| WMQ Intercommunication manual wrote: |
How you reserve space and use it
When the send exit program is called for initialization, set the ExitSpace field of MQXCP to the number of bytes to be reserved. See “MQCXP – Channel exit parameter” on page 492 for details. ExitSpace can be set only during initialization, that is when ExitReason has the value MQXR_INIT. When the send exit is invoked immediately before transmission, with ExitReason set to MQXR_XMIT, ExitSpace bytes are reserved in the transmission buffer. ExitSpace is not supported on z/OS.
The send exit need not use all of the reserved space. It can use less than ExitSpace bytes or, if the transmission buffer is not full, the exit can use more than the amount reserved. When setting the value of ExitSpace, you must leave at least 1 KB for message data in the transmission buffer. Note that channel performance can be affected if reserved space is used for large amounts of data.
What happens at the receiving end of the channel
Channel receive exit programs must be set up to be compatible with the corresponding send exits. Receive exits must know the number of bytes in the reserved space and must remove the data in that space. |
| WMQ Intercommunication manual wrote: |
ExitSpace (MQLONG)
Number of bytes in transmission buffer reserved for exit to use.
This field is relevant only for a send exit. It specifies the amount of space in bytes that the MCA will reserve in the transmission buffer for the exit to use. This allows the exit to add to the transmission buffer a small amount of data (typically not exceeding a few hundred bytes) for use by a complementary receive exit at the other end. The data added by the send exit must be removed by the receive exit.
The value is always zero on z/OS.
Note: This facility should not be used to send large amounts of data, as this may degrade performance, or even inhibit operation of the channel.
By setting ExitSpace the exit is guaranteed that there will always be at least that number of bytes available in the transmission buffer for the exit to use. However, the exit can use less than the amount reserved, or more than the amount reserved if there is space available in the transmission buffer. The exit space in the buffer is provided following the existing data.
ExitSpace can be set by the exit only when ExitReason has the value MQXR_INIT; in all other cases the value returned by the exit is ignored. On input to the exit, ExitSpace is zero for the MQXR_INIT call, and is the value returned by the MQXR_INIT call in other cases.
If the value returned by the MQXR_INIT call is negative, or there are fewer than 1024 bytes available in the transmission buffer for message data after reserving the requested exit space for all of the send exits in the chain, the MCA outputs an error message and closes the channel. Similarly, if during data transfer the exits in the send exit chain allocate more user space than they reserved such that fewer than 1024 bytes remain in the transmission buffer for message data, the MCA outputs an error message and closes the channel. The limit of 1024 allows the channel’s control and administrative flows to be processed by the chain of send exits, without the need for the flows to be segmented.
This is an input/output field to the exit if ExitReason is MQXR_INIT, and an input field in all other cases. The field is not present if Version is less than MQCXP_VERSION_5. |
| mqdogsbody wrote: |
| But (if the TSH is undocumented) how I am supposed to know where the existing data ends? |
Very, very, very ... carefully. Expect a lot of head banging on your part. 
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Wed Jun 16, 2010 12:47 pm Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| RogerLacroix wrote: |
| Please remember, exits are an advanced-level topic. |
I am well aware of this and feel unqualified and underinformed!
| RogerLacroix wrote: |
| Make sure you are thinking in terms of parallel processing. Also, watch out for ASCII <--> EBCDIC and Big-Endian <--> Little-Endian issues. |
I am hoping that I can ignore charset and endianness issues (for now) as we have a pure Solaris/SPARC environment.
But what about parallel processing? This scares me ... in all contexts: my reaction to threads is to reach for my bargepoles!
What are the issues here? I guess I can't have any static variables. (Though something I read elsewhere suggests that I might be pessimistic. We are running 6.0.2.2. BTW.)
So I must keep my state in a malloc'ed area and keep a pointer to that ... where? ExitUserArea? (Or *ExitBufferAddr ... my guess is no: that's for data if the agent buffer isn't big enough.)
_________________
-- mqDB -- |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jun 16, 2010 2:56 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| mqdogsbody wrote: |
...But what about parallel processing? This scares me ... in all contexts: my reaction to threads is to reach for my bargepoles!
What are the issues here? I guess I can't have any static variables. (Though something I read elsewhere suggests that I might be pessimistic. We are running 6.0.2.2. BTW.)
So I must keep my state in a malloc'ed area and keep a pointer to that ... where? ExitUserArea? (Or *ExitBufferAddr ... my guess is no: that's for data if the agent buffer isn't big enough.) |
The pointer is typically kept in MQCXP.ExitUserArea. I hope you are not about to embark on a development effort. Writing exits is a long a painful process of experimenting and learning. The code needs to be reentrant, so you can't use static variables.
_________________
Glenn |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Jun 17, 2010 3:07 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| gbaddeley wrote: |
| I hope you are not about to embark on a development effort. Writing exits is a long a painful process of experimenting and learning. The code needs to be reentrant, so you can't use static variables. |
I am ... you can add your own adverb to that: sadly, unfortunately, ill-advisedly, ... a client-side channel send exit. If you read my commnets you'll see I am not gung-ho about this.
| gbaddeley wrote: |
| Writing exits is a long a painful process of experimenting and learning |
Thanks for the encouragement!
I am hoping to reduce the pain and speed the learning by getting tips from you guys.
_________________
-- mqDB -- |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jun 17, 2010 3:27 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| mqdogsbody wrote: |
| gbaddeley wrote: |
| I hope you are not about to embark on a development effort. Writing exits is a long a painful process of experimenting and learning. The code needs to be reentrant, so you can't use static variables. |
I am ... you can add your own adverb to that: sadly, unfortunately, ill-advisedly, ... a client-side channel send exit. If you read my commnets you'll see I am not gung-ho about this.
|
| mqdogsbody wrote: |
| RogerLacroix wrote: |
| Please remember, exits are an advanced-level topic. |
I am well aware of this and feel unqualified and underinformed!
|
| mqdogsbody wrote: |
| gbaddeley wrote: |
| Writing exits is a long a painful process of experimenting and learning |
Thanks for the encouragement!
I am hoping to reduce the pain and speed the learning by getting tips from you guys. |
So you are doing something against your will and you feel unqualified for and also expect us to help you do it...
I have completely lost you here... what happens if you say: NO ???
will you get fired, will someone else do it instead... ??? What ???
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 17, 2010 5:27 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Years ago, the manager who hired me told me "your job is to protect the organization from people like me (who don't know or understand the real issues)".
I believe you at a point where you are being told/asked to do something that will put the business at risk.
_________________
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 |
|
|
|
|
