[Info-vax] OpenVMS app stacking

[DaveFroble]

Stephen Hoffman wrote:
> On 2018-01-01 18:03:47 +0000, Arne Vajhj said:
> 
>> On 1/1/2018 10:45 AM, Kerry Main wrote:
>>> With OpenVMS, it is very common to run many Apps on one OpenVMS 
>>> instance.
>>
>> It certainly was 30 years ago.
>>
>> But I am not so sure today.
> 
> We aren't always in thirty-year-old environments, either.
> 
> Try getting a dozen apps that all need to run TCP 443 HTTPS playing nice 
> together, some with their own in-built web servers and some using 
> Apache, and with a mix of Tomcat apps all expecting to accept client 
> connections into TCP 8080 and with the clients not using DNS SRV records 
> or PortMunger.   The cherry on top are some apps that are mis-coded to 
> have mismatched DECC$* default settings requirements, but the libraries 
> are old and the third-party dependencies are hard-coded.  Oh, and two of 
> the dozen require the same hardcoded username and conflicting UIC values 
> for entirely different implementations, because of a now-ancient shared 
> dependency, and which means they're all in the same group table.   And 
> one app has an un-prefixed logical name that it needs and that 
> unfortunately conflicts with the filename of a data file in an unrelated 
> app.   Several of the dozen have differing ideas of what the OPENSSL 
> logical name should be referencing, too.  Etc.
> 
> No.  I won't ask you to get the apps among that dozen that are currently 
> also using TCP 80 HTTP moved over to TCP 443 HTTPS, because the audit 
> folks just flagged the against-policy use of HTTP.
> 
> And I definitely won't ask you to get the certificates and certificate 
> management de-conflicted.
> 
> Nor to get TLSv1.3 working, because auditing is asking for that in the 
> near future and that's not something you need to deal with to get the 
> dozen apps stacked and "working" together.
> 
> Go ahead.  App-stack that.   Make my day.   Automatically, of course, 
> because we're not hand-managing these bespoke boxes and these 
> deployments if we can avoid it.
> 
> Yeah, with a managed switch, it'd be possible to remap parts of the 
> network side of this app-stacking nightmare, but the OpenVMS apps 
> themselves aren't always fond of allowing ports to be changed short of 
> patching code, and OpenVMS has no generic mechanisms for establishing 
> profiles for apps for these sorts of tasks, and multiple web servers 
> really don't play well on the same ports short of some reverse proxy... 
> fun.
> 
> Most of the OpenVMS boxes I'm dealing with are now running one related 
> set of apps per box, too.  That's both because there aren't all that 
> many OpenVMS apps and installations around in most organizations, and — 
> when there are multiple unrelated apps in use within an organization — 
> it's easier to not cross the streams when there are.   The folks with 
> those more complex configurations do routinely ask for x86-64 guest 
> support, too; they want more guests and fewer boxes, and they want more 
> consistency among their servers which means fewer not-x86-64 boxes around.
> 
> We are NOT operating with the same sorts of apps we had in the last 
> millennium.   Arbitrary apps just don't stack all that well, not within 
> the existing by-convention, un-enforced, laissez-faire, "coordination" 
> schemes used by and among the apps written classic OpenVMS app developers.
> 
> BTW: has VSI acquired and re-opened the product prefix registry from the 
> folks at HPE?  That registry contains (contained?) the facility prefixes 
> for DEC/Compaq/HP/HPE and third-party products that are intended to be 
> used across organizations.   (For those with source listings access, 
> that was part of what was included in the $FACDEF module, but not 
> everything made it into $FACDEF.)   And those cross-organization apps 
> are the same sorts of apps that we're hoping to be stacking, eh?
> 
> 

I'm sorry Steve, I really didn't mean to laugh as I was reading this.

Well, not much, anyway.

I'm not close enough to the issues to declare "poor design", don't know if it 
would be appropriate, but, it is what it is and you just got to deal with it.

I do have to sympathize with the TLS V1.3 issue, since that's the gorilla 
currently on my back.  (Come on VSI, get that new TCP/IP out)

However, one part reminds me of a discussion we had in the past.  You didn't 
seem too thrilled with my idea of a listener which would peek into a shared 
socket buffer, then send (in whatever way appropriate) the work to another app 
which would us the same socket.  Think that idea might work for all those apps 
waiting for HTTPS connections?  I'm guessing it might require some work on the 
destination apps.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486