f



Is it possible to use the value of the PROGRAM ID within the source code?

I'm using MicroFocus COBOL 4.0 on UnixWare 2.1.3.

I'd quite like to be able to use the Program Id in every program using
the same phrase (e.g. MOVE prog id TO XYZ).

There are other ways of getting the same result but I just wondered if
this was possible.

David L.
0
david1989 (5)
6/8/2004 10:31:31 AM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

271 Replies
2608 Views

Similar Articles

[PageSpeed] 28

david@quantumcat.demon.co.uk (David Latimer) wrote:

>I'm using MicroFocus COBOL 4.0 on UnixWare 2.1.3.
>
>I'd quite like to be able to use the Program Id in every program using
>the same phrase (e.g. MOVE prog id TO XYZ).
>
>There are other ways of getting the same result but I just wondered if
>this was possible.

You cannot get it from Cobol but you can get it from Unix. Some Unixen store it
in an environment variable named _ (underscore). I know Solaris does. To read it
say:

01  program-name     pic x(30) value spaces.
01  a-underscore      pointer.
linkage section.
01  underscore        pic  x(30).

call 'cobgetenv' using z'_' returning a-underscore
set address of underscore to a-underscore
unstring underscore delimited by low-value into program-name

This only works if you compile to an executable, not .gnt.

The following will work on any species of Unix:

call 'system' using z"pgrep -s0 | xargs -Ipid ps -fppid | awk '{print $8}' | sed
-e'/CMD/d' -e'/xargs/d' -e'/ksh/d' -e'/awk/d' -e'/sed/d' >xxx" 

Your program name will be in file xxx. Alternatively, you could send it to an
environment variable which can be read as above by changing >xxx to 
| xargs -Iprog export _=prog

If you compile to .gnt, change awk to print $9. I used the -f option on ps so it
would show the whole command line.







0
6/9/2004 9:23:02 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> >I'd quite like to be able to use the Program Id in every program using
> >the same phrase (e.g. MOVE prog id TO XYZ).
 
> If you compile to .gnt, change awk to print $9. I used the -f option on ps so it
> would show the whole command line.

That is not going to show the name of any CALLed programs, which is
probably the point of the request.
0
riplin (4127)
6/10/2004 5:43:38 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> >I'd quite like to be able to use the Program Id in every program using
>> >the same phrase (e.g. MOVE prog id TO XYZ).
> 
>> If you compile to .gnt, change awk to print $9. I used the -f option on ps so
it
>> would show the whole command line.
>
>That is not going to show the name of any CALLed programs, which is
>probably the point of the request.

No, he wants the name of the Main program, probably to print in a log file or
report header. The logic getting the name would best be in a called program.
Printing 'getmyname' on every report would not be informative.

If programs are compiled to .gnt, the gnt _is_ a called program .. called by
cobrun, which would appear in column 8.

0
6/10/2004 6:44:13 AM
You could use x/open syntax...

        01 ws-stuff           pic x(80).

        display 0 upon argument-number
        accept ws-stuff from argument-value
        display "Main exe is : " ws-stuff

It works with both "cobrun xx" and your program built as an exe....

--
Stephen

"David Latimer" <david@quantumcat.demon.co.uk> wrote in message
news:a9026f4e.0406080231.4a745813@posting.google.com...
> I'm using MicroFocus COBOL 4.0 on UnixWare 2.1.3.
>
> I'd quite like to be able to use the Program Id in every program using
> the same phrase (e.g. MOVE prog id TO XYZ).
>
> There are other ways of getting the same result but I just wondered if
> this was possible.
>
> David L.


0
6/10/2004 8:22:20 AM
In article <40c800ce.497169106@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>riplin@Azonic.co.nz (Richard) wrote:
>
>>robert.deletethis@wagner.net (Robert Wagner) wrote
>>
>>> >I'd quite like to be able to use the Program Id in every program using
>>> >the same phrase (e.g. MOVE prog id TO XYZ).
>> 
>>> If you compile to .gnt, change awk to print $9. I used the -f option on ps so
>it
>>> would show the whole command line.
>>
>>That is not going to show the name of any CALLed programs, which is
>>probably the point of the request.
>
>No, he wants the name of the Main program, probably to print in a log file or
>report header.

Mr Wagner, how do you manage to translate 'I'd quite like... *every* 
program using the same phrase' to 'he wants the name of the Main program'?

DD
0
docdwarf (6044)
6/10/2004 9:22:14 AM
If you had Server Express you could use CBL_GET_PROGRAM_INFO...

       01 ws-pi-function       pic x(4) comp-5.
       01 ws-pi-param.
            03 ws-pi-size        pic x(4) comp-5.
            03 ws-pi-flags        pic x(4) comp-5.
            03 ws-pi-handle       usage pointer.
            03 ws-pi-prog-id      usage pointer.
            03 ws-pi-gpi-attrs    pic x(4) comp-5.
       01 ws-pi-name-buf       pic x(60).
       01 ws-pi-name-len       pic x(4) comp-5.


       procedure division.

       move 0 to ws-pi-function
       move 20 to ws-pi-size
       move 2 to ws-pi-flags
       move length of ws-pi-name-buf to ws-pi-name-len
       call "CBL_GET_PROGRAM_INFO" using
          by value ws-pi-function
          by reference ws-pi-param
          by reference ws-pi-name-buf
          by reference ws-pi-name-len
       end-call

       display "Return-code : " return-code
       display ws-pi-name-buf

"David Latimer" <david@quantumcat.demon.co.uk> wrote in message
news:a9026f4e.0406080231.4a745813@posting.google.com...
> I'm using MicroFocus COBOL 4.0 on UnixWare 2.1.3.
>
> I'd quite like to be able to use the Program Id in every program using
> the same phrase (e.g. MOVE prog id TO XYZ).
>
> There are other ways of getting the same result but I just wondered if
> this was possible.
>
> David L.


0
6/10/2004 9:47:25 AM
Stephen Gennard wrote:
> You could use x/open syntax...
> 
>         01 ws-stuff           pic x(80).
> 
>         display 0 upon argument-number
>         accept ws-stuff from argument-value
>         display "Main exe is : " ws-stuff
> 
> It works with both "cobrun xx" and your program built as an exe....
> 
> --

Normally, only one program of a run unit can be the EXE.  You prbably 
*KNOW* what is running at that point. It is after control transfers to 
another program that you need the information.

Donald

0
donald_tees (563)
6/10/2004 11:35:12 AM
robert.deletethis@wagner.net (Robert Wagner) wrote

> >That is not going to show the name of any CALLed programs, which is
> >probably the point of the request.
> 
> No, he wants the name of the Main program, 

Where did you get that from ?  What part of "every" did you not
understand ?

> probably to print in a log file or report header. 

I do that, using the name of the program that prints the report, not
just the name of the 'main' program which is the same one in most of
my systems.

> The logic getting the name would best be in a called program.
> Printing 'getmyname' on every report would not be informative.

Then obviously, to me at least, this would _not_ be the 'best' if the
result would be completely useless.  So why did you put 'best' ?

But he probably doesn't want 'mainprog' on every report either.
 
> If programs are compiled to .gnt, the gnt _is_ a called program .. called by
> cobrun, which would appear in column 8.

So, you have satisfied his 'every' with just 1 out of, potentially,
dozens of programs with different names.

The way that I get the program name available in each program in many
systems is to pass a parameter block around on each CALL that includes
the name used by the CALL. This, of course, is not a simple solution
for a system that doesn't do that.

The easiest way is probably to process all the source code to pick up
the word after Program-id (or use the file name) and add a W-S item
for all source files.
0
riplin (4127)
6/10/2004 7:25:00 PM
docdwarf@panix.com wrote:


>Mr Wagner, how do you manage to translate 'I'd quite like... *every* 
>program using the same phrase' to 'he wants the name of the Main program'?

Just a guess. Besides, there's no easy way to get the name of a called program.
0
6/10/2004 10:45:00 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> >That is not going to show the name of any CALLed programs, which is
>> >probably the point of the request.
>> 
>> No, he wants the name of the Main program, 
>
>Where did you get that from ?  What part of "every" did you not
>understand ?
>
>> probably to print in a log file or report header. 
>
>I do that, using the name of the program that prints the report, not
>just the name of the 'main' program which is the same one in most of
>my systems.

In the case of reports, I hardcode the program name in the header. If a program
prints two reports, I suffix the name with 1 and 2. 

In the case of error messages from batch programs, we use a utility starter
program analogous to cobrun. It is an executable, the applications are
dynamically callable. The starter parses the command line, connects to the
database, does housekeeping such as setting nls_date_format, WRITES THE PROGRAM
NAME AND START TIME TO LOG FILES SYSOUT AND SYSERR, then calls the program. 
Any messages from the program do not need a program id because it's already in
the log file.

The starter program could pass the program name as parameter 1, but we don't do
that. Structurally, the starter program *should* be the one to abort() if the
return code is non-zero. We can't do that because of a deficiency in 'anim',
which refuses to show called programs even though they are in the 'core' image.

>> The logic getting the name would best be in a called program.
>> Printing 'getmyname' on every report would not be informative.
>
>Then obviously, to me at least, this would _not_ be the 'best' if the
>result would be completely useless.  So why did you put 'best' ?

I meant that if the called program getmyname got its own name, its output would
be uninformative. It should return the name of Main or Caller or, preferably, it
should walk back the whole call stack.

>The way that I get the program name available in each program in many
>systems is to pass a parameter block around on each CALL that includes
>the name used by the CALL. This, of course, is not a simple solution
>for a system that doesn't do that.

Our programs, developed on AS/400, keep an internal 'perform stack'. On entry to
every paragraph, they bump an index and insert the paragraph's name; on exit,
they set the index down by 1. A standard abend process in a copybook dumps the
'perform stack' to syserr. I was told by an AS/400 pro that the reason for this
is "The AS/400 debugger is so bad that programmers will do anything to avoid
using it." Out of curiosity, I looked at the debugger. It looks very much like
Micro Focus' anim. One can set breakpoints on lines of code, but not a data
elements, telling to stop when the element is touched or changed. Our most
common question is 'Show me when this field is changed to spaces'. Good
debuggers (possible oxymoron) such as MS DevStudio have it; bad ones don't.

[flame-bait alert] I don't use debuggers except as a last resort. They waste
more time than they save. If you can't read code and see what it does, you
shouldn't call yourself a programmer. Maybe you'd be happier as a tester. [end
of alert]

>The easiest way is probably to process all the source code to pick up
>the word after Program-id (or use the file name) and add a W-S item
>for all source files.

That's what he's gonna do, evinced by subsequent postings.
0
6/10/2004 10:45:01 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40c8d8c2.552461456@news.optonline.net...

> Just a guess. Besides, there's no easy way to get the name of a called
program.

I wouldn't think this would be difficult for implementors to provide, and
would suggest you propose that a future standard provide an Intrinsic
Function to provide the program-name, function-name, class-name or
method-name of wherever you are at the moment.  Whether it'd be
unconditionally meaningful or not is another question!

I'd also suggest that, if you called a program, the *caller* (so far as I
know always) knows its name, and if you need the called routine to know the
name by which it was called, I'd say passing the name using a by-value
parameter shouldn't take *that* many hours of head-scratching to figure out.
I mean, how difficult is CALL 'a-program' USING BY VALUE 'a-program' ... "?

    -Chuck Stevens


0
6/10/2004 11:25:33 PM
In article <40c8d8c2.552461456@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>
>>Mr Wagner, how do you manage to translate 'I'd quite like... *every* 
>>program using the same phrase' to 'he wants the name of the Main program'?
>
>Just a guess.

I... see.

DD
0
docdwarf (6044)
6/10/2004 11:29:18 PM
Just a thought.  

On z/OS you could find this information by looking at the PPA1 and PPA2 
parts of the loaded program (offset 168 in one of those).

Whatever platform you are on must have a well defined object file format 
(PEF, XCOFF, ELF, whatever).  The docs for that format ought to tell you 
how to find the executable name.

This method just begs for someone to reply with a "Cobol programmers 
should never have to know load module format or use pointers or anything 
that smells of programming..." post.  But it really is easy to do...
0
6/11/2004 1:44:11 AM
Joe,
  I won't reply the way you suggested, but rather by saying that *IF* one is in
an IBM mainframe environment, what this thread actually reminds me of is the
existing SHARE requriement,

"SSLNGC0313587      New LE Callable Service to get (various) Program Names
    ...
A new LE callable service (with capabilities well beyond CEE3GRN) should be
created to obtain various program names. This should include options to obtain:

- The currently executing program's name
- The name of the program that "activated" (Called, Invoked, whatever) the
currently executing program
- The name of the program at the "top" of the current LE "enclave"
- The name of the program at the "top" of the current LE "thread"

For each of these, sub-options may be required to provide information such as
- Any "alias" by which the program was entered
- Any "long-name" (with mixed characters) as supported by the Binder
- Any Entry-point name when other than the modules name

Finally, although not necessarily a part of this callable service, it would also
be desirable to be able to obtain the "data set name" (HFS, PDS, PDSE, LPA
member, or whatever) from which each of these entities was obtained."



-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-BF8C66.21441110062004@corp.supernews.com...
> Just a thought.
>
> On z/OS you could find this information by looking at the PPA1 and PPA2
> parts of the loaded program (offset 168 in one of those).
>
> Whatever platform you are on must have a well defined object file format
> (PEF, XCOFF, ELF, whatever).  The docs for that format ought to tell you
> how to find the executable name.
>
> This method just begs for someone to reply with a "Cobol programmers
> should never have to know load module format or use pointers or anything
> that smells of programming..." post.  But it really is easy to do...


0
wmklein (2605)
6/11/2004 1:52:47 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40c8d8c2.552461456@news.optonline.net...
>
>> Just a guess. Besides, there's no easy way to get the name of a called
>program.
>
>I wouldn't think this would be difficult for implementors to provide, and
>would suggest you propose that a future standard provide an Intrinsic
>Function to provide the program-name, function-name, class-name or
>method-name of wherever you are at the moment.  Whether it'd be
>unconditionally meaningful or not is another question!

A general-purpose solution would be to walk back the call stack returning the
names of all programs from the program of interest back to Main.

>I'd also suggest that, if you called a program, the *caller* (so far as I
>know always) knows its name,

Not necessarily. A certain breed likes to 'clone' programs by copying them to a
slightly different name, then changing a few lines of code. I've seen 15
'versions' of the same program.

> and if you need the called routine to know the
>name by which it was called, I'd say passing the name using a by-value
>parameter shouldn't take *that* many hours of head-scratching to figure out.
>I mean, how difficult is CALL 'a-program' USING BY VALUE 'a-program' ... "?

Generally, you can't pass strings on the stack. You can only pass words, such as
a pointer to the string. Make that 'CALL a-program USING (default BY REFERENCE)
a-program'.

0
6/11/2004 8:26:35 AM
In article <Pf8yc.9773$uX2.6404@newsread2.news.pas.earthlink.net>,
 "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Joe,
>   I won't reply the way you suggested, but rather by saying that *IF* one is 
>   in
> an IBM mainframe environment, what this thread actually reminds me of is the
> existing SHARE requriement,
> 
> "SSLNGC0313587      New LE Callable Service to get (various) Program Names
>     ...
> A new LE callable service (with capabilities well beyond CEE3GRN) should be
> created to obtain various program names. This should include options to 
> obtain:
> 
> - The currently executing program's name

This can be done via the prefix area.


> - The name of the program that "activated" (Called, Invoked, whatever) the
> currently executing program

The entire call chain can be observed using a tiny assembler program 
that will dereference save areas and do a CSVQUERY on the owner of the 
save area location.

> - The name of the program at the "top" of the current LE "enclave"

This can be done in Cobol by looking at the SWA.

> - The name of the program at the "top" of the current LE "thread"

I'm not sure how to do this one.

> For each of these, sub-options may be required to provide information such as
> - Any "alias" by which the program was entered
> - Any "long-name" (with mixed characters) as supported by the Binder
> - Any Entry-point name when other than the modules name
> 
> Finally, although not necessarily a part of this callable service, it would 
> also
> be desirable to be able to obtain the "data set name" (HFS, PDS, PDSE, LPA
> member, or whatever) from which each of these entities was obtained."

I'll post some code soon...
0
6/11/2004 12:21:54 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40c9685a.589226654@news.optonline.net...

> A general-purpose solution would be to walk back the call stack returning
the
> names of all programs from the program of interest back to Main.

That is presuming that the implementation has an accessible structure such
as a "call stack".

> Not necessarily. A certain breed likes to 'clone' programs by copying them
to a
> slightly different name, then changing a few lines of code. I've seen 15
> 'versions' of the same program.

Yes, you could have any number of programs with the same PROGRAM-ID, even in
the same multiple-program structure. If these programs are all
separately-compiled, the PROGRAM-ID becomes less interesting as seen from
outside the program, and what is important is how the calling program refers
to the separately-compiled called program.

> Generally, you can't pass strings on the stack. You can only pass words,
such as
> a pointer to the string. Make that 'CALL a-program USING (default BY
REFERENCE)
> a-program'.

Last sentence first:  "CALL a-program USING BY CONTENT a-program" would I
think be preferable.  The objective here is to ensure that a-program cannot
step on this particular parameter.

In our implementation, there is no pre-execution-time linking phase; the
determination as to whether the target procedure is nested or
separately-compiled has to be made at execution time and is a rather
expensive process.  Thus, while "CALL <dataname>"  works it is almost
invariably much more costly than "CALL <literal>".

And I was indeed mistaken; I was looking at the wrong format in ISO/IEC
1989:2002.  By-value and by-content literal parameters are only allowed in
program-prototype calls.

But where does the standard require that the implementor keep track of
information about calling history in some sort of hardware stack?   Where
does the standard prohibit putting strings (do you mean strictly
"alphanumeric literals" or do you include "alphanumeric data items"?) on
that stack?

BY CONTENT non-numeric parameters of arbitrary length are allowed.

How the implementation *accomplishes* passing, say, a 30,000-byte record as
a parameter BY CONTENT is none of the end user's business; the only concern
is how the caller sees it if the called program happens to step on its
contents (and the correct expectation is that it be unchanged).

So far as I know there's nothing wrong with
    MOVE "a-program" TO program-to-call.
    CALL "a-program" USING BY CONTENT program-to-call ...
or even
    MOVE "a-program" TO program-to-call.
    CALL program-to-call USING BY CONTENT program-to-call ...
if one is so inclined.

What's this about words?  It may be *common* to use some sort of fixed
structure to describe a parameter passed by content -- but there is
absolutely no requirement that that structure be inherently different from
the structure that would be used for parameters passed by reference, or that
the structure be related in any way to any other structure that might be
used in the operating environment.

Moreover, there is nothing except resources and incentive preventing an
obsolete-computer buff from implementing a fully-2002-compliant COBOL
implementation on a Burroughs B3500, or even an IBM 1401, for which
architectures the concept of "fixed-length words" as I understand the
concept does not exist.

    -Chuck Stevens


0
6/11/2004 4:44:52 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> A general-purpose solution would be to walk back the call stack returning the
> names of all programs from the program of interest back to Main.

That doesn't solve anything. It is unlikely that the name of the
calling program, nor even that of the called program is actually on
the stack (presuming that it soes actually do this using a stack in
the first place).  When a program does a 'CALL progname USING
parameters', you will notice that progname is _not_ one of the
parameters.

But also the CALL does not necessarily go to the called program
directly.  It most likely goes to the run-time resolver, so going one
up the stack does not necessarily go to the caller.

So even if one could work out the stack frames to access the calling
program there is still _nothing_ as a 'general-purpose' in that
program that would give that name.  If there was then it would also be
in the called program, so walking the stack is unrequired.

> >I'd also suggest that, if you called a program, the *caller* (so far as I
> >know always) knows its name,

> Not necessarily. A certain breed likes to 'clone' programs by copying them to a
> slightly different name, then changing a few lines of code. I've seen 15
> 'versions' of the same program.

I am not sure why you think that this means that the caller does not
know its own name ?  Are you saying that the programmer copies the
code to a new file and does not change the program-id, or other
references ?

This can become a problem with, say, Microfocus, where a dynamic
loading for a CALL is by file name and a CANCEL is by Program-Id.  If
they don't match there can be unrequired results.
0
riplin (4127)
6/12/2004 12:04:27 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40c9685a.589226654@news.optonline.net...
>
>> A general-purpose solution would be to walk back the call stack returning
>the
>> names of all programs from the program of interest back to Main.
>
>That is presuming that the implementation has an accessible structure such
>as a "call stack".

Every called program has a way of returning to its caller.

>> Generally, you can't pass strings on the stack. You can only pass words,
>such as
>> a pointer to the string. Make that 'CALL a-program USING (default BY
>REFERENCE)
>> a-program'.
>
>Last sentence first:  "CALL a-program USING BY CONTENT a-program" would I
>think be preferable.  The objective here is to ensure that a-program cannot
>step on this particular parameter.

But it can. It just cannot modify it back in the caller's memory.

I don't think this is a realistic concern. Programs generally don't recklessly
modify parameters.

>In our implementation, there is no pre-execution-time linking phase; the
>determination as to whether the target procedure is nested or
>separately-compiled has to be made at execution time and is a rather
>expensive process.  Thus, while "CALL <dataname>"  works it is almost
>invariably much more costly than "CALL <literal>".

It is in nearly all environments. It need not be. Sure, dataname can change, but
99.99 percent of the time it doesn't. INLINE code could (should) check that it's
the same and then call directly, with little more overhead than a static link. I
used to write enhancers that reached back and modified generated code to do
exactly that.

> where does the standard require that the implementor keep track of
>information about calling history in some sort of hardware stack?   Where
>does the standard prohibit putting strings (do you mean strictly
>"alphanumeric literals" or do you include "alphanumeric data items"?) on
>that stack?
>
>BY CONTENT non-numeric parameters of arbitrary length are allowed.
>
>How the implementation *accomplishes* passing, say, a 30,000-byte record as
>a parameter BY CONTENT is none of the end user's business; the only concern
>is how the caller sees it if the called program happens to step on its
>contents (and the correct expectation is that it be unchanged).

True but discordant with the culture of operating systems and other languages.
Micro Focus says:

"If the program being called is not COBOL, the size of the additional data item
should not exceed the maximum size of the system area (typically the size of a
POINTER on the system); otherwise the system might become catastrophically
corrupt."

You wouldn't want to be the one found to have "catastrophically corrupted" the
system. I know .. FUD.

>What's this about words?  It may be *common* to use some sort of fixed
>structure to describe a parameter passed by content -- but there is
>absolutely no requirement that that structure be inherently different from
>the structure that would be used for parameters passed by reference, or that
>the structure be related in any way to any other structure that might be
>used in the operating environment.

The idea of BY CONTENT and BY VALUE is based on paranoia and disrespect. Its
premise is that called programs may irrationally corrupt parameter values. In
the real world, that's not a realistic concern.

>Moreover, there is nothing except resources and incentive preventing an
>obsolete-computer buff from implementing a fully-2002-compliant COBOL
>implementation on a Burroughs B3500, or even an IBM 1401, for which
>architectures the concept of "fixed-length words" as I understand the
>concept does not exist.

On the 1401 I wrote a rudimentary  operating system because the machine didn't
come with one. On the B3500/4700 I completely rewrite the communications
software and print spooler in Cobol and contributed to the design of MCPV.

You're correct: they didn't have words nor stacks, but they did have a pointer
back to the caller.
0
6/12/2004 12:14:13 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 
>
>> A general-purpose solution would be to walk back the call stack returning the
>> names of all programs from the program of interest back to Main.
>
>That doesn't solve anything. It is unlikely that the name of the
>calling program, nor even that of the called program is actually on
>the stack (presuming that it soes actually do this using a stack in
>the first place).  When a program does a 'CALL progname USING
>parameters', you will notice that progname is _not_ one of the
>parameters.

The stack contains a return address. Using that, the program name can usually be
found near the beginning of its segment or in a public symbol table. 

>But also the CALL does not necessarily go to the called program
>directly.  It most likely goes to the run-time resolver, so going one
>up the stack does not necessarily go to the caller.

Let's try to stay in focus. We're interested in the RETURN address, not the call
address.

>So even if one could work out the stack frames to access the calling
>program there is still _nothing_ as a 'general-purpose' in that
>program that would give that name.  If there was then it would also be
>in the called program, so walking the stack is unrequired.

Heap walkers are a very common diagnostic tool. I'm disappointed to read you're
unfamiliar with the concept.

>> >I'd also suggest that, if you called a program, the *caller* (so far as I
>> >know always) knows its name,
>
>> A certain breed likes to 'clone' programs by copying them to  a
>> slightly different name, then changing a few lines of code. I've seen 15
>> 'versions' of the same program.
>
>I am not sure why you think that this means that the caller does not
>know its own name ?  Are you saying that the programmer copies the
>code to a new file and does not change the program-id, or other
>references ?

Yes, it is common practice. Then I'm asked to 'find every place where a program
does A and change it to B.' I find 15 copies of the same program doing A. Nobody
knows which is the production version. The files' 'last touched' timestamps are
all the same, the last time someone ran a GREP. 

Thinking ahead, I'd developed a tool to track program executions. It shows one
of the 15 running every day, the others seldom or never. I change that one.
Months later the file gets broken. Hours of research leads to 'we run that
program when someone asks for special handling.' Why didn't you put special
handling logic in the production program? The answer: 'I believe in the KISS
principle.'

This kind of abuse is WHY big shops are burdened with Change Management software
and programmers locked out of the production box.

>This can become a problem with, say, Microfocus, where a dynamic
>loading for a CALL is by file name and a CANCEL is by Program-Id.  If
>they don't match there can be unrequired results.

Cancel? Let the operating system worry about cleanup.

0
6/12/2004 3:25:40 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> The stack contains a return address. Using that, the program name can usually 

The 'return address' need not be to the actual CALLing program.  It
may be to the run-time so that the run-time can decrement the 'active'
counter or somesuch.  The run-time does know which programs are
active, which is why it can give an error when a re-entry is tried.

> found near the beginning of its segment or in a public symbol table. 

I just looked as some object code.  Yes the program name is there, so
are a lot of other names, and in no particular order.  This is also
_not_ a general solution as you claimed and may be entirely specific
to particualr compilers and environments, each one requiring a
different solution.
 
> >But also the CALL does not necessarily go to the called program
> >directly.  It most likely goes to the run-time resolver, so going one
> >up the stack does not necessarily go to the caller.
> 
> Let's try to stay in focus. We're interested in the RETURN address, not the
> call address.

And the return address may be back to the run-time which is where the
actual entry to the called program came from.

> >So even if one could work out the stack frames to access the calling
> >program there is still _nothing_ as a 'general-purpose' in that
> >program that would give that name.  If there was then it would also be
> >in the called program, so walking the stack is unrequired.
> 
> Heap walkers are a very common diagnostic tool. I'm disappointed to read 
> you're unfamiliar with the concept.

You are now confused between the stack and the heap.  They are
different things you know.

As I said there is still _nothing_ that make this a general solution.

> Yes, it is common practice. ...

> Thinking ahead, I'd developed a tool to track program executions. It shows one
> of the 15 running every day, the others seldom or never. I change that one.

So, how did you know which one ran ?  Obviously not from the
Program-Id if they were all the same.

How did the program get executed ?  Something must have specified its
name, presumably its file name.  Surely you should have been able to
find which one was run by looking at what CALLed it, or the job cards.

> Months later the file gets broken. Hours of research leads to 'we run that
> program when someone asks for special handling.' 

That shows you have a complete lack of 'thinking ahead'.  Either you
should have changed all 15 or should have 'archived' the other 14 so
they could be used.

> Yes, it is common practice. ...

> This kind of abuse is WHY big shops are burdened with Change Management
> software and programmers locked out of the production box.

The 'common practice' and 'burdened by CMS' seem to be incompatible.
0
riplin (4127)
6/12/2004 10:10:03 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> >That is presuming that the implementation has an accessible structure such
> >as a "call stack".
> 
> Every called program has a way of returning to its caller.
 
But that not not imply that the called program has _access_ to the
caller's memory nor to anything above that.
0
riplin (4127)
6/12/2004 10:13:03 PM
David Latimer wrote:
> I'm using MicroFocus COBOL 4.0 on UnixWare 2.1.3.
>
> I'd quite like to be able to use the Program Id in every program using
> the same phrase (e.g. MOVE prog id TO XYZ).
>
> There are other ways of getting the same result but I just wondered if
> this was possible.
>
> David L.

Inasmuch as this thread has wandered over all creation, let's start another:

Why do you want to do this? What do you want to accomplish?

In olden days, programmers used to mark the start of Working-Storage with:

01  FILLER  PIC X(24) VALUE 'START OF WORKING-STORAGE.

We use the same technique. All our COBOL programs start with:

01 FILLER PIC X(24) VALUE 'Microsoft C++ (c) 1997'.


0
nospam312 (645)
6/12/2004 10:41:41 PM
JerryMouse wrote:
> 
> In olden days, programmers used to mark the start of Working-Storage with:
> 
> 01  FILLER  PIC X(24) VALUE 'START OF WORKING-STORAGE.

Wow!  In olden days, you used to be able to omit the closing quote?  ;)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
6/12/2004 11:21:00 PM
Chuck Stevens wrote:

>> much snipped
 >
> Moreover, there is nothing except resources and incentive preventing an
> obsolete-computer buff from implementing a fully-2002-compliant COBOL
> implementation on a Burroughs B3500, or even an IBM 1401, for which
> architectures the concept of "fixed-length words" as I understand the
> concept does not exist.
I remember the 1401.  It had characters with six bits plus a word mark 
bit.  All fields were terminated by a word mark, a record mark or a 
group mark.  I forget whether the group mark was a record mark with the 
word mark bit set or a record mark was a group mark with the word mark 
bit set.  The 1401/1440 definitely could not handle the 2002 standard 
with only three character addresses maximum and I doubt the big brothers 
1410/7010 would have been equal to the task.  With all fields being 
variable, the series was not well suited to COBOL with multiple record 
formats.  Many of the instructions were variable length of 1, 4 or 7 
characters.  The Move Instruction M meant Move A to B stopping at the 
word mark.  If an address was omitted it meant pick up where the 
previous instruction left off.  All told an intriguing machine. 
Emulation on Intel would be interesting.  It probably would be slow.
> 
>     -Chuck Stevens
> 
> 




0
cfmtech (125)
6/12/2004 11:39:25 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> The stack contains a return address. Using that, the program name can usually

>
>The 'return address' need not be to the actual CALLing program.  It
>may be to the run-time so that the run-time can decrement the 'active'
>counter or somesuch.  The run-time does know which programs are
>active, which is why it can give an error when a re-entry is tried.

Even if the program does return to a run-time, the return address will be below
it on a stack. It has to be in order for recursion to work.

>> found near the beginning of its segment or in a public symbol table. 
>
>I just looked as some object code.  Yes the program name is there, so
>are a lot of other names, and in no particular order.  This is also
>_not_ a general solution as you claimed and may be entirely specific
>to particualr compilers and environments, each one requiring a
>different solution.

The location of the name is defined by the file format, which is defined by the
operating system. It has to be so Task Viewers can show what's running,
including called programs.

>> >So even if one could work out the stack frames to access the calling
>> >program there is still _nothing_ as a 'general-purpose' in that
>> >program that would give that name.  If there was then it would also be
>> >in the called program, so walking the stack is unrequired.
>> 
>> Heap walkers are a very common diagnostic tool. I'm disappointed to read 
>> you're unfamiliar with the concept.
>
>You are now confused between the stack and the heap.  They are
>different things you know.

Heap walkers and Task viewers follow the same concept, and are often integrated.
The concept is walking up and down a tree structure.

>> Thinking ahead, I'd developed a tool to track program executions. It shows
one
>> of the 15 running every day, the others seldom or never. I change that one.
>
>So, how did you know which one ran ?  Obviously not from the
>Program-Id if they were all the same.

From the file name. Logging executions is especially easy when they use 'cobrun'
to start programs. Write a script named 'cobrun' and put it ahead of Micro Focus
in the PATH.

>How did the program get executed ?  Something must have specified its
>name, presumably its file name.  Surely you should have been able to
>find which one was run by looking at what CALLed it, or the job cards.

That just moves the problem up a level without solving it. There may be obsolete
scripts running obsolete programs. Some programs were run by a human typing the
name on a command line. Some are called by dead code hooked to a menu item that
no longer displays.

Analysis of the thousands of programs showed the same happening at the file
level. There were thousands of FDs that were never opened, or opened but not
read or written, or opened for update but not updated. I posted the analysis
program here last year.

This is what happens when programs are 'written' by copy-and-paste. 

>> Months later the file gets broken. Hours of research leads to 'we run that
>> program when someone asks for special handling.' 
>
>That shows you have a complete lack of 'thinking ahead'.  Either you
>should have changed all 15 or should have 'archived' the other 14 so
>they could be used.

If I changed all 15, the forces of darkness would say I was wasting time
changing obsolete programs. If I'd archived the unused ones, they'd wait for (or
create) a crisis, then point the finger at me for removing an 'essential'
program. Or they'd run it unmodified, thereby breaking the file.

What SHOULD have been done was complete elimination of duplicate code. OO makes
it easier to do that. If one needs 'special handling' for one run, he or she
overloads a method for that run only. 

>> This kind of abuse is WHY big shops are burdened with Change Management
>> software and programmers locked out of the production box.
>
>The 'common practice' and 'burdened by CMS' seem to be incompatible.

Undisciplined redundant code is found in small shops lacking Change Management.
Big shops make a clear distinction between production code and everything else.
Obfuscators still find ways to ply their trade. ODBC is one of their best
friends, enabling them to write applications in Access without the inconvenience
of controls. Access feels like a programming environment designed by Walmart.
The more things change, the more they stay the same.



0
6/13/2004 2:10:30 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> >That is presuming that the implementation has an accessible structure such
>> >as a "call stack".
>> 
>> Every called program has a way of returning to its caller.
> 
>But that not not imply that the called program has _access_ to the
>caller's memory nor to anything above that.

The language requires this to work:

Program A: call 'B' using BY REFERENCE a-1
Program B: call 'C' using BY REFERENCE a-1, b-2
Program C: display 'I have access to ' a-1 ' and ' b-2

Operating systems protect memory at the Process level. Can you cite one that
works at the called program level? I thought not.


0
6/13/2004 2:12:17 AM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> >But that not not imply that the called program has _access_ to the
> >caller's memory nor to anything above that.
> 
> The language requires this to work:
> 
> Program A: call 'B' using BY REFERENCE a-1
> Program B: call 'C' using BY REFERENCE a-1, b-2
> Program C: display 'I have access to ' a-1 ' and ' b-2
> 
> Operating systems protect memory at the Process level. Can you cite one that
> works at the called program level? I thought not.

It doesn't need to be protected by the OS to not have access to
something, just because you have a return address to the code segemnt
(presuming it is not just the run-time's) does not mean that you can
usefully find the data segement.

The LINKAGE areas may be of little use as these, as you show, may be
areas in some other program entirely.
0
riplin (4127)
6/13/2004 6:09:53 AM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> Even if the program does return to a run-time, the return address will be below
> it on a stack. It has to be in order for recursion to work.

It may be _somewhere_ on the stack. Of course if it is .int code then
it isn't a real return address but an address in the byte code that
the interpreter will use.

> The location of the name is defined by the file format, which is defined by the
> operating system. It has to be so Task Viewers can show what's running,
> including called programs.

What is in memory is entirely what the run-time wants it to be.  For
example .int and .gnt aren't loaded as executables.  The 'task' is the
run-time byte interpreter.

> Heap walkers and Task viewers follow the same concept, and are often
> integrated.
> The concept is walking up and down a tree structure.

What stack is a 'tree structure' ?
0
riplin (4127)
6/13/2004 6:17:35 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 

>What is in memory is entirely what the run-time wants it to be.  For
>example .int and .gnt aren't loaded as executables.  The 'task' is the
>run-time byte interpreter.

Micro Focus says those formats are retained only for backward compatibility.
They recommend OS standard formats: executable, .so and .dll.

>> Heap walkers and Task viewers follow the same concept, and are often
>> integrated.
>> The concept is walking up and down a tree structure.
>
>What stack is a 'tree structure' ?

The calling and called programs form a tree structure.

0
6/13/2004 10:19:12 AM
LX-i wrote:
> JerryMouse wrote:
>>
>> In olden days, programmers used to mark the start of Working-Storage
>> with:
>>
>> 01  FILLER  PIC X(24) VALUE 'START OF WORKING-STORAGE.
>
> Wow!  In olden days, you used to be able to omit the closing quote?
> ;)

No, there's a continuation line. Remember those?


0
nospam312 (645)
6/13/2004 12:08:43 PM
Isn't this getting a little bit out of hand?

  Some compilers use entry logic that stores the program name in the stack frame for
  just this purpose.

  On some platforms you can compile with debugging enabled, which will set STABS
  information in the link-edited file, accomplishing the same thing

  Most shops that really want to do this define standard entry-logic for their programs
  which includes a step to store the program name in WS or some other well known space.

   On the mainframe, you have ADATA records that can help you out.

-Paul

"Richard" <riplin@Azonic.co.nz> wrote in message news:217e491a.0406121410.5ac81559@posting.google.com...
> robert.deletethis@wagner.net (Robert Wagner) wrote
>
> > The stack contains a return address. Using that, the program name can usually
>
> The 'return address' need not be to the actual CALLing program.  It
> may be to the run-time so that the run-time can decrement the 'active'
> counter or somesuch.  The run-time does know which programs are
> active, which is why it can give an error when a re-entry is tried.
>
> > found near the beginning of its segment or in a public symbol table.
>
> I just looked as some object code.  Yes the program name is there, so
> are a lot of other names, and in no particular order.  This is also
> _not_ a general solution as you claimed and may be entirely specific
> to particualr compilers and environments, each one requiring a
> different solution.
>
> > >But also the CALL does not necessarily go to the called program
> > >directly.  It most likely goes to the run-time resolver, so going one
> > >up the stack does not necessarily go to the caller.
> >
> > Let's try to stay in focus. We're interested in the RETURN address, not the
> > call address.
>
> And the return address may be back to the run-time which is where the
> actual entry to the called program came from.
>
> > >So even if one could work out the stack frames to access the calling
> > >program there is still _nothing_ as a 'general-purpose' in that
> > >program that would give that name.  If there was then it would also be
> > >in the called program, so walking the stack is unrequired.
> >
> > Heap walkers are a very common diagnostic tool. I'm disappointed to read
> > you're unfamiliar with the concept.
>
> You are now confused between the stack and the heap.  They are
> different things you know.
>
> As I said there is still _nothing_ that make this a general solution.
>
> > Yes, it is common practice. ...
>
> > Thinking ahead, I'd developed a tool to track program executions. It shows one
> > of the 15 running every day, the others seldom or never. I change that one.
>
> So, how did you know which one ran ?  Obviously not from the
> Program-Id if they were all the same.
>
> How did the program get executed ?  Something must have specified its
> name, presumably its file name.  Surely you should have been able to
> find which one was run by looking at what CALLed it, or the job cards.
>
> > Months later the file gets broken. Hours of research leads to 'we run that
> > program when someone asks for special handling.'
>
> That shows you have a complete lack of 'thinking ahead'.  Either you
> should have changed all 15 or should have 'archived' the other 14 so
> they could be used.
>
> > Yes, it is common practice. ...
>
> > This kind of abuse is WHY big shops are burdened with Change Management
> > software and programmers locked out of the production box.
>
> The 'common practice' and 'burdened by CMS' seem to be incompatible.


0
pkrauleson (30)
6/13/2004 3:52:59 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> >What stack is a 'tree structure' ?
> 
> The calling and called programs form a tree structure.

No they don't, the structure of 'the stack' is 'a stack', like a stack
of plates it grows and shrinks along a single axis.

A 'tree structure', like an actual tree, has branches.  A binary tree,
for example, has left and right pointers.

Sometimes I don't know whether you are just confused of whether you
are trolling.
0
riplin (4127)
6/13/2004 7:12:59 PM
JerryMouse wrote:
> LX-i wrote:
> 
>>JerryMouse wrote:
>>
>>>In olden days, programmers used to mark the start of Working-Storage
>>>with:
>>>
>>>01  FILLER  PIC X(24) VALUE 'START OF WORKING-STORAGE.
>>
>>Wow!  In olden days, you used to be able to omit the closing quote?
>>;)
> 
> 
> No, there's a continuation line. Remember those?

Heh - remember?  I've used 'em - used one last week.  :)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0
lxi0007 (1830)
6/13/2004 7:13:44 PM
riplin@Azonic.co.nz (Richard) wrote:

>Sometimes I don't know whether you are just confused of whether you
>are trolling.

I'm not trolling. You don't understand the points I try to make.
0
6/14/2004 12:11:30 AM
The problem with using PROGRAM-ID is that it has no necessary 
operational significance in many environments.  On the IBM OS360 and 
successor operating systems (z/OS being the latest incarnation), a 
program could have a source member name of X123 and be compiled and 
linked to give an executable name of X123 while the PROGRAM-ID value is 
Z456.  While this is bad policy, the operating system will happily 
execute X123 or accept dynamic CALLs of X123, executing them correctly 
and won't recognize Z456.

0
cfmtech (125)
6/14/2004 12:42:14 AM
In article <40cbb7c3.101370979@news.optonline.net>,
 robert.deletethis@wagner.net (Robert Wagner) wrote:

> riplin@Azonic.co.nz (Richard) wrote:
> 
> >robert.deletethis@wagner.net (Robert Wagner) wrote
> >
> >> >That is presuming that the implementation has an accessible structure such
> >> >as a "call stack".
> >> 
> >> Every called program has a way of returning to its caller.
> > 
> >But that not not imply that the called program has _access_ to the
> >caller's memory nor to anything above that.
> 
> The language requires this to work:
> 
> Program A: call 'B' using BY REFERENCE a-1
> Program B: call 'C' using BY REFERENCE a-1, b-2
> Program C: display 'I have access to ' a-1 ' and ' b-2
> 
> Operating systems protect memory at the Process level. Can you cite one that
> works at the called program level? I thought not.
 
MVS, OS/390, z/OS.

While it does not protect memory at the program level.  It does limit 
switches to supervisor state (e.g. free access to all system memory) at 
the program level.

Thus, a process with its own protected memory can call an 'authorized' 
program, which can then read any memory in the system regardless of 
protection level or owner.
0
6/14/2004 1:00:59 PM
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
news:cag4bh$j8c$1@news.eusc.inter.net...
[snip]
> Emulation on Intel would be interesting.  It probably would be slow.

It all depends on what your definition of 'slow' is.

My first computer programming job (outside of college) was translating 1401
Autocoder to this new-fangled 360 COBOL.  This was done for a large
manufacturing concern that literally had acres (hectares) of 360s, including
row upon row of 360/30s running in 1401 emulation mode.   Of course they
were faster than the 1401s they replaced.

There is absolutely no doubt in my mind that the 2.8GHz Intel waiting for me
to type this could emulate several 1401s between keystrokes, and still
perform better than the original 1401 speed!

Tom Morrison


0
t.morrison (73)
6/14/2004 1:11:56 PM
Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:

>In article <40cbb7c3.101370979@news.optonline.net>,
> robert.deletethis@wagner.net (Robert Wagner) wrote:
>
>> riplin@Azonic.co.nz (Richard) wrote:
>> 
>> >robert.deletethis@wagner.net (Robert Wagner) wrote
>> >
>> >> >That is presuming that the implementation has an accessible structure
such
>> >> >as a "call stack".
>> >> 
>> >> Every called program has a way of returning to its caller.
>> > 
>> >But that not not imply that the called program has _access_ to the
>> >caller's memory nor to anything above that.
>> 
>> The language requires this to work:
>> 
>> Program A: call 'B' using BY REFERENCE a-1
>> Program B: call 'C' using BY REFERENCE a-1, b-2
>> Program C: display 'I have access to ' a-1 ' and ' b-2
>> 
>> Operating systems protect memory at the Process level. Can you cite one that
>> works at the called program level? I thought not.
> 
>MVS, OS/390, z/OS.
>
>While it does not protect memory at the program level.  It does limit 
>switches to supervisor state (e.g. free access to all system memory) at 
>the program level.

Every operating system does that. The issue was limiting access within a
Process.

>Thus, a process with its own protected memory can call an 'authorized' 
>program, which can then read any memory in the system regardless of 
>protection level or owner.

Sounds like a hole in security. Another process might have cleartext of an
encrypted document.

0
6/14/2004 4:01:23 PM
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
news:cag4bh$j8c$1@news.eusc.inter.net...

> I remember the 1401.  It had characters with six bits plus a word mark
> bit.  All fields were terminated by a word mark, a record mark or a
> group mark.  I forget whether the group mark was a record mark with the
> word mark bit set or a record mark was a group mark with the word mark
> bit set.  The 1401/1440 definitely could not handle the 2002 standard
> with only three character addresses maximum and I doubt the big brothers
> 1410/7010 would have been equal to the task.  With all fields being
> variable, the series was not well suited to COBOL with multiple record
> formats.  Many of the instructions were variable length of 1, 4 or 7
> characters.  The Move Instruction M meant Move A to B stopping at the
> word mark.  If an address was omitted it meant pick up where the
> previous instruction left off.  All told an intriguing machine.

I maintain that *given enough time* you could do anything on a 1401.  It
might not be easy.  It might not be straightforward.  But presuming the task
at hand did not require peripherals unavailable on a 1401 it is *doable* if
you're willing to wait long enough.

I remember writing a model of the chemical reactions in the human retina
(which involved five simultaneous linear differential equations with
coefficients too great to allow for Runge-Kutta techniques, requiring a
Laplace transform which had to be solved for the quartic and thence to the
binomials using Newton-Raphson iterations) on, first, an Interdata Model 3
(which had no hardware multiply/divide, much less floating-point hardware),
and subsequently on a Wang 700 programmable calculator using code
segmentation and automatic loading on the program cassette drive.

While the Wang took a few hours to do a "run", and the Interdata took three
days, two hours, and ten minutes, the same equation could be solved in a few
minutes on the Philco 2000/210.

I didn't say the 1401 would execute 2002 COBOL code *rapidly*

> Emulation on the Intel would be interesting.  It probably would be slow.

Actually, I doubt it!

    -Chuck Stevens


0
6/14/2004 4:06:36 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40cb1626.59991723@news.optonline.net...

>
> The stack contains a return address. Using that, the program name can
usually be
> found near the beginning of its segment or in a public symbol table.

Define "usually".  Definitely *not* the case for Unisys MCP systems; the
only place the name of the called program appears at execution time is in
the execution-time library template for external programs and not at all for
unambiguously nested ones (for which the name is resolved at compile time)!

> Let's try to stay in focus. We're interested in the RETURN address, not
the call
> address.

What does a PCW have to do with a name?

> Heap walkers are a very common diagnostic tool. I'm disappointed to read
you're
> unfamiliar with the concept.

I'm familiar enough with the concept; it escapes me why you feel walking a
heap (or a stack, for that matter) is universally applicable to standard
COBOL in all, or even most, implementations.

    -Chuck Stevens


0
6/14/2004 4:22:15 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40cce67e.178881558@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
>
> >Sometimes I don't know whether you are just confused of whether you
> >are trolling.
>
> I'm not trolling. You don't understand the points I try to make.

The job of communicating to an audience lies to significant degree with the
person trying to make the points.  That you are not succeeding with Richard
(or, for that matter, frequently with me) is not necessarily his, or my,
fault.

Often I do understand the points you make.  You've indicated that a user
program can access its own stack at execution time, or alternatively that a
user-written program can access another program's stack.  On machines where
the hardware design prohibits such access as a security measure, your
assertion is ... ummm ... unlikely.

       -Chuck Stevens


0
6/14/2004 4:29:29 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40ca30db.1284627@news.optonline.net...

> Every called program has a way of returning to its caller.

That does not mean that mechanism is necessarily visible to the caller, the
called program, or to an outside process.

> > The objective here is to ensure that a-program cannot
> > step on this particular parameter.

> But it can. It just cannot modify it back in the caller's memory.

True; that's precisely the point of the difference between BY CONTENT and BY
REFERENCE.  A called program *can* step on the parameter in the caller's
memory if it's BY REFERENCE.

> I don't think this is a realistic concern. Programs generally don't
recklessly
> modify parameters.

It was a realistic enough problem in a Fortran environment I worked on back
in about 1970, in which the constant integer 1 was passed to a subroutine
that modified its value.  And it was a realistic enough problem during the
development of the '85 standard to stimulate the framers of that standard
into adding "by content" to the parameter descriptions in CALL and "by
value" to the Procedure Division header.    Programs may not generally
*recklessly* modify parameters, but it is not uncommon for them
*inadvertently* to do so!


> It is in nearly all environments. It need not be. Sure, dataname can
change, but
> 99.99 percent of the time it doesn't. INLINE code could (should) check
that it's
> the same and then call directly, with little more overhead than a static
link. I
> used to write enhancers that reached back and modified generated code to
do
> exactly that.

In our environment, if you use CALL <dataname> it is precisely because you
expect the contents of <dataname> to change from one execution to the next.


> > where does the standard require that the implementor keep track of
> >information about calling history in some sort of hardware stack?   Where
> >does the standard prohibit putting strings (do you mean strictly
> >"alphanumeric literals" or do you include "alphanumeric data items"?) on
> >that stack?
> >
> >BY CONTENT non-numeric parameters of arbitrary length are allowed.
> >
> >How the implementation *accomplishes* passing, say, a 30,000-byte record
as
> >a parameter BY CONTENT is none of the end user's business; the only
concern
> >is how the caller sees it if the called program happens to step on its
> >contents (and the correct expectation is that it be unchanged).
>
> True but discordant with the culture of operating systems and other
languages.

I'm not sure what you're responding to here.  I have been actively
supporting compilers for four dialects of ALGOL, two of Pascal, three of
COBOL, and miscellaneous other language compilers *and* their operating
environments for quite some time now, and I don't see the discordance you
assert.

> Micro Focus says:
>
> "If the program being called is not COBOL, the size of the additional data
item
> should not exceed the maximum size of the system area (typically the size
of a
> POINTER on the system); otherwise the system might become catastrophically
> corrupt."

Unlikely on our system because of memory protection hardware.   A fatal
termination of the offending program would almost certainly result.  Can be
done, but you have to go *way* out of your way (like, call an ALGOL
subprogram that changes the size of a data item) to do it, and the manual
already says it's the user's responsibility to ensure that parameter.  The
standard already says that the parameter in a Procedure Division USING
phrase must be the same size *or smaller* than in the program that calls it
if the caller passes it by reference, so that means the called program can't
get outside the bounds of what it's passed.  Wouldn't the same thing
reasonably apply when what's being called isn't in COBOL?   Aren't the
consequences of violating the rules of the standard undefined?  What's your
point?

> The idea of BY CONTENT and BY VALUE is based on paranoia and disrespect.
Its
> premise is that called programs may irrationally corrupt parameter values.
In
> the real world, that's not a realistic concern.

No, it is based on the premise of *safeguarding* parameter values.  It is
not merely "irrational" corruption that it guards against, it is also
"inadvertent" corruption as well as "malevolent" corruption.  A called
routine can protect itself and its data from a malevolent caller, and a
calling program can protect itself and its data from a
malevolently-substituted called routine.  And, however silly you might find
the idea, it's been part of COBOL for nigh onto twenty years now, and it
ain't going anywhere soon!

> You're correct: they didn't have words nor stacks, but they did have a
pointer
> back to the caller.

Didn't say they didn't.  What I did say was that it wasn't a *word*, nor did
it necessarily bear any relationship to any other hardware or software
structure in the system.

    -Chuck Stevens


0
6/14/2004 5:46:46 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40cbb7c3.101370979@news.optonline.net...

> The language requires this to work:
>
> Program A: call 'B' using BY REFERENCE a-1
> Program B: call 'C' using BY REFERENCE a-1, b-2
> Program C: display 'I have access to ' a-1 ' and ' b-2

True enough.  It also requires that if you change a-1 that change is visible
in Program A, and if you change b-2, that change is visible in Program B.

The language also requires that if Program A contains data items a-3 and
a-4, and Program B has data items b-3 and b-4, B cannot "see" a-1 or a-2
(unless, of course, they're declared global and B is nested in A), nor can C
see b-3 or b-4 (unless they're global and C is nested in B) or a3 or a-4
(unless they're global and C is nested within B which is nested within A).

Moreover, given

Program A: call 'B' using BY CONTENT a-1
Program B: call 'C' using BY CONTENT a-1, b-2
Program C: display 'I have access to ' a-1 ' and ' b-2 '
will execute, but any changes B or C make to a-1 or b-2 will *not* be
visible in their "owning" programs.

> Operating systems protect memory at the Process level. Can you cite one
that
> works at the called program level?

Depends on what you mean by "memory", "protect", and "process", to say
nothing of the blanket "operating systems".  Protection of the "local"
memory of a called program is a function of the operating environment as it
relates to the characteristics of the *program*.  It's not so much the
"operating system" as it is the "hardware" in our case, but the operating
system does participate.    Parameters are protected, or not protected, as
specified by the authors of both the called and calling programs.  If the
memory is shared between them (by reference in the calling and called
programs), then it's shared; if it's any other combination (by reference in
the calling program, by value in the called or vice versa, or by value in
both), the rules require that the formal and actual parameters be "treated
as if" they were separate memory areas.

In the case of Unisys MCP, it's the *compiler* that handles these
distinctions, not the operating system.  So, yes, I can cite one that works
at the called program level rather than at the operating system level.

> I thought not.

I'm afraid you thought wrong.

    -Chuck Stevens


0
6/14/2004 6:11:28 PM
Chuck Stevens wrote:
[...]
> I maintain that *given enough time* you could do anything on a 1401.  It
> might not be easy.  It might not be straightforward.  But presuming the task
> at hand did not require peripherals unavailable on a 1401 it is *doable* if
> you're willing to wait long enough.
[...]


My 1401 story is more mundane - the company had payroll
running on a 16K 1401 with multiply/divide, and wanted
to downgrade to a 4K 1401 without multiply/divide. They
did retain tape, on which I developed macros for the
multiply/divide, and on which I could store intermediate
results. The resulting program had two phases, with the
data cards inserted between the two portions of the program.


Kindrick



0
kownby (20)
6/14/2004 7:29:49 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40cbb7c3.101370979@news.optonline.net...

>> Operating systems protect memory at the Process level. Can you cite one
>that
>> works at the called program level?
>
>Depends on what you mean by "memory", "protect", and "process", to say
>nothing of the blanket "operating systems".  Protection of the "local"
>memory of a called program is a function of the operating environment as it
>relates to the characteristics of the *program*.  It's not so much the
>"operating system" as it is the "hardware" in our case, but the operating
>system does participate.   

Every platform I've worked on also uses hardware. But the operating system tells
the hardware about zones of memory and ids of authorized users. Typically, the
zones are "segments" and the user is a "process id". Thus, every called program
has access to the memory of all other programs within the process .. as far as
the hardware is concerned. 

Does Unisys MCP setup user ids smaller than a 'process'? 

>Parameters are protected, or not protected, as
>specified by the authors of both the called and calling programs.  If the
>memory is shared between them (by reference in the calling and called
>programs), then it's shared; if it's any other combination (by reference in
>the calling program, by value in the called or vice versa, or by value in
>both), the rules require that the formal and actual parameters be "treated
>as if" they were separate memory areas.
>
>In the case of Unisys MCP, it's the *compiler* that handles these
>distinctions, not the operating system.  So, yes, I can cite one that works
>at the called program level rather than at the operating system level.

Would Unisys MCP or compiler stop this:

Program A:
01  bunch-of-pointers.
     05  pointer-to-a4       pointer.
     05  pointer-to-a5       pointer.

set pointer-to-a4 to address of a4
set pointer-to-a5 to address of a5
call 'B' using bunch-of-pointers

Program B:
linkage section.
01  bunch-of-pointers.
     05  pointer-to-a4       pointer.
     05  pointer-to-a5       pointer.
01 a4     pic x.
01 a5     pic x.
procedure division using bunch-of-pointers.
set address of a4 to pointer-to-a4
set address of a5 to pointer-to-a5
display 'I can see ' a4 ' and ' a5
0
6/15/2004 12:31:50 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40ca30db.1284627@news.optonline.net...

>> I don't think this is a realistic concern. Programs generally don't
>recklessly
>> modify parameters.
>
>It was a realistic enough problem in a Fortran environment I worked on back
>in about 1970, in which the constant integer 1 was passed to a subroutine
>that modified its value.  And it was a realistic enough problem during the
>development of the '85 standard to stimulate the framers of that standard
>into adding "by content" to the parameter descriptions in CALL and "by
>value" to the Procedure Division header.    Programs may not generally
>*recklessly* modify parameters, but it is not uncommon for them
>*inadvertently* to do so!

In 40+ years Cobol programming, I've never used BY CONTENT (unless the called
program required it).

>> It is in nearly all environments. It need not be. Sure, dataname can
>change, but
>> 99.99 percent of the time it doesn't. INLINE code could (should) check
>that it's
>> the same and then call directly, with little more overhead than a static
>link. I
>> used to write enhancers that reached back and modified generated code to
>do
>> exactly that.
>
>In our environment, if you use CALL <dataname> it is precisely because you
>expect the contents of <dataname> to change from one execution to the next.

I dispute that. You use it because you want to force dynamic links and the
compiler doesn't provide a suitable option such as DYNAM, which makes all calls
dynamic.

In the Unix world, late binding is the default.

>> True but discordant with the culture of operating systems and other
>languages.
>
>I'm not sure what you're responding to here.  I have been actively
>supporting compilers for four dialects of ALGOL, two of Pascal, three of
>COBOL, and miscellaneous other language compilers *and* their operating
>environments for quite some time now, and I don't see the discordance you
>assert.

Other languages discourage or outright prohibit passing large structures on the
stack. That's the provenance of malloc (intra-process) or Shared Memory (across
processes). The caller is expected to allocate a chunk and pass a pointer to it.




0
6/15/2004 12:31:51 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>Often I do understand the points you make.  You've indicated that a user
>program can access its own stack at execution time, or alternatively that a
>user-written program can access another program's stack.  On machines where
>the hardware design prohibits such access as a security measure, your
>assertion is ... ummm ... unlikely.

If a program couldn't access its own stack, it wouldn't be able to return from a
call. 

If it couldn't access the caller's stack, this wouldn't work:

Program A: call 'B' using by content a1
Program B: display "A's stack is at " address of a1
0
6/15/2004 12:31:52 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40cb1626.59991723@news.optonline.net...
>
>>
>> The stack contains a return address. Using that, the program name can
>usually be
>> found near the beginning of its segment or in a public symbol table.
>
>Define "usually".  Definitely *not* the case for Unisys MCP systems; the
>only place the name of the called program appears at execution time is in
>the execution-time library template for external programs and not at all for
>unambiguously nested ones (for which the name is resolved at compile time)!

When a runtime error occurs and the program isn't handling it, doesn't Cobol
issue a message containing the program name and a description of the error?

Isn't there a debug compiler option, which preserves names?

>> Heap walkers are a very common diagnostic tool. I'm disappointed to read
>you're
>> unfamiliar with the concept.
>
>I'm familiar enough with the concept; it escapes me why you feel walking a
>heap (or a stack, for that matter) is universally applicable to standard
>COBOL in all, or even most, implementations.

Near the beginning of this thread, we discussed identifying programs in error
messages. I opined that the error reporting mechanism should walk back the stack
reporting the names of all programs leading to one of interest. 
0
6/15/2004 12:31:54 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
>news:cag4bh$j8c$1@news.eusc.inter.net...
>
>I maintain that *given enough time* you could do anything on a 1401.  It
>might not be easy.  It might not be straightforward.  But presuming the task
>at hand did not require peripherals unavailable on a 1401 it is *doable* if
>you're willing to wait long enough.

I maintain a machine needs only one instruction to solve any problem. There
wouldn't be an opcode. The four operands would be o1 and o2, the source and
destination for a (possibly indexed) copy; o3, the object of a test; and o4, the
address and condition of a call. 

Let's call this hypothetical machine CADET, for Can't Add, Doesn't Even Try. It
could do arithmetic by table lookup using two indicies. The RCA 301 actually
worked that way. If someone stepped on the arithmetic table at a fixed address
in low memory, answers came out wrong until you rebooted the machine. 

>I remember writing a model of the chemical reactions in the human retina
>(which involved five simultaneous linear differential equations with
>coefficients too great to allow for Runge-Kutta techniques, 

Adams-Moulton techniques would likely have handled the range.

>requiring a
>Laplace transform which had to be solved for the quartic and thence to the
>binomials using Newton-Raphson iterations) 

Birge-Vieta methods of pivotal condensation would have speeded up that phase.

0
6/15/2004 12:31:55 AM
Obviously it depends on just what you want to do wit hthe Program Name and
why.

I use this type of thing to identify the actual program being run.  But I am
not interested in just the name of the program, but the version as well.

The PROGRAM-ID doesn't give you the version so it is useless for my
purposes.

Instead, I define a Working Storage variable (with the inovative name of
PROG-NAME) and I use CVS commands to define the value.  This means that when
some idiot copies the program and doesn't change "PROGRAM-ID", I still pick
up the real name of the program.  It also gives me the version number as
well.

I would imagine that most systems have some kind of Source Code Control
System capable of doing this.

Jim Morcombe

Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40c800ce.497169106@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
>
> >robert.deletethis@wagner.net (Robert Wagner) wrote
> >
> >> >I'd quite like to be able to use the Program Id in every program using
> >> >the same phrase (e.g. MOVE prog id TO XYZ).
> >
> >> If you compile to .gnt, change awk to print $9. I used the -f option on
ps so
> it
> >> would show the whole command line.
> >
> >That is not going to show the name of any CALLed programs, which is
> >probably the point of the request.
>
> No, he wants the name of the Main program, probably to print in a log file
or
> report header. The logic getting the name would best be in a called
program.
> Printing 'getmyname' on every report would not be informative.
>
> If programs are compiled to .gnt, the gnt _is_ a called program .. called
by
> cobrun, which would appear in column 8.
>


0
jim3810 (16)
6/15/2004 4:40:49 AM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> In 40+ years Cobol programming, I've never used BY CONTENT (unless the called
> program required it).

How would a CALLed program specify that it _requires_ a parameter to
be passed BY CONTENT ?

> >In our environment, if you use CALL <dataname> it is precisely because you
> >expect the contents of <dataname> to change from one execution to the next.
> 
> I dispute that. You use it because you want to force dynamic links and the
> compiler doesn't provide a suitable option such as DYNAM, which makes all
> calls dynamic.

Why do you assume that in his environment he does not have a way to
make calls using literals as being dynamic ?  On some COBOL systems
_all_ CALLs are dynamic, even when using literals.

Disputing and contradicting people about environments you seem to know
little about may sometimes be the sign of trolling.

> In the Unix world, late binding is the default.

Which may be irrelevant to what any particualr COBOL system does.  For
example using .int does not need to use what the 'Unix world' uses.
0
riplin (4127)
6/15/2004 7:22:52 AM
There is an emulator that claims the 1401.  The SIMH runs on Intel and 
windows:

   http://simh.trailing-edge.com/

So the theory of a fast 1401 can be tested...
0
6/15/2004 11:58:06 AM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40ce1792.256994029@news.optonline.net...

> Every platform I've worked on also uses hardware. But the operating system
tells
> the hardware about zones of memory and ids of authorized users.

In the case of Unisys MCP, programs request memory during their initiation.
The descriptors pointing to that memory are contained within the program's
stack, and the only processes that can see those descriptors, or the memory
they point to, are the programs themselves and the MCP.  Even the
descriptors are indirect, as they reference a MCP table that contain the
*actual* descriptors of the code segments.  The only authorized user of a
space of memory is the process that created it, unless that process
explicitly provides a path to it (for example, as a parameter to a task or
library).

> Typically, the
> zones are "segments" and the user is a "process id". Thus, every called
program
> has access to the memory of all other programs within the process .. as
far as
> the hardware is concerned.

Nope.  Not even close.

> Does Unisys MCP setup user ids smaller than a 'process'?

"User id's" arent germane to Unisys MCP memory management, as I see it.  You
want memory?  You build a descriptor template; first time you touch that
template, the MCP allocates the memory.  The descriptor to that memory is in
*your* stack; nobody else but the MCP can see it, or the memory it
addresses, unless you pass them the descriptor.  You go away?  The MCP
deallocates the memory as part of the process of tearing the stack down.

> Would Unisys MCP or compiler stop this:
>
> Program A:
> 01  bunch-of-pointers.
>      05  pointer-to-a4       pointer.
>  ...

Umm... Yeah, sure would, at "pointer-to-A4  pointer".  I think you're
laboring under at least one mistaken assumption here.

The Unisys MCP environment currently supports two dialects of COBOL:
COBOL74, which follows ANSI X3.23-1974, and COBOL85, which follows ANSI
X3.23-1985 plus the two amendments.

USAGE POINTER was introduced in ISO/IEC 1989:2002 and is an *extension* to
any implementation of COBOL that conforms to any *prior* standard.

Thus, Unisys MCP software does not recognize the above code as meaningful
simply because USAGE POINTER isn't in either ANSI X3.23-1974 or ANSI
X3.23-1985, nor is it implemented as a Unisys extension to either of those
standards in either of the Unisys MCP COBOL compilers.

Unisys might consider adding USAGE POINTER to the list of 2002-standard
features for consideration for inclusion in our ANSI-85 compiler, but before
we could do so we would need at least one Unisys MCP user to let it be known
to us that they found it a desirable enhancement, and we have not as yet
been notified of such a request.  The enhancements that people have actually
asked for have to take precedence (for example, INITIALIZE WITH FILLER has
been requested as a means of improving performance of INITIALIZE).

The current memory management scheme, and the security it affords our users,
is a well-liked feature of the Unisys MCP environment that our users have
liked since our introduction of it in the Burroughs B5000 and through its
refinement over a number of generations of hardware design.  It is not clear
to us that providing a mechanism whereby users could pretty much arbitrarily
get to any memory of any component of a run unit without the most local
"owner" of that memory having any say in the matter would represent an
improvement in either security or functionality to our existing customers.

    -Chuck Stevens


0
6/15/2004 4:26:22 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40ce1f14.258916099@news.optonline.net...

> If a program couldn't access its own stack, it wouldn't be able to return
from a
> call.

Silly me.  I was under the impression that the EXIT (or RETN) hardware
operators, with a RCW on the stack placed there by the caller and invisible
to the called routine, handled that.  Must've been wrong all these years.

> If it couldn't access the caller's stack, this wouldn't work:
>
> Program A: call 'B' using by content a1
> Program B: display "A's stack is at " address of a1

Could you point out to me once again where "address of" appears in ANSI
X3.23-1985 (or, for that matter ANSI X3.23-1974)?

    -Chuck Stevens


0
6/15/2004 4:31:17 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40ce2169.259513248@news.optonline.net...

> When a runtime error occurs and the program isn't handling it, doesn't
Cobol
> issue a message containing the program name and a description of the
error?

The outermost object code file name is reflected in the basic error message.
The stack history is reflected by sequence number in the log; the program
dump provides more details for separately-compiled programs.

> Isn't there a debug compiler option, which preserves names?

What's to preserve?

> Near the beginning of this thread, we discussed identifying programs in
error
> messages. I opined that the error reporting mechanism should walk back the
stack
> reporting the names of all programs leading to one of interest.

No, perhaps *you* discussed identifying programs in error messages; I don't
recall having participated in that part of the discussion.

In our case, because the fundamental architecture of the system is
stack-based to begin with, identifying the history from the point of failure
all the way through all the nested calls is handled.  Names are available
for separately-compiled programs, but COBOL programs in the Unisys MCP
environment typically have unique sequence numbers for each source line, a
nested program forms part of a compilation unit, and the sequence numbers
(together, sometimes, with the code address in the RCW) provides enough
information for the user to figure out the calling sequence that led to the
failure.  The program-id of a nested program may show up, but that's not
what people used to working with Unisys MCP COBOL85 use as a primary
debugging tool.

    -Chuck Stevens


0
6/15/2004 4:38:34 PM
"Jim Morcombe" <jim@byronics.com.au> wrote in message
news:caltrm$ft9$1@yeppa.connect.com.au...

> The PROGRAM-ID doesn't give you the version so it is useless for my
> purposes.
>
> Instead, I define a Working Storage variable (with the inovative name of
> PROG-NAME) and I use CVS commands to define the value.  This means that
when
> some idiot copies the program and doesn't change "PROGRAM-ID", I still
pick
> up the real name of the program.  It also gives me the version number as
> well.

Note that the Intrinsic Function amendment (ANSI X3.23a-1989) included
WHEN-COMPILED alongside CURRENT-DATE, both of which provide their respective
information in the same format.   This doesn't speak to a source-code
version number as such, but this function should help provide *some* sort of
unique identification for the compiled object code.

    -Chuck Stevens


0
6/15/2004 4:45:13 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> Would Unisys MCP or compiler stop this:
> [...]
> set pointer-to-a4 to address of a4
> set pointer-to-a5 to address of a5
> call 'B' using bunch-of-pointers
> [...]
> display 'I can see ' a4 ' and ' a5

You seem to assume that just because you can see some parts of the
memory of the calling program as passed by parameters in a stack frame
that therefore you would be able to access every other part of that
program.

In some cases the Working-Storage of a program is not all one
contiguous segement.  The compiler cannot split 01 levels or 77 levels
(actually it could as long as the result was logically identical), but
there is no reason to assume that any or all 01s or 77s are in the
same segment or have an address that is determinable from the address
of another, or from a code address such as the return in the stack.

In fact you may not even be able to determine the address of the stack
frame of the calling program, there is no guarantee that the run-time
has not created a new stack to pass parameters and return address to
the program while keeping the caller's stack private.
0
riplin (4127)
6/15/2004 7:01:12 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40ce3a88.265945256@news.optonline.net...

> In 40+ years Cobol programming, I've never used BY CONTENT (unless the
called
> program required it).

Using standard COBOL you couldn't do so until the introduction of the syntax
in the '85 standard, less than twenty years ago.  I never used Function
CURRENT-DATE in COBOL68, either, but I'm not sure that says anything about
whether anyone might find it useful or efficacious!

Certainly I've used the equivalents in ALGOL and Pascal many a time, and the
absence of CONTENT / VALUE from ANSI X3.23-1974 was a restriction that
"bilingual" (ALGOL/COBOL) programmers found decidedly limiting.

> >In our environment, if you use CALL <dataname> it is precisely because
you
> >expect the contents of <dataname> to change from one execution to the
next.

> I dispute that. You use it because you want to force dynamic links and the
> compiler doesn't provide a suitable option such as DYNAM, which makes all
calls
> dynamic.

If I understand your definition of "dynamic links", under the Unisys MCP
implementation of COBOL IPC to separately-compiled programs, *all* such
CALLs *are* dynamic.  Some implementations resolve such things using a
"linkage editor", as I understand it; the Unisys MCP analog to this is a
product called "BINDER".  For standard COBOL programs, the compilers produce
*executable code*, directly, period.   There is no "post-compilation" step
other than execution in such a case; BINDER is not involved in ANSI IPC
calls.  At all.  Ever.

I would guess that *both* CALL <literal> *and* CALL <dataname> generate
"dynamic calls" in this environment by your definition.  While it's true
that the first such CALL is more costly than a call to, say, a
separately-compiled procedure (which requires non-standard syntax and a
post-compilation step), once the MCP has initiated the called program and
established the linkage, the performance is essentially the same, because
the object code's essentially the same.

What's different about CALL <literal> and CALL <dataname>?  In CALL
<literal> the library template is constructed at compilation time.  In CALL
<dataname> the library template must be constructed as part of the object
code associated with the CALL itself, and destroyed immediately upon return
from the procedure.   That means an InitialPBIT for the library template on
each CALL and a BLOCKEXIT call to the MCP on each return.  That's expensive.

On Unisys MCP systems, if you want to be able to call a separately-compiled
procedure that has somehow been incorporated into your COBOL object program,
you don't do it using ANSI IPC calls, you do it through Unisys extensions
associated with calling procedures that have been incorporated using BINDER.
This syntax is somewhat similar to the IPC syntax, but not identical.  That
appears to me to be the sense of what I think you'd refer to as a "static
link" -- a link established after compilation but before execution.  You can
do it on our system, but it's not part of the ANSI IPC implementation.

> In the Unix world, late binding is the default.

In the Unisys MCP world as it relates to ANSI IPC to separately-compiled
programs, binding occurs on first CALL, period.   There is no "early" or
"late" in the ANSI IPC context, there is only the linkage established by the
MCP at execution time.  If you want "early" binding, then don't use ANSI IPC
syntax, use declaratives with USE EXTERNAL, bind the procedure in, and use
CALL <section-name>.

> Other languages discourage or outright prohibit passing large structures
on the
> stack. That's the provenance of malloc (intra-process) or Shared Memory
(across
> processes). The caller is expected to allocate a chunk and pass a pointer
to it.

What other languages -- from ALTAC to C# -- do or did and how and why they
did it is not necessarily germane to the design and history of, or
requirements for, COBOL.  Pascal allows all sorts of stuff that neither
Fortran66 nor RPG allow, and prohibits stuff that even COBOL(68) thought was
the bee's knees.  What's your point?

If your expectation is that all implementations "allocate a chunk and pass a
pointer to it", all I can say is the advice some wise friends gave me:  "an
expectation is a premeditated resentment".  The code generated for the call
may be expected *by you* to look the way you want it to and to make the data
available to the called routine in a particular fashion, but that's your
expectation, to which you are welcome, and that expectation does not
necessarily have anything to do with general reality.

Even if the implementor does decide to pass some sort of description of the
data, rather than the data itself, to the called program, there's no
guarantee that that description would bear any relationship or similarity to
what might pass for a "USAGE POINTER" data item in that implementor's
implementation (real, planned, or hypothetical) of ISO/IEC 1989:2002 COBOL,
or anything else, for that matter.

The decision as to what the code to pass a parameter BY CONTENT actually
*does* is up to the implementor; the standard offers guidelines as to what
the *overall effect* of that code should be.

    -Chuck Stevens


0
6/15/2004 7:13:53 PM
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0406151101.527e4e03@posting.google.com...

> You seem to assume that just because you can see some parts of the
> memory of the calling program as passed by parameters in a stack frame
> that therefore you would be able to access every other part of that
> program.

That is certainly not the case in Unisys MCP COBOLs.

> In some cases the Working-Storage of a program is not all one
> contiguous segement.  The compiler cannot split 01 levels or 77 levels
> (actually it could as long as the result was logically identical), but
> there is no reason to assume that any or all 01s or 77s are in the
> same segment or have an address that is determinable from the address
> of another, or from a code address such as the return in the stack.

Most definitely.

In Unisys MCP COBOL74, *each* 01-level item and *each* 77-level item has a
separate structure in memory, each allocated when it is first "touched" by
the program.  And although COBOL74 doesn't split 01-level items into
separate blocks of memory, COBOL(68) allowed the user to do so.  In COBOL74
there is no possibility of accessing beyond the bounds of an 01-level item;
the *hardware* prohibits it, whether the access is as a source or a
destination.

 In Unisys MCP COBOL85, to cut down on the stack cell requirements, data is
"pooled", so it is at least theoretically possible to get outside one's
"own" 01-level item within a program; otherwise, those "pools" are again
local to the program.  I can also demonstrate that 01-level items used as
parameters are allocated their own locations, whether passed by value or by
reference, so the same rule applies as is true for COBOL74:  just because
you can get to an 01-level record (for access or for update) from the called
program does not mean you can get to the one declared before or after it, or
any other record not passed as a parameter, in the calling program.  The
COBOL compiler *and* the hardware conspire to prevent such access from
anyone but the MCP.

    -Chuck Stevens


0
6/15/2004 7:37:36 PM
Hi:

Some comments for the old-timers who worked on the 1401 and
those never lucky enough to do so.

If you don't count wiring control panels for EAM machines,
the 1401 was the first machine I programmed and I loved it.

Someone else mentioned the programs to play music. There were
several programs which played music on the printer. The 1403
printer was quite loud and the music would sound different 
depending on the type of paper (1-part, 3-part or the special
pink printer-chain cleaning paper). You could also remove the
huge ribbon and run the programs with no paper although I
recall that the IBM CEs frowned on that. There were also programs
which played music which could be heard via a transistor radio
held next to the machine.

The original SPS assembler was a two-pass version which created
an intermediate deck so card-usage was quite spectacular. I
wrote a single-pass assembler when I was working for Independent
News Company, a large magazine distributor in New York which we used
exclusively in place of the IBM assembler. 

I also wrote a program to dynamically trace SPS programs and
one to calculate execution times. 

When FARGO (Fourteen-Oh-One Automatic Report Generating Operation?)
was introduced, I tried it but didn't like it for whatever reason.
Did it run directly from the source or was there a 'compile' step -
anyone remember? I don't remember if there was RPG for the 1401
or did that come out with the 360?

Although as mathematical as a moose, I also wrote a program to
calculate statistical t-tests which had to calculate square roots
by repetitive division or something. That one gave me lots of
headaches. I still have the listing of that one and samples of
its printed output.

I also wrote a program which allowed the 1401 to play solitaire
by itself. You shuffled the deck and the program read it and
went through the exercise all by itself and printed the final
results. Unfortunately, I don't have the listing for that one
nor samples of its output.

Finally, when the H-200 was introduced I wrote a program to
convert SPS to Easycoder which so impressed Honeywell that
they invited me to Massachusetts to see if I was good enough
to work for them. They didn't hire me so I guess I wasn't.

I still have my original working 1401 and H-200 manuals which
are covered in doodles and notes.

There are some pics of the 1401 at foodman123.com/history

Thanks

Tony Dilworth
0
motorbyte (3)
6/16/2004 12:49:43 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40ce1792.256994029@news.optonline.net...
>
>> Every platform I've worked on also uses hardware. But the operating system
>tells
>> the hardware about zones of memory and ids of authorized users.
>
>In the case of Unisys MCP, programs request memory during their initiation.
>The descriptors pointing to that memory are contained within the program's
>stack, and the only processes that can see those descriptors, or the memory
>they point to, are the programs themselves and the MCP.  Even the
>descriptors are indirect, as they reference a MCP table that contain the
>*actual* descriptors of the code segments.  The only authorized user of a
>space of memory is the process that created it, unless that process
>explicitly provides a path to it (for example, as a parameter to a task or
>library).
>
>> Typically, the
>> zones are "segments" and the user is a "process id". Thus, every called
>program
>> has access to the memory of all other programs within the process .. as
>far as
>> the hardware is concerned.
>
>Nope.  Not even close.

I'll take that as a yes. You said the hardware permits a called program to
access its parent's memory. How it gets the address was not in the question.

>> Does Unisys MCP setup user ids smaller than a 'process'?
>
>"User id's" arent germane to Unisys MCP memory management, as I see it.  You
>want memory?  You build a descriptor template; first time you touch that
>template, the MCP allocates the memory.  The descriptor to that memory is in
>*your* stack; nobody else but the MCP can see it, or the memory it
>addresses, unless you pass them the descriptor.  You go away?  The MCP
>deallocates the memory as part of the process of tearing the stack down.

All operating systems offer a way to dynamically allocate memory, but MCP's way
sounds OOish. 

>> Would Unisys MCP or compiler stop this:
>>
>> Program A:
>> 01  bunch-of-pointers.
>>      05  pointer-to-a4       pointer.
>>  ...
>
>Umm... Yeah, sure would, at "pointer-to-A4  pointer".  I think you're
>laboring under at least one mistaken assumption here.
>
>The Unisys MCP environment currently supports two dialects of COBOL:
>COBOL74, which follows ANSI X3.23-1974, and COBOL85, which follows ANSI
>X3.23-1985 plus the two amendments.
>
>USAGE POINTER was introduced in ISO/IEC 1989:2002 and is an *extension* to
>any implementation of COBOL that conforms to any *prior* standard.
>
>Thus, Unisys MCP software does not recognize the above code as meaningful
>simply because USAGE POINTER isn't in either ANSI X3.23-1974 or ANSI
>X3.23-1985, nor is it implemented as a Unisys extension to either of those
>standards in either of the Unisys MCP COBOL compilers.

So MCP doesn't prevent access, they compiler does by 'hiding' the address. 

>Unisys might consider adding USAGE POINTER to the list of 2002-standard
>features for consideration for inclusion in our ANSI-85 compiler, but before
>we could do so we would need at least one Unisys MCP user to let it be known
>to us that they found it a desirable enhancement, and we have not as yet
>been notified of such a request.  The enhancements that people have actually
>asked for have to take precedence (for example, INITIALIZE WITH FILLER has
>been requested as a means of improving performance of INITIALIZE).

I wasn't aware the 2002-standard was a Chinese menu .. nor a popular opinion
poll. I thought it was all or nothing.

>The current memory management scheme, and the security it affords our users,
>is a well-liked feature of the Unisys MCP environment that our users have
>liked since our introduction of it in the Burroughs B5000 and through its
>refinement over a number of generations of hardware design.  It is not clear
>to us that providing a mechanism whereby users could pretty much arbitrarily
>get to any memory of any component of a run unit without the most local
>"owner" of that memory having any say in the matter would represent an
>improvement in either security or functionality to our existing customers.

I concur that it wouldn't be an improvement for general applications programs,
but contend it would be for systems software charged with diagnosing a failure.
0
6/17/2004 1:32:07 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> Would Unisys MCP or compiler stop this:
>> [...]
>> set pointer-to-a4 to address of a4
>> set pointer-to-a5 to address of a5
>> call 'B' using bunch-of-pointers
>> [...]
>> display 'I can see ' a4 ' and ' a5
>
>You seem to assume that just because you can see some parts of the
>memory of the calling program as passed by parameters in a stack frame
>that therefore you would be able to access every other part of that
>program.

That was the question -- whether the hardware prevents access.

>In some cases the Working-Storage of a program is not all one
>contiguous segement.  The compiler cannot split 01 levels or 77 levels
>(actually it could as long as the result was logically identical), but
>there is no reason to assume that any or all 01s or 77s are in the
>same segment or have an address that is determinable from the address
>of another, or from a code address such as the return in the stack.
>
>In fact you may not even be able to determine the address of the stack
>frame of the calling program, there is no guarantee that the run-time
>has not created a new stack to pass parameters and return address to
>the program while keeping the caller's stack private.

So protection is afforded by 'information hiding' rather than being
hardware-based. 

A widely accepted tenet of computer security is that 'information hiding' and
'secret algorithms' are inadequate and doomed to ultimate failure. The most
robust security systems, such as DES, make their algorithms public. 

0
6/17/2004 1:32:09 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40ce3a88.265945256@news.optonline.net...
>
>> In 40+ years Cobol programming, I've never used BY CONTENT (unless the
>called
>> program required it).
>
>Certainly I've used the equivalents in ALGOL and Pascal many a time, and the
>absence of CONTENT / VALUE from ANSI X3.23-1974 was a restriction that
>"bilingual" (ALGOL/COBOL) programmers found decidedly limiting.

You offered nothing supporting or explaining WHY this was a "restriction".

>> >In our environment, if you use CALL <dataname> it is precisely because
>you
>> >expect the contents of <dataname> to change from one execution to the
>next.
>
>> I dispute that. You use it because you want to force dynamic links and the
>> compiler doesn't provide a suitable option such as DYNAM, which makes all
>calls
>> dynamic.
>
>If I understand your definition of "dynamic links", under the Unisys MCP
>implementation of COBOL IPC to separately-compiled programs, *all* such
>CALLs *are* dynamic.  Some implementations resolve such things using a
>"linkage editor", as I understand it; the Unisys MCP analog to this is a
>product called "BINDER".  For standard COBOL programs, the compilers produce
>*executable code*, directly, period.   There is no "post-compilation" step
>other than execution in such a case; BINDER is not involved in ANSI IPC
>calls.  At all.  Ever.

The Unix analog is 'ld', which is both the static 'linker' and dynamic 'binder'.
In normal default use, all binding is dynamic. Called programs are compiled to
.so, which are dynamically bound.

>I would guess that *both* CALL <literal> *and* CALL <dataname> generate
>"dynamic calls" in this environment by your definition.  While it's true
>that the first such CALL is more costly than a call to, say, a
>separately-compiled procedure (which requires non-standard syntax and a
>post-compilation step), once the MCP has initiated the called program and
>established the linkage, the performance is essentially the same, because
>the object code's essentially the same.

Unix works the same way.

>What's different about CALL <literal> and CALL <dataname>?  In CALL
><literal> the library template is constructed at compilation time.  In CALL
><dataname> the library template must be constructed as part of the object
>code associated with the CALL itself, and destroyed immediately upon return
>from the procedure.   That means an InitialPBIT for the library template on
>each CALL and a BLOCKEXIT call to the MCP on each return.  That's expensive.

If the systems software was smart, it would cache the previous CALL <dataname>.
If dataname is the same on the next CALL, as it is 99% of the time, the call
would be faster than the first.

>On Unisys MCP systems, if you want to be able to call a separately-compiled
>procedure that has somehow been incorporated into your COBOL object program,
>you don't do it using ANSI IPC calls, you do it through Unisys extensions
>associated with calling procedures that have been incorporated using BINDER.
>This syntax is somewhat similar to the IPC syntax, but not identical.  That
>appears to me to be the sense of what I think you'd refer to as a "static
>link" -- a link established after compilation but before execution.  You can
>do it on our system, but it's not part of the ANSI IPC implementation.

I can't tell from your response whether ANSI IPC favors dynamic or static links.
I would guess dynamic because that's favored by Unix, NT and most other modern
operating systems.

>> In the Unix world, late binding is the default.
>
>In the Unisys MCP world as it relates to ANSI IPC to separately-compiled
>programs, binding occurs on first CALL, period.   There is no "early" or
>"late" in the ANSI IPC context, there is only the linkage established by the
>MCP at execution time.  If you want "early" binding, then don't use ANSI IPC
>syntax, use declaratives with USE EXTERNAL, bind the procedure in, and use
>CALL <section-name>.

Ok, ANSI IPC and MCP are both late binding, despite your protestations.

>> Other languages discourage or outright prohibit passing large structures
>on the
>> stack. That's the provenance of malloc (intra-process) or Shared Memory
>(across
>> processes). The caller is expected to allocate a chunk and pass a pointer
>to it.
>
>What other languages -- from ALTAC to C# -- do or did and how and why they
>did it is not necessarily germane to the design and history of, or
>requirements for, COBOL.  Pascal allows all sorts of stuff that neither
>Fortran66 nor RPG allow, and prohibits stuff that even COBOL(68) thought was
>the bee's knees.  What's your point?

My point was modern operating systems, not obsolete languages.

>If your expectation is that all implementations "allocate a chunk and pass a
>pointer to it", all I can say is the advice some wise friends gave me:  "an
>expectation is a premeditated resentment".  The code generated for the call
>may be expected *by you* to look the way you want it to and to make the data
>available to the called routine in a particular fashion, but that's your
>expectation, to which you are welcome, and that expectation does not
>necessarily have anything to do with general reality.

Too obtruse to reply.


0
6/17/2004 1:32:10 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40ce1f14.258916099@news.optonline.net...
>
>> If a program couldn't access its own stack, it wouldn't be able to return
>from a
>> call.
>
>Silly me.  I was under the impression that the EXIT (or RETN) hardware
>operators, with a RCW on the stack placed there by the caller and invisible
>to the called routine, handled that.  Must've been wrong all these years.

Silly me. I thought the hardware afforded protection independent of language.
Now you claim the language's 'hiding' features make the stack invisible to
'application code'. 

Obviously, we'll have to deny application programmers access to languages that
generate an EXIT or RETN, especially assembly language. That would be easy on
Unisys because there is no assembly language.

Tying programmers' hands is even worse security than 'information hiding'. 

>> If it couldn't access the caller's stack, this wouldn't work:
>>
>> Program A: call 'B' using by content a1
>> Program B: display "A's stack is at " address of a1
>
>Could you point out to me once again where "address of" appears in ANSI
>X3.23-1985 (or, for that matter ANSI X3.23-1974)?

It doesn't, but it appears in IBM, Micro Focus, Fujitsu and others. In other
words, 98+% of available Cobol compilers.
0
6/17/2004 1:32:11 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40ce2169.259513248@news.optonline.net...
>

>> Near the beginning of this thread, we discussed identifying programs in
>error
>> messages. I opined that the error reporting mechanism should walk back the
>stack
>> reporting the names of all programs leading to one of interest.
>
>No, perhaps *you* discussed identifying programs in error messages; I don't
>recall having participated in that part of the discussion.

The original poster recently confirmed that my guess was correct, he wanted to
identify the offending program in an error message. 

>In our case, because the fundamental architecture of the system is
>stack-based to begin with, identifying the history from the point of failure
>all the way through all the nested calls is handled.  Names are available
>for separately-compiled programs, but COBOL programs in the Unisys MCP
>environment typically have unique sequence numbers for each source line, a
>nested program forms part of a compilation unit, and the sequence numbers
>(together, sometimes, with the code address in the RCW) provides enough
>information for the user to figure out the calling sequence that led to the
>failure.  The program-id of a nested program may show up, but that's not
>what people used to working with Unisys MCP COBOL85 use as a primary
>debugging tool.

Clear as mud. Just tell me the name of the failed program and line number on
which it failed. Given that, I can figure out why it failed. Do I ask too much?
0
6/17/2004 1:32:12 AM
robert.deletethis@wagner.net (Robert Wagner) wrote

> The original poster recently confirmed that my guess was correct, he wanted to
> identify the offending program in an error message. 

Your memory is selective or, possibly, failing:

RP >> >That is not going to show the name of any CALLed programs,
which is
RP >> >probably the point of the request.

RW >> No, he wants the name of the Main program,

If you are not trolling, then your messages are becoming increasingly
indistinguishable from that.
0
riplin (4127)
6/17/2004 5:41:18 AM
In article <40d0bf9d.22939564@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>"Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>>
>>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>>news:40ce1792.256994029@news.optonline.net...

[snip]

>>> Typically, the
>>> zones are "segments" and the user is a "process id". Thus, every called program
>>> has access to the memory of all other programs within the process .. as far as
>>> the hardware is concerned.
>>
>>Nope.  Not even close.
>
>I'll take that as a yes.

Mr Wagner, at times you've mentioned how some folks have... difficulties 
when discussing things with you.  The above might, if pondered, give an 
indication towards a reason.

DD
0
docdwarf (6044)
6/17/2004 9:17:53 AM
docdwarf@panix.com wrote:

>In article <40d0bf9d.22939564@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>"Chuck Stevens" <charles.stevens@unisys.com> wrote:
>>
>>>
>>>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>>>news:40ce1792.256994029@news.optonline.net...
>
>[snip]
>
>>>> Typically, the
>>>> zones are "segments" and the user is a "process id". Thus, every called
program
>>>> has access to the memory of all other programs within the process .. as far
as
>>>> the hardware is concerned.
>>>
>>>Nope.  Not even close.
>>
>>I'll take that as a yes.
>
>Mr Wagner, at times you've mentioned how some folks have... difficulties 
>when discussing things with you.  The above might, if pondered, give an 
>indication towards a reason.

I've learned that attempts to find common ground by clarifying or adding
information are fruitless here. They work in face-to-face conversation but not
in electronic communication. Thus, I responded to the information given. The
question was 'Does the hardware prevent a called program from accessing its
parent's memory?' Mr. Stevens' response, deleted here, said it does not.
0
6/17/2004 10:19:05 AM
In article <40d16df7.67579839@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>>In article <40d0bf9d.22939564@news.optonline.net>,
>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>>"Chuck Stevens" <charles.stevens@unisys.com> wrote:
>>>
>>>>
>>>>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>>>>news:40ce1792.256994029@news.optonline.net...
>>
>>[snip]
>>
>>>>> Typically, the
>>>>> zones are "segments" and the user is a "process id". Thus, every called program
>>>>> has access to the memory of all other programs within the process .. as far as
>>>>> the hardware is concerned.
>>>>
>>>>Nope.  Not even close.
>>>
>>>I'll take that as a yes.
>>
>>Mr Wagner, at times you've mentioned how some folks have... difficulties 
>>when discussing things with you.  The above might, if pondered, give an 
>>indication towards a reason.
>
>I've learned that attempts to find common ground by clarifying or adding
>information are fruitless here. They work in face-to-face conversation but not
>in electronic communication.

Mr Wagner, from what little experience that I have in face-to-face
conversation to respond to 'Nope.  Not even close.' with 'I'll take that
as a yes.' has a tendency to cause the negating party to respond with
something along the lines of 'I'm sorry, were your parents blood
relatives?  I said 'No'; you can take that as an apple strudel, if you so
desire, but what you are claiming to take it as is the exact opposite of
what I gave it as.'

If you are not 'attempting to find common ground by clarifying or adding 
information', Mr Wagner, then what *are* you trying to do?

DD

0
docdwarf (6044)
6/17/2004 11:31:05 AM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d0bf9d.22939564@news.optonline.net...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> >
> >"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> >news:40ce1792.256994029@news.optonline.net...
> >
> >> Every platform I've worked on also uses hardware. But the operating
system
> >tells
> >> the hardware about zones of memory and ids of authorized users.
> >
> >In the case of Unisys MCP, programs request memory during their
initiation.
> >The descriptors pointing to that memory are contained within the
program's
> >stack, and the only processes that can see those descriptors, or the
memory
> >they point to, are the programs themselves and the MCP.  Even the
> >descriptors are indirect, as they reference a MCP table that contain the
> >*actual* descriptors of the code segments.  The only authorized user of a
> >space of memory is the process that created it, unless that process
> >explicitly provides a path to it (for example, as a parameter to a task
or
> >library).
> >
> >> Typically, the
> >> zones are "segments" and the user is a "process id". Thus, every called
> >program
> >> has access to the memory of all other programs within the process .. as
> >far as
> >> the hardware is concerned.
> >
> >Nope.  Not even close.
>
> I'll take that as a yes. You said the hardware permits a called program to
> access its parent's memory. How it gets the address was not in the
question.

No, you misunderstood.  The hardware permits a called (separately-compiled)
program to access the parameters that the caller passed to it, and data
items that are declared EXTERNAL.  The hardware permits a called (nested)
program to access the parameters that the caller passed to it, variables
declared GLOBAL in higher nesting levels, and data items that are declared
EXTERNAL.

> All operating systems offer a way to dynamically allocate memory, but
MCP's way
> sounds OOish.

More like OO sounds MCP-ish.  This mechanism has been in daily use since the
introduction of the Burroughs B5000 in 1959.  The hardware was originally
designed around the semantics of ALGOL, and implements a "just-in-time"
approach to memory management in which memory isn't allocated until it's
actually referenced for the first time, and the resources associated with a
procedure disappear automatically or are disappeared by the oerating system
when the procedure is executed unless explicit steps are taken to do
otherwise.   I'm reasonably certain that Object Orientation as a software
development regimen rather postdates the introduction of ALGOL.

> So MCP doesn't prevent access, they compiler does by 'hiding' the address.

No, the compiler doesn't "hide" the address; neither the compiler nor the
program ever has reason to *know* the address.  All it has is a descriptor,
and if it doesn't explicitly pass the descriptor to that memory space to
somebody else, that somebody else can't see it.

> I wasn't aware the 2002-standard was a Chinese menu .. nor a popular
opinion
> poll. I thought it was all or nothing.

The 2002 standard is indeed all or nothing if the compiler you are
implementing claims to be conformant with the 2002 standard.  Many
implementations take features of a standard and incorporate them *as
extensions* to compilers conformant with *previous* standards.  In this
case, I was discussing the efficacy of *extending* a compiler compliant with
ANSI X3.23-1985 to include the USAGE POINTER as described in a *later*
standard.  We did the same when the Indexed I/O module was standardized in
the '74 standard -- we incorporated the same syntax into our COBOL(68)
compiler.

> I concur that it wouldn't be an improvement for general applications
programs,
> but contend it would be for systems software charged with diagnosing a
failure.

Well, yeah ... the MCP, which has access to the entire system because it has
special privileges, decodes this information on behalf of the diagnostic
software.  The problem with that is ... ?

    -Chuck Stevens


0
6/17/2004 4:22:37 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d0da71.29808196@news.optonline.net...

> So protection is afforded by 'information hiding' rather than being
> hardware-based.

No, that's not it.  Memory is only accessible through descriptors and
according to the hardware scope rules of execution level.  Nothing but the
ASD initialization process deals with "real" memory addresses.  The ASD
table is not actively "hidden"; the scope rules of the hardware simply mean
that it's not visible to anybody but the MCP.  There is no hardware
mechanism to access memory spaces except through descriptors, and unless the
user has visibility to that descriptor (through scope rules or through
direct means) the user can't see the memory.  A user application program
cannot explicitly *manipulate* its own stack, much less any other, nor has
it any means to deal with raw memory addresses.

There are lots of discussions on the web about the architecture of the
Burroughs B5000 and its evolution into the Burroughs B6700; they'd be a much
better source of how this all works than I.

    -Chuck Stevens


0
6/17/2004 4:37:12 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d0e65d.32860852@news.optonline.net...

> Silly me. I thought the hardware afforded protection independent of
language.
> Now you claim the language's 'hiding' features make the stack invisible to
> 'application code'.

EXIT, RETN, and the setting of the RCW on ENTR are independent of language.
The hardware scope rules and the D registers are independent of language.

> Obviously, we'll have to deny application programmers access to languages
that
> generate an EXIT or RETN, especially assembly language. That would be easy
on
> Unisys because there is no assembly language.

Application programs cause the compilers to generate EXIT, RETN, MKST and
ENTR all the time.  What application programs cannot do is make use of raw
memory addresses, access other programs' stacks, or even access their own
stack as if it were data and "leapfrog" from there into a stack owned by
another process.

Moreover, precisely because memory *is* dynamically allocated, there is no
guarantee from one access to the next that a given piece of information will
be in the same physical location, so *raw* memory addresses are meaningless.


If you could decode a RCW or access the stack directly as if it were a
memory space, what would you do with that information, given that even that
space is protected by the scope rules?

> Tying programmers' hands is even worse security than 'information hiding'.

Users are welcome to write their own compilers.  However, it is the compiler
author's responsibility to ensure that the code it generates is compatible
with all currently-supported machines, and there is no guarantee that a
given convention or approach to a process will survive for any period of
time. And if a user elects to change one of our compilers, any problem they
report in that language must be reproduced by them using, and reported
against, a released compiler; we do not support software that has been
locally patched.

Why is it necessary for a user program to have access to another process'
memory space without that process' direct involvement in the access?   So
far as I know, very few, if any, actual *users* of this architecture have
found the mechanisms of memory management and the stack architecture
*restrictive*.

> > It doesn't, but it appears in IBM, Micro Focus, Fujitsu and others. In
other
> words, 98+% of available Cobol compilers.

Are we using the adolescent argument "But MOM!!!!  Everybody who's *ANYbody*
has one!", eh?   Or are we back to "What is or is not standards-compliant
COBOL has nothing to do with what the standards say, only with what I
perceive to be Admirable Practice!"?

Again, any Unisys MCP customer is welcome to file a New Feature Suggestion
against COBOL85 to request USAGE POINTER in that dialect.  I daresay IBM,
Micro Focus, Fujitsu and others have incorporated it because *their*
customers have found it to be a useful feature.  As far as ANSI X3.23-1985
COBOL goes, it is an extension, and in our case there has been so little
demand for this extension from our users -- that is to say, none -- and
there has been so little evidence that this feature would be of particular
benefit in the Unisys MCP environment -- none that I've seen so far, and a
lot of security risks -- that it isn't even on the list of such features for
consideration at this time.

    -Chuck Stevens


0
6/17/2004 5:15:17 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d0eaff.34046405@news.optonline.net...

> Clear as mud. Just tell me the name of the failed program and line number
on
> which it failed. Given that, I can figure out why it failed. Do I ask too
much?

Unisys MCP COBOLs don't deal in *line* numbers, they deal in *sequence*
numbers (remember columns 1-6?).

Given that, for a system consisting exclusively of separately-compiled COBOL
programs, the program dump provides the object code file name of the
compilation unit and the sequence number and actual object code instruction
address of the failure for each level in the PERFORM and CALL stack history.

For a program that's nested, the sequence numbers identify the location of
the failure, the call history within the compilation unit, the object code
file name of the compilation unit, and the actual object code instruction
address for of the failure for each level in the PERFORM and CALL stack
history.

The sequence number history of any failure is also by default provided in
the abnormal-termination message, though you may actually have to glance at
the program dump to find out which sequence number goes with which program.

Have you *demonstrated* that you need more information than the MCP has
already provided *you*?   Or is it just "I want to do it *my* way, not the
way the system allows me to do it!"?

    -Chuck Stevens


0
6/17/2004 5:22:08 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> >>>> Typically, the
> >>>> zones are "segments" and the user is a "process id". Thus, every called
>  program
> >>>> has access to the memory of all other programs within the process .. as far
>  as
> >>>> the hardware is concerned.
> >>>
> >>>Nope.  Not even close.
> >>
> >>I'll take that as a yes.
> >
> >Mr Wagner, at times you've mentioned how some folks have... difficulties 
> >when discussing things with you.  The above might, if pondered, give an 
> >indication towards a reason.
 
> I've learned that attempts to find common ground by clarifying or adding
> information are fruitless here. 

The only way that common ground can be found is by _learning_ what the
other party's experience and knowledge is.  When there are things that
are outside your experience and knowledge then you 'adding
information' just doesn't work, it is just contradicting what they
know to be true (and know that you don't know).

> They work in face-to-face conversation but not
> in electronic communication. Thus, I responded to the information given. The
> question was 'Does the hardware prevent a called program from accessing its
> parent's memory?' Mr. Stevens' response, deleted here, said it does not.

You fail to distinguish between 'accessing the passed parameters from
the parent' and your assertion about: "access to the memory of all
other programs within the process".

Just because the hardware allows a small amount of specific access
does not mean that therfore it allows complete and unrestricted
access.  An issue here is addressability.  A CALLed program is passed
the address of some specific areas as parameters.  You may be used to
being able to calculate the addresses of other areas from that, but
that is not necessarily a valid assumption in other architectures.

Even in a lowly 80286 it is possible to create a new descriptor that
allows access to an area of data but which bears no relationship to
descriptors which access other data.  For example on doing a CALL the
run-time (or generated code) could create a descriptor for each
parameter and pass pointers referenceing those.  This would give free
access to the parent(s)' data areas being passed by reference while
enforcing hardware restrictions beyond those boundries.
0
riplin (4127)
6/17/2004 7:38:21 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d0ddc7.30662731@news.optonline.net...

I wrote:

> >Certainly I've used the equivalents in ALGOL and Pascal many a time, and
the
> >absence of CONTENT / VALUE from ANSI X3.23-1974 was a restriction that
> >"bilingual" (ALGOL/COBOL) programmers found decidedly limiting.

Robert responded:

> You offered nothing supporting or explaining WHY this was a "restriction".

I thought that was self-explanatory.  ANSI X3.23-1974 requires parameters to
be passed by reference and requires that the called program be able to
modify those parameters as they exist in the calling program.

By contrast, ALGOL allows VALUE, NAME or REFERENCE parameters.  VALUE is
conventional and preferred; the others allow access to the caller's
instantiations of the data.

The inability to CALL an ALGOL program that has a VALUE parameter from
COBOL74 stems from the fact that ANSI X3.23 requires that COBOL74 programs
be able to modify the caller's instantiation, and the ALGOL VALUE syntax
prevents that.  The result is a failure when the MCP attempts to link the
library to the program because the parameter descriptions in the two library
templates are incompatible.

> If the systems software was smart, it would cache the previous CALL
<dataname>.

Well, it might.  But it's not clear that it's smart to do so.

> If dataname is the same on the next CALL, as it is 99% of the time, the
call
> would be faster than the first.

Where on earth did you get *that* statistic?   The whole point of CALL
<dataname> is that the programmer *doesn't* know what the name of the called
program is going to be until he gets to the CALL statement!    If 99% of the
time it's the same, why not use CALL <literal>?  Or even CHANGE ATTRIBUTE
TITLE OF <libraryname> TO <newlibname> CALL <newlibname>?   Both are a whole
lot faster than CALL <dataname>!

> I can't tell from your response whether ANSI IPC favors dynamic or static
links.
> I would guess dynamic because that's favored by Unix, NT and most other
modern
> operating systems.

I'm not sure the standard cares, but I would suggest that the Unisys MCP
implementation, which requires no post-compile pre-execution steps and uses
dynamic links, matches both the spirit and the letter of the ANSI spec in
this fashion.   A compiled COBOL74 program is ready to execute in our
environment as soon as the compiler's locked the file in the disk directory,
whether that execution is "manual" or as a called program in a COBOL74 run
unit.   That's the convention on Unisys MCP systems, where a "linking"
process is very much the exception and is always carefully considered in
application design.  On systems where a "link" step is usual or even
mandatory, it wouldn't be surprising for ANSI IPC handling to include such a
step, but that's not the case on Unisys MCP systems, and a bind (or rebind)
during every compilation would be regarded by most Unisys MCP users as
extremely tedious and contrary to their expectations.

> Ok, ANSI IPC and MCP are both late binding, despite your protestations.

ANSI COBOL IPC *as such* does not state anything about "binding", much less
what time it should occur.   But Unisys believes their users expect programs
to be ready for use when the *compiler* is finished producing them, which
means that the only time binding occurs for ANSI IPC calls (and for "library
linkages") in the MCP environment is during execution, at the first CALL to
the program.

What you call "early binding" is something entirely different -- external
subprograms -- and MCP supports that too, but not using ANSI IPC syntax or
mechanisms.

The distinction "early" vs. "late" may apply to Unix.  It may apply to IBM.
But it is simply not meaningful in the Unisys MCP environment when it comes
to a *single* CALL mechanism.  If you want called routines to be linked
*before* execution -- in which case they form a single object code file with
the caller -- then you specify USE EXTERNAL and CALL <section-name>.  That,
in MCP terminology, is called "using bound procedures".  Many do that.  If
you want the ability to replace the called program on the fly, then you can
use ANSI IPC syntax or minor extensions to it.  That, in MCP terminology, is
called "using library calls".

> My point was modern operating systems, not obsolete languages.

What COBOL does is what COBOL is defined to do.  The COBOL standards do not
specify the manner in which a CONTENT parameter is passed, only that the
called program has access to it.  That some languages have explicit "heap
manipulation" syntax and others have explicit memory allocation syntax is
all well and good, but it's not clear to me that the lack of such features
in a given language renders that language obsolete!

I might even be inclined to agree with you in this:  Any operating
environment that passes a parameter by reference to a called routine does so
using a descriptor occupying a single 48-bit word with tag bits containing
5, visible only to the process in which it was declared and to the caller,
pointing to an entry in the ASD table maintained by the operating
environment (and visible only to the operating environment and the hardware)
that describes the actual memory space.  Any operating environment that
passes a numeric parameter by value to a called routine does so by placing
the numeric value on the stack where it is visible to the called routine.
Any operating environment that doesn't handle calling processes in this way
is hopelessly obsolete and richly deserves to be cast onto the dustbin of
history!     ;-)    But that's only my opinion, not a statement ex cathedra
papae!

> Too obtruse to reply.

Hey, you're the one that has decided in his infinite wisdom, how *all*
environments ought to work! Passing some sort of something that might be
described as a pointer *might* be a reasonable approach in general, but I
can certainly come up with exceptions and environments in which other
approaches could be preferable!

    -Chuck Stevens
>
>


0
6/17/2004 7:44:05 PM
docdwarf@panix.com wrote:

>In article <40d16df7.67579839@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>docdwarf@panix.com wrote:
>>
>>>In article <40d0bf9d.22939564@news.optonline.net>,
>>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>>>"Chuck Stevens" <charles.stevens@unisys.com> wrote:
>>>>
>>>>>
>>>>>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>>>>>news:40ce1792.256994029@news.optonline.net...
>>>
>>>[snip]
>>>
>>>>>> Typically, the
>>>>>> zones are "segments" and the user is a "process id". Thus, every called
program
>>>>>> has access to the memory of all other programs within the process .. as
far as
>>>>>> the hardware is concerned.
>>>>>
>>>>>Nope.  Not even close.
>>>>
>>>>I'll take that as a yes.
>>>
>>>Mr Wagner, at times you've mentioned how some folks have... difficulties 
>>>when discussing things with you.  The above might, if pondered, give an 
>>>indication towards a reason.
>>
>>I've learned that attempts to find common ground by clarifying or adding
>>information are fruitless here. They work in face-to-face conversation but not
>>in electronic communication.
>
>Mr Wagner, from what little experience that I have in face-to-face
>conversation to respond to 'Nope.  Not even close.' with 'I'll take that
>as a yes.' has a tendency to cause the negating party to respond with
>something along the lines of 'I'm sorry, were your parents blood
>relatives?  I said 'No'; you can take that as an apple strudel, if you so
>desire, but what you are claiming to take it as is the exact opposite of
>what I gave it as.'
>
>If you are not 'attempting to find common ground by clarifying or adding 
>information', Mr Wagner, then what *are* you trying to do?

My reason for being here is to promote Cobol as a Real Programming Language
rather than the travesty that mainframers have turned it into.
0
6/18/2004 12:30:27 AM
In article <40d23662.118894516@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>>In article <40d16df7.67579839@news.optonline.net>,
>>Robert Wagner <robert.deletethis@wagner.net> wrote:

[snip]

>>>I've learned that attempts to find common ground by clarifying or adding
>>>information are fruitless here. They work in face-to-face conversation but not
>>>in electronic communication.
>>
>>Mr Wagner, from what little experience that I have in face-to-face
>>conversation to respond to 'Nope.  Not even close.' with 'I'll take that
>>as a yes.' has a tendency to cause the negating party to respond with
>>something along the lines of 'I'm sorry, were your parents blood
>>relatives?  I said 'No'; you can take that as an apple strudel, if you so
>>desire, but what you are claiming to take it as is the exact opposite of
>>what I gave it as.'
>>
>>If you are not 'attempting to find common ground by clarifying or adding 
>>information', Mr Wagner, then what *are* you trying to do?
>
>My reason for being here is to promote Cobol as a Real Programming Language
>rather than the travesty that mainframers have turned it into.

I see... and you expect to do this without 'attempting to find common 
ground by clarifying or adding information'.

What's left, one might wonder... cunningly-wrought insults or sheer Force 
of Personality?

DD

0
docdwarf (6044)
6/18/2004 1:30:54 AM
robert.deletethis@wagner.net (Robert Wagner) wrote

> It doesn't, but it appears in IBM, Micro Focus, Fujitsu and others. In other
> words, 98+% of available Cobol compilers.

Let me see now.  "Available Cobol compilers", here are some:

    Microfocus
    Liant
    AcuCobol
    IBM
    Fujitsu
    Kobol
    OpenCobol
    HP Cobol
    Compaq NonStop

The one you mentioned seems to be about 33% of this list.

Perhaps you meant something else, again.
0
riplin (4127)
6/18/2004 2:44:29 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote 

> > If dataname is the same on the next CALL, as it is 99% of the time, the
>  call
> > would be faster than the first.
> 
> Where on earth did you get *that* statistic?   The whole point of CALL
> <dataname> is that the programmer *doesn't* know what the name of the called
> program is going to be until he gets to the CALL statement!    If 99% of the
> time it's the same, why not use CALL <literal>?  Or even CHANGE ATTRIBUTE
> TITLE OF <libraryname> TO <newlibname> CALL <newlibname>?   Both are a whole
> lot faster than CALL <dataname>!

I have several systems where the 'main' program is a simple loop which
is roughly:

       MOVE Logon-Program   TO Program-Name
       MOVE Menu-Program    TO Next-Program
       PERFORM 
           UNTIL Program-Name = "FINISH"

           CALL Program-Name
               USING <interface block that includes Program-Name
                         and Next-Program>
               ON EXCEPTION ...
           END-CALL
           CANCEL Program-Name
           MOVE Next-Program    TO Program-Name
           MOVE Menu-Program    TO Next-Program
       END-PERFORM

Any program can change Next-Program to allow the user or any program
to control where the system goes without having to return to the menu,
which is just the default action.

The chances of the same program being CALLed twice in a row is very
small.
0
riplin (4127)
6/18/2004 6:06:14 AM
robert.deletethis@wagner.net (Robert Wagner) wrote

> >If you are not 'attempting to find common ground by clarifying or adding 
> >information', Mr Wagner, then what *are* you trying to do?
> 
> My reason for being here is to promote Cobol as a Real Programming Language
> rather than the travesty that mainframers have turned it into.

I'd be interested in what way you think that mainframers have 'turned
it into a travesty'.  It may well be that some mainframers are still
using it in much the same way that it has been used for 25 or even 45
years, but this has _retained_ its origins and not changed it into
something completely different.

Cobol always has been a 'real language' but trying to turn it into C
or a second rate Java is a mistake (IMHO). Its major strength is that
code has continued to be used and reused for decades and can continue
to do so where it still meets the business needs.

C++, Java, C#, VB programmers are irrelevant to Cobol, they will use
what is the current trend and then move on to the next.  They will
never be interested in Cobol, and if they became so they would soon
move on to something else anyway.
0
riplin (4127)
6/18/2004 6:42:38 AM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d16df7.67579839@news.optonline.net...

> I've learned that attempts to find common ground by clarifying or adding
> information are fruitless here. They work in face-to-face conversation but
not
> in electronic communication. Thus, I responded to the information given.
The
> question was 'Does the hardware prevent a called program from accessing
its
> parent's memory?'
>
>Mr. Stevens' response, deleted here, said it does not.

No, Mr. Wagner, that's not correct, that wasn't what I responded to.

You asserted:

<<Typically, the zones are "segments" and the user is a "process id". Thus,
every called
program has access to the memory of all other programs within the process ..
as
far as  the hardware is concerned >>

I cited that set of assertions and the conclusion you drew from it, and
replied:

<<Nope.  Not even close.>>

Your assertions, as well as your conclusion, is what I was addressing.  Both
initial assertions are incorrect on Unisys MCP systems, and the conclusion
does not follow from the assertions even if the assertions were general
truths.

I quoted that particular text immediately before my response precisely
because that's what I was responding to.

You may certainly take "Nope.  Not even close."  as a "Yes" if you like.
You make take it as a "tuesday" or a  "Chevrolet" or as any word in any part
of speech you wish, but if you take it as anything but "Nope.  Not even
close."  you're living in a castle in the air that you built.

On Unisys MCP systems, a called *separately-compiled* program has access,
besides to its local data, only to those data items declared EXTERNAL in the
caller or passed to the called program as parameters by the caller.  A
called *nested* program in that environment has access to those categories,
plus any data items declared GLOBAL in a "shallower" nesting level within
the compilation unit.

Because the contents of a memory space are not visible or addressible unless
a descriptor pointing to that memory space is visible, and because each
memory space has its own descriptor, a called program does *not* have access
to any memory space owned by the caller unless the caller explicitly makes
it visible (as EXTERNAL, or as a parameter, or as GLOBAL in the case of
nested programs) by having a descriptor individually, and explicitly,
provided to it.

Of these, the only one that's a *software* convention is access to a
shallower nesting level's non-GLOBAL data space by a nested program, and the
compiler knows which stack cells are allocated for local data for shallower
levels.  Access to such item is not allowed simply because the *compiler*
"forgets" at the deeper nesting level, what the stack cells associated with
local data at shallower nesting levels are used for, remembering only that
they're in use elsewhere and skipping them during allocation of cells at the
deper nesting level.  Since the descriptor of a shallower program's local
data isn't in the nested program's stack space, the nested program has no
access to it.

You may want to think that a called program can get to, for example, all of
its caller's WORKING-STORAGE if it has access to any of it, because
everybody knows that a program's data space is  monolithic and contiguous in
all implementations.  And there may be implementations and environments in
which that's the case.   But that isn't the way either the hardware or the
software works on Unisys MCP systems.

Allocation of memory space is secondary to having an untouched data
descriptor to begin with.  The only way to gain access to a preexisting
memory space -- which means that the memory space has been touched -- is to
have access to the already-built descriptor that points to it.  If the
compiler doesn't provide that access (through EXTERNAL, through GLOBAL, or
as a parameter), the called process doesn't get access to the memory.
Having access to another memory space in the memory space in the same
calling program is absolutely irrelevant, because that memory space is
governed by a *different* descriptor.    The hardware *design* prevents
access to other portions of the caller's memory by the simple expedient of
"you can't get there from here".  Neither the hardware nor the software
*actively prevents* anything; it's the *access* that has to be granted
*explicitly* to begin with.

    -Chuck Stevens


0
6/18/2004 5:39:42 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> >If you are not 'attempting to find common ground by clarifying or adding 
>> >information', Mr Wagner, then what *are* you trying to do?
>> 
>> My reason for being here is to promote Cobol as a Real Programming Language
>> rather than the travesty that mainframers have turned it into.
>
>I'd be interested in what way you think that mainframers have 'turned
>it into a travesty'.  It may well be that some mainframers are still
>using it in much the same way that it has been used for 25 or even 45
>years, but this has _retained_ its origins and not changed it into
>something completely different.

But it has, at least once. When Structured Programming appeared in the late
'60s, we already had a substantial body of work based on GO TO. Had this forum
existed then, I can picture heated debates between the Old Guard defending GO TO
and bright-eyed 'progressives' decrying GO TO. For once, the good guys won,
although we still see backguard pockets of resistance some 35 years later. 

What happened to that spirit of improvement? OO Cobol is roughly comparable to
Structured Programming back then. Why has it been ignored by the Cobol
community? Because we're now aged 50-60 rather than 20-30? Or is it because
mainframe shops have Programming Standards prohibiting progress? (pardon
alliteration)

>Cobol always has been a 'real language' but trying to turn it into C
>or a second rate Java is a mistake (IMHO). Its major strength is that
>code has continued to be used and reused for decades and can continue
>to do so where it still meets the business needs.

I don't think pointers make Cobol C-like; I think they make it equally capable.
Before compilers 'extended the Standard' to support pointers, we did it with
calls to assembly language programs that modified 'BLL cells'. Pointers are an
essential tool. Their absence in Java and C# is a serious limitation to those
cultures.

There is merit in resistance to change. It goes to the difference between
evolution and revolution. See for example Alexander's "Notes on the Synthesis of
Form", published by Harvard Press.The book deals with design of a tea kettle,
but the principles involved embrace all architecture and computer systems.

FWIW, I have a tea kettle that boils water four times faster than microwave, on
an ordinary gas stove.

Resisting progress is one thing, arguably good; ignoring and rejecting it is
Bad. Cobol's strength doesn't come from immutability, it comes from
extensibility. OO Cobol is a good demonstration of the language's vibrancy ..
and its adherents' resistance to progress.

>C++, Java, C#, VB programmers are irrelevant to Cobol, they will use
>what is the current trend and then move on to the next.  They will
>never be interested in Cobol, and if they became so they would soon
>move on to something else anyway.

I agree -- diletantes will not stick with Cobol. Good riddance. 

0
6/19/2004 12:37:19 AM
docdwarf@panix.com wrote:

>In article <40d23662.118894516@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>docdwarf@panix.com wrote:
>>
>>>In article <40d16df7.67579839@news.optonline.net>,
>>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>
>[snip]
>
>>>>I've learned that attempts to find common ground by clarifying or adding
>>>>information are fruitless here. They work in face-to-face conversation but
not
>>>>in electronic communication.
>>>
>>>Mr Wagner, from what little experience that I have in face-to-face
>>>conversation to respond to 'Nope.  Not even close.' with 'I'll take that
>>>as a yes.' has a tendency to cause the negating party to respond with
>>>something along the lines of 'I'm sorry, were your parents blood
>>>relatives?  I said 'No'; you can take that as an apple strudel, if you so
>>>desire, but what you are claiming to take it as is the exact opposite of
>>>what I gave it as.'
>>>
>>>If you are not 'attempting to find common ground by clarifying or adding 
>>>information', Mr Wagner, then what *are* you trying to do?
>>
>>My reason for being here is to promote Cobol as a Real Programming Language
>>rather than the travesty that mainframers have turned it into.
>
>I see... and you expect to do this without 'attempting to find common 
>ground by clarifying or adding information'.
>
>What's left, one might wonder... cunningly-wrought insults or sheer Force 
>of Personality?

...Demos of well-written code using Advanced Features such as multithreading and
OO.
...Rebuttal against the forces of darkness, so readers know there is an
alternative.

PECD uses Force of Personality very effictively, I think. The rest of us code
crankers must rely on facts, code samples or emotion to be Validated.
0
6/19/2004 12:37:20 AM
Robert Wagner wrote:
> "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> 
> 
>>"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
>>news:cag4bh$j8c$1@news.eusc.inter.net...
>>
>> snip >>>


> Let's call this hypothetical machine CADET, for Can't Add, Doesn't Even Try. It
> could do arithmetic by table lookup using two indicies. The RCA 301 actually
> worked that way. If someone stepped on the arithmetic table at a fixed address
> in low memory, answers came out wrong until you rebooted the machine. 
> 
Where were the add tables?  I know that the print translate table was in 
high memory (19900-63 as I recall) because we had a program space fill 
the table causing the Analex (sp?) drum printer to print and blow a 
fuse.  Translate instructions used tables that started at 00 locations.
>> rest snipped



0
cfmtech (125)
6/19/2004 12:55:49 AM
In article <40d38256.203887241@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>>In article <40d23662.118894516@news.optonline.net>,
>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>>docdwarf@panix.com wrote:
>>>
>>>>In article <40d16df7.67579839@news.optonline.net>,
>>>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>
>>[snip]
>>
>>>>>I've learned that attempts to find common ground by clarifying or adding
>>>>>information are fruitless here. They work in face-to-face conversation but
>not
>>>>>in electronic communication.
>>>>
>>>>Mr Wagner, from what little experience that I have in face-to-face
>>>>conversation to respond to 'Nope.  Not even close.' with 'I'll take that
>>>>as a yes.' has a tendency to cause the negating party to respond with
>>>>something along the lines of 'I'm sorry, were your parents blood
>>>>relatives?  I said 'No'; you can take that as an apple strudel, if you so
>>>>desire, but what you are claiming to take it as is the exact opposite of
>>>>what I gave it as.'
>>>>
>>>>If you are not 'attempting to find common ground by clarifying or adding 
>>>>information', Mr Wagner, then what *are* you trying to do?
>>>
>>>My reason for being here is to promote Cobol as a Real Programming Language
>>>rather than the travesty that mainframers have turned it into.
>>
>>I see... and you expect to do this without 'attempting to find common 
>>ground by clarifying or adding information'.
>>
>>What's left, one might wonder... cunningly-wrought insults or sheer Force 
>>of Personality?
>
>..Demos of well-written code using Advanced Features such as multithreading and
>OO.

That would appear to constitute 'adding information', Mr Wagner, and you 
have already admitted that you are not trying to do this.

>..Rebuttal against the forces of darkness, so readers know there is an
>alternative.

Those rebuttals, however, must be devoid of 'attempting to find ground by 
clarifying or adding information'... hence my question still stands.

>
>PECD uses Force of Personality very effictively, I think. The rest of us code
>crankers must rely on facts, code samples or emotion to be Validated.

What someone else does, Mr Wagner, is their own concern... and 'facts 
(and) code samples', in that they are attempts to communicate knowledge or 
intelligence, are 'information', which you said... oh, by now you should 
be getting the gist of this.

DD

0
docdwarf (6044)
6/19/2004 1:39:36 AM
robert.deletethis@wagner.net (Robert Wagner) wrote

> But it has, at least once. When Structured Programming appeared in the late
> '60s, we already had a substantial body of work based on GO TO. Had this forum
> existed then, I can picture heated debates between the Old Guard defending GO TO
> and bright-eyed 'progressives' decrying GO TO. For once, the good guys won,
> although we still see backguard pockets of resistance some 35 years later. 

There is nothing in 'structured programming' that prohibits the use of
GO TO, though it may restrict the scope of its use.

Personally I find that I never need GO TO and have a style in which it
can not be useful.
 
> What happened to that spirit of improvement? OO Cobol is roughly comparable to
> Structured Programming back then. Why has it been ignored by the Cobol
> community? Because we're now aged 50-60 rather than 20-30? Or is it because
> mainframe shops have Programming Standards prohibiting progress? (pardon
> alliteration)

No. That is not the case.  Much of the OO features in C++, for
example, are to solve the problems of the C language.  In many cases
Cobol never had those problems.  Now OO does have some really useful
functionality, in many cases the types of applications that Cobol is
commonly used for does not need this functionality.  In other cases,
such as in your demonstration, the OO is not only inappropriate but is
far slower when compared to conventional solutions.

If you had learnt other languages well enough then you would have seen
where the OO solutions were required and could evaluate whether these
could be applied to Cobol.

> I don't think pointers make Cobol C-like; I think they make it equally capable.

One of the reasons that C++ of the 80s is a step up from C is that it
replaced pointers with objects.  Memory management was contained
within the objects.  The reason that Java  of the 90s is a step up
from C++ is that the objects themselves are garbage collected.  These
two steps removed all the manual grubbiness from pointers that were
the bane of C.

Cobol never had this pointer problem because the applications
generally did not require them.  C used them to build trees, lists and
other complex structures.  Cobol just put this data into files and
arrays.

Introducing pointers to Cobol in the way you want them to be used just
takes the language back to the C of the 70s.  There are reasons for
wanting pointers, such as interacting with the OS, but these should be
as restrained as possible. They are not an 'advanced feature', they
are taught in a 'C advanced course', because the programmer needs to
be better than a beginner.

> Before compilers 'extended the Standard' to support pointers, we did it with
> calls to assembly language programs that modified 'BLL cells'. Pointers are an
> essential tool. Their absence in Java and C# is a serious limitation to those
> cultures.

You simply show that you never went through the learning process that
led to the reason why they are not in Java or C#, and what has
replaced the need for them.

While trivial programs, such as your demos, may make pointer
management seem easy this is not the case in any substantial program. 
C++ programmers who wrote large C applications with pointers know why
C++ introduced objects.  Java programmers who did large systems in C++
know why garbage collection was added and pointers were removed.

You obviously did not go through that and so promote starting at step
1 in the 70s.

> Resisting progress is one thing, arguably good; ignoring and rejecting it is
> Bad. Cobol's strength doesn't come from immutability, it comes from
> extensibility. OO Cobol is a good demonstration of the language's vibrancy ..
> and its adherents' resistance to progress.

Pointers are _not_ progress.  Your demo of doing anappropriate things
with collection classes and then concluding they are slow and poor is
not progress.  If you want progress then do something _better_.

> I agree -- diletantes will not stick with Cobol. Good riddance.

So why do you care what they say about Cobol ?
0
riplin (4127)
6/19/2004 6:49:46 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d0bf9d.22939564@news.optonline.net...
>> "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>>
>> >
>> >"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>> >news:40ce1792.256994029@news.optonline.net...
>> >
>> >> Every platform I've worked on also uses hardware. But the operating
>system
>> >tells
>> >> the hardware about zones of memory and ids of authorized users.
>> >
>> >In the case of Unisys MCP, programs request memory during their
>initiation.
>> >The descriptors pointing to that memory are contained within the
>program's
>> >stack, and the only processes that can see those descriptors, or the
>memory
>> >they point to, are the programs themselves and the MCP.  Even the
>> >descriptors are indirect, as they reference a MCP table that contain the
>> >*actual* descriptors of the code segments.  The only authorized user of a
>> >space of memory is the process that created it, unless that process
>> >explicitly provides a path to it (for example, as a parameter to a task
>or
>> >library).
>> >
>> >> Typically, the
>> >> zones are "segments" and the user is a "process id". Thus, every called
>> >program
>> >> has access to the memory of all other programs within the process .. as
>> >far as
>> >> the hardware is concerned.
>> >
>> >Nope.  Not even close.
>>
>> I'll take that as a yes. You said the hardware permits a called program to
>> access its parent's memory. How it gets the address was not in the
>question.
>
>No, you misunderstood.  The hardware permits a called (separately-compiled)
>program to access the parameters that the caller passed to it, and data
>items that are declared EXTERNAL.  The hardware permits a called (nested)
>program to access the parameters that the caller passed to it, variables
>declared GLOBAL in higher nesting levels, and data items that are declared
>EXTERNAL.

In the end, the only real protection is that provided by hardware. Descriptors
can be forged -- copied from a parent program's stack. 

>> I concur that it wouldn't be an improvement for general applications
>programs,
>> but contend it would be for systems software charged with diagnosing a
>failure.
>
>Well, yeah ... the MCP, which has access to the entire system because it has
>special privileges, decodes this information on behalf of the diagnostic
>software.  The problem with that is ... ?

Third-party software might be superior. IBM mainframes have a long history of
third-party abend analyzers that work better than IBM's. In my limited
experience with Burroughs medium systems (B3500/4700), I found it necessary to
improve the MCP's communication module to make the first Telechek system work,
and to rewrite the print spooler from scratch to improve its functionality. Many
shops switched to my print spooler.  A cursory Web search shows third-party
performance monitors and memory optimizers for the current Unisys MCP. 

BMC, the first billion dollar software company, was founded in the late '60s to
provide services MUCH better than IBM's offerings. I recall meeting with them
and being blown away by their technical skill.

Third-party software must sometimes resort to 'hacking' because the hardware
manufacturer arrogantly assumes its way is the only way.
0
6/19/2004 8:59:39 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d0ddc7.30662731@news.optonline.net...

>> If dataname is the same on the next CALL, as it is 99% of the time, the
>call
>> would be faster than the first.
>
>Where on earth did you get *that* statistic?   The whole point of CALL
><dataname> is that the programmer *doesn't* know what the name of the called
>program is going to be until he gets to the CALL statement!    If 99% of the
>time it's the same, why not use CALL <literal>?  

Before compiler options such as DYNAM, we were forced to write CALL <dataname>
to get dynamic (late) binding. That was the case on IBM mainframes for many
years.

>I'm not sure the standard cares, but I would suggest that the Unisys MCP
>implementation, which requires no post-compile pre-execution steps and uses
>dynamic links, matches both the spirit and the letter of the ANSI spec in
>this fashion.   A compiled COBOL74 program is ready to execute in our
>environment as soon as the compiler's locked the file in the disk directory,
>whether that execution is "manual" or as a called program in a COBOL74 run
>unit.   That's the convention on Unisys MCP systems, where a "linking"
>process is very much the exception and is always carefully considered in
>application design.  On systems where a "link" step is usual or even
>mandatory, it wouldn't be surprising for ANSI IPC handling to include such a
>step, but that's not the case on Unisys MCP systems, and a bind (or rebind)
>during every compilation would be regarded by most Unisys MCP users as
>extremely tedious and contrary to their expectations.

I'm pleased to read that. Late binding is also the norm on Unix and Windows.

>The distinction "early" vs. "late" may apply to Unix.  It may apply to IBM.
>But it is simply not meaningful in the Unisys MCP environment when it comes
>to a *single* CALL mechanism.  If you want called routines to be linked
>*before* execution -- in which case they form a single object code file with
>the caller -- then you specify USE EXTERNAL and CALL <section-name>.  That,
>in MCP terminology, is called "using bound procedures".  Many do that.  If
>you want the ability to replace the called program on the fly, then you can
>use ANSI IPC syntax or minor extensions to it.  That, in MCP terminology, is
>called "using library calls".

Unix terminology is the same. The files are even named 'LIBxxx.so'.
0
6/19/2004 8:59:40 AM
riplin@Azonic.co.nz (Richard) wrote:

>"Chuck Stevens" <charles.stevens@unisys.com> wrote 
>
>> > If dataname is the same on the next CALL, as it is 99% of the time, the
>>  call
>> > would be faster than the first.
>> 
>> Where on earth did you get *that* statistic?   The whole point of CALL
>> <dataname> is that the programmer *doesn't* know what the name of the called
>> program is going to be until he gets to the CALL statement!    If 99% of the
>> time it's the same, why not use CALL <literal>?  Or even CHANGE ATTRIBUTE
>> TITLE OF <libraryname> TO <newlibname> CALL <newlibname>?   Both are a whole
>> lot faster than CALL <dataname>!
>
>I have several systems where the 'main' program is a simple loop which
>is roughly:
>
>       MOVE Logon-Program   TO Program-Name
>       MOVE Menu-Program    TO Next-Program
>       PERFORM 
>           UNTIL Program-Name = "FINISH"
>
>           CALL Program-Name
>               USING <interface block that includes Program-Name
>                         and Next-Program>
>               ON EXCEPTION ...
>           END-CALL
>           CANCEL Program-Name
>           MOVE Next-Program    TO Program-Name
>           MOVE Menu-Program    TO Next-Program
>       END-PERFORM
>
>Any program can change Next-Program to allow the user or any program
>to control where the system goes without having to return to the menu,
>which is just the default action.
>
>The chances of the same program being CALLed twice in a row is very
>small.

I've never written nor seen a program like that. 

Letting subordinate programs control who gets control next seems like bad
structure. The menu program should make that decision.
0
6/19/2004 8:59:40 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d0eaff.34046405@news.optonline.net...
>
>> Clear as mud. Just tell me the name of the failed program and line number
>on
>> which it failed. Given that, I can figure out why it failed. Do I ask too
>much?
>
>Unisys MCP COBOLs don't deal in *line* numbers, they deal in *sequence*
>numbers (remember columns 1-6?).

Major YUCK. Even the retrograde Cobol I support has given up on columns 1-6.
They use it for 'version control', with values like "rw0618". 

>Given that, for a system consisting exclusively of separately-compiled COBOL
>programs, the program dump provides the object code file name of the
>compilation unit and the sequence number and actual object code instruction
>address of the failure for each level in the PERFORM and CALL stack history.

Good. That's what we want.

>For a program that's nested, the sequence numbers identify the location of
>the failure, the call history within the compilation unit, the object code
>file name of the compilation unit, and the actual object code instruction
>address for of the failure for each level in the PERFORM and CALL stack
>history.
>
>The sequence number history of any failure is also by default provided in
>the abnormal-termination message, though you may actually have to glance at
>the program dump to find out which sequence number goes with which program.
>
>Have you *demonstrated* that you need more information than the MCP has
>already provided *you*?   Or is it just "I want to do it *my* way, not the
>way the system allows me to do it!"?

Policy determines the fate of systems and institutions. Politics determines the
fate of individuals. Although both are based on the same Greek root word "pol",
meaning people, they refer to different mental processes. Policy is rational
whereas politics is emotional. 

By emphasizing "you", you're trying to redirect the discussion into a political
vein. I claim no special credentials nor authority on Cobol. I'm just a code
cranker.
0
6/19/2004 8:59:40 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> It doesn't, but it appears in IBM, Micro Focus, Fujitsu and others. In other
>> words, 98+% of available Cobol compilers.
>
>Let me see now.  "Available Cobol compilers", here are some:
>
>    Microfocus
>    Liant
>    AcuCobol
>    IBM
>    Fujitsu
>    Kobol
>    OpenCobol
>    HP Cobol
>    Compaq NonStop
>
>The one you mentioned seems to be about 33% of this list.
>
>Perhaps you meant something else, again.

I meant INSTANCES of actively used compilers. If 1,000 programmers are using
Micro Focus versus 1 using Kobol then Micro Focus gets a higher score. 

0
6/19/2004 8:59:41 AM
In article <40d3f520.233277868@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>riplin@Azonic.co.nz (Richard) wrote:
>
>>"Chuck Stevens" <charles.stevens@unisys.com> wrote 

[snip]

>>I have several systems where the 'main' program is a simple loop which
>>is roughly:
>>
>>       MOVE Logon-Program   TO Program-Name
>>       MOVE Menu-Program    TO Next-Program
>>       PERFORM 
>>           UNTIL Program-Name = "FINISH"
>>
>>           CALL Program-Name
>>               USING <interface block that includes Program-Name
>>                         and Next-Program>
>>               ON EXCEPTION ...
>>           END-CALL
>>           CANCEL Program-Name
>>           MOVE Next-Program    TO Program-Name
>>           MOVE Menu-Program    TO Next-Program
>>       END-PERFORM
>>
>>Any program can change Next-Program to allow the user or any program
>>to control where the system goes without having to return to the menu,
>>which is just the default action.
>>
>>The chances of the same program being CALLed twice in a row is very
>>small.
>
>I've never written nor seen a program like that. 

Mr Wagner, you have presented code here about which many others have made 
the same claim... and you've called them 'resistant to progress' or the 
like.

>
>Letting subordinate programs control who gets control next seems like bad
>structure. The menu program should make that decision.

Oh, I *cannot resist... this seems like rigid, hierarchical thinking, Mr
Wagner, how very archaic of you!  Remeber the IBM mainframe ISPF
'revolution' of the 1970s?  Not only was there a menu-driven Integrated
environment... but at any point one could use the command-line to jump to
any other place in the Facility.

Come to The Future, Mr Wagner... it started about three decades ago!

DD

0
docdwarf (6044)
6/19/2004 12:58:01 PM
docdwarf@panix.com wrote:
> In article <40d3f520.233277868@news.optonline.net>,
> Robert Wagner <robert.deletethis@wagner.net> wrote:
> 
>>riplin@Azonic.co.nz (Richard) wrote:
>>
>>
>>>"Chuck Stevens" <charles.stevens@unisys.com> wrote 
> 
> 
> [snip]
> 
> 
>>>I have several systems where the 'main' program is a simple loop which
>>>is roughly:
>>>
>>>      MOVE Logon-Program   TO Program-Name
>>>      MOVE Menu-Program    TO Next-Program
>>>      PERFORM 
>>>          UNTIL Program-Name = "FINISH"
>>>
>>>          CALL Program-Name
>>>              USING <interface block that includes Program-Name
>>>                        and Next-Program>
>>>              ON EXCEPTION ...
>>>          END-CALL
>>>          CANCEL Program-Name
>>>          MOVE Next-Program    TO Program-Name
>>>          MOVE Menu-Program    TO Next-Program
>>>      END-PERFORM
>>>
>>>Any program can change Next-Program to allow the user or any program
>>>to control where the system goes without having to return to the menu,
>>>which is just the default action.
>>>
>>>The chances of the same program being CALLed twice in a row is very
>>>small.
>>
>>I've never written nor seen a program like that. 
> 
> 
> Mr Wagner, you have presented code here about which many others have made 
> the same claim... and you've called them 'resistant to progress' or the 
> like.
> 
> 
>>Letting subordinate programs control who gets control next seems like bad
>>structure. The menu program should make that decision.
> 
> 
> Oh, I *cannot resist... this seems like rigid, hierarchical thinking, Mr
> Wagner, how very archaic of you!  Remeber the IBM mainframe ISPF
> 'revolution' of the 1970s?  Not only was there a menu-driven Integrated
> environment... but at any point one could use the command-line to jump to
> any other place in the Facility.
> 
> Come to The Future, Mr Wagner... it started about three decades ago!
> 
> DD
> 

A collection of such command lines, tied as an object to a buttons on a 
screen, seems like such a neat liitle oop object. Compiled with the 
actual code given above, also implimented as an oop object, you have a 
ten minute single stepping debug tool.

'Course using objects is just *so* inefficient.

Donald

0
donald_tees (563)
6/19/2004 1:10:50 PM
In article <40d3f68b.233641146@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:

[snip]

>Policy determines the fate of systems and institutions. Politics determines the
>fate of individuals. Although both are based on the same Greek root word "pol",
>meaning people, they refer to different mental processes. Policy is rational
>whereas politics is emotional. 

Mr Wagner, this Greek derivation you assert... do you have any 
documentation for it?  My memory is, admittedly, porous and I was taught 
such things a... few years back but I seem to recall that the root for 
politics and policy was, ultimately, from the Greek 'polis' 
(pi-omicron-lambda-iota-sigma), or 'city'... and that the entry for 
'polis' in the Liddell and Scott lexicon was in Capital letters, 
indicating a Root or Primitive Form.

Where can you cite a source for this 'pol' = people?

(It might be interesting to compare the use of these Greek 'city'-based 
words with the Latin-based 'city'-based ones (civ-, urb-)... but that 
would be for another time.)

DD

0
docdwarf (6044)
6/19/2004 1:26:03 PM
In article <217e491a.0406182249.4cd3715d@posting.google.com>,
 riplin@Azonic.co.nz (Richard) wrote:

> robert.deletethis@wagner.net (Robert Wagner) wrote
> 
> > But it has, at least once. When Structured Programming appeared in the late
> > '60s, we already had a substantial body of work based on GO TO. Had this 
> > forum
> > existed then, I can picture heated debates between the Old Guard defending 
> > GO TO
> > and bright-eyed 'progressives' decrying GO TO. For once, the good guys won,
> > although we still see backguard pockets of resistance some 35 years later. 
> 
> There is nothing in 'structured programming' that prohibits the use of
> GO TO, though it may restrict the scope of its use.
> 
> Personally I find that I never need GO TO and have a style in which it
> can not be useful.

There may not be a prohibition on GO TO in someones specific 
implementation of 'Cobol Structured Programming' (that guy that wrote up 
the perform/thru/goto/exit comes to mind).  But there are plenty of 
prohibitions against it in generic structured programming.  Quite 
simply, it makes programs unstructured.
0
6/19/2004 2:19:00 PM
riplin@Azonic.co.nz (Richard) wrote:


>You fail to distinguish between 'accessing the passed parameters from
>the parent' and your assertion about: "access to the memory of all
>other programs within the process".
>
>Just because the hardware allows a small amount of specific access
>does not mean that therfore it allows complete and unrestricted
>access.  An issue here is addressability.  A CALLed program is passed
>the address of some specific areas as parameters.  You may be used to
>being able to calculate the addresses of other areas from that, but
>that is not necessarily a valid assumption in other architectures.
>
>Even in a lowly 80286 it is possible to create a new descriptor that
>allows access to an area of data but which bears no relationship to
>descriptors which access other data.  For example on doing a CALL the
>run-time (or generated code) could create a descriptor for each
>parameter and pass pointers referenceing those.  This would give free
>access to the parent(s)' data areas being passed by reference while
>enforcing hardware restrictions beyond those boundries.

Thank you for providing such a good example in support of my point. The 80286
had an address space of 16M. When a program touched memory to which it lacked
permission, the hardware generated an interrupt 0. 

A called program with bad intentions could a) revector interrupt 0 to its own
handler and b) employ a brute force search through all 16M. At the end it would
have a map of all its parent's sectors. 

0
6/19/2004 4:06:18 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:


>Allocation of memory space is secondary to having an untouched data
>descriptor to begin with.  The only way to gain access to a preexisting
>memory space -- which means that the memory space has been touched -- is to
>have access to the already-built descriptor that points to it.  If the
>compiler doesn't provide that access (through EXTERNAL, through GLOBAL, or
>as a parameter), the called process doesn't get access to the memory.
>Having access to another memory space in the memory space in the same
>calling program is absolutely irrelevant, because that memory space is
>governed by a *different* descriptor.    The hardware *design* prevents
>access to other portions of the caller's memory by the simple expedient of
>"you can't get there from here".  Neither the hardware nor the software
>*actively prevents* anything; it's the *access* that has to be granted
>*explicitly* to begin with.

Thanks for the description of Unisys memory management. I can't dispute what you
said because I don't know the MCP environment.

0
6/19/2004 4:18:20 PM
Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-B0D300.10185919062004@corp.supernews.com...
> In article <217e491a.0406182249.4cd3715d@posting.google.com>,
>  riplin@Azonic.co.nz (Richard) wrote:
[snip]
> >
> > There is nothing in 'structured programming' that prohibits the use of
> > GO TO, though it may restrict the scope of its use.
> >
> > Personally I find that I never need GO TO and have a style in which it
> > can not be useful.
>
> There may not be a prohibition on GO TO in someones specific
> implementation of 'Cobol Structured Programming' (that guy that wrote up
> the perform/thru/goto/exit comes to mind).  But there are plenty of
> prohibitions against it in generic structured programming.  Quite
> simply, it makes programs unstructured.

I find this rather curious. '[G]eneric structured programming', as
I understand it, could only refer to flow charts; not to any actual
programming language. It is in the translation of a flow chart that
one uses GO TO, where the implementation language does not
have a means for directly implementing the generic form. How is
it that the mere translation of one form to another makes the latter
unstructured when the former is structured?



0
ricksmith (875)
6/19/2004 4:51:09 PM
Regarding the Never Before Seen Program mentioned below, and based upon
the logic depicted, that logic is very much like the old Univac I Run to
Run Locater (our only operating system), and placed between each load
mod on an application library TAPE.

Our manual controls had to make sure the right library tape had to be
mounted upon the correct drive before an application began. Simple.
Worked well. Not very good when you are using fancy hardware like you
are dealing with today.

Warren Simmons

Robert Wagner wrote:

> riplin@Azonic.co.nz (Richard) wrote:
> 
> 
>>"Chuck Stevens" <charles.stevens@unisys.com> wrote 
>>
>>
>>>>If dataname is the same on the next CALL, as it is 99% of the time, the
>>>
>>> call
>>>
>>>>would be faster than the first.
>>>
>>>Where on earth did you get *that* statistic?   The whole point of CALL
>>><dataname> is that the programmer *doesn't* know what the name of the called
>>>program is going to be until he gets to the CALL statement!    If 99% of the
>>>time it's the same, why not use CALL <literal>?  Or even CHANGE ATTRIBUTE
>>>TITLE OF <libraryname> TO <newlibname> CALL <newlibname>?   Both are a whole
>>>lot faster than CALL <dataname>!
>>
>>I have several systems where the 'main' program is a simple loop which
>>is roughly:
>>
>>      MOVE Logon-Program   TO Program-Name
>>      MOVE Menu-Program    TO Next-Program
>>      PERFORM 
>>          UNTIL Program-Name = "FINISH"
>>
>>          CALL Program-Name
>>              USING <interface block that includes Program-Name
>>                        and Next-Program>
>>              ON EXCEPTION ...
>>          END-CALL
>>          CANCEL Program-Name
>>          MOVE Next-Program    TO Program-Name
>>          MOVE Menu-Program    TO Next-Program
>>      END-PERFORM
>>
>>Any program can change Next-Program to allow the user or any program
>>to control where the system goes without having to return to the menu,
>>which is just the default action.
>>
>>The chances of the same program being CALLed twice in a row is very
>>small.
> 
> 
> I've never written nor seen a program like that. 
> 
> Letting subordinate programs control who gets control next seems like bad
> structure. The menu program should make that decision.
0
wsimmons5 (172)
6/19/2004 6:10:49 PM
docdwarf@panix.com wrote:

>In article <40d3f68b.233641146@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:
>
>[snip]
>
>>Policy determines the fate of systems and institutions. Politics determines
the
>>fate of individuals. Although both are based on the same Greek root word
"pol",
>>meaning people, they refer to different mental processes. Policy is rational
>>whereas politics is emotional. 
>
>Mr Wagner, this Greek derivation you assert... do you have any 
>documentation for it?  My memory is, admittedly, porous and I was taught 
>such things a... few years back but I seem to recall that the root for 
>politics and policy was, ultimately, from the Greek 'polis' 
>(pi-omicron-lambda-iota-sigma), or 'city'... and that the entry for 
>'polis' in the Liddell and Scott lexicon was in Capital letters, 
>indicating a Root or Primitive Form.

I stand corrected; I should have written 'polis'. (I actually saw the error
seconds after posting, hoped no one would notice.)

>Where can you cite a source for this 'pol' = people?

It means civilized people, in contrast to tribal people. 

"If relations in the tribe were along the lines made possible by the natural
bonds of blood ties and lineages, that's of the organic or gemeinschaft, those
of the polis were of the gesellschaft type, i.e, a result of deliberate human
invention. Far beyond the coming together of families and kin, as in the tribe,
relations in the polis were among individuals who have no other bonds except
those regulated by Laws and enshrined in Institutions. And, while relations in
the tribe don't go beyond guaranteeing a minimum modicum of functioning,
relations in the polis were built on the synergetic principle which says the
whole must be more than the sum of its parts. For the polis was not a mere
collections of simple units, be those of residence or production, but rather of
a vast agglomeration of institutions. The Parthenon, the Agora, the Stadium, The
Gymnasium, the Theater, the Academy, etc., not to forget about the processes of
governing; assembly, courts, etc., were the physical and intellectual
manifestations of the process of what the Greeks called politeia, from which the
derivation of polity; and later their Latin inheritors re-named civitas which
constituted the stem root of city and of civi-lization."

http://www.libyaforum.org/english/index.php?option=content&task=view&id=38

0
6/19/2004 6:11:28 PM
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:

>Robert Wagner wrote:
>> "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>> 
>> Let's call this hypothetical machine CADET, for Can't Add, Doesn't Even Try.
It
>> could do arithmetic by table lookup using two indicies. The RCA 301 actually
>> worked that way. If someone stepped on the arithmetic table at a fixed
address
>> in low memory, answers came out wrong until you rebooted the machine. 
>> 
>Where were the add tables?  I know that the print translate table was in 
>high memory (19900-63 as I recall) because we had a program space fill 
>the table causing the Analex (sp?) drum printer to print and blow a 
>fuse.  Translate instructions used tables that started at 00 locations.
>>> rest snipped

I don't recall the exact address. 

Everything about the RCA 301 (aka ICT1500) seemed like a joke. It had a disk
drive made by Wurlitzer that looked and worked like a juke box. When an IO error
occurred, the machine stopped and a red light came on. The operator was expected
to fix the record in memory (how?) and continue. It had a three-speed card
reader that required the programmer to start downshifting about a hundred cards
from the end. 

Perhaps the biggest joke was the tape drives. They were designed with a
hook-and-eye fastener between the removable tape and the permanent leader. It
didn't work right, so operators would dismount a tape by cutting it with a pair
of scissors. The first time I saw that, I couldn't believe my eyes. To mount a
tape, they'd attach it to the leader with splicing tape. 
0
6/19/2004 6:53:14 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> I've never written nor seen a program like that. 
 
> Letting subordinate programs control who gets control next seems like bad
> structure. The menu program should make that decision.

It is neither the subordinate program nor the menu program that
controls which program is loaded next, it is the _user_.

Mostly the user indicates they want to return to the menu to select
what to do next, or, because tasks are related, they indicate they
want to go directly to another task (from a limited selection) without
bothering with the menu.

Some of these systems originated when memory was a limited resource
sparingly used.  Some were running on 64Kb 8085 networked machines and
are still in use (though updated and enhanced) because they meet the
users needs.
0
riplin (4127)
6/19/2004 7:34:16 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> >> words, 98+% of available Cobol compilers.

> >Perhaps you meant something else, again.
> 
> I meant INSTANCES of actively used compilers. If 1,000 programmers are using
> Micro Focus versus 1 using Kobol then Micro Focus gets a higher score.

Ahhh, the big 'IF'.  Do you have any actual information that there are
1000 programmers using MicroFocus for every one using Kobol ?  Or are
you just researching your keyboard yet again ?
0
riplin (4127)
6/19/2004 7:44:59 PM
Robert Wagner wrote:

> "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
> 
> 
>>Robert Wagner wrote:
>>
>>>"Chuck Stevens" <charles.stevens@unisys.com> wrote:
>>>
>>>Let's call this hypothetical machine CADET, for Can't Add, Doesn't Even Try.
> 
> It
> 
>>>could do arithmetic by table lookup using two indicies. The RCA 301 actually
>>>worked that way. If someone stepped on the arithmetic table at a fixed
> 
> address
> 
>>>in low memory, answers came out wrong until you rebooted the machine. 
>>>
>>
>>Where were the add tables?  I know that the print translate table was in 
>>high memory (19900-63 as I recall) because we had a program space fill 
>>the table causing the Analex (sp?) drum printer to print and blow a 
>>fuse.  Translate instructions used tables that started at 00 locations.
>>
>>>>rest snipped
> 
> 
> I don't recall the exact address. 
Incidentally, there was no way in assembler to force a 00 starting 
address even though one was needed for various tables.
> 
> Everything about the RCA 301 (aka ICT1500) seemed like a joke. It had a disk
> drive made by Wurlitzer that looked and worked like a juke box. When an IO error
> occurred, the machine stopped and a red light came on. The operator was expected
> to fix the record in memory (how?) and continue. It had a three-speed card
> reader that required the programmer to start downshifting about a hundred cards
> from the end. 
We were lucky because we had the IBM card reader punch attached.  The 
error correction procedure for tape was to backspace 1 block and then 
read it with ALarm Inhibit (ALI) on.  The operator would then scan 
memory for Memory Register Parity Error and/or Data Parity Error 
(MRPE/DPE) and when found, correct the byte in memory.

> 
> Perhaps the biggest joke was the tape drives. They were designed with a
> hook-and-eye fastener between the removable tape and the permanent leader. It
> didn't work right, so operators would dismount a tape by cutting it with a pair
> of scissors. The first time I saw that, I couldn't believe my eyes. To mount a
> tape, they'd attach it to the leader with splicing tape. 
At Westinghouse Electric International, we actually used the hook and eye.

I did like the RPG they had and DYL260 seemed to be designed with the 
same philosophy.

0
cfmtech (125)
6/19/2004 8:59:35 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> But it has, at least once. When Structured Programming appeared in the late
>> '60s, we already had a substantial body of work based on GO TO. Had this
forum
>> existed then, I can picture heated debates between the Old Guard defending GO
TO
>> and bright-eyed 'progressives' decrying GO TO. For once, the good guys won,
>> although we still see backguard pockets of resistance some 35 years later. 
>
>There is nothing in 'structured programming' that prohibits the use of
>GO TO, though it may restrict the scope of its use.

It seems odd that so many misinterpreted structured programming the same way.

>Personally I find that I never need GO TO and have a style in which it
>can not be useful.

Same here, although I occasionally use GO TO when the program is aborting. 

>> What happened to that spirit of improvement? OO Cobol is roughly comparable
to
>> Structured Programming back then. Why has it been ignored by the Cobol
>> community? Because we're now aged 50-60 rather than 20-30? Or is it because
>> mainframe shops have Programming Standards prohibiting progress? (pardon
>> alliteration)
>
>No. That is not the case.  Much of the OO features in C++, for
>example, are to solve the problems of the C language.  In many cases
>Cobol never had those problems. 

It has other problems that would be solved by OO. Number one is massive
monolithic programs. Another is passing decisions 'under the covers' via data
stored in memory or in a file. A decision is made in program A; an action based
on that decision occurs in program B. Hopefully OO would make it clear that the
decision and action should be packaged together. 

> Now OO does have some really useful
>functionality, in many cases the types of applications that Cobol is
>commonly used for does not need this functionality. 

It sounds like you're referring to batch programs. I think they need OO more
than realtime, because they tend to be larger.

> In other cases,
>such as in your demonstration, the OO is not only inappropriate but is
>far slower when compared to conventional solutions.

They don't have to be much slower. The measured speed of an INVOKation is only
slightly worse than a dynamic call. Because methods often work on larger chunks
of data, for example an entire collection, the number of INVOKEs should be fewer
than the number of CALLs.

>If you had learnt other languages well enough then you would have seen
>where the OO solutions were required and could evaluate whether these
>could be applied to Cobol.

What about other Cobol programmers avoiding OO? Are they all disqualified by
lack of experience with other languages?

>> I don't think pointers make Cobol C-like; I think they make it equally
capable.
>
>One of the reasons that C++ of the 80s is a step up from C is that it
>replaced pointers with objects.  Memory management was contained
>within the objects.  The reason that Java  of the 90s is a step up
>from C++ is that the objects themselves are garbage collected.  These
>two steps removed all the manual grubbiness from pointers that were
>the bane of C.

Now that we have gigabytes of memory, garbage collection seems obsolete.
Moreover, I thought the virtual memory manager's job was to identify a program's
working set. 

>Cobol never had this pointer problem because the applications
>generally did not require them.  C used them to build trees, lists and
>other complex structures.  Cobol just put this data into files and
>arrays.

Nowadays it puts the data into databases, thereby offloading efficiency to
database software. When it runs too slowly, they don't blame poor design, they
say the database needs tuning. I spend most of my time trying to trick the
Oracle optimizer into acting rational. 'Look, dummy, there's an index on that
table. Why are you doing a full table scan? If I say ORDERED BY, will you use it
then?' 

Database tuning tips: rule-based is your best friend. Second best is tweaking
cost fastors to seemingly unreasonable levels. 

>Introducing pointers to Cobol in the way you want them to be used just
>takes the language back to the C of the 70s. 

I disagree. Pointers let you build lists with no practical size limit, and don't
require that every entry be padded to its maximum size. When the number of
dimensions in a data structure goes above 1, arrays can become unmanagably large
... even with lots of memory.

I use lists routinely for everyday application programming. 

> There are reasons for
>wanting pointers, such as interacting with the OS, but these should be
>as restrained as possible. They are not an 'advanced feature', they
>are taught in a 'C advanced course', because the programmer needs to
>be better than a beginner.

Cobol uses pointers on every CALL. One can exploit that by passing a pointer BY
CONTENT to a program expecting a reference. It was a handy technique in the days
of memory mapped screens. Given Cobol programmers' aversion to prototypes,
there's no type-safety across a CALL. 

Cobol pointers are less error-prone than C pointers. In Cobol, you set it once
and it says set until you change it. In C, you have to say the pointer's name on
*every blasted reference*. If you name the wrong pointer, the compiler generates
misbehaving code.

Realia supported pointers (in 1984) without giving you access to them. The
program referred to a Linkage Section item and asked it to construct an
instance. Subsequent references were based on a hidden pointer. The program had
no way of stepping on it or using the wrong one. Unfortunately one couldn't
build lists that way. I had to call another program using BY REFERENCE the newly
created structure. The program expected .. you guessed it .. a word to be passed
BY CONTENT, and simply returned the pointer.

>You simply show that you never went through the learning process that
>led to the reason why they are not in Java or C#, and what has
>replaced the need for them.

They were deleted for SECURITY reasons, not because they were unneeded. 

>While trivial programs, such as your demos, may make pointer
>management seem easy this is not the case in any substantial program. 
>C++ programmers who wrote large C applications with pointers know why
>C++ introduced objects.  Java programmers who did large systems in C++
>know why garbage collection was added and pointers were removed.

Because some people 'always had trouble with pointers'. Generally the same ones
who 'always had trouble with complex conditionals'. Those people are better
suited be managers, testers or administrators.

>You obviously did not go through that and so promote starting at step
>1 in the 70s.

You can't send up what you don't have down.

>> Resisting progress is one thing, arguably good; ignoring and rejecting it is
>> Bad. Cobol's strength doesn't come from immutability, it comes from
>> extensibility. OO Cobol is a good demonstration of the language's vibrancy ..
>> and its adherents' resistance to progress.
>
>Pointers are _not_ progress.  Your demo of doing inappropriate things
>with collection classes and then concluding they are slow and poor is
>not progress.  If you want progress then do something _better_.

I could write a FAST collection class. Would that be better?

>> I agree -- diletantes will not stick with Cobol. Good riddance.
>
>So why do you care what they say about Cobol ?

Because they go on to become decision makers. Too often their decision is to
replace Cobol with some language they read about in an airline magazine.

I'd wager fewer than 1 in 100 managers knows that Cobol can do GUI screens or
OO. An informal survey of programmers I work with showed none of them did. One
asked "Why? Everyone knows VB is a better tool for the job."

I once worked for an IT manager at a well-known Wall Street company who didn't
even know the word Cobol. When asked what language he thought a program was
written in, his answer was "Oh, that's written in Batch."

0
6/19/2004 9:24:37 PM
     Am  14.06.04
schrieb  charles.stevens@unisys.com (Chuck Stevens)
    auf  /COMP/LANG/COBOL
     in  cakiec$1lan$1@si05.rsvl.unisys.com
  ueber  Re: IBM 1401 was: Re: Is it possible to use the value of the PROGRAM I

CS> and subsequently on a Wang 700 programmable calculator using code
CS> segmentation and automatic loading on the program cassette drive.

  On a Wang 700 B I have written my very first programs ... with it's  
just about 900 program steps. Quite a feat what you did on it.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung m�glich"        - Friedrich Engels      (Februar 1865)
0
l.willms1 (637)
6/19/2004 10:08:00 PM
In article <joe_zitzelberger-B0D300.10185919062004@corp.supernews.com>,
Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:
>In article <217e491a.0406182249.4cd3715d@posting.google.com>,
> riplin@Azonic.co.nz (Richard) wrote:

[snip]

>> There is nothing in 'structured programming' that prohibits the use of
>> GO TO, though it may restrict the scope of its use.
>> 
>> Personally I find that I never need GO TO and have a style in which it
>> can not be useful.
>
>There may not be a prohibition on GO TO in someones specific 
>implementation of 'Cobol Structured Programming' (that guy that wrote up 
>the perform/thru/goto/exit comes to mind).  But there are plenty of 
>prohibitions against it in generic structured programming.  Quite 
>simply, it makes programs unstructured.

Quite simply, things might not be as they are described as 'quite simply'.  
I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
defined as allowing for a GO TO which directed execution to the top of the
paragraph which contained the statement, to the -EXIT paragraph THRU which
the containing paragraph was PERFORMed or to the -ABEND routine of the
program... those three and no more.

If these teaching were correct then a method of structuring is defined as 
allowing for a GO TO and therefore, quite simply, it does *not* make a 
program unstructured.

DD

0
docdwarf (6044)
6/19/2004 10:29:53 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> >Even in a lowly 80286 it is possible to create a new descriptor that
> >allows access to an area of data but which bears no relationship to
> >descriptors which access other data.  For example on doing a CALL the
> >run-time (or generated code) could create a descriptor for each
> >parameter and pass pointers referenceing those.  This would give free
> >access to the parent(s)' data areas being passed by reference while
> >enforcing hardware restrictions beyond those boundries.
> 
> Thank you for providing such a good example in support of my point. 

It isn't 'support for your point' at all, but you just haven't enough
knowledge to know that yet.

> The 80286
> had an address space of 16M. When a program touched memory to which it lacked
> permission, the hardware generated an interrupt 0. 
> 
> A called program with bad intentions could a) revector interrupt 0 to its own
> handler and b) employ a brute force search through all 16M. At the end it would
> have a map of all its parent's sectors.

Well, no, it couldn't do that.  Not when the processor was running in
protected mode.  You may well come up with all sorts of ideas and
schemes, but they are all, it seems, based on your rather limited
experience.
0
riplin (4127)
6/19/2004 10:44:54 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> Thanks for the description of Unisys memory management. I can't dispute what you
> said 

But you _have_ been disputing what he said.

> because I don't know the MCP environment.

We already worked that out.
0
riplin (4127)
6/19/2004 10:46:37 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> Everything about the RCA 301 (aka ICT1500) seemed like a joke. It had a disk
> drive made by Wurlitzer that looked and worked like a juke box.

Then you missed the joke.  That drive was _not_ made by Wurlitzer, it
was called 'Wurlitzer' as a joke because it worked like a juke box. 
This was no more strange than other mechanisms, such as MCF (Magnetic
Card File) or the IBM system that used a mechanical loading system for
tape cartridges to store and recover disk data.

> When an IO error
> occurred, the machine stopped and a red light came on. The operator was expected
> to fix the record in memory (how?) and continue. 

When it had an 'IO error' the machine stopped and the operator fixed
the card and refed it.

> It had a three-speed card
> reader that required the programmer to start downshifting about a hundred
> cards from the end. 

No, it didn't require the _programmer_ to downshift.

I worked for ICT (International Computers and Tabulators), later it
was renamed ICL when it merged with English Electric LEO Marconi and
others.

> Perhaps the biggest joke was the tape drives. They were designed with a
> hook-and-eye fastener between the removable tape and the permanent leader. 

It was quite common to have preloaded leaders, not only with computer
tape drives, but with commercial audio and vieo drives too.  And not
just reel to reel, I still have some 3 inch cartridge tapes (that is
the diameter of the cartridge not the width of the tape) that
automatically clips onto a pretheaded leader on the drive.

> It
> didn't work right, so operators would dismount a tape by cutting it with a pair
> of scissors. The first time I saw that, I couldn't believe my eyes. To mount a
> tape, they'd attach it to the leader with splicing tape.

Whatever works for them.
0
riplin (4127)
6/19/2004 11:19:49 PM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>Again, any Unisys MCP customer is welcome to file a New Feature Suggestion
>against COBOL85 to request USAGE POINTER in that dialect.  I daresay IBM,
>Micro Focus, Fujitsu and others have incorporated it because *their*
>customers have found it to be a useful feature.  As far as ANSI X3.23-1985
>COBOL goes, it is an extension, and in our case there has been so little
>demand for this extension from our users -- that is to say, none -- and
>there has been so little evidence that this feature would be of particular
>benefit in the Unisys MCP environment -- none that I've seen so far, and a
>lot of security risks -- that it isn't even on the list of such features for
>consideration at this time.

Algol has pointers. Why are they a security risk in the hands of Cobol
programmers but not Algol programmers?
0
6/20/2004 12:04:56 AM
In article <40d46df5.264215145@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>>In article <40d3f68b.233641146@news.optonline.net>,
>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>
>>[snip]
>>
>>>Policy determines the fate of systems and institutions. Politics determines the
>>>fate of individuals. Although both are based on the same Greek root word "pol",
>>>meaning people, they refer to different mental processes. Policy is rational
>>>whereas politics is emotional. 
>>
>>Mr Wagner, this Greek derivation you assert... do you have any 
>>documentation for it?  My memory is, admittedly, porous and I was taught 
>>such things a... few years back but I seem to recall that the root for 
>>politics and policy was, ultimately, from the Greek 'polis' 
>>(pi-omicron-lambda-iota-sigma), or 'city'... and that the entry for 
>>'polis' in the Liddell and Scott lexicon was in Capital letters, 
>>indicating a Root or Primitive Form.
>
>I stand corrected; I should have written 'polis'. (I actually saw the error
>seconds after posting, hoped no one would notice.)
>
>>Where can you cite a source for this 'pol' = people?
>
>It means civilized people, in contrast to tribal people. 

Mr Wagner, according to the Liddell and Scott lexicon the root/primitive 
form is 'polis'; 'pol' is not a word in Ancient Greek.  As for 'civilised' 
versus 'polis-ticised' versus 'urbanised'... well, as what you snipped 
from my original posting may have indicated, this might be another 
discussion, entire.

>
>"If relations in the tribe were along the lines made possible by the natural
>bonds of blood ties and lineages, that's of the organic or gemeinschaft, those
>of the polis were of the gesellschaft type, i.e, a result of deliberate human
>invention. Far beyond the coming together of families and kin, as in the tribe,
>relations in the polis were among individuals who have no other bonds except
>those regulated by Laws and enshrined in Institutions. And, while relations in
>the tribe don't go beyond guaranteeing a minimum modicum of functioning,
>relations in the polis were built on the synergetic principle which says the
>whole must be more than the sum of its parts. For the polis was not a mere
>collections of simple units, be those of residence or production, but rather of
>a vast agglomeration of institutions. The Parthenon, the Agora, the Stadium, The
>Gymnasium, the Theater, the Academy, etc., not to forget about the processes of
>governing; assembly, courts, etc., were the physical and intellectual
>manifestations of the process of what the Greeks called politeia, from which the
>derivation of polity; and later their Latin inheritors re-named civitas which
>constituted the stem root of city and of civi-lization."
>
>http://www.libyaforum.org/english/index.php?option=content&task=view&id=38
>

Leaving aside that the above-cited section does not make mention of 'pol = 
people'... it seems that the (anonymous?) author has other disagreements 
with Liddell and Scott's definitions, as well.

DD

0
docdwarf (6044)
6/20/2004 12:07:31 AM
docdwarf@panix.com wrote:

>Quite simply, things might not be as they are described as 'quite simply'.  
>I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
>defined as allowing for a GO TO which directed execution to the top of the
>paragraph which contained the statement, to the -EXIT paragraph THRU which
>the containing paragraph was PERFORMed or to the -ABEND routine of the
>program... those three and no more.

The standards committee dropped the ball twice. First they gave us PERFORM ..
THRU, which was intended for the case where we sometimes perform a and other
times perform a thru b. It wasn't intended to be an exit mechanism, but it
quickly devolved into one.

They could have corrected the abuse by giving us EXIT PARAGRAPH in '85 or '02.
If we had EXIT PARAGRAPH, there would be no excuse to perform THRU an exit nor
GO TO an exit. 

We can EXIT FUNCTION, EXIT METHOD, EXIT PROGRAM and EXIT PERFORM. The absence of
EXIT PARAGRAPH seems oddly irregular. I speculate its absence was due to the
aforementioned THRU. If a program said 'perform a thru c' and paragraph a said
exit paragraph, where would control go? Logically, it would go to the paragraph
following a. But poorly written unstructured programs might not have a. b. and
c. in a straight line. The paragraph following a. might be z., which is
logically unrelated. Paragraph a. might rely on GO TO to transfer control to
either b. or c.

So we're stuck with 'the sins of the fathers'. It all started with the seemingly
innocuous THRU.
0
6/20/2004 2:09:21 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 
>
>> >Even in a lowly 80286 it is possible to create a new descriptor that
>> >allows access to an area of data but which bears no relationship to
>> >descriptors which access other data.  For example on doing a CALL the
>> >run-time (or generated code) could create a descriptor for each
>> >parameter and pass pointers referenceing those.  This would give free
>> >access to the parent(s)' data areas being passed by reference while
>> >enforcing hardware restrictions beyond those boundries.
>> 
>> Thank you for providing such a good example in support of my point. 
>
>It isn't 'support for your point' at all, but you just haven't enough
>knowledge to know that yet.
>
>> The 80286
>> had an address space of 16M. When a program touched memory to which it lacked
>> permission, the hardware generated an interrupt 0. 
>> 
>> A called program with bad intentions could a) revector interrupt 0 to its own
>> handler and b) employ a brute force search through all 16M. At the end it
would
>> have a map of all its parent's sectors.
>
>Well, no, it couldn't do that.  Not when the processor was running in
>protected mode.  You may well come up with all sorts of ideas and
>schemes, but they are all, it seems, based on your rather limited
>experience.

I previously showed how it could switch to real mode with a single instruction.
After revectoring the interrupt, it could switch back to protected mode and have
its way with the machine. 

Of course, this is based on my limited experience writing such hacks and
distributing them worldwide. 
0
6/20/2004 2:09:22 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 
>
>> I've never written nor seen a program like that. 
> 
>> Letting subordinate programs control who gets control next seems like bad
>> structure. The menu program should make that decision.
>
>It is neither the subordinate program nor the menu program that
>controls which program is loaded next, it is the _user_.
>
>Mostly the user indicates they want to return to the menu to select
>what to do next, or, because tasks are related, they indicate they
>want to go directly to another task (from a limited selection) without
>bothering with the menu.

Fine, but the subordinate program shouldn't be expected to supply the NAME of
the next program. 

>Some of these systems originated when memory was a limited resource
>sparingly used.  Some were running on 64Kb 8085 networked machines and
>are still in use (though updated and enhanced) because they meet the
>users needs.

"Meets their needs" is an euphemism for 'they can tolerate its inadequacies.'
Those limits are now largely gone, but the coping mechanisms we developed over
40+ years are not.

0
6/20/2004 2:09:23 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 
>
>> >> words, 98+% of available Cobol compilers.
>
>> >Perhaps you meant something else, again.
>> 
>> I meant INSTANCES of actively used compilers. If 1,000 programmers are using
>> Micro Focus versus 1 using Kobol then Micro Focus gets a higher score.
>
>Ahhh, the big 'IF'.  Do you have any actual information that there are
>1000 programmers using MicroFocus for every one using Kobol ?  Or are
>you just researching your keyboard yet again ?

Yes. I recently posted here findings from US employment ads breaking the market
down by platform and compiler. If you have information from other sources,
please share it.

0
6/20/2004 2:09:24 AM
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:

>I did like the RPG they had and DYL260 seemed to be designed with the 
>same philosophy.

I wrote DYL240, the first in the series, on a Spectra 70.

Later, I was embarrassed by its RPG-like 'language'. If I had it to do over, I
would have used a freeform language.

0
6/20/2004 2:09:25 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 

>> When an IO error
>> occurred, the machine stopped and a red light came on. The operator was
expected
>> to fix the record in memory (how?) and continue. 
>
>When it had an 'IO error' the machine stopped and the operator fixed
>the card and refed it.

I was referring to tape read errors. Clark Morris said the operator would do a
backspace and re-execute the read instruction, ten bytes back. That agrees with
my memory. When that failed, the operator would 'correct' the error in memory.
Based on what?

>> It had a three-speed card
>> reader that required the programmer to start downshifting about a hundred
>> cards from the end. 
>
>No, it didn't require the _programmer_ to downshift.

My programs were required to. They looked for an 'end is near' card.

The card reader ran like a check sorter, here comes the next card ready or not.
The program didn't say read a card, it said wait for wait for the next card. If
it diddled around too long, it missed a card.


0
6/20/2004 2:09:26 AM
Regarding Structured Programming.....

At one time, our Data Center was managed by a programmer who mostly
was interested in getting the computer used for scientific work during
his lunch hour to work on his stock portfolio.

My view of his attitude was that we all know how to program, you staff
managers take care of things. I'll watch.

Then, a new guy came in. His background was managing a card shop at a
large plant. He reminded me of a first Sargent. Everything has to be
lined up by size, nothing left on a desk overnight, etc. However, he
was used to listening to his equipment salespeople, and when they and
people in the staff began to suggest a training program, he bought the
idea, and did a better than average job seeing that the training paid off.

After all, everything we did as a service to the company was funded
by cost savings. I was in no position to judge the outcome, but having
a part in some of the training programs, I found that it was well
received, and that in my opinion, there was no way, did the training
cost us money.

Yet, when it came down to some of the training programs, the bosses
exercised "discretion' and only supported part of the over all 
objective.  As an example, the trend became to use Structured 
Programming,but some of the elements were overlooked for cost savings!
Such as weekly review by team members. In the long run, something else
may have replaced it, but the attitude became supportive of staying
aware of the progress of tools, and the rapid adoption of them.

It was like a breath of fresh air. Something I could use a little of
right now. New Jersey vs Arizona. Guess which one I favor.

Warren Simmons



docdwarf@panix.com wrote:
> In article <joe_zitzelberger-B0D300.10185919062004@corp.supernews.com>,
> Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:
> 
>>In article <217e491a.0406182249.4cd3715d@posting.google.com>,
>>riplin@Azonic.co.nz (Richard) wrote:
> 
> 
> [snip]
> 
> 
>>>There is nothing in 'structured programming' that prohibits the use of
>>>GO TO, though it may restrict the scope of its use.
>>>
>>>Personally I find that I never need GO TO and have a style in which it
>>>can not be useful.
>>
>>There may not be a prohibition on GO TO in someones specific 
>>implementation of 'Cobol Structured Programming' (that guy that wrote up 
>>the perform/thru/goto/exit comes to mind).  But there are plenty of 
>>prohibitions against it in generic structured programming.  Quite 
>>simply, it makes programs unstructured.
> 
> 
> Quite simply, things might not be as they are described as 'quite simply'.  
> I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
> defined as allowing for a GO TO which directed execution to the top of the
> paragraph which contained the statement, to the -EXIT paragraph THRU which
> the containing paragraph was PERFORMed or to the -ABEND routine of the
> program... those three and no more.
> 
> If these teaching were correct then a method of structuring is defined as 
> allowing for a GO TO and therefore, quite simply, it does *not* make a 
> program unstructured.
> 
> DD
> 
0
wsimmons5 (172)
6/20/2004 3:15:15 AM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40d49134.273240416@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
[snip]
> > Now OO does have some really useful
> >functionality, in many cases the types of applications that Cobol is
> >commonly used for does not need this functionality.
>
> It sounds like you're referring to batch programs. I think they need OO
more
> than realtime, because they tend to be larger.

No, Mr Wagner, batch programs do not need OO at all. However,
it seems to me that Mr Plinston is referring to Object Oriented
Programming while you seem to be relying on the use of OO
features to accomplish Modular Programming.

Bjarne Stroustrup, "The C++ Programming Language," Third
Edition, Addison-Wesley, 1997, page 725-726.

"Consider design that ignores classes. The resulting C++ program
will be roughly equivalent to the C program that would have resulted
from the same design process -- and this program would again be
roughly equivalent to the COBOL program that would have resulted
from the same design process. In essence, the design has been
made 'programming language independent' at the cost of forcing
the programmer to code in the common subset of C and COBOL.
This approach does have advantages. For example, the strict
separation of data and code that results makes it easy to use
traditional databases that are designed for such programs. Because
a minimal programming language is used, it would appear that less
skill -- or at least different skills -- would be required from programmers.
For many applications -- say, a traditional sequential database update
program -- this way of thinking is quite reasonable, and the traditional
techniques developed over decades are adequate for the job.

"However, suppose the application differs sufficiently from traditional
sequential processing of records (or characters) or the complexity
involved is higher -- say, in an interactive CASE system. The lack of
language support for data abstraction implied by the decision to
ignore classes will hurt. The inherent complexity will show up in the
application somewhere, and if the system is implemented in an
impoverished language, the code will not reflect the design directly.
The program will have too many lines of source code, lack type
checking and will in general not be amenable to tools. This is a
prescription for a maintenance nightmare."

Of course, Mr Wagner, COBOL programmers are not forced 'to code
in the common subset of C and COBOL'.

A couple pithy quotes:

1. Object Oriented Programming is the use of an Object Oriented
Programing Language to implement an Object Oriented Design.

2. Object Oriented Programming -- like Structured Programming -- is
defined by its principles and practices; not the mere use of langauge
elements.

When using the term 'OO', one must be careful to distinguish between
Object Oriented Programming and the mere use of language elements.
Mr Wagner, it is not clear to me that you are making such a distinction;
while Mr Plinston, by referring to the 'functionality' of OO, was making
a distinction.

When Stroustrup wrote 'The resulting C++ program will be roughly
equivalent to the C program ...', he may have been referring to
Procedural Programming (page 23) or, more likely, Modular
Programming (page 26); but was excluding Object Oriented
Programming. ('Consider design that ignores classes').

Procedural Programming in C++, C, and COBOL, tends to result
in a small number of large source programs.

Modular programming in COBOL may be accomplished by using
the object oriented features in recent implementations or by using
the ENTRY statement extension in earlier implementations; and
in C++ and C with data and functions partitioned appropriately into
separate source files. Thus Modular Programming results in a larger
number of smaller souce programs.

In the second, quoted paragraph, Stroustrup discusses how those
OO language features (Mr Plinston's 'functionality') that support
abstraction become useful when batch processing ('traditional
sequential processing of records') does not apply.

In summary, Mr Wagner, the use of OO features to improve
modularity in traditional COBOL applications is a good thing; but
Object Oriented Programming is not a particularly useful
improvement for traditional COBOL programming.



0
ricksmith (875)
6/20/2004 4:27:55 AM
robert.deletethis@wagner.net (Robert Wagner) wrote

> >There is nothing in 'structured programming' that prohibits the use of
> >GO TO, though it may restrict the scope of its use.
> 
> It seems odd that so many misinterpreted structured programming the same way.

It may seem odd to you, but as structured programming did not disallow
the use of GO TO then it is probably you that made this
misinterpretation.  In fact it was not until ANS'84 that elimination
of the GO TO was practical, decades after structured programming.
 
> >No. That is not the case.  Much of the OO features in C++, for
> >example, are to solve the problems of the C language.  In many cases
> >Cobol never had those problems. 
> 
> It has other problems that would be solved by OO. Number one is massive
> monolithic programs.

Massive monolithic programs are not a feature, nor a requirement, of
Cobol.  They can be done, or avoided, in any language, even in C++. 
In fact it is not a problem that is solved by OO, but one that is
solved by CALL which has been available since the early 60s.

> Another is passing decisions 'under the covers' via data
> stored in memory or in a file. A decision is made in program A; an action based
> on that decision occurs in program B. Hopefully OO would make it clear that the
> decision and action should be packaged together. 

Until you make it clear what exactly you are talking about then I
can't comment on this.

> > Now OO does have some really useful
> >functionality, in many cases the types of applications that Cobol is
> >commonly used for does not need this functionality. 
> 
> It sounds like you're referring to batch programs. I think they need OO more
> than realtime, because they tend to be larger.

What particular OO features do you think that batch programs need ?

> Now that we have gigabytes of memory, garbage collection seems obsolete.

No. It isn't.

> Moreover, I thought the virtual memory manager's job was to identify a
> program's working set. 

What has that to do with it ?

> I disagree. Pointers let you build lists with no practical size limit, and don't
> require that every entry be padded to its maximum size. When the number of
> dimensions in a data structure goes above 1, arrays can become unmanagably
> large .. even with lots of memory.

You may not notice that this conflicts with you claims that there are
'gigabytes of memory' and a virtual memory, but I do.

In fact there is usually very little reason to build huge lists in
memory, haven't you heard about sharing data ?  You can't share it
from a list.  The data should be in databases or even ISAM files,
which have no practical limit, can be permanent and can be shared.

The problem with pointers is that they are the 'GO TO' of data.  They
are easy to misuse and difficult to maintain full control of.

As I say, you never learnt the lessons of C in the 70s and so do not
know why they should not be used as you promote.


> Cobol uses pointers on every CALL. One can exploit that by passing a pointer BY
> CONTENT to a program expecting a reference. It was a handy technique in the days
> of memory mapped screens. 

I never went much down the path of grubbying around fiddling the
hardware, that was the lowly DOS domain with single-tasking and having
to pass files around on diskettes.

> Given Cobol programmers' aversion to prototypes,
> there's no type-safety across a CALL. 

There is also no 'type safety' with a pointer, you are just raising
other reasons why they should not be used where they can be avoided.


> Cobol pointers are less error-prone than C pointers. In Cobol, you set it once
> and it says set until you change it. In C, you have to say the pointer's name on
> *every blasted reference*. If you name the wrong pointer, the compiler 
> generates misbehaving code.

Excuse me but 'naming the wrong pointer' is just the same as 'naming
the wrong variable'.  If you 'name the wrong pointer' in your SET
statement then the compiler will generate the wrong code too.

> They were deleted for SECURITY reasons, not because they were unneeded. 

Yet, strangely, it is still possible to write programs without them.
 
> Because some people 'always had trouble with pointers'. Generally the same ones
> who 'always had trouble with complex conditionals'. Those people are better
> suited be managers, testers or administrators.

So, in your world, incompetence is rewarded with promotion ?  _That_
must be why you're still a coder.

> I could write a FAST collection class. Would that be better?

We only have your word for that.
0
riplin (4127)
6/20/2004 6:43:16 AM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40d4d6df.291078207@news.optonline.net...
> docdwarf@panix.com wrote:
>
> >Quite simply, things might not be as they are described as 'quite
simply'.
> >I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
> >defined as allowing for a GO TO which directed execution to the top of
the
> >paragraph which contained the statement, to the -EXIT paragraph THRU
which
> >the containing paragraph was PERFORMed or to the -ABEND routine of the
> >program... those three and no more.
>
> The standards committee dropped the ball twice. First they gave us PERFORM
...
> THRU, which was intended for the case where we sometimes perform a and
other
> times perform a thru b. It wasn't intended to be an exit mechanism, but it
> quickly devolved into one.

14.3 Procedures. "A procedure is composed of a paragraph, or
a group of successive paragraphs, or a section, or a group of
successive sections within the procedure division." I would
speculate that PERFORM THRU was intended to provide a means
for executing a procedure where that procedure is composed of
a group of successive paragraphs or sections.

> They could have corrected the abuse by giving us EXIT PARAGRAPH in '85 or
'02.
> If we had EXIT PARAGRAPH, there would be no excuse to perform THRU an exit
nor
> GO TO an exit.

Both EXIT PARAGRAPH and EXIT SECTION were added to
standard COBOL for 2002. Both have been extensions to
Micro Focus COBOL for more than 10 years.

> We can EXIT FUNCTION, EXIT METHOD, EXIT PROGRAM and EXIT PERFORM. The
absence of
> EXIT PARAGRAPH seems oddly irregular. I speculate its absence was due to
the
> aforementioned THRU. If a program said 'perform a thru c' and paragraph a
said
> exit paragraph, where would control go? Logically, it would go to the
paragraph
> following a. But poorly written unstructured programs might not have a. b.
and
> c. in a straight line. The paragraph following a. might be z., which is
> logically unrelated. Paragraph a. might rely on GO TO to transfer control
to
> either b. or c.
>
> So we're stuck with 'the sins of the fathers'. It all started with the
seemingly
> innocuous THRU.

Mr Wagner, there was no sin, so we're not stuck with it.



0
ricksmith (875)
6/20/2004 7:01:28 AM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> The standards committee dropped the ball twice. First they gave us PERFORM ..
> THRU, which was intended for the case where we sometimes perform a and other
> times perform a thru b. It wasn't intended to be an exit mechanism, but it
> quickly devolved into one.

How are you able to know what the standard was _intended_ for ?
 
> They could have corrected the abuse by giving us EXIT PARAGRAPH in '85 or '02.
> If we had EXIT PARAGRAPH, there would be no excuse to perform THRU an exit nor
> GO TO an exit. 

> We can EXIT FUNCTION, EXIT METHOD, EXIT PROGRAM and EXIT PERFORM. The absence of
> EXIT PARAGRAPH seems oddly irregular. 

Given that EXIT FUNCTION, EXIT METHOD, EXIT PERFORM and EXIT PARAGRAPH
are identical in being all extensions in any '85 based compiler and
being in the '02 standard, then it seems the only irregularity is you
knowledge of what is or is not in the standards.

> I speculate its absence was due to the
> aforementioned THRU. If a program said 'perform a thru c' and paragraph a said
> exit paragraph, where would control go? Logically, it would go to the
> paragraph
> following a. But poorly written unstructured programs might not have a. b. and
> c. in a straight line. The paragraph following a. might be z., which is
> logically unrelated. Paragraph a. might rely on GO TO to transfer control to
> either b. or c.

So exactly why would you want to use EXIT PARAGRAPH ?

> So we're stuck with 'the sins of the fathers'. It all started with the
> seemingly
> innocuous THRU.

Any and all features can be abused.  Personally I never use THRU, but
then I would never use EXIT PARAGRAPH either.
0
riplin (4127)
6/20/2004 7:07:14 AM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> Fine, but the subordinate program shouldn't be expected to supply the NAME of
> the next program. 

And whyever not ?  The menu program certainly does.  A CALL literal
certainly does.  In fact in my systems the menu program does not know
the name of very much at all, it gets the menu text, program names and
security items from the system control file (via a called routine) and
so can any program if it requires any particular names to use.
 
> >Some of these systems originated when memory was a limited resource
> >sparingly used.  Some were running on 64Kb 8085 networked machines and
> >are still in use (though updated and enhanced) because they meet the
> >users needs.
> 
> "Meets their needs" is an euphemism for 'they can tolerate its inadequacies.'

Which particular 'inadequacies' are you referring to ?  Please do tell
me exactly what these are.

> Those limits are now largely gone, but the coping mechanisms we developed over
> 40+ years are not.

Said by someone who still seems stuck in the 'coping mechanisms' of
the 70s and 80s.
0
riplin (4127)
6/20/2004 7:18:29 AM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> Yes. I recently posted here findings from US employment ads breaking the market
> down by platform and compiler. If you have information from other sources,
> please share it.

Yes, you recently posted a list of empty desks, and not for example
any numbers relating to actual users, let alone numbers of compilers
used. But even those figures did not come to your '98+%' which was
just your usual hyperbole.

As to the number of Kobol, OpenCobol and TinyCobol compilers being
used, you certainly won't find those in the employment ads, but they
are still compilers, they are still used.

Perhaps you meant something else, again.  Such as the number of desks
in corporate DP departments which could access Cobol compilers and
_weren't_ being advertised.
0
riplin (4127)
6/20/2004 7:25:11 AM
Robert Wagner wrote:
> docdwarf@panix.com wrote:
> 
> 
>>Quite simply, things might not be as they are described as 'quite simply'.  
>>I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
>>defined as allowing for a GO TO which directed execution to the top of the
>>paragraph which contained the statement, to the -EXIT paragraph THRU which
>>the containing paragraph was PERFORMed or to the -ABEND routine of the
>>program... those three and no more.
> 
> 
> The standards committee dropped the ball twice. First they gave us PERFORM ..
> THRU, which was intended for the case where we sometimes perform a and other
> times perform a thru b. It wasn't intended to be an exit mechanism, but it
> quickly devolved into one.
> 
> They could have corrected the abuse by giving us EXIT PARAGRAPH in '85 or '02.
> If we had EXIT PARAGRAPH, there would be no excuse to perform THRU an exit nor
> GO TO an exit. 
> 
> We can EXIT FUNCTION, EXIT METHOD, EXIT PROGRAM and EXIT PERFORM. The absence of
> EXIT PARAGRAPH seems oddly irregular. I speculate its absence was due to the
> aforementioned THRU. If a program said 'perform a thru c' and paragraph a said
> exit paragraph, where would control go? Logically, it would go to the paragraph
> following a. But poorly written unstructured programs might not have a. b. and
> c. in a straight line. The paragraph following a. might be z., which is
> logically unrelated. Paragraph a. might rely on GO TO to transfer control to
> either b. or c.
> 
> So we're stuck with 'the sins of the fathers'. It all started with the seemingly
> innocuous THRU.

However, they have made "exit sentence"(in the form of next sentence) 
obsolete.

Donald

0
donald_tees (563)
6/20/2004 11:17:08 AM
Robert Wagner wrote:
> 
> Fine, but the subordinate program shouldn't be expected to supply the NAME of
> the next program. 
> 

Why ever not?  I have worked on at least half a dozen Var packages in 
Cobol that loaded menu's according to how it was set up for that 
paricular customer.

Donald

0
donald_tees (563)
6/20/2004 11:22:49 AM
In article <40d4d6df.291078207@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>>Quite simply, things might not be as they are described as 'quite simply'.  
>>I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
>>defined as allowing for a GO TO which directed execution to the top of the
>>paragraph which contained the statement, to the -EXIT paragraph THRU which
>>the containing paragraph was PERFORMed or to the -ABEND routine of the
>>program... those three and no more.
>
>The standards committee dropped the ball twice.

Attributed to Alfonso X (The Wise) of Spain: 'Had I bben present at the 
creation I would have given some useful hints for the better ordering of 
the universe.'

The standards committee did what they did, Mr Wagner, and what resulted is 
called COBOL and not Modula II.  Given what the committee approved as 
COBOL I was taught what I stated above, a definition of programming 
structure which allowed for GO TO under those three conditions.

DD
0
docdwarf (6044)
6/20/2004 11:30:28 AM
Robert Wagner wrote:
> 
> I wrote DYL240, the first in the series, on a Spectra 70.
> 
> Later, I was embarrassed by its RPG-like 'language'. If I had it to do over, I
> would have used a freeform language.

Now why is that?  There are advantages to fixed-format languages:
readability for one thing; restriction of what can go into each field
(cuts down on the more fantastic extensions to a verb that might
otherwise be attempted); similarity of format, verb by verb,  means that
it's easier to learn; etc.

I know people who hate RPG because it's fixed-form but that doesn't make
sense to me.  

Just curious.

PL
0
lacey (134)
6/20/2004 3:11:10 PM
docdwarf@panix.com wrote:

>In article <40d46df5.264215145@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>docdwarf@panix.com wrote:
>>
>>>In article <40d3f68b.233641146@news.optonline.net>,
>>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>>
>>>[snip]
>>>
>>>>Policy determines the fate of systems and institutions. Politics determines
the
>>>>fate of individuals. Although both are based on the same Greek root word
"pol",
>>>>meaning people, they refer to different mental processes. Policy is rational
>>>>whereas politics is emotional. 
>>>
>>>Mr Wagner, this Greek derivation you assert... do you have any 
>>>documentation for it?  My memory is, admittedly, porous and I was taught 
>>>such things a... few years back but I seem to recall that the root for 
>>>politics and policy was, ultimately, from the Greek 'polis' 
>>>(pi-omicron-lambda-iota-sigma), or 'city'... and that the entry for 
>>>'polis' in the Liddell and Scott lexicon was in Capital letters, 
>>>indicating a Root or Primitive Form.
>>
>>I stand corrected; I should have written 'polis'. (I actually saw the error
>>seconds after posting, hoped no one would notice.)
>>
>>>Where can you cite a source for this 'pol' = people?
>>
>>It means civilized people, in contrast to tribal people. 
>
>Mr Wagner, according to the Liddell and Scott lexicon the root/primitive 
>form is 'polis'; 'pol' is not a word in Ancient Greek.  As for 'civilised' 
>versus 'polis-ticised' versus 'urbanised'... well, as what you snipped 
>from my original posting may have indicated, this might be another 
>discussion, entire.

Please take it to alt.pedantry. We're here to discuss Cobol and potty humor.

0
6/20/2004 3:49:01 PM
"Rick Smith" <ricksmith@mfi.net> wrote:

>Both EXIT PARAGRAPH and EXIT SECTION were added to
>standard COBOL for 2002.

Great! It's not in my draft version. Must have been a late addition.

> Both have been extensions to Micro Focus COBOL for more than 10 years.

That wouldn't help mainframers here (unless they're using Micro Focus' fine
mainframe compiler).


0
6/20/2004 3:49:01 PM
"Rick Smith" <ricksmith@mfi.net> wrote:

>Bjarne Stroustrup, "The C++ Programming Language," Third
>Edition, Addison-Wesley, 1997, page 725-726.
>
>"Consider design that ignores classes. The resulting C++ program
>will be roughly equivalent to the C program that would have resulted
>from the same design process -- and this program would again be
>roughly equivalent to the COBOL program that would have resulted
>from the same design process. In essence, the design has been
>made 'programming language independent' at the cost of forcing
>the programmer to code in the common subset of C and COBOL.
>This approach does have advantages. For example, the strict
>separation of data and code that results makes it easy to use
>traditional databases that are designed for such programs. Because
>a minimal programming language is used, it would appear that less
>skill -- or at least different skills -- would be required from programmers.
>For many applications -- say, a traditional sequential database update
>program -- this way of thinking is quite reasonable, and the traditional
>techniques developed over decades are adequate for the job.

Stroustrup wants to create two classes of programmers: a lower class that does
boring, repetitive work using unsophisticated tools, and an upper class that
handles complex problems through the use of intelligence and education. This
elitist attitude is common in academia, where Dr. Stroustrup has spent his
entire life. 

>"However, suppose the application differs sufficiently from traditional
>sequential processing of records (or characters) or the complexity
>involved is higher -- say, in an interactive CASE system. The lack of
>language support for data abstraction implied by the decision to
>ignore classes will hurt. The inherent complexity will show up in the
>application somewhere, and if the system is implemented in an
>impoverished language, the code will not reflect the design directly.
>The program will have too many lines of source code, lack type
>checking and will in general not be amenable to tools. This is a
>prescription for a maintenance nightmare."

That's a pretty accurate description of a typical Cobol shop, showing it too
would benefit from OO.

>A couple pithy quotes:
>
>1. Object Oriented Programming is the use of an Object Oriented
>Programing Language to implement an Object Oriented Design.

I've seen OO Design implemented in a non-OO language, through the use of many
called programs .. modular programming.

>2. Object Oriented Programming -- like Structured Programming -- is
>defined by its principles and practices; not the mere use of langauge
>elements.

The converse is more common -- traditional design implemented in an OO language,
typically C++. Well, at least compiled with a C++ compiler. Inspection of the
code reveals it's largely straight C, but they tell everyone they're using C++.

A variant is straight Cobol painted with lipstick and wearing an OO dress. It is
characterized by many INVOKE SELF, which replace PERFORM.

>When using the term 'OO', one must be careful to distinguish between
>Object Oriented Programming and the mere use of language elements.
>Mr Wagner, it is not clear to me that you are making such a distinction;
>while Mr Plinston, by referring to the 'functionality' of OO, was making
>a distinction.

Point taken.

>Procedural Programming in C++, C, and COBOL, tends to result
>in a small number of large source programs.
>
>Modular programming in COBOL may be accomplished by using
>the object oriented features in recent implementations or by using
>the ENTRY statement extension in earlier implementations; and
>in C++ and C with data and functions partitioned appropriately into
>separate source files. Thus Modular Programming results in a larger
>number of smaller souce programs.

We do it with CALL, not with OO nor ENTRY. 

>In the second, quoted paragraph, Stroustrup discusses how those
>OO language features (Mr Plinston's 'functionality') that support
>abstraction become useful when batch processing ('traditional
>sequential processing of records') does not apply.

Stroustrup did not show how it follows that OO functionality does not apply to
batch processing. His assertion is not suppored by argumentation.

>In summary, Mr Wagner, the use of OO features to improve
>modularity in traditional COBOL applications is a good thing; but
>Object Oriented Programming is not a particularly useful
>improvement for traditional COBOL programming.

Ok, how about when Cobol is used for NONtraditional  applications? 

Let me guess .. another language is 'a better tool for the job.' Sounds like a
circular argument.
0
6/20/2004 3:49:02 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> >There is nothing in 'structured programming' that prohibits the use of
>> >GO TO, though it may restrict the scope of its use.
>> 
>> It seems odd that so many misinterpreted structured programming the same way.
>
>It may seem odd to you, but as structured programming did not disallow
>the use of GO TO then it is probably you that made this
>misinterpretation.  In fact it was not until ANS'84 that elimination
>of the GO TO was practical, decades after structured programming.

Wrong. I stopped using GO TO in the '60s.

>Massive monolithic programs are not a feature, nor a requirement, of
>Cobol.  They can be done, or avoided, in any language, even in C++. 
>In fact it is not a problem that is solved by OO, but one that is
>solved by CALL which has been available since the early 60s.

True, but Cobol is plagued with large programs more than other languages. It
seems a feature of 'Cobol culture' as practiced in big shops.

>> > Now OO does have some really useful
>> >functionality, in many cases the types of applications that Cobol is
>> >commonly used for does not need this functionality. 
>> 
>> It sounds like you're referring to batch programs. I think they need OO more
>> than realtime, because they tend to be larger.
>
>What particular OO features do you think that batch programs need ?

Reusability.

Packaging logic close to the data it operates on. 

Packaging ALL logic that operates on a particular datum in one place. 

Ability to define structures more complex than a record or array.

Ability to perform operations on those structures more complex than Copy,
facilitating abstraction in design.

Ability to change logic by overriding rather than modifying existing logic,
especially useful when you don't have access to existing third-party code.

Separation between low-level mechanics (reading files) and application logic.

>> Now that we have gigabytes of memory, garbage collection seems obsolete.
>
>No. It isn't.
>
>> Moreover, I thought the virtual memory manager's job was to identify a
>> program's working set. 
>
>What has that to do with it ?

Garbage gets paged out of real memory.

>> I disagree. Pointers let you build lists with no practical size limit, and
don't
>> require that every entry be padded to its maximum size. When the number of
>> dimensions in a data structure goes above 1, arrays can become unmanagably
>> large .. even with lots of memory.
>
>You may not notice that this conflicts with you claims that there are
>'gigabytes of memory' and a virtual memory, but I do.

Even with "lots of memory", multi-dimensional arrays can grow to
multi-gigabytes. For instance, I wrote a 'program' (a series of modular
programs) that parses freeform text documents, a very common data warehousing
problem. Suppose I had allocated 30 bytes per word (not enough, as Cobol has
shown), 20 words per line, 10,000 lines per document and a maximum of 3,000
documents (way too small). My array would have taken 18GB. If I'd carelessly
used INITIALIZE, every one of those bytes would have been touched.

Because I used lists, it ran in 500MB.

>In fact there is usually very little reason to build huge lists in
>memory, haven't you heard about sharing data ?  You can't share it
>from a list. 

Sure you can. That's what IPC is for.

> The data should be in databases or even ISAM files,
>which have no practical limit, can be permanent and can be shared.

Databases and files are for transport through TIME. Using them just to organize
data in SPACE is a waste of resources. Any organization a file system can do,
can be done in memory much faster. 

Take the case of sorting an array. You _could_ insert the rows into an indexed
file and read them back in sequence. I've seen programs do that. It's the mark
of an amateur programmer. 

>The problem with pointers is that they are the 'GO TO' of data.

Only if they are single-threaded. The simplest tree is as fast as a binary
lookup on an array. A tree can be made faster by increasing its width; an array
cannot be speeded up.

>  They are easy to misuse and difficult to maintain full control of.

I don't have that problem.

>As I say, you never learnt the lessons of C in the 70s and so do not
>know why they should not be used as you promote.

As you also say, any language and feature can be abused. 

>> They were deleted for SECURITY reasons, not because they were unneeded. 
>
>Yet, strangely, it is still possible to write programs without them.

Every Cobol programmer knows that. 

If I hadn't used pointers, the aforementioned freeform text program would have
been impractical. It would have taken all day to process 3,000 reports rather
than 5 minutes.

In fact, it was considered impractical, which is why it hadn't been written
sooner.

>So, in your world, incompetence is rewarded with promotion ?  _That_
>must be why you're still a coder.

I was a manager for 20 years. Now I'm a code cranker by choice, 'cause I love
it.

0
6/20/2004 3:49:04 PM
Donald Tees <donald_tees@sympatico.ca> wrote:

>However, they have made "exit sentence"(in the form of next sentence) 
>obsolete.

They should have made it obsolete when they made periods optional. NEXT SENTENCE
is a bugtrap.

0
6/20/2004 5:06:31 PM
docdwarf@panix.com wrote:

>The standards committee did what they did, Mr Wagner, and what resulted is 
>called COBOL and not Modula II.  Given what the committee approved as 
>COBOL I was taught what I stated above, a definition of programming 
>structure which allowed for GO TO under those three conditions.

When you get EXIT PARAGRAPH, the number will be down to two. 

Perhaps you should lobby for RESTART PARAGRAPH. Why would a program want to do
that? State machine? In any case, PERFORM UNTIL at the top will do the same.

0
6/20/2004 5:06:32 PM
Donald Tees <donald_tees@sympatico.ca> wrote:

>Robert Wagner wrote:
>> 
>> Fine, but the subordinate program shouldn't be expected to supply the NAME of
>> the next program. 
>> 
>
>Why ever not?  I have worked on at least half a dozen Var packages in 
>Cobol that loaded menu's according to how it was set up for that 
>paricular customer.

In that case, the name came from a file or database. My objection was to
hardcoded names. 
0
6/20/2004 5:06:33 PM
Peter Lacey <lacey@mb.sympatico.ca> wrote:

>Robert Wagner wrote:
>> 
>> I wrote DYL240, the first in the series, on a Spectra 70.
>> 
>> Later, I was embarrassed by its RPG-like 'language'. If I had it to do over,
I
>> would have used a freeform language.
>
>Now why is that?  There are advantages to fixed-format languages:
>readability for one thing; restriction of what can go into each field
>(cuts down on the more fantastic extensions to a verb that might
>otherwise be attempted); similarity of format, verb by verb,  means that
>it's easier to learn; etc.

Ease of learning was the primary design criterion.

At the time (late '60s), I worked at a service bureau (in Burbank, Ca) that
specialized in magazine and junk mail lists. My programmers were spending more
than half their time on one-time requests such as 'pull every 20th name for a
test mailing and remember who they were so we don't use them again in the big
mailing.' To free up programmer time, I wrote a tool that could be used by clerk
who had above average intelligence but was not a programmer. 

It worked. She handled about 95% of the requests. The programming staff
available to work on Real Programming was doubled. A former manager, 'Wild' Bill
Newcomer, liked it so much, he started Dylakor and built a career on the program
and its successors. (Dylakor was acquired by Sterling in 1983. Sterling was
acquired by CA in 2000).

DYL240 was a JIT compiler that spit machine language into memory. It had an
undocumented feature -- it understood assembly language mnemonics too. This
allowed programmers to make it do anything the machine could do. Somewhere along
the line, Dylakor turned it into a SLOW interpreter. A few years ago, when I
used QuikJob, I was saddened to see my zippy little sports car had turned into a
lumbering truck. CA offers a compiler as an extra-cost option (I assume, 'cause
the shop didn't use it). 

>I know people who hate RPG because it's fixed-form but that doesn't make
>sense to me.  

I thought RPG went free-form in the '80s, when the AS/400 was introduced.
0
6/20/2004 5:06:34 PM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40d5afd3.346626239@news.optonline.net...
> "Rick Smith" <ricksmith@mfi.net> wrote:
>
> >Bjarne Stroustrup, "The C++ Programming Language," Third
> >Edition, Addison-Wesley, 1997, page 725-726.
> >
> >"Consider design that ignores classes. The resulting C++ program
> >will be roughly equivalent to the C program that would have resulted
> >from the same design process -- and this program would again be
> >roughly equivalent to the COBOL program that would have resulted
> >from the same design process. In essence, the design has been
> >made 'programming language independent' at the cost of forcing
> >the programmer to code in the common subset of C and COBOL.
> >This approach does have advantages. For example, the strict
> >separation of data and code that results makes it easy to use
> >traditional databases that are designed for such programs. Because
> >a minimal programming language is used, it would appear that less
> >skill -- or at least different skills -- would be required from
programmers.
> >For many applications -- say, a traditional sequential database update
> >program -- this way of thinking is quite reasonable, and the traditional
> >techniques developed over decades are adequate for the job.
>
> Stroustrup wants to create two classes of programmers: a lower class that
does
> boring, repetitive work using unsophisticated tools, and an upper class
that
> handles complex problems through the use of intelligence and education.
This
> elitist attitude is common in academia, where Dr. Stroustrup has spent his
> entire life.

You are confused. Dr Stroustrup is a long-time employee of AT&T.

> >"However, suppose the application differs sufficiently from traditional
> >sequential processing of records (or characters) or the complexity
> >involved is higher -- say, in an interactive CASE system. The lack of
> >language support for data abstraction implied by the decision to
> >ignore classes will hurt. The inherent complexity will show up in the
> >application somewhere, and if the system is implemented in an
> >impoverished language, the code will not reflect the design directly.
> >The program will have too many lines of source code, lack type
> >checking and will in general not be amenable to tools. This is a
> >prescription for a maintenance nightmare."
>
> That's a pretty accurate description of a typical Cobol shop, showing it
too
> would benefit from OO.

Please, Mr Wagner, is it typical to use COBOL for interactive
CASE?

> >A couple pithy quotes:
> >
> >1. Object Oriented Programming is the use of an Object Oriented
> >Programing Language to implement an Object Oriented Design.
>
> I've seen OO Design implemented in a non-OO language, through the use of
many
> called programs .. modular programming.

Actually, I think it more typical to use EVALUATE/WHEN and
switch/case to implement parts of an OOD. The point was that
to do OOP, one must deal with abstractions presented in the OOD
and an OOPL is not 'an impoverished language'. That using
'an impoverished language' will result in an unfaithful translation
of the OOD and therefore not be OOP.

> >2. Object Oriented Programming -- like Structured Programming -- is
> >defined by its principles and practices; not the mere use of langauge
> >elements.
>
> The converse is more common -- traditional design implemented in an OO
language,
> typically C++. Well, at least compiled with a C++ compiler. Inspection of
the
> code reveals it's largely straight C, but they tell everyone they're using
C++.

Mr Wagner, the point is that if one is using C++ as a better C and
claims they are doing OOP, they are incorrect.

> A variant is straight Cobol painted with lipstick and wearing an OO dress.
It is
> characterized by many INVOKE SELF, which replace PERFORM.
>
> >When using the term 'OO', one must be careful to distinguish between
> >Object Oriented Programming and the mere use of language elements.
> >Mr Wagner, it is not clear to me that you are making such a distinction;
> >while Mr Plinston, by referring to the 'functionality' of OO, was making
> >a distinction.
>
> Point taken.
>
> >Procedural Programming in C++, C, and COBOL, tends to result
> >in a small number of large source programs.
> >
> >Modular programming in COBOL may be accomplished by using
> >the object oriented features in recent implementations or by using
> >the ENTRY statement extension in earlier implementations; and
> >in C++ and C with data and functions partitioned appropriately into
> >separate source files. Thus Modular Programming results in a larger
> >number of smaller souce programs.
>
> We do it with CALL, not with OO nor ENTRY.

Actually, with CALL/ENTRY or INVOKE/<method-name> on a
single instance of an object that remains active and is merely
re-populated sequentially.

> >In the second, quoted paragraph, Stroustrup discusses how those
> >OO language features (Mr Plinston's 'functionality') that support
> >abstraction become useful when batch processing ('traditional
> >sequential processing of records') does not apply.
>
> Stroustrup did not show how it follows that OO functionality does not
apply to
> batch processing. His assertion is not suppored by argumentation.

Mr Wagner, the support was in the first, quoted paragraph.
"For example, the strict separation of data and code that results
makes it easy to use traditional databases that are designed for
such programs." Traditional databases do not hold objects.
Upon reading the database (or file), it becomes necesary to
instantiate an object and fill that object (including the objects for
any object references that are its properties) from the data before
it can be used. Finally the object must be deleted. This is a lot
of unnecessary overhead for the types of simple objects that
are used in 'traditional sequential processing of records'.
Stroustrup suggests that when 'the complexity involved is higher'
ignoring classes 'will hurt'.

> >In summary, Mr Wagner, the use of OO features to improve
> >modularity in traditional COBOL applications is a good thing; but
> >Object Oriented Programming is not a particularly useful
> >improvement for traditional COBOL programming.
>
> Ok, how about when Cobol is used for NONtraditional  applications?

Yes, absolutely, word processing, CAD, simulation, modelling, etc.
Go for it!



0
ricksmith (875)
6/20/2004 6:28:39 PM
In article <40d5b515.347971834@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>>The standards committee did what they did, Mr Wagner, and what resulted is 
>>called COBOL and not Modula II.  Given what the committee approved as 
>>COBOL I was taught what I stated above, a definition of programming 
>>structure which allowed for GO TO under those three conditions.
>
>When you get EXIT PARAGRAPH, the number will be down to two. 

When I work at five sites, consecutively, where Prod Review will allow the 
technique to access live data then I may see things differently; until 
then the client has the final say on the code that will be allowed.

>
>Perhaps you should lobby for RESTART PARAGRAPH.

I do not always do as I 'should', Mr Wagner... but when I see a need for 
me to lobby then I might be a bit closer to that action.

DD
0
docdwarf (6044)
6/20/2004 11:12:29 PM
In article <40d5ae99.346312140@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>>In article <40d46df5.264215145@news.optonline.net>,
>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>>docdwarf@panix.com wrote:
>>>
>>>>In article <40d3f68b.233641146@news.optonline.net>,
>>>>Robert Wagner <robert.deletethis@wagner.net> wrote:
>>>>
>>>>[snip]
>>>>
>>>>>Policy determines the fate of systems and institutions. Politics determines the
>>>>>fate of individuals. Although both are based on the same Greek root word "pol",
>>>>>meaning people, they refer to different mental processes. Policy is rational
>>>>>whereas politics is emotional. 
>>>>
>>>>Mr Wagner, this Greek derivation you assert... do you have any 
>>>>documentation for it?  My memory is, admittedly, porous and I was taught 
>>>>such things a... few years back but I seem to recall that the root for 
>>>>politics and policy was, ultimately, from the Greek 'polis' 
>>>>(pi-omicron-lambda-iota-sigma), or 'city'... and that the entry for 
>>>>'polis' in the Liddell and Scott lexicon was in Capital letters, 
>>>>indicating a Root or Primitive Form.
>>>
>>>I stand corrected; I should have written 'polis'. (I actually saw the error
>>>seconds after posting, hoped no one would notice.)
>>>
>>>>Where can you cite a source for this 'pol' = people?
>>>
>>>It means civilized people, in contrast to tribal people. 
>>
>>Mr Wagner, according to the Liddell and Scott lexicon the root/primitive 
>>form is 'polis'; 'pol' is not a word in Ancient Greek.  As for 'civilised' 
>>versus 'polis-ticised' versus 'urbanised'... well, as what you snipped 
>>from my original posting may have indicated, this might be another 
>>discussion, entire.
>
>Please take it to alt.pedantry. We're here to discuss Cobol and potty humor.

Plural majestatus est, Mr Wagner... is it your habit to request that which 
appears to prove you wrong to be taken elsewhere?

DD

0
docdwarf (6044)
6/20/2004 11:19:51 PM
Robert Wagner wrote:
>
> Stroustrup wants to create two classes of programmers: a lower class
> that does boring, repetitive work using unsophisticated tools, and an
> upper class that handles complex problems through the use of
> intelligence and education. This elitist attitude is common in
> academia, where Dr. Stroustrup has spent his entire life.

I wouldn't say the technique is limited to academia. It exists at McDonalds
and at Exxon, at hospitals and auto repair shops. It exists in government.
It existed when the pyramids were built and I hope it still exists when we
colonize Mars.

While "elitism" is a belief that certain groups should get benefits because
of intellect or wealth, I suggest elitism is a belief based on fact.
Moreover, people with a greater intellect or wealth should get favored
treatement.


0
nospam312 (645)
6/21/2004 12:42:26 AM
Robert Wagner wrote:
>>
>> You may not notice that this conflicts with you claims that there are
>> 'gigabytes of memory' and a virtual memory, but I do.
>
> Even with "lots of memory", multi-dimensional arrays can grow to
> multi-gigabytes. For instance, I wrote a 'program' (a series of
> modular programs) that parses freeform text documents, a very common
> data warehousing problem. Suppose I had allocated 30 bytes per word
> (not enough, as Cobol has shown), 20 words per line, 10,000 lines per
> document and a maximum of 3,000 documents (way too small). My array
> would have taken 18GB. If I'd carelessly used INITIALIZE, every one
> of those bytes would have been touched.
>
> Because I used lists, it ran in 500MB.

And used hundreds of statements instead of one?

>
> Take the case of sorting an array. You _could_ insert the rows into
> an indexed file and read them back in sequence. I've seen programs do
> that. It's the mark of an amateur programmer.

No, it's the mark of an efficient programmer. The ISAM I-O routines are far
more efficient than any code to insert a row in a table. For
reasonable-sized tables, there's not even any disk activity.

[snip more opinion]


0
nospam312 (645)
6/21/2004 12:48:00 AM
docdwarf@panix.com wrote:
>>
>> Please take it to alt.pedantry. We're here to discuss Cobol and
>> potty humor.
>
> Plural majestatus est, Mr Wagner... is it your habit to request that
> which
> appears to prove you wrong to be taken elsewhere?

The sign that says: "This way to Chicago==>" doesn't actually GO to Chicago
itself. (Although I can't imagine why anyone would actually WANT to go to
Chicago, so, perhaps, the sign is more correct by just standing pat and
issuing orders.)


0
nospam312 (645)
6/21/2004 12:50:42 AM
In article <yaWdnQ84CpdBrUvdRVn-gw@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>docdwarf@panix.com wrote:
>>>
>>> Please take it to alt.pedantry. We're here to discuss Cobol and
>>> potty humor.
>>
>> Plural majestatus est, Mr Wagner... is it your habit to request that
>> which
>> appears to prove you wrong to be taken elsewhere?
>
>The sign that says: "This way to Chicago==>" doesn't actually GO to Chicago
>itself.

Most signs I know of have something written on them... where are you 
finding the talking one?

DD
0
docdwarf (6044)
6/21/2004 12:52:39 AM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d23662.118894516@news.optonline.net...
> docdwarf@panix.com wrote:
>
<snip>
>
> My reason for being here is to promote Cobol as a Real Programming Language
> rather than the travesty that mainframers have turned it into.

It appears (to many readers of CLC) that the *ONLY* purpose that you (Robert
Wagner) have in posting to this group is to make (occasionally - but rarely)
accurate "universal" statements and then continue threads well past the point
that others have shown that your original statements have no "universality" and
often little accuracy.

When you "came" back after your hiatus from the group, one person posted that
they were happy to see you back.  I think that it was (and continues to be) a
much more common hope/desire that you will "go away" again (and stay away
forever).

This will help CLC - and possibly COBOL in a variety of platforms.

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


0
wmklein (2605)
6/21/2004 1:13:49 AM
What version of the draft are you looking at?  As the person who wrote the
original proposal adding them, they were in by a VERY early version of the DRAFT
Standard.  Possibly you have as much trouble reading draft standards as you do
in knowing what is and isn't true about COBOL in general.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d5afcb.346617830@news.optonline.net...
> "Rick Smith" <ricksmith@mfi.net> wrote:
>
> >Both EXIT PARAGRAPH and EXIT SECTION were added to
> >standard COBOL for 2002.
>
> Great! It's not in my draft version. Must have been a late addition.
>
> > Both have been extensions to Micro Focus COBOL for more than 10 years.
>
> That wouldn't help mainframers here (unless they're using Micro Focus' fine
> mainframe compiler).
>
>


0
wmklein (2605)
6/21/2004 1:21:14 AM
"JerryMouse" <nospam@bisusa.com> wrote:

>docdwarf@panix.com wrote:
>>>
>>> Please take it to alt.pedantry. We're here to discuss Cobol and
>>> potty humor.
>>
>> Plural majestatus est, Mr Wagner... is it your habit to request that
>> which
>> appears to prove you wrong to be taken elsewhere?
>
>The sign that says: "This way to Chicago==>" doesn't actually GO to Chicago
>itself. (Although I can't imagine why anyone would actually WANT to go to
>Chicago, so, perhaps, the sign is more correct by just standing pat and
>issuing orders.)

That's a paraphrase from Dickens' Martin Chuzzlewit. He wrote "I likened him to
a signpost, which is always telling the way to a place but never goes there."

I lived in Barrington for a year, 30 miles NW of Chicago, and found it
delightful. The highway system works, unlike the gridlock in our NorthEast and
California. The restaurant scene is as serious as NY or CA without the snobism.
Charlie Trotter, America's greatest chef,  is based out of Chicago.

Everywhere you go, there are wildlife refuges. Betwen suburbs, you're driving
through woods that will never be despoiled. What other city has that?

Chicago is a world-class city with the convenience and amenities of a
medium-sized city.

0
6/21/2004 1:58:37 AM
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d23662.118894516@news.optonline.net...
>> docdwarf@panix.com wrote:
>>
><snip>
>>
>> My reason for being here is to promote Cobol as a Real Programming Language
>> rather than the travesty that mainframers have turned it into.
>
>It appears (to many readers of CLC) that the *ONLY* purpose that you (Robert
>Wagner) have in posting to this group is to make (occasionally - but rarely)
>accurate "universal" statements and then continue threads well past the point
>that others have shown that your original statements have no "universality" and
>often little accuracy.
>
>When you "came" back after your hiatus from the group, one person posted that
>they were happy to see you back.  I think that it was (and continues to be) a
>much more common hope/desire that you will "go away" again (and stay away
>forever).

Why should I care whether you and others like me .. especially after they've
been rude to me? When someone shows me courtesy, I reciprocate. When they show
me disrespect, I respond in like kind. 

Your message would better be directed to Richard and DocDwarf, who both carry on
the pointless threads you object to.

Actually, I returned only to post demos. Richard and others sucked me into
dialogs, some of which seemed fruitful. 

I'm not leaving CLC. Deal with it.
0
6/21/2004 2:33:37 AM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d6443a.5235729@news.optonline.net...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote:
<snip>
>
> I'm not leaving CLC. Deal with it.

I do deal with it - correcting your misinformation as quickly as I can - unless
someone else gets there first.

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


0
wmklein (2605)
6/21/2004 3:11:45 AM
In article <40d6443a.5235729@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>"William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
>>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>>news:40d23662.118894516@news.optonline.net...
>>> docdwarf@panix.com wrote:
>>>
>><snip>
>>>
>>> My reason for being here is to promote Cobol as a Real Programming Language
>>> rather than the travesty that mainframers have turned it into.
>>
>>It appears (to many readers of CLC) that the *ONLY* purpose that you (Robert
>>Wagner) have in posting to this group is to make (occasionally - but rarely)
>>accurate "universal" statements and then continue threads well past the point
>>that others have shown that your original statements have no "universality" and
>>often little accuracy.
>>
>>When you "came" back after your hiatus from the group, one person posted that
>>they were happy to see you back.  I think that it was (and continues to be) a
>>much more common hope/desire that you will "go away" again (and stay away
>>forever).
>
>Why should I care whether you and others like me .. especially after they've
>been rude to me? When someone shows me courtesy, I reciprocate. When they show
>me disrespect, I respond in like kind. 

As my Sainted Paternal Grandmother - may she sleep with the angels! - 
might have asked, e'er-so-long ago... 'When someone else jumps off the 
Brooklyn Bridge *you* will, too?'

>
>Your message would better be directed to Richard and DocDwarf, who both carry on
>the pointless threads you object to.
>
>Actually, I returned only to post demos. Richard and others sucked me into
>dialogs, some of which seemed fruitful. 

Just a victim of soicumstance, eh... wooWOOWoowoowoowoo!

DD
0
docdwarf (6044)
6/21/2004 9:15:57 AM
In article <cb2ep1$nv2$1@panix5.panix.com>, docdwarf@panix.com wrote:

> In article <joe_zitzelberger-B0D300.10185919062004@corp.supernews.com>,
> Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:
> >In article <217e491a.0406182249.4cd3715d@posting.google.com>,
> > riplin@Azonic.co.nz (Richard) wrote:
> 
> [snip]
> 
> >> There is nothing in 'structured programming' that prohibits the use of
> >> GO TO, though it may restrict the scope of its use.
> >> 
> >> Personally I find that I never need GO TO and have a style in which it
> >> can not be useful.
> >
> >There may not be a prohibition on GO TO in someones specific 
> >implementation of 'Cobol Structured Programming' (that guy that wrote up 
> >the perform/thru/goto/exit comes to mind).  But there are plenty of 
> >prohibitions against it in generic structured programming.  Quite 
> >simply, it makes programs unstructured.
> 
> Quite simply, things might not be as they are described as 'quite simply'.  
> I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
> defined as allowing for a GO TO which directed execution to the top of the
> paragraph which contained the statement, to the -EXIT paragraph THRU which
> the containing paragraph was PERFORMed or to the -ABEND routine of the
> program... those three and no more.
> 
> If these teaching were correct then a method of structuring is defined as 
> allowing for a GO TO and therefore, quite simply, it does *not* make a 
> program unstructured.
> 
> DD

In the sense of Yourdon style structured programming for Cobol, you are 
correct.  (If Yourdan is the one that defined and popularized that 
perform/thru/goto/exit style).

The problem with this style is that it violates the spirit and purpose 
of the "single exit point rule" in a very loud and flagrant manner.  
While it complies with the requirement on a technicality.

Doing a branch to a branch is, effectively a branch to the target of the 
second branch.  The goto/exit effectively reintroduces some of the 
problems the single exit was supposed to solve.

The reason that I mention "generic structured programming" is that all 
of the languages that I've used, studied or maintained have one thing in 
common.  Their commonly accepted convention of "structured programming" 
honors the "single exit point rule".  Only Cobolesse violates it so 
proudly and often.
0
6/21/2004 11:43:35 AM
In article <10d8rli1632hu78@corp.supernews.com>,
 "Rick Smith" <ricksmith@mfi.net> wrote:

> Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote in message
> news:joe_zitzelberger-B0D300.10185919062004@corp.supernews.com...
> > In article <217e491a.0406182249.4cd3715d@posting.google.com>,
> >  riplin@Azonic.co.nz (Richard) wrote:
> [snip]
> > >
> > > There is nothing in 'structured programming' that prohibits the use of
> > > GO TO, though it may restrict the scope of its use.
> > >
> > > Personally I find that I never need GO TO and have a style in which it
> > > can not be useful.
> >
> > There may not be a prohibition on GO TO in someones specific
> > implementation of 'Cobol Structured Programming' (that guy that wrote up
> > the perform/thru/goto/exit comes to mind).  But there are plenty of
> > prohibitions against it in generic structured programming.  Quite
> > simply, it makes programs unstructured.
> 
> I find this rather curious. '[G]eneric structured programming', as
> I understand it, could only refer to flow charts; not to any actual
> programming language. It is in the translation of a flow chart that
> one uses GO TO, where the implementation language does not
> have a means for directly implementing the generic form. How is
> it that the mere translation of one form to another makes the latter
> unstructured when the former is structured?

Generic as in non-Cobol, non-Yourdon, structured programming.  The kind 
where rules of single entry, single exit, scoped data, common code 
reuse, et al, can be applied to any number of languages.

As a matter of reality, few people ever write a flow chart before coding 
a program.  Fewer still update said flow chart as maintenance is 
applied.  The only accurate flow charts of production code I've ever 
seen been auto-generated from the source -- and the results are often 
not as pretty as they would be in the maintenance-free text-book 
sequence of chart/code/compile/execute.

I'm at something of a loss here -- I will have to read up on the 
specifics of Yourdon Cobol.  I learned all of my structured programming 
with Pascal and 6502 assembler.  It was much later that I learned Cobol 
and applied my prior knowledge to what I was reading.  From the look of 
the the perform/thru/goto/exit code I have seen over the last decade, 
this style is failing in several places:

   - The goto-exit is effectively a distinct exit point.  Thus violating 
the single exit point idea.

   - The THRU sequence seems to discourage code reuse in practice.  
Perhaps this is good, because if it did not,

   - the separately targeted paragraph names in a THRU sequence could be 
considered multiple entry points.

Much of this rests on my concept of a paragraph as the unit of structure 
in Cobol, similar to the block/function of C or the 
block/function/procedure of Pascal.  To consider a series of paragraphs, 
a THRU sequence, the unit of structure introduces the multi- entry/exit 
problem and makes reuse tricky.
0
6/21/2004 12:28:16 PM
On Mon, 21 Jun 2004 01:13:49 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> enlightened us:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d23662.118894516@news.optonline.net...
>> docdwarf@panix.com wrote:
>>
><snip>
>>
>> My reason for being here is to promote Cobol as a Real Programming Language
>> rather than the travesty that mainframers have turned it into.
>
>It appears (to many readers of CLC) that the *ONLY* purpose that you (Robert
>Wagner) have in posting to this group is to make (occasionally - but rarely)
>accurate "universal" statements and then continue threads well past the point
>that others have shown that your original statements have no "universality" and
>often little accuracy.
>
>When you "came" back after your hiatus from the group, one person posted that
>they were happy to see you back.  I think that it was (and continues to be) a
>much more common hope/desire that you will "go away" again (and stay away
>forever).
>
>This will help CLC - and possibly COBOL in a variety of platforms.

When someone says that mainframers have changed Cobol into a travesty,
they have absolutely no credibility (at least with me) and, therefore,
should be ignored and maybe pitied like you would the village idiot.  

Regards,

          ////
         (o o)
-oOO--(_)--OOo-

Old professors never die, 
they just lose their faculties.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve
0
swiegand4720 (202)
6/21/2004 2:52:40 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d488be.271074057@news.optonline.net...

> Perhaps the biggest joke was the tape drives. They were designed with a
> hook-and-eye fastener between the removable tape and the permanent leader.

I've run into a number of machines that had tape drives that worked that
way -- Philco 2000 being one.  Actually I suspect the convention of wrapping
the leader around the takeup reel as part of the mounting process was more
common on IBM systems than elsewhere, and may have been a holdover from the
days before the vacuum column, for which rethreading might have been more
tedious.

The inexpensive tape drives on some Burroughs systems were another example.
They had four drives in a single box occupying floor space about that of an
IBM 2311 disk drive.  The four units shared a common set of electronics and
mechanical drive gear (which meant that only one drive could be in motion at
any given time), and the takeup reel was coaxial with and beneath the feed
reel (*requiring* the use of hook-and-eye leaders).  The tapes were mounted
horizintally on the top of the unit.  Because it occupied about the floor
space of a washing machine (though a bit taller), and sounded rather like
one in operation (because of the single tape motor and all the relays and
clutches to transmit its drive to the four tape drives), it was
affectionately known as the "Maytag" tape drive.   I'd say it occupied the
same spot in the Burroughs product line as the 7330 and the later 2415 did
in the IBM lineup.   The big disadvantage was that if something significant
went wrong with one of the four tapedrives it was usually wrong with all
four.

I've seen them used on everything from a B1710 to a B6700; they were
particularly common on Medium Systems (B2/3/4000).

> It didn't work right, so operators would dismount a tape by cutting it
with a pair
of scissors. The first time I saw that, I couldn't believe my eyes. To mount
a
tape, they'd attach it to the leader with splicing tape.

In Burroughs (and Philco) shops, it worked right if you worked it right.
Operators were expected to turn the little lever that trapped the tape
leader, and unhook the tape from its leader.

Sometimes the loop on the leader would split, or the little D-shaped piece
at the end of the tongue on the tape would rip, and when that happened the
appropriate fix was to replace the leader, the end oif the leader, the
entire tape or the tongue at the end of the tape respectively as deemed
appropriate at the time.  But unless the hook-and-eye parts were no longer
available, I can't imagine a circumstance in which cutting tapes on a
dismount and resplicing them on each mount, in preference to unhooking the
tape from its leader, would have been considered an effective approach to
the process!  That seems to me to speak more to the shop than to the
equipment!

    -Chuck Stevens


0
6/21/2004 3:40:26 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d4d6df.291078207@news.optonline.net...

> The standards committee dropped the ball twice. First they gave us PERFORM
...
> THRU,

.... no later than 1960, from all the evidence at hand.  I think that's quite
a bit before the publication of Dijkstra's seminal work published in 1968,
to say nothing of Yourdon's publications of the 1970's.  I find it difficult
to fault Codasyl's actions before 1960 for failing to foresee Dijkstra's
positions of 1968 and Yourdon's amplification of them in the following years
....

> which was intended for the case where we sometimes perform a and other
> times perform a thru b. It wasn't intended to be an exit mechanism, but it
> quickly devolved into one.

Oh.  Then what was EXIT intended for?   It's clearly documented as being
used with PERFORM, and since EXIT is allowed only as the single statement in
a paragraph, how is one to reach an EXIT statement save through PERFORM ...
THRU when the PERFORM references paragraphs and not sections?

> They could have corrected the abuse by giving us EXIT PARAGRAPH in '85 or
'02.

As others have pointed out, they *did* give us EXIT PARAGRAPH (as well as
EXIT SECTION) in the 2002 standard.  It's not clear to me that this is a
"correction" as distinct from an "additional feature", however, just as it
is not clear to me that PERFORM ... THRU was an abuse when it was
introduced, however it might have been viewed by later generations.  .

Tell me again where the *second* place the standards committee dropped the
ball in this particular area was?

    -Chuck Stevens


0
6/21/2004 4:11:40 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d4e1c2.293865029@news.optonline.net...

> "Meets their needs" is an euphemism for 'they can tolerate its
inadequacies.'

Or maybe "its inadequacies do not impact either the utility of the software
or the company's bottom line sufficiently to warrant changing it."

    -Chuck Stevens


0
6/21/2004 4:18:42 PM
Joe, if I were to hit one of my former bosses with your ideas, often I 
would hear them say, "you think to much." Now, that's not bad in my 
book. However, this is the way it is because of something I tried to
establish recently in a ramble here.

Fact: "We are going to adopt "such and such" a rule."
Fact: The 'we' in the above is not really going to do
anything but claim to be using "such and such". Some
examples will be available because some implementors of
"such and such" are trying to do a better job, and follow
rules.
Fact: Most rules require an enforcement procedure that is
staffed and funded. We hear that a lot at all levels of
society.  Why not Structured Programming?

Fact: The person responsible for seeing to it that rules
are followed for many reasons is NOT even trying to administer
the rule. When attempting to get support, the answer is
we have nothing in our budget, and no staff we can spare for
that. Period.

Fact: Your concerns are valid "in a perfect world". Sometimes
we find one, but is it worth going to Mars via the Moon?

Fact: People who try to do the job they are given often are
ignored, or relieved, or leave.

Now, I have to say, those are MY FACTS. They are not
universal, and I'm only stating them to try to shed some
light on the way things go in all organizations. IMHO.

Warren Simmons



Joe Zitzelberger wrote:
> In article <10d8rli1632hu78@corp.supernews.com>,
>  "Rick Smith" <ricksmith@mfi.net> wrote:
> 
> 
>>Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote in message
>>news:joe_zitzelberger-B0D300.10185919062004@corp.supernews.com...
>>
>>>In article <217e491a.0406182249.4cd3715d@posting.google.com>,
>>> riplin@Azonic.co.nz (Richard) wrote:
>>
>>[snip]
>>
>>>>There is nothing in 'structured programming' that prohibits the use of
>>>>GO TO, though it may restrict the scope of its use.
>>>>
>>>>Personally I find that I never need GO TO and have a style in which it
>>>>can not be useful.
>>>
>>>There may not be a prohibition on GO TO in someones specific
>>>implementation of 'Cobol Structured Programming' (that guy that wrote up
>>>the perform/thru/goto/exit comes to mind).  But there are plenty of
>>>prohibitions against it in generic structured programming.  Quite
>>>simply, it makes programs unstructured.
>>
>>I find this rather curious. '[G]eneric structured programming', as
>>I understand it, could only refer to flow charts; not to any actual
>>programming language. It is in the translation of a flow chart that
>>one uses GO TO, where the implementation language does not
>>have a means for directly implementing the generic form. How is
>>it that the mere translation of one form to another makes the latter
>>unstructured when the former is structured?
> 
> 
> Generic as in non-Cobol, non-Yourdon, structured programming.  The kind 
> where rules of single entry, single exit, scoped data, common code 
> reuse, et al, can be applied to any number of languages.
> 
> As a matter of reality, few people ever write a flow chart before coding 
> a program.  Fewer still update said flow chart as maintenance is 
> applied.  The only accurate flow charts of production code I've ever 
> seen been auto-generated from the source -- and the results are often 
> not as pretty as they would be in the maintenance-free text-book 
> sequence of chart/code/compile/execute.
> 
> I'm at something of a loss here -- I will have to read up on the 
> specifics of Yourdon Cobol.  I learned all of my structured programming 
> with Pascal and 6502 assembler.  It was much later that I learned Cobol 
> and applied my prior knowledge to what I was reading.  From the look of 
> the the perform/thru/goto/exit code I have seen over the last decade, 
> this style is failing in several places:
> 
>    - The goto-exit is effectively a distinct exit point.  Thus violating 
> the single exit point idea.
> 
>    - The THRU sequence seems to discourage code reuse in practice.  
> Perhaps this is good, because if it did not,
> 
>    - the separately targeted paragraph names in a THRU sequence could be 
> considered multiple entry points.
> 
> Much of this rests on my concept of a paragraph as the unit of structure 
> in Cobol, similar to the block/function of C or the 
> block/function/procedure of Pascal.  To consider a series of paragraphs, 
> a THRU sequence, the unit of structure introduces the multi- entry/exit 
> problem and makes reuse tricky.
0
wsimmons5 (172)
6/21/2004 4:20:04 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d4d2e5.290059559@news.optonline.net...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> Algol has pointers. Why are they a security risk in the hands of Cobol
> programmers but not Algol programmers?

Partly because ALGOL pointers are not the same thing as pointers as
described in ISO/IEC 1989:2002 for COBOL.

    -Chuck Stevens


0
6/21/2004 4:33:59 PM
Bill,

I read this thread with some sadness.

I don't intend to take sides here but I have some observations I'll
certainly share with the group:

1. This is an open unmoderated forum. EVERYONE has a right to post
here. That includes Robert.

Similarly, EVERYONE has a right to respond or not. It is a choice.

My feeling is that if a given individual's posts upset you, ignore
them. There is no COMPULSION (other than the innate pyschological one)
that says you MUST respond to someone's post. History has shown that
if a given individual's posts are consistently ignored, that
individual will usually recognise that it is pointless to post, and
depart.

I would see this kind of treatment being reserved for people who
flame, "haunt", and/or generally seek to destroy the group. I don't
think Robert comes in that category at the moment, even though he is
on record (a long time ago) as saying that that was his aim... I'd
like to believe he has "grown" since that time.
(Maybe Robert might care to comment as to whether that is still his
stated aim?)

Different people will deal with what happens here in different ways.

Some people will depart in a sulk or huff (not naming any names, but
I'm sure you've seen a recent example of this... :-). Now, you could
argue that it is entirely my fault that person departed. My response
would be: "I take responsibility for my own actions, not those of
others.").

Others will just decide not to correspond with the "troublemakers". 

Some will continue posting, showing the errors in the post they object
to and arguing mercilessly. Debate is no bad thing.

Each of us will respond (or not) in whatever way we feel comfortable.
There is no requirement for posts to be "acceptable". (But, it is nice
if they are...).

In my own case, I have been a regular contributor here over many
years. I've made friends and enemies (in saying that, I can honestly
say I bear no malice to anyone here, present or departed, except Tony
Dilworth who is the lowest kind of pond scum and ....Oops! sorry...),
I've lost my rag on occasion, I've tried to calm things down on other
occasions, but it has always been "interesting". Now I find that there
are pressures on my time outside of COBOL, and also I believe that a
lot of the debate here really is pointless (that doesn't make me
advocate that we shouldn't have it; it just makes me re-evaluate
priorities on my time). It was Robert (ironically enough) who pointed
out in a response to recent mail of mine, that all of us have the same
time, 24 hours each day, it is just a question of priorities. I agree
100%.

But I would hate to see this group close or go off the air.

The point is that what we have here is a valuable avenue of free
speech about things COBOL. (And all the other OT stuff that this group
has always generated... :-))

2. There will always be people and posts here that irritate or annoy
others.

Escalating the conflict is unlikely to make it go away. Renaming a
thread with the name of an individual is not a reasonable way to
object, in my opinion. As soon as people are named, it becomes
personal. It is unfair and unworthy for the group to attack a given
individual (although a series of individual attacks are probably
fair...) Everyone should have the same right to a hearing.

"I may not agree with what you say, but I shall defend to the death,
your right to say it."

3. I remember a certain person, a few years back, (not too far away
from this thread) who was "attacked" by a gang of people because he
held and expressed an unpopular viewpoint. I seem to recall writing an
article in defence of him... It would be a pity if the same gentleman
was not prepared to tolerate (or even ignore) the unpopular viewpoints
 (or specious arguments) of others...

Finally, no matter how passionate any of us feel about CLC, no matter
how much we would like it to conform to certain guidelines or rules
(even common courtesy and decency), we cannot MAKE it so...

If you want a moderated forum, start one.(I'll happily volunteer to be
on the moderator rota...)

CLC is not such a forum and I really hope it never will be.

(continues below...)

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:<hDqBc.8580$w07.2455@newsread2.news.pas.earthlink.net>...
> "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> news:40d23662.118894516@news.optonline.net...
> > docdwarf@panix.com wrote:
> >
>  <snip>
> >
> > My reason for being here is to promote Cobol as a Real Programming Language
> > rather than the travesty that mainframers have turned it into.
> 
I'm surprised you would rise to this obvious bait, Bill...

> It appears (to many readers of CLC)[er...isn't quoting made-up statistics one of the things we are tryng to avoid? How many is "many"?...]

 that the *ONLY* purpose that you (Robert
> Wagner) have in posting to this group is to make (occasionally - but rarely)
> accurate "universal" statements and then continue threads well past the point
> that others have shown that your original statements have no "universality" and
> often little accuracy.

I hate cliches, but isn't there one about a certain Latin American
dance that requires more than one person in order to dance it? <G> The
secret in corresponding with Robert is knowing when to stop...<G>

> 
> When you "came" back after your hiatus from the group, one person posted that
> they were happy to see you back.  I think that it was (and continues to be) a
> much more common hope/desire that you will "go away" again (and stay away
> forever).
>
Hardly the milk of Human kindness is it Bill? <G>

 
> This will help CLC - and possibly COBOL in a variety of platforms.

So Robert Wagner is now elevated to the role of being important to
COBOL across platforms?!

That would be enough to make anyone reach for "Teach Yourself Java"...
maybe Robert has done some good after all :-)

OK, this has been fun and it has been real, but it hasn't been real
fun...<G>

I'm sure this post will have no effect whatsoever on what happens in
CLC but then, I'd be sorry if it did... The best I can hope for is
that there will be some consideration on't.

Pete.
0
dashwood1 (2140)
6/21/2004 4:54:27 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d5afcb.346617830@news.optonline.net...

> Great! It's not in my draft version. Must have been a late addition.

Good grief!  What draft version of the 2002 standard are you looking
at?!?!?!

Format 6 EXIT (which includes EXIT PARAGRAPH and EXIT SECTION) was already
in Committee Draft 1.1 dated July 1997, the earliest one I have available in
my personal archives.  I have also verified that it is in *each* of the nine
subsequent committee drafts (CD 1.2 through CD 1.10), *and* the two Draft
International Standards (2/8/2002 and 3/15/2002), *and* and the Final Draft
International Standard of  5/7/2002 in my files.

Maybe it'd be a good idea for you to fork out the $18 for a downloadable
copy of the *real*standard so you can figure out what's actually in it
before making false claims about what it doesn't include?

    -Chuck Stevens


0
6/21/2004 4:58:53 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d3ec60.231037676@news.optonline.net...

> In the end, the only real protection is that provided by hardware.
Descriptors
> can be forged -- copied from a parent program's stack.

How exactly would you go about doing that, since a *program* doesn't have
access to it's caller's *stack* (or, for that matter, its own) addressed as
a data structure?

> Third-party software might be superior. IBM mainframes have a long history
of
> third-party abend analyzers that work better than IBM's.

Goody for them!  What deficiencies have you found in Unisys's programdump
mechanisms?   Certainly our users haven't found it so tedious as to
stimulate developers to write a better one!

> In my limited
> experience with Burroughs medium systems (B3500/4700), I found it
necessary to
> improve the MCP's communication module to make the first Telechek system
work,
> and to rewrite the print spooler from scratch to improve its
functionality.

And the Medium System was a quite different machine from the Large System,
then and now.

There are areas in which such user extensions are practical and useful, and
there are areas in which they are not.

> Many
> shops switched to my print spooler.  A cursory Web search shows
third-party
> performance monitors and memory optimizers for the current Unisys MCP.

I know about some performance monitors, but I don't see memory optimizers
for the *Unisys MCP* environment.

The MCP does provide some "hooks" that allow some features of this sort; the
fact that the hooks exist in this area and that third-party developers have
made use of them does not necessarily mean that developers have done so, or
will do so, in other areas.

> BMC, the first billion dollar software company, was founded in the late
'60s to
> provide services MUCH better than IBM's offerings. I recall meeting with
them
> and being blown away by their technical skill.

..... And .... ?

> Third-party software must sometimes resort to 'hacking' because the
hardware
> manufacturer arrogantly assumes its way is the only way.

.... presuming the software has a way to get into the system other than with
the MCP's permission in the first place!

    -Chuck Stevens


0
6/21/2004 5:16:24 PM
I wrote:

> >For a program that's nested, the sequence numbers identify the location
of
> >the failure, the call history within the compilation unit, the object
code
> >file name of the compilation unit, and the actual object code instruction
> >address for of the failure for each level in the PERFORM and CALL stack
> >history.
> >
> >The sequence number history of any failure is also by default provided in
> >the abnormal-termination message, though you may actually have to glance
at
> >the program dump to find out which sequence number goes with which
program.
> >
> >Have you *demonstrated* that you need more information than the MCP has
> >already provided *you*?   Or is it just "I want to do it *my* way, not
the
> >way the system allows me to do it!"?

Robert Wagner responded:

> Policy determines the fate of systems and institutions. Politics
determines the
> fate of individuals. Although both are based on the same Greek root word
"pol",
> meaning people, they refer to different mental processes. Policy is
rational
> whereas politics is emotional.

I fail to see the relevance of this paragraph.

> By emphasizing "you", you're trying to redirect the discussion into a
political
> vein.

No, I am trying to ascertain whether your practical experience on current or
recent Unisys MCP-based systems (that is to say, ex-Burroughs Large Systems)
has brought to light specific deficiencies in the application program
debugging tools provided by Unisys.  The reason I raise that question is
that I suspect you haven't actually tried to debug a program fault using the
available tools and are claiming their inadequacy without having seen what
they actually do.

> I claim no special credentials nor authority on Cobol. I'm just a code
> cranker.

Yet you claim enough credentials to criticize the debugging tools of Unisys
MCP-based systems without (so far as I can tell) having any practical
experience with them!

    -Chuck Stevens


0
6/21/2004 5:27:03 PM
Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-9A1F56.08281621062004@corp.supernews.com...
> In article <10d8rli1632hu78@corp.supernews.com>,
>  "Rick Smith" <ricksmith@mfi.net> wrote:
>
> > Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote in message
> > news:joe_zitzelberger-B0D300.10185919062004@corp.supernews.com...
> > > In article <217e491a.0406182249.4cd3715d@posting.google.com>,
> > >  riplin@Azonic.co.nz (Richard) wrote:
> > [snip]
> > > >
> > > > There is nothing in 'structured programming' that prohibits the use
of
> > > > GO TO, though it may restrict the scope of its use.
> > > >
> > > > Personally I find that I never need GO TO and have a style in which
it
> > > > can not be useful.
> > >
> > > There may not be a prohibition on GO TO in someones specific
> > > implementation of 'Cobol Structured Programming' (that guy that wrote
up
> > > the perform/thru/goto/exit comes to mind).  But there are plenty of
> > > prohibitions against it in generic structured programming.  Quite
> > > simply, it makes programs unstructured.
> >
> > I find this rather curious. '[G]eneric structured programming', as
> > I understand it, could only refer to flow charts; not to any actual
> > programming language. It is in the translation of a flow chart that
> > one uses GO TO, where the implementation language does not
> > have a means for directly implementing the generic form. How is
> > it that the mere translation of one form to another makes the latter
> > unstructured when the former is structured?
>
> Generic as in non-Cobol, non-Yourdon, structured programming.  The kind
> where rules of single entry, single exit, scoped data, common code
> reuse, et al, can be applied to any number of languages.
>
> As a matter of reality, few people ever write a flow chart before coding
> a program.  Fewer still update said flow chart as maintenance is
> applied.  The only accurate flow charts of production code I've ever
> seen been auto-generated from the source -- and the results are often
> not as pretty as they would be in the maintenance-free text-book
> sequence of chart/code/compile/execute.
>
> I'm at something of a loss here -- I will have to read up on the
> specifics of Yourdon Cobol.  I learned all of my structured programming
> with Pascal and 6502 assembler.  It was much later that I learned Cobol
> and applied my prior knowledge to what I was reading.  From the look of
> the the perform/thru/goto/exit code I have seen over the last decade,
> this style is failing in several places:
>
>    - The goto-exit is effectively a distinct exit point.  Thus violating
> the single exit point idea.
>
>    - The THRU sequence seems to discourage code reuse in practice.
> Perhaps this is good, because if it did not,
>
>    - the separately targeted paragraph names in a THRU sequence could be
> considered multiple entry points.
>
> Much of this rests on my concept of a paragraph as the unit of structure
> in Cobol, similar to the block/function of C or the
> block/function/procedure of Pascal.  To consider a series of paragraphs,
> a THRU sequence, the unit of structure introduces the multi- entry/exit
> problem and makes reuse tricky.

I also decided to review Yourdon's work, at least the books I have
with Yourdon's name as an author. I am not not certain that 'modified
Yourdon structuring' is other than 'John Doe structuring'; that is,
some unidentified person took what Yourdon wrote and modified
it to allow GO TO under additional cicumstances.

In a response to Mr Wagner, in another part of this thead, I quoted
a portion of the COBOL standard that defines 'procedure' as
being "composed of a paragraph, or a group of successive
paragraphs, or a section, or a group of successive sections within
the procedure division." It occurs to me that this definition suggests
that each procedure has a single-entry and single-exit. It follows that
if a procedure is 'composed of a group of successive paragraphs
(or sections)' then the additional procedure names are not additional
entry points, but rather labels internal to the procedure.

[The standard does not state that procedures shall not overlap; but,
I believe, the behavior with two active performs using the same
ending procedure-name is undefined.]

AIUI, the relationship between what became structured programming
and flow charts was established by Bohm and Jacopini when they
reduced all programming to process block and decision; that is,
two easily recognized flow chart symbols, rectangle and diamond.
Dijkstra and others expanded the concept and provided names
for the additional structures. Each was shown in flow chart symbols.

When I learned structured programming, scoped-data and code
resuse were not discussed (these were relegated to modular
programming); however, reading from top to bottom was.

The point of my prior response may be seen with an example
of the structure REPEAT UNTIL. It being difficult to show the
flow chart symbols, I will use words.

Given:

REPEAT
    statement
UNTIL (condition)

In COBOL 68 and 74, one may write:

    PERFORM statement
    PERFORM statement UNTIL (condition)

statement.
    <code>

[Note that the code associated with 'statement' has been separated
from the representation of the structure.]

In COBOL 85 and 02, one may write:

    PERFORM WITH TEST AFTER UNTIL (condition)
        statement
    END-PERFORM

[Note that the 'condition' has been moved to the beginning of the
structure.]

In any COBOL, one could write:

LOOP-START.
    statement
    IF NOT (condition) GO TO LOOP-START.

[Note that regardless of the complexity of 'statement' the code
used is faithful to the REPEAT UNTIL structure because it
keeps both 'statement' and 'condition' in the same relative
positions as the design.]

The first two examples are in the spirit of structured programming
but only the last, the one with GO TO, is faithful to it and may be
read from top to bottom.

My point is that a translation of a structure that uses GO TO
does not automatically make the resulting program unstructured.
It is not my point that one should actually use GO TO in these
circumstances. (Though I did so when using 6800 assembler.)



0
ricksmith (875)
6/21/2004 8:43:06 PM
Peter E. C. Dashwood wrote:
>
> My feeling is that if a given individual's posts upset you, ignore
> them. There is no COMPULSION (other than the innate pyschological one)
> that says you MUST respond to someone's post.

"All that is required for evil to triumph is for good men to busy themselves
trying to shave cats."

> History has shown that
> if a given individual's posts are consistently ignored, that
> individual will usually recognise that it is pointless to post, and
> depart.

True for many. Some just like to generate adrenaline.



0
nospam312 (645)
6/21/2004 10:55:22 PM
"JerryMouse" <nospam@bisusa.com> wrote:

>Robert Wagner wrote:
>>
>> Stroustrup wants to create two classes of programmers: a lower class
>> that does boring, repetitive work using unsophisticated tools, and an
>> upper class that handles complex problems through the use of
>> intelligence and education. This elitist attitude is common in
>> academia, where Dr. Stroustrup has spent his entire life.
>
>I wouldn't say the technique is limited to academia. It exists at McDonalds
>and at Exxon, at hospitals and auto repair shops. It exists in government.
>It existed when the pyramids were built and I hope it still exists when we
>colonize Mars.
>
>While "elitism" is a belief that certain groups should get benefits because
>of intellect or wealth, I suggest elitism is a belief based on fact.
>Moreover, people with a greater intellect or wealth should get favored
>treatement.

Evidence to the contrary: George W. Bush, whose stupidity in permitting neocons
to override the military has damaged foreign policy.

0
6/22/2004 12:54:57 AM
"JerryMouse" <nospam@bisusa.com> wrote:

>Robert Wagner wrote:
>>>
>>> You may not notice that this conflicts with you claims that there are
>>> 'gigabytes of memory' and a virtual memory, but I do.
>>
>> Even with "lots of memory", multi-dimensional arrays can grow to
>> multi-gigabytes. For instance, I wrote a 'program' (a series of
>> modular programs) that parses freeform text documents, a very common
>> data warehousing problem. Suppose I had allocated 30 bytes per word
>> (not enough, as Cobol has shown), 20 words per line, 10,000 lines per
>> document and a maximum of 3,000 documents (way too small). My array
>> would have taken 18GB. If I'd carelessly used INITIALIZE, every one
>> of those bytes would have been touched.
>>
>> Because I used lists, it ran in 500MB.
>
>And used hundreds of statements instead of one?

Constructing a list entry took, at most, four statements.

>> Take the case of sorting an array. You _could_ insert the rows into
>> an indexed file and read them back in sequence. I've seen programs do
>> that. It's the mark of an amateur programmer.
>
>No, it's the mark of an efficient programmer. The ISAM I-O routines are far
>more efficient than any code to insert a row in a table. For
>reasonable-sized tables, there's not even any disk activity.

I could easily add that to the sort demo. If I did and it ran 'efficiently', I
would admit to being wrong. If it ran significantly slower, would you admit to
being wrong?
0
6/22/2004 12:54:58 AM
"Rick Smith" <ricksmith@mfi.net> wrote:

>
>Robert Wagner <robert.deletethis@wagner.net> wrote in message
>news:40d5afd3.346626239@news.optonline.net...
>> "Rick Smith" <ricksmith@mfi.net> wrote:

>> Stroustrup wants to create two classes of programmers: a lower class that
>does
>> boring, repetitive work using unsophisticated tools, and an upper class
>that
>> handles complex problems through the use of intelligence and education.
>This
>> elitist attitude is common in academia, where Dr. Stroustrup has spent his
>> entire life.
>
>You are confused. Dr Stroustrup is a long-time employee of AT&T.

He is head of the Computer Science department at Texas A&M. Before moving there
he worked at Bell Labs in Murray Hill and later at AT&T Labs in Florham Park. I
live near both, in Morris County NJ, and know people who now or previously
worked a both. The people are academecians and the tone of the Labs is like a
university, not a business.

>
>> >"However, suppose the application differs sufficiently from traditional
>> >sequential processing of records (or characters) or the complexity
>> >involved is higher -- say, in an interactive CASE system. The lack of
>> >language support for data abstraction implied by the decision to
>> >ignore classes will hurt. The inherent complexity will show up in the
>> >application somewhere, and if the system is implemented in an
>> >impoverished language, the code will not reflect the design directly.
>> >The program will have too many lines of source code, lack type
>> >checking and will in general not be amenable to tools. This is a
>> >prescription for a maintenance nightmare."
>>
>> That's a pretty accurate description of a typical Cobol shop, showing it
>too
>> would benefit from OO.
>
>Please, Mr Wagner, is it typical to use COBOL for interactive
>CASE?

It is typical for Cobol shops to be a maintenance nightmare because they have
too many lines of source code, are not amenable to tools, and code does not
reflect the design directly. 

>> Stroustrup did not show how it follows that OO functionality does not
>apply to
>> batch processing. His assertion is not suppored by argumentation.
>
>Mr Wagner, the support was in the first, quoted paragraph.
>"For example, the strict separation of data and code that results
>makes it easy to use traditional databases that are designed for
>such programs." Traditional databases do not hold objects.

Yes they do. Of the traditional RDBMSs, Informix was first with its bladelets.
Oracle, IBM and Sybase responded by adding their own versions of object support.

0
6/22/2004 12:55:01 AM
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

>What version of the draft are you looking at?  As the person who wrote the
>original proposal adding them, they were in by a VERY early version of the
>DRAFT Standard. 

Committee Draft 1.8, Issued February 23, 2000.

I looked in the Index, where EXIT PARAGRAPH is missing, and assumed it was
missing from the body. Navigation is difficult in a document lacking hot links. 

Looking at the body (by adding 18 to the page number), I now see it is there.


0
6/22/2004 12:55:03 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>The inexpensive tape drives on some Burroughs systems were another example.
>They had four drives in a single box occupying floor space about that of an
>IBM 2311 disk drive. ....
>I've seen them used on everything from a B1710 to a B6700; they were
>particularly common on Medium Systems (B2/3/4000).

I saw them in other shops, where they were auxiliary to the 'real' tape drives.
The two Burroughs shops where I worked didn't use them. 

>> It didn't work right, so operators would dismount a tape by cutting it
>with a pair
>of scissors. The first time I saw that, I couldn't believe my eyes. To mount
>a
>tape, they'd attach it to the leader with splicing tape.
>
>In Burroughs (and Philco) shops, it worked right if you worked it right.
>Operators were expected to turn the little lever that trapped the tape
>leader, and unhook the tape from its leader.

Yes, it did work right on Burroughs drives.

>Sometimes the loop on the leader would split, or the little D-shaped piece
>at the end of the tongue on the tape would rip, and when that happened the
>appropriate fix was to replace the leader, the end of the leader, the
>entire tape or the tongue at the end of the tape respectively as deemed
>appropriate at the time.  

When the "D" broke, one used a handheld cutter that looked like a hole punch to
make another "D" further down the leader.

>But unless the hook-and-eye parts were no longer
>available, I can't imagine a circumstance in which cutting tapes on a
>dismount and resplicing them on each mount, in preference to unhooking the
>tape from its leader, would have been considered an effective approach to
>the process!  That seems to me to speak more to the shop than to the
>equipment!

There was nothing substandard about the shop. Operators said they had tried
other approaches and found cutting the most practical solution. They could mount
a tape pretty quickly, and dismounting was _really_ fast. :)
0
6/22/2004 12:55:04 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d5afcb.346617830@news.optonline.net...
>
>> Great! It's not in my draft version. Must have been a late addition.
>
>Good grief!  What draft version of the 2002 standard are you looking
>at?!?!?!

See my response to Bill Klein. It wasn't in the index.

>Maybe it'd be a good idea for you to fork out the $18 for a downloadable
>copy of the *real*standard so you can figure out what's actually in it
>before making false claims about what it doesn't include?

I thought the draft was close enough for gubbermint work.

0
6/22/2004 12:55:05 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d4d6df.291078207@news.optonline.net...
>
>> The standards committee dropped the ball twice. First they gave us PERFORM
>..
>> THRU,
>
>... no later than 1960, from all the evidence at hand.  I think that's quite
>a bit before the publication of Dijkstra's seminal work published in 1968,
>to say nothing of Yourdon's publications of the 1970's.  I find it difficult
>to fault Codasyl's actions before 1960 for failing to foresee Dijkstra's
>positions of 1968 and Yourdon's amplification of them in the following years
>...

I don't heavily fault Codasyl. We were all innocent and inexperienced in those
days.

>> which was intended for the case where we sometimes perform a and other
>> times perform a thru b. It wasn't intended to be an exit mechanism, but it
>> quickly devolved into one.
>
>Oh.  Then what was EXIT intended for?   It's clearly documented as being
>used with PERFORM, and since EXIT is allowed only as the single statement in
>a paragraph, how is one to reach an EXIT statement save through PERFORM ...
>THRU when the PERFORM references paragraphs and not sections?

I always thought of EXIT as a 'filler' word, like CONTINUE, to be used where you
had nothing to say. It did not necessarily exit. It only exited if it was at the
end of a PERFORM THRU. When a paragraph of straight line code was commented out,
the maintainer would sometimes replace the body with EXIT, meaning fall thru to
the next paragraph.

>> They could have corrected the abuse by giving us EXIT PARAGRAPH in '85 or
>'02.
>
>As others have pointed out, they *did* give us EXIT PARAGRAPH (as well as
>EXIT SECTION) in the 2002 standard.  It's not clear to me that this is a
>"correction" as distinct from an "additional feature", however, just as it
>is not clear to me that PERFORM ... THRU was an abuse when it was
>introduced, however it might have been viewed by later generations.  

I believe PERFORM 1234-some-paragraph THRU 1234-EXIT _is_ abusive, and I'm first
generation. Setting aside the issue of numbered paragraphs, what's wrong with
PERFORM some-paragraph? They think they _might_ want to exit prematurely, so
they make it a Standard that _every_ paragraph have an exit paragraph. Well,
EXIT PARAGRAPH takes the wind out of those sails. 

>Tell me again where the *second* place the standards committee dropped the
>ball in this particular area was?

It didn't, thanks to 'enlightened' members such as you and Bill Klein.

Documentation people dropped the ball by failing to list EXIT PARAGRAPH in the
index. 
0
6/22/2004 12:55:06 AM
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40d3ec60.231037676@news.optonline.net...
>
>> In the end, the only real protection is that provided by hardware.
>Descriptors
>> can be forged -- copied from a parent program's stack.
>
>How exactly would you go about doing that, since a *program* doesn't have
>access to it's caller's *stack* (or, for that matter, its own) addressed as
>a data structure?

Not being an MCP programmer, I don't know. But as they say in the movies, 'give
me an hour with it and I'll make it spill its guts.'

>>  A cursory Web search shows third-party
>> performance monitors and memory optimizers for the current Unisys MCP.
>
>I know about some performance monitors, but I don't see memory optimizers
>for the *Unisys MCP* environment.

Look here:
http://www.metalogic.eu.com/Main/about/about.htm

>The MCP does provide some "hooks" that allow some features of this sort; the
>fact that the hooks exist in this area and that third-party developers have
>made use of them does not necessarily mean that developers have done so, or
>will do so, in other areas.

Lacking an audit trail, you don't know whether developers are exploiting holes
in your system. Reliance on 'user ignorance' is really bad security.

>> BMC, the first billion dollar software company, was founded in the late
>'60s to
>> provide services MUCH better than IBM's offerings. I recall meeting with
>them
>> and being blown away by their technical skill.
>
>.... And .... ?

And third parties' knowledge of your system might be superior to yours.


0
6/22/2004 12:55:07 AM
dashwood@enternet.co.nz (Peter E. C. Dashwood) wrote:


>I would see this kind of treatment being reserved for people who
>flame, "haunt", and/or generally seek to destroy the group. I don't
>think Robert comes in that category at the moment, even though he is
>on record (a long time ago) as saying that that was his aim... I'd
>like to believe he has "grown" since that time.
>(Maybe Robert might care to comment as to whether that is still his
>stated aim?)

My intent was never to destroy CLC. If I said so a long time ago, my remarks
were probably taken out of context and distorted. I don't recall ever saying
that. 

As to baiting mainframers, I plead guilty. They take the bait so gullibly.

I applaud your defense of Free Speech in this posting. Thank you and keep it up.

>> This will help CLC - and possibly COBOL in a variety of platforms.
>
>So Robert Wagner is now elevated to the role of being important to
>COBOL across platforms?!

An amateurish attempt to appeal to my eleemosynisity, easily ignored.

0
6/22/2004 12:55:08 AM
I suspect that you guys are all barking up the wrong tree about Robert
Wagner.  Check out the French mathematician named Nicholas Bourbaki.   
Same situation?

PL
0
lacey (134)
6/22/2004 1:18:15 AM
Peter - stop being sensible. It is not any fun at all to argue with you when I have to
agree with you.

And Bill- you know quite well that 90% of the people that read this forum consider
you both an expert on everything Cobol, and darn near a Saint in how far you will
go to help someone you don't even know. *Anyone* - even dumb questions from
me. <grin>

So relax and don't worry about it. This group has developed some kind of synergy; behavior
problems are mostly self correcting.

-Paul

"Peter E. C. Dashwood" <dashwood@enternet.co.nz> wrote in message news:b3638c46.0406210854.29e8bb35@posting.google.com...
> Bill,
>
> I read this thread with some sadness.
>
> I don't intend to take sides here but I have some observations I'll
> certainly share with the group:
>
> 1. This is an open unmoderated forum. EVERYONE has a right to post
> here. That includes Robert.
>
> Similarly, EVERYONE has a right to respond or not. It is a choice.
>
> My feeling is that if a given individual's posts upset you, ignore
> them. There is no COMPULSION (other than the innate pyschological one)
> that says you MUST respond to someone's post. History has shown that
> if a given individual's posts are consistently ignored, that
> individual will usually recognise that it is pointless to post, and
> depart.
>
> I would see this kind of treatment being reserved for people who
> flame, "haunt", and/or generally seek to destroy the group. I don't
> think Robert comes in that category at the moment, even though he is
> on record (a long time ago) as saying that that was his aim... I'd
> like to believe he has "grown" since that time.
> (Maybe Robert might care to comment as to whether that is still his
> stated aim?)
>
> Different people will deal with what happens here in different ways.
>
> Some people will depart in a sulk or huff (not naming any names, but
> I'm sure you've seen a recent example of this... :-). Now, you could
> argue that it is entirely my fault that person departed. My response
> would be: "I take responsibility for my own actions, not those of
> others.").
>
> Others will just decide not to correspond with the "troublemakers".
>
> Some will continue posting, showing the errors in the post they object
> to and arguing mercilessly. Debate is no bad thing.
>
> Each of us will respond (or not) in whatever way we feel comfortable.
> There is no requirement for posts to be "acceptable". (But, it is nice
> if they are...).
>
> In my own case, I have been a regular contributor here over many
> years. I've made friends and enemies (in saying that, I can honestly
> say I bear no malice to anyone here, present or departed, except Tony
> Dilworth who is the lowest kind of pond scum and ....Oops! sorry...),
> I've lost my rag on occasion, I've tried to calm things down on other
> occasions, but it has always been "interesting". Now I find that there
> are pressures on my time outside of COBOL, and also I believe that a
> lot of the debate here really is pointless (that doesn't make me
> advocate that we shouldn't have it; it just makes me re-evaluate
> priorities on my time). It was Robert (ironically enough) who pointed
> out in a response to recent mail of mine, that all of us have the same
> time, 24 hours each day, it is just a question of priorities. I agree
> 100%.
>
> But I would hate to see this group close or go off the air.
>
> The point is that what we have here is a valuable avenue of free
> speech about things COBOL. (And all the other OT stuff that this group
> has always generated... :-))
>
> 2. There will always be people and posts here that irritate or annoy
> others.
>
> Escalating the conflict is unlikely to make it go away. Renaming a
> thread with the name of an individual is not a reasonable way to
> object, in my opinion. As soon as people are named, it becomes
> personal. It is unfair and unworthy for the group to attack a given
> individual (although a series of individual attacks are probably
> fair...) Everyone should have the same right to a hearing.
>
> "I may not agree with what you say, but I shall defend to the death,
> your right to say it."
>
> 3. I remember a certain person, a few years back, (not too far away
> from this thread) who was "attacked" by a gang of people because he
> held and expressed an unpopular viewpoint. I seem to recall writing an
> article in defence of him... It would be a pity if the same gentleman
> was not prepared to tolerate (or even ignore) the unpopular viewpoints
>  (or specious arguments) of others...
>
> Finally, no matter how passionate any of us feel about CLC, no matter
> how much we would like it to conform to certain guidelines or rules
> (even common courtesy and decency), we cannot MAKE it so...
>
> If you want a moderated forum, start one.(I'll happily volunteer to be
> on the moderator rota...)
>
> CLC is not such a forum and I really hope it never will be.
>
> (continues below...)
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:<hDqBc.8580$w07.2455@newsread2.news.pas.earthlink.net>...
> > "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> > news:40d23662.118894516@news.optonline.net...
> > > docdwarf@panix.com wrote:
> > >
> >  <snip>
> > >
> > > My reason for being here is to promote Cobol as a Real Programming Language
> > > rather than the travesty that mainframers have turned it into.
> >
> I'm surprised you would rise to this obvious bait, Bill...
>
> > It appears (to many readers of CLC)[er...isn't quoting made-up statistics one of the things we are tryng to avoid? How many is
"many"?...]
>
>  that the *ONLY* purpose that you (Robert
> > Wagner) have in posting to this group is to make (occasionally - but rarely)
> > accurate "universal" statements and then continue threads well past the point
> > that others have shown that your original statements have no "universality" and
> > often little accuracy.
>
> I hate cliches, but isn't there one about a certain Latin American
> dance that requires more than one person in order to dance it? <G> The
> secret in corresponding with Robert is knowing when to stop...<G>
>
> >
> > When you "came" back after your hiatus from the group, one person posted that
> > they were happy to see you back.  I think that it was (and continues to be) a
> > much more common hope/desire that you will "go away" again (and stay away
> > forever).
> >
> Hardly the milk of Human kindness is it Bill? <G>
>
>
> > This will help CLC - and possibly COBOL in a variety of platforms.
>
> So Robert Wagner is now elevated to the role of being important to
> COBOL across platforms?!
>
> That would be enough to make anyone reach for "Teach Yourself Java"...
> maybe Robert has done some good after all :-)
>
> OK, this has been fun and it has been real, but it hasn't been real
> fun...<G>
>
> I'm sure this post will have no effect whatsoever on what happens in
> CLC but then, I'd be sorry if it did... The best I can hope for is
> that there will be some consideration on't.
>
> Pete.


0
pkrauleson (30)
6/22/2004 1:30:10 AM
Oh you said that and worse Robert. In fact you descended upon the newsgroup
like a plague of hungry locusts.

On the other hand, you have come up with some interesting ideas, tried to help
other people, and you definitely seem to have grown some manners over the years.

But you *really* need to lay off Bill - the man does more than you, me, and everyone
else around here to promote Cobol, and that is a fact that cannot be argued. He
daily combats idiot journalists, egotistical nutcases, and <brrrr> committees.
Do *you* want to volunteer to deal with <shudder> bureaucrats? I mean without
the use of deadly force?

If you want to pick on mainframers - pick on me. Whatever kind of paycheck you
get is probably created or ordered from a mainframe someone. Piss me off too much
and...

<grin>

-Paul

"Robert Wagner" <robert.deletethis@wagner.net> wrote in message news:40d77f11.34624516@news.optonline.net...
> dashwood@enternet.co.nz (Peter E. C. Dashwood) wrote:
>
>
> >I would see this kind of treatment being reserved for people who
> >flame, "haunt", and/or generally seek to destroy the group. I don't
> >think Robert comes in that category at the moment, even though he is
> >on record (a long time ago) as saying that that was his aim... I'd
> >like to believe he has "grown" since that time.
> >(Maybe Robert might care to comment as to whether that is still his
> >stated aim?)
>
> My intent was never to destroy CLC. If I said so a long time ago, my remarks
> were probably taken out of context and distorted. I don't recall ever saying
> that.
>
> As to baiting mainframers, I plead guilty. They take the bait so gullibly.
>
> I applaud your defense of Free Speech in this posting. Thank you and keep it up.
>
> >> This will help CLC - and possibly COBOL in a variety of platforms.
> >
> >So Robert Wagner is now elevated to the role of being important to
> >COBOL across platforms?!
>
> An amateurish attempt to appeal to my eleemosynisity, easily ignored.
>


0
pkrauleson (30)
6/22/2004 1:36:14 AM
Should the question arise in the future, the index was one of the VERY LAST
things that the committee "worked on" (for - to me - fairly obvious reasons).  I
would NOT rely very heavily on the index of any draft of the 2002 Standard.

In fact, if you down-load the ANSI $18 version of the approved Standard, you
will need to "verify" that the links are fixed in your version. They were "bad"
in the initial purchasable version - but a repaired version is now available
from INCITS.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d767db.28681025@news.optonline.net...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
> >What version of the draft are you looking at?  As the person who wrote the
> >original proposal adding them, they were in by a VERY early version of the
> >DRAFT Standard.
>
> Committee Draft 1.8, Issued February 23, 2000.
>
> I looked in the Index, where EXIT PARAGRAPH is missing, and assumed it was
> missing from the body. Navigation is difficult in a document lacking hot
links.
>
> Looking at the body (by adding 18 to the page number), I now see it is there.
>
>


0
wmklein (2605)
6/22/2004 1:41:31 AM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40d75d4b.25976551@news.optonline.net...
> "Rick Smith" <ricksmith@mfi.net> wrote:
> >
> >Robert Wagner <robert.deletethis@wagner.net> wrote in message
> >news:40d5afd3.346626239@news.optonline.net...
> >> Stroustrup did not show how it follows that OO functionality does not
> >apply to
> >> batch processing. His assertion is not suppored by argumentation.
> >
> >Mr Wagner, the support was in the first, quoted paragraph.
> >"For example, the strict separation of data and code that results
> >makes it easy to use traditional databases that are designed for
> >such programs." Traditional databases do not hold objects.
>
> Yes they do. Of the traditional RDBMSs, Informix was first with its
bladelets.
> Oracle, IBM and Sybase responded by adding their own versions of object
support.

Mr Wagner, I see a difference between 'object support' and the
object itself. That is, 'object support' may have the information
necessary to resconstruct an object, in memory, from data in the
database; but it is not the database that holds the object.



0
ricksmith (875)
6/22/2004 2:04:20 AM
"Paul Raulersonv" <pkrauleson@verizon.net> wrote:

>But you *really* need to lay off Bill - the man does more than you, me, and
everyone
>else around here to promote Cobol, and that is a fact that cannot be argued.

He talks to me with disrespect, I respond in like kind.  One would hope a
committee member would have better political skills.

>If you want to pick on mainframers - pick on me. Whatever kind of paycheck you
>get is probably created or ordered from a mainframe someone. Piss me off too
much
>and...

My payroll is run on PeopleSoft running on a Unix box. You and your mainframe
have been disenfranchised. 

0
6/22/2004 2:46:42 AM
Peter Lacey <lacey@mb.sympatico.ca> wrote:

>I suspect that you guys are all barking up the wrong tree about Robert
>Wagner.  Check out the French mathematician named Nicholas Bourbaki.   
>Same situation?

N. Bourbaki was a mathematical genius I find the word "genius" applied too
liberally. Yes I qualified for "M squared', meaning the upper 2% of the upper 2%
of the general population. But that's a measure of potential. When one reaches
the age of accomplishment, roughly about 30, actual accomplishment replaces
prognostigations. We should be judged on what we did rather than what we
hypothetically might have done. 

0
6/22/2004 2:46:43 AM
Somewhere below some light was seen. Forgive my rambling.
Who knew how to do anything then.
The Univac I had an instruction pair called
R  U. Now called Perform.
The IBM 705 had an instruction pair something
like Store B address and Return. Most of the other
hardware discussed here these days had not yet been
designed, and We Went With What We Had and What We
though Was Good. So help me.

Now, tell me why other aspects of programmer needs ( not
in COBOL today) are not debated and perhaps result in
a draft proposal. It would be the practical thing to
do with all the know how among US. Why use other tools
when they in most cases could be included as another division,
or data structure.

I believe there are  many interfacing devices now used
that could be incorporated into a COBOL Source Program
without the need to Call, etc.

Practice makes perfect.
It was not uncommon before "we" learned better to have a sequence
of paragraphs that included steps useful elsewhere. It might
be true that a dozen or so perform statements contained logic
that jumped around mainly because who knew better, or because
of some limitation, lack of training, or slow programmers.
All of the above no doubt contributed something to that situation.
And once you were used to using such now known as bad practice
you  might fight to keep the "feature" in the language to avoid
a mass rewrite.

Warren Simmons

Robert Wagner wrote:
> "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> 
> 
>>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>>news:40d4d6df.291078207@news.optonline.net...
>>
>>
>>>The standards committee dropped the ball twice. First they gave us PERFORM
>>
>>..
>>
>>>THRU,
>>
>>... no later than 1960, from all the evidence at hand.  I think that's quite
>>a bit before the publication of Dijkstra's seminal work published in 1968,
>>to say nothing of Yourdon's publications of the 1970's.  I find it difficult
>>to fault Codasyl's actions before 1960 for failing to foresee Dijkstra's
>>positions of 1968 and Yourdon's amplification of them in the following years
>>...
> 
> 
> I don't heavily fault Codasyl. We were all innocent and inexperienced in those
> days.
> 
> 
>>>which was intended for the case where we sometimes perform a and other
>>>times perform a thru b. It wasn't intended to be an exit mechanism, but it
>>>quickly devolved into one.
>>
>>Oh.  Then what was EXIT intended for?   It's clearly documented as being
>>used with PERFORM, and since EXIT is allowed only as the single statement in
>>a paragraph, how is one to reach an EXIT statement save through PERFORM ...
>>THRU when the PERFORM references paragraphs and not sections?
> 
> 
> I always thought of EXIT as a 'filler' word, like CONTINUE, to be used where you
> had nothing to say. It did not necessarily exit. It only exited if it was at the
> end of a PERFORM THRU. When a paragraph of straight line code was commented out,
> the maintainer would sometimes replace the body with EXIT, meaning fall thru to
> the next paragraph.
> 
> 
>>>They could have corrected the abuse by giving us EXIT PARAGRAPH in '85 or
>>
>>'02.
>>
>>As others have pointed out, they *did* give us EXIT PARAGRAPH (as well as
>>EXIT SECTION) in the 2002 standard.  It's not clear to me that this is a
>>"correction" as distinct from an "additional feature", however, just as it
>>is not clear to me that PERFORM ... THRU was an abuse when it was
>>introduced, however it might have been viewed by later generations.  
> 
> 
> I believe PERFORM 1234-some-paragraph THRU 1234-EXIT _is_ abusive, and I'm first
> generation. Setting aside the issue of numbered paragraphs, what's wrong with
> PERFORM some-paragraph? They think they _might_ want to exit prematurely, so
> they make it a Standard that _every_ paragraph have an exit paragraph. Well,
> EXIT PARAGRAPH takes the wind out of those sails. 
> 
> 
>>Tell me again where the *second* place the standards committee dropped the
>>ball in this particular area was?
> 
> 
> It didn't, thanks to 'enlightened' members such as you and Bill Klein.
> 
> Documentation people dropped the ball by failing to list EXIT PARAGRAPH in the
> index. 
0
wsimmons5 (172)
6/22/2004 2:55:09 AM
In article <40d799de.41486419@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>"Paul Raulersonv" <pkrauleson@verizon.net> wrote:
>
>>But you *really* need to lay off Bill - the man does more than you, me, and everyone
>>else around here to promote Cobol, and that is a fact that cannot be argued.
>
>He talks to me with disrespect, I respond in like kind.

He jumps off the Brooklyn Bridge, *you* will, too?

>One would hope a
>committee member would have better political skills.

Perhaps as much as one would hope a mature adult would have a better basis 
for behavior than the Brooklyn Bridge defense.

DD
0
docdwarf (6044)
6/22/2004 9:14:52 AM
In article <10dei1ic805ka30@corp.supernews.com>,
 "Rick Smith" <ricksmith@mfi.net> wrote:
> I also decided to review Yourdon's work, at least the books I have
> with Yourdon's name as an author. I am not not certain that 'modified
> Yourdon structuring' is other than 'John Doe structuring'; that is,
> some unidentified person took what Yourdon wrote and modified
> it to allow GO TO under additional cicumstances.

I suspect you are correct.  I have only yet read a 1977 ACM paper by 
Yourdon, but he does not look like the THRU/EXIT author in it.  For some 
reason I had a vague memory of a STEVENS or a JOHNSON or a SMITH that 
had written about Cobol specific structured programming with the 
THRU/EXIT style.


> The first two examples are in the spirit of structured programming
> but only the last, the one with GO TO, is faithful to it and may be
> read from top to bottom.
> 
> My point is that a translation of a structure that uses GO TO
> does not automatically make the resulting program unstructured.
> It is not my point that one should actually use GO TO in these
> circumstances. (Though I did so when using 6800 assembler.)

You are quite correct.  That was quite responsible use of the GO TO 
verb.  My only concern is maintenance -- something the academics never 
mention when they design styles and methodologies.  I suspect that if 
you put the following into production:

   LOOP-REPEAT.
      statement.
      statement.
      IF NOT condition GO TO LOOP-REPEAT.

After several iterations of maintenance you might find it looking like:

   LOOP-REPEAT.
      statement.
      IF 3am-fix = 'Y' GO TO WILD-BRANCH.
      statement.
      IF new-project = 154 GO TO OTHER-PLACE.
      statement.
      IF NOT condition GO TO LOOP-REPEAT.

While it might be caught by a code review, the problem is that people 
who would be likely to code the above are exactly the people who will 
not be able to understand the difference between the first, responsible, 
use of GO TO and the subsequent, irresponsible uses.

I just do not trust programmers to maintain responsible use of GO TO.
0
6/22/2004 12:43:01 PM
In article <joe_zitzelberger-43FFA8.08430122062004@corp.supernews.com>,
Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:

[snip]

>My only concern is maintenance -- something the academics never 
>mention when they design styles and methodologies.  I suspect that if 
>you put the following into production:
>
>   LOOP-REPEAT.
>      statement.
>      statement.
>      IF NOT condition GO TO LOOP-REPEAT.
>
>After several iterations of maintenance you might find it looking like:
>
>   LOOP-REPEAT.
>      statement.
>      IF 3am-fix = 'Y' GO TO WILD-BRANCH.
>      statement.
>      IF new-project = 154 GO TO OTHER-PLACE.
>      statement.
>      IF NOT condition GO TO LOOP-REPEAT.
>
>While it might be caught by a code review, the problem is that people 
>who would be likely to code the above are exactly the people who will 
>not be able to understand the difference between the first, responsible, 
>use of GO TO and the subsequent, irresponsible uses.

If people have trouble understanding 'Use of the GO TO imperative is 
restricted to three, and only three conditions: to the paragraph-name 
immediately preceding the imperative, to the -EXIT paragraph of the 
invoking statement's PERFORM THRU and to the common ABEND routine' then 
perhaps one's hiring practises might do with a bit of review.

>
>I just do not trust programmers to maintain responsible use of GO TO.

Ummmmmm... with all due respect, Mr Zitzelberger, what construct(s) *do* 
you trust programmer to 'maintain responsible use of'?  If the aphorism 
'anything that can be used can be abused' is true the list might be rather 
short.

DD

0
docdwarf (6044)
6/22/2004 1:00:35 PM
We could strive for wisdom.
We all make mistakes.

Warren Simmons

Robert Wagner wrote:
> Peter Lacey <lacey@mb.sympatico.ca> wrote:
> 
> 
>>I suspect that you guys are all barking up the wrong tree about Robert
>>Wagner.  Check out the French mathematician named Nicholas Bourbaki.   
>>Same situation?
> 
> 
> N. Bourbaki was a mathematical genius I find the word "genius" applied too
> liberally. Yes I qualified for "M squared', meaning the upper 2% of the upper 2%
> of the general population. But that's a measure of potential. When one reaches
> the age of accomplishment, roughly about 30, actual accomplishment replaces
> prognostigations. We should be judged on what we did rather than what we
> hypothetically might have done. 
> 
0
wsimmons5 (172)
6/22/2004 4:17:32 PM
And you should not. If you can arrange it, find a way
to review code before it is approved for installation.
Considering the things that are done to optimize code,
it seems resonable to me, to specify such a check in the
pre processor of the compiler.

Warren Simmons

Joe Zitzelberger wrote:

> In article <10dei1ic805ka30@corp.supernews.com>,
>  "Rick Smith" <ricksmith@mfi.net> wrote:
> 
>>I also decided to review Yourdon's work, at least the books I have
>>with Yourdon's name as an author. I am not not certain that 'modified
>>Yourdon structuring' is other than 'John Doe structuring'; that is,
>>some unidentified person took what Yourdon wrote and modified
>>it to allow GO TO under additional cicumstances.
> 
> 
> I suspect you are correct.  I have only yet read a 1977 ACM paper by 
> Yourdon, but he does not look like the THRU/EXIT author in it.  For some 
> reason I had a vague memory of a STEVENS or a JOHNSON or a SMITH that 
> had written about Cobol specific structured programming with the 
> THRU/EXIT style.
> 
> 
> 
>>The first two examples are in the spirit of structured programming
>>but only the last, the one with GO TO, is faithful to it and may be
>>read from top to bottom.
>>
>>My point is that a translation of a structure that uses GO TO
>>does not automatically make the resulting program unstructured.
>>It is not my point that one should actually use GO TO in these
>>circumstances. (Though I did so when using 6800 assembler.)
> 
> 
> You are quite correct.  That was quite responsible use of the GO TO 
> verb.  My only concern is maintenance -- something the academics never 
> mention when they design styles and methodologies.  I suspect that if 
> you put the following into production:
> 
>    LOOP-REPEAT.
>       statement.
>       statement.
>       IF NOT condition GO TO LOOP-REPEAT.
> 
> After several iterations of maintenance you might find it looking like:
> 
>    LOOP-REPEAT.
>       statement.
>       IF 3am-fix = 'Y' GO TO WILD-BRANCH.
>       statement.
>       IF new-project = 154 GO TO OTHER-PLACE.
>       statement.
>       IF NOT condition GO TO LOOP-REPEAT.
> 
> While it might be caught by a code review, the problem is that people 
> who would be likely to code the above are exactly the people who will 
> not be able to understand the difference between the first, responsible, 
> use of GO TO and the subsequent, irresponsible uses.
> 
> I just do not trust programmers to maintain responsible use of GO TO.
0
wsimmons5 (172)
6/22/2004 4:26:23 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> Stroustrup wants to create two classes of programmers: a lower class that does
> boring, repetitive work using unsophisticated tools, and an upper class that
> handles complex problems through the use of intelligence and education. This
> elitist attitude is common in academia, where Dr. Stroustrup has spent his
> entire life. 

No. Quite wrong.  Bjarne has nothing to do with creating any sorts of
classes at all, except those in C++.  He is _observing_ and reporting.

It may well be that businesses want to create different 'classes' of
programmers and for critical business applications there is a need for
an approach to programming that may seem rather dull to some, a
reduced risk approach, a conservative approach that can be understood
by a wide variety of practioners.

You may well compare this to other trades:  Drivers for example. 
There are a large number of drivers who take trucks from place to
place and are expected to do it conservatively and regularly.  And
then there are drivers who are expected to take high risks while
taking a few seconds less than anyone else to complete a course.

Complaining that this is trying to 'create' a "lower class" of drivers
that does "boring, repetitive work using unsophisticated tools" would
be seen as complete nonsense.

It is _you_, Robert, that want to be an elitist.

> Stroustrup did not show how it follows that OO functionality does not apply to
> batch processing. His assertion is not suppored by argumentation.

Perhaps he thought that anyone who understood the functionality of
objects would understand why it is not a requirement.

For example one feature of OO functionality is the creation of
multiple instances of objects.  Batch programs use files for this and
serially reuse record areas.

> Let me guess .. another language is 'a better tool for the job.' Sounds like a
> circular argument.

They do truck racing here.  It may be fun to see that these can
actually get around the track one would not want those drivers doing
the frieght runs, nor would one ever think that those vehicles are the
best for the job of taking one man around the track the fastest way.

One certainly can contemplate a 'technology transfer', but only where
there is an actual benefit, not because someone tries to be an
elitist.
0
riplin (4127)
6/22/2004 8:06:17 PM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> Wrong. I stopped using GO TO in the '60s.

Until the universal availability of scope terminators there were
several ways that flow could be controlled around the problem areas
where a single full stop would terminate all scopes.  Some of these
led to complexity problems of having too many small paragraphs, others
led to repitition of condition tests.

It is a matter of balancing 'purity' against complexity and
reliability.  You may well have a level of purity that approached
sainthood (in your own church at least), but for others a more
pragmatic resolution was required.

> True, but Cobol is plagued with large programs more than other languages. It
> seems a feature of 'Cobol culture' as practiced in big shops.

I suspect that you have a rather limited experience.  Large Fortran
programs used also to be found.  But this is a matter of 'selection of
the fittest'.  If large programs were a 'plague' then this would have
been resolved by the programming shops themselves.  If they didn't
work or were too expensive in some way, the business case would have
removed them.

Just because you don't like them doesn't mean that they are wrong.

> >What particular OO features do you think that batch programs need ?
> 
> Reusability.

But 'reusability' is not a unique feature of OO design.  That is, it
is not necessary to have object orientation to have code reusability.

> Packaging logic close to the data it operates on. 

That is a convenience for the source editing, perhaps better editing
tools will help you there.
 
> Packaging ALL logic that operates on a particular datum in one place. 

Why is that actually an advantage ?

You seem to want, for example, a simple print report program to carry
all the baggage of the logic that would be used to update the file. 
Instead of the programmer being able to focus on the _procedure_ being
performed, you want them to deal with all the other complexities.

This _may_ be appropriate in types of programs that actually do deal
with all possible actions that apply to data items, such as would
occur in interactive programs or where programmers may have to use all
the logic, but it is not an advantage where there are 'classes' of
programmers.

You don't need 24 gear gearboxes on local delivery vans.

> Ability to define structures more complex than a record or array.

Really ?  Do they _need_ this ?  Why ?

> Ability to perform operations on those structures more complex than Copy,
> facilitating abstraction in design.

Really ? Do they _require_ this ?  Why.  Give examples.

> Ability to change logic by overriding rather than modifying existing logic,
> especially useful when you don't have access to existing third-party code.
>
> Separation between low-level mechanics (reading files) and application logic.

All that you have done is listed a few features from an OO primer and
stated these are _required_.

There is no argumentation, no justification, no rationale, just you
want it.

> Garbage gets paged out of real memory.

Garbage _may_ be paged out of real memory, except where it resides in
the same pages or segments that non-garbage resides in.  These objects
are created on the heap and ddrop out of scope in random ways.  Some
remain and some are now garbage.  Because of the granuality of the
address space being larger than a typical object the garbage may
reside in real memory.  Garbage collection will allow that space to be
reused.

A little better understanding will allow you to make fewer errors of
judgement.
 
> Even with "lots of memory", multi-dimensional arrays can grow to
> multi-gigabytes. For instance, I wrote a 'program' (a series of modular
> programs) that parses freeform text documents, a very common data warehousing
> problem. Suppose I had allocated 30 bytes per word (not enough, as Cobol has
> shown), 20 words per line, 10,000 lines per document and a maximum of 3,000
> documents (way too small). My array would have taken 18GB. If I'd carelessly
> used INITIALIZE, every one of those bytes would have been touched.
 
> Because I used lists, it ran in 500MB.

You are attempting to use one extreme example to justify a general
case.  I very much doubt that '500Mbyte' is 'very common'.

> >The problem with pointers is that they are the 'GO TO' of data.
> 
> Only if they are single-threaded. The simplest tree is as fast as a binary
> lookup on an array. A tree can be made faster by increasing its width; an array
> cannot be speeded up.

Yet you finally did agree that your lists were actually slower than
arrays when challenged to prove your argument about speed, yet you
continue to make claims about how fast they are.

Increasing the 'width' of a tree built with pointers makes them slower
to create. There is _no_ restriction on having navigation paths in a
array by including index references to traverse the array in any
required manner.  Your assertions merely show a lack of imagination.

> If I hadn't used pointers, the aforementioned freeform text program would have
> been impractical. It would have taken all day to process 3,000 reports rather
> than 5 minutes.

Or it could have been done in a language with more appropriate
features.
0
riplin (4127)
6/22/2004 8:57:32 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> In that case, the name came from a file or database. My objection was to
> hardcoded names.

Without you even knowing whether they were hardcoded or not.

Do you _never_ have 'CALL literal' ?  Or 'INVOKE literal' ?

Or is your objection selective ?
0
riplin (4127)
6/22/2004 9:01:32 PM
docdwarf@panix.com wrote 


> Most signs I know of have something written on them... where are you 
> finding the talking one?

It is a special service for blind drivers.
0
riplin (4127)
6/22/2004 9:08:54 PM
In article <217e491a.0406221206.1e45f900@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote 
>
>> Stroustrup wants to create two classes of programmers: a lower class that does
>> boring, repetitive work using unsophisticated tools, and an upper class that
>> handles complex problems through the use of intelligence and education. This
>> elitist attitude is common in academia, where Dr. Stroustrup has spent his
>> entire life. 

[snip]

>It is _you_, Robert, that want to be an elitist.

Come now, Mr Plinston... someone who desires an 'elite' position might do 
things like refer groups of 'Real Programmers' and assert that people who 
use a particular kind of hardware make a travesty of a language!  Would Mr 
Wagner ever do such things?

DD

0
docdwarf (6044)
6/22/2004 9:31:33 PM
In article <217e491a.0406221308.47cd4278@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote 
>
>
>> Most signs I know of have something written on them... where are you 
>> finding the talking one?
>
>It is a special service for blind drivers.

Ahhhh... you must mean the guys that use the Braille on the drive-up ATMs!

DD

0
docdwarf (6044)
6/22/2004 9:33:58 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> I always thought of EXIT as a 'filler' word, like CONTINUE, to be used where
> you had nothing to say. 

It is commentary, it is put where the programmer wants to say that
this is the point at which the procedure will exit.

> It did not necessarily exit. It only exited if it was at the
> end of a PERFORM THRU.

Actually that is quite wrong.  An EXIT in its own paragraph may also
be used as the last point in a PERFORM section where the next label is
a section header.

You seem to be assuming that THRU is the only mechanism for EXIT to be
used, and thus EXIT was constructed for THRU.

> When a paragraph of straight line code was commented out,
> the maintainer would sometimes replace the body with EXIT, meaning fall thru to
> the next paragraph.

Did they ?  Did it ?  You just made that up.  The easiest to 'comment
out' a paragraph was to use NOTE.
 
> I believe PERFORM 1234-some-paragraph THRU 1234-EXIT _is_ abusive, and I'm first
> generation. Setting aside the issue of numbered paragraphs, what's wrong with
> PERFORM some-paragraph? They think they _might_ want to exit prematurely, so
> they make it a Standard that _every_ paragraph have an exit paragraph. 

It is useful to have a consistent standard for structuring programs. 
Many decided that PERFORM section provided that consistency, with or
without an exit paragraph.

> Well, EXIT PARAGRAPH takes the wind out of those sails. 

I dislike EXIT PARAGRAPH and EXIT SECTION and see them as merely a GO
TO without a specific label.  I would prefer them not to exist and
code to be complete without these.
 
> Documentation people dropped the ball by failing to list EXIT PARAGRAPH in the
> index.

It is _always_ someone else's fault.  Is _every_ clause in the index
or do they expect the readers to have two clues to rub together.
0
riplin (4127)
6/22/2004 9:38:43 PM
<docdwarf@panix.com> wrote in message news:cba8k6$oc3$1@panix5.panix.com...
> In article <217e491a.0406221308.47cd4278@posting.google.com>,
> Richard <riplin@Azonic.co.nz> wrote:
> >docdwarf@panix.com wrote
> >
> >
> >> Most signs I know of have something written on them... where are you
> >> finding the talking one?
> >
> >It is a special service for blind drivers.
>
> Ahhhh... you must mean the guys that use the Braille on the drive-up ATMs!


I'd be lost without it........


0
no18 (4537)
6/22/2004 9:41:18 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> I always thought of EXIT as a 'filler' word, like CONTINUE, to be used where
> you had nothing to say. 

It is commentary, it is put where the programmer wants to say that
this is the point at which the procedure will exit.

> It did not necessarily exit. It only exited if it was at the
> end of a PERFORM THRU.

Actually that is quite wrong.  An EXIT in its own paragraph may also
be used as the last point in a PERFORM section where the next label is
a section header.

You seem to be assuming that THRU is the only mechanism for EXIT to be
used, and thus EXIT was constructed for THRU.

> When a paragraph of straight line code was commented out,
> the maintainer would sometimes replace the body with EXIT, meaning fall thru to
> the next paragraph.

Did they ?  Did it ?  You just made that up.  The easiest to 'comment
out' a paragraph was to use NOTE.
 
> I believe PERFORM 1234-some-paragraph THRU 1234-EXIT _is_ abusive, and I'm first
> generation. Setting aside the issue of numbered paragraphs, what's wrong with
> PERFORM some-paragraph? They think they _might_ want to exit prematurely, so
> they make it a Standard that _every_ paragraph have an exit paragraph. 

It is useful to have a consistent standard for structuring programs. 
Many decided that PERFORM section provided that consistency, with or
without an exit paragraph.

> Well, EXIT PARAGRAPH takes the wind out of those sails. 

I dislike EXIT PARAGRAPH and EXIT SECTION and see them as merely a GO
TO without a specific label.  I would prefer them not to exist and
code to be complete without these.
 
> Documentation people dropped the ball by failing to list EXIT PARAGRAPH in the
> index.

It is _always_ someone else's fault.  Is _every_ clause in the index
or do they expect the readers to have two clues to rub together.
0
riplin (4127)
6/22/2004 9:42:04 PM
In the 60's (or even in the 70's and first half of the 80's) - I wonder if those
claiming to NEVER use a GO TO

 A) never coded a SORT Input/Output procedure
        or
 B) only used compilers with an extension to the '68 & '74 Standards

***

It was TOTALLY impossible (with a conforming to those Standards) compiler to
code a "loop" in a SORT procedure without a GO TO.  This was because it was
non-conforming to PERFORM (thru) a procedure OUTSIDE the Input/Output procedure.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0406221257.4dedf3cd@posting.google.com...
> robert.deletethis@wagner.net (Robert Wagner) wrote
>
> > Wrong. I stopped using GO TO in the '60s.
>
> Until the universal availability of scope terminators there were
> several ways that flow could be controlled around the problem areas
> where a single full stop would terminate all scopes.  Some of these
> led to complexity problems of having too many small paragraphs, others
> led to repitition of condition tests.
>
> It is a matter of balancing 'purity' against complexity and
> reliability.  You may well have a level of purity that approached
> sainthood (in your own church at least), but for others a more
> pragmatic resolution was required.
>
> > True, but Cobol is plagued with large programs more than other languages. It
> > seems a feature of 'Cobol culture' as practiced in big shops.
>
> I suspect that you have a rather limited experience.  Large Fortran
> programs used also to be found.  But this is a matter of 'selection of
> the fittest'.  If large programs were a 'plague' then this would have
> been resolved by the programming shops themselves.  If they didn't
> work or were too expensive in some way, the business case would have
> removed them.
>
> Just because you don't like them doesn't mean that they are wrong.
>
> > >What particular OO features do you think that batch programs need ?
> >
> > Reusability.
>
> But 'reusability' is not a unique feature of OO design.  That is, it
> is not necessary to have object orientation to have code reusability.
>
> > Packaging logic close to the data it operates on.
>
> That is a convenience for the source editing, perhaps better editing
> tools will help you there.
>
> > Packaging ALL logic that operates on a particular datum in one place.
>
> Why is that actually an advantage ?
>
> You seem to want, for example, a simple print report program to carry
> all the baggage of the logic that would be used to update the file.
> Instead of the programmer being able to focus on the _procedure_ being
> performed, you want them to deal with all the other complexities.
>
> This _may_ be appropriate in types of programs that actually do deal
> with all possible actions that apply to data items, such as would
> occur in interactive programs or where programmers may have to use all
> the logic, but it is not an advantage where there are 'classes' of
> programmers.
>
> You don't need 24 gear gearboxes on local delivery vans.
>
> > Ability to define structures more complex than a record or array.
>
> Really ?  Do they _need_ this ?  Why ?
>
> > Ability to perform operations on those structures more complex than Copy,
> > facilitating abstraction in design.
>
> Really ? Do they _require_ this ?  Why.  Give examples.
>
> > Ability to change logic by overriding rather than modifying existing logic,
> > especially useful when you don't have access to existing third-party code.
> >
> > Separation between low-level mechanics (reading files) and application
logic.
>
> All that you have done is listed a few features from an OO primer and
> stated these are _required_.
>
> There is no argumentation, no justification, no rationale, just you
> want it.
>
> > Garbage gets paged out of real memory.
>
> Garbage _may_ be paged out of real memory, except where it resides in
> the same pages or segments that non-garbage resides in.  These objects
> are created on the heap and ddrop out of scope in random ways.  Some
> remain and some are now garbage.  Because of the granuality of the
> address space being larger than a typical object the garbage may
> reside in real memory.  Garbage collection will allow that space to be
> reused.
>
> A little better understanding will allow you to make fewer errors of
> judgement.
>
> > Even with "lots of memory", multi-dimensional arrays can grow to
> > multi-gigabytes. For instance, I wrote a 'program' (a series of modular
> > programs) that parses freeform text documents, a very common data
warehousing
> > problem. Suppose I had allocated 30 bytes per word (not enough, as Cobol has
> > shown), 20 words per line, 10,000 lines per document and a maximum of 3,000
> > documents (way too small). My array would have taken 18GB. If I'd carelessly
> > used INITIALIZE, every one of those bytes would have been touched.
>
> > Because I used lists, it ran in 500MB.
>
> You are attempting to use one extreme example to justify a general
> case.  I very much doubt that '500Mbyte' is 'very common'.
>
> > >The problem with pointers is that they are the 'GO TO' of data.
> >
> > Only if they are single-threaded. The simplest tree is as fast as a binary
> > lookup on an array. A tree can be made faster by increasing its width; an
array
> > cannot be speeded up.
>
> Yet you finally did agree that your lists were actually slower than
> arrays when challenged to prove your argument about speed, yet you
> continue to make claims about how fast they are.
>
> Increasing the 'width' of a tree built with pointers makes them slower
> to create. There is _no_ restriction on having navigation paths in a
> array by including index references to traverse the array in any
> required manner.  Your assertions merely show a lack of imagination.
>
> > If I hadn't used pointers, the aforementioned freeform text program would
have
> > been impractical. It would have taken all day to process 3,000 reports
rather
> > than 5 minutes.
>
> Or it could have been done in a language with more appropriate
> features.


0
wmklein (2605)
6/22/2004 10:25:22 PM
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d77642.32368855@news.optonline.net...

> Not being an MCP programmer, I don't know. But as they say in the movies,
'give
> me an hour with it and I'll make it spill its guts.'

To write MCP-like code, or to modify the current MCP, you have to be writing
in a language that allows you that sort of access to the hardware in the
first place.   Programs containing such constructs can't be executed as
standalone programs to begin with (although COBOL programs *might* be able
to access them through other interfaces if the MCP has previously "blessed"
those other interfaces and the wind is right).

> Look here:
> http://www.metalogic.eu.com/Main/about/about.htm

Thanks for the reference.  Taking this as an example:  "A dynamic memory
cache algorithm, which alters the cache size based on the instantaneous I/O
and memory traffic."  I don't know what the particular system software
interfaces this particular piece of system software uses are, but I am aware
that there are a whole lot of procedures in the system software that the
knowledgeable can exploit to provide this sort of functionality without
having to fish it out of raw memory, and as I recall these interfaces are
documented.  My guess is that this program is making use of documented entry
points into system software libraries, including but not limited to the MCP
itself, and that it is written in some dialect of ALGOL.  I seriously doubt
that *any* of the entry points this program is using to gather and modify
this information are accessible from COBOL.

> Lacking an audit trail, you ...

Ummm ... ?   Do I?

> don't know whether developers are exploiting holes
> in your system.

I don't know whether users are building software that might exploit such
holes.  I *do* know that they are not building software *in COBOL* that does
so.

> Reliance on 'user ignorance' is really bad security.

I don't disagree.  Reliance on the nonexistence of constructs that can allow
breaches of security is rather better, though.   If you can't get there from
COBOL you can't get there from COBOL.

> And third parties' knowledge of your system might be superior to yours.

No doubt to mine personally if "yours" is singular, although I would contend
the knowledge of the architects of the system (some of whom have been
involved in the evolution from the B5000 to the latest Libra 580 over a
period of forty years or so) would be hard to beat.

If some third party comes up with a "better idea" for the Unisys MCP
environment, it might be a demonstration that the developer saw it as a
greater marketing opportunity than the Unisys beancounters did.  I've seen
that happen on a number of occasions.   I've also seen third-party
developers take on projects that Unisys started and then decided not to
pursue.

There is a great deal about our system software *and* our hardware that
changes over time, sometimes significantly, without there necessarily being
any notice of the speicifics of those changes to the users, except that we
require our users to recompile all their programs every few years to keep up
with these changes.

It's one thing for a user to know *that* he has to recompile a program that
was compiled under SSR 45.1 before it will execute under SSR 50.1 (after
all, the MCP will tell him "This codefile is too old to run on this release"
if he tries); it may not be nearly so clear *how* the undocumented internal
interfaces might have changed, much less *why*, between those releases, or
what the consequences would be if he convinced the MCP to relent in its
prohibition.

    -Chuck Stevens


0
6/22/2004 10:30:01 PM
In article <cb9ahj$foj$1@panix5.panix.com>, docdwarf@panix.com wrote:

> In article <joe_zitzelberger-43FFA8.08430122062004@corp.supernews.com>,
> Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:
> 
> [snip]
> 
> >My only concern is maintenance -- something the academics never 
> >mention when they design styles and methodologies.  I suspect that if 
> >you put the following into production:
> >
> >   LOOP-REPEAT.
> >      statement.
> >      statement.
> >      IF NOT condition GO TO LOOP-REPEAT.
> >
> >After several iterations of maintenance you might find it looking like:
> >
> >   LOOP-REPEAT.
> >      statement.
> >      IF 3am-fix = 'Y' GO TO WILD-BRANCH.
> >      statement.
> >      IF new-project = 154 GO TO OTHER-PLACE.
> >      statement.
> >      IF NOT condition GO TO LOOP-REPEAT.
> >
> >While it might be caught by a code review, the problem is that people 
> >who would be likely to code the above are exactly the people who will 
> >not be able to understand the difference between the first, responsible, 
> >use of GO TO and the subsequent, irresponsible uses.
> 
> If people have trouble understanding 'Use of the GO TO imperative is 
> restricted to three, and only three conditions: to the paragraph-name 
> immediately preceding the imperative, to the -EXIT paragraph of the 
> invoking statement's PERFORM THRU and to the common ABEND routine' then 
> perhaps one's hiring practises might do with a bit of review.
> 
> >
> >I just do not trust programmers to maintain responsible use of GO TO.
> 
> Ummmmmm... with all due respect, Mr Zitzelberger, what construct(s) *do* 
> you trust programmer to 'maintain responsible use of'?  If the aphorism 
> 'anything that can be used can be abused' is true the list might be rather 
> short.
> 
> DD


Granted, hiring practices can be set to restrict the use of a GO TO -- 
but those only go so far.  Even if one is fired after applying a 3am fix 
using GO TO -- the issue then becomes, well, it's working, should we not 
mess with it? 

Ideally, one could design the ultimate programmers aptitude test as a 
precondition to employment.  Only applicants that show they understand 
the benefits of well-defined constructs and who voluntarily eschew GO TO 
would be hired.  This should generate a better quality of programmer, or 
at least a pool of programmers that is able to learn from 50 years of 
others mistakes. 

(Actually designing such an aptitude test is left as an exercise for the 
user...;-)

When a programmer expects me to trust his ability to code, he should 
show proficiency using the most well-known, least error-prone constructs.

The very idea of structured programming relies upon sequence, selection 
(IF/EVALUATE) and iteration (PERFORM).  30 years ago, there was limited 
support for these, and that necessitated creating your own with GO TO.  
However, modern Cobol has full support for such things.

You are correct that anything can be abused -- but GO TO requires effort 
NOT to abuse it.  That should be reason enough.
0
6/22/2004 11:12:08 PM
Chuck Stevens wrote:

> "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> news:40d77642.32368855@news.optonline.net...
> 
> 
>>Not being an MCP programmer, I don't know. But as they say in the movies,
> 
> 'give
> 
>>me an hour with it and I'll make it spill its guts.'
> 
> 
> To write MCP-like code, or to modify the current MCP, you have to be writing
> in a language that allows you that sort of access to the hardware in the
> first place.   Programs containing such constructs can't be executed as
> standalone programs to begin with (although COBOL programs *might* be able
> to access them through other interfaces if the MCP has previously "blessed"
> those other interfaces and the wind is right).
> 
> 
>>Look here:
>>http://www.metalogic.eu.com/Main/about/about.htm
> 
> 
> Thanks for the reference.  Taking this as an example:  "A dynamic memory
> cache algorithm, which alters the cache size based on the instantaneous I/O
> and memory traffic."  I don't know what the particular system software
> interfaces this particular piece of system software uses are, but I am aware
> that there are a whole lot of procedures in the system software that the
> knowledgeable can exploit to provide this sort of functionality without
> having to fish it out of raw memory, and as I recall these interfaces are
> documented.  My guess is that this program is making use of documented entry
> points into system software libraries, including but not limited to the MCP
> itself, and that it is written in some dialect of ALGOL.  I seriously doubt
> that *any* of the entry points this program is using to gather and modify
> this information are accessible from COBOL.
> 
> 
>>Lacking an audit trail, you ...
> 
> 
> Ummm ... ?   Do I?
> 
> 
>>don't know whether developers are exploiting holes
>>in your system.
> 
> 
> I don't know whether users are building software that might exploit such
> holes.  I *do* know that they are not building software *in COBOL* that does
> so.
> 
> 
>>Reliance on 'user ignorance' is really bad security.
> 
> 
> I don't disagree.  Reliance on the nonexistence of constructs that can allow
> breaches of security is rather better, though.   If you can't get there from
> COBOL you can't get there from COBOL.
> 
> 
>>And third parties' knowledge of your system might be superior to yours.
> 
> 
> No doubt to mine personally if "yours" is singular, although I would contend
> the knowledge of the architects of the system (some of whom have been
> involved in the evolution from the B5000 to the latest Libra 580 over a
> period of forty years or so) would be hard to beat.
> 
> If some third party comes up with a "better idea" for the Unisys MCP
> environment, it might be a demonstration that the developer saw it as a
> greater marketing opportunity than the Unisys beancounters did.  I've seen
> that happen on a number of occasions.   I've also seen third-party
> developers take on projects that Unisys started and then decided not to
> pursue.
> 
> There is a great deal about our system software *and* our hardware that
> changes over time, sometimes significantly, without there necessarily being
> any notice of the speicifics of those changes to the users, except that we
> require our users to recompile all their programs every few years to keep up
> with these changes.
> 
> It's one thing for a user to know *that* he has to recompile a program that
> was compiled under SSR 45.1 before it will execute under SSR 50.1 (after
> all, the MCP will tell him "This codefile is too old to run on this release"
> if he tries); it may not be nearly so clear *how* the undocumented internal
> interfaces might have changed, much less *why*, between those releases, or
> what the consequences would be if he convinced the MCP to relent in its
> prohibition.

The above is one way to force a shop to keep correct source.  This must 
make system upgrades interesting.  I think that IBM is of two minds on 
this.  The z series is still able to execute many programs that were 
compiled and linked 30 years ago and more (360 and descendants).  I 
understand the i series (S38 and AS400 and descendants) requires mass 
recompiles as a part of system upgrades.  I don't know what shops do if 
they lose the source.

>     -Chuck Stevens
> 
> 

0
cfmtech (125)
6/23/2004 12:07:01 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote

>> It did not necessarily exit. It only exited if it was at the
>> end of a PERFORM THRU.
>
>Actually that is quite wrong.  An EXIT in its own paragraph may also
>be used as the last point in a PERFORM section where the next label is
>a section header.

EXIT at the end of a section is superfluous. If it is omitted, the program exits
in exactly the same way. 

>You seem to be assuming that THRU is the only mechanism for EXIT to be
>used, and thus EXIT was constructed for THRU.

It was constructed for paragraphs that would otherwise be empty. Such as one
commented out.

>> When a paragraph of straight line code was commented out,
>> the maintainer would sometimes replace the body with EXIT, meaning fall thru
to
>> the next paragraph.
>
>Did they ?  Did it ?  You just made that up.  The easiest to 'comment
>out' a paragraph was to use NOTE.

Now you've stepped in cow dung. NOTE was deleted from the Standard for good
reason -- it was a bugtrap.

>> I believe PERFORM 1234-some-paragraph THRU 1234-EXIT _is_ abusive, and I'm
first
>> generation. Setting aside the issue of numbered paragraphs, what's wrong with
>> PERFORM some-paragraph? They think they _might_ want to exit prematurely, so
>> they make it a Standard that _every_ paragraph have an exit paragraph. 
>
>It is useful to have a consistent standard for structuring programs. 
>Many decided that PERFORM section provided that consistency, with or
>without an exit paragraph.

Sections seem to be popular outside the US. For whatever reason, US programmers
think PERFORM THRU is better. 

I use a simple PERFORM, or better yet, a CALL.

>> Well, EXIT PARAGRAPH takes the wind out of those sails. 
>
>I dislike EXIT PARAGRAPH and EXIT SECTION and see them as merely a GO
>TO without a specific label.  I would prefer them not to exist and
>code to be complete without these.

I agree. Well-structured code doesn't need procedural bail-outs. The same can be
accomplished with conditionals such as UNTIL.

0
6/23/2004 12:25:08 AM
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

>In the 60's (or even in the 70's and first half of the 80's) - I wonder if
those
>claiming to NEVER use a GO TO
>
> A) never coded a SORT Input/Output procedure
>        or
> B) only used compilers with an extension to the '68 & '74 Standards
>
>***
>
>It was TOTALLY impossible (with a conforming to those Standards) compiler to
>code a "loop" in a SORT procedure without a GO TO.  This was because it was
>non-conforming to PERFORM (thru) a procedure OUTSIDE the Input/Output
>procedure. 

You are correct. We had to GO TO the exit of the input and output procedure
sections.

I regarded it as an 'impurity' imposed by the Cobol Standard. 


0
6/23/2004 12:25:10 AM
Well actually, he has both the credentials and the credibility to talk
anyway he wants to
anyone if the subject is COBOL. Fortunately, he is an exceedingly polite
person, unless
he has reason to believe he has been insulted or mistreated. Sort of the
same
way you view yourself I suppose.

Basically, you are in the middle of a pissing contest and I hate to point
this out, but even
if your view is correct, you cannot win. So basically, you can either pout,
or put it behind
you and act politely.

Or you can get on everyone's 'kill list' and loose any and all of the
credibility you have
built up here. Your choice my man, but if you want any kind of advice, I
suggest you
just not worry about and move past it. Indeed, you are really working hard
to alienate
yourself by acting this way.

<grin><joshing> As for PeopleSoft, you pay taxes don't you? I *know* what
computers the
IRS and SSA use... </joshing></grin>

-Paul


"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40d799de.41486419@news.optonline.net...
> "Paul Raulersonv" <pkrauleson@verizon.net> wrote:
>
> >But you *really* need to lay off Bill - the man does more than you, me,
and
> everyone
> >else around here to promote Cobol, and that is a fact that cannot be
argued.
>
> He talks to me with disrespect, I respond in like kind.  One would hope a
> committee member would have better political skills.
>
> >If you want to pick on mainframers - pick on me. Whatever kind of
paycheck you
> >get is probably created or ordered from a mainframe someone. Piss me off
too
> much
> >and...
>
> My payroll is run on PeopleSoft running on a Unix box. You and your
mainframe
> have been disenfranchised.
>


0
6/23/2004 2:07:50 AM
In article <joe_zitzelberger-352FBD.19120822062004@corp.supernews.com>,
Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:
>In article <cb9ahj$foj$1@panix5.panix.com>, docdwarf@panix.com wrote:
>
>> In article <joe_zitzelberger-43FFA8.08430122062004@corp.supernews.com>,
>> Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:
>> 
>> [snip]
>> 
>> >My only concern is maintenance -- something the academics never 
>> >mention when they design styles and methodologies.  I suspect that if 
>> >you put the following into production:
>> >
>> >   LOOP-REPEAT.
>> >      statement.
>> >      statement.
>> >      IF NOT condition GO TO LOOP-REPEAT.
>> >
>> >After several iterations of maintenance you might find it looking like:
>> >
>> >   LOOP-REPEAT.
>> >      statement.
>> >      IF 3am-fix = 'Y' GO TO WILD-BRANCH.
>> >      statement.
>> >      IF new-project = 154 GO TO OTHER-PLACE.
>> >      statement.
>> >      IF NOT condition GO TO LOOP-REPEAT.
>> >
>> >While it might be caught by a code review, the problem is that people 
>> >who would be likely to code the above are exactly the people who will 
>> >not be able to understand the difference between the first, responsible, 
>> >use of GO TO and the subsequent, irresponsible uses.
>> 
>> If people have trouble understanding 'Use of the GO TO imperative is 
>> restricted to three, and only three conditions: to the paragraph-name 
>> immediately preceding the imperative, to the -EXIT paragraph of the 
>> invoking statement's PERFORM THRU and to the common ABEND routine' then 
>> perhaps one's hiring practises might do with a bit of review.
>> 
>> >
>> >I just do not trust programmers to maintain responsible use of GO TO.
>> 
>> Ummmmmm... with all due respect, Mr Zitzelberger, what construct(s) *do* 
>> you trust programmer to 'maintain responsible use of'?  If the aphorism 
>> 'anything that can be used can be abused' is true the list might be rather 
>> short.
>> 
>
>
>Granted, hiring practices can be set to restrict the use of a GO TO -- 
>but those only go so far.  Even if one is fired after applying a 3am fix 
>using GO TO -- the issue then becomes, well, it's working, should we not 
>mess with it? 

If 'the issue' becomes that then the organisation has the code it 
deserves... then again, your situation proposed above might also easily be 
applied to any coding construct whatsoever.

'Hey... that 3:AM fix you put it has a PERFORM THRU.'

'Well, it's working, should we not mess with it?'

>
>Ideally, one could design the ultimate programmers aptitude test as a 
>precondition to employment.

Ability to follow simple instructions such as 'GO TO is to be used only 
under three conditions (etc)' is behavior that has been seen demonstrated 
by life-forms lower than programmers... if such a thing could be imagined!

[snip]

>When a programmer expects me to trust his ability to code, he should 
>show proficiency using the most well-known, least error-prone constructs.

.... and code should be easy-to-understand... which means using the 
constructs and style which the proponent is proposing, no?

>
>The very idea of structured programming relies upon sequence, selection 
>(IF/EVALUATE) and iteration (PERFORM).  30 years ago, there was limited 
>support for these, and that necessitated creating your own with GO TO.  
>However, modern Cobol has full support for such things.
>
>You are correct that anything can be abused -- but GO TO requires effort 
>NOT to abuse it.  That should be reason enough.

'... requires effort NOT to abuse it'... you mean one must be disciplined?  
Zounds, take that out of the hiring-exam... can't have any disciplined 
coders in *this* shop!

DD

0
docdwarf (6044)
6/23/2004 2:13:19 AM
In article <2I1Cc.116897$Gx4.72886@bgtnsc04-news.ops.worldnet.att.net>,
Hugh Candlin <no@spam.com> wrote:
>
><docdwarf@panix.com> wrote in message news:cba8k6$oc3$1@panix5.panix.com...
>> In article <217e491a.0406221308.47cd4278@posting.google.com>,
>> Richard <riplin@Azonic.co.nz> wrote:
>> >docdwarf@panix.com wrote
>> >
>> >
>> >> Most signs I know of have something written on them... where are you
>> >> finding the talking one?
>> >
>> >It is a special service for blind drivers.
>>
>> Ahhhh... you must mean the guys that use the Braille on the drive-up ATMs!
>
>
>I'd be lost without it........

Wow... they print location-directions there?  The things you learn on 
UseNet!

DD

0
docdwarf (6044)
6/23/2004 2:18:38 AM
     Am  22.06.04
schrieb  cfmtech@istar.ca (Clark F. Morris, Jr.)
    auf  /COMP/LANG/COBOL
     in  cbahjl$a5r$1@news.eusc.inter.net
  ueber  Method to force keeping of source was Re: Is it possible to use the va

LW>> It's one thing for a user to know *that* he has to recompile a program
LW>> that was compiled under SSR 45.1 before it will execute under SSR 50.1
LW>> (after all, the MCP will tell him "This codefile is too old to run on
LW>> this release" if he tries); it may not be nearly so clear *how*  
the
LW>> undocumented internal interfaces might have changed, much less *why*,
LW>> between those releases, or what the consequences would be if he
LW>> convinced the MCP to relent in its prohibition.

CFMJ> The above is one way to force a shop to keep correct source.  This
CFMJ> must make system upgrades interesting.  I think that IBM is of two
CFMJ> minds on this.  The z series is still able to execute many programs
CFMJ> that were compiled and linked 30 years ago and more (360 and
CFMJ> descendants).

  The same applies (or at least, did apply) to Unisys' OS/1100 line  
from the Sperry branch, which is called IX now, I understand.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Es sind nicht die Gener�le und K�nige, die die Geschichte machen,
sondern die breiten Massen des Volkes"                - Nelson Mandela
0
l.willms1 (637)
6/23/2004 7:38:00 AM
robert.deletethis@wagner.net (Robert Wagner) wrote

> >Actually that is quite wrong.  An EXIT in its own paragraph may also
> >be used as the last point in a PERFORM section where the next label is
> >a section header.
> 
> EXIT at the end of a section is superfluous. If it is omitted, the program
> exits in exactly the same way. 
> It was constructed for paragraphs that would otherwise be empty. Such as one
> commented out.

Your argument fails to take into account any actual historic facts (as
usual for you).

The EXIT statement was there to cater for the very early compiler code
to act as a 'place holder' for the PERFORM return code.  Wherever the
end of a PERFORM was required an EXIT has to be coded in its own
paragraph.  This was used by some compilers to generate null code that
was replaced by return code by the PERFORM statement.  The PERFORM
would then tidy up by making it null again so it would drop thru if
necessary.

While not all compilers required this, it certainly was the case with
some compilers that I worked with that pre-dated the '68 standard,
such as ICT's XE13.

The '68 standard reduced the EXIT to being non-functional and
optional, compilers had become somewhat more sophisticated.

Your assertion that it was for 'commented out paragraphs' is nonsense
because there was no mechanism to 'comment out code' that left a
paragraph without a statement until the '74 standard.

The '74 standard introduced the '*' in column 7.  Previously it would
be done by the NOTE statement which did not leave the paragraph empty
at all.

So your argument is that the committee constructed the EXIT to cater
for code that would not be possible until 15 years later.

> Now you've stepped in cow dung. NOTE was deleted from the Standard for good
> reason -- it was a bugtrap.

It was deleted when the '*' was added to replace it.  When the EXIT
was 'constructed' the only standard 'comment out' was NOTE, which did
not leave the paragraph 'empty' and thus did not require an 'EXIT' as
you claim.
0
riplin (4127)
6/23/2004 7:59:19 AM
"Paul Raulersonv" <pkrauleson@verizon.net> wrote in message news:<CYLBc.20277$Yb1.8409@nwrddc02.gnilink.net>...
> Peter - stop being sensible. It is not any fun at all to argue with you when I have to
> agree with you.
> 

Oops! Sorry, I'll try to be more stupid, so you can relate <G>

> And Bill- you know quite well that 90% of the people that read this forum consider
> you both an expert on everything Cobol, and darn near a Saint in how far you will
> go to help someone you don't even know. *Anyone* - even dumb questions from
> me. <grin>
> 

I just wanted to endorse that. Bill's knowledge about, and tireless
efforts on behalf of, COBOL, are simply staggering. Even apart from
that, he has a big heart and the right attitude. I guess everybody
gets pissed off occasionally, and sometimes we get too close to
things.

> So relax and don't worry about it. This group has developed some kind of synergy; behavior
> problems are mostly self correcting.
>

That's an interesting observation, Paul. I hadn't thought about it
like that but I think you're right.
 
Pete.

> -Paul
> 
> "Peter E. C. Dashwood" <dashwood@enternet.co.nz> wrote in message news:b3638c46.0406210854.29e8bb35@posting.google.com...
> > Bill,
> >
> > I read this thread with some sadness.
> >
> > I don't intend to take sides here but I have some observations I'll
> > certainly share with the group:
> >
> > 1. This is an open unmoderated forum. EVERYONE has a right to post
> > here. That includes Robert.
> >
> > Similarly, EVERYONE has a right to respond or not. It is a choice.
> >
> > My feeling is that if a given individual's posts upset you, ignore
> > them. There is no COMPULSION (other than the innate pyschological one)
> > that says you MUST respond to someone's post. History has shown that
> > if a given individual's posts are consistently ignored, that
> > individual will usually recognise that it is pointless to post, and
> > depart.
> >
> > I would see this kind of treatment being reserved for people who
> > flame, "haunt", and/or generally seek to destroy the group. I don't
> > think Robert comes in that category at the moment, even though he is
> > on record (a long time ago) as saying that that was his aim... I'd
> > like to believe he has "grown" since that time.
> > (Maybe Robert might care to comment as to whether that is still his
> > stated aim?)
> >
> > Different people will deal with what happens here in different ways.
> >
> > Some people will depart in a sulk or huff (not naming any names, but
> > I'm sure you've seen a recent example of this... :-). Now, you could
> > argue that it is entirely my fault that person departed. My response
> > would be: "I take responsibility for my own actions, not those of
> > others.").
> >
> > Others will just decide not to correspond with the "troublemakers".
> >
> > Some will continue posting, showing the errors in the post they object
> > to and arguing mercilessly. Debate is no bad thing.
> >
> > Each of us will respond (or not) in whatever way we feel comfortable.
> > There is no requirement for posts to be "acceptable". (But, it is nice
> > if they are...).
> >
> > In my own case, I have been a regular contributor here over many
> > years. I've made friends and enemies (in saying that, I can honestly
> > say I bear no malice to anyone here, present or departed, except Tony
> > Dilworth who is the lowest kind of pond scum and ....Oops! sorry...),
> > I've lost my rag on occasion, I've tried to calm things down on other
> > occasions, but it has always been "interesting". Now I find that there
> > are pressures on my time outside of COBOL, and also I believe that a
> > lot of the debate here really is pointless (that doesn't make me
> > advocate that we shouldn't have it; it just makes me re-evaluate
> > priorities on my time). It was Robert (ironically enough) who pointed
> > out in a response to recent mail of mine, that all of us have the same
> > time, 24 hours each day, it is just a question of priorities. I agree
> > 100%.
> >
> > But I would hate to see this group close or go off the air.
> >
> > The point is that what we have here is a valuable avenue of free
> > speech about things COBOL. (And all the other OT stuff that this group
> > has always generated... :-))
> >
> > 2. There will always be people and posts here that irritate or annoy
> > others.
> >
> > Escalating the conflict is unlikely to make it go away. Renaming a
> > thread with the name of an individual is not a reasonable way to
> > object, in my opinion. As soon as people are named, it becomes
> > personal. It is unfair and unworthy for the group to attack a given
> > individual (although a series of individual attacks are probably
> > fair...) Everyone should have the same right to a hearing.
> >
> > "I may not agree with what you say, but I shall defend to the death,
> > your right to say it."
> >
> > 3. I remember a certain person, a few years back, (not too far away
> > from this thread) who was "attacked" by a gang of people because he
> > held and expressed an unpopular viewpoint. I seem to recall writing an
> > article in defence of him... It would be a pity if the same gentleman
> > was not prepared to tolerate (or even ignore) the unpopular viewpoints
> >  (or specious arguments) of others...
> >
> > Finally, no matter how passionate any of us feel about CLC, no matter
> > how much we would like it to conform to certain guidelines or rules
> > (even common courtesy and decency), we cannot MAKE it so...
> >
> > If you want a moderated forum, start one.(I'll happily volunteer to be
> > on the moderator rota...)
> >
> > CLC is not such a forum and I really hope it never will be.
> >
> > (continues below...)
> >
> > "William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:<hDqBc.8580$w07.2455@newsread2.news.pas.earthlink.net>...
> > > "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> > > news:40d23662.118894516@news.optonline.net...
> > > > docdwarf@panix.com wrote:
> > > >
>  <snip>
> > > >
> > > > My reason for being here is to promote Cobol as a Real Programming Language
> > > > rather than the travesty that mainframers have turned it into.
> > >
> > I'm surprised you would rise to this obvious bait, Bill...
> >
> > > It appears (to many readers of CLC)[er...isn't quoting made-up statistics one of the things we are tryng to avoid? How many is
>  "many"?...]
> >
> >  that the *ONLY* purpose that you (Robert
> > > Wagner) have in posting to this group is to make (occasionally - but rarely)
> > > accurate "universal" statements and then continue threads well past the point
> > > that others have shown that your original statements have no "universality" and
> > > often little accuracy.
> >
> > I hate cliches, but isn't there one about a certain Latin American
> > dance that requires more than one person in order to dance it? <G> The
> > secret in corresponding with Robert is knowing when to stop...<G>
> >
> > >
> > > When you "came" back after your hiatus from the group, one person posted that
> > > they were happy to see you back.  I think that it was (and continues to be) a
> > > much more common hope/desire that you will "go away" again (and stay away
> > > forever).
> > >
> > Hardly the milk of Human kindness is it Bill? <G>
> >
> >
> > > This will help CLC - and possibly COBOL in a variety of platforms.
> >
> > So Robert Wagner is now elevated to the role of being important to
> > COBOL across platforms?!
> >
> > That would be enough to make anyone reach for "Teach Yourself Java"...
> > maybe Robert has done some good after all :-)
> >
> > OK, this has been fun and it has been real, but it hasn't been real
> > fun...<G>
> >
> > I'm sure this post will have no effect whatsoever on what happens in
> > CLC but then, I'd be sorry if it did... The best I can hope for is
> > that there will be some consideration on't.
> >
> > Pete.
0
dashwood1 (2140)
6/23/2004 8:29:04 AM
On 21-Jun-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:

> As to baiting mainframers, I plead guilty. They take the bait so gullibly.

You like this because it isn't much of a challenge?

Well, recognizing the problem is the first step to a cure.    
0
howard (6283)
6/23/2004 3:34:54 PM
On 21-Jun-2004, robert.deletethis@wagner.net (Robert Wagner) wrote:

> I always thought of EXIT as a 'filler' word, like CONTINUE, to be used where
> you had nothing to say. It did not necessarily exit.

I recommend using CONTINUE instead.    EXIT has some syntaxual requirements.

e.g.   the following won't compile with debug on:

 EXIT-PARAGRAPH.
D      DISPLAY 'REACHED EXIT-PARAGRAPH.
         EXIT.

While the following works quite nicely:


 EXIT-PARAGRAPH.
D      DISPLAY 'REACHED EXIT-PARAGRAPH.
         CONTINUE.
0
howard (6283)
6/23/2004 3:39:43 PM
On 22-Jun-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> In the 60's (or even in the 70's and first half of the 80's) - I wonder if
> those
> claiming to NEVER use a GO TO
>
>  A) never coded a SORT Input/Output procedure
>         or
>  B) only used compilers with an extension to the '68 & '74 Standards
>
> ***
>
> It was TOTALLY impossible (with a conforming to those Standards) compiler to
> code a "loop" in a SORT procedure without a GO TO.  This was because it was
> non-conforming to PERFORM (thru) a procedure OUTSIDE the Input/Output
> procedure.

I don't understand.   My experience during the 70's was with IBM, Univac (9030
and 1100), Burroughs, and Honeywell.  I don't remember for sure about
Honneywell, but am sure I wrote CoBOL SORT's without using GO TO's back then in
the other systems.

I have the following questions:
1.   Why was it non-conforming?
2.   Why do we need to perform (thru) OUTSIDE the Input/Output procedure?
3.   And why would it be impossible to have a perform within the Input/Output
procedure without a GO TO?

Maybe all of the systems I used didn't conform to the standards they purported
to use.
0
howard (6283)
6/23/2004 3:47:36 PM
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
news:cbahjl$a5r$1@news.eusc.inter.net...

> The above is one way to force a shop to keep correct source.  This must
> make system upgrades interesting.

Users get plenty of warning.  For example, for SSR 50.1 MCP, execution of
codefiles from SSR's 46.1 and 47.1 result in a warning on the ODT and in the
system log log that the codefile is approaching the end of its life.
Codefiles from SSR's 48.1 and 49.1 are accepted by SSR 50.1 MCP without
murmur.

Generally speaking, users simply recompile on a rotating basis; those who
wait for a system software upgrade to find out that their codefiles no
longer run, after ignoring two releases of warnings, are shooting themselves
in the foot.

Likewise, those users who don't keep track of their source files are
shooting themselves in the foot, regardless of the system policies.

> I think that IBM is of two minds on
> this.  The z series is still able to execute many programs that were
> compiled and linked 30 years ago and more (360 and descendants).

The Burroughs Medium System took this approach (with the proviso that few,
if any, programs were "linked" -- they generally came out of the compilers
in executable form).  Any codefile compiled anytime for any Medium System
would run forever, as far as I know.

I think the Large System folks learned from that experience, because the
approach prevented the Medium System architecture from making some
improvements that many users would have found highly desirable.  There was
no effective mechanism whereby the software could warn the user that
"<Functionality x> will no longer be supported on <date>" on that system,
and that presented some problems.

> I don't know what shops do if  they lose the source.

Wise managers ensure that their source files are not only preserved but
backed up in any case.

I've run into cases -- on a variety of systems -- where shops failed to do
this, and in several occasions they were in a world of hurt.

One of those, from about 22 years ago, involved a shop with an
even-then-ancient computer for which all object files were in punched cards,
the (assembler) source had been abandoned (probably ten years before) in
favor of the practice of object patching.  One day the operator went
berserk, threw all the object code decks into the air and then trampled on
them.  I don't think they even had the object code deck for the assembler
any more.  This was also a rather obscure and *very* obsolete machine for
which there was simply no longer anybody around who knew anything about it.

This was a utility company with about 26,000 accounts, and the company had
been perfectly content with their billing system (including the ancient
hardware!) because there was *no* possibility that their customer base would
ever expand significantly.

It was something like two years before they were fully operational on custom
billing software written in COBOL for a newer machine.

I *do* know what shops do if they lose the source.  Been there, seen that!
One way another, eventually they're in a world of hurt, whether or not the
system forces periodic recompiles!

    -Chuck Stevens


0
6/23/2004 3:56:12 PM
I know that IBM's OS/VS COBOL *did* have an extension.  I don't know about the
other compilers.

The problem was that an INPUT/OUTPUT procedure statement did an implicit GO TO
to the beginning of the procedure and there was another implicit GO TO at the
end of the procedure.  The ANSI rule was that you could NOT PERFORM or GO TO any
paragraph/section outside of the procedure.

Try and figure out how to do a "loop" within a procedure - where you execute ALL
the code without doing a GO TO.  It simply can't be done.   What you were
required to  do was one of two types of logic.

Option 1:

Sort ... Input/Output procedure . Proc-1 thru Proc-2

 * start here
    Proc-1.
       Release/return
             at end
                  Go to Proc-2
         .
        Do all your logic here.
 * without the next statement you won't loop
         Go to Proc-1
     Proc-2.
        Exit.

Option 2:
    Proc-1.
          Read/Return
               At end move "Y" to eof
                   .
       Perform Loop-Proc
            Until EOF = "Y"
        .
 * without the next statement you will "fall thru" to loop para.
       Go to Proc-2
    Loop-Proc.
        Do logic here
       Release/return
           at end
              Move "Y" to eof
           .
      Proc-2.
            Exit.


-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:cbc8mo$apr$1@peabody.colorado.edu...
>
> On 22-Jun-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
> > In the 60's (or even in the 70's and first half of the 80's) - I wonder if
> > those
> > claiming to NEVER use a GO TO
> >
> >  A) never coded a SORT Input/Output procedure
> >         or
> >  B) only used compilers with an extension to the '68 & '74 Standards
> >
> > ***
> >
> > It was TOTALLY impossible (with a conforming to those Standards) compiler to
> > code a "loop" in a SORT procedure without a GO TO.  This was because it was
> > non-conforming to PERFORM (thru) a procedure OUTSIDE the Input/Output
> > procedure.
>
> I don't understand.   My experience during the 70's was with IBM, Univac (9030
> and 1100), Burroughs, and Honeywell.  I don't remember for sure about
> Honneywell, but am sure I wrote CoBOL SORT's without using GO TO's back then
in
> the other systems.
>
> I have the following questions:
> 1.   Why was it non-conforming?
> 2.   Why do we need to perform (thru) OUTSIDE the Input/Output procedure?
> 3.   And why would it be impossible to have a perform within the Input/Output
> procedure without a GO TO?
>
> Maybe all of the systems I used didn't conform to the standards they purported
> to use.


0
wmklein (2605)
6/23/2004 5:11:46 PM
Option 3??

           Sort ... Input/Output procedure . Loop-Proc thru Proc-2

	Loop-Proc.
                  If    first-time = "Y"
                        next sentence
                  else
		do logic here
                  	release/return
                             at end move "Y" to eof.
                  move "N"   to first-time-switch.
             proc-2.
                  perform loop-proc until eof = "Y".
   
0
howard (6283)
6/23/2004 5:51:07 PM
You do see that your "do logic here" is done once BEFORE you have actually
Return/Released a record (2nd time in Loop-Proc)?  You could add yet another
switch for "2nd time" - but that gets a bit complex (and I am not positive where
the logic would need to go).   The current logic would do the "logic" even if
the file were empty.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:cbcfua$rqd$1@peabody.colorado.edu...
> Option 3??
>
>            Sort ... Input/Output procedure . Loop-Proc thru Proc-2
>
> Loop-Proc.
>                   If    first-time = "Y"
>                         next sentence
>                   else
> do logic here
>                   release/return
>                              at end move "Y" to eof.
>                   move "N"   to first-time-switch.
>              proc-2.
>                   perform loop-proc until eof = "Y".
>


0
wmklein (2605)
6/23/2004 6:58:52 PM
riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> Wrong. I stopped using GO TO in the '60s.
>
>Until the universal availability of scope terminators there were
>several ways that flow could be controlled around the problem areas
>where a single full stop would terminate all scopes.  Some of these
>led to complexity problems of having too many small paragraphs, others
>led to repitition of condition tests.
>
>It is a matter of balancing 'purity' against complexity and
>reliability.  You may well have a level of purity that approached
>sainthood (in your own church at least), but for others a more
>pragmatic resolution was required.

I didn't repeat conditions (nor use many indicators), have an
excessive number of small paragraphs nor find it particularly
challenging. I think it's all in structure, how one packages logic
into paragraphs. That's what spaghetti coders don't know how to do.

>> True, but Cobol is plagued with large programs more than other
languages. It
>> seems a feature of 'Cobol culture' as practiced in big shops.
>
>I suspect that you have a rather limited experience.  Large Fortran
>programs used also to be found.  But this is a matter of 'selection of
>the fittest'.  If large programs were a 'plague' then this would have
>been resolved by the programming shops themselves.  If they didn't
>work or were too expensive in some way, the business case would have
>removed them.

I see little new development in Cobol, only maintenance. When systems are
replaced, new code is in another language. Businesses _are_ removing
Cobol slowly, by attrition.

>> >What particular OO features do you think that batch programs need ?
>>
>> Reusability.
>
>But 'reusability' is not a unique feature of OO design.  That is, it
>is not necessary to have object orientation to have code reusability.

The alternatives are called programs and copy-and-paste. Big shops don't
like called programs because they think a change requires retesting all
callers. They use lots of copy-and-paste, which creates multiple copies of
the same code. When that code needs maintenance, they do it in the program
that 'needs' the change. They wind up with multiple versions of the same
code slightly out of synch with each other. Years later, when someone
unfamilar with the history needs to do maintenance, he has a knot to
unravel.

>> Packaging logic close to the data it operates on.
>
>That is a convenience for the source editing, perhaps better editing
>tools will help you there.
>
>> Packaging ALL logic that operates on a particular datum in one place.
>
>Why is that actually an advantage ?

It goes to Yourdon & Constantine's ideas about Cohesion. The goal of
Structured Design is Functional cohesion. Most batch programs are
organized for Temporal cohesion. The first line performs
Initialization, which opens all files. The very last physical line is
Stop Run. Why? Because that's how we used to design batch jobstreams --
temporal.

When we do maintenance, we're not interested in timeline, we're interested
in a few particular variables. Under what conditions is this thing changed?
Finding hits in numerous programs makes the process unreliable. It's worse
when the variable is called by different names, for example one name in
working-storage and a different name in the database. Or when some code
that changes it is hidden in a stored procedure.

Packaging all logic in one place would make maintenance more reliable.

As with OO Programming, Structured Programming means using Structured
Technology to impliment a Structured Design. Most Cobol programmers
think eliminating GO TO and using EVALUATE, while keeping old-fashioned
design, is good enough to claim they do Structured Programming. They're
packaging old wine in new bottles.

>You seem to want, for example, a simple print report program to carry
>all the baggage of the logic that would be used to update the file.
>Instead of the programmer being able to focus on the _procedure_ being
>performed, you want them to deal with all the other complexities.

My report programs concern themselves with the structure of the report.
They are usually passed the data as an input structure. If not, they obtain
it with a database read or program calls.

>> Ability to define structures more complex than a record or array.
>
>Really ?  Do they _need_ this ?  Why ?
>
>> Ability to perform operations on those structures more complex than
>> Copy, facilitating abstraction in design.
>
>Really ? Do they _require_ this ?  Why.  Give examples.

For example, the aforementioned document processor wants to perform
operations at the document level without tediously operating on lines
and words.

A manufacturing program wants to recost or delete finished goods
without traversing the bill of materials tree.

>All that you have done is listed a few features from an OO primer and
>stated these are _required_.

I'm citing real problems from my experience.

>Garbage _may_ be paged out of real memory, except where it resides in
>the same pages or segments that non-garbage resides in.  These objects
>are created on the heap and drop out of scope in random ways.  Some
>remain and some are now garbage.  Because of the granuality of the
>address space being larger than a typical object the garbage may
>reside in real memory.  Garbage collection will allow that space to be
>reused.

I didn't tell them to use fixed-length pages. My operating system
used object-sized pages. When I argued for that last year, I was
the village idiot. As a result, I don't want to discuss virtual memory.

>> For instance, I wrote a 'program' (a series of modular
>> programs) that parses freeform text documents, a very common data
>> warehousing problem.
>
>You are attempting to use one extreme example to justify a general
>case.  I very much doubt that '500Mbyte' is 'very common'.

Are you kidding? In data warehousing, tables with 500 million ROWS are
common. The two databases I was feeding, one Oracle and the other Sybase, each
had 75 billion rows.

0
6/23/2004 11:51:53 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 

>They do truck racing here.  It may be fun to see that these can
>actually get around the track one would not want those drivers doing
>the frieght runs, nor would one ever think that those vehicles are the
>best for the job of taking one man around the track the fastest way.
>
>One certainly can contemplate a 'technology transfer', but only where
>there is an actual benefit, not because someone tries to be an
>elitist.

In another life I drove modified Chevrolet Corvairs, a rather lame economy car
with poor weight distribution and overheating problems, in Sports Car Category 3
(something like that), which also included Porshes. It was a kick using a $2K
everyman car to beat $20K elitist cars. (Prices in the mid '60s)

Opportunities for technology transfer abounded -- better suspension, more power,
better cooling, safety cage -- but did not find their way into everyday use. 

It has been suggested that racing cars be required to comply with US pollution
'emission standards'. The idea, of course, is to foster technology transfer.
Good idea but I doubt it would work.

Technology transfer seems to work when the technology is revolutionary, brand
new. It doesn't work when it's evolutionary. In the minds of most people, Cobol
is an evolving legacy language, therefore not amenable to transfer. OO Cobol had
the potential to be revolutionary, but it appeared too late. C++ had captured
the market ten years sooner. We were seen as playing 'me too'.
0
6/23/2004 11:51:53 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote

>The EXIT statement was there to cater for the very early compiler code
>to act as a 'place holder' for the PERFORM return code.  Wherever the
>end of a PERFORM was required an EXIT has to be coded in its own
>paragraph.  This was used by some compilers to generate null code that
>was replaced by return code by the PERFORM statement.  The PERFORM
>would then tidy up by making it null again so it would drop thru if
>necessary.
>
>While not all compilers required this, it certainly was the case with
>some compilers that I worked with that pre-dated the '68 standard,
>such as ICT's XE13.

I can't recall a mandatory EXIT, even on the earliest IBM compilers.

>Your assertion that it was for 'commented out paragraphs' is nonsense
>because there was no mechanism to 'comment out code' that left a
>paragraph without a statement until the '74 standard.
>
>The '74 standard introduced the '*' in column 7.  Previously it would
>be done by the NOTE statement which did not leave the paragraph empty
>at all.

I recall that on the IBM 7090/7040 compiler, circa. 1960. Also 1401 from the
same era.  By 1965, on the S/360, I'm reasonably sure it offered * in column 7
as an alternative to NOTE. Does anyone remember?

>> Now you've stepped in cow dung. NOTE was deleted from the Standard for good
>> reason -- it was a bugtrap.
>
>It was deleted when the '*' was added to replace it.  When the EXIT
>was 'constructed' the only standard 'comment out' was NOTE, which did
>not leave the paragraph 'empty' and thus did not require an 'EXIT' as
>you claim.

Funny story about NOTE. In the late '60s I worked for a programming manager who
was a real jerk. During meetings to formulate a Programming Standard, I
suggested "Every paragraph must start with a NOTE explaining what it does." He
bought the idea and published it in the Standard. Programmers were giggling and
giving me high-fives. 

His tenure was short-lived. I replaced him a month later. His "V. 'Duke' Smith
Programming Standards Manual" occupied an honored space in our library.

0
6/23/2004 11:51:54 PM
In article <cbaovv$33d$1@panix5.panix.com>, docdwarf@panix.com wrote:

> [snip]
> 
> >When a programmer expects me to trust his ability to code, he should 
> >show proficiency using the most well-known, least error-prone constructs.
> 
> ... and code should be easy-to-understand... which means using the 
> constructs and style which the proponent is proposing, no?

Actually, I mean that it is something so blindingly obvious that a 
programmer should not have to be told.  

It has been three decades since the industry at large adopted structured 
code.  Programmers should not peddle out of date talent.  It is getting 
close to the point where they OO ought to be 'required skills' as well.


> '... requires effort NOT to abuse it'... you mean one must be disciplined?  
> Zounds, take that out of the hiring-exam... can't have any disciplined 
> coders in *this* shop!

A funnly little thing from a few years ago a rather humorous, but 
disjointed, design committee of technical managers (some coding, some 
non-coding, most previously coded) yielded the following in a largish 
manual:

   All performs should be PERFORM 1234-X thru 1234-EXIT

   All paragraphs should have an EXIT paragraph with the same number

   PERFORM THRU should not be used

   Nested subprograms can cause confusion and will not be used.

   Nested subprograms help promote structure and organization and should 
be used where possible.

   All programs will exit with STOP RUN

   IMS programs must not use STOP RUN

   CICS programs must not use STOP RUN

   All subprograms will exit with GOBACK.

   Routine names should be meaningful.  E.G. READ-MASTER-FILE, 
READ-TRANSACTION-FILE, READ-EXTRACT-FILE

   Paragraph names should start with a number, followed by a  
description.  E.G. 1000-READ-FILE, 2000-READ-FILE, 3000-READ-FILE

   GO TO is prohibited.

   GO TO should be used carfully

   GO TO will be used to go the the EXIT paragraph

   GO TO should be limited to a fatal error exit


(they were not in that order, and I mined the entire book for these fun 
contradictions -- there are others, but off the top of my head, these 
are enough)

Even with self discipline, sometimes one will encounter a programmer 
that is going to use GO TO.  Perhaps even entire departments or 
applications will be filled with it.  Not much to be done except hope 
that it goes away someday...

I've reduced myself to babbleing, so I'll shut up now.
0
6/24/2004 3:44:22 AM
In article <cbahjl$a5r$1@news.eusc.inter.net>,
 "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:

> The above is one way to force a shop to keep correct source.  This must 
> make system upgrades interesting.  I think that IBM is of two minds on 
> this.  The z series is still able to execute many programs that were 
> compiled and linked 30 years ago and more (360 and descendants).  I 
> understand the i series (S38 and AS400 and descendants) requires mass 
> recompiles as a part of system upgrades.  I don't know what shops do if 
> they lose the source.
> 
> >     -Chuck Stevens

One great way with the IBM line of compilers is to use the TEST and/or 
ADATA options (DOC).  It can include the source as part of the load 
module, and that can later be recoverdd using a utility like IDILANGP, 
or just reading the module for ADATA source lines.

I've heard lots of complaints about the size of source, but it isn't 
executable, and disk is so cheap when considering load module sizes that 
doubling them isn't really that big a deal.

Does the Unisys compiler support embedding the source in the executable?  
MicroFocus?  Any others?

I just think this is a neat option...
0
6/24/2004 3:49:31 AM
One of the features I'd like to see along those lines
relates to the, now obsolete. "label records are standard".
That item became that way in part, I think, because there
was no label system on all systems that could be
standardized.

With 2020 hindsight, I would have liked to see the development
fix this by requiring the FD and SD file descriptions for
both Input and output to be recorded in plain text on all
files.

The subsequent changes would then be made to the label records,
and the programs recompiled reflecting both the changes, and
the differences at each stage of maintenance.

Reading Open Source Code shows me that they do a good job
of tracking changes, but I"m not sure it would be as useful
as what I currently believe COBOL should have.

Warren Simmons



Joe Zitzelberger wrote:
> In article <cbahjl$a5r$1@news.eusc.inter.net>,
>  "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
> 
> 
>>The above is one way to force a shop to keep correct source.  This must 
>>make system upgrades interesting.  I think that IBM is of two minds on 
>>this.  The z series is still able to execute many programs that were 
>>compiled and linked 30 years ago and more (360 and descendants).  I 
>>understand the i series (S38 and AS400 and descendants) requires mass 
>>recompiles as a part of system upgrades.  I don't know what shops do if 
>>they lose the source.
>>
>>
>>>    -Chuck Stevens
> 
> 
> One great way with the IBM line of compilers is to use the TEST and/or 
> ADATA options (DOC).  It can include the source as part of the load 
> module, and that can later be recoverdd using a utility like IDILANGP, 
> or just reading the module for ADATA source lines.
> 
> I've heard lots of complaints about the size of source, but it isn't 
> executable, and disk is so cheap when considering load module sizes that 
> doubling them isn't really that big a deal.
> 
> Does the Unisys compiler support embedding the source in the executable?  
> MicroFocus?  Any others?
> 
> I just think this is a neat option...
0
wsimmons5 (172)
6/24/2004 4:39:22 AM
robert.deletethis@wagner.net (Robert Wagner) wrote 

> >> >What particular OO features do you think that batch programs need ?
> >
> >But 'reusability' is not a unique feature of OO design.  That is, it
> >is not necessary to have object orientation to have code reusability.
> 
> The alternatives are called programs and copy-and-paste. 

Actually one could also use COPYbooks.

> Big shops don't
> like called programs because they think a change requires retesting all
> callers. 

So, how do you think OO overcomes this objection ?  Why would these
shops suddenly say: "we won't have to retest all invokers" ?

> They use lots of copy-and-paste, which creates multiple copies of
> the same code. When that code needs maintenance, they do it in the program
> that 'needs' the change. They wind up with multiple versions of the same
> code slightly out of synch with each other. Years later, when someone
> unfamilar with the history needs to do maintenance, he has a knot to
> unravel.

They'll probably copy and paste to create a new class.

Or perhaps they'll wind up with infinite inheritance.  This is where a
base class is never touched and every variation is done through
inheriting the previous iteration and adding a few changes via
overriding.

OO is not a magic bullet that will fix poor practices.
 
> I didn't tell them to use fixed-length pages. My operating system
> used object-sized pages. When I argued for that last year, I was
> the village idiot. 
> As a result, I don't want to discuss virtual memory.

So, you agree that your comments about garbage in the real world was
nonsense.

Using small variable page size for demand paging is simply a
non-starter, this leads either to huge internal fragmentation or large
overhead to avoid this fragmentation, _or_ requires 'garbage
collection' which is what you claimed wasn't necessary.

You did mention that your 'OS' was a failure, didn't you ?
 
> >You are attempting to use one extreme example to justify a general
> >case.  I very much doubt that '500Mbyte' is 'very common'.
> 
> Are you kidding? In data warehousing, tables with 500 million ROWS are
> common. The two databases I was feeding, one Oracle and the other Sybase, each
> had 75 billion rows.

I doubt that '500Mbyte' as an in-memory list is 'very common'.  Your
examples of large _databases_ hardly applies.

Perhaps you may like to consider what the word 'common' means.
0
riplin (4127)
6/24/2004 7:09:17 AM
In article <joe_zitzelberger-BFE83F.23442223062004@corp.supernews.com>,
Joe Zitzelberger  <joe_zitzelberger@nospam.com> wrote:
>In article <cbaovv$33d$1@panix5.panix.com>, docdwarf@panix.com wrote:
>
>> [snip]
>> 
>> >When a programmer expects me to trust his ability to code, he should 
>> >show proficiency using the most well-known, least error-prone constructs.
>> 
>> ... and code should be easy-to-understand... which means using the 
>> constructs and style which the proponent is proposing, no?
>
>Actually, I mean that it is something so blindingly obvious that a 
>programmer should not have to be told.  

It is my experience, Mr Zitzelberger, that 'obvious' is in the mind of the 
beholder.

>
>It has been three decades since the industry at large adopted structured 
>code.  Programmers should not peddle out of date talent.  It is getting 
>close to the point where they OO ought to be 'required skills' as well.

The world, Mr Zitzelber, is not a place where 'should' and 'ought to' 
equal 'is'; people - and that just might include programmers - try to sell 
what they think others will want to buy and people - and that includes 
hiring managers - buy what they think they might need or enjoy.

>
>
>> '... requires effort NOT to abuse it'... you mean one must be disciplined?  
>> Zounds, take that out of the hiring-exam... can't have any disciplined 
>> coders in *this* shop!
>
>A funnly little thing from a few years ago a rather humorous, but 
>disjointed, design committee of technical managers (some coding, some 
>non-coding, most previously coded) yielded the following in a largish 
>manual:
>
>   All performs should be PERFORM 1234-X thru 1234-EXIT
>
>   All paragraphs should have an EXIT paragraph with the same number
>
>   PERFORM THRU should not be used

'Too many cooks spoil the broth.'

'Many hands make light work.'

>
>   Nested subprograms can cause confusion and will not be used.
>
>   Nested subprograms help promote structure and organization and should 
>be used where possible.

'Look before you leap.'

'He who hesitates is lost.'


.... seems like they were following some rather... ancient human 
traditions, eh?

[snip]

>(they were not in that order, and I mined the entire book for these fun 
>contradictions -- there are others, but off the top of my head, these 
>are enough)
>
>Even with self discipline, sometimes one will encounter a programmer 
>that is going to use GO TO.  Perhaps even entire departments or 
>applications will be filled with it.  Not much to be done except hope 
>that it goes away someday...

Should, ought to, hope... these seem to be words which are used to 
describe approaches to the World Around One rather than what that World 
'is'... but perhaps I tread on the border of Philosophy.

>
>I've reduced myself to babbleing, so I'll shut up now.

Of course, quite right, very reasonable... now, as you were saying...?

DD

0
docdwarf (6044)
6/24/2004 9:28:48 AM
In answer to the original question.

Given the specific environment (Micro Focus), one of my "usually reliable
sources" informed me that there is a CBL_ routine to provide exactly the desired
informing.  Use the Micro Focus:

    CBL_GET_PROGRAM_INFO

callalbe routine.  I had trouble finding the documentation on this, but I
*think* it may be in your "online" help.  If not, you might want to ask for the
available parameters in the MF forum.

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


0
wmklein (2605)
6/24/2004 12:47:44 PM
On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:

> So, how do you think OO overcomes this objection ?  Why would these
> shops suddenly say: "we won't have to retest all invokers" ?

A "feature" of OO is that once a shop moves to OO, it is impossible to do the
same rigorous testing that were the earlier standards, so the standards get
changed.
0
howard (6283)
6/24/2004 2:14:32 PM
Howard Brazee wrote:
> On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:
> 
> 
>>So, how do you think OO overcomes this objection ?  Why would these
>>shops suddenly say: "we won't have to retest all invokers" ?
> 
> 
> A "feature" of OO is that once a shop moves to OO, it is impossible to do the
> same rigorous testing that were the earlier standards, so the standards get
> changed.

Why is that?

Donald

0
donald_tees (563)
6/24/2004 5:56:13 PM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40d9f6b8.196351819@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
> >robert.deletethis@wagner.net (Robert Wagner) wrote
[snip]
> >> >What particular OO features do you think that batch programs need ?
[snip]
> >> Packaging ALL logic that operates on a particular datum in one place.
> >
> >Why is that actually an advantage ?
>
> It goes to Yourdon & Constantine's ideas about Cohesion. The goal of
> Structured Design is Functional cohesion. Most batch programs are
> organized for Temporal cohesion. The first line performs
> Initialization, which opens all files. The very last physical line is
> Stop Run. Why? Because that's how we used to design batch jobstreams --
> temporal.

Mr Wagner, structured design, as I understand it, is functional
decomposition and temporal cohesion. It seems to me that
object oriented design is closer to the idea of functional cohesion,
which may also be obtained in some measure with modular
programming.

Steve McConnell, "Code Complete," Microsoft Press, 1993,
page 159, "When to Use Structured Design," writes "Structured
design is mainly a way of breaking a program into routines. It
emphasizes functionality and doesn't stress data. An example
of a functionally oriented problem domain would be a system
that reads data in batch mode, performs predictable processes
on that data in a predictable order, and writes the data."

Here, McConnell seems to be suggesting that the use of structured
design for batch programs is adequate; much as Stroustrup stated.

McConnell goes on to write (referring to Constantine's article,
"Objects, Functions, and Program Extensibility") "If data is likely
to change, the object-oriented approach is appropriate because
it isolates the data likely to change into individual objects (modules).
If functionality is likely to change, the object-oriented approach is not
so appropriate because functionality is spread thoughout many
objects (modules). If the functionality is more likely to change than
the data, you are better off using the functional decomposition of
structured design." [Here 'functionality' seems to refer to the
functionality of a proposed system.]

> When we do maintenance, we're not interested in timeline, we're interested
> in a few particular variables. Under what conditions is this thing
changed?
> Finding hits in numerous programs makes the process unreliable. It's worse
> when the variable is called by different names, for example one name in
> working-storage and a different name in the database. Or when some code
> that changes it is hidden in a stored procedure.
>
> Packaging all logic in one place would make maintenance more reliable.

Or perhaps, Mr Wagner, a bit easier; there sometimes being tools
to help identify all such affected source programs.

Given a fixed asset application with the abstract superclass
DepreciationMethod and subclasses StraightLine and
DoubleDecliningBalance; also, an inventory application with the
abstract superclass ReorderMethod and subclasses EOQ and
OrderToLevel, it is fairly easy to add classes for additional
depeciation methods and reorder methods. But, Mr Wagner
is it really so much more difficult to accomplish this using
structured design as to *need* object oriented design for the
simple, common abstractions found in so many business
applications, ?

Mr Wagner, there is a balance that seems to be related to
complexity and size; as both increase, so does the *advantage*
of object oriented design. Object oriented design has an
additional burden to overcome when batch processing is
involved.



0
ricksmith (875)
6/24/2004 10:45:19 PM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote 

>> Big shops don't
>> like called programs because they think a change requires retesting all
>> callers. 
>
>So, how do you think OO overcomes this objection ?  Why would these
>shops suddenly say: "we won't have to retest all invokers" ?

They would change their culture. They would become practical by testing the
Class rather than all invokers.

>They'll probably copy and paste to create a new class.
>
>Or perhaps they'll wind up with infinite inheritance.  This is where a
>base class is never touched and every variation is done through
>inheriting the previous iteration and adding a few changes via
>overriding.

That's what the worst of them would do.

>OO is not a magic bullet that will fix poor practices.

Why do we have poor practices? I contend it's a generational issue. People are
promoted to management on the strength of obsolete technical skills. Today I
heard a manager jokingly disparage herself by saying "we'd be in big trouble if
I used my RPG skills." That's a good characterization of what's happening.
Policy-makers make us follow Cobol Programming Standards or informal programming
practices designed to solve problems and abuses of the '70s, which no longer
exist.

Practitioners don't object because they want predictability in their lives. They
have it. Cobol is predictably being brushed aside.

>Using small variable page size for demand paging is simply a
>non-starter, this leads either to huge internal fragmentation or large
>overhead to avoid this fragmentation, _or_ requires 'garbage
>collection' which is what you claimed wasn't necessary.

Your computer spends 99% of its time waiting for a keystroke. 

>You did mention that your 'OS' was a failure, didn't you ?

Not for technical reasons.

0
6/24/2004 11:43:22 PM
"Howard Brazee" <howard@brazee.net> wrote in message news:<cbenk8$nt2$1@peabody.colorado.edu>...
> On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:
> 
> > So, how do you think OO overcomes this objection ?  Why would these
> > shops suddenly say: "we won't have to retest all invokers" ?
> 
> A "feature" of OO is that once a shop moves to OO, it is impossible to do the
> same rigorous testing that were the earlier standards, so the standards get
> changed.

I don't think so, Howard.

Control of your environment is an administrative function. If you
insist that "rigourous testing as prescribed by our existing
standards" will be done, then it will be. It certainly isn't made
"impossible" by adopting OO, although it may be made "unnecessary".

I don't want to argue the case for OO here any more (I'm heartily sick
of doing so) but I will say that if you extend your OO Classes into
encapsulated components (as I have been doing for some years now) you
CAN obviate a large amount of what was previous regression testing.

Because components have specific Methods that define their
functionality, you can change the functionality of a system by adding
new components to it. (In the same way that you might add an extra
wall to your house by buying more bricks). Why would you then go and
retest all the functions that haven't changed?  Would you stress test
all the previously existing bricks in your wall?

Well, you might, but the answer is it depends on how confident you are
about the wall and the bricks. You certainly don't HAVE to do it.

It isn't about testing every "invoker" just as you would every
"caller". There are subtle, but important, differences between what is
called and what is invoked, but most COBOLLers just lump them together
because that is what they understand. "Hey, Ive been using CALL for
years, INVOKE has exactly the same syntax, what's the big deal? They
must do the same, right?" Wrong.

(Just as a hint, and I have no intention of expanding this because it
is pointless to do so in this forum, consider what differences it
might make (to your system and program design) if you were able to
change the internal data of a called module, dynamically, immediately
before you called it, WITHOUT changing the interface to it. Change the
internal settings so its behaviour changed, set internal flags, give
it different initial values?  But don't need to recompile everything
that calls it, because the interface to it is exactly the same and the
functionality is exactly the same.  Code that invoked it without
changing its properties will work exactly as it always has; new code
will cause it to behave differently. It still takes the same
parameters through the USING clause, but its behaviour is different
when it is called by some callers, from when it is called by others...
Only new code that needed to change some of the behaviours in it would
need to be tested.

Would it make generalized and flexible software easier to write? Could
you have fewer, more "general-purpose" modules? Do you find this idea
exciting or do you find it frightening? Invoked objects CAN do that;
called modules can't.)

You CAN create "system building blocks" that do more than called COBOL
modules ever could, you CAN deploy these blocks into responsive,
easily maintained, reusable, application functionality, and if you do,
you DON'T need to do all the rigourous regression testing that is
standard practice for most installations.

But there is nothing to stop you from continuing to do it if that
makes you feel better.

Pete.
0
dashwood1 (2140)
6/25/2004 6:36:50 AM
Rick Smith <ricksmith@mfi.net> wrote in message
news:10dmma0mgsho6f9@corp.supernews.com...
>
> Robert Wagner <robert.deletethis@wagner.net> wrote in message
> news:40d9f6b8.196351819@news.optonline.net...
[snip]
> > It goes to Yourdon & Constantine's ideas about Cohesion. The goal of
> > Structured Design is Functional cohesion. Most batch programs are
> > organized for Temporal cohesion. The first line performs
> > Initialization, which opens all files. The very last physical line is
> > Stop Run. Why? Because that's how we used to design batch jobstreams --
> > temporal.
>
> Mr Wagner, structured design, as I understand it, is functional
> decomposition and temporal cohesion. It seems to me that
> object oriented design is closer to the idea of functional cohesion,
> which may also be obtained in some measure with modular
> programming.

Let me apologize for what must seem a confused response. At
some point after posting, I realized that I had never before seen
the term 'functional cohesion' used with structured design; and
I was right. The term I saw was 'functional binding' in an article
written by Stevens, Myers, and Constantine, titled "Structured
design". The article states "Binding is the measure of cohesiveness
of a module." and "Functional Cohesiveness" is the highest of six
classifications. By implication, the goal of structured design is
functional decomposition into modules to achieve the highest
classification of cohesiveness. My use of 'temporal cohesion'
came from another source and is related to batch files.

The article also states "In a functionally bound module, all of the
elements are related to the performance of a single function."
Expanding this *idea* to the program level suggests that the *goal*,
functional cohesiveness, can only be achieved at the program
level if there is only one program operating on private data. This
seems to exclude batch processing where some of the
elements (data) are related to the performance of different functions.
Thus I still see no *need* nor any *advantage*.

However, Robert C. Martin, "Designing Object-Oriented C++
Applications Using the Booch Method," Prentice-Hall, 1995,
does describe a batch payroll system, which, as nearly I can
determine, is one program and treats its database as private data.



0
ricksmith (875)
6/25/2004 6:48:44 AM
In article <cbenk8$nt2$1@peabody.colorado.edu>,
 "Howard Brazee" <howard@brazee.net> wrote:

> On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:
> 
> > So, how do you think OO overcomes this objection ?  Why would these
> > shops suddenly say: "we won't have to retest all invokers" ?
> 
> A "feature" of OO is that once a shop moves to OO, it is impossible to do the
> same rigorous testing that were the earlier standards, so the standards get
> changed.

Not impossible, unnecessary...
0
6/25/2004 11:41:28 AM
On 24-Jun-2004, Donald Tees <donald_tees@sympatico.ca> wrote:

> > A "feature" of OO is that once a shop moves to OO, it is impossible to do
> > the
> > same rigorous testing that were the earlier standards, so the standards get
> > changed.
>
> Why is that?

It is only that if OO is used the way its proponents say it should be used -
with reusability.    With non-reusability, it is possible to test every possible
option that uses some changed code.   But if an object or component is used by
the whole world, we can't test it with the whole world.

Moving slightly away from OO:

A shop that has very tight standards for its CoBOL programs is unlikely to have
a kiosk to test out its public web pages with a dozen browsers with different
operating systems and modems.    If the web page doesn't work, they demand that
someone "upgrade" their compliant Opera browser working on Linux to something
less compliant and far more dangerous such as IE on Windows.    Because testing
is expensive.
0
howard (6283)
6/25/2004 3:05:01 PM
Howard Brazee wrote:
> On 24-Jun-2004, Donald Tees <donald_tees@sympatico.ca> wrote:
> 
> 
>>>A "feature" of OO is that once a shop moves to OO, it is impossible to do
>>>the
>>>same rigorous testing that were the earlier standards, so the standards get
>>>changed.
>>
>>Why is that?
> 
> 
> It is only that if OO is used the way its proponents say it should be used -
> with reusability.    With non-reusability, it is possible to test every possible
> option that uses some changed code.   But if an object or component is used by
> the whole world, we can't test it with the whole world.
> 

That is slightly dumb, if I might be so bold. Simply do not try to 
re-use it with the entire world.  Stick to your own system, and test it 
with your own system.

> Moving slightly away from OO:
> 
> A shop that has very tight standards for its CoBOL programs is unlikely to have
> a kiosk to test out its public web pages with a dozen browsers with different
> operating systems and modems.    If the web page doesn't work, they demand that
> someone "upgrade" their compliant Opera browser working on Linux to something
> less compliant and far more dangerous such as IE on Windows.    Because testing
> is expensive.

Sounds to me like you are talking about display technology, not OOP.

Donald

0
donald_tees (563)
6/25/2004 4:30:17 PM
Joe Zitzelberger wrote:
> In article <cbenk8$nt2$1@peabody.colorado.edu>,
>  "Howard Brazee" <howard@brazee.net> wrote:
> 
> 
>>On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:
>>
>>
>>>So, how do you think OO overcomes this objection ?  Why would these
>>>shops suddenly say: "we won't have to retest all invokers" ?
>>
>>A "feature" of OO is that once a shop moves to OO, it is impossible to do the
>>same rigorous testing that were the earlier standards, so the standards get
>>changed.
> 
> 
> Not impossible, unnecessary...

Given that testing in all too many shops is less than adequate now, I am 
skeptical that testing will become unnecessary when things are 
structured by OO.  I suspect that the problem that fouled up my account 
at the Royal Bank of Canada for a week was due to a misunderstanding of 
the scope of the effect of a change that ran for the first time on 
Monday, May 31.  This made national news and you can see their 
statements at www.royalbank.ca.  Note, I suspect this particular change 
was to a batch non-OO program.  The concern I have is program one in a 
processing stream works as expected but program twenty gives unexpected 
results because it didn't provide for the change in data caused by 
program one.  If an object is changed for performance reasons and all 
inputs and outputs are kept the same (exactly), then testing can be 
confined to the object.  If it is changed to accept new inputs leading 
to new outputs or to provide changed outputs, then testing should be 
done to test the effects of the change on most if not all invokers. 
Indeed a running of the entire processing cycle in which the changes 
occur may be necessary.  An input that on day one causes a rejection or 
error flagging can cause interesting problems when it becomes legal on 
day two.  User changes to control tables used in packages can have 
similar effects so the problem is not unique to traditional or OO code. 
  There is a reason that many server environments be they IBM mainframe, 
other mainframe, Unix, Windows, etc. phase in operating system and 
middleware changes through systems test, test, and systems assurance 
before putting them in production.  As the number of interactions 
increase the probability of having an unexpected side effect of a change 
increases.

This does not say that OO or CALL prototypes have no effect on 
reliability.  The enforcement of expectations being met is of great 
value in catching sometimes hidden errors.  The provision of 
repositories along with better documentation can cut down on the errors 
in the first place.  Indeed, moving control and modification of the 
system to end users may pose a greater threat than doing less testing of 
invokable OO modules.

It is interesting that the last three shops I have been in used the 
DYNAMIC bind option in batch which meant that subroutines were bound at 
run time.  In CICS subroutines are either bound to the caller when 
called by literal or at run time when called by data-name.  CICS has a 
large amount of interaction between separately compiled modules 
involving data areas and transient data that have varying degrees of 
complexity.  In many cases the testing may not be adequate because of 
people not understanding the variety of control flows.

I am grateful that the Royal Bank had controls in place that told them 
something went wrong.  As environments become more fluid, provision of 
appropriate controls and checks becomes more vital.  The use of OO can 
be helpful but we have to understand the full scope of a change. 
Managing change and verification of reliability has not been given 
proper respect in many shops.  Indeed one of the largest areas of 
vulnerability is user control tables.  There many times is very little 
consistency checking of the values entered and the tools available to 
those responsible for the tables are meager at best.  Documentation may 
be less than perfect.  OO can provide benefits that more than offset the 
execution cycle overhead just as Windows XP provides significant 
benefits over Windows 98 in terms of reliability at the cost of more 
cycles being spent verifying the validity of system requests.  Note you 
can use z/OS versus MVS/XA etc. as the comparison because what we have 
seen is reliability and security slowly added to our environments at the 
cost of validity checking at the boundaries.


0
cfmtech (125)
6/25/2004 4:49:39 PM
Warren Simmons wrote:

> Somewhere below some light was seen. Forgive my rambling.
> Who knew how to do anything then.
> The Univac I had an instruction pair called
> R  U. Now called Perform.
> The IBM 705 had an instruction pair something
> like Store B address and Return. Most of the other
> hardware discussed here these days had not yet been
> designed, and We Went With What We Had and What We
> though Was Good. So help me.
>> rest snipped
The 705 mod III had Receive Serial (set the location for the move or 
store) followed by a Transfer Store Location.  The perform thus would 
store the next instruction location in the instruction address of the 
implied or explicit EXIT instruction and the EXIT instruction would 
store the next Instruction address in the EXIT Transfer Store Location 
making a branch to next instruction.  The store next instruction 
location and branch of the RCA 301 worked the same way (V1 
store-address,branch address).  Unfortunately, the IBM 360 did not have 
a comparable instruction or capability.


0
cfmtech (125)
6/25/2004 5:15:52 PM
On 25-Jun-2004, "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:

> >>A "feature" of OO is that once a shop moves to OO, it is impossible to do
> >>the
> >>same rigorous testing that were the earlier standards, so the standards get
> >>changed.
> >
> >
> > Not impossible, unnecessary...
>
> Given that testing in all too many shops is less than adequate now, I am
> skeptical that testing will become unnecessary when things are
> structured by OO.

The more code is turned into a component, the less testing is needed - provided
it stays as a component.   I haven't found many bugs in CoBOL compilers, for
instance.     But testing still is necessary, and we have seen bugs make it to
production even in highly tested OO code such as Windows.   I have found more
bugs in published routines in library type languages.   In-house objects are
more likely to have bugs in them yet.

OO's advantages allow us to use it in bigger and more complex systems, which
really can't be created in time any other way.   And couldn't be tested to the
old standards.    Sure, when done right, there will be fewer errors - but
typically they are in much more complex systems, so the trick is to not make the
errors that do make it through hurt us as much.

Along with OO's advantages in components, it also has a huge advantage in
distributed processing and multi-language systems.   But anytime we have lots of
interfaces and diverse systems, we increase points of vulnerability.    We use
OO because it allows us to do what we want to be done - but we shouldn't be
fooled into thinking that we won't have errors that get through in ways we don't
expect.

And when we increase our connectivity to demand that our XML/Java web page works
with some unknown browser on some unknown platform - we need to test more than
we do.     But we *can't* test every unknown interface, so we have to change our
standards.

Our world is too big and complex to know everything or test everything anymore.
0
howard (6283)
6/25/2004 6:13:54 PM
robert.deletethis@wagner.net (Robert Wagner) wrote

> >So, how do you think OO overcomes this objection ?  Why would these
> >shops suddenly say: "we won't have to retest all invokers" ?
> 
> They would change their culture. They would become practical by testing the
> Class rather than all invokers.

No. Wrong.  They _could_ change their culture, but the question that I
asked was: Why _would_ they change ?

In fact the _could_ change their culture without using OO.  They could
carefully (re)design their existing interfaces between programs so
that changes in the called program did not require recompiling and
retesting all the callers.  They _could_ design test harnesses that
will prove the changed routine would not be a problem to the callers.

But this change has in it much of what would be required if they used
OO, carefully designed and documented intefaces, stand-alone module
(class) testing.  If they aren't doing this now what _would_ make them
change ?
 
> >They'll probably copy and paste to create a new class.
> >
> >Or perhaps they'll wind up with infinite inheritance.  This is where a
> >base class is never touched and every variation is done through
> >inheriting the previous iteration and adding a few changes via
> >overriding.
> 
> That's what the worst of them would do.

Exactly. As I already said:..
 
> >OO is not a magic bullet that will fix poor practices.
> 
> Why do we have poor practices? I contend it's a generational issue. People are
> promoted to management on the strength of obsolete technical skills. 

Exactly.  30 years ago I was told by a manager that if I wanted
promotion then I would have to 'forget' everything that made me useful
in my job.  I have been very fortunate in being able to completely
ignore managers everywhere I have worked.

But you haven't answered why you think that using OO will suddenly
change this 'generational problem'.

> >Using small variable page size for demand paging is simply a
> >non-starter, this leads either to huge internal fragmentation or large
> >overhead to avoid this fragmentation, _or_ requires 'garbage
> >collection' which is what you claimed wasn't necessary.
> 
> Your computer spends 99% of its time waiting for a keystroke. 

You never really answer any questions at all, but simply try to
deflect.  You had claimed that 'garbage collection' was obsolete,
presumably on the basis that you thought it would be 'paged out' while
in fact it won't, the heap would become fragmented.  Now you give an
example that there is _plenty_ of time available for garbage
collection to run.
 
> >You did mention that your 'OS' was a failure, didn't you ?
> 
> Not for technical reasons.

I recall you mentioned that some 'computer scientists' had raised
technical objections that you, presumably, didn't agree with, or
possibly didn't understand.

Did it ever run ?
0
riplin (4127)
6/25/2004 9:13:54 PM
"Clark F. Morris, Jr." wrote:
> 
> Warren Simmons wrote:
> 
>>> rest snipped
> The 705 mod III had Receive Serial (set the location for the move or
> store) followed by a Transfer Store Location.  The perform thus would
> store the next instruction location in the instruction address of the
> implied or explicit EXIT instruction and the EXIT instruction would
> store the next Instruction address in the EXIT Transfer Store Location
> making a branch to next instruction.  The store next instruction
> location and branch of the RCA 301 worked the same way (V1
> store-address,branch address).  Unfortunately, the IBM 360 did not have
> a comparable instruction or capability.

Seems to me that we did something very similar: using a S define
constant with the address of where we wanted to go back to plugged into
the address field  of the unconditional branch to return: but it only
worked (as I recall) on machines with 32K or less memory.

PL
0
lacey (134)
6/25/2004 11:05:24 PM
In article <cbhq12$pg4$1@peabody.colorado.edu>,
 "Howard Brazee" <howard@brazee.net> wrote:

> The more code is turned into a component, the less testing is needed - 
> provided it stays as a component.   I haven't found many bugs in CoBOL
> compilers, for instance.   But testing still is necessary, and we have
> seen bugs make it to production even in highly tested OO code such as
> Windows.   I have found more bugs in published routines in library 
> type languages.   In-house objects are more likely to have bugs in 
> them yet.

Windows is neither 'highly tested' or 'OO'.

Unless you mean "highly tested" by the end users after the company has 
released it as "producetion quality".
0
6/25/2004 11:36:57 PM
"Rick Smith" <ricksmith@mfi.net> wrote:

>
>Robert Wagner <robert.deletethis@wagner.net> wrote in message
>news:40d9f6b8.196351819@news.optonline.net...
>> riplin@Azonic.co.nz (Richard) wrote:
>> >robert.deletethis@wagner.net (Robert Wagner) wrote

>Steve McConnell, "Code Complete," Microsoft Press, 1993,

One of my favorite programming books. A Must Read. 

>page 159, "When to Use Structured Design," writes "Structured
>design is mainly a way of breaking a program into routines. It
>emphasizes functionality and doesn't stress data. An example
>of a functionally oriented problem domain would be a system
>that reads data in batch mode, performs predictable processes
>on that data in a predictable order, and writes the data."

A little confusing. He extolls functionality, then describes temporal
processing.

>McConnell goes on to write (referring to Constantine's article,
>"Objects, Functions, and Program Extensibility") "If data is likely
>to change, the object-oriented approach is appropriate because
>it isolates the data likely to change into individual objects (modules).

So does database technology. 

>If functionality is likely to change, the object-oriented approach is not
>so appropriate because functionality is spread thoughout many
>objects (modules). If the functionality is more likely to change than
>the data, you are better off using the functional decomposition of
>structured design." [Here 'functionality' seems to refer to the
>functionality of a proposed system.]

Wrong. When functionality changes, OO shines brightest. It lets one override
methods with new variations.

>> When we do maintenance, we're not interested in timeline, we're interested
>> in a few particular variables. Under what conditions is this thing
>changed?
>> Finding hits in numerous programs makes the process unreliable. It's worse
>> when the variable is called by different names, for example one name in
>> working-storage and a different name in the database. Or when some code
>> that changes it is hidden in a stored procedure.
>>
>> Packaging all logic in one place would make maintenance more reliable.
>
>Or perhaps, Mr Wagner, a bit easier; there sometimes being tools
>to help identify all such affected source programs.

Tools are hard to find, and they don't delve into things like stored procedures.
Brief's 'hot grep' was added as an afterthought, written as a macro. It was so
slow that it was unusable. I had to write my own editor to get that capability.

>Given a fixed asset application with the abstract superclass
>DepreciationMethod and subclasses StraightLine and
>DoubleDecliningBalance; also, an inventory application with the
>abstract superclass ReorderMethod and subclasses EOQ and
>OrderToLevel, it is fairly easy to add classes for additional
>depeciation methods and reorder methods. But, Mr Wagner
>is it really so much more difficult to accomplish this using
>structured design as to *need* object oriented design for the
>simple, common abstractions found in so many business
>applications, ?

No it isn't. You're talking like a user, who thinks algorithms are the apex of
complexity because it the highest level of abstraction he experiences.
Variations in depreciation don't even deserve methods. They can be 'sub-classed'
with a case statement.


0
6/26/2004 1:20:16 AM
>Rick Smith <ricksmith@mfi.net> wrote in message
>news:10dmma0mgsho6f9@corp.supernews.com...

>Let me apologize for what must seem a confused response. At
>some point after posting, I realized that I had never before seen
>the term 'functional cohesion' used with structured design; and
>I was right. The term I saw was 'functional binding' in an article
>written by Stevens, Myers, and Constantine, titled "Structured
>design". The article states "Binding is the measure of cohesiveness
>of a module." and "Functional Cohesiveness" is the highest of six
>classifications. By implication, the goal of structured design is
>functional decomposition into modules to achieve the highest
>classification of cohesiveness. My use of 'temporal cohesion'
>came from another source and is related to batch files.

I applaud your introspection and self-correction.

>The article also states "In a functionally bound module, all of the
>elements are related to the performance of a single function."
>Expanding this *idea* to the program level suggests that the *goal*,
>functional cohesiveness, can only be achieved at the program
>level if there is only one program operating on private data. This
>seems to exclude batch processing where some of the
>elements (data) are related to the performance of different functions.
>Thus I still see no *need* nor any *advantage*.

It's pretty simple. In the old days we had limited memory. We had to package
batch logic along temporal lines. Program A applied transactions, program B did
recalculations. A and B couldn't fit in memory at the same time. 

Now we can call A to apply transactions to a particular thing, then immediately
call B to recalculate that thing. We can write batch programs that operate like
online programs. We don't need temporary files feeding data from A to B. 
0
6/26/2004 1:20:17 AM
riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> >So, how do you think OO overcomes this objection ?  Why would these
>> >shops suddenly say: "we won't have to retest all invokers" ?
>> 
>> They would change their culture. They would become practical by testing the
>> Class rather than all invokers.
>
>No. Wrong.  They _could_ change their culture, but the question that I
>asked was: Why _would_ they change ?
>
>In fact the _could_ change their culture without using OO.  They could
>carefully (re)design their existing interfaces between programs so
>that changes in the called program did not require recompiling and
>retesting all the callers.  They _could_ design test harnesses that
>will prove the changed routine would not be a problem to the callers.
>
>But this change has in it much of what would be required if they used
>OO, carefully designed and documented intefaces, stand-alone module
>(class) testing.  If they aren't doing this now what _would_ make them
>change ?

They might be lured to changing by New Technology. Called programs aren't new,
we've known them for 20+ years. OO is new to the Cobol world.

>You never really answer any questions at all, but simply try to
>deflect. 

Because I don't want to be dragged into fruitless debates.

> You had claimed that 'garbage collection' was obsolete,
>presumably on the basis that you thought it would be 'paged out' while
>in fact it won't, the heap would become fragmented.  Now you give an
>example that there is _plenty_ of time available for garbage
>collection to run.

Garbage is a non-issue when objects are persistent. The important issue is
defragging objects (on disk) so that objects accessed close together in time are
close together on disk, to avoid head movement. That coalesence should be done
when the computer would otherwise be idle. 

It's not always obvious that a customer object should be located close to orders
from that customer, for example.

>Did it ever run ?

Of course. Since the target platform was Intel 8086 compatible, it could run on
any DOS machine. 
0
6/26/2004 1:20:21 AM
In article <40dcc261.36805756@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>riplin@Azonic.co.nz (Richard) wrote:

[snip]

>>You never really answer any questions at all, but simply try to
>>deflect. 
>
>Because I don't want to be dragged into fruitless debates.

No answering questions, no attempts to clarify or add information... and 
all of this with the intent of promoting COBOL as 'a Real Programming 
Language' (caps original).

Nobody said it was going to be easy, I guess.

DD
0
docdwarf (6044)
6/26/2004 1:45:00 AM
"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
>  If an object is changed for performance reasons and all 
>inputs and outputs are kept the same (exactly), then testing can be 
>confined to the object.  If it is changed to accept new inputs leading 
>to new outputs or to provide changed outputs, then testing should be 
>done to test the effects of the change on most if not all invokers. 
>Indeed a running of the entire processing cycle in which the changes 
>occur may be necessary. 

The systems that should not be affected need only a 'negative finding'
regression test. That's relatively painless.
0
6/26/2004 7:49:52 AM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40dca602.29541137@news.optonline.net...
> "Rick Smith" <ricksmith@mfi.net> wrote:
>
> >
> >Robert Wagner <robert.deletethis@wagner.net> wrote in message
> >news:40d9f6b8.196351819@news.optonline.net...
> >> riplin@Azonic.co.nz (Richard) wrote:
> >> >robert.deletethis@wagner.net (Robert Wagner) wrote
>
> >Steve McConnell, "Code Complete," Microsoft Press, 1993,
>
> One of my favorite programming books. A Must Read.
>
> >page 159, "When to Use Structured Design," writes "Structured
> >design is mainly a way of breaking a program into routines. It
> >emphasizes functionality and doesn't stress data. An example
> >of a functionally oriented problem domain would be a system
> >that reads data in batch mode, performs predictable processes
> >on that data in a predictable order, and writes the data."
>
> A little confusing. He extolls functionality, then describes temporal
> processing.

Mr Wagner, this not confusing, at all. Here, McConnell is discussing
*when* to use Structured Design, not what it is or how to use it.

> >McConnell goes on to write (referring to Constantine's article,
> >"Objects, Functions, and Program Extensibility") "If data is likely
> >to change, the object-oriented approach is appropriate because
> >it isolates the data likely to change into individual objects (modules).
>
> So does database technology.
>
> >If functionality is likely to change, the object-oriented approach is not
> >so appropriate because functionality is spread thoughout many
> >objects (modules). If the functionality is more likely to change than
> >the data, you are better off using the functional decomposition of
> >structured design." [Here 'functionality' seems to refer to the
> >functionality of a proposed system.]
>
> Wrong. When functionality changes, OO shines brightest. It lets one
override
> methods with new variations.

Perhaps an example and explanation will clarify.

In 1983 I was doing embedded programming for a firm that made
data collection terminals. The president of the company decided
we could sell more terminals if we also supplied software to
process the data collected.

Decisions were made -- people brought in -- a system was born.

Over the next five years, the system underwent several changes.
Users liked what the system did and wanted it to do more. That is,
they wanted the system to do more than process the data collected.
The functionality of the system changed.

McConnell's interpretation of Constantine's article seems to be
that structured design may be better for such evolving systems.
Perhaps this is because such systems have no 'real world' to
model or, maybe the expression of the functionality is needed
before one can decide what the 'real world' ought to be.
[This is reminiscent of Machiavelli's 'new order' and having
'actual experience of it'.]

In other words, evolving functionality will determine what data is
to be processed and preserved and this fits structured design.
Evolving data (improved modeling) will determine what processes
(behavior) are to be done and this fits object oriented design.



0
ricksmith (875)
6/26/2004 10:34:48 AM
One thing about your ideas; *anytime* a module's internals change, you run a very
real risk of introducing some form of unexpected behavior, anything from a performance
hit to the thing just rolling over and dying.

So basically, what time you would have spent before in integration testing is now
dedicated to module level testing. There is usually a slight net gain realized, but
it is nothing near as huge as one might think.

Essentially, OO technology in unarguably a *good* thing, but it always has had a
few problems with truth in advertising. :)

-Paul

"Peter E. C. Dashwood" <dashwood@enternet.co.nz> wrote in message news:b3638c46.0406242236.136ca912@posting.google.com...
> "Howard Brazee" <howard@brazee.net> wrote in message news:<cbenk8$nt2$1@peabody.colorado.edu>...
> > On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:
> >
> > > So, how do you think OO overcomes this objection ?  Why would these
> > > shops suddenly say: "we won't have to retest all invokers" ?
> >
> > A "feature" of OO is that once a shop moves to OO, it is impossible to do the
> > same rigorous testing that were the earlier standards, so the standards get
> > changed.
>
> I don't think so, Howard.
>
> Control of your environment is an administrative function. If you
> insist that "rigourous testing as prescribed by our existing
> standards" will be done, then it will be. It certainly isn't made
> "impossible" by adopting OO, although it may be made "unnecessary".
>
> I don't want to argue the case for OO here any more (I'm heartily sick
> of doing so) but I will say that if you extend your OO Classes into
> encapsulated components (as I have been doing for some years now) you
> CAN obviate a large amount of what was previous regression testing.
>
> Because components have specific Methods that define their
> functionality, you can change the functionality of a system by adding
> new components to it. (In the same way that you might add an extra
> wall to your house by buying more bricks). Why would you then go and
> retest all the functions that haven't changed?  Would you stress test
> all the previously existing bricks in your wall?
>
> Well, you might, but the answer is it depends on how confident you are
> about the wall and the bricks. You certainly don't HAVE to do it.
>
> It isn't about testing every "invoker" just as you would every
> "caller". There are subtle, but important, differences between what is
> called and what is invoked, but most COBOLLers just lump them together
> because that is what they understand. "Hey, Ive been using CALL for
> years, INVOKE has exactly the same syntax, what's the big deal? They
> must do the same, right?" Wrong.
>
> (Just as a hint, and I have no intention of expanding this because it
> is pointless to do so in this forum, consider what differences it
> might make (to your system and program design) if you were able to
> change the internal data of a called module, dynamically, immediately
> before you called it, WITHOUT changing the interface to it. Change the
> internal settings so its behaviour changed, set internal flags, give
> it different initial values?  But don't need to recompile everything
> that calls it, because the interface to it is exactly the same and the
> functionality is exactly the same.  Code that invoked it without
> changing its properties will work exactly as it always has; new code
> will cause it to behave differently. It still takes the same
> parameters through the USING clause, but its behaviour is different
> when it is called by some callers, from when it is called by others...
> Only new code that needed to change some of the behaviours in it would
> need to be tested.
>
> Would it make generalized and flexible software easier to write? Could
> you have fewer, more "general-purpose" modules? Do you find this idea
> exciting or do you find it frightening? Invoked objects CAN do that;
> called modules can't.)
>
> You CAN create "system building blocks" that do more than called COBOL
> modules ever could, you CAN deploy these blocks into responsive,
> easily maintained, reusable, application functionality, and if you do,
> you DON'T need to do all the rigourous regression testing that is
> standard practice for most installations.
>
> But there is nothing to stop you from continuing to do it if that
> makes you feel better.
>
> Pete.


0
6/26/2004 4:12:40 PM
For the slow learner, me, please itemize the steps in a negative finding
regression test.
Thank you in advance.

Warren Simmons

Robert Wagner wrote:

> "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
> 
>> If an object is changed for performance reasons and all 
>>inputs and outputs are kept the same (exactly), then testing can be 
>>confined to the object.  If it is changed to accept new inputs leading 
>>to new outputs or to provide changed outputs, then testing should be 
>>done to test the effects of the change on most if not all invokers. 
>>Indeed a running of the entire processing cycle in which the changes 
>>occur may be necessary. 
> 
> 
> The systems that should not be affected need only a 'negative finding'
> regression test. That's relatively painless.
0
wsimmons5 (172)
6/26/2004 4:13:29 PM
Your discussion brings to mind one application that caused a great deal 
of trouble in design. The "application" was the administration of the
several Pension Plans. At the start, rules existed, but were different
in different cases. They could be over ruled as well. No two people
involved in the manual system could agree on what the system was
supposed to do. There was an seemingly endless list of options and
several had no documentation. I don't know the outcome of that
design, except to say an attempt was made to make the logic depend
upon a table of yes and no indicators. Also, the programmer,
thou retired, was hired back to update the program.

His assignment resulted in the first major review and update of the
plans in years.

Warren Simmons


Rick Smith wrote:

> Robert Wagner <robert.deletethis@wagner.net> wrote in message
> news:40dca602.29541137@news.optonline.net...
> 
>>"Rick Smith" <ricksmith@mfi.net> wrote:
>>
>>
>>>Robert Wagner <robert.deletethis@wagner.net> wrote in message
>>>news:40d9f6b8.196351819@news.optonline.net...
>>>
>>>>riplin@Azonic.co.nz (Richard) wrote:
>>>>
>>>>>robert.deletethis@wagner.net (Robert Wagner) wrote
>>
>>>Steve McConnell, "Code Complete," Microsoft Press, 1993,
>>
>>One of my favorite programming books. A Must Read.
>>
>>
>>>page 159, "When to Use Structured Design," writes "Structured
>>>design is mainly a way of breaking a program into routines. It
>>>emphasizes functionality and doesn't stress data. An example
>>>of a functionally oriented problem domain would be a system
>>>that reads data in batch mode, performs predictable processes
>>>on that data in a predictable order, and writes the data."
>>
>>A little confusing. He extolls functionality, then describes temporal
>>processing.
> 
> 
> Mr Wagner, this not confusing, at all. Here, McConnell is discussing
> *when* to use Structured Design, not what it is or how to use it.
> 
> 
>>>McConnell goes on to write (referring to Constantine's article,
>>>"Objects, Functions, and Program Extensibility") "If data is likely
>>>to change, the object-oriented approach is appropriate because
>>>it isolates the data likely to change into individual objects (modules).
>>
>>So does database technology.
>>
>>
>>>If functionality is likely to change, the object-oriented approach is not
>>>so appropriate because functionality is spread thoughout many
>>>objects (modules). If the functionality is more likely to change than
>>>the data, you are better off using the functional decomposition of
>>>structured design." [Here 'functionality' seems to refer to the
>>>functionality of a proposed system.]
>>
>>Wrong. When functionality changes, OO shines brightest. It lets one
> 
> override
> 
>>methods with new variations.
> 
> 
> Perhaps an example and explanation will clarify.
> 
> In 1983 I was doing embedded programming for a firm that made
> data collection terminals. The president of the company decided
> we could sell more terminals if we also supplied software to
> process the data collected.
> 
> Decisions were made -- people brought in -- a system was born.
> 
> Over the next five years, the system underwent several changes.
> Users liked what the system did and wanted it to do more. That is,
> they wanted the system to do more than process the data collected.
> The functionality of the system changed.
> 
> McConnell's interpretation of Constantine's article seems to be
> that structured design may be better for such evolving systems.
> Perhaps this is because such systems have no 'real world' to
> model or, maybe the expression of the functionality is needed
> before one can decide what the 'real world' ought to be.
> [This is reminiscent of Machiavelli's 'new order' and having
> 'actual experience of it'.]
> 
> In other words, evolving functionality will determine what data is
> to be processed and preserved and this fits structured design.
> Evolving data (improved modeling) will determine what processes
> (behavior) are to be done and this fits object oriented design.
> 
> 
> 
0
wsimmons5 (172)
6/26/2004 4:36:51 PM
Actually, Windows is both, much as it irks me to admit it. 99% of the troubles with windows
are related to the fact it has to run on an ungodly number of hardware configurations. Something
that was *not* really in its original design.  Dave Cutler, the real mind behind the core of Windows NT, came to Microsoft fresh
from success with DEC VMS, which is a beautiful OS,
incredibly stable, and to which NT has amazing similarities. ;) But VMS ran on a restricted range
of hardware, and an even more restricted range of firmware.

NT on the other paw, runs on a tens of thousands of different hardware devices, and quite
literally, millions of combinations of that hardware. A daunting task indeed.

Most of the software issues with NT are definitely not in the 'core' OS, but are related to peripheral software products, like
Internet Explorer. :)

-Paul

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message news:joe_zitzelberger-C0F17F.19365725062004@corp.supernews.com...
> In article <cbhq12$pg4$1@peabody.colorado.edu>,
>  "Howard Brazee" <howard@brazee.net> wrote:
>
> > The more code is turned into a component, the less testing is needed -
> > provided it stays as a component.   I haven't found many bugs in CoBOL
> > compilers, for instance.   But testing still is necessary, and we have
> > seen bugs make it to production even in highly tested OO code such as
> > Windows.   I have found more bugs in published routines in library
> > type languages.   In-house objects are more likely to have bugs in
> > them yet.
>
> Windows is neither 'highly tested' or 'OO'.
>
> Unless you mean "highly tested" by the end users after the company has
> released it as "producetion quality".


0
6/26/2004 4:58:00 PM
"Rick Smith" <ricksmith@mfi.net> wrote:

>
>Robert Wagner <robert.deletethis@wagner.net> wrote in message
>news:40dca602.29541137@news.optonline.net...
>> "Rick Smith" <ricksmith@mfi.net> wrote:
>>
>> >
>> >Robert Wagner <robert.deletethis@wagner.net> wrote in message
>> >news:40d9f6b8.196351819@news.optonline.net...
>> >> riplin@Azonic.co.nz (Richard) wrote:
>> >> >robert.deletethis@wagner.net (Robert Wagner) wrote
>>
>> >Steve McConnell, "Code Complete," Microsoft Press, 1993,
>>
>> One of my favorite programming books. A Must Read.
>>
>> >page 159, "When to Use Structured Design," writes "Structured
>> >design is mainly a way of breaking a program into routines. It
>> >emphasizes functionality and doesn't stress data. An example
>> >of a functionally oriented problem domain would be a system
>> >that reads data in batch mode, performs predictable processes
>> >on that data in a predictable order, and writes the data."
>>
>> A little confusing. He extolls functionality, then describes temporal
>> processing.
>
>Mr Wagner, this not confusing, at all. Here, McConnell is discussing
>*when* to use Structured Design, not what it is or how to use it.
>
>> >McConnell goes on to write (referring to Constantine's article,
>> >"Objects, Functions, and Program Extensibility") "If data is likely
>> >to change, the object-oriented approach is appropriate because
>> >it isolates the data likely to change into individual objects (modules).
>>
>> So does database technology.
>>
>> >If functionality is likely to change, the object-oriented approach is not
>> >so appropriate because functionality is spread thoughout many
>> >objects (modules). If the functionality is more likely to change than
>> >the data, you are better off using the functional decomposition of
>> >structured design." [Here 'functionality' seems to refer to the
>> >functionality of a proposed system.]
>>
>> Wrong. When functionality changes, OO shines brightest. It lets one
>override
>> methods with new variations.
>
>Perhaps an example and explanation will clarify.
>
>In 1983 I was doing embedded programming for a firm that made
>data collection terminals. The president of the company decided
>we could sell more terminals if we also supplied software to
>process the data collected.
>
>Decisions were made -- people brought in -- a system was born.
>
>Over the next five years, the system underwent several changes.
>Users liked what the system did and wanted it to do more. That is,
>they wanted the system to do more than process the data collected.
>The functionality of the system changed.
>
>McConnell's interpretation of Constantine's article seems to be
>that structured design may be better for such evolving systems.
>Perhaps this is because such systems have no 'real world' to
>model or, maybe the expression of the functionality is needed
>before one can decide what the 'real world' ought to be.
>[This is reminiscent of Machiavelli's 'new order' and having
>'actual experience of it'.]
>
>In other words, evolving functionality will determine what data is
>to be processed and preserved and this fits structured design.
>Evolving data (improved modeling) will determine what processes
>(behavior) are to be done and this fits object oriented design.

I'm guessing the company was either Telzon or Symbol. I have some experience
with both.  Their '80s offerings weren't that great. They could run DOS
programs. Big deal, and a far cry from the abstractions of McConnell and
Constantine.

I don't see the either-or choice between structured and object oriented. Seems
to me they're solving the same problem in much the same way. Historically,
structured appeared in the '70s whereas OO appeared in the '80s. Structured was
more conformant with machine limitations whereas OO was more interpretive. 

Now that we have CPU speed galore, we should probably go with OO unless there is
a compelling abstract reason to the contrary.

0
6/26/2004 10:44:04 PM
Warren Simmons <wsimmons5@optonline.net> wrote:

>For the slow learner, me, please itemize the steps in a negative finding
>regression test.

You run the old system and the new system. You compare their outputs and find
them identical. 'Negative' means no difference. 


>Robert Wagner wrote:
>
>> "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
>> 
>>> If an object is changed for performance reasons and all 
>>>inputs and outputs are kept the same (exactly), then testing can be 
>>>confined to the object.  If it is changed to accept new inputs leading 
>>>to new outputs or to provide changed outputs, then testing should be 
>>>done to test the effects of the change on most if not all invokers. 
>>>Indeed a running of the entire processing cycle in which the changes 
>>>occur may be necessary. 
>> 
>> 
>> The systems that should not be affected need only a 'negative finding'
>> regression test. That's relatively painless.

0
6/26/2004 11:31:22 PM
Oh, I would have said check to see if you get the same results.
You can sss why I'm a slow learner.

warren simmons

Robert Wagner wrote:
> Warren Simmons <wsimmons5@optonline.net> wrote:
> 
> 
>>For the slow learner, me, please itemize the steps in a negative finding
>>regression test.
> 
> 
> You run the old system and the new system. You compare their outputs and find
> them identical. 'Negative' means no difference. 
> 
> 
> 
>>Robert Wagner wrote:
>>
>>
>>>"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
>>>
>>>
>>>>If an object is changed for performance reasons and all 
>>>>inputs and outputs are kept the same (exactly), then testing can be 
>>>>confined to the object.  If it is changed to accept new inputs leading 
>>>>to new outputs or to provide changed outputs, then testing should be 
>>>>done to test the effects of the change on most if not all invokers. 
>>>>Indeed a running of the entire processing cycle in which the changes 
>>>>occur may be necessary. 
>>>
>>>
>>>The systems that should not be affected need only a 'negative finding'
>>>regression test. That's relatively painless.
> 
> 
0
wsimmons5 (172)
6/27/2004 1:30:48 AM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40ddf53a.115370059@news.optonline.net...
[snip]
> I don't see the either-or choice between structured and object oriented.
Seems
> to me they're solving the same problem in much the same way.

Structured is top-down; OO is not.

Structured begins, normally, with the sequence input-process-
output and continues partitioning heirarchically by function, or
functional decomposition, until the system has been fully
described. [For COBOL this is normally procedural
decomposition. Academics seldom use COBOL to support
their theories.]

OO begins by partioning objects until there are no more
objects. The resulting system is described as 'a set of objects
working together to support a common purpose', 'objects
interacting' or 'collaborating'.

In the purist sense of OO 'real systems have no top'. This lead
to concerns that real OO should not be used for batch
processing since, by convention, such systems must have a
top from which to control the sequence input-process-output.

In theory, structured could be used to solve any problem. In
practice, problems become intractable when complexity or
size become very large. One explanation is that structured's
dependency on the heirarchy to control the bottom makes the
problem unmanagable. OO eliminates the heirarchy thus
making OO better for large or complex systems.

For a large, real-time, embedded application use OO. For
a small batch process, use structured. In between it's a matter
of preference that will be influenced by the type of problem,
the size, and complexity.



0
ricksmith (875)
6/27/2004 10:45:26 AM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40ddf53a.115370059@news.optonline.net...
[snip]
> [...] we should probably go with OO unless there is
> a compelling abstract reason to the contrary.

Mr Wagner, what does it mean to 'go with OO [design]'?

In the beginning, there was code-and-fix programming with
ad hoc design. This was found to be inadequate for
communicating the designs of programs or applications.
Various methods and documentation techniques were
developed, and improved upon, to provide a means for
communicating the design of progams and applications.
These methods and techniques were described in articles
and books and taught to practitioners.

Today, IMO, (structured) practioners generally use code-and-fix
programming with ad hoc design; but there is a difference.
As a result of training and study, code-and-fix programming
is in the spirit of structured programming and program and
application design is in the spirit of structured design; even
where it is not separately documented. That is, how many
actually create structure charts and PDL -- say, structured
English -- before programming and maintain them separately?

To understand OO Design it is necessary to study the Booch
method (or one of the others) for partitioning an application
and the means used for documenting the design. Only then
may one know what it means to 'go with OO [design]'. Then
one may resume one's code-and-fix programming with ad hoc
design in the spirit of OO Design.

There is one important difference between structured and OO
with respect to documenting a design. The design of a
structured system may be understood by the heirarchy and,
therefore, need not necessarily be shown in a separate
document. To completely understand an OO design, a separate
document is needed to show the interconnections between
classes. UML or paper will do.



0
ricksmith (875)
6/27/2004 1:17:20 PM
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:10dti4sdjjmmuc6@corp.supernews.com...
>
> Robert Wagner <robert.deletethis@wagner.net> wrote in message
> news:40ddf53a.115370059@news.optonline.net...
> [snip]
> > [...] we should probably go with OO unless there is
> > a compelling abstract reason to the contrary.
>
> Mr Wagner, what does it mean to 'go with OO [design]'?
>
> In the beginning, there was code-and-fix programming with
> ad hoc design. This was found to be inadequate for
> communicating the designs of programs or applications.
> Various methods and documentation techniques were
> developed, and improved upon, to provide a means for
> communicating the design of progams and applications.
> These methods and techniques were described in articles
> and books and taught to practitioners.
>
> Today, IMO, (structured) practioners generally use code-and-fix
> programming with ad hoc design; but there is a difference.
> As a result of training and study, code-and-fix programming
> is in the spirit of structured programming and program and
> application design is in the spirit of structured design; even
> where it is not separately documented. That is, how many
> actually create structure charts and PDL -- say, structured
> English -- before programming and maintain them separately?
>
> To understand OO Design it is necessary to study the Booch
> method (or one of the others) for partitioning an application
> and the means used for documenting the design. Only then
> may one know what it means to 'go with OO [design]'. Then
> one may resume one's code-and-fix programming with ad hoc
> design in the spirit of OO Design.
>

Well, yes. LVM/OOD, though 'out of date' is my favorite and well used
approach.
However, there is a group of people who adhere to the SmallTalk idea of
purist OO deisgn and coding. I've used Smalltalk is some moderately large
sized applications, and while I appreciate its power and amd actually
in a little awe of how beautiful its structure is (almost musical, like Bach
:)
well...

Implementation in SmallTalk is fun and veryunderstandable, but you are
restricted and hemmed in on all sides as to how your implement something,
and the only real recourse for performance is to put it on faster hardware.

I fall more towards implementation in 3GLs with external OO design
imposed. I suppose I was spoiled by doing a very large project in Ada. :)

-Paul


> There is one important difference between structured and OO
> with respect to documenting a design. The design of a
> structured system may be understood by the heirarchy and,
> therefore, need not necessarily be shown in a separate
> document. To completely understand an OO design, a separate
> document is needed to show the interconnections between
> classes. UML or paper will do.
>
>
>


0
6/27/2004 4:57:28 PM
"Rick Smith" <ricksmith@mfi.net> wrote:

>
>Robert Wagner <robert.deletethis@wagner.net> wrote in message
>news:40ddf53a.115370059@news.optonline.net...
>[snip]
>> I don't see the either-or choice between structured and object oriented.
>Seems
>> to me they're solving the same problem in much the same way.
>
>Structured is top-down; OO is not.

That's a profound insight. You're saying structured is hierocratic whereas OO is
networked.

>Structured begins, normally, with the sequence input-process-
>output and continues partitioning heirarchically by function, or
>functional decomposition, until the system has been fully
>described.

Slight correction -- it is driven by process, not by input. Process is at the
top of the pyramid; input is at the very bottom. Picture it sucking input like
liquid through a straw. 

The program's purpose is not 'to process input', it is 'to run a warehouse.' We
start with that high level view and decompose. At a low level in the
decomposition, we recognize the need for inputs to tell us about new items and
customer demand, but they are not the driving force. The main idea should be
moving merchandise through a warehouse building.

>OO begins by partioning objects until there are no more
>objects. The resulting system is described as 'a set of objects
>working together to support a common purpose', 'objects
>interacting' or 'collaborating'.

In other words, a network.

>In the purist sense of OO 'real systems have no top'. This leads
>to concerns that real OO should not be used for batch
>processing since, by convention, such systems must have a
>top from which to control the sequence input-process-output.

I once wrote "The secret to success in structured programming is ambivalance.
The word commonly means indecisive. To me it means rapid alternation between
top-down and bottom-up thinking."

What I meant was we should design top-down and program bottom-up. That
programming should be an interative process -- design a little, program a
little, design some more, program what you just designed. Give the design
process some feedback by alternating every few seconds. 

I dislike the practice of doing all design first, followed by 'implementation'.
It is not humanly possible to anticipate all contingencies, to think of
everything that might go wrong. 

The network model seems more friendly than structured to my methodology. It
doesn't pretend that ALL design should be done before the first line of code is
written.

>In theory, structured could be used to solve any problem. In
>practice, problems become intractable when complexity or
>size become very large. One explanation is that structured's
>dependency on the heirarchy to control the bottom makes the
>problem unmanagable. OO eliminates the heirarchy thus
>making OO better for large or complex systems.

Large corporations and agencies use both approaches. They are networked at the
upper levels. Messages are sent laterally between department heads .. via
meetings, emails and other documents. But within each department, the
organization is hierocratic. 

Organizations that are hierocratic from top to bottom are known for their
inflexibility.

What's wrong with organizing programs the same way we organize people? Send
messages between 'systems' while using a hierarchy within each system. The
problem then becomes defining the domain of a 'system'. OO seems to define each
Class as a system whereas structured programming defines systems much larger ..
comparable to organizational departments. 

In that regard, OO seems more like a society than 'a set of objects
working together to support a common purpose'. Given that they don't know the
common purpose (any more than we know the meaning of life), how can they
collaborate? 

>For a large, real-time, embedded application use OO. For
>a small batch process, use structured. In between it's a matter
>of preference that will be influenced by the type of problem,
>the size, and complexity.

I favor OO between 'systems' and structured inside systems. Because the dynamics
of programs is not the same as people, the size of a 'system' can be much
smaller than a human department or business function. 

0
6/27/2004 9:58:55 PM
"Rick Smith" <ricksmith@mfi.net> wrote:

>
>Robert Wagner <robert.deletethis@wagner.net> wrote in message
>news:40ddf53a.115370059@news.optonline.net...
>[snip]
>> [...] we should probably go with OO unless there is
>> a compelling abstract reason to the contrary.
>
>Mr Wagner, what does it mean to 'go with OO [design]'?

>Today, IMO, (structured) practioners generally use code-and-fix
>programming with ad hoc design; but there is a difference.
>As a result of training and study, code-and-fix programming
>is in the spirit of structured programming and program and
>application design is in the spirit of structured design; even
>where it is not separately documented. That is, how many
>actually create structure charts and PDL -- say, structured
>English -- before programming and maintain them separately?

Few do, because it's not necessary nor (IMO) desirable. 

However, we do have a clear statement of the business requirement .. at several
levels of detail. That's what non-programmers test the code against. It is
widely accepted that, when there is a discrepency between a high-level and
low-level document (or program), the higher level prevails. The process is
called waterfall or, more correctly, 'V model'.

>To understand OO Design it is necessary to study the Booch
>method (or one of the others) for partitioning an application
>and the means used for documenting the design. Only then
>may one know what it means to 'go with OO [design]'. Then
>one may resume one's code-and-fix programming with ad hoc
>design in the spirit of OO Design.

Well said. I'll read one of the books rather than trying to figure it out by
reading code.

>There is one important difference between structured and OO
>with respect to documenting a design. The design of a
>structured system may be understood by the heirarchy and,
>therefore, need not necessarily be shown in a separate
>document. To completely understand an OO design, a separate
>document is needed to show the interconnections between
>classes. UML or paper will do.

Crap. I don't like that requirement.

0
6/27/2004 9:58:56 PM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40df0d19.187027976@news.optonline.net...
> "Rick Smith" <ricksmith@mfi.net> wrote:
>
> >
> >Robert Wagner <robert.deletethis@wagner.net> wrote in message
> >news:40ddf53a.115370059@news.optonline.net...
> >[snip]
> >> I don't see the either-or choice between structured and object
oriented.
> >Seems
> >> to me they're solving the same problem in much the same way.
> >
> >Structured is top-down; OO is not.
>
> That's a profound insight. You're saying structured is hierocratic whereas
OO is
> networked.

The literature does not refer to classes as networked; but I did
post such an observation about five years ago and raised it
again a couple years ago.

[snip]
> >In theory, structured could be used to solve any problem. In
> >practice, problems become intractable when complexity or
> >size become very large. One explanation is that structured's
> >dependency on the heirarchy to control the bottom makes the
> >problem unmanagable. OO eliminates the heirarchy thus
> >making OO better for large or complex systems.
>
> Large corporations and agencies use both approaches.

Peter F. Drucker descibes, as I recall, five different forms of
organization. And, yes, there are some eeire similarities to
programming.

> Organizations that are hierocratic from top to bottom are known for their
> inflexibility.
>
> What's wrong with organizing programs the same way we organize people?
Send
> messages between 'systems' while using a hierarchy within each system. The
> problem then becomes defining the domain of a 'system'. OO seems to define
each
> Class as a system whereas structured programming defines systems much
larger ..
> comparable to organizational departments.

Because programs are not people -- they are contrivances
intended to model -- here it comes -- 'an artificial reality'.

OO does not 'define each class as a system'. Often lower level
classes are abstract -- they do nothing more than provide a base
upon which to build a class hierachy that acommplishes the real
work. This is no pretty visualization of this. It kind of like a tree;
except that multiple inheritance gives it multiple trunks and
composition becomes something like trees growing out of trees.

> In that regard, OO seems more like a society than 'a set of objects
> working together to support a common purpose'. Given that they don't know
the
> common purpose (any more than we know the meaning of life), how can they
> collaborate?

Because they are contrivances designed to communicate with
each other. Each solving small parts of the problem. So that
together they figuratively 'hold up and add strength to' the
common purpose.



0
ricksmith (875)
6/27/2004 11:33:46 PM
Robert Wagner <robert.deletethis@wagner.net> wrote in message
news:40df1fc2.191805678@news.optonline.net...
[snip]
> However, we do have a clear statement of the business requirement .. at
several
> levels of detail. That's what non-programmers test the code against. It is
> widely accepted that, when there is a discrepency between a high-level and
> low-level document (or program), the higher level prevails. The process is
> called waterfall or, more correctly, 'V model'.

Mr Wagner, congratulations, you said one of the magic
words, waterfall.

I'll make popcorn while you and Mr Dashwood discuss
its value. <g>



0
ricksmith (875)
6/27/2004 11:51:03 PM
"Rick Smith" <ricksmith@mfi.net> wrote:

>
>Robert Wagner <robert.deletethis@wagner.net> wrote in message
>news:40df1fc2.191805678@news.optonline.net...
>[snip]
>> However, we do have a clear statement of the business requirement .. at
>several
>> levels of detail. That's what non-programmers test the code against. It is
>> widely accepted that, when there is a discrepency between a high-level and
>> low-level document (or program), the higher level prevails. The process is
>> called waterfall or, more correctly, 'V model'.
>
>Mr Wagner, congratulations, you said one of the magic
>words, waterfall.
>
>I'll make popcorn while you and Mr Dashwood discuss
>its value. <g>

When the V model is done well, it is not an obstacle to development. It doesn't
deal with program or database detail at all. It communicates user requirements
to us and the testers. We can develop however we want.

When the V model is done badly, it produces Programming Specs that are usually
poorly written and are always an obstacle to development. 

Organizations with a lot of experience, particularly Big Six contractors, tend
to do it well. I say that from personal experience with IBM, Accenture, EDS and
Keane. The ones who do it badly tend to end-user companies, especially when the
methodology is first used. 

Recall that I advocated the incremental style of development that Mr. Dashwood
favors, and says is impossible under waterfall. I do it every day. 


0
6/28/2004 1:20:59 AM
And after only 10 years they have gotten NT5.0 (Win2k) down to only 
occasional kernel panics and page thrashings.  

(I haven't moved to XP yet, but I don't expect much.)

Original design is great, but what Micro$oft actually releases is what 
it needs to be judged on.


In article <sWhDc.4668$x9.4281@nwrddc01.gnilink.net>,
 "Paul Raulerson" <pkraulerson@verizon.net> wrote:

> Actually, Windows is both, much as it irks me to admit it. 99% of the 
> troubles with windows
> are related to the fact it has to run on an ungodly number of hardware 
> configurations. Something
> that was *not* really in its original design.  Dave Cutler, the real mind 
> behind the core of Windows NT, came to Microsoft fresh
> from success with DEC VMS, which is a beautiful OS,
> incredibly stable, and to which NT has amazing similarities. ;) But VMS ran 
> on a restricted range
> of hardware, and an even more restricted range of firmware.
> 
> NT on the other paw, runs on a tens of thousands of different hardware 
> devices, and quite
> literally, millions of combinations of that hardware. A daunting task indeed.
> 
> Most of the software issues with NT are definitely not in the 'core' OS, but 
> are related to peripheral software products, like
> Internet Explorer. :)
> 
> -Paul
> 
> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message 
> news:joe_zitzelberger-C0F17F.19365725062004@corp.supernews.com...
> > In article <cbhq12$pg4$1@peabody.colorado.edu>,
> >  "Howard Brazee" <howard@brazee.net> wrote:
> >
> > > The more code is turned into a component, the less testing is needed -
> > > provided it stays as a component.   I haven't found many bugs in CoBOL
> > > compilers, for instance.   But testing still is necessary, and we have
> > > seen bugs make it to production even in highly tested OO code such as
> > > Windows.   I have found more bugs in published routines in library
> > > type languages.   In-house objects are more likely to have bugs in
> > > them yet.
> >
> > Windows is neither 'highly tested' or 'OO'.
> >
> > Unless you mean "highly tested" by the end users after the company has
> > released it as "producetion quality".
> 
>
0
6/28/2004 1:56:03 AM
"Paul Raulerson" <pkraulerson@verizon.net> wrote in message news:<YfhDc.2740$x9.1348@nwrddc02.gnilink.net>...
> One thing about your ideas; *anytime* a module's internals change, you run a very
> real risk of introducing some form of unexpected behavior, anything from a performance
> hit to the thing just rolling over and dying.

Performance hits I stopped worrying about 25 years ago (obviously, I
don't write code that is deliberately inefficient, and I have a
lifetime of considering how what I'm writing will impact the platform
I'm writing it for, but I don't WORRY about it and it would be low
down on my design criteria.

I have NEVER had code modified by me "roll over and die". The day that
happens, I'll take up truck driving...<G>

Now to serious discussion...

I haven't changed the internals. That's the whole point. I changed the
PROPERTIES, which are simply data. This causes a behavioural change,
but that "possibility" has always been in the code and was tested and
debugged when it was written. There may also be "dormant" methods in
the component that haven't needed to be activated yet. That's because,
when it was designed it was designed to be comprehensive, but our
application hasn't go to the stage of needing some of the
possibilities yet.

This is why the approach is completely different. Design is not based
on a series of procedures to meet current requirements. Instead it is
based on "modelling" or simulating the behaviour of things in the real
world.

Individual objects are examined and all of their possible behaviours
are considered. (Obviously, you can't ALWAYS get ALL of the
possibilities, but it is real fun trying, and you design things so
that they are generalised (But dynamically modifiable)solutions. On
the other hand, sometimes you CAN identify all possible behaviours
fairly easily; A file or database handling component, for instance. As
long as it can ADD, CHANGE, DELETE, and FETCH data, there are unlikely
to be other requirements for it. (You COULD add maintenance functions
like CREATE, LOAD, and UNLOAD to it, but I wouldn't do this... It
comes down to the criteria you use for your CBD).

> 
> So basically, what time you would have spent before in integration testing is now
> dedicated to module level testing. There is usually a slight net gain realized, but
> it is nothing near as huge as one might think.

At what point did we drop integration testing? I integration test new
components as they come off the assembly line and I integration test
newly activated behaviour in existing components. What I don't do, is
regression test behaviours that have not changed.

Besides, I use a development methodology that spreads testing into the
development phase (there is no separate "Testing" phase) and things
are tested as they are written.

I do not use the "Waterfall" for either my personal stuff  or on
commercial sites where I have development responsibility. My thoughts
about it are a matter of record and I've covered why it doesn't work
at great length. So, for me, there is no "Testing" phase at either a
module or system level. There is only "Get the code working"
(Development). The result is a significant saving in time, and it IS
as huge as I might think <G> (I have quantified it over several
projects.) On timeboxed projects (and all mine are) the time saving is
irrelevant; you simply use the time that is available. So the time I
technically "saved", I re-invest in doing another iteration and adding
some lower priority functionality...

> 
> Essentially, OO technology in unarguably a *good* thing, but it always has had a
> few problems with truth in advertising. :)
> 

I don't think it is "unarguable"; and it isn't a "Good Thing" for
EVERYTHING.

The right tool for the job.

Personally, I've never had a problem with telling the truth about
technology and it has got me into a lot of trouble in the course of my
career.<G> Nevertheless, I call 'em like I see 'em...

Pete.


> -Paul
> 
> "Peter E. C. Dashwood" <dashwood@enternet.co.nz> wrote in message news:b3638c46.0406242236.136ca912@posting.google.com...
> > "Howard Brazee" <howard@brazee.net> wrote in message news:<cbenk8$nt2$1@peabody.colorado.edu>...
> > > On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:
> > >
> > > > So, how do you think OO overcomes this objection ?  Why would these
> > > > shops suddenly say: "we won't have to retest all invokers" ?
> > >
> > > A "feature" of OO is that once a shop moves to OO, it is impossible to do the
> > > same rigorous testing that were the earlier standards, so the standards get
> > > changed.
> >
> > I don't think so, Howard.
> >
> > Control of your environment is an administrative function. If you
> > insist that "rigourous testing as prescribed by our existing
> > standards" will be done, then it will be. It certainly isn't made
> > "impossible" by adopting OO, although it may be made "unnecessary".
> >
> > I don't want to argue the case for OO here any more (I'm heartily sick
> > of doing so) but I will say that if you extend your OO Classes into
> > encapsulated components (as I have been doing for some years now) you
> > CAN obviate a large amount of what was previous regression testing.
> >
> > Because components have specific Methods that define their
> > functionality, you can change the functionality of a system by adding
> > new components to it. (In the same way that you might add an extra
> > wall to your house by buying more bricks). Why would you then go and
> > retest all the functions that haven't changed?  Would you stress test
> > all the previously existing bricks in your wall?
> >
> > Well, you might, but the answer is it depends on how confident you are
> > about the wall and the bricks. You certainly don't HAVE to do it.
> >
> > It isn't about testing every "invoker" just as you would every
> > "caller". There are subtle, but important, differences between what is
> > called and what is invoked, but most COBOLLers just lump them together
> > because that is what they understand. "Hey, Ive been using CALL for
> > years, INVOKE has exactly the same syntax, what's the big deal? They
> > must do the same, right?" Wrong.
> >
> > (Just as a hint, and I have no intention of expanding this because it
> > is pointless to do so in this forum, consider what differences it
> > might make (to your system and program design) if you were able to
> > change the internal data of a called module, dynamically, immediately
> > before you called it, WITHOUT changing the interface to it. Change the
> > internal settings so its behaviour changed, set internal flags, give
> > it different initial values?  But don't need to recompile everything
> > that calls it, because the interface to it is exactly the same and the
> > functionality is exactly the same.  Code that invoked it without
> > changing its properties will work exactly as it always has; new code
> > will cause it to behave differently. It still takes the same
> > parameters through the USING clause, but its behaviour is different
> > when it is called by some callers, from when it is called by others...
> > Only new code that needed to change some of the behaviours in it would
> > need to be tested.
> >
> > Would it make generalized and flexible software easier to write? Could
> > you have fewer, more "general-purpose" modules? Do you find this idea
> > exciting or do you find it frightening? Invoked objects CAN do that;
> > called modules can't.)
> >
> > You CAN create "system building blocks" that do more than called COBOL
> > modules ever could, you CAN deploy these blocks into responsive,
> > easily maintained, reusable, application functionality, and if you do,
> > you DON'T need to do all the rigourous regression testing that is
> > standard practice for most installations.
> >
> > But there is nothing to stop you from continuing to do it if that
> > makes you feel better.
> >
> > Pete.
0
dashwood1 (2140)
6/28/2004 2:14:42 AM
LOL! Comments below..

"Peter E. C. Dashwood" <dashwood@enternet.co.nz> wrote in message
news:b3638c46.0406271814.45bc2775@posting.google.com...
> "Paul Raulerson" <pkraulerson@verizon.net> wrote in message
news:<YfhDc.2740$x9.1348@nwrddc02.gnilink.net>...
> > One thing about your ideas; *anytime* a module's internals change, you
run a very
> > real risk of introducing some form of unexpected behavior, anything from
a performance
> > hit to the thing just rolling over and dying.
>
> Performance hits I stopped worrying about 25 years ago (obviously, I
> don't write code that is deliberately inefficient, and I have a
> lifetime of considering how what I'm writing will impact the platform
> I'm writing it for, but I don't WORRY about it and it would be low
> down on my design criteria.
>
> I have NEVER had code modified by me "roll over and die". The day that
> happens, I'll take up truck driving...<G>
>

You've never every had a production module/class/package you wrote crater?
Wow - first person I've ever met that never had *that* happen to 'em.
<grin>

> Now to serious discussion...
>
> I haven't changed the internals. That's the whole point. I changed the
> PROPERTIES, which are simply data. This causes a behavioural change,
> but that "possibility" has always been in the code and was tested and
> debugged when it was written. There may also be "dormant" methods in
> the component that haven't needed to be activated yet. That's because,
> when it was designed it was designed to be comprehensive, but our
> application hasn't go to the stage of needing some of the
> possibilities yet.
>
> This is why the approach is completely different. Design is not based
> on a series of procedures to meet current requirements. Instead it is
> based on "modelling" or simulating the behaviour of things in the real
> world.
>

All software is based upon that, procedures are simply one model used to
do so. Action/Event Ask/Tell models achieve the same results, and at the
lowest level, wind up being implemented by some form of procedural
process. We don'thave tri-logic machines or quantum computers yet.
At least, I don't think we do... ;)


> Individual objects are examined and all of their possible behaviours
> are considered. (Obviously, you can't ALWAYS get ALL of the
> possibilities, but it is real fun trying, and you design things so
> that they are generalised (But dynamically modifiable)solutions. On
> the other hand, sometimes you CAN identify all possible behaviours
> fairly easily; A file or database handling component, for instance. As
> long as it can ADD, CHANGE, DELETE, and FETCH data, there are unlikely
> to be other requirements for it. (You COULD add maintenance functions
> like CREATE, LOAD, and UNLOAD to it, but I wouldn't do this... It
> comes down to the criteria you use for your CBD).
>
> >
> > So basically, what time you would have spent before in integration
testing is now
> > dedicated to module level testing. There is usually a slight net gain
realized, but
> > it is nothing near as huge as one might think.
>
> At what point did we drop integration testing? I integration test new
> components as they come off the assembly line and I integration test
> newly activated behaviour in existing components. What I don't do, is
> regression test behaviours that have not changed.
>

Your right, I tend to consider integration and regression testing pretty
much
as the same thing, even though they are not. Within the limits of what is
affected
by a module, integration testing does however, involve 'regression' testing
of
the affected modules. At least it does in any shop I run. YMMV, and that
assumption on my part does not make what I actually said right, but I
figured
I would explain it anyway.

> Besides, I use a development methodology that spreads testing into the
> development phase (there is no separate "Testing" phase) and things
> are tested as they are written.
>
> I do not use the "Waterfall" for either my personal stuff  or on
> commercial sites where I have development responsibility. My thoughts
> about it are a matter of record and I've covered why it doesn't work
> at great length. So, for me, there is no "Testing" phase at either a
> module or system level. There is only "Get the code working"
> (Development). The result is a significant saving in time, and it IS
> as huge as I might think <G> (I have quantified it over several
> projects.) On timeboxed projects (and all mine are) the time saving is
> irrelevant; you simply use the time that is available. So the time I
> technically "saved", I re-invest in doing another iteration and adding
> some lower priority functionality...
>

So you use some kind of iterative or refactoring technique? Those are nice,
but I find them difficult indeed to hold to any kind of schedule. That is,
of
course, due to the classic weakness involved in any iterative development
methodology, which is correctly detecting when the thing meets the
requirements
closely enough to be declared 'finished.' (I often find I have to spend time
cheering
up depressed programmers at that point, because in their point of view, it
aint'
finished until it is perfect. In my point of view of course, it isn't
finished until we
have been paid for it. The two viewpoints can often conflict. :)



> >
> > Essentially, OO technology in unarguably a *good* thing, but it always
has had a
> > few problems with truth in advertising. :)
> >
>
> I don't think it is "unarguable"; and it isn't a "Good Thing" for
> EVERYTHING.
>

The technology, or more accurately, the design methodology is. Heck it is
even
good for dealing with non-computer everyday issues. OO programming is NOT
indicated or even right for every job, as you point out.

> The right tool for the job.
>
> Personally, I've never had a problem with telling the truth about
> technology and it has got me into a lot of trouble in the course of my
> career.<G> Nevertheless, I call 'em like I see 'em...
>

<grin> I empathize with you on that. I've left several jobs because I
couldn't stomache
telling lies (or near lies) just to handle the politics. I make it a point
to work for companies
owned and ran by engineers whenever possible. It is MUCH better to have the
engineers hire the accountants than vice versa!


> Pete.
>
>
> > -Paul
> >
> > "Peter E. C. Dashwood" <dashwood@enternet.co.nz> wrote in message
news:b3638c46.0406242236.136ca912@posting.google.com...
> > > "Howard Brazee" <howard@brazee.net> wrote in message
news:<cbenk8$nt2$1@peabody.colorado.edu>...
> > > > On 24-Jun-2004, riplin@Azonic.co.nz (Richard) wrote:
> > > >
> > > > > So, how do you think OO overcomes this objection ?  Why would
these
> > > > > shops suddenly say: "we won't have to retest all invokers" ?
> > > >
> > > > A "feature" of OO is that once a shop moves to OO, it is impossible
to do the
> > > > same rigorous testing that were the earlier standards, so the
standards get
> > > > changed.
> > >
> > > I don't think so, Howard.
> > >
> > > Control of your environment is an administrative function. If you
> > > insist that "rigourous testing as prescribed by our existing
> > > standards" will be done, then it will be. It certainly isn't made
> > > "impossible" by adopting OO, although it may be made "unnecessary".
> > >
> > > I don't want to argue the case for OO here any more (I'm heartily sick
> > > of doing so) but I will say that if you extend your OO Classes into
> > > encapsulated components (as I have been doing for some years now) you
> > > CAN obviate a large amount of what was previous regression testing.
> > >
> > > Because components have specific Methods that define their
> > > functionality, you can change the functionality of a system by adding
> > > new components to it. (In the same way that you might add an extra
> > > wall to your house by buying more bricks). Why would you then go and
> > > retest all the functions that haven't changed?  Would you stress test
> > > all the previously existing bricks in your wall?
> > >
> > > Well, you might, but the answer is it depends on how confident you are
> > > about the wall and the bricks. You certainly don't HAVE to do it.
> > >
> > > It isn't about testing every "invoker" just as you would every
> > > "caller". There are subtle, but important, differences between what is
> > > called and what is invoked, but most COBOLLers just lump them together
> > > because that is what they understand. "Hey, Ive been using CALL for
> > > years, INVOKE has exactly the same syntax, what's the big deal? They
> > > must do the same, right?" Wrong.
> > >
> > > (Just as a hint, and I have no intention of expanding this because it
> > > is pointless to do so in this forum, consider what differences it
> > > might make (to your system and program design) if you were able to
> > > change the internal data of a called module, dynamically, immediately
> > > before you called it, WITHOUT changing the interface to it. Change the
> > > internal settings so its behaviour changed, set internal flags, give
> > > it different initial values?  But don't need to recompile everything
> > > that calls it, because the interface to it is exactly the same and the
> > > functionality is exactly the same.  Code that invoked it without
> > > changing its properties will work exactly as it always has; new code
> > > will cause it to behave differently. It still takes the same
> > > parameters through the USING clause, but its behaviour is different
> > > when it is called by some callers, from when it is called by others...
> > > Only new code that needed to change some of the behaviours in it would
> > > need to be tested.
> > >
> > > Would it make generalized and flexible software easier to write? Could
> > > you have fewer, more "general-purpose" modules? Do you find this idea
> > > exciting or do you find it frightening? Invoked objects CAN do that;
> > > called modules can't.)
> > >
> > > You CAN create "system building blocks" that do more than called COBOL
> > > modules ever could, you CAN deploy these blocks into responsive,
> > > easily maintained, reusable, application functionality, and if you do,
> > > you DON'T need to do all the rigourous regression testing that is
> > > standard practice for most installations.
> > >
> > > But there is nothing to stop you from continuing to do it if that
> > > makes you feel better.
> > >
> > > Pete.


0
6/28/2004 2:28:45 AM
PAUL RAULERSON <pkraulerson@verizon.net> wrote in message
news:Y%CDc.9500$x9.3479@nwrddc01.gnilink.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:10dti4sdjjmmuc6@corp.supernews.com...
[snip]
> > To understand OO Design it is necessary to study the Booch
> > method (or one of the others) for partitioning an application
> > and the means used for documenting the design. Only then
> > may one know what it means to 'go with OO [design]'. Then
> > one may resume one's code-and-fix programming with ad hoc
> > design in the spirit of OO Design.
> >
>
> Well, yes. LVM/OOD, though 'out of date' is my favorite and well used
> approach.

I don't remember the source; but about ten years ago there
were, as I recall, about ten different methods for OO design.



0
ricksmith (875)
6/28/2004 2:42:30 AM
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-1F0865.23493123062004@corp.supernews.com...

> Does the Unisys compiler support embedding the source in the executable?

None of the Unisys MCP compilers (any language) do so, and I'd contend that
such a feature would present some problems in that environment, in which
COPY is frequently used.  Are the statements included via COPY to be
included in the object code as well, or is the user expected to presume the
presence of the library files after the main source has been reconstructed?
If they're included, is it before or after any REPLACING statements have
been applied?   What about DMSII data bases?  ADDS repositories?

>I just think it's a neat option...

After some reflection, I feel obligated to quote my sainted mother:  "A good
idea, but not very much", at least for the environment with which I'm most
familiar! ;-)     Too many "gotchas".

    -Chuck Stevens


0
6/28/2004 4:22:48 PM
Chuck,

How would you reply, if the specifications said, a. only when copy is 
NOT used; or if it said, the source would be the same as the compiler
generated from; or if copy were made obsolete?  Other methods might
be possible. And yes, current implementations would all probably have
to be impacted in some way. Yet, it seems the input to the compiler
in all cases has to include the resulting source code.

Warren Simmons
Oh, and what about the potential savings when the source is not 
available, but the data file is? WS.


Chuck Stevens wrote:
> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
> news:joe_zitzelberger-1F0865.23493123062004@corp.supernews.com...
> 
> 
>>Does the Unisys compiler support embedding the source in the executable?
> 
> 
> None of the Unisys MCP compilers (any language) do so, and I'd contend that
> such a feature would present some problems in that environment, in which
> COPY is frequently used.  Are the statements included via COPY to be
> included in the object code as well, or is the user expected to presume the
> presence of the library files after the main source has been reconstructed?
> If they're included, is it before or after any REPLACING statements have
> been applied?   What about DMSII data bases?  ADDS repositories?
> 
> 
>>I just think it's a neat option...
> 
> 
> After some reflection, I feel obligated to quote my sainted mother:  "A good
> idea, but not very much", at least for the environment with which I'm most
> familiar! ;-)     Too many "gotchas".
> 
>     -Chuck Stevens
> 
> 
0
wsimmons5 (172)
6/28/2004 7:42:54 PM
Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:


>Does the Unisys compiler support embedding the source in the executable?  
>MicroFocus?  Any others?

Micro Focus -- no.
AcuCobol -- yes, with appropriate debugger option.
AS/400 -- kinda, stores enough so that source can be recreated.
0
6/28/2004 9:39:46 PM
..    Am  23.06.04
schrieb  joe_zitzelberger@nospam.com (Joe Zitzelberger)
    auf  /COMP/LANG/COBOL
     in  joe_zitzelberger-1F0865.23493123062004@corp.supernews.com
  ueber  Re: Method to force keeping of source was Re: Is it possible to use th

JZ> One great way with the IBM line of compilers is to use the TEST
JZ> and/or ADATA options (DOC).  It can include the source as part of the
JZ> load module,

   which is a useful option just for testing and debugging

JZ> and that can later be recoverdd using a utility like
JZ> IDILANGP, or just reading the module for ADATA source lines.

JZ> Does the Unisys compiler support embedding the source in the
JZ> executable? MicroFocus?  Any others?

   The question is posed in an awkward way, I'm afraid.

   The question is: does the compiler support source level debugging?
I.e., does the system provide means to point to the source line or  
area where an error occured or a breakpoint was set?

   I don't know very much about the Unisys MCP systems (Burroughs  
tradition), but I'm pretty sure that the UCS family of compilers (UCS  
= Universal Compiler System) on the Sperry line (i.e. OS/1100 aka OS/ 
2200, or IX systems) does support source code debugging.


Yours,
L�ko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Es sind nicht die Gener�le und K�nige, die die Geschichte machen,
sondern die breiten Massen des Volkes"                - Nelson Mandela
0
l.willms1 (637)
6/28/2004 11:39:00 PM
In article <cbpgko$2ddj$1@si05.rsvl.unisys.com>,
 "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
> news:joe_zitzelberger-1F0865.23493123062004@corp.supernews.com...
> 
> > Does the Unisys compiler support embedding the source in the executable?
> 
> None of the Unisys MCP compilers (any language) do so, and I'd contend that
> such a feature would present some problems in that environment, in which
> COPY is frequently used.  Are the statements included via COPY to be
> included in the object code as well, or is the user expected to presume the
> presence of the library files after the main source has been reconstructed?
> If they're included, is it before or after any REPLACING statements have
> been applied?   What about DMSII data bases?  ADDS repositories?
> 
> >I just think it's a neat option...
> 
> After some reflection, I feel obligated to quote my sainted mother:  "A good
> idea, but not very much", at least for the environment with which I'm most
> familiar! ;-)     Too many "gotchas".
> 
>     -Chuck Stevens
> 
> 

You get the actual source that was compiled -- after COPY processing.  
The only exception is COPY SUPPRESS, which totally hoses the source 
recovery.
0
6/29/2004 2:57:11 AM
This is pretty simple to do with batch programs, which generally take input
files and create output files and reports.  Those output files and reports
can be compared easily.  With online systems, not so easy (for me anyway).
Frank

>>> Robert Wagner<robert.deletethis@wagner.net> 6/26/2004 5:31:22 PM >>>
Warren Simmons <wsimmons5@optonline.net> wrote:

>For the slow learner, me, please itemize the steps in a negative finding
>regression test.

You run the old system and the new system. You compare their outputs and
find
them identical. 'Negative' means no difference. 


>Robert Wagner wrote:
>
>> "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
>> 
>>> If an object is changed for performance reasons and all 
>>>inputs and outputs are kept the same (exactly), then testing can be 
>>>confined to the object.  If it is changed to accept new inputs leading 
>>>to new outputs or to provide changed outputs, then testing should be 
>>>done to test the effects of the change on most if not all invokers. 
>>>Indeed a running of the entire processing cycle in which the changes 
>>>occur may be necessary. 
>> 
>> 
>> The systems that should not be affected need only a 'negative finding'
>> regression test. That's relatively painless.



0
6/30/2004 8:16:09 PM
There are testing tools that can do the comparison. Not being a tester, I'm not
very knowledgable about them. I've seen them in use, so I know they exist.
They work off scripts that emit keystrokes and mouse clicks, then compare output
screens and report differences. 

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:

>This is pretty simple to do with batch programs, which generally take input
>files and create output files and reports.  Those output files and reports
>can be compared easily.  With online systems, not so easy (for me anyway).
>Frank
>
>>>> Robert Wagner<robert.deletethis@wagner.net> 6/26/2004 5:31:22 PM >>>
>Warren Simmons <wsimmons5@optonline.net> wrote:
>
>>For the slow learner, me, please itemize the steps in a negative finding
>>regression test.
>
>You run the old system and the new system. You compare their outputs and
>find
>them identical. 'Negative' means no difference. 
>
>
>>Robert Wagner wrote:
>>
>>> "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
>>> 
>>>> If an object is changed for performance reasons and all 
>>>>inputs and outputs are kept the same (exactly), then testing can be 
>>>>confined to the object.  If it is changed to accept new inputs leading 
>>>>to new outputs or to provide changed outputs, then testing should be 
>>>>done to test the effects of the change on most if not all invokers. 
>>>>Indeed a running of the entire processing cycle in which the changes 
>>>>occur may be necessary. 
>>> 
>>> 
>>> The systems that should not be affected need only a 'negative finding'
>>> regression test. That's relatively painless.
>
>
>

0
6/30/2004 11:04:48 PM
Reply:

Similar Artilces:

Possible to use mySQL, an open source program with Labview without the use of toolkit, just like we can do with MySQL with Command line.
Hi i am trying to see if I can use sys exe .vi to execute Mysql commands. Is it possible to use without toolkit? &nbsp; regards, Clement This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C5EE8A.A54C8480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Sure, this is possible. But there is a free toolkit for SQL = communications: http://www.jeffreytravis.com/lost/labsql.html Regards, Wiebe. "astroboy" <x@no.email> wrote in message = news:1132540857741-290763@exchange.ni.com... Hi i am tr...

A COBOL program that parses its own source code
Written using Micro Focus COBOL 3.2.50 with extensions, the program includes code for features not used by the program, such as unary plus and minus, hexadecimal literals, etc.; and does not process continuation lines, does not remove inline comments, etc. ----- program-id. lex-scan. environment division. input-output section. select src-file assign to src-name organization line sequential. select token-file assign to "token.txt" organization line sequential. data division. file secti...

A program which would print out it's own source code
Is it possible to write a program which would print out it's own source code, using C++? mikhal80@gmail.com wrote: > Is it possible to write a program which would print out it's own > source code, using C++? Yes. - Jensen On 23 Jan, 11:15, mikha...@gmail.com wrote: > Is it possible to write a program which would print out it's own > source code, using C++? Google "quine". mikhal80@gmail.com wrote: > Is it possible to write a program which would print out it's own > source code, using C++? yes, here is one example for free: On 2008-01-23 10:24:30 -0500, anon <anon@no.no> said: > mikhal80@gmail.com wrote: >> Is it possible to write a program which would print out it's own >> source code, using C++? > > yes, here is one example for free: deep, philosophically... lol. -- -kira Kira Yamato wrote: > On 2008-01-23 10:24:30 -0500, anon <anon@no.no> said: > >> mikhal80@gmail.com wrote: >>> Is it possible to write a program which would print out it's own >>> source code, using C++? >> >> yes, here is one example for free: > > deep, philosophically... lol. It probably is. But my dumb compiler complains that there is no 'main' in my program... V -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask mikhal80@gmail.com writes: > Is it possible to write a...

COBOL source code to create usersnames using SETUAI
Hi, I'm on vms 7.3-1 and need to start testing external authentication from our alpha's with Active directory, probably using something like ldap. I think my first hurdle is to create VMS usernames up to 32 characters long - using $setuai service. Its been a long time since I cut cobol code (cobol is the only compiler we have) and was wondering is some kind soul out there could throw me some code where they have done this before. Thanx, Martin. SETUAI cannot be used to create VMS accounts in SYSUAF. Martin wrote: > Hi, > > I'm on vms 7.3-1 and need to start testing ...

Is it possible to obtain DBMS_SCHEDULER log id from within program being scheduled
Hi. As above, basically what i am trying to do is attach output files to a shceduled program using the DBMS_SCHEDULER package. Within the program being executed i want to output log file and output file information, attached to the Job in the scheduler, so that using the USER_SCHEDULER_JOB_LOG view i can drill into the files produced by the procedure (i am using utl_file to produce these files) being executed. Any help greatly appreciated Cheers, Neil Version Info Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod PL/SQL Release 10.1.0.2.0 - Production CORE 10.1.0.2.0 Prod...

Is it possible to invoke a Unix command within Fortran 90 source code?
Hi, there. I know it is pretty easy to invoke a Unix command within C code, but it seems that no textbook has mentioned to invoke a Unix command within Fortran code. So the question is "is it possible or not?" Thank you in advance! On 7 feb, 12:02, hermitian <iamwu...@gmail.com> wrote: > Hi, there. > > I know it is pretty easy to invoke a Unix command within C code, but > it seems that no textbook has mentioned to invoke a Unix command > within Fortran code. So the question is "is it possible or not?" > > Thank you in advance! Yes, but it dep...

RE: COBOL source code to create usersnames using SETUAI #2
Martin wrote: > I think my first hurdle is to create VMS usernames up to 32 characters > long - using $setuai service. Its been a long time since I cut cobol > code (cobol is the only compiler we have) and was wondering is some > kind soul out there could throw me some code where they have done > this before. While the UAF field for USERNAME is, in fact 32 characters, there are many places within the VMS code that allow for only 12 characters. For example, AUTHORIZE will not allow you to add a username larger that 12 characters. I do believe there are JIB fields that contai...

No content (source code) while using 'window.open' in Mozilla, Opera, Chrome & Safari (source code only visible in IE)
I'd like to offer a print view window which automatically opens the printer window (Ctrl+P) after it has been loaded. Unfortunately the printer window (Ctrl+P) doesn't open automatically. After some troubleshooting I realized that in Mozilla, Opera, Chrome & Safari there is no source code visible of the print view window. In Internet Explorer the source code looks fine and if you save the source code and open the print view page again the printer window (Ctrl +P) opens automatically. What's wrong with my code? Hint: I need to open the print view window in 'print.js' b...

Is it always possible to write a COBOL program using only 1 sentence per paragraph?
I'm trying to write a program that reformats the structure of a given COBOL program. One of the transformations I'd like to apply is to try to eliminate as many periods as possibles, using the END-whatever (END-IF, END-CALL, END-COMPUTE, etc.) constructs. My question is, is it always possible to do this? I don't want to "cheat" by adding new paragraph names at the beginning of every sentence (which may affect PERFORM statements anyway). My theory is that yes, it is always possible, but I haven't been programming in COBOL for that long, so I wasn't ...

Is it possible, when i call a vi from within my code, to pass to it parameters as input and to return some values too?
Hi There! &nbsp; I am currently calling a vi from within my code. However, what i would like to do, is to pass it 2 int values when i call it and for it to return 2 int values when it is done! &nbsp; Any advice on how i can do this please. &nbsp; Thanks. Regards, If you have two controls and two indicators on the subVI, just wire them to the subVI's connector pane. &nbsp;<a href="http://zone.ni.com/devzone/cda/tut/p/id/5199" target="_blank">LabVIEW fundamentals</a> Hi there! &nbsp; Thanks for your reply. I have had it the way you mentio...

use a hash from a module within a main program without passing by reference or value
Hello, i have a module and my program that uses it. i want to use the hash which is only declared in my module within the main program. I want the output to be one two two one but it prints nothing anyone can help me out and teach me the scope of variables when using modules? in other words: how can i make %MYCOOLHASH available in test.pl without passing it by reference or value. thanks in advance Sebastian --- test.pl ------------------ use mycoolmodule; print "$MYCOOLHASH{'test1'}\n"; print "$MYCOOLHASH{'test2'}\n"; &changeValues(); print "$M...

Is it possible to print from ABIO ( DOS program) to a copier-printer that uses an access code?
Hi A friend of mine, accountant, bought a copier-printer and she wants to print her documents from a DOS program, called ABIO. This program uses generic drives and the driver for the copier-printer is not included. She installed the copier-printer driver on her laptop, set the driver as a default printer, and she could print to the copier-printer using a parallel cable. So far so good. As my friend is not the only one in her office using the copier-printer, she wanted to activate the access code for the copier-printer. However, after activating the access code on the copier-printer, and entering the same access code in the driver settings, she cannot print anymore. Is it because none of the generic drivers that comes with ABIO does not support access codes? Can emulation help? -- Thanks Nick The last loser is the first winner "Nick" <psstcenter@shaw.ca> wrote in message news:G4sRe.347070$s54.195650@pd7tw2no... > A friend of mine, accountant, bought a copier-printer and she wants to print > her documents from a DOS program, called ABIO. This program uses generic > drives and the driver for the copier-printer is not included. She installed > the copier-printer driver on her laptop, set the driver as a default > printer, and she could print to the copier-printer using a parallel cable. > So far so good. > > As my friend is not the only one in her office using the copier-printer, she > ...

Source code for the programs in Effective Awk Programming
Is there someplace online that I can get the source for the programs listed in EAP? Or do I have to try to OCR them? -- Genesis 2:7 And the LORD God formed man of the dust of the ground, and breathed into his nostrils the breath of life; and man became a living soul. On 2015-08-01 3:22, Kenny McCormack wrote: > Is there someplace online that I can get the source for the programs listed > in EAP? > You could have a look at: http://git.savannah.gnu.org/cgit/gawk.git/tree/awklib/eg Hermann On 01.08.2015 03:22, Kenny McCormack wrote: > Is there someplace onl...

M code into programming C code or MATLAB programming code
hallo firends, Can any body help me write this below code into MATLAB object oriented or C code form please? M=50; % total number of periods. (choose for 1s duration) f0 = 50; % fundamental AC frequency T0 = 1/f0; %fundamental AC period T = M*T0; %Time for M periods (integer M) N=30; % sample points per period. dt = T0/N; % Sample at N points per period (integer N > 20) t = dt*[1:M*N-1]; % Sampling time array A0=120/2; % amplitude of AC signal. Divide by 2 or maybe sqrt (2) ? AC=A0*sin(f0*t*2*pi); % create AC signal. DC0=50; % DC amplitude DC=DC0*ones(1,length...

Is it possible to embed C++ codes within MATLAB codes?
Hi, I would like to learn if it is possible to run C++ functions on MATLAB. I have written a code on MATLAB however some parts are working too slow. I would like to run those parts using C++ functions and call them in the MATLAB code. I would be very glad if you help me with this problem. Best Regards, -Baran Baran Aydogan wrote: > Hi, > > I would like to learn if it is possible to run C++ functions on > MATLAB. > > I have written a code on MATLAB however some parts are working too > slow. I would like to run those parts using C++ functions and call > them in the...

guys Can you send me the Cobol Program/ Cobol code for this
Guys I need some tips from u r side=20 1. we need to create screen file, data file 2.read the data file in a loop populate it screen files 3. send the screen file & Read the screen file=20 I want this below data come on screen at end & ALSO 1. IT SHOULD BE [KEY BOARD OPERATED]NAVIGATED.not mouse operated 2 NEED TO RUN ON UNIX=20 3. WANT TO ACCESS Thru their [other] Machine thru TELNET=20 Requirement is to showout put=20 --------------------------------------------------------------------- 0123 BRIAN 2200 0124 WAYNE ...

Possible to hide code outside the mdb and use this code?
Hi all, Is it possible to 'hide' code (e.g. in a mde) and to use this in app.mdb? Reason for asking: I have made some of the applications a client (health-care organisation) works with. My applications are usually mde's (Access '97 and up) or secured mdb's (Access 2.0) I want to secure the code and I also don't want clients to be able to 'mess up' applications I made. The organisation also uses 'own' mdb's. They work A LOT with Access. Now they ask me to enhance one of 'their' mdb's. (A2k) They want far more features than they can ac...

To delete a used value from the combobox using SQL code
Hi All Can anybody pls help me out with this problem. I have a combo box control which has about 10,000 values in it. These values in the combo box are called from a different table. When i use a value(1 out of 10000) in the combo box for a particular record say Record1, this value should no longer be displayed for the next new record say Record2 and the combo box should just display only 9999 values. I am trying to do this, just because I do not want the data entry person to use the same combo value for two different records. Is it possible to do this using SQL code? Any help in this regard ...

how to use the design results of the vhdl code for a program in C code
hello, i need help. i work over an algo in C langage that verifies a design described in VHDL for it, i want take all informations from my vhdl code for use them in my programme in C and i don't know how. On Mon, 15 Mar 2010 02:51:22 -0700 (PDT), lolita grenoble <lolita.grenoble@gmail.com> wrote: >hello, >i need help. >i work over an algo in C langage that verifies a design described in >VHDL >for it, i want take all informations from my vhdl code for use them in >my programme in C and i don't know how. One way is to write a file in your VHDL code (running it...

Re: guys Can you send me the Cobol Program/ Cobol code for this
Raju, The HP3000 does not run Unix - its object programs are created for use by its own operating system: MPE-iX. It accepts input from the keyboard in 2 ways: Character-mode (one field at a time transmitted by pressing the 'Return' key), using the COBOL 'ACCEPT' statement or a 'REED' intrinsic - or - Block mode (the entire screen at one time, after the user presses the 'Enter' key), which HP calls a ViewPlus application. Code for the Block mode type of operation is quite complex - there is probably some third-party code which simplifies this...

Possible to run a SAS program within another SAS program?
Hello, I have 9 SAS programs, all within the same Windows folder that I usually run at the same time - one right after the other. For convenience, is it possible to write a simple SAS program that will let me run all the programs at once or to have a program that will allow me to pick and choose which SAS programs I want to run (e.g., in the case I only want to run the first 3 and last program out of the 9 SAS programs) and which order the programs are run in? I guess what I'm really looking for is if there is a way to call another SAS program using only a couple lines of code so that, if ...

Re: Possible to run a SAS program within another SAS program?
Julie, Uhhh create a macro that simply %includes the programs you want and in what order. It would be very specific to you the creator and user, in other words right biw I can't think of a good way to pass al the info you need to the macro from the user. As you can tell the user interface would be the crucial part of this. I personally wouldnt want to have this in my production code but have written SAS programs that do nothing more than %include a list of programs. Toby Dunn From: oseithedude@GMAIL.COM Reply-To: oseithedude@GMAIL.COM To: SAS-L@LISTSERV.UGA.EDU Subject: Possibl...

Using values within arrays within a hash to gsub into an input word...
Hi there, I'm a beginner at Ruby so please bear with me. My question is how can I identify how many values are in an array within my hash? Also, how can I utilize those values separately? Here's what I have so far: mtrules_cons = { 's' => s_sounds = %w[s c sc sch], 'f' => f_sounds = %w[f ph], 'k' => k_sounds = %w[ch c k cch qu], 'z' => z_sounds = %w[z s x], 'ch' => ch_sounds = %w[ch t tch ct], 'zh' => zh_sounds = %w[c ch sc sch sh] } puts mtrules_cons['s'] ....print...

How to access all values within a structur