Cobol - COBOL - still a place for it...

Author

COBOL - still a place for it...

Pete Dashwood

2006-07-29, 3:55 am

I have watched but (so far) refrained from joining the debate about OO
Collections and whether they should be an intrinsic part of the COBOL
language. (I have no such reservations about XML, and my views on including
this in COBOL are a matter of record.).

My own feeling is that if the COBOL community had embraced OO 10 years ago,
and the price of compilers had been lower, COBOL could have been a
'mainline' OO development language and, instead of COBOL playing a pitiful
'catch up' to established languages with established libraries, the other
languages would be trying to accommodate the COBOL libraries which would, by
now, have made a name for themselves as reliable and robust... But that is
all speculation, and debatable, and of little value, and this is not the
thread for it...

For some time now I haven't written any COBOL (not even for fun) and, to be
honest, I didn't expect to have to write any more in connection with
commercial applications.

But sometimes Fate has surprises in store and we never quite know what is
around the corner...

My team had a requirement to get information from the New Zealand Post
Office lists of addresses and post codes.

As I don't want to have busy, bright young people doing work that a monkey
could do, I told them I would get the NZPO stuff myself. Being a manager, I
am ideally qualified for monkey work :-)

Up until this year these address lists were provided on Excel spreadsheets
for download into local systems. Now the NZPO has realised it is becoming
redundant, and, in a frantic effort to re-invent itself and generate
revenue, it has decided that it will produce a comprehensive postal data
file called the PAF (Postal Address File... you can see what an imaginative
lot they are :-)). The PAF is yours for a very modest (remember this
information used to be free...) $3000 (includes regular updates) and it will
include what are termed 'drop point IDs', an 8 character identifier which
uniquely identifies every mail box in the country (even in blocks of
apartments), as well as street address, locality, region and normal postcode
(4 digits, which, up until recently no-one ever used, as its main purpose
was to get discounts for bulk mailing by pre-sorting mailouts on postcode,
thereby making less work for the Post Office.)

In conjunction with this, a multi-million dollar campaign has been launched
to make people aware of their postcodes (but not their drop point ID because
only people or organizations with the PAF will know what those are...).
Unfortunately (or not, depending on how you look at it), they are taking
this opportunity to completely revise all the postcodes and localities, so
every commercial organisation in the land will need to update and revalidate
their existing filed addresses... Usually, the postcodes are similar, but
different, if you catch my drift... e.g. my 'old' post code was '3001'; my
new one is '3110'...

, huh? :-)

Now, although the organisation I work for can easily afford to buy the PAF
(and probably will) it just makes me smart that they virtually HAVE to. So I
decided to get the same information we have always had for free (which gives
us everything except the drop point id), for free, just like always... :-)
(Besides, I may want this data for my own purposes and I am certainly not
paying for the PAF unless it is commercially viable).

Although the XL spreadsheets that used to have street, locality, city, and
postcode are no longer available (and now rendered redundant by the new
changes to postcodes and localities), the NZPO DOES provide downloadable
..PDF files which are, in effect, PostCode directories for the country. These
are available by region or in a single global .PDF. So, it should be
possible to get this and build a local database from it.

Enter COBOL. (Anybody tried reading a .PDF from COBOL? If you have, well
done. I decided to convert it to text as the 'easy' option...:-)) So, I
looked for converter software, found lots of it, but the firewall at work
wouldn't let me download it. I pulled rank and got permissions to get the
stuff, then found that most of it was pathetic and not worth the effort of
downloading. I won't tell you how I solved this, but I did :-)

So, now I have the directory listing in .TXT. Imagine my horror when I find
that the 500 page, 1.6MB, document only has street, locality, and Post Code.
No cities. Phone the PO. After doing the switchboard shuffle for 20 minutes,
get a customer support person and explain the problem. "But Sir, you don't
NEED a city under the new organization... it is unique to street locality,
post code.". So, I go back to my programming Team Lead, shuffle a bit and
avoid looking her directly in the eye, and relay the NZPO offical line, as a
reason why I can't provide City.

She is polite but firm. Our existing software REQUIRES a CITY. Would you
like us to change it? Not a very simple task, unfortunately. It involves
Entity Beans needing to be changed, and that's just for the DB, then there's
the various print solutions all of which need a City...

I tell her I'll get Cities...by hook, or by crook. (Have no idea how'll I do
it, but am now on record as having said I will... I find that raising the
necessity level often prompts previously unimagined solutions... :-))

I start designing a database that will hold the information on the PDFs.
Then a COBOL program to read the .TXT files. Straightforward batch, but the
most amazing things came up...

Consider the following...(I have solved all of them, but it was real fun
doing so and I'd be interested to hear your ideas...)

1. How do you tell if a string is in upper or lower case in COBOL? (I'm
using Fujitsu and yes, it does have intrinsic functions that will CONVERT to
upper or lower case. It does NOT have an equivalent to the Class Test that
says: IF Alphabetic UPPER CASE... Of course, back in ye Oldene Dayze it was
possible to do some simple aritmetic on the EBCDIC (or ASCII), but such a
solution would (and should) be frowned on today...

2. How do you find a street in a free format address? (everything on the
PDF is free format; there are NO indications of where a street ends or a
locality starts. Streets and localities can both be several words or just
one word. It is a fair bet that, if the last word of the address is 4
numeric digits, then that is an address terminating postcode, but that is
the only clue you get.

Search for the word 'Street' (or variations thereof...)? Guess how many
'variations thereof' I found... :-)

3. When you have a number of words in an array and you want to string them
back into a single string, how can you do it so there is NOT a space at the
start, but each word is separated by one, and only one, space? It must be a
looping solution rather than a hard coded single STRING statement that
brings all possible words together. The loop should terminate on a blank
word in the array (or bounds exceeded, of course)

4. Once I have decided what is the street, and what is the locality, and the
postcode, I have to write it to a Relational database. The database has
three different tables because there are urban, rural, and post box/post bag
addresses that all have different information in them. Considering only the
urban addresses (which have been described above) what would you use as the
primary key? Why? :-) (No, Doc, I am not trying to get the forum to do my
homework; I have already done it. I just want people to know the fun you can
have with COBOL. :-))

5. How would you get the Cities for the output database? (Yes, I have solved
it and they are loaded, but I sweated it... :-))

I think I had more real enjoyment writing this program and solving the
problems mentioned above than I have had for a very long time.:-)

The program makes extensive use of STRING, UNSTRING, and INSPECT, as you
might expect for a text processing job. It has heightened my awareness of
when (and when NOT) to use these constructs.

This exercise has reminded me of the true power of COBOL for this kind of
work. Some of my team were interested to see the code (I developed it on my
notebook where I have the Fujitsu IDE installed) and I showed it to them.
Some of them had never SEEN COBOL!

It amused me when one of them saw an address string being loaded to an array
with a single UNSTRING, and another commented: "Oh, that's just like
tokenizing in Java..."

So now we have a database with the NZPO data on it. And I have given them a
..EXE that will take the post office .PDFs as text, and load said
database.(No one cares that it is written in COBOL, because nobody will
maintain it. Once the output database has been designed (as it now has)
that will drive whatever data sources are used in future. If the PO change
the format of their PDFs we will simply build another solution, or buy one.)
The main things from my point of view are that none of my team were pulled
off their planned project tasks to do this, I have a COBOL program that
meets my personal needs, and it was real fun doing it!

Footnote:

I will create one or more COM components that access the created NZPO
database and do things like address validation, de-duplication, 'filling in
the blanks' (you give us a street and a postcode we give you the locality
and city, or you give us a locality or city and we give you everything else,
including the post code etc.) The loaded DB also accommodates Soundex codes
for locality and street so that inexact matches can be searched on. (I have
found this to be very useful in the past, especially where the people
entering the data do not have English as a first language).

Obviously, in a large organisation there will be many small departmental
apps that need to deal with address data. By centralizing the components
above to a server and remotely invoking the Methods of them (RPC), wrapping
the requests in SOAP, we can provide a single web service for the whole
organisation, with address data automatically wrapped in XML. This means
only one database needs to be maintained. It also means that all addresses
are valid, and the common XML allows transport across all platforms in use.

Whether the components we use at work are written in Java or something else
is irrelevant. For my own use, I will certainly use components written in OO
COBOL.

BOTTOM LINE:

COBOL is still very valuable for sequential batch type processes, where
there is requirement for text and string data manipulation.

And OO COBOL is still a very useful way to build components.

Pete.

PS I had a very nice letter from the New Zealand Post Office saying they had
considered the points I made for including cities in the PDFs. As a result,
from next year, they will do this...! Sometimes, when you pull the lephant's
tail, it actually moves! :-)

William M. Klein

2006-07-29, 3:55 am

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4j07i5F5mkquU1@individual.net...
<lots of interesting stuff snipped>

> 1. How do you tell if a string is in upper or lower case in COBOL? (I'm using
> Fujitsu and yes, it does have intrinsic functions that will CONVERT to upper
> or lower case. It does NOT have an equivalent to the Class Test that says: IF
> Alphabetic UPPER CASE... Of course, back in ye Oldene Dayze it was possible to
> do some simple aritmetic on the EBCDIC (or ASCII), but such a solution would
> (and should) be frowned on today...
>

Alphabetic-Upper has been part of the ANSI/ISO Standard since '85. I really
think that Fujitsu DOES have an

If field1 Alphabetic-Upper

class test.

It allows for spaces (as I recall - I didn't check) but will "choke" on
apostrophes, periods, etc - so I don't know if it would have helped with
"real-world" data at all.

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

Pete Dashwood

2006-07-29, 7:55 am

As usual Bill, your knowledge of COBOL is simply encyclopaedic... :-)

I checked my Fujitsu docs (once I knew what to look for) and you are
absolutely right.

There is alphabetic-upper and alphabetic-lower.

For what it's worth, I solved it by...

if function UPPER-CASE (data-string) = datastring...

[Hangs head in shame and shuffles off :-)...]

Pete.

TOP POST

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:0TDyg.150849$tQ4.91843@fe01.news.easynews.com...
>
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4j07i5F5mkquU1@individual.net...
> <lots of interesting stuff snipped>
>
>
> Alphabetic-Upper has been part of the ANSI/ISO Standard since '85. I
> really think that Fujitsu DOES have an
>
> If field1 Alphabetic-Upper
>
> class test.
>
> It allows for spaces (as I recall - I didn't check) but will "choke" on
> apostrophes, periods, etc - so I don't know if it would have helped with
> "real-world" data at all.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
>

Alistair

2006-07-29, 6:55 pm

Pete Dashwood wrote:
> So, I go back to my programming Team Lead, shuffle a bit and
> avoid looking her directly in the eye, and relay the NZPO offical line, as a
> reason why I can't provide City.
>
> She is polite but firm. Our existing software REQUIRES a CITY. Would you
> like us to change it? Not a very simple task, unfortunately. It involves
> Entity Beans needing to be changed, and that's just for the DB, then there's
> the various print solutions all of which need a City...
>
> I tell her I'll get Cities...by hook, or by crook. (Have no idea how'll I do
> it, but am now on record as having said I will...

Typical BLOODY manager! Promising a result with no idea as to how to
get there (or if it is even possible).

>
> This exercise has reminded me of the true power of COBOL for this kind of
> work. Some of my team were interested to see the code (I developed it on my
> notebook where I have the Fujitsu IDE installed) and I showed it to them.
> Some of them had never SEEN COBOL!
>
> It amused me when one of them saw an address string being loaded to an array
> with a single UNSTRING, and another commented: "Oh, that's just like
> tokenizing in Java..."

No, Java tokenization is just like Cobol's Unstring verb.... (Cobol
predates Java)

Glad you enjoyed your retro-coding foray.

>
> PS I had a very nice letter from the New Zealand Post Office saying they had
> considered the points I made for including cities in the PDFs. As a result,
> from next year, they will do this...! Sometimes, when you pull the lephant's
> tail, it actually moves! :-)

Sometimes it just dumps on you?

Michael Mattias

2006-07-29, 6:55 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1154187702.781069.323560@75g2000cwc.googlegroups.com...
> Typical BLOODY manager! Promising a result with no idea as to how to
> get there (or if it is even possible).

Sometimes you have to promise a result due to market forces, e.g., if you
don't have this feature, nobody will buy your product, and soon everyone
will be unemployed anyway.

I believe this scenario is often called free-market capitalism, or something
like that.

Besides.... in my years as a general manager (yes, in the software
business!), I learned that when dealing with our programming staff that
"But <competitor's> programmers can do it" was a pretty powerful antidote
to "It can't be done."

MCM

Richard

2006-07-29, 6:55 pm

Pete Dashwood wrote:

> 1. How do you tell if a string is in upper or lower case in COBOL? (I'm
> using Fujitsu and yes, it does have intrinsic functions that will CONVERT to
> upper or lower case. It does NOT have an equivalent to the Class Test that
> says: IF Alphabetic UPPER CASE...

SPECIAL-NAMES.

CLASS Alpha-Lower IS "A" THRU "Z" " "
CLASS Alpha-Upper IS "a" thru "z" " "

epc8@juno.com

2006-07-29, 9:55 pm

Pete Dashwood wrote:

> For some time now I haven't written any COBOL (not even for fun) and, to be
> honest, I didn't expect to have to write any more in connection with
> commercial applications.

> But sometimes Fate has surprises in store and we never quite know what is
> around the corner...

[snip]

> Enter COBOL. (Anybody tried reading a .PDF from COBOL? If you have, well
> done. I decided to convert it to text as the 'easy' option...:-)) So, I
> looked for converter software, found lots of it, but the firewall at work
> wouldn't let me download it. I pulled rank and got permissions to get the
> stuff, then found that most of it was pathetic and not worth the effort of
> downloading. I won't tell you how I solved this, but I did :-)

Acrobat Reader provides convert to text but I had to do it "manually".
Ctrl-A (select all) Ctrl-C (copy). Open Notepad. Ctrl-V (paste).

I don't know if you looked at GhostScript. Setup *does* take some minor
work but .ps to .pdf and supposedly .pdf to .txt can be done from the
command line.

> So, now I have the directory listing in .TXT. Imagine my horror when I find
> that the 500 page, 1.6MB, document only has street, locality, and Post Code.
> No cities.

[snip description of text manipulation in COBOL]

> 2. How do you find a street in a free format address? (everything on the
> PDF is free format; there are NO indications of where a street ends or a
> locality starts. Streets and localities can both be several words or just
> one word. It is a fair bet that, if the last word of the address is 4
> numeric digits, then that is an address terminating postcode, but that is
> the only clue you get.

> 3. When you have a number of words in an array and you want to string them
> back into a single string, how can you do it so there is NOT a space at the
> start, but each word is separated by one, and only one, space? It must be a
> looping solution rather than a hard coded single STRING statement that
> brings all possible words together. The loop should terminate on a blank
> word in the array (or bounds exceeded, of course)

This is the kind of problem for which I might use AWK instead. Each
line of input is split into tokens residing in variables $1, $2 ....
$NF where NF is the number of fields, as a start. NF may vary from line
to line, etc. Various pattern matching operations are available. [On
the minus side, it is interpreted, it resembles C and it takes time to
learn pattern matching and regular expressions.]

But I'm happy you solved it in COBOL.

> This exercise has reminded me of the true power of COBOL for this kind of
> work. Some of my team were interested to see the code (I developed it on my
> notebook where I have the Fujitsu IDE installed) and I showed it to them.
> Some of them had never SEEN COBOL!

> It amused me when one of them saw an address string being loaded to an array
> with a single UNSTRING, and another commented: "Oh, that's just like
> tokenizing in Java..."

[snip]

> BOTTOM LINE:
>
> COBOL is still very valuable for sequential batch type processes, where
> there is requirement for text and string data manipulation.
>
> And OO COBOL is still a very useful way to build components.
>
> Pete.

And once the component is built, the users do not care what language
was used to write it!

James J. Gavan

2006-07-29, 9:55 pm

epc8@juno.com wrote:
> Pete Dashwood wrote:
>
Fascinating problem Pete laid out - more on that later 'cos it's a
lovely sunny day, my grass is getting too lonnnnnnnng, and I should get
some of the weeds out from within the chard !
>
>
>
> This is the kind of problem for which I might use AWK instead. Each
> line of input is split into tokens residing in variables $1, $2 ....
> $NF where NF is the number of fields, as a start. NF may vary from line
> to line, etc. Various pattern matching operations are available. [On
> the minus side, it is interpreted, it resembles C and it takes time to
> learn pattern matching and regular expressions.]
>
> But I'm happy you solved it in COBOL.

And there's another way to do it in COBOL, which I'll outline. Specific
to Net Express but not in any way covered by the proposed J4
Collections. And the solution is really a doddle without requiring any
deep background knowledge. (Very likely Pete has emulated the same using
standard Procedural code).

> And once the component is built, the users do not care what language
> was used to write it!

Correct !

Jimmy

HeyBub

2006-07-29, 9:55 pm

Michael Mattias wrote:
> "Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
> news:1154187702.781069.323560@75g2000cwc.googlegroups.com...
>
> Sometimes you have to promise a result due to market forces, e.g., if
> you don't have this feature, nobody will buy your product, and soon
> everyone will be unemployed anyway.
>
> I believe this scenario is often called free-market capitalism, or
> something like that.
>
> Besides.... in my years as a general manager (yes, in the software
> business!), I learned that when dealing with our programming staff
> that "But <competitor's> programmers can do it" was a pretty
> powerful antidote to "It can't be done."

It is far, far better to sell what you don't (yet) have than try to find a
market for what you do have.

HeyBub

2006-07-29, 9:55 pm

Richard wrote:
> Pete Dashwood wrote:
>
>
> SPECIAL-NAMES.
>
> CLASS Alpha-Lower IS "A" THRU "Z" " "
> CLASS Alpha-Upper IS "a" thru "z" " "
> .
>
>
> IF ( field IS Alpha-Upper )
> ...

How does this work on

o'conner or RIDLEY-SMITH ?

Pete Dashwood

2006-07-29, 9:55 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1154187702.781069.323560@75g2000cwc.googlegroups.com...
>
> Pete Dashwood wrote:
>
> Typical BLOODY manager! Promising a result with no idea as to how to
> get there (or if it is even possible).
>

I DID provide it, and when I said I would.

For me, that is being a typical manager.

The fact that I couldn't see a solution at the time, never made me doubt for
one minute that I WOULD find a solution. You might consider the attitudinal
approach here, Alastair.
>
>
> No, Java tokenization is just like Cobol's Unstring verb.... (Cobol
> predates Java)

That was why I was amused... (a joke isn't funny when you have to spell it
out)
>
>
> Glad you enjoyed your retro-coding foray.
>
Well, I did.

>
> Sometimes it just dumps on you?
>
Yes, I guess that is always a possibility too... :-)

Pete.

Richard

2006-07-29, 9:55 pm

HeyBub wrote:
[color=darkred]

Louis Krupp

2006-07-30, 3:55 am

HeyBub wrote:
[snip]
> It is far, far better to sell what you don't (yet) have than try to find a
> market for what you do have.

To quote a computer salesman I knew about 30 years ago:

It's not what you can do that counts; it's what you can *say* you can do.

Louis

Pete Dashwood

2006-07-30, 3:55 am

I like this solution, Richard, but not sure I would do it... :-)

Pete

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1154217480.115560.63160@m73g2000cwd.googlegroups.com...
>
> HeyBub wrote:
>
> .
>
> Note to self, read back what has been written. Lower and Upper are
> reversed.
>
>
> It works exactly as well as you want to make it work. If you want to
> test for particular characters then it is only necessary to include
> those in the class you define.
>
> My task was to construct a standard Cobol way of testing for alphabetic
> upper or lower, those are a to z and space.
>

Pete Dashwood

2006-07-30, 3:55 am

"Jürgen Vetter" <vetter@dokom.net> wrote in message
news:44cc5646$1@news.knipp.de...
> Am 29.07.2006 06:47 schrieb Pete Dashwood:
>
>
> One of the first question to me is: what is your environment?

It is a client server network with a non-IBM mainframe that handles legacy.

> You wrote something about excel-spreadsheets, so your environment is
> a pc-solution?

No, but for the purpose of this exercise it may be considered so.

> The next question is: what is your task or in other words where do you
> want to go?

I thought that was fairly clear. I want to download data from the New
Zealand Post Office and eventually load it into a relational database. I
then want to build components to access this database, wrap them in SOAP (or
maybe use Dot NET), as Web Services, and provide a single, remotely
invocable, solution that anyone in our organisation can use when they need
to deal with addresses. This will be transported by XML as part of the SOAP
layer. (Our organisation is aiming towards SOA and such a service would be a
step in the right direction.) The first step on the journey is to get the
data out of the .PDF format it is now packaged in by NZ Post.
>
> Informations like the postalinformat of all poeple in a country is a
> classical problem to solve whith a central mainframe instead of many
> local pc-server.

And your basis for deciding this is... what?

>
>
> What? a txt-file? No database? Oh my godness!

Yes, a text file. Easier to manipulate under program control than a .PDF.
>
>
> You have to find the command in your compiler. IBM vs cobol can convert
> strings from lower to upper case.

So can the compiler I am using. I think you have totally misunderstood the
problem here. Try reading the above again...slowly. Ich weiss das Englische
sprach sind schwerig fuer dich, aber der bedeutung ist klar, hoffentlich.
Als ich habe gesagt, oben, das problem ist nicht mit CONVERSION
(uebersetzung?), sonst mit DETECTION (aufdeckung?) Entschuldigung, mein
schreckliche, sehr rustig, Deutsch.. :-))

>
>
> you have to organize your data well, for example in a database.
> If you have to read it from a stream, like a txt-file you must have
> a delimiter like tabulator or something else (remember how ms office
> does import unknown formats)

Unfortunately this is not MY data. I cannot make the post office organize it
how I would like. All I can do is deal with the way they HAVE organized it.
There are no delimiters or tabulators. It is a free download and you do so
at your own risk.
>
>
> Whith ibm vs-cobol you have the commands string and unstring with many
> different options like pointer, counter, delimiter and so on. No problem
> to solve your solution well with that compiler.

There is no problem to solve it with the compiler I am using, which has the
same options. However, when you actually come to DO it, there are some
subtle traps in it. I was trying not to use pointer, but I agree it is
easier if you do.

>
>
> cobol has nothing to do with your database solution, i don't understand
> you.
No,

ly, you don't. That is not your fault, or mine.

if you want to transform your txt-file in a relationl database you
> have to know something about the concepts of saving data in a relationl
> database.

Er... I was on the second relational database course run by IBM in the U.K.
in 1983. I have studied relational theory, read Codd and Date's seminal work
and been building relational databases for the last 23 years. I have taught
people this technology, written papers on normalization, and actually
implemented (once :-)) a database in Boyce-Codd normal form (5th
normalization). It is fair to say I understand the concepts. :-)

>
> to me is to partition data in rural, urban or postbox-adress only an
> attribute of the address.

Then you may need to revisit normalization theory. Have a look at the next
step in normalization, after removing repeating groups... (Certainly,
address formats are attributes of an address, but my question was about
primary keys, and that pertains to higher level normalization.)

>
>
> I use cobol only on mainframes. In a pc-solution i use languages like
> c++ or delphi. Delphi has a powerfull way to work with strings, such as
> cobol have. maybe delphi is more powerfull.

I became familiar with Delphi a few w

s ago while covering a different
exercise. :-) The underlying Pascal is an open book to most people who
understand OO. For this exercise, I decided to use COBOL. I explained why I
did that in the original post.
>
>
> if you have to work with big data the only right solution is:
> mainframe to use massive batch-processing and than any mainframe
> language like pl/1, cobol or easytrieve (<- reporting tool)with
> a database like DB2 (relational database) or ims/db (hierarchical
> database)

The "only way", huh?... :-)

<rant... it's been a while :-)>
My experience (and it is extensive...) has been that when IT people say
something is "the only way", what they really mean is: "It is the only way I
can think of..." It has furthermore been my experience that sometimes such
people are lacking in imagination, and when shown an alternative solution,
the response is usually... "Oh, well, of course, if you do it like THAT..."

Imaginative, bright people, and (fortunately) they exist in IT just like
most other walks of life, would never limit their horizons by claiming
something is the ONLY way... rather, "This is the best way I can find at the
moment. Let me sleep on it and I'l try for a better solution...".

The ONLY way is an ALLEY way. It permits of no further investigation or
lateral thought. It represents a closed mind.

Sometimes, I have worked in places where they substitute "OUR way" for the
""ONLY way". "This is the way we have always done it and we see no reason to
change it." You present arguments for an alternative, but the minds are
closed.

I don't stay in such places very long and I learned years ago not to work
there in the first place. You can sense the corporate culture when you go
for interview, and five minutes chatting to the shop floor soon confirms a
lethargic, unenthusiastic, bunch of jobsworths.

Best avoided.
</rant... I feel much better now...:-)>
>
>
> In know 20 years programming cobol i never have the wish to use oo witho
> cobol :->
>

And in 40 years programming, I believe OO is one of the major breakthroughs,
and most important events in the history of computer science. (BTW, before
PCs were invented, I spent 20 years programming mainframes in COBOL,
including IBM and the BUNCH, so please don't think I am unqualified to argue
this with you :-)

Summarising:

I believe you have missed several points here, Jurgen. It may be the
language...

I further believe you are confusing size with power. You seem to think that
mainframes are best for large tasks; that is simply no longer true. There is
a lingering misconception that mainframes are more powerful than networks;
that isn't so either. I believe mainframes will be absorbed into the
networks and become indistinguishable from high powered servers. Whether I
am right or wrong, the fact remains that you don't put a job onto particular
hardware because it has a bigger box than a rack mounted one.

> sorry about my bad english, i better can read it than write

No problem. I evened us up with my bad German :-) (Apologies to all German
readers. It is some years since I lived in Germany, and I get little chance
to practice in NZ...:-))

MFG,

Pete.

epc8@juno.com

2006-07-30, 7:55 am

Pete Dashwood wrote:

> And in 40 years programming, I believe OO is one of the major breakthroughs,
> and most important events in the history of computer science.

I've been trying to understand what OO really is for some time. I don't
routinely use OO and I certainly don't regularly use COBOL, let alone
OO in COBOL. But I still would like to make some general comments.

1. COBOL is a good candidate for new techniques such as OO. While COBOL
does have sub-programs, local variables and functions, traditional
COBOL did not use them. Older programs tend to be monoliths with global
variables. OO is less of a conceptual leap if you have worked in other
languages such as C or Fortran where sub-programs and variable scope
issues come up frequently.

Look at a typical Fortran task, say inverting a matrix. There are many
different numerical techniques which might be used, each with pages of
documentation. But to the program user the relevant questions are

a. How, in general, does the called program work?
b. What arguments are passed to the sub-program?
c. What does the sub-program return?
d. How do you link it to your main program?

2. Pascal is actually a good example of some OO concepts. Both UCSD and
Turbo Pascal introduced UNITS. Units are chunks of program whose
IMPLEMENTATION may be hidden. But they have a well described INTERFACE
to the outside world.

3. Is this really just a different way of saying separate compilation
and program libraries? Perhaps. But I believe that OO and OO like
techniques add additional features.

a. late binding - Yes COBOL has dynamic CALL and yes COBOL can call
DLLs.
b. self describing interfaces - IMO this is important because it adds
an additional capability to the older (Smalltalk) way of looking at OO
- passing messages to objects. In this case the objects talk back and
tell you what they can do!

This form of abstraction may help you drain the swamp - unless the
alligators bite you first.

-- elliot

Robert Jones

2006-07-30, 7:55 am

message snipped

Very interesting and informative.

I expect the NZPO is going to have some fun for several months over the
changeover with a substantial proportion of the population continuing
to use the old post codes, some might continue to use them for several
years.

Robert

Pete Dashwood

2006-07-30, 7:55 am

"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1154257805.814136.203310@i3g2000cwc.googlegroups.com...
> message snipped
>
> Very interesting and informative.
>
> I expect the NZPO is going to have some fun for several months over the
> changeover with a substantial proportion of the population continuing
> to use the old post codes, some might continue to use them for several
> years.
>
> Robert
>
Yes, they have agreed to continue delivering mail to the old postcodes for 2
years... after that I guess all bets are off :-)

They have stated that mail addressed to old postcodes and localities will
take longer to deliver.

Large sums of money are being invested in updating and upgrading the
automatic OCR readers for mail sorting. The new overhaul is supposed to
facilitate this.

Time will tell... :-)

Pete.

Pete Dashwood

2006-07-30, 7:55 am

"Jürgen Vetter" <vetter@dokom.net> wrote in message
news:44cc9cb5$1@news.knipp.de...
> Am 30.07.2006 10:11 schrieb Pete Dashwood:
>
>
> sorry, it's my mistake. i thought it was a permanently translation from
> an unfriendly format to something like a relational database.
>
> ok, if you have to deal with this data because there isn't a chance to
> get them in an other format you made i nice job. but i can't understand
> why they have only this pdf-format. normally big companies or some state
> offices have found a way to send and receive data each other. if there
> is nothing else they often use xml to transfer data.

Yes, that is what you might expect :-) They USED to provide the data on
Excel spreadsheets so people could use it directly or easily import it into
their own systems. BUT, that was before they had a PAF (see my original
post) on offer for $3000... It is not in their interest to make these
downloads easy. Instead, they have simply taken the hard copy directories
which you can buy at any Post Office for $35 and converted them to .PDF. I
s'pose some people may buy the book and scan it (:-)) but I was hoping to do
something a bit more elegant than that...

>
> did you ask this postal office?

Yes, I had several conversations with hem. As a result, they are going to
implement some of my suggestions next year :-)
>
>
> ok, sorry :-)
>
>
> ok, but with my badly understanding i'd make this mistake.
> you don't announce any structure, so it's hard to understand.
> but if normalization is no problem to you so everything should solve
> well.

It does indeed :-).
>
<snipped some stuff not worth pursuing>

>
> In my understanding of developing
> an application i try to use the best strategy to get the best result.
> the best result has attributes like performance, low or no errors and
> a long lifecycle of the application. I have no time and money to make
> some exercises :->

That is commendable, Jurgen and I agree it is a sensible way to develop
applications.

>
> I think you will do this in the same way if the appication is not only
> an exercise, won't you?

Yes. I've tried to do something along those lines most of my working life.
Sometimes there are external pressures that mean you can't get quite what
you want, but it is always fun trying :-)
>
>
> and sometimes there is only one way to solve a problem with best
> results. first there is the problem to solve second there a different
> ideas one of them is the only one (very often) to get the best results.

Be careful here... "best results" can mean different things to different
people. Different people may have different priorities and different
perceptions. Sometimes system development is coloured by what, in pure
terms, are complete irrelevancies, like politics, f'r'instance :-)

If several options have been explored then the chosen option is NOT "the
only way", it is simply the BEST way we can find at the moment, based on our
agreed priorities and requirements.

I won't discuss this further because I am sensitive about it; I've heard
"the only way" far too often in my career, and seen bright and innovative
solutions stifled by it. It is probably just me. I never use this phrase.

>
> you won't get some different words from me. i pointed out that i won't
> use oo in cobol. i use it with delphi or c++.

Said it before, I'll say it again: "The implementation of OO into standard
COBOL is, in my opinion, one of the finest feats of software engineeering I
have seen in a liftetime of IT."

Nevertheless, COBOL is still a procedural language, and even with the
beautifully seamless addition of OO to it, it suffers by comparison to true
OO languages like Java, which were designed to be OO from the ground up. In
comparison to Java, OO COBOL is like a man with an extra leg... ("Jake the
Peg" - Rolf Harris).

Having said all of that, OO COBOL could still be a mainstream development
language if users had backed it. They didn't. (The reasons for this are
manifold, but some of it stems from the mainframe environmenrt not
recognising the need for OO. Unless you are familiar with the needs of
networks, concepts like RPC to encapsulated objects don't really mean much.
Many mainframe sites still haven't tumbled to the benefits to be obtained
from a Service Oriented Architecture (I was talking with someone the other
day who thought it was part of Marketing...:-)), even though IBM are pushing
it.

The tragedy with OO COBOL is that the COBOL community simply didn't see the
value in it.

>
>
> i think so
>
>
> a mainframe has not only the power. the whole system is easier to handle
> instead of a pc-network or serverfarm. do you know a network with an
> on-time by 99,7 percent?

Yes, I know several, and I subscripe to a server farm in the USA which has
99,98% And work doesn't stop every Monday morning for routine maintenance...
:-) Neither does it require a bevy of systems experts and programmers to
keep it running.
>
> it's the descision between local datastorage and central datastorage.

That is certainly part of it. During the course of my career I have seen
this "centralize/decentralize" pendulum swing several times. The fact is
that there are merits in both approaches.

>
> think about this: if you have a telecom-company and you have to deal
> with million of customers, maybe to send them there bill, whould you
> prefer a pc-network with hundreds of printers or a mainframe with one
> big database and one big printer to solve this problem?

Those are not the only options. You don't need hundreds of printers on your
network; you need a number of print servers. If you buy a solution such as
Thunderhead, or Xerox, it is irrelevant whether they are driven by a
mainframe or a network. (I am looking at exactly this problem for my project
at the moment, so I know something about alternatives...:-))

>
> i can't imagine a world without mainframes but pcs and pc-networks open
> some new ideas, concepts and ways, for example the communication between
> people.

I can't imagine a world without computer power. Whether it comes from a
mainframe or a network is irrelevant to the end user. All that matters is
the seamless deployment of that capability to the end user. Wireless
internet will change all our lives in the next 10 years and it won't matter
in the least whether it is driven from mainframes or PCs or other devices.

>
> at the end:
> As an it-professionell you have to decide which is the best solution and
> sometimes still your conclusion is: it's a mainframe whith it's
> performance to deal with big data like no other can do.

OK. :-) I can agree for you to believe that.
>
>
> right!

On principles, I think we are in accord... :-)

Pete.

Pete Dashwood

2006-07-30, 7:55 am

<epc8@juno.com> wrote in message
news:1154254323.265763.261110@m73g2000cwd.googlegroups.com...
> Pete Dashwood wrote:
>
>
> I've been trying to understand what OO really is for some time. I don't
> routinely use OO and I certainly don't regularly use COBOL, let alone
> OO in COBOL. But I still would like to make some general comments.
>
> 1. COBOL is a good candidate for new techniques such as OO. While COBOL
> does have sub-programs, local variables and functions, traditional
> COBOL did not use them.
The traditional stuff I wrote certainly did :-) Once we got to "structured
COBOL" or "COBOL 2" as it was sometimes called, I think everybody started
structuring code. Even before that, COBOL had the things you mention right
from day 1 (I first used 'COBOL 59' (from memory... I seem to recall seeing
that on the listing pages), on tape based systems, in the mid 1960s. We
wrote subprograms and called them...It was fun watching the SYSRES tape
reading backwards and forwards to get the subprograms...:-))

Older programs tend to be monoliths with global
> variables.
Certainly batch processing ones are. But that is a good thing.

OO is less of a conceptual leap if you have worked in other
> languages such as C or Fortran where sub-programs and variable scope
> issues come up frequently.

Fortran ???!!! gasp! :-)

>
> Look at a typical Fortran task, say inverting a matrix. There are many
> different numerical techniques which might be used, each with pages of
> documentation. But to the program user the relevant questions are
>
> a. How, in general, does the called program work?
> b. What arguments are passed to the sub-program?
> c. What does the sub-program return?
> d. How do you link it to your main program?
>
> 2. Pascal is actually a good example of some OO concepts. Both UCSD and
> Turbo Pascal introduced UNITS. Units are chunks of program whose
> IMPLEMENTATION may be hidden. But they have a well described INTERFACE
> to the outside world.

Yes, I saw this with Delphi and was quite impressed. The Delphi compiler
could automatically find needed units and the whole approach lent itself to
a modular paradigm.

>
> 3. Is this really just a different way of saying separate compilation
> and program libraries? Perhaps. But I believe that OO and OO like
> techniques add additional features.

So do I :-)

>
> a. late binding - Yes COBOL has dynamic CALL and yes COBOL can call
> DLLs.

OO COBOL can also statically bind and use the Respository for conformance
checking at compile time. (I always use late binding, but that's because I
never know until runtime what I'm gonna do, half the time... :-))

> b. self describing interfaces - IMO this is important because it adds
> an additional capability to the older (Smalltalk) way of looking at OO
> - passing messages to objects. In this case the objects talk back and
> tell you what they can do!
>
> This form of abstraction may help you drain the swamp - unless the
> alligators bite you first.
>
> -- elliot
>

I hope you'll have a look at OO COBOL, Elliot. Jimmy uses it for building
Classes; I use it for building components. The

fact is that support will
probably be withdrawn within the next 5 - 10 years. I think all of the major
implementations of it are pretty good.

As a 'quick build' GUI tool, Fujitsu PowerCOBOL is very useful. It is OO
'under the covers' and so is very good for people to get some of the
concepts without being exposed to nitty gritty on day one.

Pete.

Pete Dashwood

2006-07-30, 7:55 am

<epc8@juno.com> wrote in message
news:1154201998.141793.119150@i3g2000cwc.googlegroups.com...
>
> Pete Dashwood wrote:
>
>
>
> [snip]
>
>
> Acrobat Reader provides convert to text but I had to do it "manually".
> Ctrl-A (select all) Ctrl-C (copy). Open Notepad. Ctrl-V (paste).

Good job, Elliot. That was what I did in the end... :-) The only problem
with this is that some of the data is corrupted when cutting and pasting.
For example, where a range of numbers was included, say, 123-345, it
appeared in the text file as: 1 3- 45

This was a right pain but it only did it occasionally and I set the parser
to throw these records to a file for manual attention. I ended up with about
180 of them, out of just under 50,000 records.
>
> I don't know if you looked at GhostScript. Setup *does* take some minor
> work but .ps to .pdf and supposedly .pdf to .txt can be done from the
> command line.
No, It's not a package I'm familiar with. Would you recommend it?

>
>
> [snip description of text manipulation in COBOL]
>
>
>
> This is the kind of problem for which I might use AWK instead.

OK, I'll buy it... what's AWK :-)?

Each
> line of input is split into tokens residing in variables $1, $2 ....
> $NF where NF is the number of fields, as a start. NF may vary from line
> to line, etc. Various pattern matching operations are available. [On
> the minus side, it is interpreted, it resembles C and it takes time to
> learn pattern matching and regular expressions.]
>
> But I'm happy you solved it in COBOL.

Me too :-).
>
>
>
> [snip]
>
>
> And once the component is built, the users do not care what language
> was used to write it!
>
Absolutely!

Pete.

epc8@juno.com

2006-07-30, 9:55 pm

> Pete Dashwood wrote:

[snip]

> Fortran ???!!! gasp! :-)

The current standard far more modern than what I first learned :-).

> I hope you'll have a look at OO COBOL, Elliot. Jimmy uses it for building
> Classes; I use it for building components. The

fact is that support will
> probably be withdrawn within the next 5 - 10 years. I think all of the major
> implementations of it are pretty good.
>
> As a 'quick build' GUI tool, Fujitsu PowerCOBOL is very useful. It is OO
> 'under the covers' and so is very good for people to get some of the
> concepts without being exposed to nitty gritty on day one.
>
> Pete.

I'm definitely going to take a look at this. I have two different
copies of Fujitsu version 3.0. First from Thane Hubbell' book, second
the demo CD from Fujitsu.
Do you know of a good reference that I should read?

-- Elliot

HeyBub

2006-07-30, 9:55 pm

Pete Dashwood wrote:
> My team had a requirement to get information from the New Zealand Post
> Office lists of addresses and post codes.

Poor problem definition. Did the powers-that-be want to punish you by making
you visit the post office or did they want something they could use? See
below.

>
> As I don't want to have busy, bright young people doing work that a
> monkey could do, I told them I would get the NZPO stuff myself. Being a
> manager, I am ideally qualified for monkey work :-)

[snip agonizing, hair-pulling, and various false-start methodologies]

My first-order approximation of the solution would be to see if I could BUY
the solution.* I can't believe you're a pioneer on this project. Heck, in
the U.S. various databases exist (in the public domain) cross-referencing
postal codes with cities.

====
* Maybe not "BUY." It would depend on the extent of the problem. If, for
example, you're dealing with only a couple of hundred objects, it would be
cheapier, easier, and faster to solve the problem by working it out with a
pencil -- the classic way a mathemetician cures constipation.

epc8@juno.com

2006-07-30, 9:55 pm

Pete Dashwood wrote:
> <epc8@juno.com> wrote in message
> news:1154201998.141793.119150@i3g2000cwc.googlegroups.com...
>
> Good job, Elliot. That was what I did in the end... :-) The only problem
> with this is that some of the data is corrupted when cutting and pasting.
> For example, where a range of numbers was included, say, 123-345, it
> appeared in the text file as: 1 3- 45
>
> This was a right pain but it only did it occasionally and I set the parser
> to throw these records to a file for manual attention. I ended up with about
> 180 of them, out of just under 50,000 records.
> No, It's not a package I'm familiar with. Would you recommend it?

I've installed it from time to time mostly to view PostScript files. (I
no longer have a PostScript printer around.) see
http://www.cs.wisc.edu/~ghost/
The documentation and setup were, last time I looked at it, somewhat
klunky.

>
> OK, I'll buy it... what's AWK :-)?

An interpreted C-like programming language from Bell Labs named for its
authors (Aho, Weinberger & Kernighan). One of its major features is the
associative array which is an array whose subscripts are strings. Data
is converted by magic between string and number if need be. Variables
need not be initialized.

An AWK program is applied line by line to all input files. It is a
series of pattern-action pairs. When a line of text fulfills a
condition or matches a pattern on the left, the program on the right is
executed. The program can be specified on the command line or from a
file.

For example

awk 1

echoes standard input to standard output. The pattern '1' is always
true. The default action is to print the input line as is. So simple
patterns are used to print out all matching lines. For example

awk /foo/

prints out all lines containg 'foo'.

As each line is read it is broken up into tokens separated by white
space. (The input separators and other things can be changed, of
course). Each "field" is assigned to a variable named $1 through $NF.
Also other variables are assigned. NF contains the number of fields, NR
is the current record number, etc.

An AWK program containing

{print $(NF-1)}

prints out the next to last field from each line.

This silly program

/^[0-9]+Q/ {t+=$3}
END{print t}

totals the third field for all lines starting with at least one decimal
digit followed by the letter Q.

see http://cm.bell-labs.com/cm/cs/awkbook/index.html

a reference version of AWK for Win95 is available from

http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe

Why would COBOL programmers want to look at this language?

1. It's handy for various forms of text manipulation.
2. It's a prototyping tool.

Suppose you want to write a program that converts quote-comma delimited
text to something else. AWK does not handle this natively, but it is
easy to test out algorithms that you might then translate into COBOL,
for example.

-- Elliot

Louis Krupp

2006-07-30, 9:55 pm

epc8@juno.com wrote:
<snip>
> Acrobat Reader provides convert to text but I had to do it "manually".
> Ctrl-A (select all) Ctrl-C (copy). Open Notepad. Ctrl-V (paste).
>
> I don't know if you looked at GhostScript. Setup *does* take some minor
> work but .ps to .pdf and supposedly .pdf to .txt can be done from the
> command line.
<snip>

PDF provides for data compression (LZW and Flate are the most common
methods). If the stuff you're after is thus encoded, you're going to
need something like Ghostscript unless you want to write your own
decoder. (LZW isn't too bad; Flate is more complicated, but there's
open source C code to deal with it.)

Louis

James J. Gavan

2006-07-30, 9:55 pm

epc8@juno.com wrote:
>
>
> [snip]
>
>
>
>
> The current standard far more modern than what I first learned :-).
>
>
>
>
> I'm definitely going to take a look at this. I have two different
> copies of Fujitsu version 3.0. First from Thane Hubbell' book, second
> the demo CD from Fujitsu.
> Do you know of a good reference that I should read?
>
> -- Elliot
>
There are two good books on OO COBOL and the rest are crap. From your
perspective both books are based on Micro Focus OO COBOL, but you can
certainly read them in conjunction with that F/J compiler you have.

If you want to go for spending about $100 then you can get the
University Edition of Net Express. (It's got all the whistles and bells
of the commercial version but limits you on the lines of code, so that
you can't creep around distributing your software without paying M/F
Runtime fees). Check out microfocus.com. Currently the UE Edition covers
Net Express V 4.0 including dotNet linkage. Keep your eye out for V 5.0,
due sometime this summer, which of course will contain new or enhanced
features.

The books. Bear in mind unless it looks like a volume of an encyclopedia
set, no one book can cover a subject to the depth we readers might like.
For example both below spell out the basics very well, but if you were
trying to look for guidance on Pete's problem - then I'm afraid that
only comes from usage :-

a) Edmund Arranga and Frank Coyle "OO COBOL". There's something wacky
with the ISBN number so go to Amazon.com and search using "Edmund
Arrranga". Chances are they may still have some second-hand copies for
around $12.

(Both Arrange and Coyle have moved on, disappointed at the poor
reception of OO in the COBOL community). Both Ed Arranga and Will below
used to run objectz.com or cobolreport.com - now defunct.

b) Will (Wilson Price) 'Elements of OO COBOL' - one of Pete's favourite
books, although I think his dog-eared copy got list in moves from Albion
to Kiwiland. So far as I am aware, the only source for this book is
Murach Publishing (they do COBOL books) so do a google to get their URL.

Will (having written some 50 books on programming) had a loyal following
in academia, (the States, up here in Quebec, Australia etc.), who were
more than happy to use his book. Sadly the concept got kiboshed as more
and more universities dropped COBOL training for the language du jours.
So Will too is disappointed at OO COBOL's reception. Nevertheless,
although a few months older than me he is still doing the teaching
circuit, at least the last I heard.

I consider both books my Bible Part 1 and Part 2. I got pushed by a
techno-freak I was working for, to get into Winders. I got Net Express.
I despaired and nearly gave up twice. Then I got Arranga/Coyle and
screamed "Eureka !". Simple but effective coded application as an
appendix - groan no diskette and I've never been able to get one.

Fortunately Will's book comes with a CD, so you can load and run his
examples in current versions of Net Express - even where his code says
"Class-Control" instead of the current "Repository".

Don't look for either of these books to cover file handling/DB Tables or
GUI-ing, OLE Web etc., but they are real SOLID on the basics. Syntax of
course is Micro Focus at the time they were writing the books around 1997.

Jimmy

Richard

2006-07-31, 7:55 am

Pete Dashwood wrote:

> My team had a requirement to get information from the New Zealand Post
> Office lists of addresses and post codes.

Me too.

> Now, although the organisation I work for can easily afford to buy the PAF
> (and probably will) it just makes me smart that they virtually HAVE to.

I had tried bit banging the html form provided by NZ Post a few months
ago and this worked, for the old codes. With the new codes they have
mangled the post data to prevent this being done.

> Enter COBOL. (Anybody tried reading a .PDF from COBOL? If you have, well
> done. I decided to convert it to text as the 'easy' option...:-)) So, I
> looked for converter software, found lots of it, but the firewall at work
> wouldn't let me download it. I pulled rank and got permissions to get the
> stuff, then found that most of it was pathetic and not worth the effort of
> downloading. I won't tell you how I solved this, but I did :-)

You can't get there from here, as they say. Any PDF to text will spit
out the text in the order it is in the PDF. The NZ Post have it
columnar so for each page you get all the street names then all the
ranges (if any) then all the towns. It is impossible to use this.

However, PDF to HTML nearly works. It almost gets it right.

Using pdftohtml provided with Mandrake 9.1 (my usual workbox) gave good
results. Trying it with Fedora 5 gave 'invalid color' or somesuch and
no usable output. Now why would NZ Post use colors that would break
extracting the data ?

Here is a python program that processes the html file crudely. It
doesn't do the PO Boxes yet but it reassembles the broken names quite
well and handles the street number ranges.

Note you need to get the indenting right as python defines logic levels
by indenting.

I won't post the whole html file or results due to copyright. I may
post samples if asked.

#!/bin/env python

import string

def main():

pc = open("postcodedirectory_nomapss.html", "r")
po = open("postcode.txt", "w")

codes = []
queue = []
skip = 0
init = ('', '', '', '')
(street,range,town,postcode) = init
part = 0

for buf in pc:
line = string.strip(buf)
if ( line[0:3] == '' ):
skip = 0
elif ( line[0:10] == 'The suburb' ):
skip = 0
elif ( line[0:1] == '<' ):
skip = 1
elif ( skip ):
pass
else:
bits = string.split(line, '<')
part += 1
text = bits[0]

hindex = string.find(text, '-')
numbers = 0
if ( hindex > 0 ):
char = text[hindex - 1]
if ( char >= '0' and char <= '9' ):
numbers = 1
if ( hindex < (len(text) - 1) ):
char = text[hindex + 1]
if ( char >= '0' and char <= '9' ):
numbers = 1

if ( hindex >= 0 and numbers ):
range = text
if ( text[-1:] == ' ' ):
queue.append(('r', len(codes)))
part -= 1
elif ( part == 1 ):
if ( string.find(text, ' ') < 0 ):
if ( len(queue) > 0 ):
(type, indx) = queue.pop(0)
try:
(street,range,town,postcode) = codes[indx]
except:
print type, indx, len(codes), text
else:
print street, range, town, postcode
if ( type == 's' ):
street += text
elif ( type == 'r' ):
range += text
else:
town += text
codes[indx] = (street,range,town,postcode)
print street, range, town, postcode
(street,range,town,postcode) = init
part = 0

else:
street = text
if ( text[-1:] == ' ' ):
queue.append(('s', len(codes)))
elif ( part == 2 ):
town = text
if ( text[-1:] == ' ' ):
queue.append(('t', len(codes)))

elif ( text[0:1] >= '0' and text[0:1] <= '9' ):
postcode = text

codes.append((street,range,town,postcode))

(street,range,town,postcode) = init
part = 0

for (street,range,town,postcode) in codes:
po.write('"%s","%s","%s",%s\n' % (street,range,town,postcode))

pc.close()
po.close()

if ( __name__ == "__main__" ):
main()

Pete Dashwood

2006-07-31, 7:55 am

Hi Elliot,

thanks for the response and the interesting summary onAWK.

I spent some time on regular expressions a little while back so I can see
the general idea. It seeems reminiscent of APL in some respects too.

I don't think I'll dive in at this stage... :-)

Pete.

TOP POST

<epc8@juno.com> wrote in message
news:1154280740.990906.38520@75g2000cwc.googlegroups.com...
>
> Pete Dashwood wrote:
>
> I've installed it from time to time mostly to view PostScript files. (I
> no longer have a PostScript printer around.) see
> http://www.cs.wisc.edu/~ghost/
> The documentation and setup were, last time I looked at it, somewhat
> klunky.
>
>
> An interpreted C-like programming language from Bell Labs named for its
> authors (Aho, Weinberger & Kernighan). One of its major features is the
> associative array which is an array whose subscripts are strings. Data
> is converted by magic between string and number if need be. Variables
> need not be initialized.
>
> An AWK program is applied line by line to all input files. It is a
> series of pattern-action pairs. When a line of text fulfills a
> condition or matches a pattern on the left, the program on the right is
> executed. The program can be specified on the command line or from a
> file.
>
> For example
>
> awk 1
>
> echoes standard input to standard output. The pattern '1' is always
> true. The default action is to print the input line as is. So simple
> patterns are used to print out all matching lines. For example
>
> awk /foo/
>
> prints out all lines containg 'foo'.
>
> As each line is read it is broken up into tokens separated by white
> space. (The input separators and other things can be changed, of
> course). Each "field" is assigned to a variable named $1 through $NF.
> Also other variables are assigned. NF contains the number of fields, NR
> is the current record number, etc.
>
> An AWK program containing
>
> {print $(NF-1)}
>
> prints out the next to last field from each line.
>
> This silly program
>
> /^[0-9]+Q/ {t+=$3}
> END{print t}
>
> totals the third field for all lines starting with at least one decimal
> digit followed by the letter Q.
>
> see http://cm.bell-labs.com/cm/cs/awkbook/index.html
>
> a reference version of AWK for Win95 is available from
>
> http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe
>
> Why would COBOL programmers want to look at this language?
>
> 1. It's handy for various forms of text manipulation.
> 2. It's a prototyping tool.
>
> Suppose you want to write a program that converts quote-comma delimited
> text to something else. AWK does not handle this natively, but it is
> easy to test out algorithms that you might then translate into COBOL,
> for example.
>
> -- Elliot
>

Pete Dashwood

2006-07-31, 7:55 am

<epc8@juno.com> wrote in message
news:1154277608.565015.193680@m73g2000cwd.googlegroups.com...
>
> [snip]
>
>
> The current standard far more modern than what I first learned :-).
>
>
> I'm definitely going to take a look at this. I have two different
> copies of Fujitsu version 3.0. First from Thane Hubbell' book, second
> the demo CD from Fujitsu.
> Do you know of a good reference that I should read?
>
> -- Elliot
>
The only book on OO COBOL that I have read myself (I have read a number of
other books on OO in general and Java in particular) is Wil(son) Price's
book on Object Oriented COBOL. Unfortunately, I'm in Auckland and the book
is in Tauranga so I can't give you an ISBN but you can probably find it by
GOOGLING. Try Murach as the publisher. I did a review on it years ago for
the Object-Z booksite but this seems to be defunct now... the following
might help: http://www.murach.com/books/objectz.htm

At the time I read Wil's book I was considering writing one myself, but I
thought his was so good there was nothing more I could add... :-0

Highly recommended.

Pete.

Pete Dashwood

2006-07-31, 9:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12cpphrn2pg5jc5@news.supernews.com...
> Pete Dashwood wrote:
>
> Poor problem definition.

Was it? I didn't provide all of the background but I thought the statement
of what we were trying to achieve was fair and simple.

Did the powers-that-be want to punish you by making
> you visit the post office or did they want something they could use? See
> below.

There were no 'powers-that-be' making me do this; it was entirely my own
decision. It is now running and doing what we hoped it would. I didn't waste
any valuable resources from my project. Instead, I provided them with some
support. Had I been much busier and pressed, I probably wouldn't have
undertaken this exercise and would have bought the PAF immediately, so I
don't disagree with what you are saying. Instead, I had some fun, my team
got to see COBOL used in anger and acquired NZPO data they were in need of
for another development, and I have some COBOL code I can use for my own
purposes. Everybody wins... :-)
>
>
> [snip agonizing, hair-pulling, and various false-start methodologies]
>
> My first-order approximation of the solution would be to see if I could
> BUY the solution.* I can't believe you're a pioneer on this project. Heck,
> in the U.S. various databases exist (in the public domain)
> cross-referencing postal codes with cities.
>
> ====
> * Maybe not "BUY." It would depend on the extent of the problem. If, for
> example, you're dealing with only a couple of hundred objects, it would be
> cheapier, easier, and faster to solve the problem by working it out with a
> pencil -- the classic way a mathemetician cures constipation.

Yes, I believe many small businesses will do exactly that; re-enter the data
manually using the NZPO hard copy directories. I hope to persuade some of
them not to... :-)

Jerry,

if you re-read the original post, I spelled out that we will probably buy
the $3000 solution. I also spelled out that I want a solution for myself; I
have some plans in this area, and I'm not personally going to spend $3000
until I know that what I am planning is viable.

There wasn't any agonizing or hair pulling; I enjoyed doing this. That
included the 'surprises'... :-)

I LIKE solving things; that's why I do cryptic crosswords...and I enjoy
pain, that's why I post to CLC... :-)

EVERYBODY who doesn't buy the PAF is a pioneer on this. The codes and
localities are new and country wide. The previous codes were distributed on
Excel files; now they're not. I covered that in other posts in this thread.

Do try and keep up... :-)

Pete.

Pete Dashwood

2006-07-31, 9:55 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1154342952.054929.230650@b28g2000cwb.googlegroups.com...
>
> Pete Dashwood wrote:
>
>
> Me too.
>
>
> I had tried bit banging the html form provided by NZ Post a few months
> ago and this worked, for the old codes. With the new codes they have
> mangled the post data to prevent this being done.
>
>
> You can't get there from here, as they say. Any PDF to text will spit
> out the text in the order it is in the PDF. The NZ Post have it
> columnar so for each page you get all the street names then all the
> ranges (if any) then all the towns. It is impossible to use this.

Hmmm... I found that to be the case.

I cut and pasted it in the end, and this gave a line with street, range of
numbers if applicable, locality, and postcode, but there were no terminators
of course. In effect, it becomes a free format address. And it has all kinds
of extraneous garbage interspersed with it...:-)

>
> However, PDF to HTML nearly works. It almost gets it right.
>

But then you need to deal with HTML tags and colours and banners etc..

> Using pdftohtml provided with Mandrake 9.1 (my usual workbox) gave good
> results. Trying it with Fedora 5 gave 'invalid color' or somesuch and
> no usable output. Now why would NZ Post use colors that would break
> extracting the data ?

Yes, one of the reasons I opted for text was because of this.
>
> Here is a python program that processes the html file crudely. It
> doesn't do the PO Boxes yet but it reassembles the broken names quite
> well and handles the street number ranges.

This is a generous offer Richard... (and the Python code is interesting in
its own right...)

I now have COBOL code that handles PO Boxes, Rural deliveries, and urban
adresses, including the ones that are broken across lines, and the ones with
street number ranges (provided it can read the range correctly. Currently I
have a couple of hundred where it can't, but I'm looking at fixing this...
:-)). I also have code that puts the correct city onto the locality.(You
probably found, as I did, that the Regional organisation of the thing is
quite useless for doing this. I wrote code to watch which range of lines
were in each regional directory, then found it was so inconsistent it was
virtually useless.)

>
> Note you need to get the indenting right as python defines logic levels
> by indenting.
>
> I won't post the whole html file or results due to copyright. I may
> post samples if asked.
>
> #!/bin/env python
>
> import string
>
> def main():
>
> pc = open("postcodedirectory_nomapss.html", "r")
> po = open("postcode.txt", "w")
>
> codes = []
> queue = []
> skip = 0
> init = ('', '', '', '')
> (street,range,town,postcode) = init
> part = 0
>
> for buf in pc:
> line = string.strip(buf)
> if ( line[0:3] == '' ):
> skip = 0
> elif ( line[0:10] == 'The suburb' ):
> skip = 0
> elif ( line[0:1] == '<' ):
> skip = 1
> elif ( skip ):
> pass
> else:
> bits = string.split(line, '<')
> part += 1
> text = bits[0]
>
> hindex = string.find(text, '-')
> numbers = 0
> if ( hindex > 0 ):
> char = text[hindex - 1]
> if ( char >= '0' and char <= '9' ):
> numbers = 1
> if ( hindex < (len(text) - 1) ):
> char = text[hindex + 1]
> if ( char >= '0' and char <= '9' ):
> numbers = 1
>
> if ( hindex >= 0 and numbers ):
> range = text
> if ( text[-1:] == ' ' ):
> queue.append(('r', len(codes)))
> part -= 1
> elif ( part == 1 ):
> if ( string.find(text, ' ') < 0 ):
> if ( len(queue) > 0 ):
> (type, indx) = queue.pop(0)
> try:
> (street,range,town,postcode) = codes[indx]
> except:
> print type, indx, len(codes), text
> else:
> print street, range, town, postcode
> if ( type == 's' ):
> street += text
> elif ( type == 'r' ):
> range += text
> else:
> town += text
> codes[indx] = (street,range,town,postcode)
> print street, range, town, postcode
> (street,range,town,postcode) = init
> part = 0
>
> else:
> street = text
> if ( text[-1:] == ' ' ):
> queue.append(('s', len(codes)))
> elif ( part == 2 ):
> town = text
> if ( text[-1:] == ' ' ):
> queue.append(('t', len(codes)))
>
> elif ( text[0:1] >= '0' and text[0:1] <= '9' ):
> postcode = text
>
> codes.append((street,range,town,postcode))
>
> (street,range,town,postcode) = init
> part = 0
>
>
> for (street,range,town,postcode) in codes:
> po.write('"%s","%s","%s",%s\n' % (street,range,town,postcode))
>
> pc.close()
> po.close()
>
> if ( __name__ == "__main__" ):
> main()
>
In the code above, the 'town' is actually a locality. (It could be a suburb
and often is...) While this is fine for the PO and they guarantee to deliver
if street, locality and postcode are correct, there is a lot of software out
there that expects a City as well as a locality. I have built our database
to include a City, and arranged to source the right cities for the
localities from a non post office, freely downloadable, source. (Sadly, this
DB doesn't have the new postcodes on it...) From next year, in response to
my requests, the Post Office will include the City in the directory entries.

It is a sobering thought that the DB I used to get the cities (and which is
updated every 5 days to include new suburbs and streets) identifies around
15,000 more streets than the Post Office directories do... Some of these
will be covered by RD but I don't think 15, 000 of them are.

The accuracy of the NZPO database, and, by implication, the PAF itself, is
yet to be established.

Pete.

Howard Brazee

2006-07-31, 9:55 pm

On Sat, 29 Jul 2006 16:47:00 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>2. How do you find a street in a free format address? (everything on the
>PDF is free format; there are NO indications of where a street ends or a
>locality starts. Streets and localities can both be several words or just
>one word. It is a fair bet that, if the last word of the address is 4
>numeric digits, then that is an address terminating postcode, but that is
>the only clue you get.
>
>Search for the word 'Street' (or variations thereof...)? Guess how many
>'variations thereof' I found... :-)

I once had an address that included "14th St. St. Louis".

I worked for a company that processed subscription cards. They had
some people working in a closed room for most of a year for trade
secret purposes as they replaced a commercial address cleansing
routine with a home built one. We also had a "dirty word" file which
was used as part of the processing to recognize false names and
addresses. We knew which postal codes fit which countries.

But data cleansing isn't an easy task. Look at what is happening now
with spam filters, and the scum bags who work to get around them.

Alistair

2006-07-31, 9:55 pm

Pete Dashwood wrote:[color=darkred]
>
> I DID provide it, and when I said I would.
>
> For me, that is being a typical manager.
>
> The fact that I couldn't see a solution at the time, never made me doubt for
> one minute that I WOULD find a solution. You might consider the attitudinal
> approach here, Alastair.

I think that some of what I was getting at can be summed up by the joke
below. No attitude adjustment required, I probably need to meet that
mythical creature - a good manager.

Joke:

A man in a hot air balloon realized he was lost. He reduced altitude
and spotted a
woman below. He descended a bit more and shouted, "Excuse me, can you
help
me? I promised a friend I would meet him an hour ago, but I don't know
where I am."
The woman below replied, "You're in a hot air balloon hovering
approximately 30
feet above the ground. You're between 40 and 41 degrees north latitude
and
between 59 and 60 degrees west longitude." "You must be in Information
Technology," said the balloonist. "I am," replied the woman, "How did
you know?"
"Well," answered the balloonist, everything you told me is technically
correct, but
I've no idea what to make of your information and the fact is I'm still
lost. Frankly,
you've not been much help at all. If anything, you've delayed my trip."

The woman below responded, "You must be in Management." "I am," replied
the
balloonist, "but how did you know that?" "Well," said the woman, "you
don't know
where you are or where you're going. You have risen to where you are
due to a
large quantity of hot air. You made a promise which you've no idea how
to keep,
and you expect people beneath you to solve your problems. The fact is
you are in
exactly the same position you were in before we met, but now, somehow,
it's my
fault!

HeyBub

2006-07-31, 9:55 pm

Pete Dashwood wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:12cpphrn2pg5jc5@news.supernews.com...
>
> Was it? I didn't provide all of the background but I thought the
> statement of what we were trying to achieve was fair and simple.

It was. You said they wanted you to get something from the post office.

>
>
>
> There were no 'powers-that-be' making me do this; it was entirely my
> own decision.

Oh. I guess I was

by your statement:

"My team had a requirement to get information from the New Zealand Post
Office lists of addresses and post codes."

Which I read as "get something from the New Zealand Post Office..."

>
> if you re-read the original post, I spelled out that we will probably
> buy the $3000 solution. I also spelled out that I want a solution for
> myself; I have some plans in this area, and I'm not personally going
> to spend $3000 until I know that what I am planning is viable.

No thanks. I read it once. That was enough. I don't like pain.

>
> There wasn't any agonizing or hair pulling; I enjoyed doing this. That
> included the 'surprises'... :-)

The only difference between you and my ex-wife, then, is the target of your
pain-infliction compulsion.

>
> I LIKE solving things; that's why I do cryptic crosswords...and I
> enjoy pain, that's why I post to CLC... :-)
>
> EVERYBODY who doesn't buy the PAF is a pioneer on this.

But only the first to solve the problem is the pioneer. I don't like
pioneering.

> The codes and
> localities are new and country wide. The previous codes were
> distributed on Excel files; now they're not. I covered that in other
> posts in this thread.

I noticed that. We went from postal codes to ZIP codes some years back. Then
ZIP+4.

But I can see where you get your sense of priorities; I bet the US has some
unused ZIP codes we could have sold NZ, but, no, your country had to go out
and create them anew.

>
> Do try and keep up... :-)

Nah. "You take the high road and I'll take the low road..."

Richard

2006-07-31, 9:55 pm

HeyBub wrote:

>
> It was. You said they wanted you to get something from the post office.

I understood exactly what that was and what the problem was. That you
didn't understand is irrelevant as you were not expected to be part of
any solution.

>
> Oh. I guess I was

by your statement:
>
> "My team had a requirement to get information from the New Zealand Post
> Office lists of addresses and post codes."

Perhaps you didn't undertand that he used 'my' to indicate ownership
and/or control. PECD _is_ the 'power that be'.

> Which I read as "get something from the New Zealand Post Office..."

> No thanks. I read it once. That was enough. I don't like pain.

Reading is optional, replying is optional. Your choice, don't blame
others.

> The only difference between you and my ex-wife, then, is the target of your
> pain-infliction compulsion.

Suffering that may not be optional for you. Reading messages here is.
You are not PECD's target, except by your volutary actions.

> But only the first to solve the problem is the pioneer. I don't like
> pioneering.

So you prefer to ride along in the wake.

Richard

2006-07-31, 9:55 pm

Pete Dashwood wrote:

>
> But then you need to deal with HTML tags and colours and banners etc..

Dealing with HTML is easy with the right tools. In this particular case
the HTML is really simple and can be used as markers.

Number Range 
Suburb/Town 
Postcode 
Abbots Way 
Otaika 
0110 
Baffin Street 
Opua 
0200 
Acacia Drive 
Raumanga 
0110 
Bahama Place 
Parahaki 
0112 

The hard bit is where there has been wrap around:

Albert Street 
Whangarei 
0110 
Bank Street 
Kaitaia 
0410 
Central 
Bank Street 
2-122 (Even Numbers) 
Whangarei 
0110 
Alcoba Street 
Kamo 
0112 
Central 
Alderton Drive 
Kerikeri 
0230 

The 'Central' has to be added to the 'Whagarei' which, fortunately has
an additional trailing space which can be used as a signal. It is two
out because the PDF has two columns on the page.

In general with HTML though it is a pain. There is a Python class for
dealing with it though and I have used this to suck data from a
complex webpage.

> In the code above, the 'town' is actually a locality. (It could be a suburb
> and often is...) While this is fine for the PO and they guarantee to deliver
> if street, locality and postcode are correct, there is a lot of software out
> there that expects a City as well as a locality. I have built our database
> to include a City, and arranged to source the right cities for the
> localities from a non post office, freely downloadable, source. (Sadly, this
> DB doesn't have the new postcodes on it...)

Can you give me that URL ?

> The accuracy of the NZPO database, and, by implication, the PAF itself, is
> yet to be established.

Its a worry. Fortuately most of the problem for my clients is
businesses in the cities, so they should be OK.

epc8@juno.com

2006-07-31, 9:55 pm

James J. Gavan wrote:
> epc8@juno.com wrote:
[color=darkred]
> There are two good books on OO COBOL and the rest are crap. From your
> perspective both books are based on Micro Focus OO COBOL, but you can
> certainly read them in conjunction with that F/J compiler you have.
>
> a) Edmund Arranga and Frank Coyle "OO COBOL". There's something wacky
> with the ISBN number so go to Amazon.com and search using "Edmund
> Arrranga". Chances are they may still have some second-hand copies for
> around $12.

Thanks for your advice and also thanks to PECD. I've ordered a used
copy of Arranga and Coyle. I'll post after I've read and worked with it
a bit.

-- Elliot

James J. Gavan

2006-07-31, 9:55 pm

epc8@juno.com wrote:
>
>
> Thanks for your advice and also thanks to PECD. I've ordered a used
> copy of Arranga and Coyle. I'll post after I've read and worked with it
> a bit.
>

OK Elliot you've decided to tackle Arranga & Coyle first. Recall I wrote
there was no diskette ? Even with an OO background you well find it
frustrating working your way through their source, so suggest you do the
following, which is what I did.

Starting at Page 373, The Library Application Code - take pieces of
paper and put them as stickers on the first page of each class, with
your own "identity" - that will help you flip backwards and forwards
between the various classes as they do inter-class invoking as opposed
to invoking self.

One problem with OO COBOL - you can come up with meaningful class names,
but it is only easy to follow if you are running them through a debugger
(M/F Animator).

When I was musing on writing an OO book from a developer's standpoint I
could see this would be a problem for a text, where others didn't have a
compatible compiler. So using a standard set of class names I would have
prefixed them, to make reference easier to source, e.g.

Customer Edit - Class01-CustomerEdit
Customer File - Class02-CustomerFile
Customer Table - Class03-CustomerTable
Customer Reports - Class03-CustomerReports

then you would get

invoke Class01-CustomerEdit "new" returning (Object reference)
os-Class01-CustomerEdit

Before anybody suggests the above could be :-

invoke Class01-CustomerEdit "new" returning (Object reference)
os-Class01

that would be even more meaningless to the reader.

In the real world you don't need that Class01 jazz - but for a reference
book ?

Jimmy

HeyBub

2006-08-01, 7:55 am

Richard wrote:
> HeyBub wrote:
>
>
> I understood exactly what that was and what the problem was. That you
> didn't understand is irrelevant as you were not expected to be part of
> any solution.

Heh. Of course I wouldn't be part of the solution. I have no easy way of
trotting down to the NZ post office. Further, if someone did insist I hie
myself to the New Zealand Post Office, I'd tell 'em to get stuffed.

>
>
> Perhaps you didn't undertand that he used 'my' to indicate ownership
> and/or control. PECD _is_ the 'power that be'.

Right. Neither I, nor, I predict, almost anyone else would take the
statement otherwise. I admit there exist those who would decode the above as
"The mayor's horse has diabetes," or something other than the statement's
plain meaning, but I attribute that and similar understandings to mental
disease or defect.

>
>
>
> Reading is optional, replying is optional. Your choice, don't blame
> others.

Blame? I didn't blame anybody. I just commented on lack of proper problem
definition.

>
>
> Suffering that may not be optional for you. Reading messages here is.
> You are not PECD's target, except by your volutary actions.

Right. I can't imagine why anyone would be the object of the Peterborough
English Country Dancer's attention, let alone me. I may have that wrong. If
so, does the fault lie with the communicator or my comprehension? It's an
intricate and difficult problem.

>
>
> So you prefer to ride along in the wake.

Of course. That way you get adequate warning of shoals, rocks, mines, and
schools of sharks (you do miss out on Mermaids, though). The only time you
should be in the lead is when a single bear attacks your group -- and even
then you only have to be ahead by one.

Success belongs more often, much more often, to the implementors than it
does to the innovators.

Richard

2006-08-01, 6:55 pm

HeyBub wrote:

>
> Heh. Of course I wouldn't be part of the solution. I have no easy way of
> trotting down to the NZ post office. Further, if someone did insist I hie
> myself to the New Zealand Post Office, I'd tell 'em to get stuffed.

It wasn't so much Pete's 'poor problem definition' than, as your 'poor
problem understanding'.

It doesn't require 'trotting down to the Post Office', this is the 21st
century, it only requires clicking on a link on the NZPO web site, such
as on this page:

http://www.nzpost.co.nz/Cultures/en...deDirectory.htm

You do understand about 'the web' and 'clicking links' don't you ? or
should these be written into the problem definition so that you could
cope ?

HeyBub

2006-08-01, 6:55 pm

Richard wrote:
> HeyBub wrote:
>
>
> It wasn't so much Pete's 'poor problem definition' than, as your 'poor
> problem understanding'.
>
> It doesn't require 'trotting down to the Post Office', this is the
> 21st
> century, it only requires clicking on a link on the NZPO web site,
> such
> as on this page:
>
> http://www.nzpost.co.nz/Cultures/en...deDirectory.htm
>
> You do understand about 'the web' and 'clicking links' don't you ? or
> should these be written into the problem definition so that you could
> cope ?

Giggle! Talk about reading comprehension or lack thereof. The original
problem was posted as:

"My team had a requirement to get information from the New Zealand Post
Office lists of addresses and post codes."

None of this new-fangled "click" business. The requirement was to get the
data from the "New Zealand Post Office," not a web site in Borneo. Furthere,
I note the alleged www.nzpost.co.nz has an IP address beginning with
202.xxx.xxx.xxx. Very many institutions automatically block on the
200-series IP addresses.

As for "writing down the problem definition," inasmuch as there are
differing definitions of the stated problem (mine and that of a few idiots),
common sense dictates that ambigious requirements be memoralized.

Richard

2006-08-01, 6:55 pm

HeyBub wrote:

> Giggle! Talk about reading comprehension or lack thereof.

Yours, obviously. I am not sure why you confuse such phrases as 'get
from' and 'go to'.

> The original problem was posted as:
>
> "My team had a requirement to get information from the New Zealand Post
> Office lists of addresses and post codes."
>
> None of this new-fangled "click" business. The requirement was to get the
> data from the "New Zealand Post Office," not a web site in Borneo.

Your geography skills seem to be somewhat lacking, too.

But, no, I did not see any part of the requirement that indicated the
type of transport to be used, nor that the request to the NZPO be
verbal over-a-counter. It could have been done with a letter, or a
telephone call, and for the lists to be returned by parcel. Those are
the traditional business of the NZPO after all, or used to be.

As it happens they also have Email and a web site.

The actual method used to 'get' was left entirely to the initiative of
the getter, you have shown the level of your abilities in this
endevour.

Not only did your 'initiative' only go as far as thinking of a single
option, but you also stated that you would refuse to take that option
if asked.

> Furthere,
> I note the alleged www.nzpost.co.nz has an IP address beginning with
> 202.xxx.xxx.xxx. Very many institutions automatically block on the
> 200-series IP addresses.

They may do so where you are, but not here, it is a NZ subnet. Your
knowledge of the IP address structure goes right alongside your grasp
of the South Pacific.

> As for "writing down the problem definition," inasmuch as there are
> differing definitions of the stated problem (mine and that of a few idiots),

You missed out the word 'other' after 'few'.

> common sense dictates that ambigious requirements be memoralized.

They weren't 'ambigious' [sic] to those who matter.

Richard

2006-08-01, 9:55 pm

HeyBub wrote:

> Giggle! Talk about reading comprehension or lack thereof. The original
> problem was posted as:
>
> "My team had a requirement to get information from the New Zealand Post
> Office lists of addresses and post codes."
>
> None of this new-fangled "click" business. The requirement was to get the
> data from the "New Zealand Post Office,"

Actually, no. The requirement was - paratheses added to help those
with comprehension difficulties:

"My team had a requirement to get information from (the New Zealand
Post
Office lists of addresses and post codes)."

James J. Gavan

2006-08-02, 3:55 am

Pete Dashwood wrote:

A while getting here, because I wass dong some coding - see below.
Fascinating topic, and be assured I have read and re-read to ensure I
don't get my knuckles wrapped ! ( :-) ).

The first thing that jumped at me was your phrase, "Some of them had
never SEEN COBOL!", referring to your team. Chances are many never will
because they aren't going to buy COBOL. So if you haven't got COBOL you
have neither an awareness of it or how it can be used.

THE PROBLEM :

Sure an interesting one.

YOUR SOLUTION :

Obviously wont go into that in detail because it is unique to your NZ
postal codes as is ours for Canada. Went looking at a Canada Post site -
format ANA NAN - and each character has a significance. Basically each
6-char code gives you a box geographical location and looks like they
started coding from Newfoundland and worked their way West. Not just
Canada Post but there are many other sites which let you enter addresses
for which the search engine will return a postal code. Doesn't mention
it - but underlying, I bet it would be possible to do a back
cross-reference having city and getting a block or ranges of postal
codes - could that work with yours ?

Using EXCEL - unfortunately can't relocate it - but when looking at the
Canadian system there was a link to 'Jay' or 'Jay's - a software house
covering US and Canada with a screenshot of using Excel to store data.
Basically just the screenshot because they expect you to buy !

COLLECTIONS :

> I have watched but (so far) refrained from joining the debate about OO
> Collections and whether they should be an intrinsic part of the COBOL
> language. (I have no such reservations about XML, and my views on including
> this in COBOL are a matter of record.).
>
> My own feeling is that if the COBOL community had embraced OO 10 years ago,
> and the price of compilers had been lower, COBOL could have been a
> 'mainline' OO development language and, instead of COBOL playing a pitiful
> 'catch up' to established languages with established libraries, the other
> languages would be trying to accommodate the COBOL libraries which would, by
> now, have made a name for themselves as reliable and robust... But that is
> all speculation, and debatable, and of little value, and this is not the
> thread for it...