Good answers, Mike!
One elaboration I would make is that while customising at the transaction level is not something we typically recommend, customising to completely REMOVE unused transactions is very commonly done. It has a beneficial effect on runtime performance because, while the type tree itself is not used at runtime, it IS used at compile time to build the parse code. Removing unused transactions makes the map smaller and makes it run faster. Whether it's worth the effort is something you'd have to decide for yourself but a lot of customers do it. Larry Pieniazek - [EMAIL PROTECTED] Cell: (616)299-6375 or page via [EMAIL PROTECTED] > > Message: 1 > Date: Sun, 17 Apr 2005 09:41:35 -0500 > From: "Michael Mattias" <[EMAIL PROTECTED]> > Subject: Re: Data Stage Tx and Commerce Manager > > > > This long time GENTRAN:Server analyst is learning a new > tool: the translator > > formerly known as Mercator, Data Stage Tx. > > > > Anyway, what do you all think about Commerce Manager? It > seems to be the > > equivalent of GENTRAN:Server's TP administration feature, > correct? Are there > > substitute, or alternatives to Commerce Manager which a > shop can use with > > Data Stage Tx? > > Although I've used Mercator/Datastage since about 1996, I've > never used the portions of the product designed for 'flow control' > (i..e., the "Commerce Manager" parts). Probably because > those parts didn't exist when I started with Mercator, I've > always used > "something else" to control firing off maps and/or running > multiple-map applications. (I use both "RUN" and MS-DOS batch files to > execute maps from the command prompt - a lot). So... the > answer to this question is "Yes, you can use something other than > Commerce Manager to control events/map execution/etc." > > > in GENTRAN:Server, one may mark and discard unused standard > > segments/elements (best for outbound parterships) for ease > of viewing. With > > Data Stage Tx, the entire standard needs to be present, correct? > > No, you can customize your type trees all you want. If a map > is required to process, say, only any "850 Purchase Order" or "810 > Invoice" transactions found in the input, no reason you can't > create a 'minimal' tree which supports detail only for those specific > transaction sets. The problem is, it would take close to > forever to identify and eliminate all the unused segments and > elements from > the trees, and even if you did do that, you end up saving not > a whole lot of anything, anyway. > > (You do realize the type tree files are not used at runtime, > right? They are only required to be present when the map is compiled. > It might help to think of a type tree as a "copy library" the > same as you'd use a copy library when developing software in some 3GL > language like COBOL, PL/1 or BASIC).. > > But the only times I've created such "custom" trees are when > partners insist on sending non-ansi-compliant transactions (and yes, > this has occurred more than once). Better IMO to just use > the 'factory' ANSI trees (which you have marked as 'read > only.' You don't > want to tinker with those, even accidentally). > > Michael Mattias > Tal Systems, Inc. > Racine WI > [EMAIL PROTECTED] > http://www.talsystems.com > > . 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/
