FOR$ – FORTRAN Support Routines

FOR$ is a call-compatible re-implementation of the OpenVMS FORTRAN run-time support library for x86 and ARM Linux. It provides the FOR$ entry points that DEC and VSI FORTRAN object code calls at run time, so migrated applications link and execute while preserving language features, execution behaviour, and system interactions. It is the runtime the compiled or translated object links against, not the compiler and not the source translator.

Two concerns dominate the library: numeric-to-text conversion through the FOR$CVT family, and record access through FOR$RAB over Sector7's RMS layer. FOR$ ships inside VX/RT and integrates with the rest of the OpenVMS run-time services on Linux, so FORTRAN applications that depend on FOR$ routines can be ported directly and keep their original behaviour.

Architecture and components

FOR$ is a linked run-time library, not a server process. There is nothing to administer: the FOR$ entry points are archived into libvxrt.a and linked directly into the migrated FORTRAN application. At run time the library owns a per-unit channel table, hands out RMS Record Access Blocks, and formats numeric values into edited character strings. The table maps each OpenVMS FORTRAN run-time concept to its Linux implementation.

OpenVMS concept	FOR$ implementation	Role	Status
`FOR$CVT_D_TE` (D_float to text)	Base numeric converter	Formats a double into an edited output string; the shared converter behind the CVT family.	live
`FOR$CVT_G_TE` / `FOR$CVT_H_TE`	G_float and H_float converters	Format G_float and H_float values to text through the shared conversion path.	live
`FOR$RAB` (unit to RAB)	Record Access Block accessor	Validates a FORTRAN unit and returns its RMS Record Access Block.	live
FORTRAN unit to RMS channel table	Per-unit channel list	Per-unit channel table sized to the maximum unit count, allocated once at initialisation.	live
OPEN / CLOSE	Record-I/O runtime	Opens and closes units, builds the FAB and RAB, and honours KEEP, DELETE, PRINT, and SUBMIT dispositions.	live
READ / WRITE / REWRITE / DELETE	Record-I/O runtime	Record read, write, update-in-place, and delete over the RMS and ISAM layer.	live
BACKSPACE / REWIND / ENDFILE / INQUIRE	Record-I/O runtime	Positioning, truncation, and INQUIRE-by-unit or by-file.	live
ERRSNS	Error-state accessor	Returns the last I/O, system, status, unit, and condition information, then clears it.	live
VMS to Unix filename translation	Filename translator	Converts a VMS file specification to a Unix path when a unit is opened.	live

No daemon to run. FOR$ is delivered as a static library inside VX/RT. The application links it directly, so there is no separate runtime service to install or manage on the Linux host.

Call lifecycle (record access path)

Translated FORTRAN object, or a FOR$ helper, reaches a unit's Record Access Block through the validated lookup below. The channel table is allocated once at initialisation:

Request

FORTRAN object calls FOR$RAB(unit)The accessor evaluates each guard in order.

Guard 01Unit in range?
No Set channel-out-of-range error state and return NULL.
Yes Look up channel table[unit].
Guard 02Unit open?
No Set unit-not-open error state and return NULL.
Yes Continue to the channel's RAB.
Guard 03RAB present?
No Set error state and return NULL.
Yes Complete the validated lookup.

All pass

Return RABDEF*The pointer identifies the unit's RMS Record Access Block.

The FORTRAN I/O statements (OPEN, READ, WRITE, and the rest) sit on the same per-unit channel table and delegate record storage to Sector7's RMS and ISAM layer, so record organisation and access order match the original OpenVMS behaviour.

Callable FOR$ routines

FOR$ exports four public entry points. Each ships in two layers in the same source module: a C-callable core, and a FORTRAN-callable wrapper that receives string arguments as a hidden VMS-style descriptor and then calls the core. The public FOR$ name is attached by an alias mechanism, so existing OpenVMS object references resolve unchanged and the FORTRAN calling convention (a trailing hidden length argument) is preserved.

FORTRAN name	Purpose	Status
`FOR$CVT_D_TE`	D_float to edited text; the base numeric converter.	live
`FOR$CVT_G_TE`	G_float to text.	live
`FOR$CVT_H_TE`	H_float (128-bit floating) to text.	live
`FOR$RAB`	Return the RMS Record Access Block for an open FORTRAN unit.	live

Numeric conversion (the CVT family)

The three FOR$CVT routines share a single call shape and a common formatting core. They format a floating value into an edited character string, apply the OpenVMS field-overflow convention (a truncated output field is filled with asterisks), and return a condition value:

U32 FOR$CVT_x_TE( double     *inValue,
                  <descriptor> outStr,
                  long        digInFrac,   ; digits in the fractional part
                  long        scale,       ; scale factor on the integer part
                  long        digInInt,    ; digits in the integer part
                  long        digInExp,    ; digits in the exponent
                  long        flags );     ; conversion options

A successful call returns a normal status. If the edited value does not fit the caller's output descriptor, the routine overwrites the field with asterisks and returns an output-conversion error, matching the OpenVMS edit-descriptor behaviour rather than silently corrupting the buffer. FOR$CVT_G_TE and FOR$CVT_H_TE currently reach text through the same shared D_float formatting path.

Record access (FOR$RAB)

FOR$RAB returns a pointer to the RMS Record Access Block for an open FORTRAN unit, or a null pointer on error with the condition recorded in the run-time error state. It runs a fixed validation ladder before returning:

RABDEF *FOR$RAB( int *for_unit );

Check	On failure
Unit number within the valid range	Record a channel-out-of-range condition; return NULL.
Unit is open (channel table slot allocated)	Record an illegal-channel-number condition; return NULL.
A Record Access Block exists for the unit	Record a no-RAB condition; return NULL.
All checks pass	Return the unit's Record Access Block.

The maximum FORTRAN unit number is 1024. Because FOR$RAB returns a null pointer and stashes the condition rather than returning the status directly, calling code checks the error state through ERRSNS (see below) when the pointer comes back null.

Real call path (banking example)

A migrated program opens a keyed account file and takes the unit's Record Access Block to drive a keyed lookup, then reads the error state if the accessor returns null:

C     open the account master and fetch its Record Access Block
      OPEN (UNIT=ACCT_UNIT, FILE='BANKING$DATA:ACCOUNT_MASTER.DAT',
     +      ORGANIZATION='INDEXED', ACCESS='KEYED', STATUS='OLD')

      RAB = FOR$RAB (ACCT_UNIT)
      IF (RAB .EQ. 0) THEN
          CALL ERRSNS (IOERR, SYSERR, STAT, UNIT, COND)
          C ... handle the recorded condition ...
      END IF

      READ (UNIT=ACCT_UNIT, KEY=CUST_ID) ACCT_RECORD

Record access and file I/O

FOR$RAB is the public window onto a larger record-I/O runtime. The FORTRAN OPEN, READ, WRITE, REWRITE, DELETE, BACKSPACE, REWIND, ENDFILE, and INQUIRE statements are all implemented over the same per-unit channel table and delegate record storage to Sector7's RMS and ISAM layer. The table lists the record-I/O surface behind the four public entry points.

FORTRAN statement	Runtime role	Status
OPEN	Open a unit, build the FAB and RAB, and translate the VMS filename to a Unix path.	live
CLOSE	Close a unit with KEEP, DELETE, PRINT, or SUBMIT disposition.	live
READ	Record read via the RMS and ISAM layer.	live
WRITE	Record write, including the formatted-write helpers.	live
REWRITE	Update a record in place.	live
DELETE	Delete the current or a keyed record.	live
BACKSPACE / REWIND	Reposition one record back, or to the start of the file.	live
ENDFILE	Truncate the file and mark end of file.	live
INQUIRE	INQUIRE by unit or by file.	live
UNLOCK	Release a record lock held on a unit.	live

The per-unit channel

Each open unit has a channel record in a table allocated once at initialisation, sized to the maximum unit count plus one. The channel carries everything the runtime needs to service the unit, including the fields most relevant to record access:

Field	Meaning
`rab`	RMS Record Access Block, the pointer `FOR$RAB` returns.
`fab`	RMS File Access Block.
`vmsname`	Original VMS file name for the unit.
`location`	Current record number or file position.
`org`	RMS organisation (sequential, relative, or indexed).
`locking`	Locking mode: automatic, manual, or exclusive.
`rec_len` / `blksiz`	Record length and buffer size.
`magic`	Integrity check confirming the slot is a live channel.

Record buffers stay compatible. The runtime reads and writes fields at the byte offsets the application's FORTRAN record declares, so record-oriented programs keep the same on-disk layout and access semantics they had under OpenVMS.

Error handling and status codes

FOR$ preserves OpenVMS FORTRAN error semantics. The conversion routines return standard status codes, the record-access routines validate the unit and open state before returning, and ERRSNS exposes the last error condition to the application exactly as it did under OpenVMS. Error state is held per thread, so a multi-threaded Linux process keeps each thread's last-error information separate.

The ERRSNS path

ERRSNS returns the last I/O, system, status, unit, and condition values, then clears the saved condition so the next call reflects only new errors. The I/O status is the RMS status mapped to a FORTRAN IOSTAT value; the system and status values come from the unit's Record Access Block:

/* FORTRAN: ERRSNS([IO_ERR][,SYS_ERR][,STAT][,UNIT][,COND]) */
void Vxf_Errsns(U32 *io_err, U32 *sys_err, U32 *stat, U32 *unit, U32 *cond)
{
    if (io_err)  *io_err  = Vxf_rms_equiv(Vxf_VMS_STATUS);      /* RMS to IOSTAT */
    if (sys_err) *sys_err = Vxf_RmsStatus(Vxf_VMS_UNIT, Value); /* RAB/FAB STV */
    if (stat)    *stat    = Vxf_RmsStatus(Vxf_VMS_UNIT, Status);/* RAB STS    */
    if (unit)    *unit    = Vxf_VMS_UNIT;
    if (cond)    *cond    = Vxf_VMS_STATUS;

    Vxf_VMS_STATUS = 0;   /* reset saved information after each ERRSNS call */
}

Run-time error codes

The FORTRAN run-time layer reports record-access failures with a small, stable set of codes:

Condition	Value	Meaning
no error	0	No error.
channel out of range	1002	Unit number outside the valid range.
file not open	1004	Unit is not open.
no RAB	1006	No Record Access Block for the unit.
no FAB	1008	No File Access Block for the unit.
illegal channel number	1010	Channel table slot is not a live channel.
invalid record	1012	Record is not valid for the operation.
record overflow	1014	Record exceeds the buffer.
illegal filename	1016	File specification could not be translated.

IOSTAT is preserved. FOR$ ships the full DEC and VSI FORTRAN IOSTAT table so that READ and WRITE error handling driven by IOSTAT values, including end-of-record and end-of-file, behaves the same on Linux as it did under OpenVMS.

Compatibility and divergences

FOR$ is built to let OpenVMS FORTRAN applications run on Linux without source changes. A few behaviours differ from the original VMS runtime by design, because the target platform differs; each divergence keeps application-visible behaviour intact while adapting to Linux.

Divergence	Reason
Error state is held per thread rather than per image.	The Linux runtime can be multi-threaded, so last-error information is kept separate for each thread.
`FOR$RAB` returns a null pointer and records the condition separately, rather than returning the status directly.	The Linux port returns the pointer type; callers consult the error state through `ERRSNS` when the pointer is null.
H_float conversion is carried on the shared double-precision path.	Linux on x86 has no native 128-bit H_float type, so H_float folds onto the shared formatter.
Filenames pass through VMS-to-Unix translation at OPEN time.	VMS file specifications are mapped to Unix paths, which RMS handled natively on OpenVMS.
Open files are closed by a registered exit handler.	Reproduces OpenVMS image-rundown file cleanup on Linux through a process exit handler.

Ships inside VX/RT. FOR$ is delivered as part of the VX/RT run-time, so a FORTRAN application picks up FOR$ conversion and record-access services alongside the rest of the OpenVMS run-time surface on x86 and ARM Linux.

Quick reference

Public FOR$ entry points

FOR$CVT_D_TE

FOR$CVT_G_TE

FOR$CVT_H_TE

FOR$RAB

Record-I/O statements serviced

OPEN

READ

WRITE

REWRITE

DELETE

BACKSPACE

REWIND

ENDFILE

INQUIRE

UNLOCK

ERRSNS

RMS file organizations

sequential

relative

indexed

Call shapes

Routine	Contract
`FOR$CVT_x_TE`	Format a floating value to edited text; return normal status, or an output-conversion error with the field filled with asterisks on overflow.
`FOR$RAB`	Return the unit's Record Access Block, or NULL with the condition recorded for `ERRSNS`.

Key facts

Item	Value
Maximum FORTRAN unit number	1024
Delivered in	VX/RT run-time, archived into `libvxrt.a`
Target platforms	x86 and ARM Linux
Error state scope	Per thread

On this page

Architecture and components

Call lifecycle (record access path)

Callable FOR$ routines

Numeric conversion (the CVT family)

Record access (FOR$RAB)

Real call path (banking example)

Record access and file I/O

The per-unit channel

Error handling and status codes

The ERRSNS path

Run-time error codes

Compatibility and divergences

Quick reference

Public FOR$ entry points

Record-I/O statements serviced

RMS file organizations

Call shapes

Key facts

Frequently Asked Questions

Curious about how Sector7 can facilitate your application migration? Explore our FAQs for expert insights.

Free Code Assessment

What is VX/FOR$ and how does it help with FORTRAN migration?

VX/FOR$ provides a call-compatible implementation of OpenVMS Fortran runtime APIs for x86 and ARM Linux. It ensures that OpenVMS Fortran applications can execute seamlessly while preserving language features, execution behavior, and system interactions.

This tool eliminates the need to rewrite complex Fortran runtime dependencies, allowing organizations to migrate legacy applications efficiently. For migration planning and implementation support, contact our team.

What specific features does VX/FOR$ support?

VX/FOR$ supports data format conversion, record access management, runtime execution, and maintains OpenVMS Fortran execution semantics to ensure consistent behavior on Linux.

Which FOR$ API functions are supported?

VX/FOR$ supports key APIs including FOR$CVT_D_TE for decimal to text conversion, FOR$CVT_G_TE for floating-point G format conversion, FOR$CVT_H_TE for hexadecimal to text conversion, and FOR$RAB for Record Access Block operations.

How does VX/FOR$ integrate with other migration tools?

VX/FOR$ seamlessly integrates with VX/RT to provide full OpenVMS Fortran runtime capabilities on x86 and ARM Linux systems.

Can VX/FOR$ handle complex record access operations?

Yes, VX/FOR$ includes full support for Record Access Block (RAB) operations, which are essential for OpenVMS applications that perform complex file I/O and data management tasks. The tool preserves the original OpenVMS behavior for these operations on Linux.

Organizations like BNY Mellon have successfully migrated complex Fortran applications with similar record management requirements.

Does VX/FOR$ require code modifications during migration?

VX/FOR$ is designed to minimize code modifications by providing call-compatible implementations of OpenVMS FOR$ APIs, allowing direct porting of applications.

How does VX/FOR$ maintain OpenVMS compatibility?

VX/FOR$ maintains full compatibility with OpenVMS FOR$ runtime functions and preserves OpenVMS Fortran execution logic. This ensures that migrated applications behave identically to their original OpenVMS counterparts, reducing testing requirements and migration risks.

What are the benefits of using VX/FOR$ for Fortran migration?

VX/FOR$ delivers significant cost and time savings by preserving existing OpenVMS Fortran execution logic and enabling direct porting without major modifications. Organizations can maintain productivity while modernizing their infrastructure.

The tool supports key OpenVMS Fortran operations including data conversion and record access, ensuring comprehensive compatibility. Companies like Amprion GmbH have successfully leveraged similar runtime preservation strategies for complex Fortran applications.

VX/FOR$ minimizes development costs and accelerates migration timelines. To explore how VX/FOR$ can streamline your Fortran migration project, contact us for a consultation.

Which Fortran features are not supported by the new host compiler?

These are language constructs which are supported by VMS for which there are no simple syntactic translations to modern Fortran. The code must be re-structured. Usually, sub-programs must be called to supply the missing features.

Again, the VMS code will simply not compile or run without modification. The important issues are:

VMS File Names in OPEN and INQUIRE: VMS file names may contain device directory and version specifications. When these are specified in I/O statements they must be translated at run-time on the new host. This is done by calling sub-programs in Sector7's VXRMS library.
ISAM Files: Indexed Sequential Access Method files are files which contain linkage pointers from fields within their records to related records. Under VMS the OPEN, READ, WRITE and INQUIRE keywords are extended to support them. These extension are not supported under Linux, Unix or Windows. fpt handles ISAM files by replacing the OPEN, CLOSE, INQUIRE, READ and WRITE statements by calls to sub-programs in Sector7's VXRMS library.
Variables and Expressions in FORMAT Statements: Under VMS, variables and run-time expressions may be written inside FORMAT statements or in embedded format strings. The variables or expressions are written within < > delimiters. This construct is translated to standard Fortran using run-time format strings.

What is FOR$?

FOR$ is a call-compatible re-implementation of the OpenVMS FORTRAN run-time support (FOR$) routines for x86 and ARM Linux. It lets OpenVMS FORTRAN applications run on Linux while preserving language features, execution behaviour, and system interactions.

Which platforms does FOR$ run on?

FOR$ runs on x86 and ARM Linux. It brings the OpenVMS FORTRAN run-time support routines to both architectures, so FOR$-dependent applications execute with consistent behaviour on Linux.

Which FOR$ routines does the library provide?

The library documents four public callable routines: FOR$CVT_D_TE (D_float to text), FOR$CVT_G_TE (G_float to text), FOR$CVT_H_TE (H_float to text), and FOR$RAB, which returns the RMS Record Access Block for an open FORTRAN unit.

Do I have to rewrite my FORTRAN application to use FOR$?

No major modifications are required. FOR$ is call-compatible with the OpenVMS FOR$ routines, so applications that rely on them can be ported directly and keep their original execution logic.

How does FOR$ relate to VX/RT?

FOR$ is delivered inside VX/RT. It integrates with the VX/RT run-time to provide the OpenVMS FORTRAN run-time support services on x86 and ARM Linux alongside the rest of the OpenVMS run-time surface.

Does FOR$ handle record access (RAB) operations?

Yes. FOR$RAB validates a FORTRAN unit and returns its RMS Record Access Block, and the run-time supports the full record-I/O surface (OPEN, READ, WRITE, REWRITE, DELETE, and more) while preserving OpenVMS record access behaviour on Linux.

What kinds of numeric conversion does FOR$ support?

FOR$ provides the FOR$CVT family of numeric-to-text conversion routines, formatting D_float, G_float, and H_float values into edited character strings. A field that does not fit its output is filled with asterisks and reported as an output-conversion error, matching the OpenVMS edit-descriptor convention.

Will my application behave the same after migrating with FOR$?

That is the goal. FOR$ preserves OpenVMS FORTRAN execution semantics, including IOSTAT error handling and record access behaviour, so applications run as they did under OpenVMS while executing on x86 and ARM Linux.

Transform Your Legacy Software Today!

Get In Touch

Unlock the potential of your legacy software with our expert migration services.