Cobol - Reset data

Author

Reset data

Mitch Steens

2007-02-26, 3:55 am

Hello,

I have the following datatype:

03 tabelle.
05 occurs 9.
07 occurs 9.
10 elem.
12 elem-a pic 9.
12 elem-b pic 9.

How can I reset the datatype, so that no value is set?

Thanks a lot!

Best regards,

Mitch

Rick Smith

2007-02-26, 3:55 am

"Mitch Steens" <M.Steens@gmx.com> wrote in message
news:45e2a4cb$0$6400$9b4e6d93@newsspool2
.arcor-online.net...
> Hello,
>
> I have the following datatype:
>
> 03 tabelle.
> 05 occurs 9.
> 07 occurs 9.
> 10 elem.
> 12 elem-a pic 9.
> 12 elem-b pic 9.
>
> How can I reset the datatype, so that no value is set?

It depends on what you mean by "no value".

If you want 'elem-a' and 'elem-b' to be reset to zero,
use: INITIALIZE tabelle.

If you want 'elem-a' and 'elem-b' to have invalid values,
use: MOVE SPACES TO tablelle.

Mitch Steens

2007-02-26, 7:55 am

"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:12u5bjm4js8fm24@corp.supernews.com...
>

>
> If you want 'elem-a' and 'elem-b' to be reset to zero,
> use: INITIALIZE tabelle.
>
> If you want 'elem-a' and 'elem-b' to have invalid values,
> use: MOVE SPACES TO tablelle.
>
MOVE SPACES was what i was looking for, thanks a lot Rick!

Donald Tees

2007-02-26, 7:55 am

Mitch Steens wrote:
> Hello,
>
> I have the following datatype:
>
> 03 tabelle.
> 05 occurs 9.
> 07 occurs 9.
> 10 elem.
> 12 elem-a pic 9.
> 12 elem-b pic 9.
>
> How can I reset the datatype, so that no value is set?
>
> Thanks a lot!
>
MOVE ALL ZERO TO TABELLE.

Howard Brazee

2007-02-26, 6:55 pm

On Mon, 26 Feb 2007 10:13:41 +0100, "Mitch Steens" <M.Steens@gmx.com>
wrote:

>I have the following datatype:
>
>03 tabelle.
> 05 occurs 9.
> 07 occurs 9.
> 10 elem.
> 12 elem-a pic 9.
> 12 elem-b pic 9.
>
>How can I reset the datatype, so that no value is set?

What do you mean by "no value". This is space in the computer
memory. Whatever happens to be in memory is a "value", whether or
not if it is a valid value.

One thing I sometimes do in a program with such a table (especially if
some of the variables are packed or binary), is to create an
initialization table. If I need to reinitialize the table, I just
MOVE ZERO-TABLE to TABELLE.

Pete Dashwood

2007-02-27, 9:55 pm

"Donald Tees" <donald_tees@donald-tees.ca> wrote in message
news:erumiv$mgf$1@aioe.org...
> Mitch Steens wrote:
> MOVE ALL ZERO TO TABELLE.

I've never understood why people do this.

Surely the figcon ALL is redundant in the above?

Can you explain this for me please, Donald?

Pete.

Pete Dashwood

2007-02-27, 9:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:chv5u214c3r2strckf1h2r8msh9pv42ne5@
4ax.com...
> On Mon, 26 Feb 2007 10:13:41 +0100, "Mitch Steens" <M.Steens@gmx.com>
> wrote:
>
>
> What do you mean by "no value". This is space in the computer
> memory. Whatever happens to be in memory is a "value", whether or
> not if it is a valid value.
>
> One thing I sometimes do in a program with such a table (especially if
> some of the variables are packed or binary), is to create an
> initialization table. If I need to reinitialize the table, I just
> MOVE ZERO-TABLE to TABELLE.

Again, something I don't understand.

How would the result of doing that (taking twice as much storage as you
actually need, and running the risk of forgetting to update one of the
tables when the structure changes) differ from...

INITIALIZE TABELLE ?

Pete.

Arnold Trembley

2007-02-27, 9:55 pm

Pete Dashwood wrote:

> "Howard Brazee" <howard@brazee.net> wrote in message
> news:chv5u214c3r2strckf1h2r8msh9pv42ne5@
4ax.com...
> (snip)
>
>
> Again, something I don't understand.
>
> How would the result of doing that (taking twice as much storage as you
> actually need, and running the risk of forgetting to update one of the
> tables when the structure changes) differ from...
>
> INITIALIZE TABELLE ?
>
> Pete.

If you are INITIALIZE'ing a structure, the generated code will have an
explicit move for each elementary field. I know it works this way in
Enterprise COBOL for zOS. If you INITIALIZE the same structure in a
loop many times, it can create some performance delays for certain
applications. I will grant you that this kind of optimization is not
typically needed in online applications, but it could be a performance
bottleneck in some cases.

With kindest regards,

--
http://arnold.trembley.home.att.net/

William M. Klein

2007-02-28, 3:55 am

Arnold,
There USED to be performance problems with IBM's INITIALIZE code, but I
thought they fixed most (all?) of them a while ago. Have you run tests with
"recent" versions of Enterprise COBOL that still show performance problems?

--
Bill Klein
wmklein <at> ix.netcom.com
"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:BC6Fh.19799$as2.5112@bgtnsc05-news.ops.worldnet.att.net...
>
>
> Pete Dashwood wrote:
>
>
> If you are INITIALIZE'ing a structure, the generated code will have an
> explicit move for each elementary field. I know it works this way in
> Enterprise COBOL for zOS. If you INITIALIZE the same structure in a loop many
> times, it can create some performance delays for certain applications. I will
> grant you that this kind of optimization is not typically needed in online
> applications, but it could be a performance bottleneck in some cases.
>
> With kindest regards,
>
>
> --
> http://arnold.trembley.home.att.net/
>

William M. Klein

2007-02-28, 3:55 am

Pete,
Although NOT related to this specific example, there was one time that there
USED to be a "good reason" for using
Move Table1 to Tabl
instead of
Initialize Tabl

In the '85 Standard (when INITIALIZE was introduced) it was "non-conforming" to
try to INITIALIZE a record that included an OCCURS DEPENDING ON item in it, i.e.
a "variable occurrence table". Although SOME vendors provided extensions to
allow this, it was not made "legal" source code until the '02 Standard.
Therefore, one could initialize a full table (including various Comp-? fields)
only by "saving" an initial value table and moving it to the target one.

There was also the whole question of whether one did or did not want to
initialize FILLER fields and initialize "to VALUE clause". Again, both of
these were made "standard" in the '02 Standard, but were only available as
extensions in a FEW compilers before that.

Again, for THE specific example, below, using the "MOVE ZERO-TABLE to TABELLE"
seems unnecessary. Also, as all the fields are DISPLAY NUMERIC without SIGNS, I
would guess that a MOVE ZERO should work OK (although I have rarely seen
'real-world' examples where this works as desired).

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:54k41rF20ig9pU1@mid.individual.net...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:chv5u214c3r2strckf1h2r8msh9pv42ne5@
4ax.com...
>
> Again, something I don't understand.
>
> How would the result of doing that (taking twice as much storage as you
> actually need, and running the risk of forgetting to update one of the tables
> when the structure changes) differ from...
>
> INITIALIZE TABELLE ?
>
> Pete.
>

Pete Dashwood

2007-02-28, 3:55 am

"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:BC6Fh.19799$as2.5112@bgtnsc05-news.ops.worldnet.att.net...
>
>
> Pete Dashwood wrote:
>
>
> If you are INITIALIZE'ing a structure, the generated code will have an
> explicit move for each elementary field. I know it works this way in
> Enterprise COBOL for zOS.

Yes, I think it works that way on most platforms.

My question then is: So what?

The art of computer programming (now rapidly becoming a lost art, thanks to
extremely powerful processors and virtual address spaces with almost
unlimited capacity) comes down to balancing space against time. Give a
program more space and it usually runs faster. In this case you are saying
that the size of a second table will be less than all the move statements
required to initialize it, if INITIALIZE is used. So, it is the second table
and a single group move, against the elemental moves required for each
element.

But there is still the question of maintenance and the overall inelegance of
a second table that serves no purpose whatsoever, other than to initialize
the original structure.

Sorry, that doesn't cut it for me...

INITIALIZE gets my vote.

Pete.

Pete Dashwood

2007-02-28, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Pm7Fh.58212$k82.45339@fe07.news.easynews.com...
> Pete,
> Although NOT related to this specific example, there was one time that
> there USED to be a "good reason" for using
> Move Table1 to Tabl
> instead of
> Initialize Tabl
>
> In the '85 Standard (when INITIALIZE was introduced) it was
> "non-conforming" to try to INITIALIZE a record that included an OCCURS
> DEPENDING ON item in it, i.e. a "variable occurrence table". Although
> SOME vendors provided extensions to allow this, it was not made "legal"
> source code until the '02 Standard. Therefore, one could initialize a full
> table (including various Comp-? fields) only by "saving" an initial value
> table and moving it to the target one.
>
> There was also the whole question of whether one did or did not want to
> initialize FILLER fields and initialize "to VALUE clause". Again, both
> of these were made "standard" in the '02 Standard, but were only available
> as extensions in a FEW compilers before that.
>
> Again, for THE specific example, below, using the "MOVE ZERO-TABLE to
> TABELLE" seems unnecessary. Also, as all the fields are DISPLAY NUMERIC
> without SIGNS, I would guess that a MOVE ZERO should work OK (although I
> have rarely seen 'real-world' examples where this works as desired).
>

Thanks Bill.

Appreciate the background.

My position is unchanged :-)

Pete.

Donald Tees

2007-02-28, 7:55 am

Pete Dashwood wrote:
> "Donald Tees" <donald_tees@donald-tees.ca> wrote in message
> news:erumiv$mgf$1@aioe.org...
>
> I've never understood why people do this.
>
> Surely the figcon ALL is redundant in the above?
>
> Can you explain this for me please, Donald?
>
> Pete.
>

Sure. I use the "all" to differentiate between a single value being
used for a single parameter and a series of ASCII characters being moved
to sub-fields at the source level so I do not have to go back and check
the format of the receiving field.

Donald

Rick Smith

2007-02-28, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:54ktfkF208kl3U1@mid.individual.net...
> "Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
> news:BC6Fh.19799$as2.5112@bgtnsc05-news.ops.worldnet.att.net...
[snip][color=darkred]
[snip][color=darkred]
> In this case you are saying
> that the size of a second table will be less than all the move statements
> required to initialize it, if INITIALIZE is used. So, it is the second
table
> and a single group move, against the elemental moves required for each
> element.

No! No! Size doesn't matter! It's performance that
counts! <g>

Howard Brazee

2007-02-28, 6:55 pm

On Wed, 28 Feb 2007 09:27:29 -0500, "Rick Smith" <ricksmith@mfi.net>
wrote:

>No! No! Size doesn't matter! It's performance that
>counts! <g>

Did your wife tell you that?

Howard Brazee

2007-02-28, 6:55 pm

On Wed, 28 Feb 2007 14:26:16 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>How would the result of doing that (taking twice as much storage as you
>actually need, and running the risk of forgetting to update one of the
>tables when the structure changes) differ from...
>
>INITIALIZE TABELLE ?

We have more control, for instance if your table has redefines,
delimiters (within fillers), or if the initialized data are variable
from run to run (or from copybook program to copybook program). It
can also be used if your table is in the linkage division.

It's also quicker, although that isn't as important these days.

We have initialized database records as well - calc into a record with
a key of space to pull out the standard *empty* database record,
before creating a new one to add. This can be changed on the fly.

Rick Smith

2007-02-28, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:re6bu29mprd7tc3l353ou4l7qc8tk7u85a@
4ax.com...
> On Wed, 28 Feb 2007 09:27:29 -0500, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
>
> Did your wife tell you that?

Not married! Was never married! Will never marry!

Any woman who would have me as a husband;
I could not have as a wife. She clearly would have
a problem with low self-esteem. <g>

HeyBub

2007-02-28, 6:55 pm

Rick Smith wrote:
>
> No! No! Size doesn't matter! It's performance that
> counts! <g>

I hear that a lot.

It's usually followed shortly (no pun intended) thereafter by laughter.

Pete Dashwood

2007-02-28, 6:55 pm

"Donald Tees" <donald_tees@donald-tees.ca> wrote in message
news:es40l4$pr0$1@aioe.org...
> Pete Dashwood wrote:
>
> Sure. I use the "all" to differentiate between a single value being used
> for a single parameter and a series of ASCII characters being moved to
> sub-fields at the source level so I do not have to go back and check the
> format of the receiving field.
>
> Donald

Ah, I see...

Thanks a lot.

Pete.

Pete Dashwood

2007-02-28, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12ub4cmanf14m2a@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:54ktfkF208kl3U1@mid.individual.net...
> [snip]
> [snip]
> table
>
> No! No! Size doesn't matter! It's performance that
> counts! <g>
>

You obviously have a very tactful girlfriend, Rick... :-)

Pete.

Pete Dashwood

2007-02-28, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12ub8hcd3924751@corp.supernews.com...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:re6bu29mprd7tc3l353ou4l7qc8tk7u85a@
4ax.com...
>
> Not married! Was never married! Will never marry!
>
> Any woman who would have me as a husband;
> I could not have as a wife. She clearly would have
> a problem with low self-esteem. <g>
>
>
>
I have to admit to some affinity for this Groucho Marx approach myself.

I've been married twice, to two really nice girls who I probably didn't
deserve. The first marriage was a victim of youth (we both grew out of it)
the second one was doomed from the start and it was amazing it lasted as
long as it did. These days I really enjoy living alone and it gives me
mobility, to go where I want and do what I want when I want. I believe that
the freedom I enjoy would be very hard to compromise on and it would take a
really special person to make me think about doing so (I'm not looking...).
I also honestly believe that such a person (if there was one) would not be
interested in spending her time with me.

I understand very well your disclaimer above, Rick. But I'd be a bit careful
about the last statement of the three...

Life has a habit of throwing extremely unexpected things out of left field.
This randomity alone may be a valid reason for living :-) ("The only reason
I keep on living is to see what the Hell is going to happen next...")

Marriage, whether it turns out good or bad, is a very valuable growth
experience.

Pete.

2007-02-28, 6:55 pm

In article <54mencF20um50U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>Life has a habit of throwing extremely unexpected things out of left field.

Bitter, old man: 'You want to hear God laugh? Tell Him your plans.'

DD

Pete Dashwood

2007-02-28, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:296bu2dqp92gakc6f1m442gegb0tpj35ot@
4ax.com...
> On Wed, 28 Feb 2007 14:26:16 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> We have more control, for instance if your table has redefines,
> delimiters (within fillers), or if the initialized data are variable
> from run to run (or from copybook program to copybook program).

(Following comments are not intended to be taken personally; I am expressing
opinions about code, not people...Fundamental to the following observations,
and taken as read, is the right of COBOL programmers to use whatever
approach they see fit, as long as it complies with local standards and
practises.)

If you are initializing to zero/spaces none of the above makes any
difference. There is no more "control" than if you issued INITIALIZE to do
the job, redefines is irrelevant if the storage is being set to zero or
spaces - it must be one or the other just as it must be if you move another
table to it), anyone who expects fillers to have a value (delimiter, for
instance) simply doesn't understand the use of filler, and if different
initializations are expected for various runs, then that is not a case of
initializing to zero/spaces, which is what we are discussing.

If tables need to be initialized with values OTHER than zero/space there may
be a case for loading the values from a secondary table. Otherwise, I can't
see it. I reckon this is something that has happened through "force of
habit" rather than serious thought about initialization... :-)

> It
> can also be used if your table is in the linkage division.
>

Tables in the linkage SECTION can be referenced by INITIALIZE. (the table in
the calling program will be initialized according to its definition in the
linkage section. If they don't match there will be problems, but there
usually will be anyway if they don't match.

> It's also quicker, although that isn't as important these days.
>
That depends entirely on the structure and the platform it is running on. I
agree it doesn't matter :-)

> We have initialized database records as well - calc into a record with
> a key of space to pull out the standard *empty* database record,
> before creating a new one to add. This can be changed on the fly.

No comment... :-)

In the example given, which was the basis for this discussion, I can't see
how a secondary table improves anything.

Furthermore, I can't see a case for using a secondary table in ANY case
where the initial state is required to be "empty" (zero/spaces).

Having said all of that, it is interesting to see some of the ways in which
people approach problems. Often, solutions that were intended to be
"temporary" (perhaps while experiencing problems with a particular COBOL
construct) just become habitual and are not reviewed.

Sometimes approaches are based on flawed understanding. I'm sure I'm not the
only one who has been exposed to sites where certain standards are based on
"urban myth"...

I guess it doesn't really matter, as long as processing is achieved and
there are minimal headaches in achieving it...

Pete.

Pete Dashwood

2007-02-28, 6:55 pm

<docdwarf@panix.com> wrote in message news:es521r$dqd$1@reader2.panix.com...
> In article <54mencF20um50U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>
> Bitter, old man: 'You want to hear God laugh? Tell Him your plans.'
>
> DD
>
Exactly :-)

That's why I avoid making them. I have evolved a "Just In Time" approach
that is designed to keep options open for as long as possible.

(We can all learn much from a study of Quantum Physics :-) Am I any less
valuable than a photon?)

For example, as April approaches, many of my friends are asking: "Are you
staying for theWinter or going back to Europe?"

When I tell them I honestly don't know, and won't make any decision before
end of April (unless something completely unforeseen comes up... like
winning the lottery or being offered a job I simply can't refuse...), they
walk away bewildered at how someone can live a life without plans... (When
your only real responsibility is to yourself, it's actually pretty easy...)

For me, life without randomity would be insufferable.

But I also realise that isn't so for everybody :-)

Pete.

HeyBub

2007-02-28, 9:55 pm

X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-RFC2646: Format=Flowed; Response
X-Complaints-To: abuse@supernews.com
Lines: 9
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:163282

Pete Dashwood wrote:
>
> That's why I avoid making them. I have evolved a "Just In Time"
> approach that is designed to keep options open for as long as
> possible.

If you wait until the last minute, the project only takes a minute.

Pete Dashwood

2007-02-28, 9:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12ucfr1svci612d@news.supernews.com...
> Pete Dashwood wrote:
>
> If you wait until the last minute, the project only takes a minute.
>
yep...even less if you hurry... :-)

(Not that anyone hurries in Texas...)

We get "King of the Hill" here... :-)

(I realise that is entirely unfair; I wouldn't want people to form their
impressions of New Zealand from our "BroTown" strip, even though bits of it
are right on the money...However, I have enjoyed several visits to Texas so
I like to think my view is balanced by actual experience :-))

My favourite episodes so far, the "assigned seats" in church, and the one
where they all jump off the boat in the Gulf of Mexico and can't get back
on...:-)

Four rednecks in an alley, drinking beer and doing their best to deal with
the changes being imposed on them by "Modern Living"... Great stuff!

Pete.

Howard Brazee

2007-03-01, 6:55 pm

On Thu, 1 Mar 2007 12:13:08 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>In the example given, which was the basis for this discussion, I can't see
>how a secondary table improves anything.

It was just part of the discussion.

>Furthermore, I can't see a case for using a secondary table in ANY case
>where the initial state is required to be "empty" (zero/spaces).

With the initialize command available, I agree with you here. But
I've had quite a few cases where the desired initialization values
were otherwise - sometimes even variable.

HeyBub

2007-03-01, 6:55 pm

Pete Dashwood wrote:
> (I realise that is entirely unfair; I wouldn't want people to form
> their impressions of New Zealand from our "BroTown" strip, even
> though bits of it are right on the money...However, I have enjoyed
> several visits to Texas so I like to think my view is balanced by
> actual experience :-))

My impressions of New Zealand have been formed by Lord of the Rings. Please
don't think Texas is the only place with weird characters. At least we don't
have Nazguls (nor vampires, but the latter has more to do with the abundance
of Bowie Knives than anything else).

>
> My favourite episodes so far, the "assigned seats" in church, and the
> one where they all jump off the boat in the Gulf of Mexico and can't
> get back on...:-)

Assigned seats in church is an old English tradition.

Pete Dashwood

2007-03-01, 6:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12uefpr45gcujb3@news.supernews.com...
> Pete Dashwood wrote:
>
> My impressions of New Zealand have been formed by Lord of the Rings.
> Please don't think Texas is the only place with weird characters. At least
> we don't have Nazguls (nor vampires, but the latter has more to do with
> the abundance of Bowie Knives than anything else).
>

I visited the main LOTR site (there are many of them scattered throughout
both main islands) which is 40 minutes drive from where I'm writing this. It
(The Shire and Hobbiton) was a fantastic experience, even if you're not a
great LOTR fan. You can sit on the bench outside Bag End where Bilbo and
Gandalf smoked weed and, as far as you can see there is no sign of anything
man made. It's very relaxing (even without the weed :-))

I didn't meet any weird people in Texas, but I sure met some characters :-)

The success of LOTR is a bit of a worry. Since then, millions of people know
we exist and are coming here to visit... Previously we had a nice little
South Pacific paradise that had a very low profile unless you were into
Rugby, wool, butter, or lamb. (Some Rugby players are into all of the
above... :-))

Now we are becoming a 21st Century society with a very diverse culture and
new-fangled nonsenses like HDTV just around the corner... (Why would you
want to see crap, clearer...?)

>
> Assigned seats in church is an old English tradition.

Yes, it is a remnant of a hierarchical Classed Society.

Next time I'm in Texas I'll pick up a genuine Bowie knife for Vampire
defence... (Can you imagine getting THAT through Customs :-)).

Pete.

Richard

2007-03-02, 3:55 am

On Mar 2, 10:01 am, "HeyBub" <heybubNOS...@gmail.com> wrote:
> Pete Dashwood wrote:
>
> My impressions of New Zealand have been formed by Lord of the Rings. Please
> don't think Texas is the only place with weird characters. At least we don't
> have Nazguls (nor vampires, but the latter has more to do with the abundance
> of Bowie Knives than anything else).
>
>
>
>
> Assigned seats in church is an old English tradition.

I recall going into the church by the abbey (ruins) in Whitby.
Apparently this was used as the pattern for making the set in the film
'Moby Dick'. Apart from having a seating gallery on each side above
the side aisle, the main pews were in family cubicles. Each cubicle
was walled about 5 feet high no roof, and a door with the family
name. From inside one could see the preacher in the pulpit but not
the others while seated or kneeling.

Apparently this was quite common, there was at least one like that in
York.

Not that I am in the habit of visiting churches except for the
architecture, and I prefer the ones that have fallen down, such as
Fountains and Reveaux. The one in Havelock North is quite nice and the
custodian will let you photograph the stained glass even the ones
behind the altar.

(photos available on request)

Howard Brazee

2007-03-02, 6:55 pm

On Fri, 2 Mar 2007 12:39:03 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>The success of LOTR is a bit of a worry. Since then, millions of people know
>we exist and are coming here to visit... Previously we had a nice little
>South Pacific paradise that had a very low profile unless you were into
>Rugby, wool, butter, or lamb. (Some Rugby players are into all of the
>above... :-))

Most people who watched LOTR have no idea where it was filmed. Those
with interest enough in the geography - already had that interest and
weren't entirely ignorant about your country.

Frank Swarbrick

2007-03-03, 3:55 am

Pete Dashwood<dashwood@removethis.enternet.co.nz> 02/28/07 4:48 PM >>>
>
><docdwarf@panix.com> wrote in message
news:es521r$dqd$1@reader2.panix.com...
>Exactly :-)
>
>That's why I avoid making them. I have evolved a "Just In Time" approach
>that is designed to keep options open for as long as possible.
>
>(We can all learn much from a study of Quantum Physics :-) Am I any less
>valuable than a photon?)
>
>For example, as April approaches, many of my friends are asking: "Are you
>staying for theWinter or going back to Europe?"
>
>When I tell them I honestly don't know, and won't make any decision before

>end of April (unless something completely unforeseen comes up... like
>winning the lottery or being offered a job I simply can't refuse...), they

>walk away bewildered at how someone can live a life without plans... (When

>your only real responsibility is to yourself, it's actually pretty
easy...)
>
>For me, life without randomity would be insufferable.
>
>But I also realise that isn't so for everybody :-)

How come that doesn't work when my boss asks me for a time estimate? "I'll
let you know once it's done".
Just doesn't work!

:-)

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Pete Dashwood

2007-03-03, 7:55 am

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:54s1j2F21k6ueU2@mid.individual.net...
> Pete Dashwood<dashwood@removethis.enternet.co.nz> 02/28/07 4:48 PM >>>
> news:es521r$dqd$1@reader2.panix.com...
>
>
>
> easy...)
>
> How come that doesn't work when my boss asks me for a time estimate?
> "I'll
> let you know once it's done".
> Just doesn't work!
>
> :-)
>
> Frank
>

It's painfully apparent that you need a more amenable Boss, Frank.... :-)

I find that the guy I work for is pretty reasonable and we agree on most
things...:-)

Pete (Self employed for 30 years now...)

Robert Jones

2007-03-03, 6:55 pm

On Mar 1, 3:25 pm, Howard Brazee <how...@brazee.net> wrote:
> On Thu, 1 Mar 2007 12:13:08 +1300, "Pete Dashwood"
>
> <dashw...@removethis.enternet.co.nz> wrote:
>
> It was just part of the discussion.
>
>
> With the initialize command available, I agree with you here. But
> I've had quite a few cases where the desired initialization values
> were otherwise - sometimes even variable.

I sometimes used a secondary table, or even just an elementary item.
Although it takes more space, some initialisations can be quite
complex. If one moves the top level data name for the table, above
the occurs to another field, it is an alphanumeric move and the other
field doesn't need the table structure defined subordinate to it. To
repeat the initialisation, one can then just move the second field
back to the first as another alphanumeric move. All one has to do is
ensure that the lengths are permanently correct (even after
maintenance), which can be done if desired with a LENGTH function,
which further has the benefit of being discarded by the compiler for a
fixed length table as when correct it will always be true.

Howard Brazee

2007-03-05, 6:55 pm

On 3 Mar 2007 13:28:13 -0800, "Robert Jones" <rjones0@hotmail.com>
wrote:

>All one has to do is
>ensure that the lengths are permanently correct (even after
>maintenance), which can be done if desired with a LENGTH function,
>which further has the benefit of being discarded by the compiler for a
>fixed length table as when correct it will always be true.

I have some programs where the first thing they do is check the
lengths of the copybook members. Better safe than sorry.

Sponsored Links