Is it a lost cause?

FWIW, my green card and my flowcharting template are both in my Struble on my desk at work. One of these days I'm going to have to work through Struble again just to get back up to speed.

When the Titan was at Cambridge students were encouraged to try to break the security and report success which sometimes led to a job with the department with instructions to close the hole they found.I just missed it but by all accounts the Titan was a hard nut to crack - by comparison hacking the 370 was discouraged as being too easy.

plonk

I REALLY, REALLY miss Execute on x86.

Which are nothing alike. OTOH x86 can be clean today if you confine yourself to a subset of instructions.

If you can't get the "lower intelligence classes" to understand you, maybe you want to reexamine how you're expressing yourself.

At a certain point the compiler has to assume the programmer knows what he's doing when he writes something a certain way.

I think perhaps nine out of ten programmers can write some pretty complex systems without knowing assembler. There are times when you need the tenth guy around, though. I always wanted to be that guy, so I tried to learn the machine language of every machine I worked on.

That's about what I did with PL/I. A bit more than 256 bytes, but still not much. If I worked at it I could probably convert more assembler to PL/I, but at a certain point it's just easier to code the assembler.

The behaviour of rudeness is something that those who are rude need to examine how they are expressing themselves.

Exactly.

Any system that does not involve the programming of I/O,. interrupts, DMA etc at the I/O register level is, in computing terms, simple, for financial systems are presented with a sanitised emulation of an idealised machine, especially when RPG is involved.

There may be complexities in the application, but those complexities are not those of the workings of the underlying computer.

I think that about the only time I *had* to use assembler due to specific HLL limitations was when I needed a TP monitor for an ICL 2903 that could handle application-specific code written in COBOL. The problem was that version of COBOL would only accept a string literal as the name of the called module. As a result I wrote a minimal TP-monitor in PLAN 3 while pushing as much code as possible over the wall to COBOL.

Funnily enough, I took a photograph of my piece of Titan memory this morning...all 512 bytes of it.

It isn't about being able or unable to write complex systems. It's more a matter of their being efficient vs inefficient. Things like "don't put a file open in the inner loop if you can open the file once at the beginning instead". The code works either way, but it has a lot of unnecessary overhead one way that it doesn't the other.

I'm inclined to say that those aspects of computing should be considered simple these days since they are very well established techniques - now when you move on to considering optimising for the various cache levels and sizes and taking full advantage (or trying to) of deep pipelines with multiple execution units, considering processor affinity and handling NUMA considerations then your talking about things that are complex in computing terms. So complex that the optimisation is best performed by software, the art is in designing the hardware and designing the optimisation software to take advantage of it. My hat is off to the people who do this stuff.

True enough - although there are complexities in computing that arise well above the level of the underlying computer - I would say more than there are at that level.

On 2 Jul 2016 04:38:20 -0400, snipped-for-privacy@panix.com (Jeff Jonas) declaimed the following:

Sigma: four-bank, four-port, interleaved memory, allowed CPU and three I/O Processors to chase each other through memory. IOPs came in two types SIOP and MIOP (it's been too long, I don't recall if SIOPs were used with tape-drives, and MIOPs with disks and other random devices)

It's still a case of determining what really generated the interrupt -- from within the interrupt handler, and then dispatching to the correct sub-handler.

For safe programming practice enabling simple calculations, suitable for all ages outside the range of, say, 10 to 75, it is sufficiently easy to write a JavaScript sand-box in an HTML page. The basic idea is to show the result of the value of a textarea in a form - eval(Frm0.TA1.value);.

does that, etc. etc.; you will need a local copy. is simpler; please use a local copy. NOT PI-TESTED.

There must be at least one JavaScript engine in an Internet-supporting Pi distribution; with that, it might not be too difficult to make a browser support HTA coding and/or an equivalent to Windows Script Host, both of which support general un-sandboxed coding.

Execute is the lightest model of self-modifying code, which is a least a bad habit, if not a clear no-no.

It was no accident that execute was not included in x86's. The main need for it was in variable-port I/O, and it was corrected by having I/O addressed via DX.

re:

closer to the sigma was series/1. the series/1 peachtree processor was significant more capable than what was selected for the 37x5 communication controllers. early 70s, the science center ... some past posts

strongly lobbied the communication group to choose the preachtree processor for the 3705 (rather than the processor they were designing) ... and lost.

the folklore is that the official series/1 RPS system had been done by some former kingston os/360 MFT people that moved to boca and tried to reimplement os/360 MFT ... which wasn't good match for the series/1. The folklore for the alternative EDX system was originally done by some summer co-op students at IBM San Jose Research physics lab.

Late 70s, early 80s, one of the baby bells did a 37x5/NCP emulator on series/1 .... the encapsulated SNA RUs in real network, emulated SNA sessions as "cross domain" (i.e. VTAM emulation with no-single-point-of-failue session management out in distributed series/1). Mid-80s, I got sucked into turning it into type-1 product. We tried to put in brickwalls anticipating the corporate dirty tricks that the communication group was well known for. What the communication group then did can only be described as truth is stranger than fiction.

Old post with part of presentation that I gave in Raleigh at SNA architecture review board meeting

part of presentation by one of the original implementors at '86 common user group meeting

continue the lost cause theme ... periodically repeated, in the late

a few short years later, the company goes into the red and was being reorged into the 13 "baby blues" ... in preparation for breaking up the company.

Agreed, but it got into early COBOL as the ALTER ... TO PROCEED TO ... statement. IMO its the worst misfeature that ever got into a high level language. I've seen it used in the past about once, in the worst-written system I've ever had the misfortune to see. Apart from ALTER statements it had:

- meaningless data names (all records and fields over 4 tape files called MTnn where nn incremented in each successive line) and so on for CFnn (cards), LPnn (line printer) and WSnn (working storage).

- no sections in PROCEDURE DIVISION, only paragraphs which all had 5 digit numeric names, but not in any detectable sequence or meaningful order.

The outfit I worked for had unfortunately bought it. It was immediately scrapped when we saw the code and we wrote an equivalent but much better system from scratch, but I digress....

ALTER was declared obsolete in COBOL 1985 and removed from the specification in 2002 but apparently is still supported by some compilers.