forums.silverfrost.com

[clint]

I'd be grateful for a reference to the following function, as it isn't in the help files

[PaulLaidler]

Clint

INQR@@ is an internal and undocumented FTN77/FTN95 routine. Presumably it was supplied as a result of a support contract with Salford Software. It appears to be an inquiry routine that checks and reports the state of an IO stream. My guess is that it was used as a work-around for a problem with FTN77 and that it is redundant in FTN95. In any case it will only be used to report the state of the IO stream rather than to change its state.

READFA@ is documented in the help file. It is a low level read routine but, without trying it, I am not sure if it can be used for buffered input (i.e. for reading one block after another).

[clint]

I'm afraid I still need to know about the INQR@@ function.
I need to know the meaning of the arguments.
Do you have a function that can be used to derive a handle for READFA@ from a unit from OPEN?

(The code appears to use a user defined device driver.)

[PaulLaidler]

Clint

The standard approach is to use OPENR@ with a handle that you specify and then you use READFA@ to read the file.

If you use the standard Fortran OPEN then you must use INQR@@ to associate a given handle with a given unit number. The handle and the associated error return must be of type INTEGER(2).

If it turns out that you need to use OPEN rather than OPENR@ because of the user defined device driver then we may need to charge you for the time involved to get the information you need.

[Martin]

INQR@@ is a (very) low level version of the standard INQUIRE statement. I can't think of a reason why you would use it instead of INQUIRE.

It can take a variable number of arguments. The first is always the number of additional arguments as a 16 bit integer. In your case you are passing 4, which means only the first 4 additional arguments will be used - the "267_2,ierror,28_2" arguments will be ignored.

The additional arguments come in (option, value) pairs. The option should be a 16 bit integer with the most significant 8 bits specifying the data type of the value and the least significant 8 bits specifying the option code.

The value data type can be one of the following: TYPE_null=0, TYPE_INTEGER_2=1, TYPE_INTEGER_4=2, TYPE_REAL_4=3, TYPE_REAL_8=4, TYPE_COMPLEX_8=5, TYPE_COMPLEX_16=6, TYPE_LOGICAL_2=7, TYPE_LOGICAL_4=8, TYPE_CHARACTER=9, TYPE_INTEGER_1=10, TYPE_LOGICAL_1=11, TYPE_REAL_10=12, TYPE_COMPLEX_20=13, STRUCT_TYPE=14, TYPE_INTEGER_8=15

The option code can be one of the following: IO_null=0, IO_ACCESS=1, IO_BLANK=2, IO_DIRECT=3, IO_END=4, IO_ERR=5, IO_EXIST=6, IO_FILE=7, IO_FMT=8, IO_FORM=9, IO_FORMATTED=10, IO_IOSTAT=11, IO_NAME=12, IO_NAMED=13, IO_NEXTREC=14, IO_NUMBER=15, IO_OPENED=16, IO_DA_REC=17, IO_RECL=18, IO_SEQUENTIAL=19, IO_STATUS=20, IO_UNFORMATTED=21, IO_UNIT=22, IO_FILETYPE=23, IO_FUNIT=24, IO_RENAME=25, IO_ANSI=26, IO_Internal_File_Address=27, IO_Pseudo_ERR=28, IO_Star=29, IO_Encode_Decode_Count=30, IO_Run_Time_Format=31, IO_Non_Char_Format_Array=32, IO_Non_Char_Internal_File=33, IO_Records_In_Internal_File=34, IO_Records_In_Run_Time_Format=35, IO_Assign_Format=36, IO_DEVICE=37, IO_UNIT_and_NOIOTRUNCATION=38, IO_UNIT_and_LUNFREC=39, IO_UNIT_and_both=40, IO_NML=41, IO_TRANSPARENT=42, IO_SHARE=43, IO_POSITION=44, IO_ACTION=45, IO_DELIM=46, IO_PAD=47, IO_ADVANCE=48, IO_SIZE=49, IO_EOR=50, IO_READWRITE=51, IO_LENGTH=52, IO_READ=53, IO_WRITE=54, IO_stack_setting=55, IO_FTN95_Internal=56, IO_NEWIO_END=57, IO_NEWIO_EOR=58, IO_NEWIO_ERR=59, IO_NEWIO_FMT=60

In your case, you have (534_2,iunit), (280_2,ihandle), (267_2,ierror), and 28_2 by itself. This most closely resembles INQUIRE (UNIT=iunit, FUNIT=ihandle, IOSTAT=ierror), with iunit being a 32 bit integer, and ihandle and ierror as 16 bit integers. The 28_2 represents a pseudo ERR= specifier, and should have a label as a value.

In the more recent versions of FTN95 (possibly as early as version 2.54) the FUNIT specifier has been removed. This was used to allow files opened with the OPEN statement to be used with our low level read routines such as READFA@, but due to internal changes it was no longer possible to support this feature. You must now use one of our low level open routines, such as OPENRW@, instead.

If you switched to a low level open routine then you would not need the inqr@@ call. However, if you are using an older version of FTN95 and wish to keep using the standard OPEN statement you should fix the problems with the INQR@@ statement noted above, i.e. the first argument should specify that their are 8 arguments, and a label should be passed as the last argument - which will be jumped to on error.


Martin