Run-time \"error\" when writing a file

I have run across a problem using TRANSPARENT to create a file. I have two different methods of creating the file (shown below) but one of these has an 'occasional' problem.

The file contains printer command codes for driving a graphic printer directly. The data are generated by the remainder of the code (too big to post) which creates an in-memory image of the rasterized data. I chose TRANSPARENT to allow the CRLF characters to NOT be transmitted unless needed.

And one byte is missing from the file (actually, many, but the first one can be easily found). I ran both methods of file generation (below), and the one that does not use the building of a character string in memory containing the raster data fails.

The binary comparison of the two files shows the following first error occurrence.

Comparing files output_fixed.plt and OUTPUT_NOTFIXED.PLT (Binary compare)
00002117: 20 00
00002119: 00 18
0000211A: 18 00
0000211C: 00 06
0000211D: 06 FF
00002120: FF 00
0000213B: 00 1F
0000213C: 1F FF
0000213D: FF F8

The code segment that fails is:

	open(unit=99,file='output_notfixed.plt',access='transparent',
     $	form='formatted',status='replace',iostat=icheck)
.
.
.
99000	format(99a1)
	i=0
	do 30060 jj4=0,ii4
	write(99,99000)RASTER_VERTICAL_C(i4,jj4),
     $	RASTER_VERTICAL_C(i4+1l,jj4),
     $	RASTER_VERTICAL_C(i4+2l,jj4)
30060	continue

The code segment that works is:

	open(unit=99,file='output_fixed.plt',access='transparent',
     $	form='formatted',status='replace',iostat=icheck)
.
.
.

99000	format(99a1)
	i=0
	do 30060 jj4=0,ii4
	i = i + 1
	raster_master(i:i)=RASTER_VERTICAL_C(i4,jj4)
	i = i + 1
	raster_master(i:i)=RASTER_VERTICAL_C(i4+1L,jj4)
	i = i + 1
	raster_master(i:i)=RASTER_VERTICAL_C(i4+2L,jj4)
30060	continue
	write(99,99001)raster_master(1:i)
99001	format(a)

When comparing the two files, they differ in size by 2306 bytes. There are 350 of these graphic outputs performed; it is likely (just based on file size) that there are more than one byte missing in these data, but it is too difficult to look through 300K of data to find them.

The compile options used for this code are: /DEFINT_KIND 2 /silent /SAVE /ZEROISE /FPP /CFPP /WINDOWS

The extra character looks to be a hex 20, which is a space character, probably associated with the format statement. Have you written a zero-length string, which may provide a minimum of 1 space character ?

Why do you open it as formatted ? You could open the file as unformatted and then write the info, omitting the format statement number. I'd expect this would produce the same file. ( checking that I >=1)

John

It's a pain, but the fact that this occurrence is a SPACE character may be incidental. Note that the format is all 99A1. There are a LOT of other characters missing from the file (difference in byte counts).

Looking at the two sections of code, there is nothing substantially different. The non-working version was supposed to be transitional to the working code in any case, except that it should work as well. Perhaps there is something with trailing spaces that this is affecting (?).

If you open it as formatted, then you ALWAYS get the CRLF combination at the end, and that is NOT necessarily what one needs when doing raster graphics to a print device. The CRLF combination may lead to spaces (blank sections) in the displayed/printed graphics. TRANSPARENT is supposed to remove the CRLF at the end; if it removes a trailing space, then that's probably the culprit for all the missing data. However, if it does, then it doesn't meet the definition of TRANSPARENT in the documentation (at least not the way I read it).

I'm getting pretty good at the 'C' to FTN95 interface, and if I have to, I can make sure to get around a trailing SPACE problem as well. But, I'd prefer not to!

I have only used TRANSPARENT with UNFORMATTED. I have not found the problems you are describing.

Try changing to UNFORMATTED in the OPEN. All you need to do is remove the format number in the WRITE and I'd recommend checking as:

IF ( I >= 1) then WRITE (99) raster_master(1:i) else write (,) 'zero length string request' end if

Also find all use of unit 99, you never know !

John

I am going to give the UNFORMATTED version a shot. More investigation to follow.

The only unit I open explicitly as 99 is for this usage. All other FTN units are opened/closed in a common routine that returns a FTN unit number as transparently as possible. That way, on different platforms, I need only to change the one routine. Unit 99 is convenient for me because it is not in the list of possible units for other portions of the software.

Eventually, even 99 will disappear as I will incorporate this TRANSPARENT open into the common utility for even this narrow usage, and use the transparently assigned unit number.

Rather than using the nonstandard extension TRANSPARENT, please consider using ACCESS='STREAM', which is covered by the Fortran standard and would make your code portable.

Great idea using STREAM.

However, this yields a compiler error that STREAM is not a valid option for the keywords ACCESS. FTN 2003?

0269)         open(unit=99,file='\\\\speedypc\\generic',access='stream',
0270)      $  form='unformatted',status='replace',iostat=icheck)
*** 'stream' is not a valid option for the ACCESS keyword, valid options are 'SEQUENTIAL', 'DIRECT', 'TRANSPARENT' and 'APPEND'
    1 ERROR  [<PLOT> FTN95/Win32 v7.10.0]

I have run across this many times since starting this project in 1982, where a particular OS will have small/large changes in syntax and/or options when opening or closing files. That's why my common file open/close routine was created, to isolate all of those idiosyncrasies to one place, and the remainder of the code need not change.

This technique has proved exceptionally useful; I am able to create a direct interface between FTN95 and my PDF creation code, written in 'C', allowing my programs to directly generate PDF output.