[Info-vax] Change Mouse Pointer Color

[Stephen Hoffman]

On 2018-12-03 18:17:34 +0000, Jairo Alves said:

> I meant 'local' as an app that the operator can run in a standalone  
> machine. But reading your explanation above, I see it could still be an 
> X app, because both ends could potentially run in the same box, just 
> like a jupyter notebook can (I know, it's a apples to oranges analogy, 
> but ok).

As mentioned, I'd expect that most new GUIs are HTTPS-based using HTML 
and  JavaScript, or more recently using JavaScript and WebAssembly more 
directly, or servers configured to communicate using REST or ilk in  
conjunction with a local client app running on the target client 
device.  And for a factory floor or process control environment, I'd 
expect these apps to be sending alerts and notifications directly.  
Which is basically what Jupyter Notebooks looks to be doing.  
Specifically, JSON over ZMQ and WebSockets is how the Jupyter web 
clients chat across the network.  In this app, ZMQ and WebSockets are 
the analog of X RPC layer.

> As it doesn't change in any app, aside from the desktop, I think it may 
> not be app related, but the app in question is a full graphical app, 
> the ones that are used in production plants. (similar to InTouch, for 
> example)

Avena InTouch HMI is analogous to X in various ways, but I'd be 
surprised if X were involved in that.  There'll be more similarities 
here to Jupyter than to X, in terms of shared pieces and parts.

> Most of our boxes are rx2660 being used as workstations.

If those boxes are connected to a graphics display monitor using the 
VGA port on the management processor and a USB-connected HID, then 
that's very likely running DECwindows.  DECwindows is the OpenVMS 
implementation of X.  The DECwindows login is very distinctive, if it's 
displayed.  If these boxes boot into a logged in state, that login and 
that logo probably won't be visible, though.

> Industrial Automation is a field with many loong product cycles, 
> everything tends to be kept running for as long as possible.

Well aware of SCADA environments, having worked on SCADA software and 
having been on-site at various installations in the US and 
internationally.  Upwards of three months spent on-site, in one case.  
Some of the factory floor network protocols used with the old embedded 
controllers and PLCs were quite hideous, too.  Worked with several that 
tossed off XON and XOFF characters in their data streams.  As data. Not 
control.  There was one that could toss ^P at a host.  And several that 
generated framing errors—break signals—on power up.  That was fun.  But 
I digress.

> Also, to this date it's not uncommon to run Windows 2000 or XP on many 
> sites, depending on the application needed.

SCADA networks having the same reputation for robust security as does 
IoT, of course.

> The specific system we have is basically unchanged in 20 years. We 
> still get updates once a year or so, but they are mostly error 
> corrections and almost never new features.

OpenVMS hasn't seen all that much change over the past ~20 years, either.

> It's gonna be interesting to go through the x86 port phase.

I'd be surprised to see much in the way of SCADA on OpenVMS on x86-64.  
Not for some years after the production port.  Many will continue to 
use Windows, Windows Server and Linux, and connected with intelligent 
controllers and industrialized IoT and ilk.  And VSI has a whole lot of 
work pending past the x86-64 production port to encourage new app 
adoption on OpenVMS, too.  OpenVMS in supervisory roles seems workable, 
but I don't expect to see OpenVMS boxes commonly performing doing 
direct process control, though stranger things that happened.

As for this case, contact the SCADA vendor for assistance here.  Or 
start reverse-engineering the SCADA software, if that's permissible 
with your licensing.


-- 
Pure Personal Opinion | HoffmanLabs LLC