On 2025-11-29, Dave Froble <davef@tsoft-inc.com> wrote:
Sometimes things don't really change. You count to 10 the same way now as in
1960. (Trivial example)
Are you sure ? I thought maths teaching was heading in a new direction
in multiple parts of your country as shown by this example (which is way
too close to actually being realistic, especially with the "support" infrastructure from the people around the teacher):
https://www.youtube.com/watch?v=Zh3Yz3PiXZw
Now this is opinion, and really a poor argument. While I detest the verbosity
in most things, that is my choice, not the problem you claim.
Back on topic, COBOL is very verbose, but I also hate way too concise languages where the language designers don't even allow words like
"function" to be spelt out in full. You read code many more times than
you write it and having cryptic syntax makes that a lot harder to achieve.
Something like Ada was designed for readability, and I wish all other languages followed that example.
Just waiting for the moment when a newcomer designs a new language which
has syntax resembling TECO... :-)
BTW, I was interested to read about the issues and tradeoffs around
the stopping of standardised testing during the application process
in some higher education establishments a few years ago.
On 12/3/2025 9:07 AM, Simon Clubley wrote:
BTW, I was interested to read about the issues and tradeoffs around
the stopping of standardised testing during the application process
in some higher education establishments a few years ago.
Nothing wrong with tests. They can be helpful. But let me tell you what is >wrong with depending on tests. SOME PEOPLE JUST DON'T DO WELL WITH TESTS!
Case in point. My son always had problems with taking tests. I don't >understand it, but that was a problem for him. Does that make him less than >those who do well with tests?
Now he is a NRC licensed reactor operator at a nuclear power station. Yes, >there was testing, and it was difficult for him. But testing is not how the job
is learned. People actually practiced the job under close supervision before >they were trusted to do the job. Perhaps still a type of testing.
Lately, when special operations are required, He is the one called upon, because
he is trusted to perform the job correctly, over most of the other operators.
I guess what I'm trying to say is while tests can be helpful, they are not >necessarily the only way of determining competence.
Chris Townley <news@cct-net.co.uk> wrote:
On 30/11/2025 21:09, Arne Vajh|+j wrote:
Why would you want that?
The selling point is the automatic persistence of global variables:
Think database. MUMPS globals really are a non-relational database. Non-persistent database would be of limited use.
On 11/3/2025 8:31 AM, Simon Clubley wrote:
What are they moving to, and how are they satisfying the extremely high
constraints both on software and hardware availability, failure
detection,
and recovery that z/OS and its underlying hardware provides ?
z/OS has a unique set of capabilities when it comes to the absolutely
critical this _MUST_ continue working or the country/company dies area.
Note that even though z/OS and mainframes generally have a
good track recording regarding availability, then it is not
a magic solution - they can also have problems.
Banks having mainframe problems are rare but far from
unheard of.
Because a bank mainframe was down for 5 hours.
On 11/11/2025 10:50 AM, Arne Vajh|+j wrote:
On 11/3/2025 8:31 AM, Simon Clubley wrote:
What are they moving to, and how are they satisfying the extremely high
constraints both on software and hardware availability, failure
detection,
and recovery that z/OS and its underlying hardware provides ?
z/OS has a unique set of capabilities when it comes to the absolutely
critical this _MUST_ continue working or the country/company dies area.
Note that even though z/OS and mainframes generally have a
good track recording regarding availability, then it is not
a magic solution - they can also have problems.
Banks having mainframe problems are rare but far from
unheard of.
And speaking of.
A lot of banking services were down Monday in Denmark.
Because a bank mainframe was down for 5 hours.
Both the company and the country survived. :-)
As often is the case the root cause was simple and
stupid. A capacity management application took away
the resources needed to process transactions.
Arne
On 2025-12-18, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 11/11/2025 10:50 AM, Arne Vajh|+j wrote:
On 11/3/2025 8:31 AM, Simon Clubley wrote:
What are they moving to, and how are they satisfying the extremely high >>>> constraints both on software and hardware availability, failureNote that even though z/OS and mainframes generally have a
detection,
and recovery that z/OS and its underlying hardware provides ?
z/OS has a unique set of capabilities when it comes to the absolutely
critical this _MUST_ continue working or the country/company dies area. >>>
good track recording regarding availability, then it is not
a magic solution - they can also have problems.
Banks having mainframe problems are rare but far from
unheard of.
And speaking of.
A lot of banking services were down Monday in Denmark.
Because a bank mainframe was down for 5 hours.
Both the company and the country survived. :-)
As often is the case the root cause was simple and
stupid. A capacity management application took away
the resources needed to process transactions.
I am impressed... :_) where did you read/see this ??
And for those that does not read Danish:
<quote>
JN Data has been working through the night to find the root cause of
the outage on our Mainframe. Initial investigations indicate that an incorrect command in JN Data's capacity management tool was the root
cause of the outage. The incorrect command meant that too little
capacity was allocated to process customers' transactions. As a result, services such as credit cards and online and mobile banking became unavailable for JN Data's customers Jyske Bank, Bankdata, BEC and
Nykredit. We are now working on the underlying cause of this to ensure
that a similar error cannot occur in the future.
</quote>
mod produser /cpu=00:00:01 /wsmax=10 /wsext=20 /pgflq=100
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 70 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 39:23:19 |
| Calls: | 948 |
| Calls today: | 2 |
| Files: | 1,325 |
| Messages: | 280,644 |