I agree with the 'real-time definition offered by Pete ...'Exceptionally fast batch'. Course, 'real-time' is also widely understood to be a 'non-scheduled' process. 'Daemon' is also used to define 'real-time' processes. Ahh well. Personally, I prefer the term 'event-driven' as opposed to 'real-time'. Here at CBP, we utilize MQ Series triggered queues that have the capability to initiate multiple concurrent CICS transaction processes/events within a single environment. Our translation software is invoked within the CICS transaction UOW. Cheers! Bud/Customs
Pete Austin <[EMAIL PROTECTED]> wrote: Brian, I'm not certain that I entirely agree. We've done thousands of hours of work with numerous translators, and there are few that cannot be leveraged into a real-time environment. What the problem really is is a lack of a common definition of 'real-time'. Real-time is commonly considered to be a connection at the socket level directly to fields in a database (for example). Obviously, the moment you write an ISA, you aren't even on the same block of what a purist would consider to be real-time. Any environment that includes writing an ISA (or any file) is a batch environment. So, what we REALLY mean by real-time is 'acceptably fast batch'. Some consider pulling money from an ATM to be real-time, when obviously it isn't. It is just acceptably fast. We recently assisted an organization with taking a batch process that was running a bit more than 8 1/2 hours down to about 5 minutes. Using ECMap, WITHOUT some of the cool tricks you can do (forcing maps to stay memory-resident, doing memory reads for input, output, and logging, etc), we had the map processing about 250 claims per second. Using some of the tricks, we could have probably increased another 50%. Yes, I know this was a batch run, and we are talking real-time, but it gives you a sense of the translator's core efficiency. Most translators that have been around for awhile have the ability to provide high speed translation; the real key is to find folks that have the ability to configure them CORRECTLY. There are a million wrong ways to perform translation, and it takes experience and skill to do it right. Thanks, Pete -- Pete Austin Vice President, eCommerce Services AXIOM Systems, Inc. The Managed Care Systems Experts 20300 Century Boulevard, Suite 120 Germantown, MD 20874-1110 www.axiom-systems.com 301 840 3861 x210 240 605 6939 cell 240 465 0051 fax [EMAIL PROTECTED] -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Lehrhoff Sent: Friday, July 01, 2005 11:23 AM To: Ilia Chlaifer; [email protected] Subject: Re: [EDI-L] <TECH><MISC> MQ vs EDI? MQ is a transport - it takes stuff from here and guarantees delivery to there. now, if you use MQ to send data to a translator and from the translator to somewhere else ... then it's doable. all of the larger messaging flow systems that i've done use this architecture. it's very real-time friendly. unfortunately most of the legacy systems are still batch oriented, and most of the major translators are built to process in a batch environment. --- Ilia Chlaifer <[EMAIL PROTECTED]> wrote: > Howdy all. > One of my colleges had made a statement that > Messaging/MQ can and should > eventually replace traditional EDI. > When I've disputed his statement claiming that MQ is > not applicable in > the retail world due it its complicity and luck of > true standards > throughout the trading partners (not as EDI > replacement at least), he > had stated that GAP for example had done it. I know > that GAP's example > is not adequate, since their both vendor and > retailer in one, but... > Without getting into semantics and keeping flaming > to the minimum I > wanted to get some opinions regarding subj. > Are some messaging platform fully capable to replace > traditional > translators supporting current EDI standards and > validations? Would they > be able to seamlessly convert to-from proprietary > EDI formats used by > the smaller or antiquated TPs in (retail) industry? > Please tell me, I might have headed in the wrong > direction for past 14 > years. > Happy Friday and ID4. > Ilia > KHNY > > > [Non-text portions of this message have been > removed] > > > > . > Please use the following Message Identifiers as your > subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, > <MISC>, <EVENT>, <OFF-TOPIC> > Access the list online at: > http://groups.yahoo.com/group/EDI-L > > Yahoo! Groups Links > > > [EMAIL PROTECTED] > > > > > Brian Lehrhoff EDI Consultant 201-913-4506 __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail . Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at: http://groups.yahoo.com/group/EDI-L Yahoo! Groups Links . Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at: http://groups.yahoo.com/group/EDI-L --------------------------------- YAHOO! GROUPS LINKS Visit your group "EDI-L" on the web. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. --------------------------------- --------------------------------- Sell on Yahoo! Auctions - No fees. Bid on great items. [Non-text portions of this message have been removed] . Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Access the list online at: http://groups.yahoo.com/group/EDI-L Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
