Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

forrtl: severe (24): end-of-file during read, unit 1

2,230 views
Skip to first unread message

maji...@gmail.com

unread,
Aug 26, 2014, 11:56:01 PM8/26/14
to
Dear all,

can Every body tell me about the following error.
I ran the code with 500000 steps with out any problem but when I ran the code with 5000000 steps the error occurred. Please share your comments. I really need them.

Thanks in Advance

forrtl: severe (24): end-of-file during read, unit 1, file /home/majid/140820-1700-New/140820-New/Production-Step/140825-9000-g0.006/HISTORY
Image PC Routine Line Source
NUMdensity.ex 000000000042426A Unknown Unknown Unknown
NUMdensity.ex 0000000000403E1B Unknown Unknown Unknown
NUMdensity.ex 0000000000402BE6 Unknown Unknown Unknown
libc.so.6 00007F81DADF676D Unknown Unknown Unknown
NUMdensity.ex 0000000000402AD9 Unknown Unknown Unknown



My codes

PROGRAM density
IMPLICIT none

INTEGER :: iii,natoms,stepinterval,steptotal,nsteps,istep,iatom
INTEGER, ALLOCATABLE :: pp(:)!,prob(:)
REAL :: box(3),zmin,zmax,length
REAL, ALLOCATABLE :: XXX(:,:,:)
CHARACTER*3, ALLOCATABLE :: atomtype(:)
CHARACTER*8 :: arg,clength!,cbin
CHARACTER*80 :: filename


filename="none"
clength="0.0"
!cbin="0.0"



iii=1
DO WHILE (.TRUE.)
CALL GETARG(iii,arg)

IF (TRIM(arg) .eq. "-f") THEN
iii=iii+1
CALL GETARG(iii,filename)
ELSE IF (TRIM(arg) .eq. "-l") THEN
iii=iii+1
CALL GETARG(iii,clength)
!ELSE IF (TRIM(arg) .eq. "-b") THEN
! iii=iii+1
! CALL GETARG(iii,cbin)
ELSE
EXIT
END IF
iii=iii+1
END DO

IF (TRIM(filename) .eq. "none") THEN
print *, ""
print *, "----------------------------------------------------------------"
print *, "density.ex"
print *, " ."
print *, " "
print *, ""
print *, "----------------------------------------------------------------"
print *, "Run options:"
print *, "density.ex -f HISTORY -l 40"
print *, " -f: (filename) DL_Poly HISTORY force co-ordinate output file"
print *, " -l: length of pore, length"
!print *, " -b: (bin) Number of bins along z direction"
print *, " The selection of bin number should consider both of nanopore and pool. Total length of z dimention= box(3)"
print *, ""
print *, "----------------------------------------------------------------"
STOP
END IF

READ(clength,'(F4.0)') length
!READ(cbin,'(F4.0)') bin
!print *, "Number of bins:", bin


CALL data_range(filename,natoms,stepinterval,steptotal)
!Output data: natoms,stepinterval,steptotal
nsteps=steptotal/stepinterval
!print *,"number of output steps: ", nsteps

ALLOCATE(atomtype(natoms), XXX(nsteps,natoms,3))
CALL read_history(atomtype,natoms,nsteps,filename,XXX,box)
!Output data: atomtype,XXX,box

print *, "Finish read HISTORY file..."




ALLOCATE(pp(nsteps))
!ALLOCATE(prob(nsteps))
pp=0
!prob=0
!nsteps=10


DO istep=1,nsteps

DO iatom=1,natoms

IF (atomtype(iatom) .eq. "OW ") THEN

zmin=-box(3)/2
zmax=-box(3)/2+length

IF ((XXX(istep,iatom,3) .ge. zmin) .AND. (XXX(istep,iatom,3) .le. zmax)) THEN

pp(istep)=pp(istep)+1

!prob(pp(istep))=prob(pp(istep))+1
!prob(pp(istep))=prob(pp(istep))/nsteps

END IF

END IF

END DO
!print *,istep, pp(istep)
END DO


OPEN(1,FILE="Analysis/density.dat")

DO istep=1,nsteps
!
WRITE (1,*) istep, pp(istep)

END DO
CLOSE(1)


END PROGRAM density







SUBROUTINE data_range(filename,natoms,stepinterval,steptotal)
IMPLICIT none

INTEGER, INTENT(OUT) :: natoms, stepinterval, steptotal
CHARACTER*80, INTENT(IN) :: filename

print *, "Determining measurement parameters..."

! Get total number of steps
CALL SYSTEM("tail -100000 " // TRIM(filename) // " | grep timestep | tail -1 | awk '{ print $2 }' > out.tmp")
OPEN(1,FILE="out.tmp")
READ(1,*) steptotal
CLOSE(1)

! Get print interval
CALL SYSTEM ("head -100000 " // TRIM(filename) // " | grep timestep | head -1| awk '{ print $2 }' > out.tmp")
OPEN(1,FILE="out.tmp")
READ(1,*) stepinterval
CLOSE(1)

! Get number of atoms
CALL SYSTEM("head -100000 " // TRIM(filename) // " | grep timestep | head -1 | awk '{ print $3 }' > out.tmp")
OPEN(1,FILE="out.tmp")
READ(1,*) natoms
CLOSE(1)

! Clean up
CALL SYSTEM("rm out.tmp")

END SUBROUTINE data_range






SUBROUTINE read_history(atomtype,natoms,nsteps,filename,XXX,box)
IMPLICIT none

INTEGER :: iatom, istep, istepp, nnn, mmm, kkk, vvv
INTEGER,INTENT(IN) :: natoms, nsteps
REAL,INTENT(OUT) :: box(3),XXX(nsteps,natoms,3)
REAL :: rubbish, tstep,readsuccess
CHARACTER*80 :: header
CHARACTER*80,INTENT(IN) :: filename
CHARACTER*8 :: crubbish
CHARACTER*3,INTENT(OUT) :: atomtype(natoms)


print *, "Reading data..."

OPEN (1,FILE=filename) ! Open file to read positions

READ(1,'(A80)') header ! Read header

READ(1,*) nnn, kkk, vvv

DO istep=1,nsteps
readsuccess=0
READ(1,*,err=99991) crubbish, istepp, vvv, kkk, nnn, tstep ! Read the step number
readsuccess=1

READ(1,*) box(1), rubbish, rubbish ! Read the 1st dimensions of the box
READ(1,*) rubbish, box(2), rubbish ! Read the 2nd dimensions of the box
READ(1,*) rubbish, rubbish, box(3) ! Read the 3th dimensions of the box

DO iatom=1,natoms

READ(1,*) atomtype(iatom),mmm,rubbish,rubbish
READ(1,*) XXX(istep,iatom,1:3)
READ(1,*) rubbish,rubbish ,rubbish
READ(1,*) rubbish,rubbish ,rubbish

END DO

IF (readsuccess .eq. 0) THEN
WRITE (*,'(A,I8,A)') "Restart point foud (",istep,").Continuing."
READ(1,*) header

END IF
END DO
99991 CONTINUE
CLOSE(1)

END SUBROUTINE read_history



A part of My HISTORY FILE

New Box 2.0A
2 2 11922
timestep 500 11922 2 2 0.000200
50.00 0.000 0.000
0.000 50.00 0.000
0.000 0.000 180.0
C 1 0.000000 0.000000
1.1500E+01 0.0000E+00 -9.0000E+01
0.0000E+00 0.0000E+00 0.0000E+00
0.0000E+00 0.0000E+00 0.0000E+00
C 2 0.000000 0.000000
1.1488E+01 5.2342E-01 -9

glen herrmannsfeldt

unread,
Aug 27, 2014, 12:48:53 AM8/27/14
to
maji...@gmail.com wrote:

> can Every body tell me about the following error.
> I ran the code with 500000 steps with out any problem but
> when I ran the code with 5000000 steps the error occurred.
> Please share your comments. I really need them.

(snip)

> forrtl: severe (24): end-of-file during read, unit 1, file /home/majid/140820-1700-New/140820-New/Production-Step/140825-9000-g0.006/HISTORY

(big snip)

> DO istep=1,nsteps
> readsuccess=0
> READ(1,*,err=99991) crubbish, istepp, vvv, kkk, nnn,
> tstep ! Read the step number
> readsuccess=1

Why is there an ERR= on this READ, but not the later ones?

Just wondering, did you want and END= on the read?
As I understand it (though I rarely use ERR=) if it is actually
end of file, it won't use the ERR= branch.

It isn't so easy to follow, but since this in inside the nsteps loop,
there must be enough data in the file to correspond to an increased
number of steps.

-- glen

-- glen




maji...@gmail.com

unread,
Aug 27, 2014, 1:04:37 AM8/27/14
to
Dear Glen

Thank you for your comment. I removed ERR= and reran the code by gfortran. But the following error happened. I dont know why?

At line 194 of file NUMdensity.f90 (unit = 1, file = 'HISTORY')
Fortran runtime error: End of file

e p chandler

unread,
Aug 27, 2014, 1:56:46 AM8/27/14
to
The OP wrote

> I ran the code with 500000 steps with out any problem but when I ran the
> code with 5000000 steps
> the error occurred. Please share your comments. I really need them.

> forrtl: severe (24): end-of-file during read, unit 1, file [path to file]
> Image PC Routine
> Line Source
> NUMdensity.ex 000000000042426A Unknown Unknown
> Unknown

[snip]

It seems that the program was compiled without the "traceback" option so we
don't know *exactly* where it fails.
That option would have helped. However, the error message *is* quite
informative. The end-of-file error says that your input data file did not
have
as much data as you expected - and the error takes place in the input data
file reading subroutine.

Your earlier version and this version both calculate the number of steps
from the input data file itself. Are you saying that when the input
data file actually contains 5 million sets of data that the program fails to
read them all?

What does

> CALL data_range(filename,natoms,stepinterval,steptotal)
> nsteps=steptotal/stepinterval
> !print *,"number of output steps: ", nsteps

return for values? You have commented out the diagnostic print statement
that would have told you.

What data have you read before your program fails? I usually print out what
I have just read in to see if it matches
1) what I expect
2) the actual data in the file
inside the read subroutine.

----- start text ----
---- end text ---

PRINT out steptotal, stepinterval and natoms before the routine returns.

---- start text ----
!!!! You never execute this piece of code. ON error you go to the CONTINUE
statement
!!! So if your intention is to "re-sync" with the data file, it does not do
that.

END DO
99991 CONTINUE
CLOSE(1)

END SUBROUTINE read_history

A part of My HISTORY FILE

New Box 2.0A
2 2 11922
timestep 500 11922 2 2 0.000200
50.00 0.000 0.000
0.000 50.00 0.000
0.000 0.000 180.0
C 1 0.000000 0.000000
1.1500E+01 0.0000E+00 -9.0000E+01
0.0000E+00 0.0000E+00 0.0000E+00
0.0000E+00 0.0000E+00 0.0000E+00
C 2 0.000000 0.000000
1.1488E+01 5.2342E-01 -9

---- end text ----

It looks like your input data reading code matches your input data so
far....
I do think you could read your "parameters" directly from the input file in
Fortran. Note that your SYSTEM calls are not portable and that your choice
of pipelines and use of AWK is strained IMO.

--- e

Richard Maine

unread,
Aug 27, 2014, 2:11:24 AM8/27/14
to
e p chandler <ep...@juno.com> wrote:

> I do think you could read your "parameters" directly from the input file in
> Fortran. Note that your SYSTEM calls are not portable and that your choice
> of pipelines and use of AWK is strained IMO.

I might also note that, although it probably isn't the problem in this
case, I generally recommend against using unit numbers less than 10. If
you do happen to hit a conflict with a system unit number, the results
can be *VERY* confusing.

Also, using the same unit number for different files is just asking for
confusion. Looks offhand as though the usage is ok because the usage
doesn't overlap in time, but it still invites user confusion about which
file is the problem.

There appears to be enough confusion already that inviting more of it
can't help.

I need to run and don't have time to really study the code, but then it
looks like E P is doing a decent job of that.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

maji...@gmail.com

unread,
Aug 27, 2014, 3:03:19 AM8/27/14
to
Dear E P,

Thanks for your attention. My input file is HISTORY file that contains positions , velocity and force data. Before reading History file it should be determined "steptotal and stepinterval". But when I do print out steptotal and steptotal the following error happened.

At line 143 of file NUMdensity.f90 (unit = 1, file = 'out.tmp')

maji...@gmail.com

unread,
Aug 27, 2014, 3:24:29 AM8/27/14
to
On Wednesday, August 27, 2014 2:56:46 PM UTC+9, e p chandler wrote:
Dear E P,

After running I did print out nsteps and natoms in the section (CALL data-rang) and it was cleared I have nsteps=1423 and natoms=11922. I dont know why the error is happening. Please share your comment. What Did you mean about that i dont have as much data as I expected? Please help me

Louis Krupp

unread,
Aug 27, 2014, 8:47:03 AM8/27/14
to
On Wed, 27 Aug 2014 00:24:29 -0700 (PDT), maji...@gmail.com wrote:

>Dear E P,
>
>After running I did print out nsteps and natoms in the section (CALL data-rang) and it was cleared I have nsteps=1423 and natoms=11922. I dont know why the error is happening. Please share your comment. What Did you mean about that i dont have as much data as I expected? Please help me

Your data files are organized as a set of records. If you try to read
ten records from a file that contains only nine records, you'll get an
error.

My thoughts:

As someone else suggested, if you haven't already compiled your
program to enable traceback information, do it.

Use different file names for your temporary files and don't remove
them. You'll be able to look at them later and see if they contain
what you think they should.

Find out how many records your file(s) contain. If they're text
files, records are basically lines of text. If you're on some
variation of UNIX, "wc -l <filename>" will give you what you want.

Consider breaking your program into smaller pieces and getting one bit
to work at a time. This will make debugging easier, too.

Louis

e p chandler

unread,
Aug 27, 2014, 10:44:30 AM8/27/14
to
On Wednesday, August 27, 2014 3:24:29 AM UTC-4, maji...@gmail.com wrote:
> On Wednesday, August 27, 2014 2:56:46 PM UTC+9, e p chandler wrote:
> > The OP wrote
> > > I ran the code with 500000 steps with out any problem but when I ran the
> > > code with 5000000 steps
> > > the error occurred. Please share your comments. I really need them.
> > > forrtl: severe (24): end-of-file during read, unit 1, file [path to file]

[snip my comments and the original code]

> After running I did print out nsteps and natoms in the section
> (CALL data-rang) and it was cleared I have nsteps=1423 and natoms=11922. I
> dont know why the error is happening. Please share your comment.
> What Did you mean about that i dont have as much data as I expected?
> Please help me

Your program tells you that you have 1423 blocks of data in your input file.
So if you are trying to read five hundred thousand blocks of such data or five million blocks of such data, you are going to exhaust all of the data in the file.

My approach to this is systematic.

1. How much data is actually in the file?
2. How did you determine fact #1?
3. How much data does your program say is in the file?
4. How many blocks of data are you trying to read?
5. At what step number does your read process stop with an end of file error?
6. What data did you read in just before your program failed?
7. What position does this correspond to in your input data file?
8. What data are you trying to read when the program fails?
9. Where are you reading from in your data file?
10. What data is located there when your read fails?

---- e

[Programming can be dull, tedious and boring. It's still more fun than bookkeeping or payroll.]

mecej4

unread,
Aug 27, 2014, 2:06:40 PM8/27/14
to
On 8/27/2014 2:24 AM, maji...@gmail.com wrote:
> On Wednesday, August 27, 2014 2:56:46 PM UTC+9, e p chandler wrote:
>> The OP wrote
>>
>>
>>
>>> I ran the code with 500000 steps with out any problem but when I ran the
>>
>>> code with 5000000 steps
>>

>> ! Get total number of steps
>> CALL SYSTEM("tail -100000 " // TRIM(filename) // " | grep timestep | tail -1 | awk '{ print $2 }' > out.tmp")
>> CALL SYSTEM ("head -100000 " // TRIM(filename) // " | grep timestep | head -1| awk '{ print $2 }' > out.tmp")
>> CALL SYSTEM("head -100000 " // TRIM(filename) // " | grep timestep | head -1 | awk '{ print $3 }' > out.tmp")
>>
> After running I did print out nsteps and natoms in the section (CALL data-rang) and it was cleared I have nsteps=1423 and natoms=11922. I dont know why the error is happening. Please share your comment. What Did you mean about that i dont have as much data as I expected? Please help me
>
Most of us do not know what your program does and what the input data
file contains, and there is not much that we can do if the data file has
errors. We simply do not have the background information needed to help
you in that regard.

Unless your input file "his.txt" has more than 100,000 lines and more
than one line with "timestep" it, the first two calls to SYSTEM and the
subsequent reads of OUT.TMP will put the *same value* into variables
STEPTOTAL and STEPINTERVAL. This is probably an error. Nor do I see
"1423" in the portion of your file HIS.TXT that you showed.

Nevertheless, the number of lines expected in subroutine READ_HISTORY
from the input data file is [(natoms+1)*4]*nsteps+2. For the values that
you listed in the last line quoted above, that would be 67,865,718. Do
you have nearly 68 million lines in your data file?

By the way, please don't try to post a file of that size in a USENET post.

-- mecej4

Paul van Delst

unread,
Aug 27, 2014, 2:57:56 PM8/27/14
to
I would hazard a guess that, during a read operation from a file called
"HISTORY", you are reaching the end-of-file?

Apologies for the sarcasm, but the error message that is being reported
is one of the clearer ones.

cheers,

paulv

On 08/26/14 23:56, maji...@gmail.com wrote:
> Dear all,
>
> can Every body tell me about the following error. I ran the code with
> 500000 steps with out any problem but when I ran
> the code with 5000000 steps the error occurred. Please share your
> comments. I really need them.
>
> Thanks in Advance
>
> forrtl: severe (24): end-of-file during read, unit 1, file
/home/majid/140820-1700-New/140820-New/Production-Step/140825-9000-g0.006/HISTORY
> Image PC Routine Line Source
> NUMdensity.ex 000000000042426A Unknown Unknown Unknown
> NUMdensity.ex 0000000000403E1B Unknown Unknown Unknown
> NUMdensity.ex 0000000000402BE6 Unknown Unknown Unknown
> libc.so.6 00007F81DADF676D Unknown Unknown Unknown
> NUMdensity.ex 0000000000402AD9 Unknown Unknown Unknown
>
[big snip]

maji...@gmail.com

unread,
Aug 27, 2014, 9:22:21 PM8/27/14
to
Dear All,

Thank you very very much for your attention. I tried to ran the program with nsteps=500 and natoms=11922. The program was correctly ran. Then I did run the program with nsteps=1423 and natoms=11922. However the following error happened again.

forrtl: severe (24): end-of-file during read, unit 1, file [path to file]

When I did ran the program with "gfortran" instead of "ifort" the program tells me the error is related to

At line 195 of file density.f90 (unit = 1, file = 'HISTORY')
Fortran runtime error: End of file

line 195 "READ(100,*) atomtype(iatom),mmm,rubbish,rubbish"


I checked the input file (HISTORY) but everything is right. I am really confused. has anybody no idea?

glen herrmannsfeldt

unread,
Aug 27, 2014, 10:15:06 PM8/27/14
to
maji...@gmail.com wrote:

(snip)

> Thank you very very much for your attention.
> I tried to ran the program with nsteps=500 and natoms=11922.
> The program was correctly ran. Then I did run the program with
> nsteps=1423 and natoms=11922. However the following error
> happened again.

> forrtl: severe (24): end-of-file during read, unit 1, file [path to file]

> When I did ran the program with "gfortran" instead of "ifort"
> the program tells me the error is related to

> At line 195 of file density.f90 (unit = 1, file = 'HISTORY')
> Fortran runtime error: End of file

> line 195 "READ(100,*) atomtype(iatom),mmm,rubbish,rubbish"

> I checked the input file (HISTORY) but everything is right.
> I am really confused. has anybody no idea?

We assume that you understand the program better than we do.

You say the file is correct, but it seems more like that it isn't.

Do remember that list directed ( with * for format) will read as
many input lines (records) as needed to satisfy the I/O list.

And values past the last one on the last record read will be ignored,
and not supplied to the next READ statement.

Those two things can be confusing to some not used to the
way Fortran I/O works.

Otherwise, put a WRITE statement after each READ, what writes out
the values just read. At the beginning of each, in addition to the
values printed, print out an unusual character, different for
each WRITE, such that you can be sure which values come from which
READ (and WRITE).

Otherwise, it might be enough to put an END= on the indicated READ,
and, at the specified line, print out the value of iatom. That will
tell you how far it got through the file, and help figure out why
it is there.

There are a large number of ways to get READ wrong.

-- glen

e p chandler

unread,
Aug 28, 2014, 12:30:17 AM8/28/14
to
maji...@gmail.com wrote:

> Thank you very very much for your attention. I tried to ran the program
> with nsteps=500 and natoms=11922. The program was correctly ran.
> Then I did run the program with nsteps=1423 and natoms=11922. However the
> following error happened again.

> forrtl: severe (24): end-of-file during read, unit 1, file [path to file]
> line 195 "READ(100,*) atomtype(iatom),mmm,rubbish,rubbish"

Please confirm that you used two different HISTORY files for your two runs.

How do you know that file #2 actually has 1423 blocks worth of data in it?

Do you know that file #2 contains only the expected data and nothing else?

If all of these are true, then there is something wrong with the SYSTEM
commands that determine NSTEPS, etc.

To test this out, replace

CALL data_range(filename,natoms,stepinterval,steptotal)
!Output data: natoms,stepinterval,steptotal
nsteps=steptotal/stepinterval

with

! CALL data_range(filename,natoms,stepinterval,steptotal)
!Output data: natoms,stepinterval,steptotal
!nsteps=steptotal/stepinterval
nsteps=1423

and try file #2 again.

If you still see the end-of-file error, then set nsteps to a lower value
until it works.
What is the largest value of NSTEPS for which the program works on file #2?

---- e






e p chandler

unread,
Aug 28, 2014, 12:37:01 AM8/28/14
to
"glen herrmannsfeldt" wrote
>> majid....@gmail.com wrote:

>> Thank you very very much for your attention.
>> I tried to ran the program with nsteps=500 and natoms=11922.
>> The program was correctly ran. Then I did run the program with
>> nsteps=1423 and natoms=11922. However the following error
>> happened again.

>> forrtl: severe (24): end-of-file during read, unit 1, file [path to file]

>> When I did ran the program with "gfortran" instead of "ifort"
>> the program tells me the error is related to

>> At line 195 of file density.f90 (unit = 1, file = 'HISTORY')
>> Fortran runtime error: End of file

>> line 195 "READ(100,*) atomtype(iatom),mmm,rubbish,rubbish"

>> I checked the input file (HISTORY) but everything is right.
>> I am really confused. has anybody no idea?

> We assume that you understand the program better than we do.
> You say the file is correct, but it seems more like that it isn't.
[snip]

Or the routine that determines the values for NATOMS and NSTEPS is faulty.
I suggested in a different message that the OP simply set the value of
NSTEPS directly instead of calling the first subroutine as an aid to finding
the source of the problem.

IMO this has gotten long winded because the OP has violated one of
"Richard's Rules" - "Don't tell me, show me."

---- e



maji...@gmail.com

unread,
Aug 28, 2014, 12:40:33 AM8/28/14
to
Dear All,

Thank you so much for all your comments and suggestions. Finally I could fix the problem with your cooperations. Thank you again

Have a good time everbody

glen herrmannsfeldt

unread,
Aug 28, 2014, 3:18:16 AM8/28/14
to
maji...@gmail.com wrote:

(snip, I wrote)

>> You say the file is correct, but it seems more like that it isn't.

>> Do remember that list directed ( with * for format) will read as
>> many input lines (records) as needed to satisfy the I/O list.
>> And values past the last one on the last record read will be ignored,
>> and not supplied to the next READ statement.

(snip)

>> There are a large number of ways to get READ wrong.

> Thank you so much for all your comments and suggestions.
> Finally I could fix the problem with your cooperations.
> Thank you again

It is nice to those who made suggestions to tell, in the end,
what the problem was. For one, it may be useful to someone
else, later, with a similar problem.

-- glen

e p chandler

unread,
Aug 28, 2014, 8:30:42 AM8/28/14
to


"glen herrmannsfeldt" wrote in message
news:ltml3o$nfs$1...@speranza.aioe.org...

maji...@gmail.com wrote:

(snip, I wrote)

>> You say the file is correct, but it seems more like that it isn't.

>> Do remember that list directed ( with * for format) will read as
>> many input lines (records) as needed to satisfy the I/O list.
>> And values past the last one on the last record read will be ignored,
>> and not supplied to the next READ statement.

(snip)

>> There are a large number of ways to get READ wrong.

majid....@gmail.com wrote:

> Thank you so much for all your comments and suggestions.
> Finally I could fix the problem with your cooperations.
> Thank you again

glen hermannsfeldt replied:

> It is nice to those who made suggestions to tell, in the end,
> what the problem was. For one, it may be useful to someone
> else, later, with a similar problem.

Yes. That would be nice.

[very bad joke warning]
Or we could film a new TV game show similar to "What's My Line?" based on
this newsgroup. {Contestants try to stump the panel by revealing little bits
of information at a time.....}

---- e




0 new messages