Re: Infinite Loops and Explicit Exits
From: Pete Dashwood (dashwood_at_enternet.co.nz)
Date: 12/06/04
- Next message: Lueko Willms: "Re: Program templates as Object Classes"
- Previous message: Pete Dashwood: "Re: Infinite Loops and Explicit Exits"
- In reply to: Robert Wagner: "Re: Infinite Loops and Explicit Exits"
- Next in thread: Robert Wagner: "Re: Infinite Loops and Explicit Exits"
- Reply: Robert Wagner: "Re: Infinite Loops and Explicit Exits"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 6 Dec 2004 23:10:03 +1300
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:g237r0hcilmnrmsqhi94i57up4ov2b9cjp@4ax.com...
> On Mon, 6 Dec 2004 01:41:27 +1300, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> >Sections are NOT disguised PERFORM...THRUs whether they are performed or
> >not.
> >
> >PERFORM ...THRU delineates an explicit range of paragraphs within the
scope
> >of the refencing perform.
>
> The PERFORM ... THRU we're discussing looks like this:
>
> PERFORM some-paragraph
> THRU some-paragraph-exit.
>
> some-paragraph.
> ....
> some-paragraph-exit.
> exit.
>
OK, so what exactly is your point?
> >A SECTION that is performed is an IMPLICIT range of paragraphs, within
the
> >scope of the referencing perform.
> >
As you demonstrated above.
> >However, there is a severe difference between the use of PERFORM..THRU
and
> >the use of PERFORM... SECTION.
> >
> >Without arguing the value (or otherwise) of paragraphs (more importantly,
> >labels), within SECTIONS,
>
> What are interior paragraphs used for? They are either GO TO targets
> or comments. Assuming the latter, comment lines would be clearer
> because they don't give the false impression they're being used for
> something else.
>
No Robert, I specifically said I wouldn't argue the use of paragraphs within
sections. So you immediately go and do so. It is a separate issue, it has
been discussed here many times and I'm not commenting on it.
> > it is certainly true that SECTION can adequately
> >describe (and document as a descriptive header) a piece of related,
> >contiguous code, that implements a given function.
>
> A flower-boxed comment works better. It's not limited to 30
> characters.
>
Neither is a flower boxed comment referenceable from somewhere else in the
program.
Perform calculate-pay
(it is a fair bet to any English speaking programmer that THIS section will
calculate how much someone should be paid. There is no requirement to go and
lookup a flower boxed comment somewhere down the bottom of the program...
that would be the comment that was never updated when the paragraph was
changed... <G>)
....
*=========================
calculate-pay section.
*>
*> This section sets the current pay field in WS to contain what we owe
*> the current employee for this pay period
*>
get-hours-worked.
yad yada yada
get-current-rate.
yada yada yada
cp-exit.
exit.
*> Yes, Robert, the exit is extraneous... at least it is this week. (And I'm
not discussing it further <G>)
*===============================
Later we decide there are more possible rates and the hours processing needs
changing to cater for part hours on the different rates. We add more
paragraphs. No change to the referencing performs in the main program.
Note that if this was an Object Method (and I wrote it) it would contain
Properties (PUBLIC) for the employee ID and the current pay field. All the
other fields it needed (derived database access keys, foreign keys,
relations, tables, semapores, calc fields, etc.) would be PRIVATE. It is a
black box where you simply give it the employee you want paid and it returns
the amount to pay him. All of his various rates would be accessed from
databases, along with the hours or part hours for each rate. Tax and
deductions, FICA, pension fund, whatever, would all be found on databases
and manipulated by this one Object Method using rules based processing,
implemented by soft rules, that can be changed outside the object.
The Class that this Method is part of might also include some other methods;
that is beyond the scope of what I'm trying to illustrate here.
I would not expect to ever maintain this code again, once it was written,
and, as the interface to it would never change either (linkage was not used
to pass data in and out), there would be no impact on code that invokes it
if other innate features of it were activated later.
In effect, the whole payroll system would be dependent on proper database
design. The behaviour could only be changed by changing the database. I
believe that is a good thing.
In fact, I am coming to the conclusion that there may be a good case for
designing proper databases and using stored procedures on them, to implement
the system, with virtually NO application code at all. The team I last
managed tried to persuade me in this direction, and they were very clever
people who had spent their whole professional lives working on this kind of
technology for COMPAQ. Guys in their 30s with 15 years experience, all on
Database driven systems <G>. For COBOL this is not a good solution and I
still believe that embedded SQL should see the DB as purely a repository.
with no application code embedded in the database. But OO solutions may well
use things that COBOL is not good with, and there could be a case for
Extended SQL stored procedures and triggers, in conjunction with transaction
processing, and no COBOL (or ONLY minimal OO COBOL...)
Pete.
- Next message: Lueko Willms: "Re: Program templates as Object Classes"
- Previous message: Pete Dashwood: "Re: Infinite Loops and Explicit Exits"
- In reply to: Robert Wagner: "Re: Infinite Loops and Explicit Exits"
- Next in thread: Robert Wagner: "Re: Infinite Loops and Explicit Exits"
- Reply: Robert Wagner: "Re: Infinite Loops and Explicit Exits"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
