[Info-vax] Kittson question

[Chris Scheers]

johnwallace4 at yahoo.co.uk wrote:
> On Sunday, 4 January 2015 21:09:49 UTC, lji... at gmail.com  wrote:
>> On Sunday, January 4, 2015 11:00:29 AM UTC-5, johnwa... at yahoo.co.uk wrote:
>>> On Sunday, 4 January 2015 15:22:30 UTC, Jan-Erik Soderholm  wrote:
>>>> Scott Dorsey skrev den 2015-01-04 15:33:
>>>>> JF Mezei  <jfmezei.spamnot at vaxination.ca> wrote:
>>>>>> In cases where the customer wants you to perfectly and completely mimic
>>>>>> their current VAX down to device names etc, is this not an indication
>>>>>> that the customer no longer has in-house VMS maintenance expertise and
>>>>>> prefers to pay you more to mimic the environment so no changes need to
>>>>>> be made ?
>>>>> Yes, or even worse he has software that he doesn't understand and cannot
>>>>> change.  Often this is commercial software for which source was never
>>>>> available, or locally-written code for which the source has been lost.
>>>>>
>>>>>> In a situation where someone setting up a new VMS box on that new
>>>>>> architecture I can't name,  wouldn't that imply an active VMS site with
>>>>>> in-house expertise who would be able to move their last VAX apps onto
>>>>>> any emulated instance and change device/disk names if needed ?
>>>>> Not necessarily.  Could be an outside consultant coming in and doing the
>>>>> job and working to get out as quickly as possible.
>>>>>
>>>>>> In other words, when looking at providing emulated VAX-VMS support on
>>>>>> the new VMS, is it really necessary to be able to mimic every different
>>>>>> VAX model with every different config ? Wouldn't a generic VAX emulation
>>>>>> based on one of the last VAX models be more than enough since anyone
>>>>>> setting it up will have the knowledge to tailor their VAX-VMS apps ?
>>>>> I don't think so, but it might be nice and it might make life easier for
>>>>> some customers.  I think this is much more an issue for ELN and Ultrix
>>>>> users than VMS, but I don't think there are any of those left.
>>>> I know a fairly large site which uses VAXeln for the factory
>>>> control systems manufacturing kitchen equipment.
>>>>
>>>>
>>>>> --scott
>>>>>
>>> Exactly. VAXeln has the capability to be fit and forget, as much as
>>> or maybe even more than VMS does/did. Any VAXeln systems that are still
>>> around stand an excellent chance of being almost invisible. 
>>>
>>> Unless a VAXeln application deliberately contains unusually
>>> hardware-specific code, the only real hardware dependence in a VAXeln
>>> system are the OS kernel's hardware-dependent pieces (the ones which
>>> in a VMS system might iirc live in SYSLOAxxx?). In a VAXeln system,
>>> the developer picks the relevant hardware=specific bits when the system
>>> image is configured. Unlike VMS, there's no boot-time mechanism for
>>> choosing the relevant hardware-specific bits for the OS. 
>>>
>>> If the hardware is emulated rather than real, the VAXeln system just
>>> needs the emulator to look sufficiently like the originally chosen
>>> target. On the surface it doesn't sound as though it needs any
>>> particular magick.
>>>
>>> Of course if it's a genuine real-time VAXELN system running in an
>>> emulator on top of Windows, and Windows decides to take a break from
>>> running the emulator for a few hundred milliseconds (as it does),
>>> *that* might sometimes be exciting. Or sometimes it might have no
>>> visible effect.
>> Exact timing is why The Logical Company (which you mentioned before) uses vtVAX for its NuVAX product line - both the QBUS and Unibus models. Logical guarantees that cycle times to custom devices will be the same on the replacement system as on the original VAX. Very important to military users like Patriot, HAWK, Minuteman, Milstar, USN, USAF.
> 
> Well that's interesting wording.
> 
> "Logical guarantees that cycle times to custom devices will be the
> same on the replacement system "
> 
> So we're not saying the instruction timing is the same (that would be
> tricky with a soft emulator)? We are saying the timing of operations
> to/from IOspace is the same?
> 
> Ya gotta be keen to need that kind of thing. And some people (probably
> not many, but possibly with big taxpayer-funded budgets) DO want/need
> that kind of thing.

There's not many users that need this, but there are some and they 
aren't all big or taxpayer funded.

If you run an emulation on a PC and talk to custom hardware through some 
sort of hardware interface, you may discover that PCI (or PCIe) timing 
can get, well, interesting.

PCI read and write times are not symmetric.

PCI timing can vary from motherboard to motherboard.

PCI timing is tied to a clock which may not match the granularity you 
need for your hardware.

It can be a challenge to juggle all this and get the customer's I/O 
working correctly.

Then throw in things like discovering that Windows would occasionally 
hang the system for 15 microseconds when a task that ran every 10 
seconds made a Windows call, which, when the stars were aligned wrong, 
could corrupt the emulated I/O.  (Sometimes, the user's hardware was 
generating a data sample every 10 microseconds, with no buffering.)

Getting all this working correctly can be a bit of a nightmare.

After handling a few of these types of systems, you get a very good 
appreciation of why these systems have never been upgraded or converted 
to newer hardware.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074