[jcifs] Is the work-around also the answer?

[Bret Comstock Waldow]

On 24/10/11 13:50, Michael B Allen wrote:
> On Sun, Oct 23, 2011 at 7:15 AM, Bret Comstock Waldow <bcw1000 at yahoo.com> wrote:
>> This is Large, Huge, International Resource Company, and that's not
>> going to happen.  Period.
>>
>> There is a project in it's early stages to replace this software with
>> something else, but I'm not doing that, and it won't happen soon.  Maybe
>> next year, but I have my doubts.
>>
>> I'm in Support, and I'm maintaining what's there, which will/must work
>> 24/7/365 or huge amounts of money are lost.  It WILL continue for months
>> or years from now
Hi Bret,
> Your position is unusual for such a huge and important company. The
> solution you are using is weak, does not work well and, most
> important, it has not been supported for years.
This is the first time I have worked in Support.  I'm used to
greenfields development, where I am given a task, and I work out the
best way to do it and carry it through.

This, instead, reminds me of Man-rated Space Hardware, which I worked on
in an earlier incarnation of my career.  Nothing is allowed that isn't
certain.  Then it was because we didn't want to kill anyone and because
killing someone would mean slowing down the space program.

Now it's because of the enormous amount of value that is flowing out
every minute of every day - which is paying my and several tens of
thousands of other people's salaries.  This is the ultimate of "if it
ain't broke, don't fix it".  It's worked for 10 years, so leave it alone.

No one changes anything unless there is a VERY good reason, and any
change is a carefully choreographed large scale ballet of interdependent
actions.

And any change takes a long while.  This software will be abandoned for
a replacement which is in it's early planning stages, will be selected
by another company, and won't likely have any of these components in it
(rumour is they are targeting off-the-shelf software).

Only if there is a stoppage is there a concern, and there was one
earlier this year, which was alleviated by the pre-authentication
"work-around".  Now I'm tasked with looking closer - is there a problem
lurking that we should know about?  Is there something that would be a
better fix?  Is there something we can learn in order to know about it
when the next stoppage occurs (which hopefully won't, but we lose sleep
if there is - I'll be on call 24/7 if anything goes wrong).

And I can learn useful knowledge about this software - if I can get
people past the idea that discussion of replacing it is of any practical
value here.  It's not in my power and I'd much rather hear
clarifications of what is what, and how to check on things - skills I
don't have yet and could use.

>  The alternative from
> IOPLEX is the correct replacement solution for the JCIFS HTTP Filter.
> Knowing how large businesses operate, if your management understood
> these facts
Management has already awarded a contract to replace this software. 
It's entirely out of my hands - not even in my company - and it won't
happen for an absolute minimum of 6 months to the first pilot, and more
likely a year or more.  It's just not relevant to my work and needs.  I
need to learn about what we have now.

> Otherwise, you really are on your own in the scenario. The JCIFS HTTP
> Filter is dead code and posts about it here are (normally) just
> ignored.
Now, that's useful.

I'm sad because the answers I have received so far suggest you are all
in a hurry to bury this, and therefore won't tell me things you might
know that would help me work with this filter - which I must do.  There
aren't many other sources of information about it, and I'm unhappy to
think you may not tell me what you know because you want to dispose of
it, rather than because you don't know useful things about it.

Regardless of how much you think badly of it, it's doing very productive
service, and I need to know about it.

Your last above is useful because it helps me to build a case that the
pre-authentication "work-around" might actually be the solution.  I'm
unhappy to say that because it might sway people to comments that
reinforce that idea just because it fits with the idea of "get rid of
it" that I'm hearing, and I'd like to hear any other knowledge anyone
has as well, because this software is not dead for us, and won't be for
a while.

Given how fast credit dried up in 2008, and how all other initiatives
went with it, I am quite comfortable predicting this software will be
used for several more years, given what's about to happen in the global
markets.  There are the beginnings of a plan to replace it, and I don't
expect that to make much headway, because risk taking is about to
disappear again, and the current software is already doing the job quite
well - as long as we can keep it running.  As the markets become
volatile again (and they are going to become VERY volatile again soon)
management will delay, and then shelve, the plans to replace it - so the
need to understand it to support it will have a long lifetime.

So finding out what I can about what could have gone wrong is of great
value to all of those several tens of thousands of people who are
collecting salaries because it keeps working, no matter how much it
isn't the wave of the future.

Please stop telling me to abandon it and instead please help me learn
about it.  Whatever you know about it is useful today to a lot of people.

Thanks,
Bret