Prev: Fortran 2003 Handbook
Next: 2010 world cup jerseys,paypal payment and free shipping
From: Louis Krupp on 12 Jun 2010 03:07
On 6/12/2010 12:22 AM, e p chandler wrote:
<snip>
> You forgot option #4. Do the project in COBOL. This language does
> support indexed files but then the math would be a real bear.
>
> Sorry to bring up COBOL, but part of this problem has the flavor of a
> fairly typical business D.P. task involving data conversion and data
> access.

Actually, I thought about COBOL, but as far as I know, commercial COBOL
compilers tend to be expensive, and then there's the learning curve for
COBOL. There's OpenCOBOL, but I get the impression the OP would be more
comfortable with a more mature product (if there's a problem, guess who
gets to learn C). I could be wrong, of course.

>
> Actually there is some important information we don't know. What is the
> format, layout and structure of the database that the OP has on his PC?
> Is his data really transferred from a VAX, byte for byte? If so, is
> there METADATA known by the operating system that is NOT transferred?

Some of this information should be embedded in the file, and
$ANALYZE/RMS might be useful here. Perhaps the OP could ship the file
to a VMS system where some kind soul could do that and perhaps $CONVERT
it to a flat file if necessary.

> I suspect that the data actually exists in some other form, possibly a
> formatted text file or maybe even a CSV file.

One can always hope.

> If so, then the OP may be able to use parts of the posted program for
> the record structure and formulas. But then he must code ALL of the
> programming logic himself to use what standard Fortran does provide:
> sequential and direct access files, either formatted or unformatted.
> (forget about stream for now.).

The OP is about to learn more about this application than he ever
dreamed possible.

Louis
From: glen herrmannsfeldt on 12 Jun 2010 03:38
rfengineer55 <rfengineer55(a)aol.com> wrote:
(snip)

> The error looks pretty clear to me also. What's not clear is the
> solution. Fortran 77 is standard Fortran. How can we utilize it's
> resources to solve the problem?

Many of the problems that used to be done using indexed I/O
are now much easier to just do in memory. That was needed
when memories were small.

Otherwise, just read the keys, generate a hash table,
and then use direct access I/O to read/write the record.
If you don't want a hash table, linear search through the
key list in memory is probably fast enough.

OK, more specifically with direct access you give the
record number and it reads or writes that record.
With indexed, you give the key, usually an alphanumeric
string, and it reads/writes the record with that key.

-- glen
From: glen herrmannsfeldt on 12 Jun 2010 03:44
e p chandler <epc8(a)juno.com> wrote:
(snip)

> You forgot option #4. Do the project in COBOL. This language does support
> indexed files but then the math would be a real bear.

> Sorry to bring up COBOL, but part of this problem has the flavor of a fairly
> typical business D.P. task involving data conversion and data access.

PL/I has indexed I/O, probably borrowed from COBOL. Well, it
is also part of the OS/360 I/O system. From the time when memories
were small (8K on the low end S/360 models), the disk hardware
can do a (linear) search through the index to find the appropriate
entry. (Running at disk speed, not CPU speed.) Even more, it
uses self-modifying channel programs, and puts absolute disk
addresses inside the files. By the time of S/370 and VAX memories
were big enough to do the index in memory, but the data stays
on disk.

-- glen
From: e p chandler on 12 Jun 2010 05:05

"Louis Krupp" <lkrupp_nospam(a)indra.com.invalid> wrote in message
news:Jd2dnXRfAqaAr47RnZ2dnUVZ_rOdnZ2d(a)indra.net...
> On 6/12/2010 12:22 AM, e p chandler wrote:
> <snip discussion of COBOL and ISAM>
>> I suspect that the data actually exists in some other form, possibly a
>> formatted text file or maybe even a CSV file.
> One can always hope.

I did exchange e-mails with the OP, off list, and it turns out that his data
can be viewed in two different ways.

1. LF delimited text, 600 char text records
2. 601 char fixed size records, all text characters + trailing LF.

I wrote a small program to make one pass through the data file, extract the
fields used in the key, and write those to an output file. Ordinary
formatted, sequential access. It took about one second to process the 17 MB
input file and write the keys to an output file for study on my 2 GHz
machine.

So I suspect, and have suggested to the OP, that he not worry about ISAM at
all. Now whether he should or can optimize his access to the file by using
formatted direct access, that's a different question. The file is already
sorted on the first part of the primary key. This is also one of the
criteria for selecting records so it's easy to cycle or exit the main DO
loop as needed.

---- E




From: mecej4 on 12 Jun 2010 08:04
e p chandler wrote:

>
> "Louis Krupp" <lkrupp_nospam(a)indra.com.invalid> wrote in message
> news:Jd2dnXRfAqaAr47RnZ2dnUVZ_rOdnZ2d(a)indra.net...
>> On 6/12/2010 12:22 AM, e p chandler wrote:
>> <snip discussion of COBOL and ISAM>
>>> I suspect that the data actually exists in some other form, possibly a
>>> formatted text file or maybe even a CSV file.
>> One can always hope.
>
> I did exchange e-mails with the OP, off list, and it turns out that his
> data can be viewed in two different ways.
>
> 1. LF delimited text, 600 char text records
> 2. 601 char fixed size records, all text characters + trailing LF.
>
> I wrote a small program to make one pass through the data file, extract
> the fields used in the key, and write those to an output file. Ordinary
> formatted, sequential access. It took about one second to process the 17
> MB input file and write the keys to an output file for study on my 2 GHz
> machine.
>
> So I suspect, and have suggested to the OP, that he not worry about ISAM
> at all. Now whether he should or can optimize his access to the file by
> using formatted direct access, that's a different question. The file is
> already sorted on the first part of the primary key. This is also one of
> the criteria for selecting records so it's easy to cycle or exit the main
> DO loop as needed.
>
> ---- E

Given the small size of the data set (by today's standards), there is no
need for elaborate file types -- the whole data can be kept in memory
(after sorting by key, if preferable) and searched by linear (or binary, if
sorted) search.

Perhaps, even that is unnecessary. The FCC may have developed modern
versions with similar functionality. I do not know what this particular
program does, but I found many applications on the FCC Web page where you
type in a location/station code and out pops a color-plot.

Elliot, please post the file AMKEYS.INC if you have it and it is not too
long. I am asking you since the OP seems to operate mostly in a WRITEONLY
mode as far as C.L.F. postings are concerned. He may have posted the file,
but there are now dozens of highly disorganized threads that he originated
and I have not seen the file yet.

-- mecej4
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Fortran 2003 Handbook
Next: 2010 world cup jerseys,paypal payment and free shipping