Prev: Fortran 2003 Handbook
Next: 2010 world cup jerseys,paypal payment and free shipping
From: e p chandler on 12 Jun 2010 09:21

"mecej4" <mecej4.nyetspam(a)operamail.com> wrote in message
news:huvt58$du0$1(a)news.eternal-september.org...
>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

I don't have that file. I just substituted an empty file for AMKEYS.INC. I
fixed the line breaks and made 3 small changes so that the program compiled
without errors and then ran and produced output!
I do have a copy of AMDIST.DAT.

---- output starts ----
C:\Users\epc\temp>a
Invalid option [junk] is ignored


Welcome to AMDIST Today is
C:\User

$Output to a print file [Y or N] -->
N

0AMDIST prints all stations within a given distance from given coordinates

We are using AM Volume 0; Last updated: 100501

0Select units for distances:

Enter K for kilometers
M for miles
$Selection?
M
0Enter S for short listings
M for medium listings
L for long listings

$Selection?
M
0Select range of frequencies:

$Starting frequency, ending frequency?
1000,1100


$Distance(mi), Lat (D.MMSS), Lon (D.MMSS)?
200,45.00,84.00
0CIRS SAULT STE MARIE ON CA 530 kHz Unl
ND-1-
U
N Lat 46 31 00 W Lon 84 21 00 Class C Region 2 Class C RMS: 35.00
mV/m
0.05000 kW Operating CL# 00457 ( 7 01) Last Updated
1 Towers; Theo Pattern; 0 Augmentations; Q: ; Cutoff:
IFRB Serial # ; Entered into List on
Coordination Status: Canada: Unknown; Mexico: Unstudied; Region 2:
0 Distance from N Lat 45 00 00 W Lon 84 00 00 is 106.1 mi
Azimuth from N Lat 45 00 00 W Lon 84 00 00 is 351.0 degrees
Azimuth to N Lat 45 00 00 W Lon 84 00 00 is 170.7 degrees

0 Number of records in the search range = 1

$More?
n

C:\Users\epc\temp>
------ end of text ------

While my criteria for frequency seem to be igonred, the station listed is
within 200 miles of the location I specified which is somewhere in northern
lower Michigan. (By my guess about 60 miles from the Mackinac Bridge).

Considering that I have made no changes to the program logic, that's
remarkable or just good luck.

Here are the changes I made to get it to compile with gfortran:

Comparing files x0.f and X.F
***** x0.f
c
character*80 amdbname /'bam:amdb.dat'/
character*80 new_db_name
***** X.F
c
character*80 amdbname /'amdb.dat'/
character*80 new_db_name
*****

***** x0.f
character*1 cc
character*2 escape /'1B'x/
logical ansi_crt
***** X.F
character*1 cc
integer*2 escape /'1B'x/
logical ansi_crt
*****

***** x0.f
character*1 cc
character*2 escape /'1B'x/
logical ansi_crt
***** X.F
character*1 cc
integer*2 escape /'1B'x/
logical ansi_crt
*****

The first is just changing the file name. The 2nd and 3rd are hacks. I'm
setting an integer variable to a numeric value and then (not) printing it
with an A format.

But of course there are bugs. I can't select a print file for output without
a fatal error. I suspect that it might be a problem with unit numbers. [see
the recent discussion in this newsgroup about a program that re-used unit
6...]

I do think that all the OP has to do is fix up the main loop to just make a
single pass through the file, and fix lots of bugs. I have not delved deeply
into this program but the one optimization I would make, if possible, is to
take the starting location and calculate the boundaries of a rectangle that
just encloses the circle centered on the location at the specified distance.

Then the logic is simple:

For each recond in the input file, if it is out of the specified frequency
range, reject.
If it is outside the bounding rectangle, reject.
Otherwise calculate the distance, if outside, reject, otherwise process it.
If the frequency read from the file is greater than the upper limit, exit.

The database does contain a sentinel record at then end with 9999 and a
header record at the start with 0000.

--- Elliot







From: rfengineer55 on 12 Jun 2010 11:03
On Jun 12, 9:21 am, "e p chandler" <e...(a)juno.com> wrote:
> "mecej4" <mecej4.nyets...(a)operamail.com> wrote in message
>
> news:huvt58$du0$1(a)news.eternal-september.org...
>
>
>
>
>
Elliot,

Thank you for your hard work on AMDIST. I don't remember if the source
I posted to the list contains all of the subroutnes or not,

Here is some actual test data that you can try -

Pick "m" for miles then

enter s for short listings. Medium and long listings are buggy.
You can try the others to see what I mean

and for

fequency range

540, 1000 It MUST be co0mma delimited.

Dist, Lat Long dd.mmss, Long dd.mmss

100, 42.0000, 88.0000

This should give us a screenfull of GC and distance information fror
all the AM radio stations within about 100 miles from WGN.

I see that the program is acting like it has a lot of logic bugs
because it misses a lot of stations. It also ignores for the most
part, the given frequency range. The stations the software does find
however,are within the correct search range. I also see where the
program does not honor search distances below about 1ooo miles.

I'm preparing for vacation, so have notn had time to enter search
criteria to see if there is a pattern to what I'm asking for versus
what the program is actually doing.

But with the program inputI've given you, you wll be able to see what
I'm seeing. At first glance without doing any actual troubleshooting
and debugging, the program will probably settle down once the AMDB.dat
read is settled down and made Fortran 77 compliant (for my purposes) I
am only guessing, but given that this program ran fine at the FCC,
Idoubt that theprogram body itself has any actual logi errors, but you
never know for sure. All depends on how mission critical this program
actually was for them. I probably won't dom much troubleshooting until
after vacation.

Again thanks Elliot to you, as well as all of the other interested
commenters on thisproject

Jeff

RF ENGINEER55



> >e p chandler wrote:
>
> >> "Louis Krupp" <lkrupp_nos...(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
>
> I don't have that file. I just substituted an empty file for AMKEYS.INC. I
> fixed the line breaks and made 3 small changes so that the program compiled
> without errors and then ran and produced output!
> I do have a copy of AMDIST.DAT.
>
> ---- output starts ----
> C:\Users\epc\temp>a
>  Invalid option [junk] is ignored
>
>  Welcome to AMDIST                                         Today is
> C:\User
>
> $Output to a print file [Y or N] -->
> N
>
> 0AMDIST prints all stations within a given distance  from given coordinates
>
>  We are using AM Volume    0; Last updated: 100501
>
> 0Select units for distances:
>
>  Enter K for kilometers
>        M for miles
> $Selection?
> M
> 0Enter S for short listings
>        M for medium listings
>        L for long listings
>
> $Selection?
> M
> 0Select range of frequencies:
>
> $Starting frequency, ending frequency?
> 1000,1100
>
> $Distance(mi), Lat (D.MMSS), Lon (D.MMSS)?
> 200,45.00,84.00
> 0CIRS     SAULT STE MARIE             ON CA  530 kHz                   Unl
> ND-1-
> U
>  N Lat 46 31 00 W Lon  84 21 00 Class  C Region 2 Class C  RMS:    35.00
> mV/m
>     0.05000 kW     Operating     CL# 00457 ( 7  01) Last Updated
>   1 Towers; Theo Pattern;  0 Augmentations; Q:              ; Cutoff:
>  IFRB Serial #          ; Entered into List   on
>  Coordination Status:  Canada: Unknown; Mexico: Unstudied; Region 2:
> 0 Distance from N Lat 45 00 00 W Lon  84 00 00 is  106.1 mi
>    Azimuth from N Lat 45 00 00 W Lon  84 00 00 is  351.0 degrees
>    Azimuth  to  N Lat 45 00 00 W Lon  84 00 00 is  170.7 degrees
>
> 0 Number of records in the search range =        1
>
> $More?
> n
>
> C:\Users\epc\temp>
> ------ end of text ------
>
> While my criteria for frequency seem to be igonred, the station listed is
> within 200 miles of the location I specified which is somewhere in northern
> lower Michigan. (By my guess about 60 miles from the Mackinac Bridge).
>
> Considering that I have made no changes to the program logic, that's
> remarkable or just good luck.
>
> Here are the changes I made to get it to compile with gfortran:
>
> Comparing files x0.f and X.F
> ***** x0.f
> c
>       character*80 amdbname /'bam:amdb.dat'/
>       character*80 new_db_name
> ***** X.F
> c
>       character*80 amdbname /'amdb.dat'/
>       character*80 new_db_name
> *****
>
> ***** x0.f
>       character*1 cc
>       character*2 escape /'1B'x/
>       logical ansi_crt
> ***** X.F
>       character*1 cc
>       integer*2 escape /'1B'x/
>       logical ansi_crt
> *****
>
> ***** x0.f
>       character*1 cc
>       character*2 escape /'1B'x/
>       logical ansi_crt
> ***** X.F
>       character*1 cc
>       integer*2 escape /'1B'x/
>       logical ansi_crt
> *****
>
> The first is just changing the file name. The 2nd and 3rd are hacks. I'm
> setting an integer variable to a numeric value and then (not) printing it
> with an A format.
>
> But of course there are bugs. I can't select a print file for output without
> a fatal error. I suspect that it might be a problem with unit numbers. [see
> the recent discussion in this newsgroup about a program that re-used unit
> 6...]
>
> I do think that all the OP has to do is fix up the main loop to just make a
> single pass through the file, and fix lots of bugs. I have not delved deeply
> into this program but the one optimization I would make, if possible, is to
> take the starting location and calculate the boundaries of a rectangle that
> just encloses the circle centered on the location at the specified distance.
>
> Then the logic is simple:
>
> For each recond in the input file, if it is out of the specified frequency
> range, reject.
> If it is outside the bounding rectangle, reject.
> Otherwise calculate the distance, if outside, reject, otherwise process it.
> If the frequency read from the file is greater than the upper limit, exit..
>
> The database does contain a sentinel record at then end with 9999 and a
> header record at the start with 0000.
>
> --- Elliot- Hide quoted text -
>
> - Show quoted text -

From: mecej4 on 12 Jun 2010 11:33
e p chandler wrote:

>
>>>>> 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.
>>>
<--- CUT --->
>>>--- Elliot

I located this link to a description of the "pre-2000" data. The record
structure is described in:

ftp://ftp.fcc.gov/pub/Bureaus/MB/Databases/formatted/amdiction.txt

which also contains this notice

" The FCC has redesigned and restructured the AM Engineering Data Base.
It has been converted to a relational data base. This change will take
place on or about May 1, 1997."

--mecej4

From: rfengineer55 on 12 Jun 2010 11:51
On Jun 12, 11:33 am, mecej4 <mecej4.nyets...(a)operamail.com> wrote:
> e p chandler wrote:
>
> >>>>> 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.
>
> <--- CUT --->
> >>>--- Elliot
>
> I located this link to a description of the "pre-2000" data. The record
> structure is described in:
>
>  ftp://ftp.fcc.gov/pub/Bureaus/MB/Databases/formatted/amdiction.txt
>
> which also contains this notice
>
> " The FCC has redesigned and restructured the AM Engineering Data  Base..  
> It has  been converted to a relational data base.  This change will take
> place on or  about  May  1,  1997."
>
> --mecej4- Hide quoted text -
>
> - Show quoted text -

Mecej4 -

Yes, that is very old information. The VAX 11/780 computer is also
long gone, which is the platform that these programs ran on. The
current software is by V-soft, which sels for about $20,000.00 for a
package.

There is also information o the FCC FTP site about their current data
layout and location of data fields, etc. You might want to take a look
at that to learn more about how they are doing things now.

RF ENGINEER55
From: Erik Toussaint on 12 Jun 2010 13:08
On 12-6-2010 15:21, e p chandler wrote:
>
> "mecej4" <mecej4.nyetspam(a)operamail.com> wrote in message
> news:huvt58$du0$1(a)news.eternal-september.org...
>>
>> 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
>
> I don't have that file. I just substituted an empty file for AMKEYS.INC.

I googled the domain fcc.gov for the keyword fortran and found the
following page:

http://www.fcc.gov/oet/info/software/vaxcode/

It has a link to a zip file containing the old source files with VAX
FORTRAN code formerly used by the FCC. (The file size is actually 7.7
_MB_, not 7.8 _kB_ as stated on that page.)

If I'm not mistaken, the OP is trying to compile the code in the
directory /allo inside this zip file. It also has the AMKEYS.INC file,
which contains no declarations or executable statements, only comments
describing the keys used in the AMDB.DAT database.

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