next up previous contents
Next: File Format Compatibility Up: Unix Portability Problems Previous: Source Code Porting   Contents

Run Level Compatibility

To run ported programs on Unix with the same features and behaviour displayed by VMS, changes to the code must be applied in the following cases:

HIGZ Windows in interactive graphic applications do not synchronize well with the X11 server with fast CPUs, in this case a fatal error is typed and the programs aborts. The same error was displayed randomly also by VMS but it was only a warning.

To solve the problem, before calling HPLINT insert a read statement to force synchronize:
read(5,'(a)') char

Control cards to ffread are read on LUN 5 by default. This unit is not convenient when running dxladebug therefore define a different LUN for ffread as follows:

call ffset('LINP',22)

then in the execution script redirect the control cards to file fort.22 as follows:

cat >fort.22 <<!EOD
noLIST
......your control cards....
END
!EOD

Date information in Unix Fortran is given by routine date_and_time as the old Fortran77 date routine is obsolete (not Y2K compliant).
When programs containing the date call are compiled, a request is made by the compiler to use date_and_time instead. By default the date produced by date_and_time is in US format. To emulate the date routine behaviour use the following code fragment:

c-----------------------------------------------------------------------
        data month/'JAN','FEB','MAR','APR','MAY','JUN',
     +             'JUL','AUG','SEP','OCT','NOV','DEC'/
c
1       format (1h ,a,4i12,f10.2)
2       format (1h ,a,3i10)
c
        call date_and_time(today)
c-------old date: 03-jun-99 - new date: 19990603------------------
        read(today,'(i4,i2,i2)') iy,im,id
        rundate=today(7:8)//'-'//month(im)//'-'//today(1:4)//' '
c-----------------------------------------------------------------------

Search lists are not supported by Unix. Search list emulation is achieved by our routine srcl, a C routine that is called by Fortran using the following syntax:

        log='MY_ENV_VAR'        !Unix environment variable == VMS logical
        fil='run7215.'          !file name
        call srcl(log,len(log),fil,len(fil),file_name,ierr)

If srcl terminates succesfully, the complete file name with path is returned in variable file_name that may be used to open file. Variable ierr is the return code and may have one of the following values:

 
        ierr= 0  file found; OK
            =-1  env var undefined
            =-2  no such file
The environment variable that defines the search list is created by a shell script similar to the one that follows:
#!/bin/sh
#
LVD_RAW_DATA=/lvdusr/lvd/test/,/lvdds0/lvdpro/raw,/lvdds0/lvdpro/w_raw
export LVD_RAW_DATA

Data Conversion is required to read VMS files and to convert floating point variables as described in the previous sections. If migrated programs are expected to run on both formats, i.e. VMS and Unix, a program parameter is needed to handle the following cases:

  1. native format, i.e. Unix created data
  2. VMS Format, i.e. VMS created data
  3. VMS REAL, i.e. Unix Fortran output containing VMS floating point variables.

Close file with a close routine that matches the open routine, otherwise the wrong file may be closed with unpredictable results. Files opened by the C routine open_lvd create a file descriptor, an integer incremented by 1 for any newly opened file, that formally resembles a Fortran logical unit. Check that any file accessed by file descriptor is closed by close_lvd and not by the Fortran statement close, otherwise another file may be closed in place causing unwanted splitting of the output file, or program abnormal termination in case of Input file.

Link Resolution is required when a file is a symbolic link pointing to the real file. In this case Unix does not resolve the link and the program is not able to print the real file name. To resolve links, we have implemented the routine ln2name, that resolves the link name as shown in the following code fragment:

        inquire(file='LVD_INP',name=link)
        write(6,*) 'File LVD_INP name is: ', link
        write(6,*) 'calling readlink .....'
        write(6,*)
        l_link=len(link)
        call ln2name(link,l_link,name,l_nam)
        write(6,*)
        write(6,*) 'Converted name is: ',name(1:l_nam)

VMS Key Indexed files are not portable and must be converted to direct access on VMS before migration. There are no general rules for key indexed file conversion and the strategy depends on the complexity of the defined keys.

As an example we will consider the LVD detector database we have migrated to Unix with limited effort. To convert our key indexed database from VMS Fortran indexed file to portable direct access file, we have designed a header structure with pointers to our data information. To keep handling simple the header is part of the database and has a fixed size to store a predefined maximum no. of entries. The header has a prolog part with free space for future implementations.

Direct access file record length must fit the indexed file data structure. The header structure must emulate the keyword/data association and must be some kind of interger multiple of the data record size.

In our case we have choosen a record length that contains 57 key/entry couples and 1000 records are reserved for the pointer area. The first record in the file is the prolog that defines the header size and the current occupation. The following 1000 records contain the pointer part of the header.


next up previous contents
Next: File Format Compatibility Up: Unix Portability Problems Previous: Source Code Porting   Contents
luvisetto 2003-01-23