f

#### Holee shit! 30 years ago!

```   Household moving can force one to ditch loads of stuff{1} at source,
or allow everything to reach the destination.  If the latter, one has
a chance to examine most items to determine where to put them in the
new domicile.

Dusting off the contents of a box, I find some ACM Computing Surveys
which haven't been cracked since forever.  The Volume 6 Number 4
December 1974 Special Issue: Programming, had an item by D.E.K. titled
Structured Programming with go to Statements.  I cracked this issue
pronto.  Seems like sacrilege.  Some excerpts, indented:

A revolution is taking place in the way we write programs ...
I should confess that the title of this article was chosen primarily
to generate attention.
B-)
By 1967, the entire XPL compiler had been written by McK., H., and
W. using GO TO only once ...

A Searching Example

In [52], Floyd and I gave the following example of a typical program
for which the ordinary capabilities of WHILE and IF are inadequate.
Let's suppose that we want to search a table A[1]...A[m] of distinct
values, in order to find where a given  x  appears; if  x  is not in
present in the table, we want to insert it as an additional entry.
Let's suppose further that there is another array  B, where  B[i]
equals the number of times we have searched for the value  A[i].
(I don't have ACM's typesetter, so bear with me.  B-)

Some PL/I programmers were asked to do the stated search problem
without using jumps, and they came up with essentially the following
two solutions:

a) DO I = 1 TO M WHILE A(I) ^= X;
END;
IF I > M THEN
DO;  M = I;  A(I) = X;  B(I) = 0;  END;
B(I) = B(I) + 1;

b) FOUND = 0;
DO I = 1 TO M WHILE FOUND = 0;
IF A(I) = X THEN FOUND = 1;
END;
IF FOUND = 0 THEN
DO;  M = I;  A(I) = X;  B(I) = 0;  END;
B(I) = B(I) = 1;

(Clearly, the second '=' above is a typo, yet legal PL/I !)

Solution (a) is the best, but since it involves a null iteration
(with no explicit statements being iterated) most people came up
with solution (b).  The instructive point is that solution (b)
doesn't work; there is a serious bug which caused great puzzle-
ment before the reason was found.  Can the reader spot the dif-
ficulty?  (The answer appears on page 298.)

To me, both examples had serious bugs.  Since DEK doesn't strike me
as a PL/I guru from his publications, he missed the syntax error
of missing parenthesis in the WHILE clauses, which are required in
case there is an array named WHILE in scope.  More grievously, the
value of a loop control variable, namely  I  in the two examples, is
explicitly undefined after loop exit according to PL/I definition.

The variable  I  is increased before  FOUND  is tested.  One way
to fix the program is to insert "I = I - FOUND;" before the last
statement.

The above text was surrounded by a box of stars, like assembler folks
did to test operators' patience during punched card days.  Hmmm.
That's the second clue that the examples were handed to DEK by the
XPL crowd, because it was so prevalent in the section on XMON.  B-)

The snippets are deprived of context through lack of declarations.
Assuming that the table size is reasonable w.r.t the machine's era of
performance using linear search, I'd suggest:

DECLARE   /* the table entry and hit count arrays: */
( A <mumble data type>,
B  FIXED BINARY(<mumble size>)  INITIAL ( (??) 0 )
) (??);     /* Note how factoring dimension keeps arrays same sized */

DECLARE  X <mumble data type>,   /* if we don't want conversions */
( M INITIAL ( 0 ), RESULT )  FIXED BINARY(<mumble size>);
...
CALL LOOKUP ( X, A, B, M, RESULT );
...
LOOKUP:  /* X in A, update count in B, table entries in M, and report
the location in RESULT.  */
PROCEDURE ( X, A, B, M, RESULT );

DECLARE  ( B(*), M, RESULT, I )  FIXED BINARY(<mumble size>),
( X, A(*) ) <mumble data type>;

DECLARE  FOUND  BIT INITIAL ( '0'B ),  HBOUND  BUILTIN;

DO  I = 1 TO M  UNTIL ( FOUND );

IF  X = A(I)  THEN   /* Pure joy! */
DO;
RESULT = I;   B(I) = B(I) + 1;   FOUND = '1'B;
END;
END;

IF  ^FOUND  THEN   /* Can we add a new table entry? */
DO;
IF  M < HBOUND ( A, 1 )  THEN  /* Yes, room enuff. */
DO;
RESULT, M = M + 1;   A(M) = X;   B(M) = 1;
END;
ELSE
DO;
SIGNAL  ERROR | SUBSCRIPTRANGE | CONDITION ? ;
STOP | EXIT;
END;
END;
END LOOKUP;

Clearly, no DEFAULT statements were implied and arrays have lower
bounds starting at one.

Some other justifications for the GO TO in the item were demolished
by  SIGNAL, within loops by LEAVE{2}, and OTHERWISE in SELECTs when
using proper PL/I.  We've come a long way, baby.

{1} I feel a George Carlin routine coming on.
{2} Never needed to use one.  Too GO TO'ish.

[52] ... "Notes on avoiding 'go to' statements," Information
Processing Letters, 1, 1 (Feb. 1971) ...
```
 0
ab528 (61)
1/4/2004 2:15:15 AM
comp.lang.pl1 1741 articles. 0 followers.

131 Replies
1177 Views

Similar Articles

[PageSpeed] 16

```Heinz W. Wiggeshoff wrote:

....

>    More grievously, the
>    value of a loop control variable, namely  I  in the two examples, is
>    explicitly undefined after loop exit according to PL/I definition.

Not so.  PL/I explicitly specifies that upon termination of an iterative do,
the value of the loop control variable is the value that was out of range of
the limit set in the specification.  I.e., the value that failed TO or WHILE
or UNTIL, whichever applies.

In many cases the entire purpose of executing a loop is to get just this
information, and I have always considered languages which go out of their way
to make it unavailable an abomination.

```
 0
jjw (608)
1/4/2004 9:11:51 AM
```In article <bt8lcm\$7uk\$1@morgoth.sfu.ca> jjw@cs.sfu.ca "James J. Weinkam" writes:

[controlled variable's value after termination of a loop]

> In many cases the entire purpose of executing a loop is to get just this
> information, and I have always considered languages which go out of their way
> to make it unavailable an abomination.

Not exactly an abomination: more realistic.  If the language specifies
(as you aseert it does in the case of PL/I) that some value shall exist,
then OK.  However, many languages used to leave it up to the implementor
whether
for i:=1 to 50 do
finished with i having the last value with which the loop was executed
(50), or the first with which it wasn't (51).

With such latitude, the sensible language designer makes it clear that
the value is "undefined".

The sensible programmer NEVER trusts the language designer, whether or
not the value is declared to be undefined: if only on the grounds that
the implementor may not have read that part of the language
specification.  (Personally I like the approach of C++ and Java, where
one writes:
for ( int i = 0; i < 50; i++ )
where one can guarantee that the controlled variable (i) does not EXIST
after termination of the loop.)

--
Brian {Hamilton Kelly}                                          bhk@dsl.co.uk
"We can no longer stand apart from Europe if we would.  Yet we are
untrained to mix with our neighbours, or even talk to them".
George Macaulay Trevelyan, 1919

```
 0
bhk (64)
1/5/2004 1:16:10 AM
```In article <1073257613snz@dsl.co.uk>,
Brian {Hamilton Kelly} <bhk@dsl.co.uk> wrote:

>The sensible programmer NEVER trusts the language designer, whether or
>not the value is declared to be undefined: if only on the grounds that
>the implementor may not have read that part of the language
>specification.

In the modern era, this isn't left to chance; people write test
suites, and that's the kind of item that would definitely be tested
for.

Followups to comp.lang.pl1 only.

-- greg

```
 0
lindahl (697)
1/5/2004 2:13:31 AM
```Brian {Hamilton Kelly} wrote:

> In article <bt8lcm\$7uk\$1@morgoth.sfu.ca> jjw@cs.sfu.ca "James J. Weinkam" writes:
>
> [controlled variable's value after termination of a loop]
>
>
>>In many cases the entire purpose of executing a loop is to get just this
>>information, and I have always considered languages which go out of their way
>>to make it unavailable an abomination.
>
>
> Not exactly an abomination: more realistic.  If the language specifies
> (as you aseert it does in the case of PL/I) that some value shall exist,
> then OK.  However, many languages used to leave it up to the implementor
> whether
>     for i:=1 to 50 do
> finished with i having the last value with which the loop was executed
> (50), or the first with which it wasn't (51).
>
> With such latitude, the sensible language designer makes it clear that
> the value is "undefined".
>
> The sensible programmer NEVER trusts the language designer, whether or
> not the value is declared to be undefined: if only on the grounds that
> the implementor may not have read that part of the language
> specification.  (Personally I like the approach of C++ and Java, where
> one writes:
>     for ( int i = 0; i < 50; i++ )
> where one can guarantee that the controlled variable (i) does not EXIST
> after termination of the loop.)
>

Or Algol 68 where the control variable is *always" new and local to the
loop, so it doesn't exist outside.

In some languages, e.g. the Pascal family, you can iterate over
enumerated types, or subrange types, and the loop will be executed for
all possible values of the control variable, so there is no "next" value
for which the loop test fails.

--brian

--
Brian Boutel
Wellington New Zealand

Note the NOSPAM
```
 0
1/5/2004 2:56:28 AM
```Brian {Hamilton Kelly} wrote:

> In article <bt8lcm\$7uk\$1@morgoth.sfu.ca> jjw@cs.sfu.ca "James J. Weinkam" writes:
> [controlled variable's value after termination of a loop]

>>In many cases the entire purpose of executing a loop is to get just this
>>information, and I have always considered languages which go out of their way
>>to make it unavailable an abomination.

> Not exactly an abomination: more realistic.  If the language specifies
> (as you aseert it does in the case of PL/I) that some value shall exist,
> then OK.  However, many languages used to leave it up to the implementor
> whether
>     for i:=1 to 50 do
> finished with i having the last value with which the loop was executed
> (50), or the first with which it wasn't (51).

> With such latitude, the sensible language designer makes it clear that
> the value is "undefined".

I believe Fortran did it because of properties of index registers on
a machine such as the 704.  Also, optimizing compilers will keep the
index variable in a register and never store it.

Though it shouldn't be hard for a modern optimizing compiler to find
out if it is used after the loop, and only store it if it is.

In Fortran 66 the only way to terminate a loop early was with a branch
to a numbered statement, so one could always set the variable to the
proper value after the loop.

-- glen

```
 0
gah (12851)
1/5/2004 6:15:14 AM
```"Brian {Hamilton Kelly}" <bhk@dsl.co.uk> wrote in message
news:1073257613snz@dsl.co.uk...
> the implementor may not have read that part of the language
> specification.  (Personally I like the approach of C++ and Java, where
> one writes:
>     for ( int i = 0; i < 50; i++ )
> where one can guarantee that the controlled variable (i) does not EXIST
> after termination of the loop.)

Not true[1] for several variants of C++ (including gcc according the web
page below).
http://www.mozilla.org/hacking/portable-cpp.html#variables_in_for

[1] I've never relied on this behaviour and what would happen with
constructor / destructors while probably specified in the C++ standards is
something I don't care to think about.
--
Work peteri@lakeview.co.uk.plugh.org | remove magic word .org to reply
Home peter@ibbotson.co.uk.plugh.org  | I own the domain but theres no MX

```
 0
spambox4 (14)
1/5/2004 9:00:01 AM
```Brian Boutel wrote:
> Or Algol 68 where the control variable is *always" new and local to the
> loop, so it doesn't exist outside.

> In some languages, e.g. the Pascal family, you can iterate over
> enumerated types, or subrange types, and the loop will be executed for
> all possible values of the control variable, so there is no "next" value
> for which the loop test fails.

Which is why Ada follows the Algol-68 plan.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/5/2004 3:44:37 PM
```"John W. Kennedy" (jwkenne@attglobal.net) writes:
> Brian Boutel wrote:
>> Or Algol 68 where the control variable is *always" new and local to the
>> loop, so it doesn't exist outside.
>
>> In some languages, e.g. the Pascal family, you can iterate over
>> enumerated types, or subrange types, and the loop will be executed for
>> all possible values of the control variable, so there is no "next" value
>> for which the loop test fails.
>
> Which is why Ada follows the Algol-68 plan.

And of course, APL took this to its logical conclusion:
no loops required for array operations.

B-)
```
 0
ab528 (61)
1/5/2004 10:17:09 PM
```Brian {Hamilton Kelly} wrote:
> In article <bt8lcm\$7uk\$1@morgoth.sfu.ca> jjw@cs.sfu.ca "James J. Weinkam" writes:
>
> [controlled variable's value after termination of a loop]
>
>
>>In many cases the entire purpose of executing a loop is to get just this
>>information, and I have always considered languages which go out of their way
>>to make it unavailable an abomination.
>
>
> Not exactly an abomination: more realistic.  If the language specifies
> (as you aseert it does in the case of PL/I) that some value shall exist,
> then OK.  However, many languages used to leave it up to the implementor
> whether
>     for i:=1 to 50 do
> finished with i having the last value with which the loop was executed
> (50), or the first with which it wasn't (51).

In that case the language hasn't been completely specified unless the disigner
specifically stated that the value was undefined.

Doing the latter, I still consider an abomination, doing the former is
incompetent design, and doing as was done in PL/I is the sensible thing.

>
> With such latitude, the sensible language designer makes it clear that
> the value is "undefined".

```
 0
jjw (608)
1/5/2004 10:19:19 PM
```In article <btb92k\$1pn\$1\$8302bc10@news.demon.co.uk>,
Peter Ibbotson <spambox@ibbotson.demon.co.uk> wrote:

>Not true[1] for several variants of C++ (including gcc according the web
>page below).
>http://www.mozilla.org/hacking/portable-cpp.html#variables_in_for

Using several-year-old webpages isn't a good way to check things out
-- g++ now emits a useful error if you get the scoping wrong.

-- greg

```
 0
lindahl (697)
1/6/2004 12:34:38 AM
```In <1073257613snz@dsl.co.uk>, on 01/05/2004
at 01:16 AM, bhk@dsl.co.uk (Brian {Hamilton Kelly}) said:

>The sensible programmer NEVER trusts the language designer,

The sensible programmer never trusts a compiler writer who can't be
bothered to follow the language definition.

>where one can guarantee that the controlled variable (i) does not
>EXIST after termination of the loop.)

One can do that in PL/I just as easily. Also, there is a point of
confusion in your wording; in PL/I the term CONTROLLED has a very
different meaning from loop variable.

BEGIN;
DO I=0 TO 49;
whatever;
END;
END;

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/6/2004 3:11:20 PM
```Shmuel (Seymour J.) Metz wrote:
> One can do that in PL/I just as easily. Also, there is a point of
> confusion in your wording; in PL/I the term CONTROLLED has a very
> different meaning from loop variable.
>
>    BEGIN;
>       DO I=0 TO 49;
>          whatever;
>          END;
>       END;

That would be:
BEGIN;
DECLARE I;
DO I = 0 TO 49;
...
END;
END;

But in PL/I, it would, on any compiler that I know of, introduce no
little overhead, not only due to the block prologue/epilogue, but
would special-case begin blocks with no ON statements and only small,
fixed automatic-storage requirements.)

It would be a rather useless exercise in PL/I, anyway, since PL/I
doesn't have ranged variables.  In Ada,

for i in v'range(1) loop
...
end loop;

is the rough equivalent of

DO I = LBOUND(V, 1) TO HBOUND(V, 1);
...
END LOOP;

but in Ada, i is a read-only variable that is guaranteed not to assume
an improper value.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/6/2004 5:23:44 PM
```On Mon, 05 Jan 2004 14:19:19 -0800 in alt.folklore.computers, "James
J. Weinkam" <jjw@cs.sfu.ca> wrote:

>Brian {Hamilton Kelly} wrote:
>> In article <bt8lcm\$7uk\$1@morgoth.sfu.ca> jjw@cs.sfu.ca "James J. Weinkam" writes:
>>
>> [controlled variable's value after termination of a loop]
>>
>>
>>>In many cases the entire purpose of executing a loop is to get just this
>>>information, and I have always considered languages which go out of their way
>>>to make it unavailable an abomination.
>>
>>
>> Not exactly an abomination: more realistic.  If the language specifies
>> (as you aseert it does in the case of PL/I) that some value shall exist,
>> then OK.  However, many languages used to leave it up to the implementor
>> whether
>>     for i:=1 to 50 do
>> finished with i having the last value with which the loop was executed
>> (50), or the first with which it wasn't (51).
>
>In that case the language hasn't been completely specified unless the disigner
>specifically stated that the value was undefined.
>
>Doing the latter, I still consider an abomination, doing the former is
>incompetent design, and doing as was done in PL/I is the sensible thing.

It's a kludge so lazy programmers who don't define a variable or
symbolic constant for the loop limit can have the value accessible: if
the loop limit is so defined, the programmer can unambiguously state:

top := limit;
or
next := limit + 1;

>> With such latitude, the sensible language designer makes it clear that
>> the value is "undefined".

Even better if it is inaccessible: then the compiler is free to
generate whatever fixed loop instructions are supported by the
machine, often "subtract one and branch if greater than zero".

--
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
```
 0
1/6/2004 9:07:11 PM
```In article <u88mvv863escqb8d5bs3khdic38rmcpm2o@4ax.com>,
Brian Inglis  <Brian.Inglis@SystematicSw.ab.ca> wrote:

>Even better if it is inaccessible: then the compiler is free to
>generate whatever fixed loop instructions are supported by the
>machine, often "subtract one and branch if greater than zero".

Modern compilers can make the loop index accessible AND support all
kinds of fancy loop instructions, at the same time. It's not hard;
however you exit the loop, you compute what the current index value
is.

On many modern CPUs, there is no special loop instruction, but it's
common that the index has been changed to some other form via strength
reduction or CSE.

-- greg

```
 0
lindahl (697)
1/6/2004 9:27:02 PM
```In <AaCKb.27498\$Cs3.2871572@news4.srv.hcvlny.cv.net>, on 01/06/2004
at 05:23 PM, "John W. Kennedy" <jwkenne@attglobal.net> said:

>But in PL/I, it would, on any compiler that I know of, introduce no
>little overhead, not only due to the block prologue/epilogue,

In PL/I (F), yes. But in current compilers?

>It would be a rather useless exercise in PL/I, anyway, since PL/I
>doesn't have ranged variables.

When's the last time you looked? Or are you talking strictly ANSI? If
so, I'd consider that inappropriate, since ANSI has effectively taken
itself out of the PL/I standardization game by reaffirming the 1976

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/7/2004 4:48:14 AM
```Shmuel (Seymour J.) Metz wrote:

> In <AaCKb.27498\$Cs3.2871572@news4.srv.hcvlny.cv.net>, on 01/06/2004
>    at 05:23 PM, "John W. Kennedy" <jwkenne@attglobal.net> said:

>>But in PL/I, it would, on any compiler that I know of, introduce no
>>little overhead, not only due to the block prologue/epilogue,

> In PL/I (F), yes. But in current compilers?

do GOTO's out of blocks, and even out of procedures, complicates
the block prologue/epilogue in some cases.  It might be that the
compiler can simplify it in cases where that isn't done, which is
most of the time.

>>It would be a rather useless exercise in PL/I, anyway, since PL/I
>>doesn't have ranged variables.

> When's the last time you looked? Or are you talking strictly ANSI? If
> so, I'd consider that inappropriate, since ANSI has effectively taken
> itself out of the PL/I standardization game by reaffirming the 1976

In comp.lang.c you get laughed at if you mention something that isn't
part of some version of ANSI C, though I can usually get away with
mentioning K&R's pre-ANSI C.

It would be nice to have a standard other than specific implementations.

-- glen

```
 0
gah (12851)
1/7/2004 8:03:28 PM
```Shmuel (Seymour J.) Metz wrote:
> In <AaCKb.27498\$Cs3.2871572@news4.srv.hcvlny.cv.net>, on 01/06/2004
>    at 05:23 PM, "John W. Kennedy" <jwkenne@attglobal.net> said:
>>But in PL/I, it would, on any compiler that I know of, introduce no
>>little overhead, not only due to the block prologue/epilogue,

> In PL/I (F), yes. But in current compilers?

There's still overhead, at least on 360-class machines.  I suppose it's
less when there's a hardware stack.

>>It would be a rather useless exercise in PL/I, anyway, since PL/I
>>doesn't have ranged variables.

> When's the last time you looked? Or are you talking strictly ANSI? If
> so, I'd consider that inappropriate, since ANSI has effectively taken
> itself out of the PL/I standardization game by reaffirming the 1976

I think you are confusing PL/I ORDINAL types with generalized ranging of
discrete types; PL/I ORDINAL types are static (as are, of course, the
equivalent constructs in all truly compilable languages), and they do
not function as pure numbers.  There is simply nothing in PL/I to
compare to something like this in Ada:

get (n);
declare
subtype matrix_size is integer range 1..n;
type matrix is array(matrix_size, matrix_size) of float;
M: matrix;
begin
for i in matrix_size loop
for j in matrix_size loop
get (M(i, j));
end loop;
-- j no longer exists
end loop;
-- i no longer exists

Closest PL/I equivalent:

GET LIST (N);
BEGIN;
DECLARE M(N, N) FLOAT;
DECLARE (I, J) FIXED BINARY;
DO I = 1 TO N;
DO J = 1 TO N;
GET LIST (M(I, J));
END;
/* J IS NOW N + 1 */
END;
/* I IS NOW N + 1 */

In the Ada version, any variable that is declared as of type
"matrix_size" will have _every_ assignment to it checked at runtime, to
ensure that it is in the range 1..n.  However, "i" and "j" above do not
have to be checked, because their declaration in the for loop ensures
that they cannot take out-of-range values.  Moreover, although Ada
normally operates with subscript checking on, that also can be optimized
out in the case above, because "i" and "j" are guaranteed to be in the
same range as the two subscript positions.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/7/2004 9:48:33 PM
```glen herrmannsfeldt wrote:
> Shmuel (Seymour J.) Metz wrote:
>
>> In <AaCKb.27498\$Cs3.2871572@news4.srv.hcvlny.cv.net>, on 01/06/2004
>>    at 05:23 PM, "John W. Kennedy" <jwkenne@attglobal.net> said:
>>> It would be a rather useless exercise in PL/I, anyway, since PL/I
>>> doesn't have ranged variables.
>
>
>> When's the last time you looked? Or are you talking strictly ANSI? If
>> so, I'd consider that inappropriate, since ANSI has effectively taken
>> itself out of the PL/I standardization game by reaffirming the 1976
>
>
> In comp.lang.c you get laughed at if you mention something that isn't
> part of some version of ANSI C, though I can usually get away with
> mentioning K&R's pre-ANSI C.
>
> It would be nice to have a standard other than specific implementations.
>

Wouldn't it, though.  No one seems interested in doing anything about
it.  IBM is happy doing their own thing, and everyone else is either
ignoring them or chasing after them.

```
 0
Peter_Flass (956)
1/7/2004 10:37:32 PM
```glen herrmannsfeldt wrote:
> It would be nice to have a standard other than specific implementations.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/8/2004 1:50:09 AM
```In <kCZKb.244872\$8y1.1130722@attbi_s52>, on 01/07/2004
at 08:03 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>GOTO's out of blocks, and even out of procedures, complicates the
>block prologue/epilogue in some cases.

How? What do you need beyond a simple stack push? What do you need for
the GOTO besides a simple pop?

>It would be nice to have a standard other than specific
>implementations.

IBM has been fighting that one for decades. If ANSI can't be bothered
then there's nothing that IBM can do about it. when the standards body
sits with it's thumb up it's nether regions then you have to go with
de facto standards.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/8/2004 2:00:35 PM
```In <R8%Kb.65205\$Cs3.8245646@news4.srv.hcvlny.cv.net>, on 01/07/2004
at 09:48 PM, "John W. Kennedy" <jwkenne@attglobal.net> said:

>PL/I ORDINAL types are static

You're right, of course; I wasn't thinking in terms of dynamic ranges.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/8/2004 2:03:19 PM
```In <MS%Kb.125739\$JW3.109924@twister.nyroc.rr.com>, on 01/07/2004
at 10:37 PM, Peter Flass <Peter_Flass@Yahoo.com> said:

>IBM is happy doing their own thing,

IBM spent a good deal of money working with ANSI on upgrading the
standard. It wasn't IBM's decision to simply reaffirm the obsolete
1976 version.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/8/2004 2:04:56 PM
```Shmuel (Seymour J.) Metz wrote:
> In <kCZKb.244872\$8y1.1130722@attbi_s52>, on 01/07/2004
>    at 08:03 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>
>>GOTO's out of blocks, and even out of procedures, complicates the
>>block prologue/epilogue in some cases.
>
>
> How? What do you need beyond a simple stack push? What do you need for
> the GOTO besides a simple pop?
>
It changes what conditions are enabled and what the appropriate handlers are
for one thing.  Depending on how the implementation keeps track of this
information this can involve anything from a little to a lot of overhead.

On the other hand, the same overhead is going to happen sooner or later when
the blocks terminate, so I don't see what the complaint is.

```
 0
jjw (608)
1/9/2004 3:57:45 AM
```In <btl8rl\$4i1\$1@morgoth.sfu.ca>, on 01/08/2004
at 07:57 PM, "James J. Weinkam" <jjw@cs.sfu.ca> said:

>It changes what conditions are enabled and what the appropriate
>handlers are  for one thing.

How? The code I gave didn't have a condition prefix on the BEGIN.

>Depending on how the implementation keeps track of this  information
>this can involve anything from a little to a lot of overhead.

For the implementations that I'm aware of, popping the stack
automatically removes any associated condition handlers.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/9/2004 5:35:36 AM
```Shmuel (Seymour J.) Metz wrote:

> In <kCZKb.244872\$8y1.1130722@attbi_s52>, on 01/07/2004
>    at 08:03 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>>GOTO's out of blocks, and even out of procedures, complicates the
>>block prologue/epilogue in some cases.

> How? What do you need beyond a simple stack push? What do you need for
> the GOTO besides a simple pop?

I only did it once, probably just to see if it would work.

With LABEL variables you can GOTO out of a procedure.  I have
seen the explanation of what it has to do to take care of that
case.   I haven't tried to write a code generator to generate
such code, and I really don't want to do it.

It has to figure out what level the stack is on in the procedure
it is going to, and from, and pop the appropriate number of
stack frames.

Also, that assumes a processor with a simple stack.

-- glen

```
 0
gah (12851)
1/9/2004 7:05:47 AM
```"Shmuel (Seymour J.) Metz" wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
> > GOTO's out of blocks, and even out of procedures, complicates the
> > block prologue/epilogue in some cases.
>
> How? What do you need beyond a simple stack push? What do you need
> for the GOTO besides a simple pop?

How many activation images do you purge?  How do you find the
appropriate instruction in the destination procedure, which may

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/9/2004 9:06:43 AM
```"Shmuel  Metz" (spamtrap@library.lspace.org.invalid) writes:
>
> How? What do you need beyond a simple stack push? What do you need for
> the GOTO besides a simple pop?

Without consulting my ancient Execution Time Logic Manual,
off the top of my head,
- free up primary and secondary AUTOMATIC storage
- update ON condition handling on the way back
- beware of recursion, multitasking and I/O in progress
- print a message to the console requesting the programmer be shot.
```
 0
ab528 (61)
1/9/2004 2:56:36 PM
```Shmuel (Seymour J.) Metz (spamtrap@library.lspace.org.invalid) wrote:
: In <kCZKb.244872\$8y1.1130722@attbi_s52>, on 01/07/2004
:    at 08:03 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

: >GOTO's out of blocks, and even out of procedures, complicates the
: >block prologue/epilogue in some cases.

: How? What do you need beyond a simple stack push? What do you need for
: the GOTO besides a simple pop?

Restoring registers at the target (one have to assume that at the point
of jump most of registers contains trash), GCC put such code after
epilogue of blocks that have nonlocal lables.

Closing files?? I do not know if PL/1 closes files when they go out
of scope, but that looks like reasonable thing to do.

For translator going via C89 one have to deallocate variable sized
data (note that native compiler may also choose to allocate variable
sized data on heap).

AFAIKS "normal" implementation of nonlocal jump should unwind the stack
and execute apropriate cleanups on the way. There are various tradeoffs,
but ability to unwind the stack looks like a must -- so prologue must
put on the stack enough info to allow stack unwinding. Naive compiler
is likely to just add to each block cleanups, regardless if the cleanups
are needed or not.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl
```
 0
hebisch (123)
1/9/2004 5:14:07 PM
```Waldek Hebisch (hebisch@math.uni.wroc.pl) writes:
>
....
> Closing files?? I do not know if PL/1 closes files when they go out
> of scope, but that looks like reasonable thing to do.

Nope.  Files are by default EXTERNAL, and thus may be used by
another scope.  However, completing outstanding I/O requests
is reasonable.
```
 0
ab528 (61)
1/9/2004 8:00:38 PM
```"Shmuel  Metz" (spamtrap@library.lspace.org.invalid) writes:
>
> How? The code I gave didn't have a condition prefix on the BEGIN.

Most statements don't.  B-)  Conditions established before the
BEGIN are used within, barring explicit overrides.
```
 0
ab528 (61)
1/9/2004 8:03:09 PM
```"James J. Weinkam" (jjw@cs.sfu.ca) writes:
> Heinz W. Wiggeshoff wrote:
>
> ...
>
>>    More grievously, the
>>    value of a loop control variable, namely  I  in the two examples, is
>>    explicitly undefined after loop exit according to PL/I definition.
>
> Not so.  PL/I explicitly specifies that upon termination of an iterative do,
> the value of the loop control variable is the value that was out of range of
> the limit set in the specification.  I.e., the value that failed TO or WHILE
> or UNTIL, whichever applies.

Even as I typed that, a little flag went up in my mind, but flags are
not always honoured when composing late night posts.
B-)
Perhaps it should've read "should be considered to be undefined as part
of good practice."  Notice that in my version, all actions demanded by
the problem search take place within the loop, and the main result
of the search is passed on in FOUND - the loop index value is useless.
>
> In many cases the entire purpose of executing a loop is to get just this
> information, and I have always considered languages which go out of their way
> to make it unavailable an abomination.

Ah, but there are so many ways to make this technique an abomination
that "the margin is too narrow to contain it."
B-)

Another prejudice against out-of-loop variables arose with the PL/I
Optimizing compiler when the REORDER option applies.  From GC33-0009-4:

Register allocation can be more significantly optimized if REORDER
is specified for the block.  Howver, the values of variables that
are reset in the block are not guaranteed to be the latest assigned
values when a computational interrupt occurs, since the latest value
may be present in a register but not in the storage location of the
variable.  Thus, any on-unit entered for a computational interrupt
must not refer to variables set in the reorder block.

Speaking of interrupts, during a fit of insomnia I dug out another
ACM Computing Surveys Vol. 9 No. 1 Special Issue: Parallel Processors
and Processing.  Turning to p. 61, Pipeline Architecture there is
mention of the IBM 360/91.  That was the beast which not only had
Precise Interrupts, but expanded the fun with Imprecise and
Multiple Imprecise Interrupts.  IIRC, there was an option for the
PL/I Opt. which would saturate object code with NOPR instructions
to drain the pipeline so one could pinpoint the address of the
calamity.  I never got near a 91 or 195, but the last 360 I used,
the 85, may have had mere imprecise int.s, IIRC.

```
 0
ab528 (61)
1/9/2004 8:41:41 PM
```Heinz W. Wiggeshoff wrote:

(snip)

>   Speaking of interrupts, during a fit of insomnia I dug out another
>   ACM Computing Surveys Vol. 9 No. 1 Special Issue: Parallel Processors
>   and Processing.  Turning to p. 61, Pipeline Architecture there is
>   mention of the IBM 360/91.  That was the beast which not only had
>   Precise Interrupts, but expanded the fun with Imprecise and
>   Multiple Imprecise Interrupts.  IIRC, there was an option for the
>   PL/I Opt. which would saturate object code with NOPR instructions
>   to drain the pipeline so one could pinpoint the address of the
>   calamity.  I never got near a 91 or 195, but the last 360 I used,
>   the 85, may have had mere imprecise int.s, IIRC.

I did run PL/I on the 360/91.

If you have the STMT option on it keeps in memory somewhere the number
of the statement being executed.  (It manages to change only the low
byte most of the time.)   If the M91 option is also on it will put
BR 0 instructions between statements.  (That is not what NOPR does.)
That makes sure that it finishes one statement before starting the
next, probably slowing it down a lot.

It will also change the message saying where the program was
executing on a program interrupt or abend to say NEAR instead

My favorite result of this BR 0 instruction was debugging PL/I code
with a debugger that allowed breakpoints.  If you set a breakpoint
it would put an SVC at the breakpoint address to trap when it got
there.  The debugger would then simulate the original instruction
before continuing on.  It turned out that the debugger had a bug
and it actually tried to branch to the address in register 0.

Of course, between statements was the most convenient place to
put breakpoints.

I don't remember which imprecise interrupts the 85 had.

-- glen

```
 0
gah (12851)
1/9/2004 9:08:17 PM
```Shmuel (Seymour J.) Metz wrote:
> In <kCZKb.244872\$8y1.1130722@attbi_s52>, on 01/07/2004
>    at 08:03 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>
>>GOTO's out of blocks, and even out of procedures, complicates the
>>block prologue/epilogue in some cases.
>
>
> How? What do you need beyond a simple stack push? What do you need for
> the GOTO besides a simple pop?
>

It doesn't really complicate prolog/epilog code, but the compiler may
have to pop several DSAs in order to reach the correct GOTO target.

```
 0
Peter_Flass (956)
1/9/2004 11:03:12 PM
```glen herrmannsfeldt wrote:
> I only did it once, probably just to see if it would work.
>
> With LABEL variables you can GOTO out of a procedure.  I have
> seen the explanation of what it has to do to take care of that
> case.   I haven't tried to write a code generator to generate
> such code, and I really don't want to do it.
>
> It has to figure out what level the stack is on in the procedure
> it is going to, and from, and pop the appropriate number of
> stack frames.
>
A LABEL variable should contain the address of the corresponding DSA.
the target.  GOTO label constant may require multiple pops.  Remember
this is not completely unstructured.  You can only GOTO a label in an
active block - either the current block or one higher up in the structure.

```
 0
Peter_Flass (956)
1/9/2004 11:07:05 PM
```Peter Flass wrote:
> glen herrmannsfeldt wrote:
>
> > I only did it once, probably just to see if it would work.
> >
> > With LABEL variables you can GOTO out of a procedure.  I have
> > seen the explanation of what it has to do to take care of that
> > case.   I haven't tried to write a code generator to generate
> > such code, and I really don't want to do it.
> >
> > It has to figure out what level the stack is on in the procedure
> > it is going to, and from, and pop the appropriate number of
> > stack frames.
> >
> A LABEL variable should contain the address of the corresponding
> DSA. The GOTO can then just load the address out of the variable
> and jump to the target.  GOTO label constant may require multiple
> pops.  Remember this is not completely unstructured.  You can
> only GOTO a label in an active block - either the current block
> or one higher up in the structure.

Consider the following Pascal fragment:

PROCEDURE foo;
LABEL 10;

PROCEDURE bar;
VAR f : text;

PROCEDURE foobar;
BEGIN
stuffwritingtof;
IF condition GOTO 10;
END;

BEGIN (* bar *(
rewrite(f);
WHILE whatever DO BEGIN
foobar;
END;
reset(f);
(* use f somehow *)
END;

BEGIN (* foo *)
bar;
(* stuff *)
10: (* morestuff *)
END;

Note that f is a file local to bar.  How do we get it closed while
executing the GOTO?  One way is to leave thunks in each activation
record to be executed on exit, and ensure they get called during
that goto.  It is a pain, and needed even though bar has no labels
or gotos in itself!

This is one place where C's longjump shines.  It nicely separates
out the easy from the complex.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/10/2004 1:15:59 AM
```glen herrmannsfeldt wrote:
> Shmuel (Seymour J.) Metz wrote:
>
>> In <kCZKb.244872\$8y1.1130722@attbi_s52>, on 01/07/2004
>>    at 08:03 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>
>>> GOTO's out of blocks, and even out of procedures, complicates the
>>> block prologue/epilogue in some cases.
>
>
>> How? What do you need beyond a simple stack push? What do you need for
>> the GOTO besides a simple pop?
>
>
> I only did it once, probably just to see if it would work.
>
> With LABEL variables you can GOTO out of a procedure.  I have
> seen the explanation of what it has to do to take care of that
> case.   I haven't tried to write a code generator to generate
> such code, and I really don't want to do it.
>
> It has to figure out what level the stack is on in the procedure
> it is going to, and from, and pop the appropriate number of
> stack frames.
>
> Also, that assumes a processor with a simple stack.

Also, if the LABEL is within a recursively called block, the LABEL
variable, at the time that it is set, is also set to include the current
recursive frame.

DECLARE ONE_TIME BIT INITIAL ('1'B);
DECLARE EXIT_HOLDER LABEL;
RECURSIVE: PROCEDURE (I) RECURSIVE;
DECLARE I FIXED BINARY;
IF ONE_TIME THEN DO;
EXIT_HOLDER = EXIT;
ONE_TIME = '0'B;
END;
IF I = 4 THEN GOTO EXIT_HOLDER;
CALL RECURSIVE (I + 1);
EXIT: PUT (I);
END RECURSIVE;
CALL RECURSIVE (1);

The output will be 1.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/10/2004 1:21:38 AM
```In article <btmngv\$c9f\$1@panorama.wcss.wroc.pl>,
hebisch@math.uni.wroc.pl (Waldek Hebisch) wrote:
>Shmuel (Seymour J.) Metz (spamtrap@library.lspace.org.invalid) wrote:
>: In <kCZKb.244872\$8y1.1130722@attbi_s52>, on 01/07/2004
>:    at 08:03 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>: >GOTO's out of blocks, and even out of procedures, complicates the
>: >block prologue/epilogue in some cases.
>
>: How? What do you need beyond a simple stack push? What do you need for
>: the GOTO besides a simple pop?
>
>Restoring registers at the target (one have to assume that at the point
>of jump most of registers contains trash), GCC put such code after
>epilogue of blocks that have nonlocal lables.
>
>Closing files?? I do not know if PL/1 closes files when they go out
>of scope, but that looks like reasonable thing to do.
>
>For translator going via C89 one have to deallocate variable sized
>data (note that native compiler may also choose to allocate variable
>sized data on heap).
>
>AFAIKS "normal" implementation of nonlocal jump should unwind the stack
>and execute apropriate cleanups on the way. There are various tradeoffs,
>but ability to unwind the stack looks like a must -- so prologue must
>put on the stack enough info to allow stack unwinding. Naive compiler
>is likely to just add to each block cleanups, regardless if the cleanups
>are needed or not.

Don't you ever want to write co-routines?  They depend on the
stack not getting unwound.

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/10/2004 10:57:45 AM
```In <fpsLb.3900\$sv6.15856@attbi_s52>, on 01/09/2004
at 07:05 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>With LABEL variables you can GOTO out of a procedure.

Likewise with label constants. It's just an elaborate pop.

>It has to figure out what level the stack is on in the procedure it
>is going to,

No, the label variable points to the stack frame.

>Also, that assumes a processor with a simple stack.

No. S/360 doesn't have an architected stack, but the IBM PL/I
it up in the LE and PL/I manuals.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/10/2004 11:05:33 PM
```In <3FFE6E8B.CC3DB915@yahoo.com>, on 01/09/2004
at 09:06 AM, CBFalconer <cbfalconer@yahoo.com> said:

>How many activation images do you purge?

None. Popping the stack to the one pointed to by the label variable
takes care of it.

>How do you find the appropriate instruction in the destination procedure,

The label variable points to it.

Why?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/10/2004 11:07:08 PM
```In <btmff4\$8un\$1@freenet9.carleton.ca>, on 01/09/2004
at 02:56 PM, ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) said:

>  Without consulting my ancient Execution Time Logic Manual,

>  - free up primary and secondary AUTOMATIC storage

Don't need to.

>  - update ON condition handling on the way back

Automatic.

>  - beware of recursion, multitasking and I/O in progress

That might be an issue; I'd have to check whether the language
requires detecting such an error.

>  - print a message to the console requesting the programmer be
>shot.

Why? It's not as if he was using C.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/10/2004 11:13:21 PM
```In <btmngv\$c9f\$1@panorama.wcss.wroc.pl>, on 01/09/2004
at 05:14 PM, hebisch@math.uni.wroc.pl (Waldek Hebisch) said:

>Restoring registers at the target (one have to assume that at the
>point of jump most of registers contains trash), GCC put such code
>after  epilogue of blocks that have nonlocal lables.

The issue is PL/I; if there is ever a PL/I front end for GCC then it
will have to ensure that PL/I semantics are supported. For current
PL/I compilers all of the required data are in the stack or registers.

>Closing files??

That might be an issue, especially if there is an I/O pending in
automatic storage.

>For translator going via C89 one have to deallocate variable sized
>data

Only BASED and CONTROLLED. For AUTOMATIC, popping the stack is enough.

>but ability to unwind the stack looks like a must

Absolutely. Otherwise you wouldn't be able to tell whether a label
variable had an obsolete stack pointer.

>Naive compiler is likely to just add to each block cleanups,
>regardless if the cleanups are needed or not.

With the possible exception of closing files, popping the stack should
take care of the cleanup.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/10/2004 11:14:30 PM
```In <btn1dt\$q9g\$1@freenet9.carleton.ca>, on 01/09/2004
at 08:03 PM, ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) said:

>  Most statements don't.  B-)  Conditions established before the
>  BEGIN are used within, barring explicit overrides.

Thank you for telling me the obvious, even if it was irrelevant. My
statement was in response to "It changes what conditions are enabled
and what the appropriate handlers are for one thing." The point is
that the code I gave did *not* change what conditions are enabled and
what the appropriate handlers were.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 3:04:18 AM
```In <btn3m5\$2pf\$1@freenet9.carleton.ca>, on 01/09/2004
at 08:41 PM, ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) said:

>I never got near a 91 or 195, but the last 360 I used,
>  the 85, may have had mere imprecise int.s, IIRC.

No, the 2085 did away with multiple imprecise interrupts. If I recall
correctly, the only imprecise interrupt was on a store, and I won't
guaranty that even that was possible.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 3:06:47 AM
```Shmuel (Seymour J.) Metz wrote:

> In <fpsLb.3900\$sv6.15856@attbi_s52>, on 01/09/2004
>    at 07:05 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

(snip)

>>Also, that assumes a processor with a simple stack.

> No. S/360 doesn't have an architected stack, but the IBM PL/I
> it up in the LE and PL/I manuals.

To me a linked list of DSA is different from a stack, though
others may disagree.  With a stack, you just move the stack
pointer, with DSA chain, each DSA needs to be FREE'ed, in
whatever sense matches the way it was allocated.

I believe they don't do GETMAIN/FREEMAIN for each one, but that
is one possible implementation.

As someone else mentioned, with recursion you need to keep track
of which instance you are GOing TO.

-- glen

```
 0
gah (12851)
1/11/2004 3:07:05 AM
```In <QqGLb.54591\$Dq1.8148@twister.nyroc.rr.com>, on 01/09/2004
at 11:03 PM, Peter Flass <Peter_Flass@Yahoo.com> said:

>It doesn't really complicate prolog/epilog code, but the compiler may
> have to pop several DSAs in order to reach the correct GOTO target.

More precisely, the code already has the address of the correct DSA
but has to unwind the stack in order to ensure that the correct DSA is
still on the stack.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 3:09:31 AM
```In <tuGLb.54656\$Dq1.15988@twister.nyroc.rr.com>, on 01/09/2004
at 11:07 PM, Peter Flass <Peter_Flass@Yahoo.com> said:

>A LABEL variable should contain the address of the corresponding DSA.
> The GOTO can then just load the address out of the variable and jump
>to  the target.  GOTO label constant may require multiple pops.

More precisely, it only requires a single pop but the validity check
may require checking more than one DSA.

>You can only GOTO a label in an active block - either the current
>block or one higher up in the structure.

Or more than one up.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 3:11:41 AM
```In <3fffec2a\$0\$6744\$61fed72c@news.rcn.com>, on 01/10/2004
at 10:57 AM, jmfbahciv@aol.com said:

>Don't you ever want to write co-routines?  They depend on the stack
>not getting unwound.

The Devil is in the details. Whether the stack must not be unwound and
whether there is "the stack" instead of "the stacks" depends on the
semantics of the language and possibly on the implementation as well.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 3:15:25 AM
```CBFalconer wrote:
>
>     [snip...]         [snip...]         [snip...]
>
> Consider the following Pascal fragment:
>
>   PROCEDURE foo;
>     LABEL 10;
>
>     PROCEDURE bar;
>       VAR f : text;
>
>       PROCEDURE foobar;
>         BEGIN
>         stuffwritingtof;
>         IF condition GOTO 10;
>         END;
>
>       BEGIN (* bar *(
>       rewrite(f);
>       WHILE whatever DO BEGIN
>         foobar;
>         END;
>       reset(f);
>       (* use f somehow *)
>       END;
>
>     BEGIN (* foo *)
>     bar;
>     (* stuff *)
> 10: (* morestuff *)
>     END;
>
> Note that f is a file local to bar.  How do we get it closed while
> executing the GOTO?  One way is to leave thunks in each activation
> record to be executed on exit, and ensure they get called during
> that goto.  It is a pain, and needed even though bar has no labels
> or gotos in itself!
>
Hey!!! I thought that "thunks" were routines in *Algol* that
were used to implement "call by name". What on earth have
"thunks" got to do with Pascal???

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+
```
 0
richchas2 (320)
1/11/2004 4:55:23 AM
```glen herrmannsfeldt wrote:
>
> Shmuel (Seymour J.) Metz wrote:
>
> > In <fpsLb.3900\$sv6.15856@attbi_s52>, on 01/09/2004
> >    at 07:05 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
> (snip)
>
> >>Also, that assumes a processor with a simple stack.
>
> > No. S/360 doesn't have an architected stack, but the IBM PL/I
> > it up in the LE and PL/I manuals.
>
> To me a linked list of DSA is different from a stack, though
> others may disagree.  With a stack, you just move the stack
> pointer, with DSA chain, each DSA needs to be FREE'ed, in
> whatever sense matches the way it was allocated.
>
> I believe they don't do GETMAIN/FREEMAIN for each one, but that
> is one possible implementation.
>
With "DSA", I am assuming you mean what PL/I called
"activation records". Each PL/I routine had a "prologue"
that built the activation record, and an "epiloge" that
destroyed it after the procedure or function complete.

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+
```
 0
richchas2 (320)
1/11/2004 4:58:06 AM
```glen herrmannsfeldt wrote:
>
> To me a linked list of DSA is different from a stack, though
> others may disagree.  With a stack, you just move the stack
> pointer, with DSA chain, each DSA needs to be FREE'ed, in
> whatever sense matches the way it was allocated.

You are confusing a data structure with its implementation:

A stack is a last in first out data structure (LIFO).

The two major implementation methodologies are linked (with all operations
taking place at the front of the list, and linear or array, where a subscript
or pointer is simply incremented or decremented.
>
> I believe they don't do GETMAIN/FREEMAIN for each one, but that
> is one possible implementation.

I'm virtually certain you're right.

It's been a long time, but if I recall, PL/I F used a combination of these
methods.  It would allocate a fairly large block of memory and use it linearly
(it was also linked because of the variable size of the blocks (DSA's or
activation records - all the same thing)).  When that was about to overflow,
another block was allocated, and some sort of little special element was
sandwiched in so that on the way back the new block would be freed.  That
reduced the number of GETMAINs and FREEMAINs.  Similarly for controlled and
based variables, it sub allocated from larger blocks to speed things up.
>
> As someone else mentioned, with recursion you need to keep track
> of which instance you are GOing TO.
>
> -- glen
>

```
 0
jjw (608)
1/11/2004 7:43:16 AM
```On Sat, 10 Jan 2004 18:07:08 -0500 in alt.folklore.computers, "Shmuel
(Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote:

>In <3FFE6E8B.CC3DB915@yahoo.com>, on 01/09/2004
>   at 09:06 AM, CBFalconer <cbfalconer@yahoo.com> said:
>
>>How many activation images do you purge?
>
>None. Popping the stack to the one pointed to by the label variable
>takes care of it.
>
>>How do you find the appropriate instruction in the destination procedure,
>
>The label variable points to it.
>
>
>Why?

ISTM Chuck may be talking about Multics and Shmuel IBM
implementations.
--
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
```
 0
1/11/2004 8:21:03 AM
```"Shmuel  Metz" (spamtrap@library.lspace.org.invalid) writes:
> In <btn3m5\$2pf\$1@freenet9.carleton.ca>, on 01/09/2004
>    at 08:41 PM, ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) said:
>
>>I never got near a 91 or 195, but the last 360 I used,
>>  the 85, may have had mere imprecise int.s, IIRC.
^^^^^^^              ^^^^
>
> No, the 2085 did away with multiple imprecise interrupts. If I recall
> correctly, the only imprecise interrupt was on a store, and I won't
> guaranty that even that was possible.
>

```
 0
ab528 (61)
1/11/2004 10:13:39 AM
```"Shmuel  Metz" (spamtrap@library.lspace.org.invalid) writes:
> In <btn3m5\$2pf\$1@freenet9.carleton.ca>, on 01/09/2004
>    at 08:41 PM, ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) said:
>
>>I never got near a 91 or 195, but the last 360 I used,
>>  the 85, may have had *-> mere <-* imprecise int.s, IIRC.

As in "only imprecise, not multiple".
>
> No, the 2085 did away with multiple imprecise interrupts. If I recall
> correctly, the only imprecise interrupt was on a store, and I won't
> guaranty that even that was possible.
>
> --
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>
> Unsolicited bulk E-mail will be subject to legal action.  I reserve
> the right to publicly post or ridicule any abusive E-mail.
>
> Reply to domain Patriot dot net user shmuel+news to contact me.  Do
>

```
 0
ab528 (61)
1/11/2004 10:40:35 AM
```In article <4000bfcd\$30\$fuzhry+tra\$mr2ice@news.patriot.net>,
"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote:
>In <3fffec2a\$0\$6744\$61fed72c@news.rcn.com>, on 01/10/2004
>   at 10:57 AM, jmfbahciv@aol.com said:
>
>>Don't you ever want to write co-routines?  They depend on the stack
>>not getting unwound.
>
>The Devil is in the details.

Huh?

> .. Whether the stack must not be unwound and
>whether there is "the stack" instead of "the stacks" depends on the
>semantics of the language and possibly on the implementation as well.

I'm talking about the programmer wanting to use coroutines, not
the compiler implementation.  If the compiler unwinds all routines
sight unseen, it's not very versatile; it's stuck in only being
good for some applications.

Have you ever written or used co-routines?

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/11/2004 12:35:23 PM
```"Shmuel (Seymour J.) Metz" wrote:
> CBFalconer <cbfalconer@yahoo.com> said:
>
> > How many activation images do you purge?
>
> None. Popping the stack to the one pointed to by the label
> variable takes care of it.
>
> > How do you find the appropriate instruction in the destination
> > procedure,
>
> The label variable points to it.
>
>
> Why?

Because the code for the destination had no reason to be in memory
during execution of the procedure with the goto in it.  It has
been swapped out by the memory manager.  Now it is time to swap it
back in, and take care of any changes required because it is in a
different physical location, etc.  The same thing applies to each
piece of code activated between the routine with the label and the
actual goto instruction.  Each one may require a thunk executed.

It is much simpler to take the C attitude and ban goto out of
procedures.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/11/2004 12:37:14 PM
```In article <40010890.C9749802@yahoo.com>,
CBFalconer <cbfalconer@yahoo.com> wrote:
>"Shmuel (Seymour J.) Metz" wrote:
>> CBFalconer <cbfalconer@yahoo.com> said:
>>
>> > How many activation images do you purge?
>>
>> None. Popping the stack to the one pointed to by the label
>> variable takes care of it.
>>
>> > How do you find the appropriate instruction in the destination
>> > procedure,
>>
>> The label variable points to it.
>>
>>
>> Why?
>
>Because the code for the destination had no reason to be in memory
>during execution of the procedure with the goto in it.  It has
>been swapped out by the memory manager.  Now it is time to swap it
>back in, and take care of any changes required because it is in a
>different physical location, etc.  The same thing applies to each
>piece of code activated between the routine with the label and the
>actual goto instruction.  Each one may require a thunk executed.
>
>It is much simpler to take the C attitude and ban goto out of
>procedures.

It may be easier but it makes it hell to write a good operating
system :-).  What you just described is a SOP in any OS that
knows what it's doing.

I don't understand you people.  YOu're recommending cutting
off all of the thumbs of any capable OS developer.

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/11/2004 12:38:18 PM
```Shmuel (Seymour J.) Metz wrote:
> In <btmngv\$c9f\$1@panorama.wcss.wroc.pl>, on 01/09/2004
>    at 05:14 PM, hebisch@math.uni.wroc.pl (Waldek Hebisch) said:
>
>
>>Restoring registers at the target (one have to assume that at the
>>point of jump most of registers contains trash), GCC put such code
>>after  epilogue of blocks that have nonlocal lables.
>
>
> The issue is PL/I; if there is ever a PL/I front end for GCC then it
> will have to ensure that PL/I semantics are supported. For current
> PL/I compilers all of the required data are in the stack or registers.
>

Apologies for not replying to this at the time.  Following a statement
label, just like at the top of a loop and exit from a loop, and various
other points, the compiler can't make any assumptions about register
contents, etc., since control can reach that point from a number of
places.  Unless it has done extensive analysis of control flow, it

```
 0
Peter_Flass (956)
1/11/2004 1:53:27 PM
```glen herrmannsfeldt wrote:
>
> To me a linked list of DSA is different from a stack, though
> others may disagree.  With a stack, you just move the stack
> pointer, with DSA chain, each DSA needs to be FREE'ed, in
> whatever sense matches the way it was allocated.
>
> I believe they don't do GETMAIN/FREEMAIN for each one, but that
> is one possible implementation.
>

In the implementations I'm familiar with, DSA storage, or at least
initial DSA storage is allocated as a block.  Then it is handled by
software as a stack, with storage allocated and freed just by adjusting
the pointer, with no GETMAIN/FREEMAIN required.  The advantage over a
"true" stack is that it's possible to allocate secondary "extents" when
the primary fills up, although I don't know if this is actually done.

```
 0
Peter_Flass (956)
1/11/2004 2:00:49 PM
```CBFalconer wrote:
>
> It is much simpler to take the C attitude and ban goto out of
> procedures.
>

This is why C is more a high-level assembler than a real programming
language.  It implements what can be done easily and leaves the rest for
"someone else".

```
 0
Peter_Flass (956)
1/11/2004 2:12:21 PM
```jmfbahciv@aol.com wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
> >
.... snip ...
> >
> > It is much simpler to take the C attitude and ban goto out of
> > procedures.
>
> It may be easier but it makes it hell to write a good operating
> system :-).  What you just described is a SOP in any OS that
> knows what it's doing.
>
>
> I don't understand you people.  YOu're recommending cutting
> off all of the thumbs of any capable OS developer.

You failed to follow the whole thread.  C has a means of
implementing such, it is called "longjump".  It serves the
admirable purpose of separating the easy from the (possibly) hard.

I know of no higher level language that can totally dispense with
assembly in creating an OS.  The assembly portions may well be
wrapped and accessed as procedures/functions.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/11/2004 6:33:39 PM
```Heinz W. Wiggeshoff wrote:
> Waldek Hebisch (hebisch@math.uni.wroc.pl) writes:
>
> ...
>
>>Closing files?? I do not know if PL/1 closes files when they go out
>>of scope, but that looks like reasonable thing to do.
>
>
>   Nope.  Files are by default EXTERNAL, and thus may be used by
>   another scope.

This is true but irrelevant.  Even if a file is internal, it is inherently
STATIC and must be left open. After all the procedure or begin block
containing the file can be entered repeatedly and further operations can be
performed on the file.

> However, completing outstanding I/O requests
>   is reasonable.

As far as I can see, the only way there could be outstanding I/O operations is
if a RECORD IO statement with the EVENT option had been executed and not yet
completed and WAITed upon.  I believe I am correct in saying that the only
compilers that support the EVENT option are the F and Optimizing compilers.
It is the responsibility of the programmer to ensure that any asynchronous IO
operations are complete before exiting from the block in which the IO area is
declared.  Otherwise the results of the operation are undefined and could
result in errors or data corruption.

For the more recent compilers, the EVENT option on RECORD IO statements is not
supported.  If asynchronous IO is taking place, it is in another thread.
Again, if the input or output area being used by the asynchronous operation is
in the block being terminated, terminating the block without waiting for
completion of the io is a programming error.  There is no way for the compiler
to handle this automatically.

```
 0
jjw (608)
1/11/2004 7:34:53 PM
```CBFalconer wrote:
>
> Because the code for the destination had no reason to be in memory
> during execution of the procedure with the goto in it.  It has
> been swapped out by the memory manager.  Now it is time to swap it
> back in, and take care of any changes required because it is in a
> different physical location, etc.

You are confusing swapping of virtual memory pages by the memory manager with
releasing and refetching a procedure.  When a page is swapped out and later
brought back into real memory when a reference to it occurs, the real page
frame may and probably will be different, but the virtual addresses all remain
the same.  No fixups are required and the mapping of virtual addresses to real
addresses is handled automatically, and completely transparently, by the

```
 0
jjw (608)
1/11/2004 8:36:04 PM
```In <btquq9\$nmc\$1@morgoth.sfu.ca>, on 01/10/2004
at 11:43 PM, "James J. Weinkam" <jjw@cs.sfu.ca> said:

>It's been a long time, but if I recall, PL/I F used a combination of
>these  methods.

I believe that PL/I (F) did a GETMAIN for each DSA and that the PL/I
"optimizing" compiler introduced the use of an ISA to hold multiple
stack levels if they fit.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 8:45:15 PM
```In <t53Mb.20083\$nt4.42399@attbi_s51>, on 01/11/2004
at 03:07 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>To me a linked list of DSA is different from a stack,

A stack in the CS literature is a FILO list, regardless of how it is
implemented.

>With a stack, you just move the stack
>pointer, with DSA chain, each DSA needs to be FREE'ed,

With a DSA chain you just need to move the stack pointer.

>As someone else mentioned, with recursion you need to keep track of
>which instance you are GOing TO.

That doesn't change anything. Whether recursive or non recursive, an
out of block GOTO is a stack pop. The unwinding for the validity check
is the same either way.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 9:15:15 PM
```CBFalconer wrote:

(snip)

> It is much simpler to take the C attitude and ban goto out of
> procedures.

You mean no setjmp() or longjmp()?

-- glen

```
 0
gah (12851)
1/11/2004 9:18:17 PM
```In <40015496\$0\$6769\$61fed72c@news.rcn.com>, on 01/11/2004
at 12:35 PM, jmfbahciv@aol.com said:

>Huh?

ObPerl There's more than one way to do it.

>I'm talking about the programmer wanting to use coroutines,

Yes, and the Earth moves in an orbit around the Sun. Any more
startling revelations.

>not the compiler implementation.

You were talking about an implementation detail. What kind of code the
compiler has to generate depends on how the compiler implements
coroutines.

>If the compiler unwinds all routines sight unseen,

Define sight unseen? Presumably the compiler will only generate an
unwind in a context where it is appropriate.

>Have you ever written or used co-routines?

Yes. In fact, I would appear to understand them better than you do.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 9:28:39 PM
```In <40010890.C9749802@yahoo.com>, on 01/11/2004
at 12:37 PM, CBFalconer <cbfalconer@yahoo.com> said:

>Because the code for the destination had no reason to be in memory
>during execution of the procedure with the goto in it.

First, you don't know that. Second, if it isn't in use then it will
get paged out in the normal course of events, and paged back in at the
first reference.

>Now it is time to swap it back in,

No. Whatever pages are needed will be paged in as they are referenced;
any pages not referenced can stay on disk.

>and take care of any changes required because it is in a different
>physical location,

Part of paging in is to put the address of the page frame in the page
descriptor.

>etc.

What etc.?

>The same thing applies to each piece of code activated between the
>routine with the label and the actual goto instruction.

Yes, in each case nothing needs to be done except for the things that
the OS would do regardless.

>Each one may require a thunk executed.

There is nothing in PL/I that would require executing a thunk for
stack unwinding.

>It is much simpler to take the C attitude and ban goto out of
>procedures.

It's much simpler to tell the programmer to write in hexadecimal. The
purpose of compilers is to remove complexity from the programmer, even
if the compiler writer has to actually think about what he is doing.
The "C attitude" has caused an immense amount of damage.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 9:37:07 PM
```In <4001946F.5CE88F78@yahoo.com>, on 01/11/2004
at 06:33 PM, CBFalconer <cbfalconer@yahoo.com> said:

>I know of no higher level language that can totally dispense with
>assembly in creating an OS.

ESPOL. It's more than 4 decades old.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/11/2004 9:39:39 PM
```CBFalconer wrote:

> "Shmuel (Seymour J.) Metz" wrote:
>
>>CBFalconer <cbfalconer@yahoo.com> said:
>>
>>
>>>How many activation images do you purge?
>>
>>None. Popping the stack to the one pointed to by the label
>>variable takes care of it.
>>
>>
>>>How do you find the appropriate instruction in the destination
>>>procedure,
>>
>>The label variable points to it.
>>
>>
>>
>>Why?
>
>
> Because the code for the destination had no reason to be in memory
> during execution of the procedure with the goto in it.  It has
> been swapped out by the memory manager.  Now it is time to swap it
> back in, and take care of any changes required because it is in a
> different physical location, etc.  The same thing applies to each
> piece of code activated between the routine with the label and the
> actual goto instruction.  Each one may require a thunk executed.
>
> It is much simpler to take the C attitude and ban goto out of
> procedures.
>

People who advocate banning goto altogether might concede that, while
local gotos within a procedure are an absolute no-no, there is an
arguable case for the "get-me-out-of-here" procedure-exiting goto.

In the Burroughs world these were called "bad gotos", and it was said that
"the only good goto is a bad goto".

--brian

--
Brian Boutel
Wellington New Zealand

Note the NOSPAM
```
 0
1/11/2004 10:34:28 PM
```On Sun, 11 Jan 2004 13:53:27 GMT in alt.folklore.computers, Peter
Flass <Peter_Flass@Yahoo.com> wrote:

>Shmuel (Seymour J.) Metz wrote:
>> In <btmngv\$c9f\$1@panorama.wcss.wroc.pl>, on 01/09/2004
>>    at 05:14 PM, hebisch@math.uni.wroc.pl (Waldek Hebisch) said:
>>
>>
>>>Restoring registers at the target (one have to assume that at the
>>>point of jump most of registers contains trash), GCC put such code
>>>after  epilogue of blocks that have nonlocal lables.
>>
>>
>> The issue is PL/I; if there is ever a PL/I front end for GCC then it
>> will have to ensure that PL/I semantics are supported. For current
>> PL/I compilers all of the required data are in the stack or registers.
>>
>
>Apologies for not replying to this at the time.  Following a statement
>label, just like at the top of a loop and exit from a loop, and various
>other points, the compiler can't make any assumptions about register
>contents, etc., since control can reach that point from a number of
>places.  Unless it has done extensive analysis of control flow, it

Basically, it has to do implicitly behind the scenes what a C
setjmp()/longjmp() pair makes the programmer do explicitly.

--
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
```
 0
1/11/2004 10:42:38 PM
```"James J. Weinkam" wrote:
> CBFalconer wrote:
> >
> > Because the code for the destination had no reason to be in memory
> > during execution of the procedure with the goto in it.  It has
> > been swapped out by the memory manager.  Now it is time to swap it
> > back in, and take care of any changes required because it is in a
> > different physical location, etc.
>
> You are confusing swapping of virtual memory pages by the memory
> manager with releasing and refetching a procedure.  When a page is
> swapped out and later brought back into real memory when a
> reference to it occurs, the real page frame may and probably will
> be different, but the virtual addresses all remain the same.  No
> fixups are required and the mapping of virtual addresses to real
> addresses is handled automatically, and completely transparently,
> by the address translation hardware.

You have led a sheltered life.  What address translation hardware?

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/11/2004 10:54:22 PM
```glen herrmannsfeldt wrote:
> CBFalconer wrote:
>
> (snip)
>
> > It is much simpler to take the C attitude and ban goto out of
> > procedures.
>
> You mean no setjmp() or longjmp()?

No, I mean let them handle the complications, and keep goto
simple.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/11/2004 10:54:24 PM
```Shmuel (Seymour J.) Metz wrote:

> In <btquq9\$nmc\$1@morgoth.sfu.ca>, on 01/10/2004
>    at 11:43 PM, "James J. Weinkam" <jjw@cs.sfu.ca> said:
>
>
>>It's been a long time, but if I recall, PL/I F used a combination of
>>these  methods.
>
>
> I believe that PL/I (F) did a GETMAIN for each DSA and that the PL/I
> "optimizing" compiler introduced the use of an ISA to hold multiple
> stack levels if they fit.

No.  The Optimizer introduced the in-line stack-manipulation code, but
the (F) compiler didn't do a GETMAIN every time.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/12/2004 12:34:14 AM
```"Shmuel (Seymour J.) Metz" wrote:
>  CBFalconer <cbfalconer@yahoo.com> said:
>
> >Because the code for the destination had no reason to be in memory
> >during execution of the procedure with the goto in it.
>
> First, you don't know that. Second, if it isn't in use then it will
> get paged out in the normal course of events, and paged back in at the
> first reference.

I do know that.  I implemented the system.  This is the first
reference.

>
> >Now it is time to swap it back in,
>
> No. Whatever pages are needed will be paged in as they are referenced;
> any pages not referenced can stay on disk.

Who mentioned pages?  There are more things in heaven and earth,
Horatio .....

>
> >and take care of any changes required because it is in a different
> >physical location,
>
> Part of paging in is to put the address of the page frame in the page
> descriptor.

FYI a language feature has to work in every environment in which
it is implemented, not just your chosen microcosm.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/12/2004 12:55:58 AM
```Brian Inglis wrote:
> Flass <Peter_Flass@Yahoo.com> wrote:
> >Shmuel (Seymour J.) Metz wrote:
> >>
.... snip ...
> >>
> >> The issue is PL/I; if there is ever a PL/I front end for GCC then it
> >> will have to ensure that PL/I semantics are supported. For current
> >> PL/I compilers all of the required data are in the stack or registers.
> >
> >Apologies for not replying to this at the time.  Following a statement
> >label, just like at the top of a loop and exit from a loop, and various
> >other points, the compiler can't make any assumptions about register
> >contents, etc., since control can reach that point from a number of
> >places.  Unless it has done extensive analysis of control flow, it
>
> Basically, it has to do implicitly behind the scenes what a C
> setjmp()/longjmp() pair makes the programmer do explicitly.

I don't know if PL/1 has nested procedures and local files or
other objects that need cleanup on exit, as do more advanced
languages such as Pascal, Modula, Ada.  These types of objects are
what makes 'unwinding the stack' a laborious operation.  The one
exception is a complete program abort, where everything stops and
may require human intervention.

C tries to keep things simple.  It allows files, pointers to
allocated memory, and whatnot to be abandoned, creating many
widows and orphans.  Thus the C programmer needs to be aware in
more detail of what is going on, and has more opportunity to
forget or omit things.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/12/2004 12:55:59 AM
```In <4001E756.B45A6B58@yahoo.com>, on 01/12/2004
at 12:55 AM, CBFalconer <cbfalconer@yahoo.com> said:

>I do know that.  I implemented the system.

You implimented *a* system; its faults are not universal. Whatever
gyrations you may go do, they are not intrinsic to PL/I but to the
system you implimented.

>FYI a language feature has to work in every environment in which it
>is implemented,

FYI, a language designer does not have to cater to every crippled
environment that someone may dream up. PL/I does not require dynamic
on a system that doesn't support it, that's not the fault of PL/I. IBM
managed to do it properly on a machine with only 64 KiB, so that
excuse just won't wash.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/13/2004 1:43:29 AM
```In <4001EA50.8A9EB2BD@yahoo.com>, on 01/12/2004
at 12:55 AM, CBFalconer <cbfalconer@yahoo.com> said:

>I don't know if PL/1 has nested procedures and local files or other
>objects that need cleanup on exit,

Nested procedures don't require cleanup on exit. However, if IBM ever
releases OO PL/I, that probably will require it.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/13/2004 1:45:28 AM
```"Shmuel (Seymour J.) Metz" wrote:
> CBFalconer <cbfalconer@yahoo.com> said:
>
> > I do know that.  I implemented the system.
>
> You implimented *a* system; its faults are not universal. Whatever
> gyrations you may go do, they are not intrinsic to PL/I but to the
> system you implimented.
>
> >FYI a language feature has to work in every environment in which it
> >is implemented,
>
> FYI, a language designer does not have to cater to every crippled
> environment that someone may dream up. PL/I does not require dynamic
> on a system that doesn't support it, that's not the fault of PL/I.
> IBM managed to do it properly on a machine with only 64 KiB, so that
> excuse just won't wash.

You seem to be talking about PL/I.  I was talking about other
languages and systems.  I know virtually nothing about PL/I,
except that IBM considered it the cats meouw in the late '60s.  I
even went to one of their indoctrination lectures.

I implemented systems that could run large programs (including
compilers) on small systems, using the equivalent of virtual code
memory, without obscure source modifications.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/13/2004 2:27:35 AM
```"Shmuel (Seymour J.) Metz" wrote:
> CBFalconer <cbfalconer@yahoo.com> said:
>
> > I don't know if PL/1 has nested procedures and local files or
> > other objects that need cleanup on exit,
>
> Nested procedures don't require cleanup on exit. However, if IBM
> ever releases OO PL/I, that probably will require it.

Why do you make such ridiculous categorical statements.  Earlier I
showed some Pascal code that required cleanup.  Either there is
some sort of language barrier, or ...

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/13/2004 2:27:38 AM
```"CBFalconer" <cbfalconer@yahoo.com> wrote in message <news:40035765.B4B4CED5@yahoo.com>...

> "Shmuel (Seymour J.) Metz" wrote:
> > CBFalconer <cbfalconer@yahoo.com> said:
> >
> > > I don't know if PL/1 has nested procedures and local files or
> > > other objects that need cleanup on exit,
> >
> > Nested procedures don't require cleanup on exit. However, if IBM
> > ever releases OO PL/I, that probably will require it.
>
> Why do you make such ridiculous categorical statements.  Earlier I
> showed some Pascal code that required cleanup.  Either there is
> some sort of language barrier, or ...

Well, he's right.  Any memory or resource leaks are easily cleaned
up by restarting the program, the computer, or at worst by FDISK
and reinstalling all software.

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/13/2004 2:56:39 AM
```In article <1073962622.788661@news-1.nethere.net>,
"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>"CBFalconer" <cbfalconer@yahoo.com> wrote in message
<news:40035765.B4B4CED5@yahoo.com>...
>
>> "Shmuel (Seymour J.) Metz" wrote:
>> > CBFalconer <cbfalconer@yahoo.com> said:
>> >
>> > > I don't know if PL/1 has nested procedures and local files or
>> > > other objects that need cleanup on exit,
>> >
>> > Nested procedures don't require cleanup on exit. However, if IBM
>> > ever releases OO PL/I, that probably will require it.
>>
>> Why do you make such ridiculous categorical statements.  Earlier I
>> showed some Pascal code that required cleanup.  Either there is
>> some sort of language barrier, or ...
>
>Well, he's right.  Any memory or resource leaks are easily cleaned
>up by restarting the program, the computer, or at worst by FDISK
>and reinstalling all software.

And our customers would immediately write an SPR with a high
expectation that the bug will be fixed.

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/13/2004 11:18:00 AM
```In <1073962622.788661@news-1.nethere.net>, on 01/12/2004
at 06:56 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:

>Well, he's right.  Any memory or resource leaks are easily cleaned up
>by restarting the program, the computer, or at worst by FDISK and
>reinstalling all software.

Sorry, I was unaware that all languages had the same semantics as
Pascal. Thanks for making that clear.

Are you really that stupid? Note that the article was *not* posted to
a Pascal news group, but *WAS* posted on a PL/I news group, and
therefor the issue was not whether cleanup was required in every
Pascal implementation. It is *NOT* required for PL/I.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/13/2004 4:03:09 PM
```In <40035642.7D44BFB7@yahoo.com>, on 01/13/2004
at 02:27 AM, CBFalconer <cbfalconer@yahoo.com> said:

>Newsgroups: alt.folklore.computers,comp.lang.pl1

>You seem to be talking about PL/I.

>I was talking about other languages and systems.

You were making general claims. Had you stated that some languages
required cleanup, I would not have commented.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/13/2004 4:06:07 PM
```In <40035765.B4B4CED5@yahoo.com>, on 01/13/2004
at 02:27 AM, CBFalconer <cbfalconer@yahoo.com> said:

>Why do you make such ridiculous categorical statements.

PKB. PL/I is not Pascal. Why do you cheat on your income tax?

>Earlier I showed some Pascal code that required cleanup.

Pascal is not the only programming language. Showing that pascal
requires something does not establish that it is required for other
languages.

>Either there is some sort of language barrier,

going to make claims about what an implementation of PL/I requires,
learn some PL/I. Don't assume that all languages are identical.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/13/2004 4:10:57 PM
```<jmfbahciv@aol.com> wrote in message <news:4003e58a\$0\$6746\$61fed72c@news.rcn.com>...

> In article <1073962622.788661@news-1.nethere.net>,
>    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
> >"CBFalconer" <cbfalconer@yahoo.com> wrote in message
> <news:40035765.B4B4CED5@yahoo.com>...
> >
> >> "Shmuel (Seymour J.) Metz" wrote:
> >> > CBFalconer <cbfalconer@yahoo.com> said:
> >> >
> >> > > I don't know if PL/1 has nested procedures and local files or
> >> > > other objects that need cleanup on exit,
> >> >
> >> > Nested procedures don't require cleanup on exit. However, if IBM
> >> > ever releases OO PL/I, that probably will require it.
> >>
> >> Why do you make such ridiculous categorical statements.  Earlier I
> >> showed some Pascal code that required cleanup.  Either there is
> >> some sort of language barrier, or ...
> >
> >Well, he's right.  Any memory or resource leaks are easily cleaned
> >up by restarting the program, the computer, or at worst by FDISK
> >and reinstalling all software.
>
> And our customers would immediately write an SPR with a high
> expectation that the bug will be fixed.

"This behavior is by design."

--
Joe Foster <mailto:jlfoster%40znet.com>     On the cans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/13/2004 5:04:44 PM
```Shmuel (Seymour J.) Metz wrote:
> Are you really that stupid? Note that the article was *not* posted to
> a Pascal news group, but *WAS* posted on a PL/I news group

It was also cross posted to a.f.c.
a.f.c. would just about cover any language, Pascal too!
Watch out for the cross post.

Sam
```
 0
1/13/2004 9:43:23 PM
```"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in message
<news:400416be\$7\$fuzhry+tra\$mr2ice@news.patriot.net>...

> In <1073962622.788661@news-1.nethere.net>, on 01/12/2004
>    at 06:56 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:
>
> >Well, he's right.  Any memory or resource leaks are easily cleaned up
> >by restarting the program, the computer, or at worst by FDISK and
> >reinstalling all software.
>
> Sorry, I was unaware that all languages had the same semantics as
> Pascal. Thanks for making that clear.
>
> Are you really that stupid? Note that the article was *not* posted to
> a Pascal news group, but *WAS* posted on a PL/I news group, and
> therefor the issue was not whether cleanup was required in every
> Pascal implementation. It is *NOT* required for PL/I.

Pascal?  I'm talking about the sort of dain-bramage that would
be demanded for a hypothetical OO PL/I.NET, if, of course, you
want to be able to play in the Billy\$hit.NET litter^Wsand-box!

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/13/2004 10:37:15 PM
```"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:1074033441.198644@news-1.nethere.net...
> "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message
> <news:400416be\$7\$fuzhry+tra\$mr2ice@news.patriot.net>...
>
<snip>
> Pascal?  I'm talking about the sort of dain-bramage that would
> be demanded for a hypothetical OO PL/I.NET, if, of course, you
> want to be able to play in the Billy\$hit.NET litter^Wsand-box!
>

Just JOKING !!!
Well, PL/I is so far "behind" COBOL.  Both Micro Focus and Fujitsu already
offer COBOL compilers for .NET.

And of course, we all know <G> that the 2002 ANSI/ISO COBOL Standards include OO
syntax as "required" by any conforming COBOL compiler.  (Do you PL/I types
"remember" what an ANSI/ISO Standard is.)

P.S.  Now ask me if ANY vendor has actually announced an intention to deliver a
2002 conforming COBOL compiler - much less when.  Does this sound familiar???

--
Bill Klein
wmklein <at> ix.netcom.com

```
 0
wmklein (2605)
1/13/2004 10:47:04 PM
```"William M. Klein" <wmklein@nospam.netcom.com> wrote in message <news:Iz_Mb.7802\$1e.61@newsread2.news.pas.earthlink.net>...

> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:1074033441.198644@news-1.nethere.net...

> > Pascal?  I'm talking about the sort of dain-bramage that would
> > be demanded for a hypothetical OO PL/I.NET, if, of course, you
> > want to be able to play in the Billy\$hit.NET litter^Wsand-box!

> Just JOKING !!!
>    Well, PL/I is so far "behind" COBOL.  Both Micro Focus and Fujitsu already
> offer COBOL compilers for .NET.
>
> And of course, we all know <G> that the 2002 ANSI/ISO COBOL Standards include OO
> syntax as "required" by any conforming COBOL compiler.  (Do you PL/I types
> "remember" what an ANSI/ISO Standard is.)

If there's any concept of "deterministic finalization" or "object
destructors", it won't fly in the Longhorn/WinFX/.NET skies...

> P.S.  Now ask me if ANY vendor has actually announced an intention to deliver a
> 2002 conforming COBOL compiler - much less when.  Does this sound familiar???

URL:http://infogoal.com/cbd/cbdz017.htm

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/13/2004 11:28:13 PM
```"Shmuel (Seymour J.) Metz" wrote:
> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:
>
> > Well, he's right.  Any memory or resource leaks are easily
> > cleaned up by restarting the program, the computer, or at worst
> > by FDISK and reinstalling all software.
>
> Sorry, I was unaware that all languages had the same semantics as
> Pascal. Thanks for making that clear.
>
> Are you really that stupid? Note that the article was *not* posted
> to a Pascal news group, but *WAS* posted on a PL/I news group, and
> therefor the issue was not whether cleanup was required in every
> Pascal implementation. It is *NOT* required for PL/I.

No, it was posted on a.f.c, and cross posted to c.l.pl1.  My
original posting said "I don't know if PL/1 has nested functions
..... but Pascal does and thus ..." or something similar.  You have
since been ranting about never needing cleanup.  I happen to think
that PL/1 is a far deader language than Pascal.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/14/2004 2:53:08 AM
```In <1074033441.198644@news-1.nethere.net>, on 01/13/2004
at 02:37 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:

>Pascal?  I'm talking about the sort of dain-bramage that would be
>demanded for a hypothetical OO PL/I.NET,

Bletch! PL/I.NET would be enough to make me switch to Ada or Java.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/14/2004 3:05:48 AM
```"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in message
<news:4004b20c\$47\$fuzhry+tra\$mr2ice@news.patriot.net>...

> In <1074033441.198644@news-1.nethere.net>, on 01/13/2004
>    at 02:37 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:
>
> >Pascal?  I'm talking about the sort of dain-bramage that would be
> >demanded for a hypothetical OO PL/I.NET,
>
> Bletch! PL/I.NET would be enough to make me switch to Ada or Java.

Didn't Sun deprecate System.runFinalizersOnExit?  Don't use Java
if you've gotten used to absolutely any automatic object cleanup
semantics whatsoever in PL/1!  At least Ada still has "controlled
types", so it can probably do RAII like a sane language.

URL:http://hackcraft.net/raii/

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/14/2004 5:56:01 AM
```Joe "Nuke Me Xemu" Foster wrote:

(snip)

> Didn't Sun deprecate System.runFinalizersOnExit?  Don't use Java
> if you've gotten used to absolutely any automatic object cleanup
> semantics whatsoever in PL/1!  At least Ada still has "controlled
> types", so it can probably do RAII like a sane language.

Yes, Java doesn't even flush buffers and close files on
exit.  After getting used to C doing it I have more than
once forget to do it in Java.

-- glen

```
 0
gah (12851)
1/14/2004 8:25:21 AM
```In article <1074013489.361888@news-1.nethere.net>,
"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
><jmfbahciv@aol.com> wrote in message
<news:4003e58a\$0\$6746\$61fed72c@news.rcn.com>...
>
>> In article <1073962622.788661@news-1.nethere.net>,
>>    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>> >"CBFalconer" <cbfalconer@yahoo.com> wrote in message
>> <news:40035765.B4B4CED5@yahoo.com>...
>> >
>> >> "Shmuel (Seymour J.) Metz" wrote:
>> >> > CBFalconer <cbfalconer@yahoo.com> said:
>> >> >
>> >> > > I don't know if PL/1 has nested procedures and local files or
>> >> > > other objects that need cleanup on exit,
>> >> >
>> >> > Nested procedures don't require cleanup on exit. However, if IBM
>> >> > ever releases OO PL/I, that probably will require it.
>> >>
>> >> Why do you make such ridiculous categorical statements.  Earlier I
>> >> showed some Pascal code that required cleanup.  Either there is
>> >> some sort of language barrier, or ...
>> >
>> >Well, he's right.  Any memory or resource leaks are easily cleaned
>> >up by restarting the program, the computer, or at worst by FDISK
>> >and reinstalling all software.
>>
>> And our customers would immediately write an SPR with a high
>> expectation that the bug will be fixed.
>
>"This behavior is by design."
>
<grin>  The old DEC customers would laugh at the joke and then
ask when will it be fixed.  Then we had to get serious and give
them an estimate.  If it was a hard problem (e.g., not reproducible),
we would tell them so.  That meant that we had an army of vigilant
people out there looking for the behaviour and a way to reproduce it.
The one who found it became a  momentary hero (we also published
SPR reports and most answers to them).  Never underestimate people's
pleasure in pointing out your error and/or corrections.  It can be
a RPITA when abused; the tradeoff is that you have all of your
customers also working for you and themselves.

I don't know how a company whose customer base is as large as Misoft
could manage problem reports so that you have all of your customers
working for you and trying to help make a better product.  Just
the volume of problem reports coming in is mind-boggling.

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/14/2004 10:36:59 AM
```In article <40052d77\$0\$6736\$61fed72c@news.rcn.com>,  <jmfbahciv@aol.com> wrote:
>In article <1074013489.361888@news-1.nethere.net>,
>   "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>><jmfbahciv@aol.com> wrote in message
><news:4003e58a\$0\$6746\$61fed72c@news.rcn.com>...
>>

>>> >Well, he's right.  Any memory or resource leaks are easily cleaned
>>> >up by restarting the program, the computer, or at worst by FDISK
>>> >and reinstalling all software.
>>>
>>> And our customers would immediately write an SPR with a high
>>> expectation that the bug will be fixed.
>>
>>"This behavior is by design."
>>
><grin>  The old DEC customers would laugh at the joke and then
>ask when will it be fixed.  Then we had to get serious and give
>them an estimate.  If it was a hard problem (e.g., not reproducible),
>we would tell them so.  That meant that we had an army of vigilant
>people out there looking for the behaviour and a way to reproduce it.
>The one who found it became a  momentary hero (we also published
>SPR reports and most answers to them).  Never underestimate people's
>pleasure in pointing out your error and/or corrections.  It can be
>a RPITA when abused; the tradeoff is that you have all of your
>customers also working for you and themselves.

Early adopters of technology tend to form communities that
do not follow customer/vendor lines, but follows the technology.
Unfortunatly this tends to break down abruptly at some point.

Just look at the railroad people 1830-1852; they formed such
but the close-knit community unraveled in the railroad crash (on
the stock market) of 1852.

The telegraph was similar, but this was unraveled by a hot
technical disagreement on open-ended, ground return vs
balanced circuits. This must have been the first major nerd
flamefest with major money at stake. Lord Kelvin got his title
by stepping in and solving the problem of the first transatlantic
cable by making a balanced circuit of it. The logical next step
was the telephone, as this could work on a balanced circuit.

The modern unity between programmers went away in a three-stage
process. The first was the mini/micro revolution that fragmented
the community; then IBM/Microsoft that tried their best to control
it, and then the insane Y2K boom and bust.

The unity that was there once is gone for good. There are
segments where it survives; but a microsoft programmer would not
feel any particular commonality with someone doing embedded work.

>I don't know how a company whose customer base is as large as Misoft
>could manage problem reports so that you have all of your customers
>working for you and trying to help make a better product.  Just
>the volume of problem reports coming in is mind-boggling.

They don't.

There are a number of showstoppers here. MS charges money by the
minute for all support, including the back-reporting of errors that
could actually help MS. The result is that the customers that has
found a solution has a strong incentive NOT to report it back.
Second, all MS support etc is strongly embedded in the MS culture
of hiding (but not managing) complexity; so the real reason is not
appearant in the vast bulk of complaints. They really need a database
with statistical assistance to find their way in the matter.

They also have a rigid build and release process that costs them
a lot to manage; mostly in terms of manpower. It appears this
has gotten so bad they needed a break in november.

So, MS programmers suffer a lot from being "inside looking out".

-- mrr
```
 0
firstname7 (17)
1/14/2004 1:30:25 PM
```In <1074061587.253967@news-1.nethere.net>, on 01/13/2004
at 09:56 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:

>Didn't Sun deprecate System.runFinalizersOnExit?

Don't know.

>Don't use Java if you've gotten used to absolutely any automatic
>object cleanup semantics whatsoever in PL/1!

What object cleanup? Or are you referring to the freeing of automatic
storage?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/14/2004 2:33:30 PM
```In <4004ABC1.2D3D70A2@yahoo.com>, on 01/14/2004
at 02:53 AM, CBFalconer <cbfalconer@yahoo.com> said:

>No, it was posted on a.f.c, and cross posted to c.l.pl1.

It was posted to every news group that appeared on the Newsgroups
*DOES* refer to a PL/I news group and does *NOT* refer to a Pascal
news group. So "Note that the article was *not* posted to a Pascal
news group, but *WAS* posted on a PL/I news group," is correct.

>My original posting said "I don't know if PL/1 has nested functions
>..... but Pascal does and thus ..." or something similar.

And I responded to the part that referred to PL/I:

> I don't know if PL/1 has nested procedures and local files or
> other objects that need cleanup on exit,

Nested procedures don't require cleanup on exit. However, if IBM
ever releases OO PL/I, that probably will require it.

Had my comment referred to Pascal I would not have trimmed the
remainder of the sentence.

>You have since been ranting about never needing cleanup.

No, I've been rebutting comments from people who either can't read or
who believe that all languages require the same run time environment.
Pascal is not required, so cleanup specific to Pascal is not required
unless there is a Pascal context.

>I happen to think that PL/1 is a far deader language than Pascal.

Then by all means use Pascal. I happen to think that it is a brain

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/14/2004 2:59:00 PM
```Morten Reistad wrote:

> In article <40052d77\$0\$6736\$61fed72c@news.rcn.com>,  <jmfbahciv@aol.com>
> wrote:
>>In article <1074013489.361888@news-1.nethere.net>,
>>   "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>>><jmfbahciv@aol.com> wrote in message
>><news:4003e58a\$0\$6746\$61fed72c@news.rcn.com>...
>>>
>
>>>> >Well, he's right.  Any memory or resource leaks are easily cleaned
>>>> >up by restarting the program, the computer, or at worst by FDISK
>>>> >and reinstalling all software.
>>>>
>>>> And our customers would immediately write an SPR with a high
>>>> expectation that the bug will be fixed.
>>>
>>>"This behavior is by design."
>>>
>><grin>  The old DEC customers would laugh at the joke and then
>>ask when will it be fixed.  Then we had to get serious and give
>>them an estimate.  If it was a hard problem (e.g., not reproducible),
>>we would tell them so.  That meant that we had an army of vigilant
>>people out there looking for the behaviour and a way to reproduce it.
>>The one who found it became a  momentary hero (we also published
>>SPR reports and most answers to them).  Never underestimate people's
>>pleasure in pointing out your error and/or corrections.  It can be
>>a RPITA when abused; the tradeoff is that you have all of your
>>customers also working for you and themselves.
>
> Early adopters of technology tend to form communities that
> do not follow customer/vendor lines, but follows the technology.
> Unfortunatly this tends to break down abruptly at some point.
>
> Just look at the railroad people 1830-1852; they formed such
> but the close-knit community unraveled in the railroad crash (on
> the stock market) of 1852.
>
> The telegraph was similar, but this was unraveled by a hot
> technical disagreement on open-ended, ground return vs
> balanced circuits. This must have been the first major nerd
> flamefest with major money at stake. Lord Kelvin got his title
> by stepping in and solving the problem of the first transatlantic
> cable by making a balanced circuit of it. The logical next step
> was the telephone, as this could work on a balanced circuit.
>
> The modern unity between programmers went away in a three-stage
> process. The first was the mini/micro revolution that fragmented
> the community; then IBM/Microsoft that tried their best to control
> it, and then the insane Y2K boom and bust.
>
> The unity that was there once is gone for good. There are
> segments where it survives; but a microsoft programmer would not
> feel any particular commonality with someone doing embedded work.
>
>>I don't know how a company whose customer base is as large as Misoft
>>could manage problem reports so that you have all of your customers
>>working for you and trying to help make a better product.  Just
>>the volume of problem reports coming in is mind-boggling.
>
> They don't.
>
> There are a number of showstoppers here. MS charges money by the
> minute for all support, including the back-reporting of errors that
> could actually help MS. The result is that the customers that has
> found a solution has a strong incentive NOT to report it back.

FWIW, they do have in place now an automated system that reports to them
failures which cause a program to abend--I haven't put an analyzer on the
system to find out what information it sends back.  It asks
first--generally if I suspect a Microsoft problem I let it, if I suspect a
third-party driver problem then I don't see much point.

> Second, all MS support etc is strongly embedded in the MS culture
> of hiding (but not managing) complexity; so the real reason is not
> appearant in the vast bulk of complaints. They really need a database
> with statistical assistance to find their way in the matter.
>
> They also have a rigid build and release process that costs them
> a lot to manage; mostly in terms of manpower. It appears this
> has gotten so bad they needed a break in november.
>
> So, MS programmers suffer a lot from being "inside looking out".
>
> -- mrr

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)
```
 0
jclarke (338)
1/14/2004 4:11:55 PM
```jmfbahciv@aol.com writes:
> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
> ><jmfbahciv@aol.com> wrote
> >> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
[snip]
> >> >Well, he's right.  Any memory or resource leaks are easily cleaned
> >> >up by restarting the program, the computer, or at worst by FDISK
> >> >and reinstalling all software.
> >>
> >> And our customers would immediately write an SPR with a high
> >> expectation that the bug will be fixed.
> >
> >"This behavior is by design."
> >
> <grin>  The old DEC customers would laugh at the joke and then
> ask when will it be fixed.  Then we had to get serious and give
> them an estimate.  If it was a hard problem (e.g., not reproducible),
> we would tell them so.  That meant that we had an army of vigilant
> people out there looking for the behaviour and a way to reproduce it.
> The one who found it became a  momentary hero (we also published
> SPR reports and most answers to them).  Never underestimate people's
> pleasure in pointing out your error and/or corrections.  It can be
> a RPITA when abused; the tradeoff is that you have all of your
> customers also working for you and themselves.

One of DEC's field people taught us about "FUGs" -- it's a
feature, not a bug.

I once had the job of handling tech problems for a larger
VAX/VMS installation.  One day the DEC tech support person
with whom I was speaking commented that we never called
with simple problems.  I advised that we took care of the
simpler problems ourselves and passed along only the
difficult ones.

> I don't know how a company whose customer base is as large as Misoft
> could manage problem reports so that you have all of your customers
> working for you and trying to help make a better product.  Just
> the volume of problem reports coming in is mind-boggling.

Option 1: Ignore problem reports.  Option 2: Claim the
problem could not exist in /our/ product.
```
 0
mojaveg (82)
1/14/2004 4:38:23 PM
```"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in message
<news:4005533a\$5\$fuzhry+tra\$mr2ice@news.patriot.net>...

> In <1074061587.253967@news-1.nethere.net>, on 01/13/2004
>    at 09:56 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:
>
> >Didn't Sun deprecate System.runFinalizersOnExit?
>
> Don't know.
>
> >Don't use Java if you've gotten used to absolutely any automatic
> >object cleanup semantics whatsoever in PL/1!
>
> What object cleanup? Or are you referring to the freeing of automatic
> storage?

If a PL/1 function or subroutine has opened a file, database transaction,
or some other limited resource as a local variable, could it be cleaned
up automagically upon exiting the function or subroutine, or must it be
always cleaned up explicitly, creating the possibility of resource leaks?

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/14/2004 5:40:19 PM
```"Morten Reistad" <firstname@lastname.pr1v.n0> wrote in message <news:h9g3ub.o93.ln@via.reistad.priv.no>...

> The unity that was there once is gone for good. There are
> segments where it survives; but a microsoft programmer would not
> feel any particular commonality with someone doing embedded work.

Is this why Microsoft's "Embedded" crap is getting nowhere fast? =)

> There are a number of showstoppers here. MS charges money by the
> minute for all support, including the back-reporting of errors that
> could actually help MS. The result is that the customers that has
> found a solution has a strong incentive NOT to report it back.
> Second, all MS support etc is strongly embedded in the MS culture
> of hiding (but not managing) complexity; so the real reason is not
> appearant in the vast bulk of complaints. They really need a database
> with statistical assistance to find their way in the matter.

They also appear to monitor Usenet and other forums where Microslop
products are ranted and raved about.

Hmm, nothing relevant to PL/1 here, so followups set.

--
Joe Foster <mailto:jlfoster%40znet.com>     On the cans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/14/2004 5:50:33 PM
```Shmuel (Seymour J.) Metz wrote:
> In <1074061587.253967@news-1.nethere.net>, on 01/13/2004
>    at 09:56 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:
>>Didn't Sun deprecate System.runFinalizersOnExit?
> Don't know.

Yes, because it was deeply broken, and could lead to hangs.  Of course,
because Java only finalizes during garbage collection, it is expected
that under normal circumstances, non-memory resources will be cleaned up
by the user, by some means other than the use of finalize.  (E.g., files
should be closed when done with.)  Because Java has fairly strong
exception handling, with a "finally" option (i.e., execute this code
when exiting this block, whether normally or via an exception), that
isn't terribly difficult.

>>Don't use Java if you've gotten used to absolutely any automatic
>>object cleanup semantics whatsoever in PL/1!

> What object cleanup? Or are you referring to the freeing of automatic
> storage?

Files closing at program exit, I suppose, since PL/I doesn't explicitly
support any non-memory resources except files, and doesn't have a
garbage collector.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/14/2004 5:56:52 PM
```"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message <news:R17Nb.48270\$5V2.65649@attbi_s53>...

> Joe "Nuke Me Xemu" Foster wrote:
>
> (snip)
>
> > Didn't Sun deprecate System.runFinalizersOnExit?  Don't use Java
> > if you've gotten used to absolutely any automatic object cleanup
> > semantics whatsoever in PL/1!  At least Ada still has "controlled
> > types", so it can probably do RAII like a sane language.
>
> Yes, Java doesn't even flush buffers and close files on
> exit.  After getting used to C doing it I have more than
> once forget to do it in Java.

C's atexit() is wonderful for catching and cleaning up resource leaks,
if libraries maintain lists of "open" resources so a cleanup function
could step through and release each one:

URL:http://mkssoftware.com/docs/man3/atexit.3.asp

In Java and .NyET, on the other hand, the current "best practice" seems
to be to throw exceptions from the finalizers if any object hadn't been
explicitly cleaned up, crashing the program.  Is that moronic or what?!

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/14/2004 6:12:11 PM
```"John W. Kennedy" <jwkenne@attglobal.net> wrote in message <news:EpfNb.35622\$G04.7316249@news4.srv.hcvlny.cv.net>...

> Shmuel (Seymour J.) Metz wrote:
> > In <1074061587.253967@news-1.nethere.net>, on 01/13/2004
> >    at 09:56 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:
> >>Didn't Sun deprecate System.runFinalizersOnExit?
> > Don't know.
>
> Yes, because it was deeply broken, and could lead to hangs.  Of course,
> because Java only finalizes during garbage collection, it is expected
> that under normal circumstances, non-memory resources will be cleaned up
> by the user, by some means other than the use of finalize.  (E.g., files
> should be closed when done with.)  Because Java has fairly strong
> exception handling, with a "finally" option (i.e., execute this code
> when exiting this block, whether normally or via an exception), that
> isn't terribly difficult.

Having to resort to "finally" isn't terribly bright, either:

URL:http://www.research.att.com/~bs/bs_faq2.html#finally considered harmful

> >>Don't use Java if you've gotten used to absolutely any automatic
> >>object cleanup semantics whatsoever in PL/1!
>
> > What object cleanup? Or are you referring to the freeing of automatic
> > storage?
>
> Files closing at program exit, I suppose, since PL/I doesn't explicitly
> support any non-memory resources except files, and doesn't have a
> garbage collector.

It would be nicer if resources could be reclaimed at subroutine exit.
A number of languages support this by using "reference counting", and
some of those deal with "circular references" via incremental garbage
collection to catch any orphaned cycles of reference-counted objects.

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/14/2004 6:34:36 PM
```Morten Reistad wrote, in <h9g3ub.o93.ln@via.reistad.priv.no>:

> The telegraph was similar, but this was unraveled by a hot
> technical disagreement on open-ended, ground return vs
> balanced circuits. This must have been the first major nerd
> flamefest with major money at stake. Lord Kelvin got his title
> by stepping in and solving the problem of the first transatlantic
> cable by making a balanced circuit of it. The logical next step
> was the telephone, as this could work on a balanced circuit.

Kelvin's Atlantic cable system was single wire, earth return as were all
subsequent long distance cables.  I earned my living as a watchkeeper on
cable relay stations for five years.  The term balancing in submarine
cable telegraphy referred to the method of duplex working where the
cable was balanced against an artificial line in a Wheatstone bridge
arrangement with the receiving instrument in the cross-circuit.
--
Nick Spalding
```
 0
spalding (9)
1/14/2004 6:40:18 PM
```Joe "Nuke Me Xemu" Foster wrote:

> "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in message
> <news:4005533a\$5\$fuzhry+tra\$mr2ice@news.patriot.net>...
>
>
>>In <1074061587.253967@news-1.nethere.net>, on 01/13/2004
>>   at 09:56 PM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:
>>
>>
>>>Didn't Sun deprecate System.runFinalizersOnExit?
>>
>>Don't know.
>>
>>
>>>Don't use Java if you've gotten used to absolutely any automatic
>>>object cleanup semantics whatsoever in PL/1!
>>
>>What object cleanup? Or are you referring to the freeing of automatic
>>storage?
>
>
> If a PL/1 function or subroutine has opened a file, database transaction,
> or some other limited resource as a local variable, could it be cleaned
> up automagically upon exiting the function or subroutine, or must it be
> always cleaned up explicitly, creating the possibility of resource leaks?

All PL/I files are STATIC, so they can be cleaned up only at program exit.

PL/I itself is aware of no resources other than memory and files (and

DB2 will clean up its own resources; I think IMS will, too.

Ada and C++ are the only languages I can think of, offhand, with the
right sort of architecture to do this within the language model.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams.  "Judgement at Chelmsford"

```
 0
jwkenne (1442)
1/14/2004 10:17:11 PM
```jmfbahciv@aol.com wrote:

> In article <1073962622.788661@news-1.nethere.net>,
>    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>
>>Well, he's right.  Any memory or resource leaks are easily cleaned
>>up by restarting the program, the computer, or at worst by FDISK
>>and reinstalling all software.
>
>
> And our customers would immediately write an SPR with a high
> expectation that the bug will be fixed.
>
> Subtract a hundred and four for e-mail.

That, unfortunately, is why DEC is gone and the blither8ing idiots of
Redmond are still going strong.  Gresham's law of software -- cr*p
drives out good code because it's quicker and cheaper to grind out, and
the maintenance cost are soooooo much lower.

```
 0
Peter_Flass (956)
1/14/2004 11:02:37 PM
```"John W. Kennedy" wrote:
> Joe "Nuke Me Xemu" Foster wrote:
>
.... snip ...
> >
> > If a PL/1 function or subroutine has opened a file, database transaction,
> > or some other limited resource as a local variable, could it be cleaned
> > up automagically upon exiting the function or subroutine, or must it be
> > always cleaned up explicitly, creating the possibility of resource leaks?
>
> All PL/I files are STATIC, so they can be cleaned up only at program exit.
>
> PL/I itself is aware of no resources other than memory and files (and
>
> DB2 will clean up its own resources; I think IMS will, too.
>
> Ada and C++ are the only languages I can think of, offhand, with
> the right sort of architecture to do this within the language model.

Pascal also.  Not the non-standard version created by Borland.
Files are automatically closed when the scope in which they are
declared is exited.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.

```
 0
cbfalconer (19194)
1/15/2004 1:08:43 AM
```"John W. Kennedy" <jwkenne@attglobal.net> wrote in message <news:HdjNb.36239\$G04.8065744@news4.srv.hcvlny.cv.net>...

> Joe "Nuke Me Xemu" Foster wrote:

> > If a PL/1 function or subroutine has opened a file, database transaction,
> > or some other limited resource as a local variable, could it be cleaned
> > up automagically upon exiting the function or subroutine, or must it be
> > always cleaned up explicitly, creating the possibility of resource leaks?
>
> All PL/I files are STATIC, so they can be cleaned up only at program exit.
>
> PL/I itself is aware of no resources other than memory and files (and
>
> DB2 will clean up its own resources; I think IMS will, too.

Only when they can tell that a client has released some resource.

> Ada and C++ are the only languages I can think of, offhand, with the
> right sort of architecture to do this within the language model.

Visual Basic, RealBasic, and some versions of Python can do this,
even for objects allocated in the dynamic heap instead of the stack,
because their objects are reference-counted.  Objects derived from
COM interfaces in Delphi also use ref-counting "garbage collection".
In VB and RB, the documentation states outright that objects will be
cleaned up and their destructor routines invoked immediately after
the last reference to an object is released, and BTW, beware the big

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/15/2004 1:27:18 AM
```In article <hUjNb.158180\$JW3.15145@twister.nyroc.rr.com>,
Peter Flass <Peter_Flass@Yahoo.com> wrote:
>jmfbahciv@aol.com wrote:
>
>> In article <1073962622.788661@news-1.nethere.net>,
>>    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>>
>>>Well, he's right.  Any memory or resource leaks are easily cleaned
>>>up by restarting the program, the computer, or at worst by FDISK
>>>and reinstalling all software.
>>
>>
>> And our customers would immediately write an SPR with a high
>> expectation that the bug will be fixed.
>>
>> Subtract a hundred and four for e-mail.
>
>That, unfortunately, is why DEC is gone and the blither8ing idiots of
>Redmond are still going strong.  Gresham's law of software -- cr*p
>drives out good code because it's quicker and cheaper to grind out, and
>the maintenance cost are soooooo much lower.

Our (PDP-10) maintenance costs (on the software side) mushroomed
with code.  We were not allowed (in the 80s) to close an SPR
with a thanks for the dump but we couldn't figure out why it
happened.  Nor could we answer an SPR with "don't do that".

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/15/2004 12:37:58 PM
```In article <tb86ub.qlj.ln@via.reistad.priv.no>,
>In article <40069b5f\$0\$18905\$61fed72c@news.rcn.com>,
> <jmfbahciv@aol.com> wrote:
>>In article <hUjNb.158180\$JW3.15145@twister.nyroc.rr.com>,
>>   Peter Flass <Peter_Flass@Yahoo.com> wrote:
>>>jmfbahciv@aol.com wrote:
>>>
>[snip]
>>>> And our customers would immediately write an SPR with a high
>>>> expectation that the bug will be fixed.
>>>>
>>>> Subtract a hundred and four for e-mail.
>>>
>>>That, unfortunately, is why DEC is gone and the blither8ing idiots of
>>>Redmond are still going strong.  Gresham's law of software -- cr*p
>>>drives out good code because it's quicker and cheaper to grind out, and
>>>the maintenance cost are soooooo much lower.
>>
>>Our (PDP-10) maintenance costs (on the software side) mushroomed
>>with code.  We were not allowed (in the 80s) to close an SPR
>>with a thanks for the dump but we couldn't figure out why it
>>happened.  Nor could we answer an SPR with "don't do that".
>
>Not even SEP? (Someone Else's Problem).

Since we were the manufacturer and all-around software provider
we didn't have too many of those.  And, if it were an SEP,
process.  It fucking hard to convince the guy who reviewed SPR
answers that it was an SEP (he was a compiler thinker).

> ...ISP's have 30-70 % rates
>of SEP in their error logs. Or PED (Performing According to Design);
>i.e. it is SUPPOSED to crash when you do that. Another 10.15%.
>You also have URI (Unreproducible on Reference Installation),
>i.e. a reference for those installations where they have too much
>custom things for the installation to work right.
>
>This is why we had our first-line support actually verify if
>things worked from their site. In around 85% of cases, it did.
>As long as you have verified it is a customer problem you can
>bill by the hour.

We didn't bill by the hour.  We often wished we could just to get
rid of the nuisance submissions.

Example of our process...I don't know the time/effort that occurred
before I got an SPR to work on, but it was not small.  I receive
an SPR that says, "The word foobar in a comment in the routine
BAZ in the file FORMES.MAC should be spelled FOOBAR." and it's marked
as urgent.  It could take as much a week of wallclock time to get
that answer out of the door into the snail mail addressed to the
customer.  And YES, we did get urgent SPRs about typos in the
comments (it's an example of SPR abuse).  Just my prep time to
produce the FILCOM that showed the answer could take a half day
and that's not counting a rebuild plus binary FILCOMS to ensure
I didn't break anything.

Like I said our methods of managing SPRs were braindead.

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/15/2004 1:48:08 PM
```In article <40069b5f\$0\$18905\$61fed72c@news.rcn.com>,
<jmfbahciv@aol.com> wrote:
>In article <hUjNb.158180\$JW3.15145@twister.nyroc.rr.com>,
>   Peter Flass <Peter_Flass@Yahoo.com> wrote:
>>jmfbahciv@aol.com wrote:
>>
[snip]
>>> And our customers would immediately write an SPR with a high
>>> expectation that the bug will be fixed.
>>>
>>> Subtract a hundred and four for e-mail.
>>
>>That, unfortunately, is why DEC is gone and the blither8ing idiots of
>>Redmond are still going strong.  Gresham's law of software -- cr*p
>>drives out good code because it's quicker and cheaper to grind out, and
>>the maintenance cost are soooooo much lower.
>
>Our (PDP-10) maintenance costs (on the software side) mushroomed
>with code.  We were not allowed (in the 80s) to close an SPR
>with a thanks for the dump but we couldn't figure out why it
>happened.  Nor could we answer an SPR with "don't do that".

Not even SEP? (Someone Else's Problem). ISP's have 30-70 % rates
of SEP in their error logs. Or PED (Performing According to Design);
i.e. it is SUPPOSED to crash when you do that. Another 10.15%.
You also have URI (Unreproducible on Reference Installation),
i.e. a reference for those installations where they have too much
custom things for the installation to work right.

This is why we had our first-line support actually verify if
things worked from their site. In around 85% of cases, it did.
As long as you have verified it is a customer problem you can
bill by the hour.

-- mrr

```
 0
firstname7 (17)
1/15/2004 2:33:33 PM
```In <1074103948.447987@news-1.nethere.net>, on 01/14/2004
at 09:40 AM, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> said:

>If a PL/1 function or subroutine has opened a file, database
>transaction, or some other limited resource as a local variable,
>could it be cleaned up automagically upon exiting the function or
>subroutine, or must it be always cleaned up explicitly, creating the
>possibility of resource leaks?

The current language definition only provides for two types of
automatic cleanup on block (including procedure) exit:

1. Freeing of AUTOMATIC variables

2. Reversion of ON handling.

As another poster has noted, files remain open.

I previously mentioned that there had been work at IBM on an OO PL/I.
If it ever ships, I would assume that it would require cleanup on
block exit, and a simple pop would not be sufficient.

As to storage leaks, that is a risk in any language that has list
processing capability but not garbage collection. It is certainly a
risk in any PL/I program that allocates BASED variables and does not
have proper housekeeping.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/15/2004 3:30:33 PM
```In <EpfNb.35622\$G04.7316249@news4.srv.hcvlny.cv.net>, on 01/14/2004
at 05:56 PM, "John W. Kennedy" <jwkenne@attglobal.net> said:

>Files closing at program exit, I suppose,

Program exit is very different from block exit. RETURN from a
procedure other than the outer (MAIN) procedure does not automatically
close files, with the exception of procedures called as subtasks.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do

```
 0
spamtrap16 (3722)
1/15/2004 3:48:02 PM
```jmfbahciv@aol.com writes:

> Example of our process...I don't know the time/effort that occurred
> before I got an SPR to work on, but it was not small.  I receive
> an SPR that says, "The word foobar in a comment in the routine
> BAZ in the file FORMES.MAC should be spelled FOOBAR." and it's marked
> as urgent.  It could take as much a week of wallclock time to get
> that answer out of the door into the snail mail addressed to the
> customer.  And YES, we did get urgent SPRs about typos in the
> comments (it's an example of SPR abuse).

Just another reason for not releasing your source code ;/

Did the customer have any cost associated with marking an SPR as
urgent?  Did you have to honor that, even if it was a typo in a
comment?

-- Patrick
```
 0
kkt3 (13)
1/15/2004 7:10:57 PM
```jmfbahciv@aol.com wrote:
>
>      [snip...]        [snip...]        [snip...]
>
> Our (PDP-10) maintenance costs (on the software side) mushroomed
> with code.  We were not allowed (in the 80s) to close an SPR
> with a thanks for the dump but we couldn't figure out why it
> happened.  Nor could we answer an SPR with "don't do that".
>
Man:  Doctor!!! Doctor!!! I broke my leg in three places!!!

Doctor:  I told you to stay *out* of those places!!!!

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+
```
 0
richchas2 (320)
1/16/2004 6:41:05 AM
```In article <tqm4quxt4ce.fsf@drizzle.com>,
Patrick Scheible <kkt@drizzle.com> wrote:
>jmfbahciv@aol.com writes:
>
>> Example of our process...I don't know the time/effort that occurred
>> before I got an SPR to work on, but it was not small.  I receive
>> an SPR that says, "The word foobar in a comment in the routine
>> BAZ in the file FORMES.MAC should be spelled FOOBAR." and it's marked
>> as urgent.  It could take as much a week of wallclock time to get
>> that answer out of the door into the snail mail addressed to the
>> customer.  And YES, we did get urgent SPRs about typos in the
>> comments (it's an example of SPR abuse).
>
>Just another reason for not releasing your source code ;/

That's definitely the trade-off.  OTOH, you don't end up with
sophisticated customers and end up babysitting their systems.
All in all, knowing how both sides worked, I would opt for
shipping sources.  The bottom line (profits) were larger when
we did.  The bad news is that there wasn't an accounting method
that measured that so the PHBs and fucking idiots didn't have
a baseball bat hitting them on the head.

>
>Did the customer have any cost associated with marking an SPR as
>urgent?

you.  I understood that SPRs were a part of the maintenance
agreement (which had to include hardware support--software was
not considered important).

> ..Did you have to honor that, even if it was a typo in a
>comment?

Towards the end, yes.  There was also a process of reclassifying
an SPR but it took just as long and more effort to do that than
to just answer the fucking thing.  Note that one of the
priorities was "For your information" which was supposed to cover
these kinds of reports.  It's not as if we didn't want to know
about them, we just didn't need to drop everything to answer them.

There was also the SPR from a customer who had marked it as a FYI.
It was a system crasher and kept them from running.  The maintenance
guy called them up and asked them how they managed because he
couldn't see how the system up.  The answer was it didn't.  This
was an instance where the customer should have marked it high
priority, called their emergency contact and screamed bloody
murder.  So they also "abused" the reporting method but in the
other extreme.  They got the patch during that phone call.

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/16/2004 11:42:56 AM
```jmfbahciv@aol.com writes:

> In article <tqm4quxt4ce.fsf@drizzle.com>,
>    Patrick Scheible <kkt@drizzle.com> wrote:
> >jmfbahciv@aol.com writes:
> >
> >> Example of our process...I don't know the time/effort that occurred
> >> before I got an SPR to work on, but it was not small.  I receive
> >> an SPR that says, "The word foobar in a comment in the routine
> >> BAZ in the file FORMES.MAC should be spelled FOOBAR." and it's marked
> >> as urgent.  It could take as much a week of wallclock time to get
> >> that answer out of the door into the snail mail addressed to the
> >> customer.  And YES, we did get urgent SPRs about typos in the
> >> comments (it's an example of SPR abuse).
> >
> >Just another reason for not releasing your source code ;/
>
> That's definitely the trade-off.  OTOH, you don't end up with
> sophisticated customers and end up babysitting their systems.
> All in all, knowing how both sides worked, I would opt for
> shipping sources.  The bottom line (profits) were larger when
> we did.  The bad news is that there wasn't an accounting method
> that measured that so the PHBs and fucking idiots didn't have
> a baseball bat hitting them on the head.
>
> >
> >Did the customer have any cost associated with marking an SPR as
> >urgent?
>
> you.  I understood that SPRs were a part of the maintenance
> agreement (which had to include hardware support--software was
> not considered important).
>
>
> > ..Did you have to honor that, even if it was a typo in a
> >comment?
>
> Towards the end, yes.  There was also a process of reclassifying
> an SPR but it took just as long and more effort to do that than
> to just answer the fucking thing.  Note that one of the
> priorities was "For your information" which was supposed to cover
> these kinds of reports.  It's not as if we didn't want to know
> about them, we just didn't need to drop everything to answer them.
>
> There was also the SPR from a customer who had marked it as a FYI.
> It was a system crasher and kept them from running.  The maintenance
> guy called them up and asked them how they managed because he
> couldn't see how the system up.  The answer was it didn't.  This
> was an instance where the customer should have marked it high
> priority, called their emergency contact and screamed bloody
> murder.  So they also "abused" the reporting method but in the
> other extreme.  They got the patch during that phone call.

Maybe the priorities should be marked:

[ ] This is stopping our system from working.
[ ] This is really annoying.
[ ] Cosmetic mistake.

Especially if we're talking about very large installed bases such as

-- Patrick
```
 0
kkt3 (13)
1/16/2004 5:28:09 PM
```On 16 Jan 2004 09:28:09 -0800 in alt.folklore.computers, Patrick
Scheible <kkt@drizzle.com> wrote:

>jmfbahciv@aol.com writes:
>
>> In article <tqm4quxt4ce.fsf@drizzle.com>,
>>    Patrick Scheible <kkt@drizzle.com> wrote:
>> >jmfbahciv@aol.com writes:

>Maybe the priorities should be marked:
>
> [ ] This is stopping our system from working.
> [ ] This is really annoying.
> [ ] Cosmetic mistake.
>
>Especially if we're talking about very large installed bases such as

Standard impacts used many places are:

system -- nothing works (/correctly);
subsystem -- some thing doesn't work, other things work;
minor -- some thing(s) don't work, but can be worked around;
documentation -- incorrect information.

Priorities are a measure of importance advised by the user, normally
used as a subsort below impact. Most places allow reclassification
after analysis, to compensate for hysterical (or laidback) users.

--
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
```
 0
Brian.Inglis (314)
1/16/2004 11:03:49 PM
```In article <pvqg00tsrauq80tp048o7dgevh01ptq2hc@4ax.com>, Brian Inglis wrote:
>
> Standard impacts used many places are:
>
> 	system -- nothing works (/correctly);
> 	subsystem -- some thing doesn't work, other things work;
> 	minor -- some thing(s) don't work, but can be worked around;
> 	documentation -- incorrect information.
>
> Priorities are a measure of importance advised by the user, normally
> used as a subsort below impact. Most places allow reclassification
> after analysis, to compensate for hysterical (or laidback) users.

This is very similar to the priority system used at my workplace (a
major vendor of networking equipment), along these lines:

"User's network is down hard"
"User's network may be somewhat degraded, but is managing"
"Information/request"

This is for the case system used by the support organisation. The bug
database has an impact/priority system that's even more similar to what
you outline in your last paragraph.

Niklas
--
"The bomb in question smashed through the road at Bank junction and bounced from
the ticket hall down the escalators. Several city workers have tried to simulate
the latter part of the bomb's path, usually on a Friday night."
-- Robin Mayes in uk.transport.london
```
 0
anksil (9)
1/16/2004 11:15:31 PM
```Joe "Nuke Me Xemu" Foster wrote:
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>
>> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
>> news:1074033441.198644@news-1.nethere.net...
>
>> > Pascal?  I'm talking about the sort of dain-bramage that would
>> > be demanded for a hypothetical OO PL/I.NET, if, of course, you
>> > want to be able to play in the Billy\$hit.NET litter^Wsand-box!
>
>> Just JOKING !!!
>>    Well, PL/I is so far "behind" COBOL.  Both Micro Focus and Fujitsu already
>> offer COBOL compilers for .NET.
>>
>> And of course, we all know <G> that the 2002 ANSI/ISO COBOL Standards include OO
>> syntax as "required" by any conforming COBOL compiler.  (Do you PL/I types
>> "remember" what an ANSI/ISO Standard is.)
>
> If there's any concept of "deterministic finalization" or "object
> destructors", it won't fly in the Longhorn/WinFX/.NET skies...

"Deterministic finalisation" is an oxymoron.  Destructors are another
thing entirely.  The development version of Visual C++.NET supports
both so I don't see why they couldn't be supported by other .NET
languages.
```
 0
1/17/2004 12:21:35 AM
```On 16 Jan 2004 23:15:31 GMT in alt.folklore.computers, Niklas Karlsson
<anksil@yahoo.se> wrote:

>In article <pvqg00tsrauq80tp048o7dgevh01ptq2hc@4ax.com>, Brian Inglis wrote:
>>
>> Standard impacts used many places are:
>>
>> 	system -- nothing works (/correctly);
>> 	subsystem -- some thing doesn't work, other things work;
>> 	minor -- some thing(s) don't work, but can be worked around;
>> 	documentation -- incorrect information.
>>
>> Priorities are a measure of importance advised by the user, normally
>> used as a subsort below impact. Most places allow reclassification
>> after analysis, to compensate for hysterical (or laidback) users.
>
>This is very similar to the priority system used at my workplace (a
>major vendor of networking equipment), along these lines:
>
>"User's network is down hard"
>"User's network may be somewhat degraded, but is managing"
>"Information/request"
>
>This is for the case system used by the support organisation. The bug
>database has an impact/priority system that's even more similar to what
>you outline in your last paragraph.

It tends to vary a bit by technology, for example, severity 1 (knew
there was a different word I was looking for) for a DB system might be
"DBMS dead/DB corruption": serious DB vendors treat corruption like a
911 call (an "Oh F***" situation), whereas severity 1 is just your
standard dead software problem, often configuration or installation
problems on a not yet fully functional DB.

--
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
```
 0
Brian.Inglis (314)
1/17/2004 1:48:44 AM
```In article <tqm8yk7u7km.fsf@drizzle.com>,
Patrick Scheible <kkt@drizzle.com> wrote:
>jmfbahciv@aol.com writes:
>
>> In article <tqm4quxt4ce.fsf@drizzle.com>,
>>    Patrick Scheible <kkt@drizzle.com> wrote:
<snip>

>> > ..Did you have to honor that, even if it was a typo in a
>> >comment?
>>
>> Towards the end, yes.  There was also a process of reclassifying
>> an SPR but it took just as long and more effort to do that than
>> to just answer the fucking thing.  Note that one of the
>> priorities was "For your information" which was supposed to cover
>> these kinds of reports.  It's not as if we didn't want to know
>> about them, we just didn't need to drop everything to answer them.
>>
>> There was also the SPR from a customer who had marked it as a FYI.
>> It was a system crasher and kept them from running.  The maintenance
>> guy called them up and asked them how they managed because he
>> couldn't see how the system up.  The answer was it didn't.  This
>> was an instance where the customer should have marked it high
>> priority, called their emergency contact and screamed bloody
>> murder.  So they also "abused" the reporting method but in the
>> other extreme.  They got the patch during that phone call.
>
>Maybe the priorities should be marked:
>
> [ ] This is stopping our system from working.
> [ ] This is really annoying.
> [ ] Cosmetic mistake.

There are situations where fixing the annoying can be more
important than 100% down time.  It depends on the customer's
POV which nobody can know but him.  In rare cases, (but were
always firefights) the whole mess was based on politics and
not technical problems.

>
>Especially if we're talking about very large installed bases such as

Limiting the classifying to a technical heirarchy  may not be
the best rating method unless it were a sub-category.

n years and still have no idea how to begin a solution.

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/17/2004 12:01:56 PM
```jmfbahciv@aol.com wrote:

>>Maybe the priorities should be marked:
>>
>>[ ] This is stopping our system from working.
>>[ ] This is really annoying.
>>[ ] Cosmetic mistake.
>
>
> There are situations where fixing the annoying can be more
> important than 100% down time.  It depends on the customer's
> POV which nobody can know but him.  In rare cases, (but were
> always firefights) the whole mess was based on politics and
> not technical problems.
>

And sometimes these categories don't fit the circumstances. There's

"This is a serious problem, but we have a workaround. Even so, you had
better fix it before someone else gets burned".

I had a case with a Burroughs B6700 running user-submited batch jobs,
where it would slow down and die. We soon discovered it always happened
when one particular job was running, and, with some hard dump-snuffling,
tracked it down to a nasty interaction between a compiler bug and an OS
failure to check for reasonableness, triggered by an Algol program doing
something legal, but very unusual. We could avoid the immediate problem
by getting the user to change his program, and it wasn't likely to
recur, but if it did, it was a machine-stopper.

--brian

--
Brian Boutel
Wellington New Zealand

Note the NOSPAM
```
 0
1/17/2004 10:25:18 PM
```On Sun, 18 Jan 2004 11:25:18 +1300 in alt.folklore.computers, Brian
Boutel <boutelbNOSPAM@acm.org> wrote:

>dump-snuffling

Never heard that one: appropriate; like it!

--
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
```
 0
Brian.Inglis (314)
1/18/2004 2:22:28 AM
```In article <mDiOb.17730\$ws.2168789@news02.tsnz.net>,
Brian Boutel <boutelbNOSPAM@acm.org> wrote:
>jmfbahciv@aol.com wrote:
>
>>>Maybe the priorities should be marked:
>>>
>>>[ ] This is stopping our system from working.
>>>[ ] This is really annoying.
>>>[ ] Cosmetic mistake.
>>
>>
>> There are situations where fixing the annoying can be more
>> important than 100% down time.  It depends on the customer's
>> POV which nobody can know but him.  In rare cases, (but were
>> always firefights) the whole mess was based on politics and
>> not technical problems.
>>
>
>And sometimes these categories don't fit the circumstances.

Yup.  If a boss has a room full of very cranky people caused
by a very annoying bug, he might consider that life-threatening,
technical problems (I'm thinking of mainframe sites).  If
there were a slue of annoyances, he'ld be spending most of his
time bandaiding the holes as they appeared rather than fixing
the problems.  With a half dozen or so, one guy could become
overwhelmed.  We had crew of dozens to take care of each
aspect of a system.  If an area got "overloaded" with problems,
others could help out or we could drop back to a saner set of
software.  Do customers these days get that option of dropping
back?  ISTM that one you've installed, you're pretty much stuck
with it unless you've hire that guy.  No PC ower can hire a guy.

> ...There's
>
>"This is a serious problem, but we have a workaround. Even so, you had
>better fix it before someone else gets burned".
>
>I had a case with a Burroughs B6700 running user-submited batch jobs,
>where it would slow down and die. We soon discovered it always happened
>when one particular job was running, and, with some hard dump-snuffling,
>tracked it down to a nasty interaction between a compiler bug and an OS
>failure to check for reasonableness, triggered by an Algol program doing
>something legal, but very unusual. We could avoid the immediate problem
>by getting the user to change his program, and it wasn't likely to
>recur, but if it did, it was a machine-stopper.

BLISS-10 had a similar problem.  Because of internal politics,
it was impossible to ship a new BLISS-10 with the real fix
in it.  So TW put in a TOPS-10 monitor fix.

Do you remember if the compiler got an edit?

/BAH

Subtract a hundred and four for e-mail.
```
 0
jmfbahciv (721)
1/18/2004 1:01:00 PM
```<jmfbahciv@aol.com> wrote in message <news:400a9565\$0\$6077\$61fed72c@news.rcn.com>...

> software.  Do customers these days get that option of dropping
> back?  ISTM that one you've installed, you're pretty much stuck
> with it unless you've hire that guy.  No PC ower can hire a guy.

"Dropping back" (without paying for a "downgrade") is probably a
EULA or DMCA violation, making even this discussion illegal...

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/18/2004 3:25:39 PM
```"Ben Hutchings" <ben-public-nospam@decadentplace.org.uk> wrote in message

> Joe "Nuke Me Xemu" Foster wrote:

> > If there's any concept of "deterministic finalization" or "object
> > destructors", it won't fly in the Longhorn/WinFX/.NET skies...
>
> "Deterministic finalisation" is an oxymoron.  Destructors are another
> thing entirely.  The development version of Visual C++.NET supports
> both so I don't see why they couldn't be supported by other .NET
> languages.

"Deterministic finalization" is the term used by the various Micro\$hills
predictable object cleanup must inevitably lead to IBM PC XT performance,
rampant memory leaks, ubiquitous Heisenbugs, working sets of infinity**N
GB, BSODs every three minutes, seas of blood, fire raining down from the
sky, impotence, and global warming.  True, VC++.NET supports destructors,
but not in "managed" code, only in "unmanaged"/"unmanageable" native code:

URL:http://codeproject.com/managedcpp/managedraii.asp

Bring me the head of Anders Hejlsberg:

URL:http://hackcraft.net/raii/

--
Joe Foster <mailto:jlfoster%40znet.com>  KrazyKookKultz! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/18/2004 8:37:46 PM
```Joe "Nuke Me Xemu" Foster wrote:
> "Ben Hutchings" <ben-public-nospam@decadentplace.org.uk> wrote in message
>
>> Joe "Nuke Me Xemu" Foster wrote:
>
>> > If there's any concept of "deterministic finalization" or "object
>> > destructors", it won't fly in the Longhorn/WinFX/.NET skies...
>>
>> "Deterministic finalisation" is an oxymoron.  Destructors are another
>> thing entirely.  The development version of Visual C++.NET supports
>> both so I don't see why they couldn't be supported by other .NET
>> languages.
>
> "Deterministic finalization" is the term used by the various Micro\$hills
> and Cheerleaders.NET when they FUD about how real object destructors and
> predictable object cleanup must inevitably lead to IBM PC XT performance,
> rampant memory leaks, ubiquitous Heisenbugs, working sets of infinity**N
> GB, BSODs every three minutes, seas of blood, fire raining down from the
> sky, impotence, and global warming.  True, VC++.NET supports destructors,
> but not in "managed" code, only in "unmanaged"/"unmanageable" native code:
>
>  URL:http://codeproject.com/managedcpp/managedraii.asp
<snip>

The development version of Visual C++.NET (which is what I referred
to) replaces "Managed C++" with "C++/CLI".  IIRC, this will
automatically call destructors (or rather the equivalent methods) for
CLI objects declared as automatic - in managed code.  So RAII will
work as in normal C++.

Also, I'm fairly sure that "unmanaged code" does not mean "native
code".

See Herb Sutter's blog <http://blogs.gotdotnet.com/hsutter/>.
```
 0
1/21/2004 12:50:13 AM
```"Ben Hutchings" <ben-public-nospam@decadentplace.org.uk> wrote in message

> Joe "Nuke Me Xemu" Foster wrote:

> > "Deterministic finalization" is the term used by the various Micro\$hills
> > and Cheerleaders.NET when they FUD about how real object destructors and
> > predictable object cleanup must inevitably lead to IBM PC XT performance,
> > rampant memory leaks, ubiquitous Heisenbugs, working sets of infinity**N
> > GB, BSODs every three minutes, seas of blood, fire raining down from the
> > sky, impotence, and global warming.  True, VC++.NET supports destructors,
> > but not in "managed" code, only in "unmanaged"/"unmanageable" native code:
> >
> >  URL:http://codeproject.com/managedcpp/managedraii.asp
> <snip>
>
> The development version of Visual C++.NET (which is what I referred
> to) replaces "Managed C++" with "C++/CLI".  IIRC, this will
> automatically call destructors (or rather the equivalent methods) for
> CLI objects declared as automatic - in managed code.  So RAII will
> work as in normal C++.
>
> Also, I'm fairly sure that "unmanaged code" does not mean "native
> code".
>
> See Herb Sutter's blog <http://blogs.gotdotnet.com/hsutter/>.

The new URL is <URL:http://blogs.msdn.com/hsutter/>, and it's quite
clear that Micro\$haft won't be happy until they've proprietarized
C++ completely, perhaps in revenge for the C++ Standard Committee's
temerity in having the unmitigated gall to force Microslop to sprinkle
"std::" throughout their holy, pristine source code files.  So now,
"*" and "new" are going away, to be replaced by "^" and "gcnew", only
to be rolled back to "*" and "new" in a few years' time?  WTF?!  I
take it Herb Sutter has finally been Billged totally, or he's never,
ever heard of garbage-collection for C++ that doesn't break existing
code?  His blog is steeped in exactly the same sort of FUD which was
used to justify the castration of Visual Basic's RAII capabilities
altogether.

HerbSutter.setCredibility(0);

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

```
 0
joe303 (603)
1/21/2004 11:15:38 PM
```Joe "Nuke Me Xemu" Foster wrote:
> "Ben Hutchings" <ben-public-nospam@decadentplace.org.uk> wrote in message
>
>> Joe "Nuke Me Xemu" Foster wrote:
>
>> > "Deterministic finalization" is the term used by the various Micro\$hills
>> > and Cheerleaders.NET when they FUD about how real object destructors and
>> > predictable object cleanup must inevitably lead to IBM PC XT performance,
>> > rampant memory leaks, ubiquitous Heisenbugs, working sets of infinity**N
>> > GB, BSODs every three minutes, seas of blood, fire raining down from the
>> > sky, impotence, and global warming.  True, VC++.NET supports destructors,
>> > but not in "managed" code, only in "unmanaged"/"unmanageable" native code:
>> >
>> >  URL:http://codeproject.com/managedcpp/managedraii.asp
>> <snip>
>>
>> The development version of Visual C++.NET (which is what I referred
>> to) replaces "Managed C++" with "C++/CLI".  IIRC, this will
>> automatically call destructors (or rather the equivalent methods) for
>> CLI objects declared as automatic - in managed code.  So RAII will
>> work as in normal C++.
>>
>> Also, I'm fairly sure that "unmanaged code" does not mean "native
>> code".
>>
>> See Herb Sutter's blog <http://blogs.gotdotnet.com/hsutter/>.
>
> The new URL is <URL:http://blogs.msdn.com/hsutter/>, and it's quite
> clear that Micro\$haft won't be happy until they've proprietarized
> C++ completely,

Not so.  C++/CLI is being standardised - through ECMA rather than ISO,
but nevertheless Stroustrup and other notables are involved.

> perhaps in revenge for the C++ Standard Committee's temerity in
> having the unmitigated gall to force Microslop to sprinkle "std::"
> throughout their holy, pristine source code files.

Nothing forces them to stop using pre-standard libraries!

> So now, "*" and "new" are going away, to be replaced by "^" and
> "gcnew", only to be rolled back to "*" and "new" in a few years'
> time?

No.  Garbage-collected pointers do not support arithmetic and they may
transparently be adjusted by the garbage collector as it compacts its
heap.  They are like Java references; significantly different from
normal C/C++ pointers.  This is why it is necessary to treat them as
different types with different syntax.

> WTF?!  I take it Herb Sutter has finally been Billged totally, or
> he's never, ever heard of garbage-collection for C++ that doesn't
> break existing code?

He has; he even refers to the Boehm collector.  I have extensive
experience with the Boehm collector (search for my name in
README.changes) and I know that while it is useful it is also limited
by the fact that it is only a library and not a language extension.
It is a conservative garbage collector - it cannot really tell
pointers from integers, so it errs on the side of caution.  It is
limited to relatively inefficient mark-and-sweep collection�and it
cannot compact its heap.

> His blog is steeped in exactly the same sort of FUD which was
> used to justify the castration of Visual Basic's RAII capabilities
> altogether.
>
> HerbSutter.setCredibility(0);

I think you're mistaken.

I suggest you also read the discussions in comp.lang.c++.moderated: