[Info-vax] DECserver/LAT across DECnet areas?

[Dave Froble]

On 7/26/2023 6:47 AM, Jan-Erik Söderholm wrote:
> Den 2023-07-26 kl. 02:30, skrev Arne Vajhøj:
>> On 7/25/2023 6:24 PM, Johnny Billquist wrote:
>>> On 2023-07-25 02:06, Arne Vajhøj wrote:
>>>> On 7/24/2023 7:53 PM, Scott Dorsey wrote:
>>>>>                    Not to mention the added overhead from all those layers.
>>>>
>>>> Are those layers that bad?
>>>>
>>>> Sure SSL handshake takes time, but that is not due to the layers
>>>> but due to the nature of the key exchange.
>>>
>>> Let me put a question for you? Are there any number of layers, in your
>>> opinion, where it becomes a problem?
>>>
>>> 1 layer? 10? 100? 1000? At which point does it become a problem, and why? And
>>> if you say 100, for example. Why is 99 not a problem, but 100 is then?
>>
>> Good question. And we all know how it is with answers to good
>> questions.  :-)
>>
>> It is in many ways similar to "how many software layers in an
>> application are too much?" and "how few lines per
>> routine/function/method is too much splitting up?".
>>
>> There is not a single provable correct answer. Based on
>> some industry experience most have a feeling for when
>> a good thing becomes too much.
>
>
> Correct. As I have understood this discussion, it has mainly been around layers
> specficially in the communication stacks.
>
> I have seen a lot of issues where there are "too many" layers in the application
> architecture also. Most often in "modern" solutions using
> some fancy framework where the developer comes longer and longer from the core
> system for each new version of these frameworks.
>
> We have an old VMS solution where the Cobol codes mostly talks directly to
> equipment (like barcode scanners, label printers and PLC in machines) and our
> response times are in 10s of ms. Another (commersial and highly "modern")
> similar system takes up to 1 min for a simple label printout.
>
> There have also been some public projects that have failed due to what I see as
> a failure to understand the whole application architecture...

An example.

Consolidated cannot continue to guarantee (as if there is such a thing) service 
to the customers.  The application has been offered to the customers.  They 
"don't want to be in the software business", even though every user of computers 
is in the software business in some way.  Anyway, the are looking for new solutions.

All the new solutions being considered are "in the cloud".  Microsoft and other 
vendors are involved.  When the prospective vendors consider the customer's 
volume, they have stated "we cannot handle that volume".  That's your "modern 
cloud solutions".

Most of the customers are determined to make the new systems work.  Sadly, we're 
predicting some craters.  Too bad, but we are way over any "retirement age". 
(Yesterday was 77.)


-- 
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