Change Manangement Software - Turnover -- MIDRANGE-L

I got this message from Turnover. Out of respect for our customer/vendor 
relationship, they did not want to post it to the list, but said that I could 
do so. Since it tells their side of the story quite clearly, I thought it only 
fair to pass it on to this list.

I would only add, that I did not set out to attack Turnover. I simply responded 
to a post to someone asking about change management software. My original post 
said we were thinking of junking it (and therefor did not recommend it). 
Everything I posted after that was in direct response to questions.



-----Original Message-----
From: Debh@softlanding.com [mailto:Debh@softlanding.com]
Sent: Monday, March 06, 2000 5:38 AM
To: RON@CPUMMS.COM
Subject: 




(Embedded image moved to file: pic20919.pcx)

March 6, 2000




Ron Hawkins, R&D Manager
Computer Processing Unlimited
9235 Activity Rd #104
San Diego, CA 92126


Dear Ron:


Rather  than  post  this  on the web, we decided to send what we would have
posted to you directly.  Here's what we would have posted:


-----


I  just wanted to clear up some of the points that have been made so far on
this web site.


First,   the   use   of  Wisedesk  was  a  way  that  Ron's  company  could
resolve/minimize some of their performance problems.  It was not the source
of  the  problem.   I  just  wanted to clarify that point first, in case it
caused  any of our customers who read this list to shy away from using this
feature.


Second, I want to present "our side" of this story.


Our  tech  support  group  was  contacted  by  our regular contact at Ron's
company  about  a  perceived performance problem.  The way that the problem
was  presented  to  us was that they had upgraded their AS/400 from V4R3 to
V4R4  and  started having performance problems when using our Client/Server
Helpdesk  application.   The  architecture  of  our C/S application is that
there is a Windows C++ program that is communicating with an AS/400 program
over  a TCP/IP socket connection.  This AS/400 program is just a dispatcher
that  takes care of the marshalling of input/output parameters when we want
to  call  RPG  programs  on  the  AS/400.   All of the AS/400 "work" in our
application is being performed by standard ILE RPG and CL programs that are
using standard RPG database I/O.  In other words, there is no ODBC, JDBC or
SQL  in  use anywhere.  Now, I have been working with the AS/400 since V1R3
of OS/400.  I cannot recall any time that an OS/400 upgrade caused standard
RPG  programs  to  perform  or  behave  any  differently?this is one of the
hallmarks  of the AS/400 itself.  I should also point out that we are using
V4R4 ourselves and we have hundreds of other customers that are doing so as
well, so we are confident that our products run fine on V4R4.


However,  since  the  customer was certain that the problem was caused when
they  went  to V4R4, I spent time searching for APAR's to see if there were
any TCP/IP-related PTF's that could affect performance.  I didn't find any.
In  the  meantime,  we  explained  to  our  customer contact how they could
control  the amount of memory and the job priority of our C/S "server" jobs
so  that  they  could  minimize  the effect these jobs were having on other
users  of  the  system.   Since  these  jobs  are  all running in their own
subsystem,  it is relatively simple to control the amount of resources they
are getting.


About a week later, the customer called back to let us know they were still
having  problems.   They  had not done anything to change the tuning of the
server  jobs  as we had suggested.  They did, however, have some additional
information  for us.  The problems appeared only to occur, or were at their
worst,  when  users  were filtering records in our Helpdesk database.  They
told  us that they have thousands of calls logged in their Helpdesk project
database,  and  they  were  experiencing  problems when they were filtering
those  calls  (for example to show just those calls for a specific customer
or  assigned  to  a specific resource).  This is when we explained how they
could  use  Wisedesk  to organize those calls into pre-defined filters that
are dynamically maintained like logical files.


At  no  point  was  there  ever  any mention of performance problems in the
promotion  process.   When Ron posted his complaint in this public forum we
called  the person we had been speaking with to find out what was going on.
He  was  not aware that Ron had posted the message, and he said that things
were  working better now that they were using Wisedesk.  I imagine sometime
after  that  call  he  talked  to  Ron  because  he called back for help on
changing  his  setup  so objects would be moved instead of compiled as they
are promoted.  Our contact told us he had made the configuration changes we
suggested and, in a subsequent conversation, he expressed satisfaction with
the  performance.   However, we also offered to send one of our consultants
on-site  to review their set up and make whatever recommendations he or she
thought appropriate.


I still am not clear whether these perceived problems really did start when
they upgraded to V4R4, or if they existed before then as well.  My guess is
that  they  did  exist before the upgrade.  The V4R4 "issue" is what really
threw  off  our  support  efforts.  Since we were told performance was good
prior  to  the upgrade, we spent our time looking for possible V4R4-related
PTF's  rather  then  looking  for  ways they could change the way they were
using the software.


Once  we  were  supplied  with  more information, we responded as we always
do?we take customer our complaints very seriously, indeed.


So  that  is  our  side  to the story.  I want to thank all of you had good
things to say in our defense.


Mark Phippard, Director of Development
SoftLanding Systems

---



As  you can see, Ron, our Director of Development wrote this in response to
the  complaint  you  posted  on  the  web  site.  Not only was that posting
damaging  to  our  business,  it was also inaccurate.   Mark approached the
Management  Team  asking  whether we thought he should post his response on
the  website.   We discussed it and decided it would be inappropriate to do
so.   We  didn't  want  to "fan the flames" or damage our relationship with
CPU.   However,  if  you chose to post it yourself, that would be fine with
us.


To  say that we were surprised by your comments would be an understatement.
No  one  on  my tech support staff had spoken with you or even knew who you
were?-let alone known of the problem as you reported it.  As a manager in a
responsible  position at a software company, perhaps you could put yourself
in our place.  How would you react to such a broadside in a public forum?


Your  comment will certainly cost us sales?you can bet our competition took
notice.  But,  you  can't  un-ring  a bell, can you?  So, perhaps you would
agree  to  work with us in a constructive way and help us get to the bottom
of  whatever  problems  you  think you have at CPU.  We're confident in our
products and our abilities, as long as we have a chance to employ them.


In  the  future, if you have a problem with our product, I hope you give us
the opportunity to assist you by giving us a call.  Our toll free number is
1-800-545-9485.    I   have   also  included  my  direct  number  for  your
convenience.   Yes,  we  are  making plans to visit your company during the
week  of COMMON, but I hope we don't have to wait that long to get to solve
your problems.


Truly yours,


Deb Holmes


Director of Technical Services
SoftLanding Systems
1-603-924-8818 Ext. 528
debh@softlanding.com
<pic20919.pcx>