Is it a lost cause?

Yup.

The FORTRAN GOTO listed the possibilities, AIR, the COBOL one didn't. I never used it except in a "structured" way, but it would seem like bad programmers could have had a lot of fun with it.

Bookmarked for possible future reference. Thanks.

Neat mechanism, but a nightmare if misused.

How did BCPL handle arrays and did it implement bound checking, i.e. was it possible to create havoc by applying a subscript to a label?

The real problem with ALTER was that the ALTER statements were often quite distant from the GO TOs they affected. In a badly written program it could be surprisingly difficult to work out whether a particular GO TO was the target of an ALTER statement, particularly of the program also included code from a COPY library.

Anyway, I think its justification was based on a false premise, that the sort of conditionals an ALTER would replace were so expensive to execute that merely using ALTERs would make a measurable difference to run times.

As you say, the simple approach was to write structured code and not use ALTERs, but remember that when COBOL was introduced, the concept of structured code was scarcely a gleam in the eye of Djikstra or Wirth.

This is a *low* level language. Anathema to have bounds checking, and anyway arrays were too high level.

In general, if A contained a memory address, then A was an array pointer, regardless of what it pointed to. Then the first element was A!0, second was A!1, etc. Or A!B, where B was an arbitary value. This was syntactic sugar for adding A to B and then using the resulting address for memory access.

To declare an array, you generally used a library function ('newvec' I think) that was like malloc in C (and on which malloc was based), thus getting the address of some memory you could treat as an array. Or you could declare a local array with: let x = vec 100 which declared 102 cells (0 to 100, plus one (named x) that pointed to the base of the 101 cells).

Or you could just use any address you liked, e.g. the address of a device register if it was memory mapped. I worked on a terminal concentrator where we used that a lot.

One last weird one. You could declare a table of predefined values: let x = TABLE 1,2,3,4,5 or whatever. x would get the address of the first cell. By filling the table with actual machine instructions, you could then execute them with: goto x or even x()

!!!!

And remember also that COBOL was designed to do very simple processing on very large data sets.

A COBOL *PROGRAMMER* is the lowest of the low. It is the analyst who does the real work, translating the business problem into code module and data dictionary specifications.

I thought that would be the case.

Understood, and not to different from C, PL/9 etc.

Thanks for the reminder. I think I'd have looked at BCPL in 1974, so I was certain it must have had arrays or it couldn't have been used to write the GPM, but I've entirely forgotten its syntax apart from it being block structured.

IOW implementing a computed goto or function call would be as straight forward as doing it in assembler - and very similar too.

I *resemble* that.

In most of the good development groups I've worked in, analysts and designers were also implementers - and some of these were quite large so that wasn't a small outfit quirk. It was also notable that some of the worst practises and most difficult systems to run were the product of outfits with a NO-CONTACT rule keeping the analysts and designers entirely separate from the implementors and operations groups.

The best working environment was one where the project manager, technical manager and senior developers came onboard during the bid process and, if the bid was won, were responsible for implementing, acceptance testing and delivering the project. This worked, and tended to deliver working projects on time and to budget and without requiring excess overtime, etc.

The size of an array was held in the cell[1] preceding the array (ie A!-1), there were also library functions for packing and unpacking strings of characters into arrays of cells.

That was a mere convention, and not widely observed. Not part of the language.

Of course.

Yes, the term 'cell' came later on when 'words' were not a term used on most target systems.

Exactly. C is much the same, but with a bit more syntactic sugar.

There seem to be several implementations of GPM these days, nit all correct apparently. I have never used it in anger, but I use ML/I quite a bit (e.g. to make it easier to write firewall rules).

Yes, you could have arrays of functions, for example - with a *much* simpler syntax than you have for C - but that's because BCPL is both typeless, and there is no check either on the number of arguments passed to a function!

Was it originally?

You need to reexamine that assumption.

/BAH

Another reason to know assembler is to be able to identify a compiler bug which is generating the wrong machine instructions.

/BAH

back in the day, yes but today?

On 2 Jul 2016 23:55:25 -0400, snipped-for-privacy@panix.com (Jeff Jonas) declaimed the following:

With a compiler that permitted returning the assigned label via parameters in subroutine call, this permitted implementation of coroutines with a master. My manuals are in storage, so I can't provide the full syntax. Essentially, the subroutine would perform an ASSIGN for where it should continue on the next invocation, and return that to the master which could then save it in an array or whatever, and move on to the next subroutine, providing its last saved continuation point.

I think so.

Batch processing of payroll etc etc.

I don't think I do. Of course analysts who couldn't program too were dire, but the general progression was coder -> 'ANAL/PROG' -> Systems analyst

performance issue shows up in machines that prefetch and decode a block of instructions ... where instruction modified may have already been fetched and decoded. also shows up in machines with separate I&D caches where I-cache is assumed to be read/only ... and storage modifications only show up as D-cache (I-cache issues similar to I-stream having already fetched and decode instruction before modification occurs).

recent (Boyd) thread with post about having done dynamic adaptive resource management (as undergraduate in the 60s, IBM picked up and included in CP67

past posts on dynamic adaptive resource management (sometimes referred to as "fair share" because "fair share" was default resource policy

Boyd posts & URLs from around the web

Nope, you won't find that. I've done a lot of BTAM. There is no DSORG in a DD card for BTAM. You just allocate the UCB. When you do an OPEN, you can query the DEVTYPE but the OS doesn't allow the "normal" access methods to use the device.

On Sat, 2 Jul 2016 21:42:04 +0000 (UTC), John Levine declaimed the following:

The only "good" use (besides my aforementioned coroutine case) I'd seen for the ASSIGNed goto was the output of a preprocessor (for some reason, the company I was with did not have access to the proprocessor, only the output files, and had to do maintenance on that).

Input language was a pseudo-C; output was FORTRAN using

ASSIGN 1234 to I001 GOTO 9999

as a local subroutine call,

as the return.

In essence -- thousands of lines of FORTRAN which behaved like BASIC (all variables global, no arguments on subroutine calls, and nearly spaghetti)

When I first started maintaining that -- and porting to VAX from PDP... I ended up putting all the variables into one large common block, and recoded some 60 subroutine files out of all the ASSIGN/GOTO crud. (That was for the main program -- it spawned dozens of others on operator command)