<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:verdana, helvetica, sans-serif;font-size:10pt"><DIV></DIV>
<DIV>Yes.</DIV>
<DIV>There's a standard report to do so - let me know if you can't find it and I'll look for it & send it to you.<BR> </DIV>
<P><FONT face="verdana, helvetica, sans-serif" color=#00007f size=2><STRONG>Regards,<BR>Shai Eyal</STRONG></FONT></P>
<P><FONT face=Verdana color=#000080 size=2><STRONG>SAP Logistics consultant<BR>SAP Workflow specialist<BR>Mobile: 972-52-5816633</STRONG></FONT></P>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: verdana, helvetica, sans-serif"><BR><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: "sap-wug-request@mit.edu" <sap-wug-request@mit.edu><BR>To: sap-wug@mit.edu<BR>Sent: Wednesday, 21 February, 2007 12:03:36 PM<BR>Subject: SAP-WUG Digest, Vol 27, Issue 46<BR><BR>
<DIV>Send SAP-WUG mailing list submissions to<BR> sap-wug@mit.edu<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR> <A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>or, via email, send a message with subject or body 'help' to<BR> sap-wug-request@mit.edu<BR><BR>You can reach the person managing the list at<BR> sap-wug-owner@mit.edu<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of SAP-WUG digest..."<BR><BR><BR>Today's Topics:<BR><BR> 1. ECC 6.0 Upgrade Question (workflow@insightbb.com)<BR> 2. RE: ECC 6.0 Upgrade Question (Munday,Sherie J.)<BR> 3. Re: ECC 6.0 Upgrade Question (Shalini Sabnani)<BR> 4. Re: Upgrade for ECC 6.0 (Paul.Bakker@osr.treasury.qld.gov.au)<BR> 5. Deadline
setting (Guenther, Annegret)<BR> 6. Re: Parallel processing of Workflow Deadline Monitoing in<BR> 4.6C (Mike Gambier)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Tue, 20 Feb 2007 12:22:22 -0500<BR>From: workflow@insightbb.com<BR>Subject: ECC 6.0 Upgrade Question<BR>To: sap-wug@mit.edu<BR>Message-ID: <f64987e517e7a.45dae7fe@insightbb.com><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>To All:<BR><BR>Has anyone been involved in an ECC 6.0 Upgrade? If yes, was it necessary to convert all related ABAP for methods to unicode?<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <A href="http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/c99bf563/attachment-0001.htm"
target=_blank>http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/c99bf563/attachment-0001.htm</A><BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Tue, 20 Feb 2007 13:34:41 -0500<BR>From: "Munday,Sherie J." <MUNDAYSJ@airproducts.com><BR>Subject: RE: ECC 6.0 Upgrade Question<BR>To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>Message-ID:<BR> <B3D052C7FA25934B94BA33FC2080CA16D11A21@us0355exmp.america.apci.com><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>We did not upgrade to unicode with our technical ECC6.0 upgrade. We are<BR>however upgrading now to unicode in conjunction with our Asia language<BR>project.<BR>Best Wishes,<BR>Sherie<BR><BR>Sherie Munday<BR>Workflow Developer/ Analyst<BR>Air Products & Chemicals, Inc.<BR><BR>________________________________<BR><BR>From: sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] On Behalf<BR>Of workflow@insightbb.com<BR>Sent:
Tuesday, February 20, 2007 12:22 PM<BR>To: sap-wug@mit.edu<BR>Subject: ECC 6.0 Upgrade Question<BR><BR><BR>To All:<BR><BR>Has anyone been involved in an ECC 6.0 Upgrade? If yes, was it necessary<BR>to convert all related ABAP for methods to unicode?<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <A href="http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/9d4c6bdc/attachment-0001.htm" target=_blank>http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/9d4c6bdc/attachment-0001.htm</A><BR><BR>------------------------------<BR><BR>Message: 3<BR>Date: Tue, 20 Feb 2007 13:57:56 -0500<BR>From: "Shalini Sabnani" <workflow.mail@gmail.com><BR>Subject: Re: ECC 6.0 Upgrade Question<BR>To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>Message-ID:<BR> <53c024f70702201057q63de0738ocfae06a851a5ad38@mail.gmail.com><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>We were
required to be Unicode compliant but since we only use Englinsh and<BR>French for the Client we did not convert out ABAP code to Unicode.<BR><BR>Hope this helps<BR>Shalini<BR><BR><BR>On 2/20/07, workflow@insightbb.com <workflow@insightbb.com> wrote:<BR>><BR>> To All:<BR>><BR>> Has anyone been involved in an ECC 6.0 Upgrade? If yes, was it necessary<BR>> to convert all related ABAP for methods to unicode?<BR>><BR>> _______________________________________________<BR>> SAP-WUG mailing list<BR>> SAP-WUG@mit.edu<BR>> <A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <A href="http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/a8b749a3/attachment-0001.htm"
target=_blank>http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/a8b749a3/attachment-0001.htm</A><BR><BR>------------------------------<BR><BR>Message: 4<BR>Date: Wed, 21 Feb 2007 09:15:06 +1000<BR>From: Paul.Bakker@osr.treasury.qld.gov.au<BR>Subject: Re: Upgrade for ECC 6.0<BR>To: SAP-WUG@mit.edu<BR>Cc: "Levy, Greg" <greg_levy@cinfin.com><BR>Message-ID:<BR> <OFCC7C7D12.62FA753E-ON4A257288.007DA266-4A257288.007FB6B7@treasury.qld.gov.au><BR> <BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Greg / WUGgers,<BR><BR>Our upgrade from 46C to ECC6.0 went surprisingly smoothly - for both<BR>standard and custom workflows. The only issues we encountered were the<BR>following:<BR><BR>Problem: 'Old' workitems (created before the upgrade) can trigger a "Error<BR>at point of synchronization" when they are processed<BR>Solution: Implement OSS note 991585 before users are allowed onto the<BR>system<BR><BR>Problem:
Workorder workflows were not being triggered<BR>Solution: the BADI 'WORKORDER_UPDATE' required manual adjustment and<BR>reactivation.<BR>Note: There is a new 'enhancement point' concept for BADIs.<BR><BR>Problem: workflows that use the obsolete BOR object 'ABSENCE' no longer<BR>work<BR>Solution: Implement OSS note 731260<BR><BR>Problem: a workflow doesn't trigger because a (custom) function group has a<BR>syntax error.<BR>ECC60 complains that executable statements in the TOP INCLUDE are 'NOT<BR>ACCESSIBLE'.<BR>Solution: Improve the custom code<BR>Note: It seems that some syntax issues that were considered 'warnings' in<BR>46C are now 'errors' in 60.<BR><BR>Problem: the new workflow log is hard to use<BR>Solution: you can still revert back to the old one!<BR><BR>I'm sure there may be more - does anyone else have some war stories to<BR>share?<BR><BR>cheers<BR>Paul
B<BR><BR><BR><BR>|---------+----------------------------><BR>| | "Levy, Greg" |<BR>| | <Greg_Levy@CINFIN|<BR>| | .com> |<BR>| | |<BR>| | 21/02/2007 04:17 |<BR>|
| |<BR>|---------+----------------------------><BR> >--------------------------------------------------------------------------------------------------------------------------|<BR> | &nbs
p; |<BR> | To: <paul.bakker@osr.treasury.qld.gov.au> |<BR> | cc: "Neumann, Marcia"
<Marcia_Neumann@CINFIN.com> |<BR> | Subject: Upgrade for ECC
6.0 |<BR> >--------------------------------------------------------------------------------------------------------------------------|<BR><BR><BR><BR><BR>Paul,<BR><BR><BR>Read your email about applying OSS note 991585 after upgrading to ECC 6.0.<BR>Thanks for that info. Also, did you have any existing custom workflows that<BR>you had to deal with after the upgrade? Did you experience any other issues<BR>with either new or old workflows after the
upgrade?<BR><BR><BR>Thanks!<BR><BR><BR>Gregory Levy<BR><BR><BR>SAP Senior Technical Consultant<BR><BR><BR>The G Levy Group, Inc<BR><BR><BR>O 513 870-2300 X-4298<BR><BR><BR>C 502 386-4788<BR><BR><BR><BR><BR><BR><BR><BR>******************************************************************************************************************************************************<BR><BR>Only an individual or entity who is intended to be a recipient of this e-mail may access or use the information contained in this e-mail or any of its attachments. Opinions contained in this e-mail or any of its attachments do not necessarily reflect the opinions of Queensland Treasury.<BR><BR>The contents of this e-mail and any attachments are confidential and may be legally privileged and the subject of copyright. If you have received this e-mail in error, please notify Queensland Treasury immediately and erase all copies of the e-mail and the attachments. Queensland
Treasury uses virus scanning software. However, it is not liable for viruses present in this e-mail or in any attachment. <BR><BR>******************************************************************************************************************************************************<BR><BR><BR><BR>------------------------------<BR><BR>Message: 5<BR>Date: Wed, 21 Feb 2007 11:01:30 +0100<BR>From: "Guenther, Annegret" <annegret.guenther@eds.com><BR>Subject: Deadline setting <BR>To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>Message-ID:<BR> <94CEEA0AE0E18B47BAF07AABFD8976BA2EE64B@derum200.emea.corp.eds.com><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR><BR>Hi,<BR>Hope anyone can help me. My costumer would like that the deadline handling will start after 2 working days. But in the Workflow customizing I can only select days and other stuff. Has anyone experiences with this and
can give me an advice??<BR><BR>Thanks in advance!!<BR><BR>Best regards<BR>Anne G?nther <BR>Phone: +49(0)3461 814 138<BR>Fax: +49(0)3461 814 202<BR>e-mail: annegret.guenther@eds.com <BR><BR><BR><BR><BR><BR><BR>------------------------------<BR><BR>Message: 6<BR>Date: Wed, 21 Feb 2007 10:03:21 +0000<BR>From: "Mike Gambier" <madgambler@hotmail.com><BR>Subject: Re: Parallel processing of Workflow Deadline Monitoing in<BR> 4.6C<BR>To: sap-wug@mit.edu<BR>Message-ID: <BAY117-F707A26743CAC4F4C80FECD5880@phx.gbl><BR>Content-Type: text/plain; format=flowed<BR><BR>Hi all,<BR><BR>Well SAP's Oracle DBA, Stefan Kuhlmann (thanks Stefan if you're reading <BR>this!), worked his magic on our Workflow data on Sunday. In just over five <BR>and a half hours our live Production tables for Workflow were trimmed right <BR>down to 200Gb from just over 1.6Tb.<BR><BR>I
don't know the figures for the indexes and how much space we clawed back <BR>from them, but overall everyone seems to be happy. Our previous run on a <BR>snapshot of Production showed a 2Tb gain in total so I suspect we were <BR>pretty close to that overall.<BR><BR>To give you an idea of what we were up against here are some table sizes and <BR>record counts from tables you'll probably all know:<BR><BR>Table Size
(Kb) Rows<BR>SRRELROLES 16,588,160<BR>SWEINSTCOU 1,330,176 9,212,962<BR>SWELOG 1,114,112 6,376,382<BR>SWELTS 303,104<BR>SWEQUEUE 293,824<BR>SWPNODELOG 71,023,616 502,301,486<BR>SWPSTEPLOG 140,800,000 395,628,934<BR>SWP_ADM_US 1,918,976<BR>SWP_HEADER 8,227,840<BR>SWP_JOIN &nbs
p; 4,669,440<BR>SWP_NODEWI 25,812,992<BR>SWWBINDEF 129,307,264 1,251,610,755<BR>SWWEI 2,655,232<BR>SWWLOGHIST 90,001,408<BR>SWWORGTASK 434,176<BR>SWWRUNMETH 27,454,464<BR>SWWSWPRET 13,524,992<BR>SWWUSERWI 37,192,960 653,628,051<BR>SWWWIDEADL 14,109,696<BR>SWWWIHEAD 174,683,584 421031224<BR>SWWWIRET 37,329,536<BR>SWW_CONT 125,770,880 1,834,208,289<BR>SWW_CONTOB 92,498,944 955,142,364<BR><BR>I don't recall ever seeing a single table with 1.8 BILLION records before!
<BR>^^<BR><BR>Apparently these tables alone when combined are much larger than some entire <BR>systems that SAP normally work with.<BR><BR>We now have just over 70 MILLION entries in SWWWIHEAD (only!) and things are <BR>running much more smoothly.<BR><BR>No problems yet reported.<BR><BR>MGT<BR><BR>>From: "Mike Gambier" <madgambler@hotmail.com><BR>>Reply-To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>>To: sap-wug@mit.edu<BR>>Subject: Re: Parallel processing of Workflow Deadline Monitoing in 4.6C<BR>>Date: Tue, 06 Feb 2007 09:44:49 +0000<BR>><BR>>Hi all,<BR>><BR>>Progress update on our open heart surgery for Worklflow : )<BR>><BR>>SAP's Oracle DBA people got hold of a snapshot of our system over the <BR>>weekend, copied the 25 Workflow tables they wanted to hack to pieces and <BR>>proceeded to slice and dice all Workflow entries where the parent WF had <BR>>terminated.<BR>><BR>>They then swapped the new copies
of the tables with the system down, <BR>>renaming the original ones as a backup, and brought the system back up.<BR>><BR>>The whole procedure took about 7 hours and our WF tablespaces dropped from <BR>>2 Terabytes to 560 Megabytes at a stroke.<BR>><BR>>We are currently running integrity tests to see if anything has been broken <BR>>but so far so good.<BR>><BR>>Considering our estimates show that we would have to run archiving <BR>>agressively for 6 months to achieve the same result, this seems like an <BR>>acceptable alternative.<BR>><BR>>The current plan is to do this for real in Production some time soon.<BR>><BR>>We're still not sure if our current archiving strategy can keep tabs with <BR>>our net growth though, perhaps we'll have a better idea when we reduce the <BR>>overall size of our WF tables.<BR>><BR>>MGT<BR>><BR>>>From: Susan Keohan <keohan@ll.mit.edu><BR>>>Reply-To: "SAP Workflow
Users' Group" <sap-wug@mit.edu><BR>>>To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>>>Subject: Re: Parallel processing of Workflow Deadline Monitoing in 4.6C<BR>>>Date: Wed, 24 Jan 2007 06:35:08 -0500<BR>>><BR>>>Hi Mike,<BR>>><BR>>>Thanks for the update.... Please keep us posted.<BR>>><BR>>>I am dealing with WF Table sizes and access time as well, but not on the<BR>>>scale that you describe. We have not yet implemented archiving on our<BR>>>workitems, but our SRM 5.0 system spends a *lot* of time accessing<BR>>>SWWWIHEAD in certain business objects (Bids, BUS2200).<BR>>><BR>>>Still, I might learn a lesson from your experience.<BR>>><BR>>>Mike Gambier wrote:<BR>>> > Hi,<BR>>> ><BR>>> > For anyone who was interested we have implemented the RFC Q option 2 on<BR>>> > my previous mail and things look to be working
well.<BR>>> ><BR>>> > We have on average 60,000 RFC entries in ARFCSSTATE for our 'new'<BR>>> > WORKFLOW_DEADLINE_100 queue and our version of SWWDHEX is churning<BR>>> > thorugh our deadlines pretty well. Load balancing seems to be working <BR>>>as<BR>>> > well as it can with WF-BATCH dominating 2 dedicated servers most of the<BR>>> > time. Our 'normal' event RFCs seem to be stable too which is good news.<BR>>> ><BR>>> > Now for our next problem to tackle: we have 2 terabytes (!!) of data in<BR>>> > our Workflow tables and only need about 300 gig of it to remain <BR>>>availablle.<BR>>> ><BR>>> > We've been trying to get rid of our Workflow data using the SAP<BR>>> > archiving objects but our net growth rate is such that we can only seem<BR>>> > to keep up with new data coming in.<BR>>> ><BR>>> > SAP have suggested a radical
'heart surgery' approach involving an<BR>>> > Oracle DBA getting his/her hands dirty to clone the 25 WF tables, slice<BR>>> > and dice them and then reinstate the trimmed versions back in the<BR>>> > system. All a bit scary to be honest...<BR>>> ><BR>>> > Will post the results here as to how we progress as someone else might<BR>>> > find this useful.<BR>>> ><BR>>> > MGT<BR>>> ><BR>>> >> From: "Mike Gambier" <madgambler@hotmail.com><BR>>> >> Reply-To: "SAP Workflow Users' Group" <sap-wug@mit.edu><BR>>> >> To: sap-wug@mit.edu<BR>>> >> Subject: Parallel processing of Workflow Deadline Monitoing in 4.6C<BR>>> >> Date: Fri, 24 Nov 2006 16:11:53 +0000<BR>>> >><BR>>> >> Hello fellow WUGgers,<BR>>> >><BR>>> >> We are faced with a bit of a new dilemma regarding WF Deadlines
and<BR>>> >> seem to<BR>>> >> be faced with some difficult choices.<BR>>> >><BR>>> >> Our old dilemma was this: we used to run RSWWDHEX every 15 minutes to<BR>>> >> pick<BR>>> >> up our steps that had passed their deadline entries (SWWWIDH /<BR>>> >> SWWWIDEADL)<BR>>> >> until this started to time out during the SELECT statement pulled too<BR>>> >> many<BR>>> >> entries back (simply because we have so many Workflows running). We<BR>>> >> also had<BR>>> >> an issue with the standard program respawning itself whilst its<BR>>> >> predecessor<BR>>> >> job was still running which caused us a bit of grief. This last bit<BR>>> >> has been<BR>>> >> resolved since we hear in later SAP versions.<BR>>> >><BR>>> >> So, to fix these issues we cloned the program and built in
a MAX HITS<BR>>> >> parameter to reduce the number of deadlines it processed per run and<BR>>> >> added a<BR>>> >> self-terminate subroutine to ensure no two jobs ran concurrently.<BR>>> >><BR>>> >> But, even after these changes we are faced with a NEW dilemma with WF<BR>>> >> Deadline Monitoring. Namely it has a nasty habit of loading up <BR>>>whatever<BR>>> >> server the job is run on to progress the deadline! This manifests<BR>>> >> itself in<BR>>> >> dailog process 'hogging' or excessive local tRFC entries in ARFCSSTATE<BR>>> >> where<BR>>> >> it can't get hold of a dialog process to use on that particular server<BR>>> >> (which can happen a lot if we have other heavy jobs running there).<BR>>> >> The load<BR>>> >> then shifts to RSARFCEX which then struggles with the load as<BR>>> >>
everything is<BR>>> >> processed locally on whatever server it is run on.<BR>>> >><BR>>> >> Unlike the Event Queue there is no standard ready made Parallel<BR>>> >> processing<BR>>> >> option for Deadlines that we know of, at least not in 4.6C. So we're<BR>>> >> thinking of choosing one of these options:<BR>>> >><BR>>> >> 1. Amend our Deadline Monitoring program (will require a mod to SAP<BR>>> >> code as<BR>>> >> well) to redirect the first RFC with a new custom destination that can <BR>>>be<BR>>> >> processed seperately to 'normal' Workflow tRFCs, e.g. <BR>>>'WORKFLOW_DL_0100'<BR>>> >> instead of 'WORKFLOW_LOCAL_0100'. The new destination would be set up <BR>>>to<BR>>> >> point to a completely different server than the one the Deadline<BR>>> >> Monitor job<BR>>> >> is
currently running on. This won't diminish the load on the server <BR>>>where<BR>>> >> dialog processes are available but at least it will shift the load on<BR>>> >> RSARFCEX when it runs. Obviously we would have to schedule a new run <BR>>>for<BR>>> >> RSARCFEX with this new destination into our schedule.<BR>>> >><BR>>> >> 2. Same as 1 (mod required) but the new destination will point to a<BR>>> >> server<BR>>> >> group destination (rather than a single server) to spread the load <BR>>>across<BR>>> >> mutltiple servers when the tRFCs are converted into qRFCs. Has the <BR>>>added<BR>>> >> benefit of reusing the qRFC queue (and its standard config settings <BR>>>and<BR>>> >> transactions) to buffer the start of each new deadline being<BR>>> >> processed. Once<BR>>> >> a deadline step is executed, any
tRFCs that result will be appended as<BR>>> >> WORKFLOW_LOCAL_0100 as normal because they will result from subsequent<BR>>> >> calls<BR>>> >> that will not affected by our mod setting. End result should be the<BR>>> >> START of<BR>>> >> each deadline process chain is distributed across multiple servers <BR>>>(and<BR>>> >> therefore will spread the demand for dialog processes accordingly),<BR>>> >> but any<BR>>> >> tRFCs that result will end up being chucked back into the 'local' pot.<BR>>> >> Unfortunately this would mean that our version of SWWDHEX would pass <BR>>>the<BR>>> >> baton on to RSQOWKEX (the outbound queue batch job) to actually<BR>>> >> progress the<BR>>> >> deadline, i.e do any real work. We would therefore have two batch jobs <BR>>>to<BR>>> >> watch and have a noticeable delay between
deadlines being selected and<BR>>> >> deadlines actually being progressed. Whether we can live with this we<BR>>> >> just<BR>>> >> don't know. The issue of different deadlines for the same Workflow <BR>>>being<BR>>> >> progressed on different servers is also a concern but since we limit <BR>>>the<BR>>> >> number of deadlines we process per run anyway that is currently<BR>>> >> something we<BR>>> >> suffer from at the moment.<BR>>> >><BR>>> >> 3. Dynamic destination determination (OSS Note 888279) applied to all<BR>>> >> Workflow steps, not just deadlines. Scary stuff. Breaks the concept of <BR>>>a<BR>>> >> single server 'owning' a deadline process chain in its entirety.<BR>>> >> Considering<BR>>> >> the volumes of Workflow we have, we're uncertain as to what impact<BR>>> >> this
will<BR>>> >> have system-wide.<BR>>> >><BR>>> >> 4. Redesign Deadline Monitoring to use the same persistence approach <BR>>>as<BR>>> >> Event Delivery and have a deadline queue. Complete overhaul using<BR>>> >> SWEQUEUE<BR>>> >> etc as a guide. Would be a lovely project to do but honestly we can't<BR>>> >> really<BR>>> >> justify the database costs, code changes and testing.<BR>>> >><BR>>> >> We are currently favouring option 2 as a realistic way forward as it<BR>>> >> seems<BR>>> >> to offer the simplest way of shifting the load around to prevent a <BR>>>single<BR>>> >> server from being hammered. It has risks and would require careful<BR>>> >> monitoring or the qRFC queues, but it seems a safer bet than <BR>>>overloading<BR>>> >> another single server (option 1), splitting up
a single deadline chain<BR>>> >> across multiple servers (option 3) or costing the earth and becoming<BR>>> >> unsupportable (option 4).<BR>>> >><BR>>> >> Has anyone out there implemented option 3, the OSS Note? We'd love to<BR>>> >> know...<BR>>> >><BR>>> >> Or, if you have any alternative suggestions we'd be interested to hear<BR>>> >> them<BR>>> >> :)<BR>>> >><BR>>> >> Regards,<BR>>> >><BR>>> >> Mike GT<BR>>> >><BR>>> >> _________________________________________________________________<BR>>> >> Stay up-to-date with your friends through the Windows Live Spaces <BR>>>friends<BR>>> >> list.<BR>>> >> <BR>>><A
href="http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk" target=_blank>http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk</A><BR>>> >><BR>>> >><BR>>> >> _______________________________________________<BR>>> >> SAP-WUG mailing list<BR>>> >> SAP-WUG@mit.edu<BR>>> >> <A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>>> ><BR>>> > _________________________________________________________________<BR>>> >> From predictions to trailers, check out the MSN Entertainment Guide to<BR>>> >> the<BR>>> > Academy Awards®<BR>>> > <A
href="http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1" target=_blank>http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1</A><BR>>> ><BR>>> ><BR>>> > <BR>>>------------------------------------------------------------------------<BR>>> ><BR>>> > _______________________________________________<BR>>> > SAP-WUG mailing list<BR>>> > SAP-WUG@mit.edu<BR>>> > <A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>>><BR>>>--<BR>>>Susan R. Keohan<BR>>>SAP Workflow Developer<BR>>>MIT Lincoln Laboratory<BR>>>244 Wood Street<BR>>>LI-200<BR>>>Lexington, MA. 02420<BR>>>781-981-3561<BR>>>keohan@ll.mit.edu<BR>>>_______________________________________________<BR>>>SAP-WUG mailing list<BR>>>SAP-WUG@mit.edu<BR>>><A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>><BR>>_________________________________________________________________<BR>>Turn searches into helpful donations. Make your search count. <BR>><A href="http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG" target=_blank>http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG</A><BR>><BR><BR><BR>>_______________________________________________<BR>>SAP-WUG mailing list<BR>>SAP-WUG@mit.edu<BR>><A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR>_________________________________________________________________<BR>Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE. <BR> <A
href="http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline" target=_blank>http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline</A><BR><BR><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>SAP-WUG mailing list<BR>SAP-WUG@mit.edu<BR><A href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target=_blank>http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR><BR>End of SAP-WUG Digest, Vol 27, Issue 46<BR>***************************************</DIV></DIV><BR></DIV></div><br>
<hr size=1>
What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the <a href="http://uk.rd.yahoo.com/mail/uk/taglines/default/championships/quiz/*http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk/">Yahoo! Mail Championship</a>.</body></html>