[Info-vax] 1 year.

[Jan-Erik Soderholm]

Den 2015-08-06 kl. 17:53, skrev IanD:
> On Thursday, July 30, 2015 at 1:06:32 PM UTC+10, David Froble wrote:
>> IanD wrote:
>>> On Tuesday, July 28, 2015 at 5:10:49 AM UTC+10, Hans Vlems wrote:
>>>> Good, I like a clear, direct statement and your reasoning is
>>>> sound. Now only hobbyists run a VAX and there is no money there
>>>> (and even less at a business that relies on them). But Jan-Erik
>>>> raises a point about Alpha. Work on it that won't generate
>>>> turnover now but will preserve a customer base for you later on.
>>>> How about subcontracting work on alpha/vms, test it on limited
>>>> platforms and supply it with limited wartanty? Hans
>>>
>>> We are stuck on Alpha
>>
>> Is that a business decision or a technical decision?
>>
>> All of our customers are using itanics.  It was a good business
>> decision, and a good technical decision.  They do what the businesses
>> need.  Personally, I'm not a fan of IA-64, for multiple reasons.
>> But, when advising customers, the task is to give them advice that is
>> best for them.
>>
>>> The business has no plans of moving to Itanium.
>>
>> What is the reason for that?  Something not available?
>>
>>> I doubt they can wait for x86 either going by the recent chatter
>>> unless there was a financial incentive to do so
>>
>> So, are the Alpha(s) not doing the job satisfactorily?  What can they
>> not wait for?
>>
>>> Once this VMS platform closes, VMS will have exited this
>>> organisation and I seriously doubt it will get a look in again
>>
>> I have to wonder, it the VMS advantage is as minor for the business
>> as you seem to indicate, and if there are forces pushing for
>> alternative solutions, I'm wondering why VMS is still in use?
>>
>> You've made some claims here, and in the past, that as far as I can
>> see have no details.  Without some details, how can anyone understand
>> whatever points you're trying to make?  Without some details, how can
>> anyone make any suggestions to possibly help you make a case for
>> continuing usage of VMS in your organization?  Can't solve a problem,
>> if one doesn't know what the problem is ....
>>
>>> In telco land as I would imagine in most market segments, letting a
>>> customer walk rather than spending money on retaining them costs
>>> something like about 2.5x's as much as on-boarding a new customer
>>> from scratch, that's a lot of money actually when you take into
>>> account all the costs involved (including advertising etc) and
>>> often they simply do not return once they have walked. Retaining
>>> the existing customer base I think is very important
>>
>> All true ....
>>
>>> So how to retain existing Alpha and dare I say Vax customers so
>>> they keep VMS in the organisation with the potential to build upon
>>> it later?
>>
>> While I'm not a fan of the itanic, it most definitely has been a
>> valid platform for VMS for some time now.  And, it has been less
>> expensive than the VAXs and Alphas before it.
>>
>>> Offer a free x86 version on which they can run their encapsulated
>>> Vax or Alpha system in perhaps? (they would of course still pay for
>>> their existing Alpha licenses etc)
>>
>> Do you mean something such as SimH?  It exists.  It's free.
>>
>>> This would at least keep an VMS presence in the enterprise and as
>>> they are willing/able, functionality could be ported over to the
>>> newer x86 version, over time. Small palatable costs are easier to
>>> swallow than big expensive ones when it comes to budgeting and
>>> approvals
>>
>> My experience in porting from VAX to Alpha, AND from Alpha to the
>> itanic has been that it's rather easy and inexpensive.  I'm not really
>> sure what you might be asking for?
>>
>>> The alternative is what is most likely going to happen where I
>>> work, the system will be migrated to a linux platform and the book
>>> will be closed on OpenVMS period. Emulators are expensive over time,
>>> so they are seen as stop-gap measures to mitigate old hardware
>>> risks
>>
>> If you have applications running on VMS, the easiest and least
>> expensive path is to continue using VMS.  Any migration will be much
>> harder and more expensive.  I'm not claiming that everyone will agree
>> with that. It will depend upon their agenda.  If someone wants off
>> VMS, or just wants Linux, then they will find arguments to support
>> that desire.  Nor do the arguments need to be valid.  They just need
>> to get management to go far enough along so that turning back would be
>> just as expensive as continuing, and of course there is ego, and the
>> unwillingness to admit mistakes.
>>
>> I feel quite sure that if accurate and honest estimates for each
>> path, remain on VMS or migrate to something else, remaining on VMS
>> will be much less expensive.
>>
>>> A good salesperson knows that getting/keeping that 'foot in the
>>> door' is vital for being able to lever future sales
>>
>> Apparently the foot is already in the door, if you're already using
>> VMS.
>>
>>> How to lever those Vax and Alpha shops out there over to the new
>>> x86 vision rather than have them walk (probably for good) is very
>>> important IMO
>>
>> AS I've written, there are valid options.  If for some reason someone
>> refuses to accept them, then I doubt there is anything that could
>> change their mind(s).
>
> Rather than do a point by point response...
>
> Basically the organisation likes VMS from a stability point of view
>
> The application has not been touched in over 10 years and there are
> issues around the source code but I am not at liberty to say what
> exactly or to make further references to the customer base in case
> someone data matches certain things and identifies more information than
> I want to reveal :-)
>
> Then you have the diminishing skills of the folk who are meant to look
> after the application but being VMS adverse, this too is a loosing
> downward spiral
>
> If the code could be lifted and put on an Itanium without the need to
> recompile, the business would have opted for that long ago - hence why I
> asked somewhere else about what exactly does a dynamic static translator
> perform - can it solve this issue for us going ahead?
>
> The customer base was once the ants pants as far as the particular
> industry was concerned but times have changed, they represent a drag on
> profits now and what they were initially required to do in terms of
> rapid expansion is no longer required, so they are not a focus anymore
> hence why the application has languished for so many years
>
> So if I have been terse with my answers, it is with reason in that I do
> not want the industry identified nor do I wish to disclose too much for
> concern that the organisation may possibly suffer customer concern if
> data matching can link the various parts together etc
>
> The alpha is doing the job fine, the problem is the hardware is old,
> going out of support and the application is no longer supported and the
> source code is, err, well, in a 'special' category of it's own
>
> Yes, I have spoken with people on the business side to let them know
> there at least is now a pathway forward as far as VMS is concerned but
> the above problems are driving their decision to get off VMS
>
> Let's just say that a certain organisation, who makes it profit on body
> count based in a certain country where IT wages are cheap and quality is
> sometimes lacking, want a linux system because that way they can rid
> themselves of the expensive VMS skilled folk and look after whatever new
> system comes in with the same resource base they currently have, i.e.
> linux folk. They do not care if this new system match is not the best
> for their customer nor if the new system will perform any better or be
> less stable.
>
> It has now got to the stage where the application folk are looking like
> shall we say, fools in lots of regards as their lack of VMS
> understanding see's things breaking and falling over with the blame
> being put back on 'an old system and an old application'. Thus I am
> fighting fires on different fronts, so to speak, including fire coming
> from my own camp!
>
> I was thinking of looking at ways to extract the rdb queries by putting
> debug flags on...

There is/was also DEC Trace (or whatever Oracle calls it today) that
can "trace" operations against an Rdb database. I think it saves the
BLR (Binary Language Representation) format and there are separate
BLR to SQL translators around.

But DEC Trace was/is not a free tool.

> but this is only part of the equation to working out the
> application functionality internally.

Hm, look it up in the docs, maybe? :-)

Jan-Erik.


> The application itself was
> developed with corba and my skills in that area are next to none
>
> Can anyone help provide guidance on how / who, to contact so that one
> can 'function rip' an application that was developed with corba / c++ I
> believe many years ago and work out a way to develop a new solution on
> VMS when the source code is, shall we say, somewhat hard to acquire?
>
> Solve this issue and VMS will remain in the workplace, otherwise it's
> pending doom is already here :-(
>