RE: Path Manager Rewrite / Optimization project ,
 Following are my comments.  The managers cc'd might have some additional th=
oughts.

 -----Original Message-----
From: =09Pena, Matt =20
Sent:=09Monday, October 08, 2001 4:26 PM
To:=09Pinion, Richard; Jaquet, Tammy; Superty, Robert; Pena, Matt
Cc:=09Warner  , John ; Ripley, Brian; D'Souza, Romeo; Rao, Ramesh
Subject:=09Path Manager Rewrite / Optimization project
Importance:=09High

All:

We're currently identifying processes that are inefficient and could possib=
ly benefit from being rewritten or not even performed.  Going foward, I wou=
ld like Bob to appoint a lead business person to whom we could ask question=
s and or suggest ideas to so that they could in turn validate this informat=
ion with the desk managers/schedulers.  We had this approach with Nomlogic =
and having Clarissa work the issues worked quite nicely.  Who ever you choo=
se, we would need about 15% of their time for now.  Later on, with coordina=
tion efforts and testing, it may go up to 75%.  I don't see that happening =
for a while though.

The sooner we get someone to devote to this, the better off we will be.  I =
expect these changes that we'll be looking into should improve performance =
quite a bit. =20

That being said, we've identified three items that would speed up processin=
g the retrieval of Path Manager. =20

1)  Currently, the Path Manager attempts to reuse Path Ids.  I can't think =
of any reason why we need to perform this extra step?    It runs through th=
is processing on the application and generally doesn't find a match.  I kno=
w Patti has mentioned this several times and I can't think of a valid reaso=
n for performing this work.  I talked with Dave Nommensen, and according to=
 him, what used to happen is that sometimes schedulers would get duplicate =
paths out there which is why they put this code in place???  From a schedul=
ing perspective, my understanding of what your main concern is to just main=
tain your position and be able to change it.  If you were overpathed, you'd=
 see it in the Path Manager either way. [Pinion, Richard]    To restate the=
 question for clarity, in path manager a scheduler pulls down a supply, mar=
ket and a service, adds any up/downstream contract information and/or Duns =
or DRN override and then saves it.  Unify looks for an old path with those =
exact variables and if it finds it re-uses it and if it does not find an ex=
act match creates a new path and path id.  I had been told that to do away =
with this function would create an unacceptably high amount of paths since =
any path once nominated on could not be deleted.  Has this changed???  At o=
ne time there were some schedulers that looked for the same path / activity=
 number match for nominations.  Texas Eastern was the only pipeline that ne=
eded the old activity numbers no matter how long it had been since they wer=
e used.  I spoke with Chris Ordway and the new LINK system no longer needs =
this to occur.  Transco uses activity numbers but uses the Activity number =
cross reference table to that function and therefore should not be affected=
.  Therefore, if it does not create a space or memory problem for Unify, I =
don't think that this constant old path look up is needed. =20

2)  The scheduling position window:  does anyone use this?  If not, we'll r=
emove the code logic that populates this window.  I have never seen a sched=
uler use this.  Please verify. [Pinion, Richard]   Originally such a window=
 was in use by everyone in the legacy system "Autonoms" so it was duplicate=
d in Unify by request.  It is not used in Unify now because of the other so=
phisticated tools Unify provides which obviate it's use.  The only value wo=
uld be notification of bridge errors or contract imbalances but there are o=
ther ways to determine those problems.  As voted on in a previous meeting o=
f the managers - Lose it!=20

3)  On the inventory pool list, does anyone need to see the Contarct Refere=
nces List?  Again, this code is called every retrieval time and doesn't app=
ear to be used from my observations.   If they do need this information, we=
 could provide it, but if not, I'd prefer to remove the functionality. [Pin=
ion, Richard]    This function is still very much in use by those with poin=
t based pipelines that must use the imbalance pool to facilitate balancing =
nomination volumes where multiple pipeline external pools exist and are pat=
hed through the same contract imbalance pool.  Keep it!=20

4)  When pathing a one to many or many to one set of paths, what's the aver=
age number of paths they create at one time?  What about updates?  I know t=
hat ANR and NIGAS are big users of this feature since they have small packa=
ges of gas that they are limited in size to.  Does the system seem faster w=
hen you update one record at a time or chunks of records?  My real question=
 is how often they do this and for what number of paths on both Updates and=
 Inserts.  By update, I mean, going to the path list and changing an upstre=
am / downstream contract or a PSNA which in turn forces a new path to be cr=
eated. [Pinion, Richard]    This one to many or many to one pathing goes on=
 every day on every pipeline.  There is no 'average'.  They typically updat=
e a path with up/downstream meters or duns or dnb numbers one at a time how=
ever.  I hope this answers your question.  I see no change to this process =
at this time=20

5)  On brokered paths, do you want to utilize the same logic we have for Se=
rvice?  In other words, when updating Brokered arrangements, we don't incor=
porate the same logic for zeroing out the path and recreating a new arrangm=
ent link and hence sending it to be renominated?  Why do we do this for ser=
vice?  Is it because we have to renominate it?  I assume that's what it's f=
or since we don't send brokered paths to the pipe.  Anyway, with the Nomlog=
ic implmentation (two way interface), we were planning on having it behave =
the same way as service.  We need this verified. [Pinion, Richard]    We do=
n't perform the same logic for Brokered paths because these are not nominat=
ed to the pipeline and hence do not need a zero path to be resent to the pi=
peline when a significant change is made to the already nominated path.  I =
don't see a need to change the way Brokered paths are behaving at this time=
.
matt.pena@enron.com