with the information that I have so far, each order is independent of the other
each order has a header and a trailer, which the program relies on in the decision process
the sequence in which the orders are processed is not a factor to the design folks
however, I am sure that each store, would like their order processed first
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
Success is a Journey, not a Destination
| "Miller, Dennis" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]> 09/20/2002 11:32 AM
|
To: [EMAIL PROTECTED] cc: Subject: Re: retrieve order |
To reiterate:
If possible, design so that retrieval order does not matter. If not,
design so that it does not affect the outcome.
Consolidating your "request" to a single message is an simple and effective
way to achieve the first goal. Just be careful not to shoot yourself in the
other foot. If you are confident that a single detail element per request is
adequate or you that you can handle a variable number of detail elements per
request (and message size does not become an issue), then go for it.
Also, it should be apparent by now that the order that requests are
processed relative to one another must not matter, either.
> -----Original Message-----
> From: Dave Adam [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 20, 2002 8:53 AM
> To: [EMAIL PROTECTED]
> Subject: Re: retrieve order
>
>
> got to work 5 hours ago and most of my morning has been tied up with MQ
> and related issues
>
> I am sending this before I get to todays list messages, cause I would like
> everyone know how we shot ourselves in the foot
>
> it is amazing how close everyone has been on this issue, and have helped
> me in asking the right questions
>
> just got off a conference call with the vendor
>
> the header, detail, and trailer are all separate messages
>
> we are the only one with that design, all others they serve have the
> header, detail, and trailer within a message
>
> we have a situation where the channel on the long distance queue appears
> to be inactive ( not sure if the keepalive parm is set up right)
>
> when this happens the vendor has been known to send a duplicate record
>
> It is amazing what you discover when you ask the right person, so we do
> not use MSMQ and we create duplicates (not MQ)
>
> here is the touchy part, cause I do not want to get into the same
> controversy I did with the other spam mail (from the company I can't
> remember)
>
> but
>
> this system we have was an old product called Marketware that we adapted
> to what is now called Encore from a company called EPOS
>
> have any of you been involved with any of these
>
> I have recommended that we switch to a single message so the monster
> program that needs the info in a specific sequence doesn't have to change
> right away
>
> and I would like to know if this is a good direction
>
> Dave Adam
> Supervalu Home Office
> Project Specialist
> (952) 828-4736
> [EMAIL PROTECTED]
>
> Success is a Journey, not a Destination
>
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
