Microsoft Programmer's Library 1.3/Microsoft_Programmers_Library.7z/MPL/fortran/frtkno.txt

Text File | 2013-11-08 | 1.7 MB | 51,179 lines

 Microsoft FORTRAN Compiler
 =============================================================================


 1. Graphics for FORTRAN

 Product Version(s): 3.3x 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBAS
 Last Modified: 29-AUG-1989    ArticleIdent: Q26943

 Question:

 I would like to produce graphics output with my FORTRAN programs. Can
 you recommend any graphics packages and/or libraries that I can use
 with FORTRAN?

 Response:

 Note: FORTRAN Version 5.00 has support for graphics. The following
 response includes only FORTRAN 4.10 and earlier.

 We do not currently provide graphics libraries for FORTRAN. However,
 since FORTRAN supports interlanguage calling between our other
 languages, we suggest you try our new QuickC compiler package. QuickC
 offers a run-time library of over 300 functions, including graphics
 routines and cursor control.

 The graphics package supports CGA, EGA, and VGA. Other QuickC run-time
 facilities include random number generation, string manipulation, and
 DOS function calling. By using QuickC, you not only have access to the
 run-time library package, you also have the luxury of a whole new
 language to program with. QuickC provides an integrated programming
 environment complete with editor, compiler, and a source-level
 debugger. With QuickC, you can write routines that can be called from
 FORTRAN or write programs that can call your FORTRAN subroutines.
 QuickC can provide the kind of flexibility that is not easily
 duplicated in FORTRAN.

 Our QuickBASIC compiler package also offers graphics support. The
 facilities provided mirror the ones available in QuickC but in a
 format that is consistent with the BASIC language.

 You can also call assembly-language routines written by you or
 third-party vendors. The bluebook of assembly-language routines for
 the IBM PC and XT by Christopher L. Morgan contains graphics and
 cursor positioning routines that may be called by your program.
 However, it should be noted that these routines were written
 specifically for the IBM and may have to be altered somewhat to run on
 IBM compatibles.

 Another option is to use the ANSI escape sequences to affect cursor
 movement and screen clearing. These have limited uses in producing
 graphics routines. Contact Microsoft Product Support Services for more
 information on ANSI escape sequences by calling [phone].

 In addition to these, a "Language Support Directory" is provided with
 each copy of FORTRAN. This booklet lists several vendors who provide
 graphics libraries (and other libraries such as communications
 packages) compatible with FORTRAN.


 2. The Following Code Caused Error F2124 Code Generation Error

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 fixlist5.0
 Last Modified: 14-JUL-1989    ArticleIdent: Q26944

 Problem:
    The following code will produce error F2124, code generation error:

         SUBROUTINE SUB
 C       IMPLICIT REAL*8 (A-H,O-Y)
         COMPLEX*16 SI,IB0,IB0P,IB1,IB1P,IBES0(3002),IBES1(3002)
         COMMON /CMN2/IBES0,IBES1,KBES0
 C
         IB0=0.5D1*IBES0(L1)
         IB0P=0.25D1*(IBES0(L0)+SI*IBES0(L1)+IBES0(L2))
         IB1=0.5D1*IBES1(L1)
         IB1P=0.25D1*(IBES1(L0)+SI*IBSE1(L1)+IBES1(L2))
 C
         RETURN
         END

 Response:
    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The workaround is to use the /Od switch or comment out the common
 statement.


 3. FORTRAN: Internal Compiler Error: mactab.c 1.34, Line 662

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q26945

 The code below generates the following internal compiler error:

 code.for
 code.for(15) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)mactab.c:1.34', line 662)
                 Contact Microsoft Technical Support

 The code is as follows:

         SUBROUTINE SUB
         COMPLEX*16 SI,IB0,IB0P,IB1,IB1P,B1,B2,IBES0(3002),IBES1(3002)
         COMMON /CMN2/IBES0,IBES1,KBES0
 C
         IB0=0.5D1*IBES0(L1)
         B1=IBES0(L0)+SI*IBES0(L1)+IBES0(L2)
         IB0P=0.25D1*B1
         IB1=0.5D1*IBES1(L1)
         B2=IBES1(L0)+SI*IBSE1(L1)+IBES1(L2)
         IB1P=0.25D1*B2
 C
         RETURN
         END

 The workaround is to disable optimization with the /Od switch or to
 remove the common block statement.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10. This problem was corrected in Version 5.00.


 4. FORTRAN: Internal Compiler Error: p3io.c 193, Line 813

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q26968

 The code below causes the following internal compiler error, but gives
 no line number for the source code that caused the error:

 fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)p3io.c:1.93', line 813)
                 Contact Microsoft Technical Support

 Function names are global and do not need to be passed to other
 functions. Microsoft has confirmed this to be a problem with Versions
 4.01 and 4.10 of the FORTRAN compiler. This problem was corrected in
 Version 5.00.

 There are two workarounds, as follows:

 1. In the first workaround, do the following:

    a. Remove "fx" when calling "simp()".

    b. Remove "f" in the simp() function declaration.

    c. Rename the call to "fx()" in simp() from "f()" to fx().

 2. In the second workaround, comment out the print statement.

 The code is as follows:

 program int (intput,output)
     integer n
     real a,b,simp
     external fx
     read *,a,b,n
     print *,'int = ',simp (a,b,n,fx)
     end

     real function fx (x)
     real x
     fx=x*x
     end

     real function simp(a,b,n,f)
     integer j,n
     real a,b,c,h,sum
     c=2.0
         do 5 j=1,2*n-1
          c=6.0 - c
          sum=sum+c*f(a+j*h)
 5        continue
     simp=sum*h/3
     end


 5. Blank Character Before "O"

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR54911 docerr
 Last Modified: 19-SEP-1988    ArticleIdent: Q11753

 Problem:

 The following program on Page 110 of the "Microsoft FORTRAN Compiler
 Reference" manual does not work properly; the first character of the
 write statement is lost:

    program wrt
    character*8 fname
    write(*,'(A\)') 'Output filename?:'
    read(*,'(A)') fname
    end

 Response:

 The document is incorrect. The example should be corrected by
 inserting a blank character before the "O" in "Output filename?" to
 reflect the correct behavior.

 It is important to remember that the first character of an output
 statement that uses unit 0, unit *, or the files PRN, LPT1, or CON is
 not printed but instead is interpreted as a carriage control
 character.


 6. No Error when Giving INTEGER*1 an Out-of-Range Value

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q26969

    When an INTEGER*1 item in the range -127 to 127 is assigned a value
 that exceeds the legal size-limits, no error message is returned.
 Execution continues, but with unpredictable results. The error message
 should be "F6100: INTEGER overflow on input."
    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 7. Random Number Generation in FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-JUL-1990    ArticleIdent: Q27211

 A random number generator was added with Microsoft FORTRAN version
 5.00. It is documented on Pages 272-273 of the "Microsoft FORTRAN
 Reference" for version 5.00.

 There is no function for random number generation in previous versions
 of Microsoft FORTRAN. However, there are at least two ways to generate
 a random number with FORTRAN versions 4.00, 4.01, and 4.10.

 The sample program DEMORAN.FOR on the Utilities and Source Code Disk
 (Disk 3 of 6) for versions 4.00 and 4.10 and on the Setup Disk for
 version 4.10 demonstrates a uniform random-number generator. It is
 documented in the comments at the beginning of the file.

 Another way to get a random number is to make use of the
 interlanguage capability of Microsoft FORTRAN. A call to QuickC is an
 easy way to get access to Rand and other C run-time library routines
 (as well as to the QuickC compiler, editor, and debugger, and other
 features, such as graphics routines).


 8. Fatal Error F1910 Unrecognized Option

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q27129

    The most common reasons for fatal error F1910, "unrecognized
 option," are an inability to open temporary files or an incorrect
 version of COMMAND.COM. Verify that "VER" and "COMMAND" both return
 the same version. If "VER" and "COMMAND" both return the same version,
 the error is caused by a problem with opening temporary files. One of
 the following could be the cause of this problem:

    1. The temporary variable is set incorrectly. The TMP variable must
 be set as follows:

    SET TMP=c:\myfullpath\mydir

    The line can have no extra spaces, and there must be a carriage
 return immediately following the last character. Retype this line at
 the DOS prompt if you are unsure about its syntax. The specified
 subdirectory must exist in the path as given.
    2. There is not enough room on the disk to store temporary files.
    3. There are not enough file handles to open temporary files. Make
 sure that the following two lines are in your CONFIG.SYS and that all
 terminate-and-stay-resident (TSR) programs are removed from the
 system:

    files=20
    buffers=20


 9. Incorrect Floating Point Representation

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR55281 buglist3.31 fixlist4.00
 Last Modified: 15-APR-1988    ArticleIdent: Q11835

 Problem:
    The following program gives the result 0,0 instead of 0,6:

    $storage:2
    program asst
    real coord(2)
    integer acc(2)
    integer i
    i=2
    coord(i)=acc(i)
    acc(i)=acc(i)+6
    write(*,*) acc
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler. The problem was corrected in Version 4.00.
    A workaround is to add the $NOFLOATCALLS metacommand.


 10. FORTRAN Setup on One 5.25" and One 3.5" Floppy Drive

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-MAR-1988    ArticleIdent: Q27501

 Question:
    I want to set up FORTRAN on my two-floppy system, but I have one
 drive that is 5.25 inch and one that is 3.5 inch. How can I do this?

 Response:
    Do not use the setup program. Instead, choose the disk size on
 which you wish to install FORTRAN. Then refer to the "Microsoft
 FORTRAN Compiler User's Guide." Table 2.1 on Pages 22-23 shows the
 disk organization to follow for 5.25 inch disks and Table 2.2 on Pages
 26-27 shows the disk organization to follow for 3.5 inch disks. Copy
 the files according to the suggested configuration for your chosen
 drive. The other drive will hold your source disk.
    You will need to build the libraries yourself. Use the BUILD1.BAT
 utility and follow the guidelines in the README.DOC file.
    When running the FORTRAN compiler, expect to see the warning
 message "Command line warning D4005 : could not execute 'f2.exe';
 please insert diskette and press any key." This is an expected
 response when running from a floppy setup. Swap disks at this point
 and continue compiling.


 11. Compatibility with an 80387 Coprocessor

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-MAR-1988    ArticleIdent: Q27502

 Question:
    Will the Microsoft FORTRAN compiler work with an 80387 math
 coprocessor?

 Response:
    You can use the coprocessor with all of our programming languages,
 but you can take advantage of it only up to the limit of the 80287
 instruction set.


 12. Cannot Trace into Program with Include File

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-OCT-1988    ArticleIdent: Q27551

 Problem:

 I have an include file that contains the following declaration:

     INTEGER*2 I,J

 When I trace into this program using CodeView, the entire program
 executes and I cannot set any break points. I am compiling the code
 with the following switches:

    /Zi
    /Od
    /FPi
    /4Yb.

 Response:

 The problem is that the switch "/4Yb" creates its own line
 information, which conflicts with the "/Zi" CodeView information.

 To work around this problem, do not to use the "/4Yb" switch when
 viewing under CodeView.


 13. How Many Files Can You Access?

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q12086

 The maximum number of files that you can open using versions of
 Microsoft FORTRAN prior to version 5.00 is 15. This maximum number
 of files is a FORTRAN limitation.

 Query on the words FILE and LIMIT and FORTRAN for more information
 about increasing this limit with FORTRAN 5.00.

 There is no limit on the number of files that you can open and close
 during the run of a program. The limit applies only to the number of
 files that can be open at the same time.

 This maximum number of open files is affected by the "FILES=" variable
 set in your CONFIG.SYS file. If you set the "FILES=" variable to less
 than 20, e.g. "FILES=15", then the maximum number of open files will
 decrease. FORTRAN opens five files itself: standard input, standard
 output, standard printer, standard error, and standard auxiliary.
 Since 5 of the 20 possible file handles are used by FORTRAN, that
 leaves your program 15.

 A simple explanation of how many files can be opened is found in IBM's
 "Disk Operating System Version 3.10 Reference" Pages 4-19 through 4-21
 "FCBS (File Control Block) Command" and Pages 4-22 through 4-23 "FILES
 Command", in particular Page 4-23 in the section called "Number of
 Files Opened".

 For more technical details on file handles, see IBM's "Disk Operating
 System Technical Reference" for Version 3.10, Chapter 4 "File
 Management Notes". See especially the following sections: "Handle
 Function Calls" (Pages 4-6 through 4-7), "Special File Handles" (Page
 4-8), "Number of Open Files Allowed" (Page 4-12), and "Restrictions on
 Handle Usage" (Page 4-13).


 14. INQUIRE Does Not Look Along APPEND File List

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 fixlist4.10
 Last Modified: 27-JUN-1988    ArticleIdent: Q27660

    The following program requires a file named A.A. The DOS command
 APPEND should allow you to list the directories in which you have
 files; thus, you do not have to specify the fully qualified path name
 of the file in your program. However, the INQUIRE statement does not
 seem to be searching this APPEND list.

          CHARACTER*20 FNAME
          LOGICAL FOUND
          DATA FNAME/'A.A'/
    C
          FOUND=.FALSE.
          INQUIRE (FILE=FNAME,EXIST=FOUND)
          WRITE(*,*) ' FILE= ',FNAME,'   EXIST= ',FOUND
    6     CONTINUE
          STOP
          END

    Microsoft has confirmed this to be a problem with the FORTRAN
 Compiler Versions 4.00 and 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 15. INQUIRE Statement Filename Length

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR57139 docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q12130

 Page 105 of the "Microsoft FORTRAN Compiler Language Reference" should
 state the following:

 The INQUIRE statement does not handle filenames longer than 31
 characters.


 16. File I/O Errors

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR57193 docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q12129

 On Page 252 of the "Microsoft FORTRAN Compiler User's Guide," the File
 I/O Errors should read as follows:

 1270 Console I/O error
 1271 User tried to rewind CON (i.e. the terminal) or USER
 1272 File I/O error after previous error


 17. FL Environment Variable Appears to Fail

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr langerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q27557

    If you set the FL environment variable exactly the way it is set in
 the two examples on Pages 10 and 12 of the "FORTRAN 4.10 Update," it
 will not affect compiling.
    The examples on Pages 10 and 12 of the update are incorrect; spaces
 are not allowed around the equal sign. The corrected example should
 state "SET FL=/Lr" with no spaces around the equal sign. However,
 spaces should be used between consecutive options.
 "SET FL=/Lr /FPi /Od" is correct.
    The /LINK option also must be given in all lowercase letters, as
 /link (the FL command line is case sensitive). Please note that the /I
 option also is incorrect; the correct option should be /INF.


 18. Using the C 5.0 Preprocessor

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q29595

 Problem:
    I am using the C 5.0 preprocessor before invoking the FL command to
 define long names (around 30 char) to something shorter for use in
 FORTRAN. However, the preprocessor is inserting blanks before comment
 lines; thus they are no longer comments in the eyes of the FORTRAN
 compiler. The manuals say it is legal to use the preprocessor. What is
 happening to the code?

 Response:
    The procedure you describe will not work. The C preprocessor is not
 a text processor and will not do what you are trying accomplish. The
 following are two alternate methods:

    1. Use the ALIAS keyword. For example:

         interface to subroutine _clearscreen[C, ALIAS =
  '_cls'] (area)

         /*  The underscore must be there in both places.  */

    2. Use the $NOTRUNCATE metacommand to set variable names to 31
 significant characters.


 19. Internal Compiler Error: grammar.c, Line 91 and FORTRAN 4.10

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 24-JUL-1990    ArticleIdent: Q27559

 Problem:

 The code below produces the following error:

 COMPERR.FOR(9) : fatal error F1001: Internal Compiler Error
                 (compiler file '../grammar.c', line 91)
                 Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem with the FORTRAN compiler
 Version 4.10. This problem was corrected in Version 5.00.

 If you are using Version 4.10, the only workaround is to disable loop
 optimization by using /Od or /Odct.

 The code is as follows:

         SUBROUTINE CPII1(ID,JD,IXS,IXE,IYS,IYE,JERR)
         IMPLICIT INTEGER*2 (I-N)
         DIMENSION ID(IXS:IXE,IYS:IYE),JD(IXS:IXE,IYS:IYE)
         DO 100 IL=IYS,IYE
         DO 100 KM=IXS,IXE
         JD(KM,IL)=ID(KM,IL)
   100   CONTINUE
         RETURN
         END
 C----------------------------------------------------------------------
         SUBROUTINE BKCUT2(ID,IBK16,IBK8,IFX,IFY,IBX,IBY,IB,IABK,JERR)
         IMPLICIT INTEGER*2 (I-N)
         DIMENSION ID(IFX,IFY),IBK16(IFX/IBX,IFY/IBY),
      A            IBK8(IFX/IBX,IFY/IBY,IB,IB)

         DO 1000 KM=1,IFX/IBX
         DO 1000 IL=1,IFY/IBY

         DO 900 KM1=1,IB
         DO 900 IL1=1,IB
         IF(IBK8(KM,IL,KM1,IL1).EQ.0) GO TO 900
         DO 800 KM2=1,IBX/IB
         DO 800 IL2=1,IBY/IB

         IKP=(KM-1)*IBX+(KM1-1)*(IBX/IB)+KM2
         ILP=(IL-1)*IBY+(IL1-1)*(IBY/IB)+IL2
         ID(IKP,ILP)=IABK

   800   CONTINUE
   900   CONTINUE
  1000   CONTINUE
         RETURN
         END


 20. Must Should Be May

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q19786

 On Page 9 of the "Microsoft FORTRAN 4.00 Quick Reference Guide," note
 3, the word "must" should be changed to "may."


 21. Floating-Point Exception Handling

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |  coprocessor 8087 80187 80287 80387
 Last Modified: 30-SEP-1988    ArticleIdent: Q19807

 Question:

 How can I clear the status word? Can I set it to any value I want?
 Page 359 of the "Microsoft FORTRAN User's Guide", Appendix D states
 that the status word remains set until the user clears it.

 Response:

 The following is a routine named "clrstat", which will allow
 you to clear the status word. Use this routine at your own
 risk, i.e., we do not support this routine.

 In both Versions 3.31 and 4.00, you cannot change the status word.
 Once it is set to a value (perhaps by a divide-by-zero error), the
 status remains at that value. Even by using assembly language, you
 only are allowed to clear the status word; you cannot set it to a
 specific value.

 The math run time does not allow you to clear the status due to the
 coupling of the invalid exception and NDP stack overflow conditions on
 the chip; the same exception is raised for both conditions. The
 clearing of the status word is prohibited because, due to the order in
 which the evaluation is done, you can inadvertently clear an invalid
 exception before the exception handler can access it.

 The following is a short FORTRAN program that first generates a
 divide-by-zero error, then does a valid calculation, followed by an
 assembly-language subroutine that only clears the status word:

    integer*2 sswrqq
    call lcwrqq (4927)
    call val1 (x,y) 100 continue
    z = x/y
    irep = sswrqq()
    write (*,*) 'status=',irep
    if (irep .eq. 4) then
    write (*,*) 'divide by zero'
    call clrstat
    endif
    if (irep .eq. 0) stop
    call val2 (x,y)
    go to 100
    end
    subroutine val1 (x,y)
    x = 1.0
    y = 0.0
    end
    subroutine val2 (x,y)
    x = 5.0
    y = 2.0
    end

    TITLE clrstat

    .8087 CLRSTAT_TEXT SEGMENT BYTE PUBLIC 'CODE' CLRSTAT_TEXT ENDS
    ASSUME CS: CLRSTAT_TEXT EXTRN __acrtused:ABS CLRSTAT_TEXT SEGMENT
    PUBLIC CLRSTA CLRSTA PROC FAR
    push bp
    mov bp,sp
    fclex
    fwait
    pop bp
    ret CLRSTA ENDP CLRSTAT_TEXT ENDS END


 22. Internal Compiler Error: loop.c 1.87, Line 836

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q19941

 Problem:
    I am getting an internal compiler error on loop.c:1.87 Line 836.

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.
    An error in loop.c probably indicates that the problem involves
 loop optimization. You may be able to work around the problem by
 separately compiling the routine specifying either -Od (optimization
 disabled) or -Odct (no loop optimization, but still perform common
 subexpression elimination and optimization for time) options.


 23. Compaq 386 Floating Point Error

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-MAR-1988    ArticleIdent: Q19948

 Problem:
    When running in real mode and using a 80287, a floating
 point exception occurs (such as divide by zero) and the CX
 register is destroyed.

 Response:
    The problem can occur with any product that accesses the
 80287 directly. Compaq is aware of the problem and has a
 solution available. If you are having such a problem,
 contact the Compaq hotline directly for more information.
    In FORTRAN, the problem may show itself by a program
 hanging in an infinite loop or (even worse) having loops
 terminate early. If you are using FORTRAN Version 4.0, you
 may be able to avert the problem by recompiling to disable
 loop optimization (either -Od or -Odct).
    Note that if you try to demonstrate this problem with
 CodeView, you cannot simply go to the offending instruction
 and then single step; you will not see the problem. You
 must set a breakpoint several instructions past the "bad"
 instruction.
    If you are using FORTRAN or C, you can determine if they
 have the problem by one of two methods:

    1. Re-compile with -FPa compiler option. If doing this
 action allows your program to run, contact COMPAQ.
    2. Mask (disable) the floating point exceptions. This is
 not the solution of choice since there are certain
 exceptions (denormal and invalid) that you are not
 permitted to mask.


 24. Run-Time Error F6419

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-DEC-1987    ArticleIdent: Q19942

 Problem:
    I am getting an error F6419: illegal structure for
 unformatted file.

 Response:
    There are two likely possibilities for this error
 message:

    1. Examine the OPEN statement for the file. You may have
 tried to do an unformatted READ on a formatted file. Since
 formatted files do not contain the length information that
 is required in unformatted files, this error would occur.
    2. Do not assume that since the notion of a file being
 UNFORMATTED is part of the ANSI FORTRAN standard, such
 files created on one machine are transportable to any other
 machine. The contents of such files are nonstandard and
 completely up to the implementor. Any data files that you
 wish to transport between machines should be produced only
 by FORMATTED WRITEs.


 25. PSP and Command Line Parameters

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1987    ArticleIdent: Q20073

 Question:
    When running a FORTRAN program, are the command line
 parameters in the PSP (Program Segment Prefix) left intact?
 In other words, could the command line parameters be
 retrieved from the PSP by an Assembler subroutine that is
 called by an Assembler program or a FORTRAN program?

 Response:
    Yes, the command line is left intact, and the parameters
 can be obtained from an Assembler program or a FORTRAN
 program.
    The parameters can be obtained by calculating where the
 PSP is in memory from your program. The PSP is generally
 256 bytes lower in memory than the first code segment.


 26. Resulting Type from Expression Using Both Integers and Reals

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-MAR-1988    ArticleIdent: Q27611

 Problem:
    My program contains expressions that use different combinations of
 REALs and INTEGERs in the following form:

 <REAL variable> = <REAL or INTEGER> ** <REAL> / <REAL or INTEGER>

    In each case, the correct result should be a REAL, but with some
 combinations the expression seems to be evaluated as an INTEGER
 (fractional portion is truncated) before it is assigned to a variable
 of type REAL.

        INTEGER*4 S2
        REAL*4 FACT(10)
        DATA S2/140/
        M = 7
        FACT(1) = 7.0 ** 2.0 / 140.0
        FACT(2) = M ** 2.0 / 140.0
        FACT(3) = 7.0 ** 2.0 / S2
        FACT(4) = 7 ** 2.0 / 140.0
        FACT(5) = 7.0 **2.0 / 140
        FACT(6) = 7 ** 2.0 / 140
 C the above is incorrectly evaluated as an integer.
        FACT(7) = M ** 2.0 / S2
 C above also incorrectly evaluated as an integer.
        WRITE (*,10) M
        WRITE (*,20) S2
        WRITE (*,*)
        WRITE (*,30) FACT(1)
        WRITE (*,*)
        WRITE (*,40) FACT(2)
        WRITE (*,*)
        WRITE (*,50) FACT(3)
        WRITE (*,*)
        WRITE (*,60) FACT(4)
        WRITE (*,*)
        WRITE (*,70) FACT(5)
        WRITE (*,*)
        WRITE (*,80) FACT(6)
        WRITE (*,*)
        WRITE (*,90) FACT(7)
 10     FORMAT (1X, 'M                  = ', I6)
 20     FORMAT (1X, 'S2                 = ', I6)
 30     FORMAT (1X, '7.0 ** 2.0 / 140.0 = ', G15.7)
 40     FORMAT (1X, 'M ** 2.0 / 140.0   = ', G15.7)
 50     FORMAT (1X, '7.0 ** 2.0 / S2    = ', G15.7)
 60     FORMAT (1X, '7 ** 2.0 / 140.0   = ', G15.7)
 70     FORMAT (1X, '7.0 ** 2.0 / 140   = ', G15.7)
 80     FORMAT (1X, '7 ** 2.0 / 140     = ', G15.7)
 90     FORMAT (1X, 'M ** 2.0 / S2      = ', G15.7)
        STOP
        END

 \.BODYTEXT
 Response:
    Microsoft has confirmed this to be a problem with the FORTRAN
 Compiler Versions 4.x. A workaround would be to convert any non-REALs
 to REALs with the intrinsic function "REAL()" to insure a REAL result.


 27. Default Option Is /Oaclt Not /Ox

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q28924

 Page 97 of the "Microsoft FORTRAN Optimizing Compiler User's Guide"
 for Versions 4.00, 4.01, and 4.10 contains documentation errors.

 In Section 3.3.15, the table near the bottom of the page incorrectly
 states the following:

 Character       Optimizing Procedure

 x            Full optimization; favors execution time (default)
 t            equivalent to x
 .
 .

 The default optimization option is /Oaclt /Gs which is equivalent to
 /Ox. Alias checking is relaxed by default. The only way to enable
 Alias checking, is to first turn off all optimization and then turn
 the specific switches back on.

 An example of turning alias checking on, when all other default
 optimization remains on, is /Odclt. Also, /Ot is not equivalent to
 /Ox, but is a subset of /Ox. The table should read as follows:

 Character Optimizing Procedure

 x               Full optimization; equivalent to /Oaclt /Gs
 t               favors execution time
 .
 .


 28. Error Running Library Manager

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q20053

 Question:
    What should I do when I get "error trying to run library manager"?

 Response:
    You should do the following:

    1. Make sure the directory LIB.EXE is in your PATH.
    2. If you still get the error message, then rename your
 AUTOEXEC.BAT file, reboot, and set PATH= to the directory LIB.EXE is
 in. Booting without an AUTOEXEC.BAT file will empty your environment.
 Setup should not be sensitive to how much is in your environment.
 However, we have found that emptying the environment causes the
 problem to disappear. Microsoft is aware of this problem and will post
 new information as it becomes available.
    3. If you continue to get the error message, terminate-and-stay
 resident programs may interfere with Setup, so check to see if you
 have any installed, and if you do, remove them.
    4. If methods 1, 2, and 3 above fail to solve the problem, the
 workaround is to build the libraries manually. If you have FORTRAN
 Version 4.01, you can use BUILD1.BAT. Information for this is in the
 README.DOC file. If you have Version 4.00 or Version 4.01, you can
 build them by running Setup with the /n option ("Setup /n"). The /n
 option allows you to run through Setup without Setup performing any
 installations. The /n option is meant to be used to familiarize you
 with the installation procedure. Since the /n option does not do any
 installations, it does not need to find LIB.EXE; the /n option runs
 its course and tells you what it is doing as it goes. Therefore, you
 can copy the commands the /n option uses to build the libraries, and
 then manually use LIB.EXE to delete and combine the appropriate
 modules to build your library.


 29. How FORTRAN Stores Two-Dimensional Arrays in Memory

 Product Version(s): 4.0 4.01 4.1 | 4.10
 Operating System:   MS-DOS       | OS/2
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q27780

 Question:
    How does FORTRAN store a two-dimensional array in memory? I know
 that C actually stores two-dimensional arrays as one-dimensional row
 arrays. Does FORTRAN use the same convention for array storage?

 Response:
    No, FORTRAN is different from languages such as C and Pascal in
 this respect. Although array elements are referenced in row major
 notation, i.e., (row, column), just as in C or Pascal, FORTRAN stores
 two-dimensional arrays as one-dimensional column arrays.
    For example, in C, a two-dimensional array with three rows and four
 columns will be stored in memory in the following sequence:

   (1,1),(1,2),(1,3),(1,4),(2,1),(2,2),(2,3),(2,4),(3,1),(3,2),(3,3),(3,4)

    However, FORTRAN will store the same array in the following
 sequence:

   (1,1),(2,1),(3,1),(1,2),(2,2),(3,2),(1,3),(2,3),(3,3),(1,4),(2,4),(3,4)


 30. Reference in Substring

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22142

    In the following program, the first call to SWRITE contains a
 substring reference where the upper bound is a function reference (the
 answer generated from this call should be the same as the one
 generated by the second call; both should be 16):

       CHARACTER*80 A
       A='THIS IS A STRING'
       CALL SWRITE( A(1:LLEN(A)) )
       L=LLEN(A)
       CALL SWRITE( A(1:L) )
       END
       INTEGER FUNCTION LLEN(A)
       CHARACTER*(*) A
       llen=16
       END
       SUBROUTINE SWRITE(A)
       CHARACTER*(*) A
       PRINT*,LEN(A)
       RETURN
       END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The LEN(A) is what is being sent to the first SWRITE, not the
 LLEN(A). You can work around this by doing what was done for the
 second call, as follows:

    1. Evaluate the function.
    2. Store it in an INTEGER temporary.
    3. Use the temporary in the substring expression.


 31. Error on READ

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22158

    The following program produces run-time error "F6205: READ (dat)--
 Edit descriptor expected for CHARACTER." The data file "dat" contains
 ASCII 11.

    dimension a(2)
    open(unit=1,file='dat')
    read(1,'(A1,F1.0)') a
    write(*,*) a(1) a(2)
    end

    By substituting another "A1" for the "F1.0" or conversely, using
 two "F1.0" formats, the program works properly. Also, the program
 works properly under Version 3.31.
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. The problem was corrected in Version 4.01.

    The error will only happen if, in the middle of an array READ, the
 FORMAT specifier indicates that the next element of the array to be
 read is of a different type (REAL in this case) than the previous one.
    There are ways to work around this, using a combination of implied
 DO lists and (if necessary) single array elements as arguments to the
 READ.
    For example, if the READ statement had used the same argument list
 as did the WRITE, i.e., a(1), a(2), the program would have worked
 normally.


 32. Rounding Errors

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22162

 Question:
    Two rounding errors occur in Version 4.00. Is it possible to get
 more information on these errors?

 Response:
    The following program demonstrates the two rounding errors:

         x = .01
         write (*,'(1x,''x='',f5.0)') x
         x = .01
         write (*,'(1x,''x='',f9.2)') x
         end

 x=   9.         [This demonstrates Error 1]
 x=      .00     [This demonstrates Error 2]

    Microsoft confirmed this to be a problem in Version 4.00 of the
 compiler. This problem was corrected in Version 4.01.
    The following is a discussion of the two error messages:

    1. Error 1:
    Any WRITE of a quantity less than 1.0 with a FORMAT of the form
 Fn.0 may produce unexpected results. Some quantities (usually the
 larger magnitude powers of 2 such as .5, .25, and .125) will produce
 the expected 0., but most (including the powers of 2 such as .0625 and
 .03125) will not.
    2. Error 2:
    This error is a very specific case and may, in fact, only affect
 FORMATs of form Fn.2 attempting to put out the quantity .01 (which is
 represented internally as .0099999).


 33. Optimization Problem

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22163

    This problem concerns moving blocks of code to improve program
 efficiency (code motion). In this program, the block includes the
 three statements starting at statement number 10 and ending at the IF
 statement.
    Compiled with the default ($STORAGE:4), the program works properly
 but no code motion takes place (even though the compiler will always
 try to do code motion unless -Od or -Zi is used). If -4I2 or
 $STORAGE:2 is used, the block is moved just before the 9999 continue
 statement.
    The -4I2 version does not work because the compiler failed to
 generate a JMP to the code that it moved.

    The following program:

       WRITE (*,*) 'THIS IS SUPPOSED TO PRINT OUT FIRST'
       IQ=1
    10 CALL SUB1(IQ)
       WRITE(*,*) 'THIS IS SUPPOSED TO PRINT OUT SECOND'
       IF (IQ.EQ.0) GOTO 9999
       WRITE (*,*) 'THIS SHOULD NOT PRINT AT ALL'
       GOTO 10
  9999 continue
       END
       subroutine sub1 (j)
       j = 0
       end

 Should print out the following two lines:

 THIS IS SUPPOSED TO PRINT OUT FIRST
 THIS IS SUPPOSED TO PRINT OUT SECOND

 If it is compiled with -4I2, it prints the following:

 THIS IS SUPPOSED TO PRINT OUT FIRST
 THIS SHOULD NOT PRINT AT ALL
 THIS IS SUPPOSED TO PRINT OUT SECOND

    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.


 34. Example on Page 86, 87 of Programming Guide Is Incorrect

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q27662

 Question:

 I typed in the FORTRAN assembler mixed-language programming example on
 Pages 86 and 87 of the "Microsoft Macro Assembler 5.00 Mixed-Language
 Programming Guide." When I compiled, I received more than seven
 errors. Why won't this program compile?

 Response:

 This program will not work as documented because the FORTRAN example
 is erroneous; there were two major sections omitted. First, the
 keyword FUNCTION is omitted; secondly, POWER2 must be be declared in
 the main body.

 The assembler routine is correct. The following example will compile
 and link correctly with the assembler routine:

 C   File name ftest.for
       INTERFACE TO INTEGER*2 FUNCTION POWER2(a, b)
       INTEGER*2 A, B
       END
 C
       INTEGER*2 A, B, POWER2
       A = 3
       B = 5
       WRITE(*, *) '3 * 2 to the power of 5 = ', POWER2(A, B)
       END

 After creating two OBJs, link them together with the MASM linker. The
 following is an example:

 link ftest.obj + mtest.obj;


 35. INCLUDE Files Incorrect

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified: 18-AUG-1988    ArticleIdent: Q22171

 Problem:
    The program below compiles normally if all the INCLUDE files exist
 in the same directory; however, it fails to compile if the files to be
 included exist in a subdirectory.
    The following is a program test of this problem:

 C TEST.FOR tests the include limits of 4.00

 $INCLUDE:'CCALLS.FIL'

         PROGRAM TEST

         CHARACTER*10    NAME
 $INCLUDE:'PLAN.CFD'
 $INCLUDE:'DIRECT.CFD'
 $INCLUDE:'CLIENT.CFD'
 $INCLUDE:'COLORS.CFD'
 $INCLUDE:'EMPMAS.CFD'
 $INCLUDE:'EMPLDF.CFD'
 $INCLUDE:'EMPLDD.CFD'
 $INCLUDE:'JUFFSA.CFD'
 $INCLUDE:'JOUEMP.CFD'
 $INCLUDE:'PLNTBL.CFD'
 $INCLUDE:'COLVAR.ASN'

         END

 Microsoft (R) FORTRAN Optimizing Compiler Version 4.00A
 Copyright (c) Microsoft Corp 1987. All rights reserved.

 test.for
 P1 : ` f1.exe -il D:012356 -f test.for -pc \:/ -ef C:\BIN\f1.err -Q 24242 -A
 lfd -4I 4 -Gs -Iinclude/ -I ./ -W 1  '
 compiling ccalls.fil
 compiling plan.cfd
 compiling direct.cfd
 compiling client.cfd
 compiling colors.cfd
 compiling empmas.cfd
 compiling emplfd.cfd
 compiling empldd.cfd
 compiling juffsa.cfd
 test.for(16) : fatal error F1909: : %s : include file nested too deeply
  : include file nested too deeply

 Response:
    The error message itself is not being produced correctly. You can
 work around this problem by placing the INCLUDE files in the same
 directory as the source file.
    Microsoft has confirmed this to be a problem in Version 4.00. We
 are researching this problem and will post new information as it
 becomes available.


 36. Linking With 3.20/3.30 Modules

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q22172

 Question:
    When linking with the 3.20/3.30 compatible library (large model, 87
 support), I receive a message from LINK that it needs the LLIBFORE
 library. I am not specifying any FP switches at link time.
    What causes this? Could this happen if my 3.20/3.30 modules were
 compiled with $NOFLOATCALLS?

 Response:
    This should only occur if you are set up to link to LLIBFOR7.LIB.
    About twelve of the modules in Version 4.00 of FORTRAN.LIB have
 library search directives for LLIBFORE.LIB embedded in them. The
 linker will ask for LLIBFORE when the 3.20/3.30 routines call a
 library routine that has not already been loaded to satisfy a request
 from the main (Version 4.00) program.
    To workaround this, use the FL directive-link to alter the library
 search order.
    The following FL will compile and link without asking for
 LLIBFORE.LIB:

    FL V40.FOR -link MYLIB FORTRAN

    Since the Version 4.00 library contains the appropriate Version 3.x
 math library, it does not matter if $FLOATCALLS is used in the Version
 3.x routines.


 37. Text Beyond 72 Columns

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q22178

 Problem:
    If text goes beyond 72 columns, FORTRAN Version 4.00 does not issue
 any kind of diagnostics. It generates code (which is incorrect code,
 because some of it is not submitted to the language translator). All
 of the other compilers on the market issue diagnostics.

 Response:
    You are partially correct. Unless truncation of the line to 72
 characters causes a syntax error, Version 4.00 does not issue any
 error message. This is program design for the product.
    Because the FORTRAN standard mandates that only the first 72
 columns be used for source code, a substantial body of mainframe
 FORTRAN code has been generated that relies on that fact and uses the
 remaining columns (generally 73-80) for other purposes (most commonly
 for sequencing information).
    If the presence of characters beyond column 72 was flagged as a
 warning, and you were porting programs with sequencing information in
 columns 73-80, you would receive such a warning for every line. The
 listing file format provided by Version 4.00 of the Microsoft FORTRAN
 Optimizing Compiler will list the content of the first 72 characters
 of the source line and indicate the presence of additional characters
 beyond column 72 by adding a "#" just before the line number, e.g.
 line 10 in the following fragment of a .LST file:

   Line    Source    Microsoft FORTRAN Optimizing Compiler Version
   Number  Line      4.00

       1   c
       2   c
       3   c
       4   c
       5   c
       6
       7          program test
       8          open(3,file='xxxx.dat',status='old')
       9          rewind 3
      10          read(3,10)i1,i2,i3,i11,i12,i21,i22,i23,i24,
                  i25,i26,i27,i28,i29
      11  10      format(5i3,13i1)
      12          write(*,*)i1,' ',i2,' ',i3
      13          write(*,*)i11,' ',i12
      14          write(*,*)i21,i22,i23,i24,i25,i26,i27,i28,i29,
                  i30,i31,i32,i33
      15          end

    Please note that the variable i31 became variable i3, which causes
 incorrect output from this program.
    Neither of the two other microcomputer FORTRAN compilers that we
 tried directly diagnosed the presence of characters beyond column 72.


 38. FORTRAN and C Compatability in Protect Mode

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-MAR-1988    ArticleIdent: Q27843

 Question:
    How do I link my FORTRAN and C modules when I have built my FORTRAN
 libraries with C compatibility? I link as follows:

 LINK objs,,,LLIBCEP.LIB LLIBFEP.LIB DOSCALLS.LIB /NOE /NOD;

 Response:
    It is not necessary to use F4COMPAT.BAT for protect mode programs.
 Any of the three math packages can be used as long as they are
 consistent between the languages. The C library must be the first
 library, the FORTRAN library and DOSCALLS.LIB must be linked
 explicitly, and the switches /NOE and /NOD must be used. The /NOE
 switch is used to prevent symbols from being defined more than once
 (error L2025). The /NOD switch turns off the default library search so
 that the order of these libraries can be given explicitly. For
 information on linking real mode programs, please refer to the C 5.00
 README.DOC section entitled "Linking Mixed-Language Programs."


 39. Device Full Error

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22177

 Problem:
    There seems to be a problem using OPEN or CLOSE on a logical unit
 where you have had an error 6422 ("no space left on device") that is
 caught in a WRITE statement. Any attempt to CLOSE or OPEN the same
 logical unit will give the same error. The example that I have opens a
 file on an almost full disk, writes until it produces the above error,
 and then attempts to CLOSE the file.

 Response:
    This is a known problem in Version 4.00. It was corrected in
 Version 4.01.
    The program tries to recover from the "no space" condition by using
 the STATUS='DELETE' specifier to delete the file.
    The error is not being cleared because when a CLOSE is done, the
 file's last buffer is being flushed before a check is done to see
 whether you specified that the file be deleted. There is no
 workaround.


 40. Error in Rounding Code

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22143

 Question:
    I have encountered an error in the rounding code. Is there a
 solution available? The following is sample code:

     real*4 n1
     character*20 str

     n1=0.01
     write(str,12) n1
     write(*,*) str
 12  format(f9.2)

    F9.2 format rounds the number to 0.00.

 Response:
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. The problem was corrected in Version 4.01.
    The problem does not occur for all values of n1 (try .02), but will
 occur whether the WRITE is to an internal or external file.


 41. Internal Compiler Error: getattrib.c 1.40, Line 162

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900051 bcp1542 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q22227

 Problem:
    The following program will produce the assertion error
 getattrib.c:1.40, line 162:

    implicit real (A - Z)
    integer*2    I CHAR
    integer*2    I SCAN
    integer*2    OPTION
    character*01 DRIVE
    common /valset/ allcharacters,  alphabetic, alphanumeric,
    &                numeric,    protected,  signed
    character*1  PROD ARRAY (36)
    character*36 PROD
    character*13 PRD KEY
    character*2  PRD DIV
    character*1  PRD FIL
    integer*4    PRD RET
    equivalence (PROD ARRAY  (1), PROD, PRD KEY, PRD DIV),
    &            (PROD ARRAY (33),                PRD RET)
    common /PROD CM/ PROD
    end
    subroutine UPDATE
    implicit real (A - Z)
    character*14 SET DD
    character*1  PROD ARRAY (36)
    character*36 PROD
    character*13 PRD KEY
    character*2  PRD DIV
    character*1  PRD FIL
    integer*4    PRD RET
    equivalence (PROD ARRAY  (1), PROD, PRD KEY, PRD DIV),
    &            (PROD ARRAY (33),                PRD RET)
    common /PROD CM/ PROD
    PRD KEY = '.............'
    PRD FILLER = ' '
    end

 Response:
    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    It seems that this problem has to do with EQUIVALENCE between
 CHARACTER and non-CHARACTER data.
    Note that the assertion error only happens on an 80286; on an
 80386, you will receive an "error 2100 : Floating point error : stack
 underflow", after which the machine will hang. This happens even on a
 patched DOS Version 3.2.


 42. Internal Compiler Error: regMD.c 1.74, Line 2156

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900054 bcp1545 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22232

 Problem:
    The following program causes a regMD.c:1.74, line 2156 assertion
 error:

         u = 1. /
      +      (xa+ 1. /
      +      (xa+ 2. /
      +      (xa+ 3. /
      +      (xa+ 4. /
      +      (xa+ 5. /
      +      (xa+ 6. /
      +      (xa+ 7. /
      +      (xa+ 8. /
      +      (xa+ 9. /
      +      (xa+ 10. /
      +      (xa+ 11. /
      +      (xa+ 12. / xa ))))))))))))
         end

 Response:
    This is a known problem in Version 4.00a of the FORTRAN compiler.
 It was corrected in Version 4.01.
    The only workaround is to break the statement into smaller
 segments.


 43. Null Pointer Assignment at Compile Time

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900048 bcp1532 ptr900049 bcp1534 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22235

    The following code gives a "null pointer assignment" error if
 compiled with -4Yb ($DEBUG):

    character cfunc,arg
    arg = 'X'
    write (*,*) cfunc (arg)
    end
    character function cfunc (arg)
    character arg
    cfunc = arg
    end

    Note that the following program also produces a "null pointer
 assignment" message during compilation if -4Yb is used:

    SUBROUTINE MAPINPUT (FILENAME)
    CHARACTER*(*) FILENAME
    OPEN (1,FILE=FILENAME)
    END

    Microsoft has confirmed this to be a problem in Version 4.00a of
 the FORTRAN Compiler. This problem was corrected in Version 4.01.

    In the first example, this occurs because a CHARACTER function is
 used in a WRITE statement (but only when compiled with -4Yb).
    The second example produces the same error, probably for the same
 internal reason, but there is no CHARACTER function this time.
 Instead, there is a CHARACTER*(*) parameter associated with an I/O
 statement.


 44. Concatenation Operator

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900055 bcp1548 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22236

    The following program should output PQRS2345, but it only outputs
 PQRS:

         J=3
         CALL SUBA(J)
         END

         SUBROUTINE SUBA(J)
         CHARACTER*8 A
         CHARACTER*4 H
         COMMON /AAA/H(3)
         h(1)='ABCD'
         H(2)='PQRS'
         H(3)='2345'

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The following statement can be inserted as a workaround:

         H(J) = H(J)
         A=H(2)//H(J)
         WRITE(0,999)A
 999     FORMAT(' A=',A8)
         END

    This problem seems only to affect the second operand of a
 concatenation if the second operand is a COMMON variable.


 45. Internal Compiler Errors: ctypes.c, MDmisc.c, expand.c

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900056 bcp1549 buglist4.00
 Last Modified:  2-JUN-1988    ArticleIdent: Q22237

    The following subroutine will produce four different internal
 compiler errors, depending on how "k" is typed:

    subroutine inerr(endprnt)
    integer endprnt

    The following errors are produced:

    1. "Character*4" will produce an error in ctypes.c line 355 if
 compiled with -4I2, as follows:

    character*4 k

    2. "Character*10" will produce an error in ctypes.c line 426 if
 compiled with -4I2, as follows:

    character*10 k

    3. "Character*1" will produce an error in MDmisc.c line 844, as
 follows:

    character*1 k

    4. "Character*2" will produce an error in expand.c line 1350, in
 the following program:

              character*2 k
              lr=1
              write(endprnt,40)k(lr),k(lr+1),k(lr+2),k(lr+3)
    40        format(1x,4A10)
              end

    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The problem apparently involves the recognition of a CHARACTER
 function as an argument to a WRITE or an OPEN statement.


 46. EOF When Value Equals 26 in a Binary file

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22238

    The program below (deof.for) will get an end-of-file (EOF) if the
 value read in is equal to 26. This happens only if the variable is
 integer*1 (integer*2 produces the proper results). It is my
 understanding that the 26 should not be treated as EOF if it is a
 binary file.
    The program is as follows:

    integer*1 i1,i2
    open(1,file='def.dat',form='binary')
    i1=22
    i2=26

    write(1) i1
    write(1) i2

    rewind (1)

    read(1) i1
    write(*,*) i1

    read(1) i2
    write(*,*) i2

    end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.

    In FORM='BINARY', you should be able to READ anything that you
 WRITE to a file (if you rewind the file), including CONTROL-Z. The
 problem is not restricted to INTEGER*1. What determines the failure is
 that the very last byte written to a file is a CONTROL-Z. When
 READing, if the run time sees a CONTROL-Z in its buffer, it strips it
 out. In this program, this causes a premature end-of-file.
    This program will fail in the same way if you change variable I2 to
 be INTEGER*2 and give it a value of #1A1A. (Due to byte swapping,
 INTEGER*2 storage of the value 26 is #1A00. Thus, because the last
 byte was zero, you did not see it fail.)


 47. Internal Compiler Error: exhelp.c 1.55, Line 662

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  1-JUN-1988    ArticleIdent: Q22240

 Problem:
    FORTRAN Version 4.00 generates the following internal compiler
 error:

    exphelp.c:1.55, line 662

 Response:
    Line 8, "B(I) = REAL(I) - CMPLX(I)", generates the above internal
 compiler error. B is COMPLEX*16 and I is INTEGER*2. The error goes
 away if you change the statement to the following:

    T = CMPLX(I)
    A(I) = REAL(I) - T

    The first file (bernard.for) generates the internal error. The
 second file (bernard2.for) adds the variable T to fix the problem.
 The following is the first file:

    program test
    integer*2 maxamt
    parameter (maxamt=5)
    complex*16 b(maxamt)
    integer*2 i

    do 1,i=1,maxamt
      b(i) = real(i) - cmplx(i)
 1    continue
    end

    REAL(I) converts I to REAL*4. CMPLX(I) converts I to COMPLEX*8.
    The problem can also be worked around by compiling with the -Odclt
 option.


 48. END= and Implied-DO READS

 Product Version(s): 4.00a 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900058 bcp1554 buglist4.00a buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22244

    The following program should produce two identical lines:

         dimension x(15)
         open (1,form='formatted')
         write (1,'(i5)') (i,i=1,10)
         rewind 1
         i = 0
 5       continue
         i = i+1
         read (1,*,end=10) x(i)
         go to 5
 10      continue
         i = i-1
         write (*,*) 'From first read, i=',i,':'
         write (*,'(1x,15f3.0)') (x(j),j=1,i)
         rewind 1
         read (1,*,end=20) (x(i),i=1,15)
 20      continue
         i = i-1
         write (*,*) 'From second read, i=',i,':'
         write (*,'(1x,15f3.0)') (x(j),j=1,i)
         end

    The output should be as follows:

    >From first read, i=         10:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10.
    >From second read, i=         10:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10.

    However, it looks like the following:

    >From first read, i=         10:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10.
    >From second read, i=         15:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10. 0. 0. 0. 0. 0.

    Microsoft is researching this problem and will post new information
 as it becomes available.

    This is a known problem in Versions 4.00a and 4.01.
    This problem will occur on READ statements that use implied-DO loops to
 read part or all of an array and that use the END= specifier to branch
 when end-of-file is reached.
    An inspection of the code reveals that no code is being generated
 to check for end-of-file when an implied-DO is used.


 49. Incorrect F2215 Errors

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | PTR900060 bcp1569
 Last Modified: 25-OCT-1988    ArticleIdent: Q22255

 The following program will generate an incorrect F2215 error
 ("character lengths differ"):

       SUBROUTINE PAGE
       IMPLICIT CHARACTER*1(A-H,J-Z)
       ENTRY PAGOUT
       END

 The compiler is issuing an error that is only appropriate for a
 function because subroutines have no type associated with them. The
 workaround for this problem is to avoid using the IMPLICIT CHARACTER
 statement; use explicit type statements instead.


 50. Macro Definitions Error

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 25-OCT-1988    ArticleIdent: Q22284

 Question:

 Is there a documentation error on Page 174 in the "Microsoft
 FORTRAN Optimizing Compiler User's Guide" for Version 4.00 regarding
 macro definitions?

 Response:

 Yes, the following statement should be changed to indicate that double
 quotation marks around a macro are required only if the macro
 definition contains white space and is on the MAKE command line:

    "To include white space in a macro definition, enclose the entire
    definition in double quotation marks (" ")"

 Macro definitions inside a MAKE file should not be enclosed in
 quotation marks. Therefore, the following example on Page 175 is
 incorrect:

    warn="/W0"

 It should be changed to something such as the following:

    make warn= "-c -W2" compile


 51. -Gr Switch Operating Incorrectly

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900063 bcp1585 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22292

    The -Gr switch is intended to be used when Version 3.20 object
 files or libraries are mixed with Version 4.00 main programs. Version
 3.20 object files may use the SI and DI registers without regard to
 their previous contents, and since Version 4.00 needs to use SI and
 DI, this switch was added to preserve their contents by pushing them
 onto the stack prior to subroutine or function calls and restoring
 them upon return.
    A problem is caused by the SI and DI registers being pushed after
 any arguments are pushed, rather than before. The -Gr switch will work
 if calls to subroutines or functions are made with no arguments, but
 programs containing subroutines or functions that have one or more
 arguments will either produce incorrect answers or behave
 unpredictably.
    Microsoft has confirmed this problem in Version 4.00 of the FORTRAN
 Compiler. This problem was corrected in Version 4.01.

    Here is an example of a program that recreates the problem. The
 following program:

         character*5 c,cfunc
         i = 1
         x = 2.0
         c = '34567'
         call junk (i,x,c)
         c = cfunc ('abcde')
         write (*,*) 'Function return value should be ''abcde'', is=',c
         end
         subroutine junk (j,y,cx)
         character cx*5
         write (*,*) 'First parameter should be 1, is=',j
         write (*,*) 'Second parameter should be 2.0, is=',y
         write (*,*) 'Third parameter should be ''34567'', is=',cx
         end
         character*(*) function cfunc(c)
         character*(*) c
         cfunc = c
         end

 should produce the following output:

    First parameter should be 1, is=          1
    Second parameter should be 2.0, is=       2.000000
    Third parameter should be '34567', is=34567
    Function return value should be 'abcde', is=abcde

 However, when compiled with -Gr, the output is as follows:

    First parameter should be 1, is= 1073741824
    Second parameter should be 2.0, is=   2.700149E-06
    Third parameter should be '34567', is=\016X>$
    run-time error F6602: WRITE(CON)
    - list-directed number bigger than record size


 52. Internal Compiler Error: omf.c 1.59, Line 185

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900053 bcp1544 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22233

 Problem:
    The following program causes an omf.c:1.59, line 185 assertion
 error if compiled with the -Fc option:

         dimension jn(8192)
         write (*,'(4i15)') jn
         end

 Response:
    This is a known problem in Version 4.00a of the FORTRAN compiler.
 It was corrected in Version 4.01.
    The pattern here is that it must be a formatted write, and the
 argument to the WRITE must be part or all of an array that is more
 than 32K in length.


 53. Code Generation Errors when Compiling with -4Yb and -Od

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900050 bcp1535 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22225

    The following program causes multiple code generation errors if
 compiled with -4Yb and -Od:

    SUBROUTINE OPED1
    CHARACTER*70 COMMENT(2)
    IF (COMMENT(1)(I:I) .EQ. ' ') i = 1
    IF (ICHAR(COMMENT(1)(I:I)) .NE. 0) i =1
    END

 Problem:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    This is probably related to an earlier problem that caused an
 assertion error in ctypes.c:1.80, line 1594. In fact, this program
 will cause the same assertion error if the -Od option is not used.
 Note that the error will not occur unless both of the IF statements
 are present.


 54. Compile Error F2328

 Product Version(s): 4.00A 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00a buglist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22208

 Problem:
    The following subroutine produces compilation error F2328 ("N :
 already typed"):

       subroutine x (a,n)
       real a(n)
       integer n
       a(1) = 1.0
       end

 Response:
    This is a known problem in Versions 4.00a and 4.01 of the FORTRAN
 Compiler.
    The program is valid, but the compiler reacts as if the presence of
 N in the REAL declaration statement "declares" N to be type INTEGER.
 Because N has been "declared" INTEGER, the compiler reports an error
 when the next statement attempts to declare it.
    To work around this compiler error, declare all variables used as
 bounds for adjustable-size arrays before declaring the arrays
 themselves.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 55. Run-Time Error F6099 Integer Overflow -4Yb -4I2

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900064 bcp1587 buglist4.00 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22291

 Problem:
    The following program produces run-time error F6099 (INTEGER
 overflow) if it is compiled with -4I2 and -4Yb:

         dimension j(200,160)
         do 10 i=1,200
         write (*,*) 'i=',i
         do 10 k=1,160
         write (*,*) 'k=',k
 10      j(i,k)=0
         end

    It writes out i=1 and j=1,2,3...82 and then terminates.

 Response:
    This is a known problem in Versions 4.00 and 4.01 of the FORTRAN
 compiler.
    The array subscript calculation is being done in INTEGER*2
 arithmetic, so when you get to j=82, it is attempting to multiply 400
 (200 elements, 2 bytes each) by 82, which is 32800. However, since
 $4Yb is in effect, the program gives the error and stops. This also
 will happen if you explicitly make the array INTEGER*2 and compile
 with just -4Yb.
    The workaround is to reduce the size or length of the character
 array to the point where size (200 elements in this case) times the
 length (2) is less than 32768 bytes.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 56. Unformatted WRITE Hangs

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900062 bcp1580 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22287

 Problem:
    The following program hangs at run time:

         dimension i(5)
         data i /1,2,3,4,5/
         data n /0/
         open (1,form='unformatted')
         write (1) (i(j),j=1,n)
 cx      write (1) (i(j)*1,j=1,n)
         close (1,status='delete')
         end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The program hangs because it is trying to write zero elements of
 the array. It is peculiar to unformatted I/O and happens only if the
 number of elements to be transferred is zero.
    If you want to be able to write zero elements, a workaround is to
 put the array element into an expression. Replacing the existing WRITE
 with the commented-out WRITE allows the above program to run.


 57. Purpose of the /Gr Switch

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  1-DEC-1987    ArticleIdent: Q22267

 Question:
    We are a little unclear on exactly what the /Gr switch does. Is it just
 that the object file format is different, or are the object references
 different?

 Response:
    The only effect the /Gr switch has is that, prior to any
 subroutine/function call, the SI and DI registers are pushed onto the stack,
 and upon return they are popped. Since Version 3.x routines may use SI and DI
 for their own purposes, the /Gr switch was added to preserve their Version 4.
 values across calls.


 58. NDP Stack Underflow

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900061 bcp1571 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22264

 Problem:
    I am receiving the following error message:

    run-time error M610: MATH
    - floating-point error: stack underflow

    I receive the above error message when I run the following program:

         data x /0.0/
         y = 0.0
         if (x .ne. 0.0) y = 1.0
         z = 1.0
         write (*,*) y,z
         end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The optimizer assumes that the constant 1.0 is on the NDP stack, so
 when it tries to assign 1.0 to Z, it simply does an FSTP
 (floating-store-pop) instruction. Unfortunately, since 1.0 will be put
 on the stack only if X is not equal to 0.0, the program fails.
    The workaround is to compile with -Od.


 59. Code Generation Error, WRITE Statement

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900059 bcp1568 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22259

 Problem:
    The following program produces a code generation error:

       real bs(3,3),br(3,3),ps(3,3),psp(3),bsp(3),bso(3),rp(3),ro(3)
           WRITE(6,350)
      +  aguse(I,J)/customers(J),
      x  agg(bs(I,J),1.0)+AGG(BR(I,J),1.0),
      +  AGG(BR(I,J)-PS(I,J),1.0),
      X  AGG(BS(I,J)+BR(I,J)-PS(I,J),1.0)
   350 FORMAT(3(1X,A22,F9.1,7F8.2,3X,F8.2))
         end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The problem here apparently involves the expressions used as
 arguments to the WRITE statement. A possible workaround would be to
 store the expressions in temporary variables and WRITE those instead.


 60. Run-Time Error F6419 in Series of READs

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22258

 Question:
    I receive run-time error F6419 in the middle of a series of READS.
 How can I prevent this?

 Response:
    This error means "illegal structure for unformatted file." You may
 be able to prevent the error by raising the BLOCKSIZE of the file.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.


 61. Opening COM1/AUX

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr90005 bcp1543 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22234

    The statement "open(3,file='com1')" generates the following error
 message:

    Error 6415: OPEN(COM1)
    -file already exists-

    The status in this OPEN statement is unknown, but the documentation
 on the error message indicates that the OPEN statement specified
 status='new'. If you explicitly specify status='old' in the open
 statement, then the error is not generated.
    Microsoft has confirmed this to be a problem with Version 4.00A of
 the FORTRAN Compiler. This problem was corrected in Version 4.01.
    Another workaround for this (besides the one mentioned above) is to
 open file 'LINE', which will access the same place. The difference is
 that when the run time sees the name 'LINE' it does not check the
 "STATUS" of the file, but it does check the "STATUS" for COM1.


 62. Unresolved External: __FHcfsubrd

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900057 bcp1553 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22239

    The following program produces an resolved external at link time if
 compiled with -FPc:

    complex z6,ans
    ans = 1.0-z6
    end

    Microsoft has confirmed this to be a problem in Version 4.00A of
 the FORTRAN Compiler. This problem was corrected in Version 4.01.
    There is no simple workaround for this problem except to compile
 with -FPi.


 63. GETFONTINFO: Documentation Error in Type Definition

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 23-APR-1990    ArticleIdent: Q60842

 The interface statement for the GETFONTINFO function shown on Page 209
 of the "Microsoft FORTRAN Advanced Topics" manual incorrectly lists
 the following line:

    INTEGER*2 avegwidth          !Average width in pixels

 The line should read as follows to conform to the definition in the
 include file FGRAPH.FD:

    INTEGER*2 avgwidth           !Average width in pixels


 64. Writing More Than 132 Characters to a Device

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900006 bcp1361 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22283

    Attempting to WRITE more than 132 characters to a device (CON, PRN,
 etc.) will cause random characters to be written. The following
 program demonstrates the problem:

    i = 12345
    write (*,'(i150)') i
    end

    This involves a problem with the run-time code that handles buffer
 overflows. The problem only occurs with WRITEs to devices, not files.
 Note, however, that files created by redirecting CON output also will
 be affected.
    A patch has been developed that will work around the problem by
 allowing the size of the device buffers to be increased. The patch
 raises the buffer size from 132 to 256 bytes. If you wish to write
 longer records, you can raise the limit to as high as 32255 bytes.
    To patch the FORTRAN Version 4.00 libraries to correctly handle
 records longer than 132 bytes written to devices, perform the
 following patch, which increases the buffer size from 132 (0084 hex)
 to 256 (0100 hex):

    /* patch the large model library first */
    LIB LLIBFOR *CORE;
    DEBUG CORE.OBJ
    E ES:48E
    00 01   /* replace the bytes 84 and 00 with bytes 00 and 01 */
    E ES:4C6
    00 01                  /* must be same two bytes */
    E ES:1052
    00 01                 /* must be same two bytes again */
    W
    Q
    LIB LLIBFOR -+CORE;

    /* now for the medium model library */
    LIB MLIBFOR *CORE;
    DEBUG CORE.OBJ
    E ES:48A
    00 01    /* replace the bytes 84 and 00 with bytes 00 and 01 */
    E ES:4C2
    00 01                    /* must be same two bytes */
    E ES:E21
    00 01                    /* must be same two bytes again */
    W
    Q
    LIB MLIBFOR -+CORE;

    /* done */

    Please note that you can increase the buffer size up to 32255 (7DFFH,
 entered as FF 7D). Never enter more than two bytes at any of the above
 locations.
    If the first byte to be changed at each address is not 84
 (hexadecimal), stop and confirm that you entered the correct address.
   Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 65. CTRL+Z Versus INCLUDE Files

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900067 bcp1603 buglist4.00 fixlist4.01
 Last Modified: 30-SEP-1988    ArticleIdent: Q22307

 Problem:

 My main program is as follows:

    c
    c This is the main program
    c
    c Now the include file (which has a CTRL+Z as the last character)
    $INCLUDE:'bcp1603a.for'
    c Since the CTRL+Z has been echoed from the INCLUDE file
    c You will not see these comments if you TYPE the .LST file
            end

 My INCLUDE file (which has a CTRL+Z as the last character) is as
 follows:

    c this is the first line of the include file
    c
    c
    $nofloatcalls
    c this is the last line of the include file

 Any attempt to TYPE the resulting .LST file stops at the end of the
 INCLUDE file.

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

 The CTRL+Z character in the INCLUDEd file is being sent to the .LST
 file and should not be. A workaround to this problem is to use the DOS
 COPY command (i.e., if file XX ends with a CTRL+Z, the following COPY
 command will create file YY, which has all the same information
 without the CTRL+Z character at the end):

 COPY XX/A YY


 66. More Than One Unnamed BLOCK DATA

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900069 bcp1614 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22351

    The compiler should give an error for the following program, but it
 does not:

    block data
    end
    block data
    end

    The ANSI X3.9-1978 FORTRAN standard states, "There must not be more
 than one unnamed BLOCK DATA subprogram in an executable program."
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    This error may result in incorrect data being placed into the
 labeled COMMON blocks. If you have more than one BLOCK DATA
 subprogram, the obvious (and correct) solution is to use named BLOCK
 DATA subprograms: one may be unnamed, but the rest must be named.


 67. Problem Reading LIB.CMP

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22339

    The following program hangs the system:

    character*5 c
    open(4,file='LIB.CMP')
    read(4,'(a)')c
    end

    This problem occurs because although LIB is not a device name,
 "LINE" is. This is another example of the PRN versus PRM problem. The
 hang occurs because "LINE" is mapped to COM1, so the program hangs
 while waiting for input.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.


 68. FL -Od *.for Error

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900065 bcp1601 buglist4.00 fixlist4.01
 Last Modified: 25-OCT-1988    ArticleIdent: Q22338

 Problem:

 When several separate source files and one of the following FL
 commands are used, different errors are received than if the routines
 are compiled one at a time:

    FL -Od *.for
    FL -Od a.for b.for c.for

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

 FL is compiling the first of the files correctly, but all subsequent
 files are being compiled as if they were compiled with the default
 maximum optimization. If -Od is going to be used, one workaround to
 this problem is to compile each source file separately.


 69. Internal Compiler Error: p3io.c, Line 604

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900070 bcp1616 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22332

 Problem:
    The following program produces a p3io.c, line 604 assertion error:

         SUBROUTINE PLSAVE
         COMMON /PLSAVE/ YOO
         YOO = YO
         END

    If compiled with -Od, it produces the following assertions:

    omf_ms.c, line 985
    %Z%%M%:%I%, line 604
    code.c, line 167

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler. It
 was corrected in Version 4.01.
    Error F2325 is generated under Version 4.01, as it should be.
    The pattern here seems to be that the SUBROUTINE and COMMON blocks
 have the same name. A workaround is to rename either the SUBROUTINE or
 COMMON block.


 70. "STOP 1" Message

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900068 bcp1612 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22308

    The following program:

    stop 1
    end

 should print as follows:

    Return code 1

    Instead, it prints the following:

    Return code Pause - 1

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.


 71. Compile Time Error F2570

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900066 bcp1602 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22306

    Compiling the following program:

    Plyevl(X1) = A1+X1*(A2+X1*(A3+X1*(A4+A5*X1)))
    B = PLYEVL(-C)
    END

 generates the following error:

    bcp1602.for(2) : error F2570: consecutive arithmetic operators illegal

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    This problem can be worked around by setting a temporary variable
 equal to -C and using it as the argument to the statement function.


 72. Compiling C Program on Page 273 of the User's Guide

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q22329

 Problem:

 I get errors when I try to compile the C program on Page 273 of the
 "Microsoft FORTRAN Optimizing Compiler User's Guide" (Section 11.3.4).

 Response:

 To compile the program, you need to change the second line of the
 program by removing the semicolon (;). The first three lines should
 read as follows:

    long time(long *);
    long time(tloc)
    long *tloc;


 73. Invalid Object Module

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-JUN-1988    ArticleIdent: Q22314

 Problem:
    I compile my module with no errors, but the linker generates the
 following error message when I link it:

    "Invalid object module"

    I have the ".FOR" extension on the end of my file on the FL command
 line. I also tried using the /Tf switch.

 Response:
    You probably are using the wrong version of the linker. You should
 be using the linker that comes with FORTRAN.
    To determine which linker you are using, do the following:

    1. Change to the directory from which you normally compile and link.
    2. Type "link".
    3. Change to the directory in which the FORTRAN compiler and linker
 reside.
    4. Type "link" again.

    The copyright message will display a version number. If these
 version numbers do not match, the linker that you are picking up is
 not the linker that came with your Microsoft FORTRAN.
    You are picking up another LINK.EXE on your system. LINK.EXE comes
 with DOS and other Microsoft language products.
    To confirm that you are picking up the wrong version, see if the
 correct LINK.EXE Version is not in your current directory. Also, see
 if your PATH environment variable is pointing to a directory that
 contains an older LINK.EXE before it points to the directory that the
 correct version is in.
    To work around this problem, do one of the following:

    1. Rename your old linkers to LINK.OLD.
    2. Change your path so that the PATH environment variable points
 to the directory that the correct version of LINK.EXE is in.

    If this does not correct the problem and you are using the correct
 LINK.EXE version, please send Microsoft Product Support Services a
 copy of your source file as a supplement to your technical assistance
 request.


 74. BTEST Function with Different Sized Arguments

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900071 bcp1618 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22342

    The following subroutine will cause unpredictable behavior (hangs,
 possibly a reboot):

            integer*2 i2
            i2 = 10
            do 100 i4=0,7
            if (btest(i2,i4)) write (*,*) 'Bit set is=',i4
    100     continue
            end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    This should happen only under the following conditions:

    1. The first argument's size is INTEGER*2.
    2. The program is not compiled with -4I2.

    Apparently, the routine being called to do the test is assuming
 that the second argument is the same size as the first.
    A quick way to verify that BTEST will not fail at run time is to
 look at the code (via -Fc or -Fa). If only four bytes are pushed
 before the call, it will fail. If six bytes are pushed, it will run.
 Note that INTEGER*2 BTEST is done by in-line code.


 75. Run-Time Error F6419 Terminating on 78th Record

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900076 bcp1635 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22380

 Problem:
    The following program will terminate on the 78th record with the
 error message "error F6419: illegal structure for unformatted file":

       DIMENSION KST(24),SPEED(24),TEMP(24),AFV(24),RFV(24),HLH(2,24),
      1 UU(24),UR(24)
       OPEN(8,FILE='bcp1635.dat',STATUS='OLD',FORM='UNFORMATTED')
       READ(8) ID,IY,IDM,IYM
       DO 100 N=1,366
       WRITE(*,150) N
  150  FORMAT('                         READING DAY ',I3)
       READ(8) IYEAR,IMONTH,DAY1,KST,SPEED,TEMP,AFV,
      1 RFV,HLH
  100  CONTINUE
       END

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    To work around this problem, if you are creating unformatted files
 for use as a temporary storage medium, change the FORM= specifier from
 'UNFORMATTED' to 'BINARY'. The READ and WRITE statements will stay the
 same.
    If you have existing unformatted data files (and cannot change
 them), you may be able to work around the problem by increasing the
 BLOCKSIZE specifier beyond the minimum 1024 bytes.


 76. Z Format Problem

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22340

    The following program will write too many characters to the
 monitor:

            character*10 short
            character*80 long
            short = 'abcd'
            long = 'xyz'
            write (*,100) short
            write (*,100) long
    100     format (1x,z)
            end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    The program is operating as expected, but it is a victim of the
 already known error that random characters will result if more than
 132 characters are written to the screen.
    The Z format, when used without the width specification, puts out
 two hex characters for each byte of the object (i.e., it puts out
 eight hex characters for an INTEGER*4, 16 for a REAL*8, etc.). In this
 case, writing out a CHARACTER*80 variable with a Z format means that
 160 characters will be printed, which demonstrates the problem of
 writing more than 132 characters to the screen.


 77. Opening a Scratch File as Unformatted

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 15-DEC-1988    ArticleIdent: Q22344

 Problem:

 Using the OPEN statement to connect the preconnected units 0, 5, or 6
 to a temporary file with form = 'unformatted' generates the following
 run-time error message:

 F6202
 -terminal I/O not consistent with OPEN options

 The following line of code causes the problem:

 open(6, form='unformatted')

 If file= is omitted in an OPEN statement, the compiler creates a
 temporary file. Therefore, this statement should not generate an error
 message.

 Response:

 This is a documentation issue. Page 102 of the "Microsoft FORTRAN
 Compiler Language Reference" manual should state that if the FILE=
 specifier is omitted in an OPEN statement for a unit other than the
 preconnected units 0, 5, and 6, the compiler creates a temporary file.

 Because the OPEN statement does not specify a filename, OPEN must
 decide whether the unit is already connected to a file. If it is not
 connected, unit 6 is opened as a scratch file. If the unit is
 connected to a file, then the BLANK specifier is the only allowed
 specifier.

 If you had specified open(3, form='unformatted'), a scratch file would
 have been created; however, units 0, 5, and 6 are preconnected
 FORM='FORMATTED' files. The error is correctly generated; the run time
 thinks that you are trying to OPEN 'CON' as an unformatted file.

 You also can achieve the desired result (a scratch file for unit 6) by
 using the following:

 OPEN (6,file='junk',form='unformatted',status='scratch')

 Renaming the file during the OPEN is crucial.


 78. "Divide by Zero" Error

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900075 bcp1634 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22415

    The following subroutine produces "error F2023: divide by zero"
 during compilation:

    subroutine sub1(cx)
    CHARACTER*(*) cx(2)
    write (*,*) cx
    end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    There are two workarounds. The following is one workaround:

    subroutine sub1(cx)
    c
    c Explicitly declare the CHARACTER size
    c
    CHARACTER*72 cx(2)
    write (*,*) cx
    end

    The following is another workaround:

    subroutine sub1(cx)
    CHARACTER*(*) cx(2)
    c
    c  Use an implied-DO WRITE statement
    c
    write (*,*) (cx(i),i=1,2)
    end


 79. INQUIRE Versus -4I2

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900086 bcp1615 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22426

    When compiled with -4I2, the following program:

            CHARACTER*25 fname
            open (1,file='test1')
            open (3,file='test3')
            do 100 i=1,4
            inquire (unit=i,name=fname)
            write (*,*) 'unit=',i,' fname=',fname
    100     continue
            end

 should produce the following output:

    unit=          1 fname=test1
    unit=          2 fname=UNKNOWN
    unit=          3 fname=test3
    unit=          4 fname=UNKNOWN

 but instead prints as follows:

    unit=      16138 fname=test1

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.

    INQUIRE is using two bytes of stack space whenever one of the
 specifiers that return a CHARACTER string (such as the NAME=
 specifier) is given. When you compile with -4I2 and maximum
 optimization, the resulting corruption of the stack becomes apparent
 because the SI register is destroyed and, unfortunately in this case,
 SI is used to store the DO loop index.
    The following are two workarounds:

    1. Compile without -4I2.
    2. Compile with -Odct (no loop optimization).


 80. Wrong Default of SHARE=

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900087 bcp1588 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22443

    The following program:

    character*30 name,mode,share
    open(1, file ='xxx')
    inquire (unit=1,mode=mode,name=name, share=share)
    write (*,*) 'MODE=[',mode,']'
    write (*,*) 'NAME=[',name,']'
    write (*,*) 'SHARE=[',share,']'
    close (1,status='delete')
    end

 should produce the following output:

    MODE=[READWRITE                     ]
    NAME=[xxx                           ]
    SHARE=[COMPAT                        ]

 but actually prints as follows:

    MODE=[READWRITE                     ]
    NAME=[xxx                           ]
    SHARE=[DENYNONE                      ]

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.


 81. Compile Time Errors F2503/F2506

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900088 bcp1650 buglist4.00 fixlist4.01
 Last Modified: 15-MAR-1988    ArticleIdent: Q22444

 Problem:
    The following program:

       CHARACTER CARD(1),C
       LOGICAL*1 BL,TEST1
       TEST1(C)=LGE(C,'A').AND.LLE(C,'Z')
       bl = TEST1(CARD(is))
       END

 produces the following compilation errors:

    bcp1650.for(4) : error F2503: LGE : incorrect use of intrinsic function
    bcp1650.for(4) : error F2506: cannot convert type to LOGICAL

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The workaround for this is to store the value of CARD(IS) in a
 CHARACTER variable and pass it instead of the array element.


 82. Unique Serial Number on Registration Card

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1987    ArticleIdent: Q22420

 Problem:
    I am following your instructions to fill out the
 registration card for your FORTRAN Compiler, but I am
 unable to access the 16-digit serial number you request. No
 serial number appears in the right-hand corner.

 Response:
    There is no unique serial number for your FORTRAN
 Compiler (or for any of our compilers). The instructions
 you are referring to pertain to Microsoft Word users only.
 You should skip this part of the registration card.


 83. Compile Time Error F2408

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22422

 Question:
    The compiler is erroneously generating error F2408 "too few
 constants to initialize data" for a data statement that uses an
 implied DO loop. Is this a reported problem?

 Response:
    This is a known problem in Version 4.00. It was corrected in
 Version 4.01.
    We have not seen this error message appear erroneously unless other
 errors precede it. Because cascading errors seem to cause this error
 to be generated, correcting the previous errors will eliminate this
 error.


 84. Optimization Bug in Character Transfer

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900080 bcp1626 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22506

    The loop optimizer apparently does not recognize that the
 destination CHARACTER array is being loaded in reverse order. It
 generates code assuming that it is a straight CHARACTER block
 transfer.
    The workaround for this problem is to compile with -Od or -Odct
 (suppressing loop optimization).
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    Here is an example of a program that recreates the problem. The
 following program:

       character*1 rd(4),tr(4)
         data rd /'1','2','3','4'/
       do 1 i=1,4
 1     tr(5-i)=rd(i)
         write (*,*) 'tr=<',tr,'>'
       end

 should produce the following output:

    tr=<4321>

 but it actually prints as follows:

    tr=<1>


 85. COMPLEX Constant Folding Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900081 bcp1633 buglist4.00 fixlist4.01
 Last Modified: 28-AUG-1990    ArticleIdent: Q22507

 The answer for "cc" in the program below is incorrect because the
 compiler does not generate the correct constant for use in the
 expression. It is generating a (0.0,0.0) when it should be generating
 a (2.0,0.0).

 The compiler, in some circumstances, is not properly creating
 constants that are calculated from an INTEGER (2) times a COMPLEX.

 There is a workaround for this problem. Do not use INTEGER constants
 as part of a COMPLEX expression. Changing both INTEGER 2s to REAL 2s
 will correct the problem.

 Microsoft has confirmed this to be a problem in version 4.00 of the
 FORTRAN Compiler. This problem was corrected in version 4.01.

 The following program is an example of how to re-create the problem.
 The following program

       complex ca,cb,cc
       r = 1.5
       ca = cmplx(.5,.1)
       cb = (0.,1.)*2*ca*r
       cc = (0.,1.)*ca*2*r
       write (*,*) 'ca=',ca
       write (*,*) 'cb=',cb
       write (*,*) 'cc=',cc
       end

 should produce the following output:

    ca=      (5.000000E-01,1.000000E-01)
    cb=         (-3.000000E-01,1.500000)
    cc=         (-3.000000E-01,1.500000)

 However, it actually prints as follows:

    ca=      (5.000000E-01,1.000000E-01)
    cb=         (-3.000000E-01,1.500000)
    cc=      (0.000000E+00,0.000000E+00)


 86. CHARACTER Functions in WRITE Statements

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900083 bcp1638 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22508

 Problem:
    The following program:

    character*10 c
    i = 1
    j = 2
    k = 3
    l = 4
    m = 5
    write(*,*)c(i),c(j),c(k),c(l),c(m)
    end
    character*10 function c(ix)
    character*10 ctemp
    write (ctemp,'(5x,i5.5)') ix
    c = ctemp
    end

 should produce the following output:

    00001     00002     00003     00004     00005

 but actually prints as follows:

    00001     00002     00003     00001     00001

 Response:
    You can work around this problem by storing the function results in
 temporary CHARACTER*10 variables and then writing them out instead of
 the functions themselves.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.


 87. Compile Time Error F2529

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900082 bcp1637 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 27-MAY-1988    ArticleIdent: Q22504

    The following program:

         character*1 c(5),d
         logical l,m
         l(d)=(d.eq.'a'.and.d.ne.'d')
         i=5
         m=l(c(i))
         end

 produces the following compilation errors:

 bcp1637.for(19) : error F2529: operands of relation not numeric or character
 bcp1637.for(19) : error F2529: operands of relation not numeric or character

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    The program fails due to the use of a CHARACTER array element as an
 argument to a LOGICAL statement function that is expecting a single
 character.
    The workaround is to store c(i) in a temporary CHARACTER variable
 and pass the temporary to the function.


 88. Compile Time Error F2734

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900106 bcp1687 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22595

 Problem:
    The following program:

 C
         OPEN(11,FILE='TMP',RECL=12,ACCESS='DIRECT',FORM='FORMATTED')
         DO 10 I=1,10
         WRITE(11,'(I5)',REC=I)I
 10      CONTINUE
         DO 20 I=5,15
         READ(11,'(I5)',END=30,REC=I,IOSTAT=N)M
         WRITE(*,*)'Read ',m,' from record ', i,'iostat=',n
 20      CONTINUE
         WRITE(*,*)'No err detected'
         CLOSE (11, STATUS='DELETE')
         STOP
 30      WRITE(*,*)'End found'
         CLOSE (11, STATUS='DELETE')
         END

 causes the following compilation error:

    may29.for(21) : error F2734: END= : illegal when REC= present

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    In Version 4.00, this was expected behavior, conforming to the ANSI
 X3.9-1978 FORTRAN standard. However, since the run time permits a
 direct-access file to be accessed sequentially, it would be convenient
 to be able to detect end-of-file on direct-access files. This is
 corrected in Version 4.01 of the compiler. The compilation error still
 will be given if the program is compiled with the -4Ys ($STRICT)
 option.


 89. WRITE of CHARACTER*(*) Substring

 Product Version(s): 4.00A 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900085 bcp1641 buglist4.00 buglist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22509

 Problem:
    The following program

    character*20 c
    c='no time for musicians'
    call s(c)
    end
    subroutine s(c)
    character*(*) c
    write(*,*)c(1:10)
    end

 should print the following:

    no time fo

    However, it actually prints only blanks.

 Response:
    This is a known problem in Versions 4.00 and 4.01.
    The workaround is to declare "c" to be CHARACTER*20 instead of
 CHARACTER*(*) in the subroutine.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 90. Bad Constant Fold of Loop Invariant

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900079 bcp1632 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22505

 Problem:
    The following program:

         x = 1.
         y = 1.
         z = 1.
         write (*,*) 'all answers should be 10001'
         do 10 i=1,10000
         x = x+y/z
 10      continue
         print *,x
         end

 should print the following:

    all answers should be 10001
       10001.000000

 but actually prints as follows:

    all answers should be 10001
         151.197500

 Response:
    The .COD file shows that the generated code is trying to calculate
 the final value of X at the point where the source code shows it being
 initialized to 1.0. This would be correct; however, in the first
 step of the calculation, a value is loaded from a temporary that never
 was initialized. Therefore, what finally is stored in X is
 <garbage>*10000+1. In this case X=151.1975. This will vary.
    This problem can be worked around by compiling with -Odclt.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 91. Compile Time Error F2125

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900084 bcp1640 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22510

    The following program produces the following error:

    "bcp1640a.for(4) : error F2125 : BUFF2 : allocation exceeds 64K":

    INTEGER*4 BUFF2(480)
    INTEGER*4 BUFF(18000)
    EQUIVALENCE(BUFF2(1),BUFF(1))
      end

    This problem lies with EQUIVALENCEing a huge array (i.e., more than
 64K) with a "non-huge" array.
    The problem can be worked around by declaring the huge arrays that
 are going to be EQUIVALENCEd before declaring the "non-huge" arrays.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler.
    This problem was corrected in Version 4.01.


 92. Errors in ISHFT and ISHL Functions

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900077 bcp1639 buglist4.00 fixlist4.
 Last Modified:  1-JUN-1988    ArticleIdent: Q22517

 Problem:
    The following program:

       integer*2 inta,itemp
       inta=#8000
         call sub (inta)
       itemp=ishft(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp
       inta=#8000
         call sub (inta)
       itemp=ishl(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp

       inta=#8000
       itemp=ishft(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp
       inta=#8000
       itemp=ishl(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp
         end
         subroutine sub (ix)
         integer*2 ix
         end

 produces the following output:

    should be #2000, is=E000
    should be #2000, is=E000
    should be #2000, is=E000
    should be #2000, is=E000

 Response:
    There are two separate errors in the above example. Both occur
 because the compiler is converting INTA to be an INTEGER*4 variable.
 This is causing problems for the ISHFT and ISHL functions, which are
 logical shift functions. Logical shifting operands to the right should
 add ("shift in") zero bits to the high-order part of the variable.
    In the first pair of ISHFT/ISHL calls, the answers are calculated
 by calls to a library routine. ITEMP cannot be calculated by the
 compiler because the value of INTA may have been changed in the
 preceding subroutine call.
    The errors in these calls occur because during the setup for the
 calls to the shift routines, INTA is converted from INTEGER*2 to
 INTEGER*4 from the value of #8000 to #FFFF8000; i.e., the upper word
 is sign-extended. Subsequently, when the two-bit right shift is done,
 bits (all of which are set) are shifted into the lower two words.
    The second pair of answers is calculated during compilation and is
 incorrect for the same reason: the answers are treated as four-byte
 integers.
    To work around this problem, compile with the -4I2 option.
    This is a confirmed problem in Version 4.00 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.01.


 93. Linker Cannot Find LLIBFOR7.LIB

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-OCT-1988    ArticleIdent: Q22588

 Problem:

 I do not have a coprocessor on my system, so I built a FORTRAN library
 with emulator support (LLIBFORE.LIB) using the Setup utility. I am
 using the Version 3.55 Linker that comes with FORTRAN Version 4.00. I
 set my LIB environment variable to C:\FORTRAN\LIB, and when I do DIR
 on this directory, it finds LLIBFORE.LIB. However, when I enter the
 command "FL DEMO.FOR", the linker generates the following warning
 message:

    Warning L4051: LLIBFOR7.LIB: cannot find library

 Response:

 When FL compiles a source file, it places the name of a FORTRAN
 library into the object file that it creates. The library name
 corresponds to the memory-model and floating-point options that you
 specify on the FL command line. If you do not specify any memory-model
 or floating-point options, FL defaults to large-model and coprocessor
 (8087/80287) support, and therefore places the library name
 "LLIBFOR7.LIB" in your object module. When you link the object module,
 the linker looks for a library matching the name embedded in the
 object file. If it finds the library, it automatically links the
 library with the object module.

 Because the command line "FL DEMO.FOR" does not explicitly specify a
 floating-point option, DEMO.OBJ contains the library name
 LLIBFOR7.LIB; that is the library name for which the linker looks.
 Because you did not create a LLIBFOR7.LIB with Setup, the linker
 returns a warning that it cannot find the library.

 Therefore, to link your object files with the LLIBFORE.LIB emulator
 library, you need to specify the floating-point option /FPi or /FPc on
 the FL command line.

 For more information regarding the floating-point options, please
 refer to Page 59 in the user's guide.


 94. Missing Line in Program Listing

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q22629

 Problem:

 There is an error in the program listing on Page 332 of the "Microsoft
 FORTRAN Compiler Language Reference" manual. Compiling as is will
 result in a syntax error.

 Response:

 There is a missing line in the program listing. Currently, line 19
 contains the following:

 + CDATE,IMON,IDAY,IYR

 There should be a line before it. The following line will correct the
 syntax error problem.

 WRITE(*,'(1X,A,I2.2,1H-,I2.2,1H-,I4)')


 95. Backspacing Past CR/LF on a Buffer Boundary

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900107 bcp1694 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22601

    The program below demonstrates a boundary condition problem. The
 program correctly writes 210 five-byte records (three digits plus
 CR/LF), REWINDs the file, and then proceeds to do a sequence of READ,
 READ, BACKSPACE operations. This process is successful until the 205th
 record. The CR/LF pair that follows the 205th record is split between
 two buffers. When the subsequent BACKSPACE occurs, the run time
 effectively gets "stuck" on the LF in the 206th record. Raising the
 BLOCKSIZE may circumvent the problem; however, more likely, it will
 simply postpone it.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The following program:

         open (1,file='bcp1694.dat')
         do 100 i=1,210
           write (1,'(i3)') i
 100     continue
         rewind (1)
         do 200 i=1,210
         read (1,'(i3)') i1
         read (1,'(i3)',end=999) ihold
         backspace 1
         if (i .ge. 200) write (*,*) 'rec #,curr rec #,next rec #=',
      +  i,i1,ihold
 200     continue
 999     continue
         close(1,status='delete')
         end

 should produce the following output:

 rec #,curr rec #,next rec #=        200         200         201
 rec #,curr rec #,next rec #=        201         201         202
 rec #,curr rec #,next rec #=        202         202         203
 rec #,curr rec #,next rec #=        203         203         204
 rec #,curr rec #,next rec #=        204         204         205
 rec #,curr rec #,next rec #=        205         205         206
 rec #,curr rec #,next rec #=        206         206         207
 rec #,curr rec #,next rec #=        207         207         208
 rec #,curr rec #,next rec #=        208         208         209
 rec #,curr rec #,next rec #=        209         209         210

    However, it actually prints the following:

 rec #,curr rec #,next rec #=        200         200         201
 rec #,curr rec #,next rec #=        201         201         202
 rec #,curr rec #,next rec #=        202         202         203
 rec #,curr rec #,next rec #=        203         203         204
 rec #,curr rec #,next rec #=        204         204         205
 rec #,curr rec #,next rec #=        205         205         206
 rec #,curr rec #,next rec #=        206           0         206
 rec #,curr rec #,next rec #=        207           0         206
 rec #,curr rec #,next rec #=        208           0         206
 rec #,curr rec #,next rec #=        209           0         206
 rec #,curr rec #,next rec #=        210           0         206


 96. Using FL with the /NOI Option

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q22761

 Question:

 Page 54 in the "Microsoft FORTRAN Optimizing Compiler User's Guide"
 states that FL always uses the /NOI link option in the linking stage.
 I have found that this is not always the case. For example, the
 following command line emits the following /NOI option:

 FL demo

 However, the following command line does not:

 Fl demo.for

 Is this a documentation error?

 Response:

 Yes, this is a documentation error. In the FORTRAN Version 4.00, the
 /NOI switch only is emitted if only object files are specified on the
 FL command line. If only source files (.FOR) are specified, or if a
 mixture of source and object files is specified, the /NOI switch is
 not generated.


 97. REC=1 Should Be RECL=1

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q22788

 Question:

 Is there is a documentation error on Page 121 in the "Microsoft
 FORTRAN Optimizing Compiler Language Reference" manual on the fifth
 line from the bottom? Should "REC=1" should be changed to "RECL=1"?

 Response:

 Yes. "REC=1" should be "RECL=1".


 98. Run Time Error F6419

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900089 bcp1648 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22719

    The following program will produce the following error and then may
 hang the computer:

    "F6419 :illegal structure"

       parameter (m = 119, n = 520)
       integer*1 ia(n),ib(n),ja(m),jb(m)
       do 11 j = 1,m
       ja(j) = mod(j,256)
 11    continue
       do 10 i = 1,n
       ia(i) = mod(i,256)
 10    continue
       open (33,file = 'ufseq',form='unformatted',blocksize=512)
       write (33) ja
       write (33) ia
       rewind(33)

       read (33) jb
       do 21 j = 1,m
       if (ja(j).ne.jb(j)) goto 51
 21    continue
       read (33) ib
       do 20 i = 1,n
       if (ia(i).ne.ib(i)) goto 50
 20    continue
       stop 'passed'

 51    write (*,*) ja(i), '.ne.', jb(i)
       write (*,*) 'j = ',j
       stop 'failed'
 50    write (*,*) ia(i), '.ne.', ib(i)
       write (*,*) 'i = ',i
       stop 'failed'
       end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    This is one of several possible causes for this error. It is very
 specific: READing an unformatted file that contains a record whose
 "trailer-byte" (a byte containing the length of the preceding record)
 is placed exactly on a buffer boundary (in this case, the 512th byte)
 will cause the error to occur on that record.
    Investigating this error also turned up the fact that the F6419
 error message itself is being truncated. It should read "F6419 :
 illegal structure for unformatted file". The routine that writes the
 error message is losing track of where the message ends.
    Until more is known about the causes for the F6419 error, the
 workarounds remain as follows:

    1. Those who use unformatted files within their programs for the
 purpose of temporary data storage can change the OPEN statement's
 FORM= specifier for their files from 'UNFORMATTED' to 'BINARY'. The
 associated READ and WRITE statements need not be changed.
    2. Those with existing unformatted data files may be able to work
 around this problem by increasing the size of the file's buffer by
 using the BLOCKSIZE= specifier on the OPEN statement.


 99. Zero-Trip Implied-DO in READ

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900101 bcp1680 buglist4.00
 Last Modified: 27-MAY-1988    ArticleIdent: Q22838

 Problem:
    The following program:

       DIMENSION IX(10)
       DO 1000 I=1,10
           IX(I)=I
  1000 CONTINUE
 C
       ISTART=0
       IEND=-1
       WRITE(*,8000)(IX(I),I=ISTART,IEND),778
  8000 FORMAT(8I10)
       END

 should produce the following output:

       778

    However, it actually prints only blanks.

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The workaround is to avoid using erroneous values for the loop
 indices.


 100. Run-Time Error F6600

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900100 bcp1682 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22837

 Problem:
    The following program:

         character str*10
         call sub1 (str)
         write (*,*) 'str should be 12345, is=<',str,'>'
         end
         subroutine sub1(str)
         character str*(*)
         inum = 12345
         write (str(2:6),'(i5)') inum
         end

 should produce the following output:

    str should be 12345, is=<12345>

    However, it actually prints the following:

    run-time error F6600: WRITE(internal)
    - internal file overflow

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The problem can be worked around in the following two ways:

    1. In the subroutine, declare STR to be of a fixed size instead of
 CHARACTER*(*).
    2. In the internal WRITE, use STR instead of the substring of STR.


 101. EQUIVALENCE of ENTRY Arguments

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900097 bcp1677 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22833

    The following program should fail with a compilation error that
 indicates that you cannot EQUIVALENCE a formal argument:

         subroutine test
         equivalence (a,c)
         entry test1 (a,b)
         c = 1.0
         end

    This is a known problem in Version 4.00 of the FORTRAN Compiler.
 This was corrected in Version 4.01.


 102. Internal Compiler Error: regMD.c 1.74, Line 1204

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900093 bcp1666 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22827

    The following program:

         integer*4 comp(2,10)
         integer*2 br(10),locx(10),stor(10),flav(10),age(10)
         do 6 i=1,mpt
            comp(1,i) = (((10*br(i) + locx(i))*10 + stor(i))*10 +
      +                    flav(i))*100 + age(i)
 6          comp(2,i) = i
         end

 produces the following assertion error:

         regMD.c:1.74, line 1204

    This is a known problem in Version 4.00 of the FORTRAN compiler. It
 was corrected in Version 4.01.
    To work around this problem, modify the statement COMP(1,I) = ...,
 as follows:

    1. Assign all of the array references to integer variables.
    2. Use them in place of the array references in the expression.


 103. -4I2 Compiler Hang

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900092 bcp1665 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22826

    The following program will hang the compiler if compiled with -4I2:

    50 MANTIS = DINT (.5D0 + DVAL * DTEN ** (SIGNIF-MAGN))
       IF (KTEST)  60, 65, 55
    55 MAGN = MAGN - 1
       GO TO 50
    60 MAGN = MAGN + 1
    65 IF (MAGN .GT. -3 .AND. MAGN .LE. MIN0(WIDTH, SIGNIF+3)) GO TO 70
    70    IF (MAGN .GE. 1) GO TO 75
    75       DO 80 I = 1, MAGN
    80       CONTINUE
       END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The workaround is to compile with -Odclt or without -4I2.


 104. OPENing an OPEN File

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900118 bcp1620 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22818

 Problem:
    The following program:

         character*10 nm
         open(1, file='xxx')
         inquire(1, name=nm)
         write(*,*) nm
         open(1, BLANK='null')
         inquire(1, name=nm)
         write(*,*) nm
         end

 should produce the following output:

 xxx
 xxx

    However, it actually prints the following:

 xxx
 ZZ004413

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The intent of this program is to change the setting of the BLANK
 specifier on an OPEN file. The run time is CLOSEing the file and then
 OPENing a scratch file that has the correct BLANK setting instead of
 just changing the setting of BLANK.


 105. OPEN(1,FILE= ' ',STATUS=cvar)

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900099 bcp1681 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22836

 Problem:
    The following program:

         character*30 stat
         stat = 'UNKNOWN'
         open (1,file=' ',status=stat,iostat=ier)
         write (*,*) 'iostat should be 0, is=',ier
         end

 should produce the following output when given a filename at
 run time:

    iostat should be 0, is=          0

    However, it actually prints the following:

    iostat should be 0, is=       6304 (illegal status value)

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    Whether the contents of STAT are uppercase or lowercase is
 irrelevant: it still does not work. The workaround is to use character
 constants instead of variables.


 106. Compile Error F2609

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900121 bcp1713 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 27-MAY-1988    ArticleIdent: Q22820

    The following program:

       SUBROUTINE LNSR(X,N,D,FUNC,ST0,XS)
       DIMENSION X(N),D(N),XS(N)
       CALL FUNC(XS,N,FOPT,*100)
  100  CALL VEC(X,D,N,ST0,X)
       END
       SUBROUTINE DLNSR(A0,NP,FU0,SFPD,S,ST0,FUNC,NST,A1,KENT)
       EXTERNAL FUNC
       DIMENSION A0(NP),S(NP),A1(NP)
 2000  CALL LNSR(A0,NP,S,FUNC,ST0,A1)
       RETURN
       END

 will produce the following error when compiled:

 error F2609: LNSR : formal argument * : actual not alternate-return label

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The compiler apparently has confused a function passed as an
 argument for an alternate-return argument. You can work around the
 error, at least in this case, by moving the subroutine LNSR to the end
 of the source file.


 107. Sending a Spawn Command

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-MAY-1988    ArticleIdent: Q29561

    The following program is an example of using the spawn function to
 spawn an EXE file that takes no arguments. This example is similiar to
 the one found on Page 298 of the Version 4.01 "Microsoft FORTRAN
 Optimizing Compiler User's Guide."

       interface to integer*2 function spawn
      + [c, varying, alias:'_spawnlp'](mode)
       integer*2 mode
       end

       integer*2 spawn

       write(*,*) 'time to start'
       i = spawn(0, loc('test.exe'c), loc('test'c), int4(0))
       write(*,*) 'its done now'

       stop
       end

    The following three points are important to notice:

    1. An alias (mentioned on Page 297) is needed for names over six
 characters.
    2. Spawn is declared as integer*2.
    3. When sending spawn, 'test.exe' and 'test' must be sent together.


 108. Sending FORTRAN Output to the Printer

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 31-OCT-1989    ArticleIdent: Q22830

 Question:

 How do I output data from my FORTRAN program to the printer?

 Response:

 You can access the printer by treating it as a SEQUENTIAL access
 file with one of the following system names:

      PRN
      LPT1
      LPT2
      COM1

 The following example sends output to the printer:

       OPEN(3,FILE='PRN')
       WRITE(3,*)'OUTPUT GOES TO THE PRINTER'
       END

 The OPEN statement associates UNIT #3 with the system file PRN, and
 then opens the printer for output. The UNIT does not have to be #3; it
 can be any UNIT number. The WRITE statement sends output to UNIT #3,
 which is the printer.

 For output to LPT2, status='old' must be included or the run-time
 error "F6415 -file already exists" is generated.

 It should be noted that the system name you use is dependent upon your
 particular system, and you may have to experiment to see which one
 works correctly for you. If you have a serial printer attached to your
 communications port, you should use the MS-DOS MODE command to tell
 the operating system to send printer output to the communications port
 instead of to the regular printer port.


 109. END=var Not Caught by the Compiler

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900114 bcp1703 buglist4.00
 Last Modified:  7-NOV-1988    ArticleIdent: Q22832

 Problem:

 When the following program runs, it hangs:

                    total = 0
                    abc = 200
                    count = 0

    100          count = count + 1
                    read(1,'(i7)',end=abc) value
                    total = total + value
                    goto 100
    200             write(*,*) 'done'
                    stop ' '
                    end

 Response:

 The program is incorrect. Variable ABC cannot be used as the target of
 an END=. END= requires a statement number and ONLY a statement number.
 The program loops because the code for the END= check is not
 generated. The compiler SHOULD be giving a syntax error for the READ
 statement.

 Microsoft has confirmed this to be a problem in Version 4.00. We are
 researching this problem and will post new information as it becomes
 available.

 To solve this problem, correct the syntax.


 110. BACKSPACE Problem

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900098 bcp1679 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22834

    In the following program the file is positioned incorrectly,
 apparently in attempting to reposition from the second record to the
 first. Since this problem appears to be related to the file buffering,
 a possible workaround might be to use the BLOCKSIZE= specifier in the
 OPEN statement to increase the buffer size (which, in this case,
 allows the program to work correctly).
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The following program:

         CHARACTER*80 alpha
         open (1,file='bcp1679.dat')
 5       continue
         read (1,10,end=100) alpha
 10      format (a80)
         write (*,20) alpha
 20      format (1x,a79)
         backspace 1
         read (1,10) alpha
         write (*,20) alpha
         go to 5
 100     continue
         end

 given the following data file:

 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000

 should produce the following output:

 111111111111111111111111111111111111111111111111111111111111
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000

    However, it actually prints:

 111111111111111111111111111111111111111111111111111111111111
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000


 111. Direct Access REC= -1

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900105 bcp1691 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22835

 Problem:
    The following program:

         character*8 junk
         open (1,file='may28.dat',access='direct',recl=8)
         write (1,rec=1) 'Stuff'
         close(1)
         open (1,file='may28.dat',access='direct',recl=8)
         read (1,rec=  0,iostat=ier) junk
         write (*,*) 'For rec=  0, iostat should be 6311, and is=',ier
         read (1,rec= -1,iostat=ier) junk
         write (*,*) 'For rec= -1, iostat should be 6311, and is=',ier
         read (1,rec= -2,iostat=ier) junk
         write (*,*) 'For rec= -2, iostat should be 6311, and is=',ier
         close (1,status='delete')
         end

 should produce the following output:

    For rec=  0, iostat should be 6311, and is=       6311
    For rec= -1, iostat should be 6311, and is=       6311
    For rec= -2, iostat should be 6311, and is=       6311

    However, it actually prints the following:

    For rec=  0, iostat should be 6311, and is=       6311
    For rec= -1, iostat should be 6311, and is=          0
    For rec= -2, iostat should be 6311, and is=       6311

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The run time seems to treat the REC = -1 case exactly the same as
 if the REC= were not there, i.e., it reads the next record.


 112. Expressions in IF Statements

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900096 bcp1676 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22831

 Problem:
    The following program:

         xmax = 14.8
         do 30 i = 1,20
         if (xmax .le. i*5.) then
                 write (*,*) 'i should be 3, is=',i
                 go to 31
         endif
 30      continue
         stop 'error'
 31      stop
         end

 should produce the following output:

 i should be 3, is=          3
 Stop - Program terminated.

    However, it actually prints the following:

 i should be 3, is=         15
 Stop - Program terminated.

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    Within the DO loop, the expression i*5. is never calculated. What
 is being compared against XMAX is i, not i*5; therefore, the loop is
 terminated after 15 iterations instead of three.
    There are a number of workarounds, as follows:

    1. Compile with -Odclt.
    2. Enclose the expression i*5. in parentheses.
    3. Set a temporary integer variable equal to i, and use it in place
 of i within the loop.


 113. HUGE Arrays on ENTRY Statements

 Product Version(s): 4.00A 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900094 bcp1671 buglist4.00 buglist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22828

 Problem:
    The following program:

         dimension x(20000)
         do 100 i=1,20000
           x(i) = i
 100     continue
         n = 20000
         write (*,*) 'in main        ',1,x(1),n,x(n)
         call sub2ad (x,n)
         call sub3as (x,n)
         end
         subroutine sub2x
         dimension y(n)
         entry sub2ad (y,n)
         write (*,*) 'at entry sub2ad',1,y(1),n,y(n)
         end
         subroutine sub3x
         dimension y(*)
         entry sub3as (y,n)
         write (*,*) 'at entry sub3as',1,y(1),20000,y(20000)
         end

 should produce the following output:

 in main                  1        1.000000       20000    20000.000000
 at entry sub2ad          1        1.000000       20000    20000.000000
 at entry sub3as          1        1.000000       20000    20000.000000

    However, it actually prints the following:

 in main                  1        1.000000       20000    20000.000000
 at entry sub2ad          1        1.000000       20000     3616.000000
 at entry sub3as          1        1.000000       20000     3616.000000

 Response:
    This is a known problem in Versions 4.00 and 4.01.
    The only workaround is to declare the arguments in the SUBROUTINE
 header.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 114. Internal READ from Substring

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900122 bcp1717 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22819

    The following program:

    character*15 ln
    ln = '  1234'
    n1 = 1
    n2 = 8
    read (ln(1:8),'(i10)') ival
    write (*,*) ' ln(1:8) ival should be 1234, is=',ival
    read (ln(1:n2),'(i10)') ival
    write (*,*) ' ln(1:n2) ival should be 1234, is=',ival
    read (ln(n1:8),'(i10)') ival
    write (*,*) ' ln(n1:8) ival should be 1234, is=',ival
    read (ln(n1:n2),'(i10)') ival
    write (*,*) ' ln(n1:n2) ival should be 1234, is=',ival
    end

 should produce the following output:

    ln(1:8) ival=       1234
    ln(1:n2) ival=       1234
    ln(n1:8) ival=       1234
    ln(n1:n2) ival=       1234

  however, it actually prints the following:

    ln(1:8) ival=       1234
    ln(1:n2) ival=          0
    ln(n1:8) ival=       1234
    ln(n1:n2) ival=       1234

    This is a known problem in Version 4.00.
    The error seems to occur only when READing from a substring of an
 internal file where the substring is of the form STR(const:var).
    This problem was corrected in Version 4.01 of the FORTRAN compiler.


 115. Type Coercion within Intrinsics

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900143 bcp1743 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22998

 Problem:
    The following program:

         integer*4 pos,pa
         data n /30000/, pos /60413/, pa /1/
         m = min0(n,pos-pa+1)
         write (*,*) 'm=',m
         write (*,*) 'min0(n,pos-pa+1)=',min0(n,pos-pa+1)
         end

 produces the following output if compiled with the option -4I2:

 m=      -5123
 min0(n,pos-pa+1)=      30000

 instead of the following correct output:

 m=      30000
 min0(n,pos-pa+1)=      30000

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The easiest workaround is to compile without using the -4I2 option.


 116. Run-Time Error M6101

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900133 bcp1742 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22997

 Problem:
    The following program:

         dimension a(0:100), b(0:100)
         n = 100
         do 1 i=1,n
         fi = float(i)
         arg = fi/3.
         a(i) = sin(arg) - sin(2.*arg) - sin(5.*arg)
         b(i) = cos(arg) + cos(2.*arg) + cos(5.*arg)
 1       continue
         end

 produces the following run-time error:

    run-time error M6101: MATH
    - floating-point error: invalid

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    You can work around the problem by compiling with -Od or -Odlt.


 117. Huge .LST Files

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900130 bcp1735 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22993

 Problem:
    The following program, compiled with the -Fs option, produces an
 .LST file that exceeds 260,000 characters in size:

 $linesize:132
 $page
       end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The workaround is to use a value of $LINESIZE that is less than or
 equal to 127 characters.


 118. Multiple CHAR Parameter Lengths Confused

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900127 bcp1690 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22943

 Problem:
    The following program:

         character*2 y
         CALL x('a',y('12'),'tyu')
         END
         subroutine x(c1,c2,c3)
         character*(*) c1,c2,c3
         write (*,*) 'c1 should be a, is =<',c1,'>'
         write (*,*) 'c2 should be 12, is =<',c2,'>'
         write (*,*) 'c3 should be tyu, is =<',c3,'>'
         end
         character*2 function y (ch)
         character*(*) ch
         y = ch
         end

 should print the following:

 c1 should be a, is =<a>
 c2 should be 12, is =<12>
 c3 should be tyu, is =<tyu>

    However, it actually prints the following:

 c1 should be a, is =<a1>
 c2 should be 12, is =<1>
 c3 should be tyu, is =<ty>

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    This error will occur only if more than one CHARACTER argument is
 passed. There is no workaround.


 119. Error Message Positions Versus $INCLUDE Files

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900131 bcp1736 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22994

    The following program:

    $include:'test'
            hgjfdhgjkfdhgjkf
            end

 has the following $INCLUDE file (test):

         integer x
         integer y
         integer z
         integer a
         integer b
         integer c

    The program has a syntax error on line 2 of the main program. If
 option -Fs is used, the error message will appear under line 2 of the
 $INCLUDE file ("integer y") in the .LST file.
    This was a confirmed problem in Version 4.00a.
    This problem was corrected in Version 4.01.
    There is no workaround.


 120. Optimization Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900132 bcp1741 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 26-MAY-1988    ArticleIdent: Q22996

 Problem:
    The following program:

         nmin = 1
         nmax = 2
         do 120 i=1,2
         write (*,*) 'nmin=',nmin
         do 110 m=nmin,2,nmax
         write(*,*) 'm,nmin=',m,nmin
 110     continue
         nmin =2
         nmax = nmax+1
 120     continue
         end

 produces the following correct output when compiled with -Od:

 nmin=          1
 m,nmin=          1           1
 nmin=          2
 m,nmin=          2           2

    However, when compiled with the default option, the program prints
 the following:

 nmin=          2
 m,nmin=          2           2
 nmin=          2
 m,nmin=          2           2

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    You can work around this problem by compiling with option -Od or
 -Odct.


 121. Integer Overflow Is Not Being Checked

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-MAR-1988    ArticleIdent: Q27850

 Problem:
    The following code will not check for integer overflow correctly.

        integer*4 d
        real*4 x
        d = 13
        x = 1123.000
        write(*,1) x/10**d
        write(*,1) x/10.0**d
  1     format(f40.20)
        stop

 The first write statement will give an incorrect answer because of
 unchecked integer overflow.

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.


 122. Direct Access File Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900129 bcp1732 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22945

 Problem:
    The program below attempts to execute the following steps:

    1. OPEN a direct access formatted file.
    2. WRITE to it until an error occurs (which, presumably, will be an
 error 6422 - no space left on device).
    3. ReWRITE the first record (with content that differs from what
 was first put there).
    4. CLOSE the file, OPEN it as a formatted sequential file, and READ
 the first record.
    5. Check to make sure that the first record contains the
 information put there following the "no space" error.

    The program is as follows:

         character*10000 line
         n = 1
         open (1,file='test.dat',access='direct',recl=10000,
      +  form='formatted')
 100     continue
         write (1,'(a)',rec=n,err=900,iostat=ier) line
         n = n+1
         go to 100
 900     continue
         write (1,'(a,i3)',rec=1,err=999) 'Disk full at record=',n-1
 999     continue
         close (1)
         open (1,file='test.dat')
         read (1,'(A)') line
         if (line(:9) .eq. 'Disk full') then
           write (*,*) 'Test passed'
         else
           write (*,*) 'Test failed'
         endif
         close (1,status='delete')
         end

    The following output should be produced:

    Test passed

    However, the following actually is printed:

    Test failed

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The "Test failed" message is printed because the run time produces
 an "error F6601 - direct record overflow" when Step 3 above is
 attempted. The error apparently is caused by a failure to update a
 buffer pointer following the "no space" error. There is no workaround.


 123. Inquire by File on Devices

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr 900150 bcp 1772 buglist4.00 fixlist4.10
 Last Modified: 30-SEP-1988    ArticleIdent: Q23118

 The program below does not produce the correct output.

 Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.10.

 The following program demonstrates the problem:

         character*10 dev(5)
         logical test
         dev(1) = 'com1'
         dev(2) = 'prn'
         dev(3) = 'aux'
         dev(4) = 'nul'
         dev(5) = 'con'
         do 100 i=1,5
           inquire (file=dev(i),exist=test)
           if (test) write (*,*) 'file ',dev(i),' exists'
 100     continue
         end

 The program should produce the following output; however, it does not
 print anything:

 file com1       exists
 file prn        exists
 file aux        exists
 file nul        exists
 file con        exists


 124. F1901 Compile Error Caused by Many Equivalences

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-JUN-1988    ArticleIdent: Q27986

    The F1901 "program too large for memory" error message occurs when
 compiling a FORTRAN program consisting of 55 equivalences. The
 following partial code demonstrates this problem by equivalencing two
 arrays.
    However, since arrays are required to be contiguous in memory, you
 need only equivalence the first element of the two arrays to
 accomplish the same effect, thereby avoiding the error.
    The following code fragment demonstrates this workaround for
 equivalencing the two arrays in the program below:

    REAL*8 A(200)
    REAL*8 B(200)
    EQUIVALENCE (A(1),B(2))
    END

    The other equivalences are not necessary. This problem does not
 occur with fewer equivalences. Another program shows this problem
 after 63 equivalences. This problem is also dependent on the size of
 the program and the code.
    Microsoft is researching this problem and will post new information
 as it becomes available.

    The following code demonstrates the problem:

       REAL*8    A(200)
       REAL*8    B(200)
       EQUIVALENCE
      +(A( 1),B( 1)),
      +(A( 2),B( 2)),
      +(A( 3),B( 3)),
             .
             .
             .
      +(A(54),B(54)),
      +(A(55),B(55))
       END


 125. FORMAT Can Give Output of Negative Zero

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | 4.10
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q27988

    The following program:

       REAL*8 RR(6)
       RR(1)=-0.00004999D0
       RR(2)=-0.00005000D0
       RR(3)=-0.00005100D0
       RR(4)=-0.00000999D0
       RR(5)=-0.00001000D0
       RR(6)=-0.00001001D0
       WRITE(*,911) RR
 911   FORMAT(/' RR :',6F10.4)
       END

 gives the following output:

 RR :    -.0000   -.0001   -.0001    .0000   -.0000   -.0000

 with negative zeros as output.

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.


 126. Optimizer Deleting EQUIVALENCEd Variable Assignment

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900138 bcp1751 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23262

 Problem:
    The function of the following program is to sum four UNSIGNED
 two-byte integers (65535, 65534, 65533, and 65532) and place the
 result in a four-byte integer variable as in the following example:

         implicit integer*2 (a-z)
         dimension buf(4),lc2(2)
         integer*4 lc4,tot4
         equivalence (lc2,lc4)
         data buf /-1,-2,-3,-4/
         lc2(2) = 0
         do 10 i = 1,4,2
         lc2(1) = buf(i)
         tot4 = tot4+lc4
         lc2(1) = buf(i+1)
         tot4 = tot4+lc4
 10      continue
         write (*,*) 'tot4 should be 262134, is=',tot4
         end

    It should produce the following output:

 tot4 should be 262134, is=     262134

    However, the following actually is printed:

 tot4 should be 262134, is=     196600

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The only workaround is to disable optimization by compiling with
 option -Od.


 127. Optimization Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900156 bcp1783 buglist4.00
 Last Modified:  2-MAY-1988    ArticleIdent: Q23264

 Problem:
    The following program:

         integer id(2)
         alat = 34.55555555
         call ddms (alat,id)
         end
         subroutine ddms (alat,id)
         integer id(2)
         real*4 rl(2)
         rl(1) = alat
         do 10 k=1,1
           rll = rl(k)
           id(k) = rll
           d = id(k)
           diff = rll-d
           write(*,*) 'diff should be 5.555573E-01, is=',diff
 10      continue
         end

 should produce the following output:

 diff should be 5.555573E-01, is=   5.555573E-01

    However, it actually prints the following:

 diff should be 5.555573E-01, is=   0.000000E+00

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The only workaround is to compile with -Od.


 128. Incorrect Code Deletion

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900153 bcp1778 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23265

    The following program:

         integer*4 pytab(300)
         common /pytab/ pytptr,pytab
         l1 = 5
         l2 = 5
         pytptr = 1
         dv = 7
         pytab(pytptr) = dv
         pytab(pytptr) = ior(ishft(pytab(pytptr),14),l1)
         pytab(pytptr) = ior(ishft(pytab(pytptr),14),l2)
         write (*,'(1x,a,z8)') 'answer should be 0x70014005, is=',pytab(1)
         end

 should produce the following output:

 answer should be 0x70014005, is=70014005

    However, it actually prints the following:

 answer should be 0x70014005, is=00014005

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    You may work around this problem by compiling with -Od or -Odlt
 (loop optimization but no common subexpression elimination).


 129. NEAR Attribute in COMMON

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900140 bcp1756 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23266

    The following program is broken into two files and compiled
 separately:

            implicit INTEGER*2 (a-z)
            common /ccc/ ia,ib,ic
            ix = 0
            ia = 5
            ib = 7
            write (*,100) 'default data segment=',locfar(ix)
    100     format (1x,a,z8)
            write (*,100) 'main program COMMON /ccc/ segment=',
         +  locfar(ia)
            call junk
            write (*,*) ia,' plus ',ib,' should be 12, is=',ic
            end
            subroutine junk
            implicit INTEGER*2 (a-z)
            common /ccc[near]/ia,ib,ic
            write (*,100) 'subroutine COMMON /ccc/ segment=',
         +  locfar(ia)
    100     format (1x,a,z8)
            ic = ia+ib
            end

 It should produce the following output:

    default data segment=8CD10842
    main program COMMON /ccc/ segment=8CD10000
    subroutine COMMON /ccc/ segment=8CD10000
              5 plus           7 should be 12, is=         12

 However, it actually prints the following:

    default data segment=8CD10842
    main program COMMON /ccc/ segment=8CD00000
    subroutine COMMON /ccc/ segment=8CD10000
              5 plus           7 should be 12, is=          0

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The following are two workarounds:

    1. Specify all the occurrences of the COMMON block to be NEAR.
    2. Specify the first occurrence of the COMMON block in each source
 file to be NEAR.


 130. C and ALIAS Attributes

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900154 bcp1779 buglist4.00
 Last Modified: 11-OCT-1988    ArticleIdent: Q23267

 Question:

 The following program should enable you to link to the C routine named
 csub.c, but you will receive an "unresolved external" error when you
 LINK:

        interface to integer*2 function isub[alias:'CSUB',c] (y)
        integer*2 y
        end

        integer*2 isub
        i = isub(j)
        end

 Response:

 When used together, the resulting name should be lowercase and should
 be preceded by an underscore. Currently, whatever is specified in the
 ALIAS is EXACTLY what you will find in the generated code. The only
 workaround is to modify the alias by inserting the underscore
 character before the name, and changing the name to lowercase letters.


 131. Bad "Type" Information in .LST File

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900149 bcp1771 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23269

    The problem program is as follows:

         logical*1 l
         l = .true.
         end

    This produces the following source listing file, (heading omitted
 on purpose):

         1         logical*1 l
         2         l = .true.
         3         end

 main  Local Symbols

 Name                      Class   Type              Size   Offset

 L . . . . . . . . . . . . local   LOGICAL*4            1    0000

 Global Symbols

 Name                      Class   Type              Size   Offset

 main. . . . . . . . . . . FSUBRT  ***                ***    0000

 Code size = 0018 (24)
 Data size = 0000 (0)
 Bss size  = 0001 (1)

 No errors detected

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 132. Logical*1 Versus Equivalence

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23277

    The following program:

        logical*1 newflag(5),flag1,flag2,flag3,flag4,flag5
        common /findex/ flag1,flag2,flag3,flag4,flag5
        equivalence (newflag,flag1)
        flag3 = .true.
        if (flag3) write (*,*) 'flag3 is true'
        if (newflag(3)) write (*,*) 'newflag(3) is true'
        write (*,*) newflag(1),flag1
        write (*,*) newflag(2),flag2
        write (*,*) newflag(3),flag3
        write (*,*) newflag(4),flag4
        write (*,*) newflag(5),flag5
        flag1 = .true.
        if (flag1) write (*,*) 'flag1 is true'
        if (newflag(1)) write (*,*) 'newflag(1) is true'
        write (*,*) newflag(1),flag1
        write (*,*) newflag(2),flag2
        write (*,*) newflag(3),flag3
        write (*,*) newflag(4),flag4
        write (*,*) newflag(5),flag5
        end
        block data
        logical*1 newflag(5),flag1,flag2,flag3,flag4,flag5
        common /findex/ flag1,flag2,flag3,flag4,flag5
        data flag1,flag2,flag3,flag4,flag5
      +    /.false.,.false.,.false.,.false.,.false./
        end

    should generate the following output:

    flag3 is true
    newflag(3) is true
    F F
    F F
    T T
    F F
    F F
    flag1 is true
    newflag(1) is true
    T T
    F F
    T T
    F F
    F F

    however, the following output is printed:

    flag3 is true
    F F
    F F
    F T
    F F
    T F
    flag1 is true
    newflag(1) is true
    T T
    F F
    F T
    F F
    T F

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    This problem seems only to affect equivalence between LOGICAL*1
 items. The easiest way to work around this problem is to use LOGICAL*2
 or LOGICAL*4.


 133. NINT Functions in Expressions

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900152 bcp1775 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23279

    The following program:

    call sub (x,y,z)
    write (*,*) '2000-240 should be 1760, is=',nint(x)-nint(y*z)
    end
    subroutine sub (x,y,z)
    x = 2000.
    y = .12
    z = 2000.
    end

    should produce the following message:

    "2000-240 should be 1760, is=1760".

    however, it prints as follows:

    "2000-240 should be 1760, is=-31067048"?

    This is a confirmed problem with Version 4.00a.
    This problem was corrected in Version 4.01.

    After computing NINT(Y*Z), the result of 240 is stored temporarily
 in the BX and CX registers. Unfortunately, the NINT function uses BX
 and CX. Therefore, after the calculation of NINT(X), the value that
 would have been subtracted from NINT(X) has been destroyed.
    You should be able to work around this problem by storing NINT(X)
 and NINT(Y*Z) in temporary integer variables and writing the temporary
 variables.


 134. Compile Time Error F1035 with $DEBUG

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900139 bcp1753 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 27-MAY-1988    ArticleIdent: Q23263

    The following program will produce error message F1035, "Expression
 is too complex":

 $DEBUG
         COMMON Y
       DIMENSION Y(1000),L(25)
    75 CALL DATAI(Y(L(1)),Y(L(2)),Y(L(3)),Y(L(4)),Y(L(5)),Y(L(6)),Y(L(7))
      1,Y(L(8)),Y(L(9)),Y(L(15)),Y(L(16)),Y(L(17)),Y(L(19)),Y(L(23)),Y(L(
      224)),Y(L(25)),AWELL,
      &  Y(LCSS),Y(LHSS),
      &   I0,J0,K0,IK,JK,K5,IP,JP,IQ,JQ,KQ,1,
      &   DUM1,IDUM1,ADUM1,IDUM2,IDUM3,DUM,IDUM4)
        END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    For this error to occur, the $DEBUG must be used and the array Y
 must not be in DGROUP (the default data segment). In this example, the
 error disappears if just the COMMON statement is removed, unless the
 size of Y is increased to the point at which the array is removed from
 the default data segment for exceeding the "data threshold" defined by
 the -Gt compiler option. (If omitted, this option is preset to 32767
 bytes.) Probably the easiest solution is to compile without the $DEBUG
 option.


 135. Run-Time Error M6103 with -FPa

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900146 bcp1765 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23276

    The following program:

        x = 1234.5678
        call strngf (x,4,0)
        end
        subroutine strngf (x,np,ijust)
        character is
        real pwr10(7), pwr210(6)
        data pwr10 /1.e6,1.e5,1.e4,1.e3,1.e2,1.e1,1.e0/
        data pwr210 /1.e-1,1.e-2,1.e-3,1.e-4,1.e-5,1.e-6/
        x2 = abs(x)+(pwr210(np+1)*5.)
        rem = amod(x2,1.)
        write (*,'(a,\)') ' answer should be 5677, is='
        do 20 i=1,np
          n3 = amod((rem/pwr210(i)),10.)
          call bout (n3+48)
 20     continue
        write (*,*)
        end
        subroutine bout (ch)
        character ch
        write (*,'(a,\)') ch
        end

 should produce the output "answer should be 5677, is=5678". However,
 it prints the following:

    answer should be 5677, is=5
    run-time error M6103: MATH
    - floating-point error: divide by 0

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01. The workaround is
 to compile with either -Od or -Odct.


 136. Piping Not Supported When Using Pause Command in FORTRAN 4.x

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q28084

    Using FORTRAN Version 3.x and the Pause command, I was able to use
 DOS piping functions. However, when I recompiled under FORTRAN 4.x and
 ran the program piping in its input, I got a run-time error saying
 that the end-of-file was encountered when I hit the pause statement.

 Response:
    The Pause function is operationally different between FORTRAN 3.x
 and 4.x. FORTRAN 3.x allowed piping, but Pause command piping is no
 longer supported using this command in FORTRAN 4.x because of new
 functionality added to FORTRAN 4.x.


 137. How To Access the Comm Port or Printer

 Product Version(s): 4.X  5.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-OCT-1989    ArticleIdent: Q28134

    To access the comm port or printer, simply open the device in the
 following way:

        OPEN(UNIT=10,FILE='COM1',STATUS='OLD')

     or

        OPEN(UNIT=9,FILE='LPT1',STATUS='OLD')

    One may then write to or read from them as to any other unit.
 However, they must be treated as sequential files (which is the
 default). See page 105 of the FORTRAN 4.X Language reference or
 page 63 of the FORTRAN 5.0 Reference for a description of sequential
 file access.


 138. CHARACTER Array Optimization

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900141 bcp1758 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23342

    The following program:

            character*30 strs(10),temp
            strs(1) = 'name1'
            strs(2) = 'name2'
            strs(3) = 'name3'
            strs(4) = 'name4'
            strs(5) = 'name5'
            do 10 i =1,5
            write (*,*) 'name is '//strs(i)
    10      continue
            end

 should produce the following output:

    name is name1
    name is name2
    name is name3
    name is name4
    name is name5

 however, it actually prints the following:

    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &

    This problem was corrected in Version 4.01.

    This problem can be worked around either by compiling with option
 -Odclt or by setting a CHARACTER variable equal to the CHARACTER
 expression and using the variable (rather than the expression) in the
 WRITE statement.


 139. Spurious F2408 Errors

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900142 bcp1748 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23343

    The following program:

         INTEGER x(10), y(10)
         DATA x(1:10) /1/
         DATA y/10*0/
         END

 should produce the following errors when compiled:

    error F2513: X : not a variable
    error F2537: X : array subscripts missing

    however, it actually prints the following:

     error F2513: X : not a variable
     error F2537: X : array subscripts missing
     error F2408: X : DATA : too few constants to initialize item
     error F2408: Y : DATA : too few constants to initialize item

    This problem was corrected in Version 4.01.
    The F2408 errors were occurring as a result of two previous errors.
 This is called a "cascade" error.


 140. Code Generation Error

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900136 bcp1745 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23344

    The following program:

         complex xx(4)
         common /elem/p(75,8)
         a = p(j,5)+1.
         b = w*p(j,4)*p(j,3)*1.e-12
         xx(2) = p(j,3)/cmplx(a,b)
         end

 generates the following compilation error:

    a:0056.for(5) : error F2124: CODE GENERATION ERROR
                    Contact Microsoft Technical Support

    This problem was corrected in Version 4.01.
    You can work around this problem by compiling with either the -Od
 or the -Odl option.


 141. Compiler Hung by Real Subscript

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900128 bcp1706 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23345

    The following program will cause the compiler to hang:

         dimension int(100)
         common pjint(100)
         x = 1.0
         pjint(x) = int(min0(x,21))
         end

    This problem was corrected in Version 4.01.
    This program relies on two features that are not part of the ANSI
 X3.9-1978 FORTRAN standard: the use of a REAL variable as an array
 index, and the use of a REAL variable as an argument to an intrinsic
 function that is expecting only INTEGER arguments. If the $STRICT
 metacommand or -4Ys switch had been used, both uses would have been
 flagged as errors. Nevertheless, the program should not hang the
 compiler.
    The following is a workaround:

    1. Calculate the subscript expression for the array INT.
    2. Store it in a temporary integer variable.
    3. Use the temporary variable to index the array.


 142. Error F2350

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q23346

 Problem:

 Consider the following program:

        program foo
        call main
        end

        subroutine main
        end

 The Version 4.00 compiler generates error message "F2530: MAIN :
 symbol class illegal here". The Version 3.31 compiler compiles this
 without error. Is this error message consistent with the standard?

 Response:

 This is consistent with the ANSI X3.9-1978 FORTRAN standard (see Page
 14-1). Remember that the entry point "_main" is always defined for the
 main program. The language reference manual discusses this in detail
 in Section 3.8 on Page 62, explaining where "main" can and cannot be
 used.


 143. Premature EOF on Redirected READs

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900103 bcp1686 buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q23349

    If the following program is run with the READ redirected from the
 console to a file that contains one or more CTRL-Zs at the end, you
 may receive a premature (or perhaps an immediate) end-of-file message:

          CHARACTER CHR
    10    CONTINUE
          READ(*,'(A)') CHR
          WRITE(*,'(1X,A)') CHR
          GOTO 10
          END

    The behavior may differ, depending on the length of the redirected
 file. The problem is occurring because the run time is detecting
 end-of-file when a BUFFER is read that contains a CTRL-Z, rather than
 when the CTRL-Z itself is read.
    This problem was corrected in Version 4.01.


 144. Internal READ from Substring

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900104 bcp1689 buglist4.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q23350

 Problem:

 The following program

        character str*10
        str = '1234567890'
        call sub1 (str)
        end
        subroutine sub1(str)
        character str*(*)
        read (str(2:6),'(i5)') inum
        write (*,*) 'inum should be 23456, is=<',inum,'>'
        end

 should produce the following output:

 inum should be 23456, is=<      23456>

 However, it actually prints the following:

 inum should be 23456, is=<          0>

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.01.

 This problem is caused by an internal WRITE to a substring of a
 CHARACTER*(*) parameter. The problem can be worked around in the
 following two ways:

 1. In the subroutine, declare STR to be of a fixed size instead of
    CHARACTER*(*).

 2. In the internal READ, use STR instead of the substring of STR.

 This was provided as an extra case for the developers.


 145. Internal Compiler Error: pgo2.c, Line 229

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900095 bcp1672 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23351

 Problem:
    A program containing several ENTRY points, most of which have
 alternate return arguments, is giving the assertion error "Pgo2.c,
 line 229" with only the default compiler switches.

 Response:
    This is a known problem in Version 4.00a.
    This problem was corrected in Version 4.01.
    The program has been reduced from 1100+ to 423 lines. The assertion
 seems to occur only in conjunction with the "function too big for
 post-optimizer" message, so most likely that will occur only when
 memory size is limited (the test was run with 416K available).


 146. "Symbol Undefined" and Length of FORTRAN Variable Name

 Product Version(s): 4.X
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q23352

 Problem:
    I am debugging a FORTRAN program and am finding that I
 cannot view any symbols with a name longer than six
 characters. For instance, using "? longvarname" produces
 the message "Symbol undefined" in CodeView.

 Response:
    Under Microsoft FORTRAN Version 4.0, only the first six
 characters of a symbol name are recognized by default. If
 you want the full name to be valid, you must use the
 $NOTRUNCATE metacommand or compile with the /4Nt switch.
 Without the metacommand or the switch, CodeView considers
 the symbol "longvarname" to be "longva". This is why you
 could not display the expression. (Had you entered
 "?longva", CodeView would have displayed the symbol
 correctly.)


 147. Internal Compiler Error: regMD.c 1.74, Line 1495

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900158 bcp1788 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23356

 Problem:
    The following program:

       COMMON/SIG/R(100,24)
       REAL*8    R,RA1(24)
       DO 4301 K=1,24
  4301 RA1(K)= R(KA, K)
  4310 K=K+KO
       IF(K .NE. KZ) GOTO 4310
       RAD = R(KR,2)
       END

 produces the following error when compiled with the default options:

 bcp1788.for(7) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)regMD.c:1.74', line 1495)
                 Contact Microsoft Technical Support

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.
    You can correct the problem by compiling with the -Odclt
 switch. The array must be in COMMON for the error to
 occur.


 148. READ from Internal File Substring

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900143 bcp1760 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23360

    The following program:

    $debug
            character*20 strc
            data itmp1,itmp2,strc /5,3,'1234567890'/
            read (strc(itmp1:itmp1+itmp2),'(f20.0)') temp
            write (*,*) 'temp should be 5678.0 and is=',temp
            end

 should produce the following output:

    temp should be 5678.0 and is=    5678.000000

 however, it actually prints the following:

    temp should be 5678.0 and is=   0.000000E+00

    This problem was corrected in Version 4.01.
    Two workarounds are as follows:

    1. Compile without $DEBUG.
    2. Store the integer expression in a variable and use it in the
 substring.


 149. FORTRAN Version 4.10 DOS, OS/2 Requirements

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q28335

 Question:

 Page 1 of the Update (Update-1), of the FORTRAN Version 4.10 insert
 for "Microsoft FORTRAN Optimizing Compiler User's Guide" states that
 DOS Version 3.00 (or later) is required. However, the product box
 states that DOS Version 2.10 (or later) is required. Which is correct?

 Response:

 The product box is correct. The Update should state that Microsoft
 FORTRAN Version 4.10 requires DOS Version 2.10 (or later).


 150. Block Data Names in Listing

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900155 bcp1780 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23373

    Garbled characters are appearing in a list file where, normally,
 the name of the routine is printed.

    There is no workaround for this problem. The following program
 reproduces the problem:

   Line#  Source Line   Microsoft FORTRAN Optimizing Compiler Version 4.00

       1        block data
       2        common /any/x(5)
       3        data x/1.,2.,3.,4.,5./
       4        end
       5        block data foo
       6        common /bar/ a
       7        data a /.5/
       8        end

 [garbage]  Local Symbols

 Name                      Class   Type              Size   Offset

 X . . . . . . . . . . . . ANY     REAL*4              20    0000
 A . . . . . . . . . . . . BAR     REAL*4               4    0000

 Global Symbols

 Name                      Class   Type              Size   Offset

 ANY . . . . . . . . . . . common  CHAR*20             20    0000
 BAR . . . . . . . . . . . common  CHAR*4               4    0000

 Code size = 0000 (0)
 Data size = 0000 (0)
 Bss size  = 0000 (0)

 No errors detected


 151. Internal Compiler Error: regMD.c 1.74, Line 285

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900159 bcp1794 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23364

 Problem:
    The following program:

         character*1 dirinfo(30,10)
         integer*4 filesize
         filesize = ichar(dirinfo(29,i))*65536 +
      +             ichar(dirinfo(28,i))*256+
      +             ichar(dirinfo(27,i))
         end

 produces the following compilation error if compiled with option -4I2:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)regMD.c:1.74', line 285)
      Contact Microsoft Technical Support

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.
    Aside from the fact that this program will cause an assertion
 error, it will, even after the assertion error is corrected, produce
 an incorrect answer. The right-hand side of the expression is being
 evaluated in INTEGER*2 arithmetic; the conversion to the type of the
 destination variable (INTEGER*4) is done only after the evaluation is
 complete. Were this program able to run, it would produce a runtime
 error F6099 : "INTEGER overflow" if compiled with both -4I2 and -4Yb
 options. There are two ways to work around the problem, as follows:

    1. Do not compile with the -4I2 option.
    2. Assign the three ICHAR expressions to temporary INTEGER*4
 variables and use them to calculate FILESIZE.


 152. Edit Descriptor File Clash

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900102 bcp1684 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23348

    The following program:

       REAL*8 D1,D2,GV
       INTEGER K1
       CHARACTER*4 IDNO(2),IDNM(4)
       OPEN(11,FILE='bcp1684a.DAT',STATUS='OLD')
       DO 1 J=1,100
       READ(11,1000,END=15) IDNO,D1,D2,GV,IDNM,K1
       WRITE(*,1000) IDNO,D1,D2,GV,IDNM,K1
     1 CONTINUE
    15   continue
         close(11)
         open(12,file='bcp1684b.dat')
       DO 2 J=1,100
       READ(12,1000,END=25,IOSTAT=IOCHCK) IDNO,D1,D2,GV,IDNM,K1
       IF(IOCHCK.NE.0) WRITE(*,1001)IOCHCK
       WRITE(*,1000) IDNO,D1,D2,GV,IDNM,K1
     2 CONTINUE
  1000 FORMAT(2X,A4,A3,11X,2F10.5,1X,F9.2,4A4,I4)
  1001 FORMAT(2X,'***IOSTAT= ',I7)
    25 STOP
       END

 should produce the following output:

   926860             49.35067-124.44583 980979.89QUALICUM           1
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
   926860             49.35067-124.44583 980979.89QUALICUM           1
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
 Stop - Program terminated.

 however, it actually prints the following:

   926860             49.35067-124.44583 980979.89QUALICUM           1
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
  ***IOSTAT=    6103
  26860                4.93507  24.44584 980970.51TAYLOR ARM        20
  ICUM                  .00000    .00000       .00                   0
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
 Stop - Program terminated.

    By the time the EOF is encountered on the first file, the run time
 has already "seen" a 2X edit descriptor. The 2X edit descriptor by
 itself does nothing until a repeatable edit descriptor is seen; it is
 merely "remembered". Unfortunately, it remembers even after the close
 of the file.
    This situation should arise only when EOF is encountered at the
 same time when a non-repeatable edit descriptor has been READ without
 having been followed by a repeatable. You can solve this problem by
 replacing the 2X descriptor with an I2 that READs into a dummy
 variable.


 153. Internal Compiler Error: regMD.c 1.79, Line 608

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q28340

 The code sample below will generate the following internal compiler
 error:

    REGMD.FOR
    REGMD.FOR(6) : fatal error F1001: Internal Compiler Error
                    (compiler file '@(#)regMD.c:1.79', line 608)
                    Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.

 You can work around the error by breaking up line six with a temporary
 variable, as in the following code:

       SUBROUTINE FOO
       IMPLICIT INTEGER*2 (A-Z)
       INTEGER*4 LA
       INTEGER*2 PUROUT,MAX,LOST

       TMP = MAX*PUROUT*3
       LA = LOST+TMP
       RETURN
       END

 The following is the code:

       SUBROUTINE FOO
       IMPLICIT INTEGER*2 (A-Z)
       INTEGER*4 LA
       INTEGER*2 PUROUT,MAX,LOST

       LA = LOST+MAX*PUROUT*3
       RETURN
       END


 154. Incorrect Error F2352

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900157 bcp1786
 Last Modified: 20-OCT-1988    ArticleIdent: Q23412

 Question:

 Why does the following program produce the following compilation
 errors?

        common /xx/ w(10)
        common y(5)
        foo(y,w) = y*w
        end

        error F2352: Y : formal argument not local variable
        error F2352: W : formal argument not local variable

 Response:

 This behavior is a correct response; the program is syntactically
 incorrect. According to the ANSI X3.9-1978 FORTRAN standard, you can
 reuse the statement function's dummy arguments as variable names and
 COMMON block names in the same program, but you cannot use them as
 array names (ANSI X3.9-1978 FORTRAN standard, Page 15-4, lines 39-44).


 155. Internal Compiler Error: sortnode.c, Line 154

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900109 bcp1697 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23450

    The program below gives the assertion error message "sortnode.c,
 line 154":

         CHARACTER A,B,C,D,E,F,G
         CHARACTER BIGLIN*60, LSTHAF*30
         A = 'A'
         B = 'B'
         C = 'C'
         D = 'D'
         E = 'E'
         F = 'F'
         G = 'G'
         LSTHAF = '123456789012345678901234567890'
         BIGLIN = ' '//A//'   '//B//'   '//C//
      +           '   '//D//'   '//E//'   '//F//'   '//
      +           G//LSTHAF
         WRITE (*,*) 'BIGLIN=<',BIGLIN,'>'
         END

    The workaround for this problem is breaking up the character
 expression into smaller pieces.


 156. Null Pointer Assignment Error in PAS2.EXE

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.31
 Last Modified:  7-NOV-1988    ArticleIdent: Q23483

 Problem:

 PAS2.EXE of the compiler seems to run properly, but when it finishes
 it prints out the error message "Null Pointer Assignment."

 Response:

 This behavior indicates that there was an error during the
 execution of PAS2.EXE.

 Microsoft has confirmed this to be a problem related to the size of
 the compiler's stack in Version 3.31. We are researching this problem
 and will post new information as it becomes available.

 You should reduce the stack sizes of both FOR1.EXE and PAS2.EXE
 from 40K down to 20K using the EXEMOD.EXE utility (which is included
 with the compiler), using the following lines:

    exemod for1 /stack 5000
    exemod pas2 /stack 5000

 For more information about the EXEMOD.EXE utility, refer to the user's
 guide, Appendix A.10.1, Page 159.


 157. Use and Misuse of Format(X,\)

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-MAY-1988    ArticleIdent: Q23434

 Question:
    I am trying to use the "\" after an "X" in a FORMAT statement. I
 tried the following using the current Version 4.00:

    write(*,10)
    10  format(1x,'Enter a number :',10x,\)

    The 10x still is being ignored in Version 4.00. Are there any plans
 to change this, or will this be a feature?

 Response:
    It is assumed by some that the X edit descriptor produces some
 output. However, it does not. It positions a pointer that says where
 the next character is to be (in this case) written.
    For more information on this, please see lines 4-10 on Page 13-6 of
 the "ANSI X3.9-1978 FORTRAN standard document."
    Because nothing further actually is written on this line, the
 current behavior is correct.
    If you wish to hang the cursor following the prompt, you can do so
 by inserting the required number of blanks as the last item in the
 prompt; within the CHARACTER constant.


 158. Scratch File on Units 5 and 6

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 30-JAN-1989    ArticleIdent: Q23443

 Question:

 I am having trouble with the following program:

 program t
 open(5,status='scratch')
 write(5,*) 'help'
 end

 This program writes "help" to the screen. Is this correct
 behavior?

 Response:

 Version 4.00 does not allow any of the pre-connected units (0, 5, and
 6) to be used as scratch files. Because there are 65531 other unit
 numbers that could be used as scratch file units, this should not be
 an inconvenience.


 159. F6301 Error and Opening Scratch Files with Names

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | docerr FORTRAN 77
 Last Modified: 26-JUL-1990    ArticleIdent: Q23465

 Page 253 of the "Microsoft FORTRAN Optimizing Compiler Language
 Reference" for versions 4.00, 4.01, and 4.10 and Page 206 of the
 "Microsoft FORTRAN Reference" for version 5.00 contain a documentation
 error that states a named file may be opened with STATUS='SCRATCH'.

 This is contrary to Page 12-19, lines 18 and 19, of the "American
 National Standard (ANSI) Programming Language FORTRAN" guide, which
 state "SCRATCH must not be specified with a named file."

 The compiler correctly generates the following run-time error:

    F6301 : SCRATCH illegal for named file

 The following OPEN statement generates the run-time error "F6301:
 SCRATCH illegal for named file":

    OPEN(6,FILE='JUNK',STATUS='SCRATCH')

 The "American National Standard (ANSI) Programming Language FORTRAN"
 guide states that "SCRATCH must not be specified with a named file."
 It may seem redundant to have a STATUS "SCRATCH" when the following
 two statements perform the same function:

    OPEN (1)
    OPEN (1,STATUS='SCRATCH')

 However, specifying"SCRATCH" for a named file provides documentation
 that the file will be deleted when the program finishes.


 160. BACKSPACE Versus Blocksize

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | bcp1850 buglist4.00
 Last Modified: 26-MAY-1988    ArticleIdent: Q23538

 Problem:
    The following program:

         dimension x(3000),y(3000),z(3000)
         ibl = 32256
         open (1,file='temp.dat')
         do 100 i=1,3000
           x(i) = i+10000
 100     continue
         write (1,'(3000f6.0)') x
         do 200 i=1,3000
           x(i) = i+20000
 200     continue
         write (1,'(3000f6.0)') x
         close (1)
         open (1,file='temp.dat',blocksize=ibl)
         read (1,'(3000f6.0)') y
         backspace 1
         read (1,'(3000f6.0)') y
         read (1,'(3000f6.0)') z
         backspace 1
         read (1,'(3000f6.0)') z
         write (*,'(1x,a,10f7.0)') 'y=',(y(i),i=1,5),(y(i),i=2996,3000)
         write (*,'(1x,a,10f7.0)') 'z=',(z(i),i=1,5),(z(i),i=2996,3000)
         close (1,status='delete')
         end

 should produce the following output:

 y= 10001. 10002. 10003. 10004. 10005. 12996. 12997. 12998. 12999. 13000.
 z= 20001. 20002. 20003. 20004. 20005. 22996. 22997. 22998. 22999. 23000.

    However, it actually prints the following:

    run-time error F6501: BACKSPACE(temp.dat)
    - end of file encountered

 Response:
    This is a known problem in Version 4.00.
    There is an error in the run time that causes incorrect positioning
 when a BACKSPACE is performed on a file whose BLOCKSIZE is greater
 than 16384 bytes (e.g. 16896 to 32256 bytes). Since the problem will
 only occur when a BLOCKSIZE greater than 16384 is used, those programs
 that also use BACKSPACE should use a BLOCKSIZE of 512 to 16384 bytes.


 161. Subtracting a Complex*8 from a Real Constant

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q23581

 Problem:
    The following program should produce the output
 "(5.000000E-01,-5.000000E-01)"; however, the program instead produces
 the output "(5.000000E-01,5.000000E-01)":

    COMPLEX*8 A,B
       A=(0.5,0.5)
       B=1.0 - A
       WRITE(*,*)B

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in FORTRAN Version 4.01.
    If A and B are COMPLEX*16, the calculation is correct.


 162. Internal Compiler Error: regMD.c 1.74, Line 285

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23587

 Problem:
    The following program gives the assertion error "regMD.c:1.74, line
 285" when it is compiled with both -FPa and -Od:

    SUBROUTINE VLNGET(XMIN,XMAX)
    DIMENSION XMIN(1),XMAX(1)
    NLI = NINT(XMAX(II)) - NINT(XMIN(II)) + 1
    END

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler.
 The problem was corrected in Version 4.01.
    The workaround is to avoid the -FPa and -Od option combination.


 163. F2124 - Code Generation Error with Complex Numbers

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist5.0
 Last Modified: 14-JUL-1989    ArticleIdent: Q23586

    The compiler generates error F2124, "code generation error" for the
 following code:

    COMPLEX A,B,C
    D=REAL(CONJG(C)*A*B)
    END

    This is a known problem in Version 4.00.
    If you add the complex variable temp and simplify the expression,
 as in the following example, then the error is corrected:

    temp=conjg(c)
    d=real(temp*a*b)

    This is similar to an earlier assertion error (mactab.c:1.30,
 line 647) caused by the following program:

    complex*16 z1,z2,z3
    z1=z1*dconjg(z2) *z3
    end

    This problem had basically the same workaround, but concerned only
 COMPLEX*16. Changing the optimization has no effect.


 164. Internal Compiler Error: regMD.c 1.74, Line 1267

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified: 26-MAY-1988    ArticleIdent: Q23588

 Problem:
    The following code generates the regMD.c:1.74, line 1267 error
 message:

    SUBROUTINE BIAS(IAE)
    CHARACTER*1 BUF6(512)
    DIMENSION IBIAS(64,2)
    BUF6(1) = CHAR(IBIAS(L,IAE))
    END

 Response:
    This is a known problem in Version 4.00.
    If you assign IAE to a local variable, the error is corrected.
    The pattern here seems to be a two-dimensional array reference
 inside a function (a one-dimensional pattern will not work), where one
 of the array dimensions is a local variable and the other is an
 argument.


 165. Compile Time Error F2215

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q23582

 Problem:
    The following program generates an incorrect F2215 error
 ("character lengths differ"):

         SUBROUTINE PAGE
         IMPLICIT CHARACTER*1 (A-H,J-Z)
         ENTRY PAGOUT
         END

 Response:
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. The problem was corrected in Version 4.01.
    FORTRAN Version 4.00 issues an error that is only appropriate for a
 function since subroutines have no associated type.
    The workaround is to avoid using the IMPLICIT CHARACTER statement,
 using explicit type statements instead.


 166. Problem with Expressions as Arguments to WRITE

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23584

    The following program will produce a code generation error:

            real bs(3,3),br(3,3),ps(3,3),psp(3),bsp(3),bso(3),rp(3),ro(3)
               WRITE(6,350)
         +  aguse(I,J)/customers(J),
         x  agg(bs(I,J),1.0)+AGG(BR(I,J),1.0),
         +  AGG(BR(I,J)-PS(I,J),1.0),
         X  AGG(BS(I,J)+BR(I,J)-PS(I,J),1.0)
    350    FORMAT(3(1X,A22,F9.1,7F8.2,3X,F8.2))
            end

    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. The problem was corrected in Version 4.01.
    The workaround is to store the expressions in temporary variables
 and WRITE those temporary variables.


 167. Loop Optimization Problems

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23585

    If the following code is compiled with /Odclt or the default, the
 program does not work properly:

    $STORAGE:2
           DO 100 I=1,2
           J=0
    50     J=J+1
           IF(J .GT. 2) GOTO 100
           WRITE(*,*) 'I,J=',I,J
           GOTO 50
    100    CONTINUE
           END

    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    If you remove $STORAGE:2, if you compile with /Od (disables
 optimization), or /Odct, the correct code is generated.


 168. Error F2317 - Using Equivalence

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23583

    Placing real numbers in a common block with an array of CHARACTER*1
 generates the message "error F2317" and the following example code:

    REAL*8 EMPEPR, EMPSPR
    CHARACTER*1 EMPBUF(2091)
    COMMON /TEST/ EMPEPR, EMPSPR
    EQUIVALENCE(EMPEPR,EMPBUF(2:9))
    EQUIVALENCE(EMPSPR,EMPBUF(10:17))

    There are two problems in the code. They are as follows:

    1. Because EMPBUF is a CHARACTER*1 array, you cannot expect
 anything substantial when attempting to extract any substring (except,
 of course, (1:1)) from a single character variable or array element.
 In this case, the compiler apparently ignores the substring reference.
 This means that both variables in the common block are EQUIVALENCEd to
 the same location, EMPBUF(1). The solution is to change the type of
 EMPBUF to CHARACTER*2091.
    2. The other problem arises if the first is solved. The compiler
 must align numeric variables on even-byte boundaries and the
 EQUIVALENCE attempts to force it to an odd location. Changing EMPBUF
 to CHARACTER*2091 and the substrings to (1:8) and (9:16) allows the
 program to compile without error.


 169. Internal Compiler Error: p2symtab.c 1.84, Line 918

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q23636

    The following program generates the assertion error
 "p2symtab.c:1.84, line 918":

      program basmap
      character*16 basmap(3)
      data basmap/ '\EXCLAND.pix\   ','\INCLAND.pix\    ',
    1  '\WATLAND.pix\   '/
      call gwrite(basmap(mask))

    The compiler is not producing an error when the program name is
 used as an array. This is a violation of the standard; "basmap" cannot
 be a name of a subroutine, function, or COMMON block in the same
 source file. Furthermore, it cannot be the same as any local name in
 the main program (see Ref. ANSI X3.9-1978, Page 14-1).
    The workaround is to change the program name or to delete the
 program statement.


 170. Running Out of Heap Size

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-MAR-1988    ArticleIdent: Q23691

 Problem:
    FORTRAN Version 3.31 is generating the error "? error :
 out of memory" at compile time.

 Response:
    Version 3.31's compiler stack size has increased to 40K,
 which is too large. The compiler is running out of heap
 size. For Version 3.31, the following will get around this
 problem:

    1. Decrease the size of the compiler stack for F1.EXE to
 20K or 30K using EXEMOD.
    2. The program may be too large; break it down into
 several modules.


 171. Determining Size of Code and Data

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-DEC-1987    ArticleIdent: Q23683

 Question:
    How do I determine the size of the code and data
 segments in each module?

 Response:
    If you specify the /Fs option to generate a listing
 (.LST file), the sizes of the code and data appear at the
 bottom.


 172. Namelist Support in FORTRAN

 Product Version(s): 3.x 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS | 4.10 5.00
 Flags: ENDUSER |
 Last Modified: 18-OCT-1989    ArticleIdent: Q23696

 Question:
    Does FORTRAN Version 4.10 (and prior versions) support namelist?

 Response:
    No; namelist is an I/O statement that is an extension beyond the
 FORTRAN-77 Standard.

 Note: NAMELIST support was added with FORTRAN 5.0.


 173. How to Get Date and Time from FORTRAN

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  6-JAN-1989    ArticleIdent: Q23682

 Problem:
    What do I need to do in order to get FORTRAN to tell me
 the system date and time?

 Response:
    In Version 4.00, you may use the procedures GETTIM and
 GETDAT to get the time and the date, respectively. In
 FORTRAN Versions 3.3 and 3.2, use DATTIM.FOR as an example
 of how to get the date and time via a Pascal interface.


 174. Unresolved External __FHceadds in FORTRAN 4.10

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 25-FEB-1991    ArticleIdent: Q28436

 When I compile with the /Od option and link the following program with
 FORTRAN Version 4.10, I get the following error:

     Link : error 2029: Unresolved externals:  __FHceadds

 The program is as follows:

        DIMENSION D(8192)
        COMPLEX Y
 120    D(NMX-N)=(RN/Y)-(1./(D(NMX-N+1)+RN/Y))
        END

 The program will run, but it stops with a Floating Point Error.

 Response:

 The main problem is the mixed data types in the expression. If the
 COMPLEX variable Y is explicitly converted to REAL using the FLOAT
 type conversion intrinsic function then the program compiles and
 links.

 Another aspect of this problem is the size of the array. If it is small
 enough (less than 32K) to stay in dgroup, then it compiles properly.

 A less useful workaround is to compile with /Odclt, or to decrease
 the size of the array. If you are trying to use CodeView, compile with the
 switches /Zi /Odclt.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.


 175. Creating One Megabyte of Code and Data

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-APR-1988    ArticleIdent: Q23694

 Question:
    The product specifications state that I can create one megabyte of
 code and data. How can I accomplish this?

 Response:
    Because DOS limits the size of code and data segments to a maximum
 of 640K, you must use the Overlay Linker to overlay code. It would
 also save memory to read data from files rather than to store it all
 in RAM.


 176. Internal Compiler Error: ctypes.c 1.80, Line 1594

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23638

 Problem:
    An internal compiler error "compiler file '@(#)ctypes.c:1.80', line
 1594" is generated by the following file:

 $debug
         subroutine test
         character*20    c
         i =1
         j=ichar(c(i:i))
         return
         end

    However, if you remove $debug, the program compiles without errors.

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler.
 The problem was corrected in Version 4.01.


 177. Internal Compiler Error: regMD.c 1.74, Line 1267

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23632

 Problem:
    The following code produces the regMD.c:1.74, line 1267 error:

    CHARACTER MATRIX(256,1)
    MATRIX(I,J) = ' '
    END

 Response:
    This is a known problem in Version 4.00.
    This is an extremely specific problem. The following conditions all
 must be true for failure:

    1. It must be a Character array.
    2. It must be two-dimensional (more than two dimensions were not
 examined).
    3. The first dimension must be exactly 256.

    This example does seem different than the previous code which
 produced this assertion: in this case, both dimensions are local vars.
 The previous code, in which the array reference consisted of a local
 var and a parameter, was as follows:

    SUBROUTINE BIAS(IAE)
    CHARACTER*1 BUF6(512)
    DIMENSION IBIAS(64,2)
    BUF6(1) = CHAR(IBIAS(L,IAE))
    END


 178. "File Access Error in File PASIBF.OID" Error 1004

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-DEC-1987    ArticleIdent: Q23695

 Question:
    Why does pass three of the FORTRAN compiler generate the
 error message "File access error in file PASIBF.OID", error
 1004?

 Response:
    This error occurs because PASIBF.OID was never
 generated. In pass one, it is necessary to specify that you
 desire to make a .COD (combined source object) file. This
 is accomplished in Version 4.00 by using the /Fc switch.
 When pass three is implemented, it searches for the
 temporary file PASIBF.OID, which is generated only if you
 specify in pass one that you want a .COD file.


 179. P2 Assertion Error with -Gt

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23639

    The following program causes a P2 assertion error only if compiled
 with -Gt:

     CHARACTER*5 ARROW2(2)
     INTEGER DIF2C(2600),DIF2OC(2),ZIFFHL(2),ZIFFLH(2),
    *COUNT(2),CHG1(5)
     INTEGER*1 KR2(2),PH2(2),PL2(2),WK2(2),YR2(2),QH2(2),QL2(2)
     WRITE(8,*)
    +COUNT(J),WK2(J),YR2(J),ARROW2(J),
    *CHG1(N21),CHG1(N22),CHG1(N23),CHG1(N24),CHG1(N25),CHG1(N26),
    * CHG1(N27),CHG1(N28),PH2(J),PL2(J),QH2(J),QL2(J),KR2(J),
    * DIF2C(J),DIF2OC(J),ZIFFHL(J),ZIFFLH(J)
     END

    There is no workaround for this problem.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 180. Null Pointer Assignment Error at Compile Time with FORTRAN 4.0

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 24-JUL-1990    ArticleIdent: Q23635

 Problem:

 The FORTRAN Version 4.00 Compiler generates the message "error 2001:
 Null pointer assignment" at compile time for the following program:

        character*64 chrfunc
        write(*,*)chrfunc()
        end

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

 The error 2001 comes from the first pass of the compiler. The error
 may be related to the presence of a null argument in the function
 argument list; adding the chrfunc function to return a character
 string gives back blanks. The problem is not affected by optimization,
 and apparently only affects character type.


 181. Internal Compiler Error: exphelp.c 1.55, Line 1102

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23634

 Problem:
    The following program gives the assertion error "exphelp.c:1.55,
 line 1102" if compiled with -Od or -Odl (but not -Odct):

         REAL*8 EISKEW(6,3), BISKEW(3,6)
         COMMON /SKEW/   EISKEW
         EISKEW(I,J) = BISKEW(J,I)
         END

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler.
 The problem was corrected in Version 4.01.
    The apparent reason for the failure is the assignment of a real*8
 array element that is not in COMMON to a real*8 array element that is
 in COMMON.
    The workaround is to compile -Odct or default.


 182. Compiler Error Message omf_ms.c:1.108, Line1078

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q23633

 Problem:

 The following code generates the omf_ms.c:1.108, line 1078 error
 message:

        DIMENSION ALS(10085)
        DIMENSION D1(2017)
        COMMON /LB1/ V(36,32), VHI
        EQUIVALENCE(V(1,1),ALS(1))
        EQUIVALENCE(ALS(1),D1(1))
        WRITE(6,210) VHI
   210  FORMAT(/1H,'POTENT. DIST.  VC=',F8.5)
        END

 Response:

 The problem is corrected if you do one of the following:

 1. Take V out of COMMON.

 2. Do not write VHI.

 3. Leave out the second EQUIVALENCE statement.

 4. Change the second EQUIVALENCE statement to
    "EQUIVALENCE(v(1,1),D1(1))".

 5. Combine the two EQUIVALENCEs into one, such as
    "EQUIVALENCE(V(1,1),ALS(1),D1(1))".


 183. Error F1039

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-DEC-1987    ArticleIdent: Q23692

 Question:
    What does it mean when I get error F1039: "unrecoverable
 heap overflow in Pass3"?

 Response:
    This error indicates that the compiler ran out of
 dynamic memory space. The program may be too large or a
 subroutine may have too many symbols (thus it is running
 out of symbol space). This also will happen if your program
 is large and you are compiling with /Zi and /Od options.
    Currently, you can get around this problem by doing the
 following:

    1. Do not use the /Zi or /Od options with the Fl
 command.
    2. Break down the program into various source codes.


 184. Internal Compiler Error: loop.c 1.87, Line 836

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23637

    The following code generates the loop.c:1.87, line 836 internal
 compiler error message:

    11      continue
            if (k1 .ne. k2) goto 20
            if (k .eq. 0) return
            if (k .ne. 2) goto 11
    20      continue
            end

    The error message occurs on the last line; if you compile with /Od
 or /Odct, the error no longer appears.

    This problem seems to be very specific; any attempt to rearrange
 the order of the three IF statements allows the program to compile.
 The pattern seems to be as follows:

    label-1
    IF jumping to label-2
    IF jumping to label-3
    IF jumping to label-1
    label-2
    label-3

    Please note that the program also will fail if the RETURN is
 replaced with a GOTO 30 and a 30 Continue is added after 20 Continue.
 A workaround is to rearrange the order of the IF statements.
    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 185. Fixup Overflow L2002

 Product Version(s): 3.x 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q23663

    When you link your program, you may get the error message "L2002 fixup
 overflow." The following conditions can cause this error:

    1. A group is larger than 64K.
    2. The program contains an intersegment short jump or intersegment
       short call.
    3. The name of a data item in the program conflicts with that of a
       library subroutine included in the link.

    The most common of the three conditions is the first, i.e., one of
 the segments is over 64K; generally, it is the default data segment.
    To work around this problem, move data outside the default data
 segment. With Versions 4.x, use the /Gt compiler switch.
    This information is documented beginning on Page 232 of the
 "Microsoft FORTRAN Optimizing Compiler User's Guide" Versions 4.00,
 4.01, and 4.10. See the index for more references.
    For Versions 3.x, place data into named common blocks to move the
 data out of the default data segment.


 186. Getting Around Data Segment Limit

 Product Version(s): 3.2 3.3x 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-MAR-1988    ArticleIdent: Q23775

 Question:
    How do I get around the 64K data segment limit?

 Response:
    You can move arrays and local variables to a named
 common. You need to allocate data outside of the default
 data segment. When using a large memory model in Version
 4.0, use the /Gt option with the Fl command to place into a
 new segment those data items greater than or equal to the
 number of bytes specified.
    FORTRAN Version 4.00 and above can also use the HUGE
 memory model to allow individual data items (such as arrays
 and common blocks) to exceed 64K (using compiler option
 /AH). The HUGE keyword may also be used on individual data
 items that exceed 64K in LARGE model.


 187. Stack Overflow Error

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-DEC-1987    ArticleIdent: Q23776

 Question:
    My program is failing with a stack overflow error. How
 can I get around it?

 Response:
    The program requires more stack than is available. You
 need to increase the size of the stack by using EXEMOD or
 the /STACK option at link time.
    If there is not enough space in the default data segment
 for the stack to grow, users of Versions 3.2, 3.3, and 3.31
 should do the following:

    1. Move the arrays and other variables into named common
 block.
    2. Use $LARGE metacommands.
    3. Move format statements into named common block.

    When using large memory model, Version 4.0 users should
 use the option /Gt (which defaults to 256 bytes) to place
 all data items greater or equal to 256 bytes outside the
 default data segment.


 188. Internal Compiler Error: regMD.c 1.74, Line 1304

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23713

 Problem:
    The following code generates the compiler internal error message
 "regMD.c:1.74, line 1304":

    integer*2 i
    external i
    character x*127, y*15
    common /fred/ y
    y(17-i(x):)=x
    end

    The error is generated on the assignment statement. If I change
 integer*2 i to integer*4 i (or just delete it), the error is
 corrected.

 Response:
    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 189. Internal Compiler Error: grammar.c, Line 91

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 21-JUL-1988    ArticleIdent: Q23708

    The following code fragment generates a compiler error in
 grammar.c, line 91:

          SUBROUTINE R(NROW,NCOL,NLAY,BUFF,IRCH)
          DIMENSION BUFF(NCOL,NROW,NLAY),IRCH(NCOL,NROW)
          DO 30 IR=1,NROW
          DO 30 IC=1,NCOL
          IL=IRCH(IC,IR)
          IF(IBD.EQ.1)BUFF(IC,IR,IL)=Q
    30    CONTINUE
       END

    Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.01.
    The program gives an internal compiler error that will disappear
 when compiled with -Odclt. Using -Odclt when compiling is the easiest
 workaround.


 190. FORTRAN: Bad Code Generated with /Ot

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q28653

 If you compile the following code with the default optimization, /Ot,
 bad code is generated for the line "DO 19999 Y=N, 1, -1." If this
 sample is compiled with /Od to disable optimizations, correct code is
 generated.

          INTEGER CL
          PARAMETER(CL=12)
          INTEGER  X,Y
          REAL FLD(101,101)
          CHARACTER   BFR*101, LEVEL*26
          DATA  LEVEL/'ABCDEFGHIJKLMNOPQRSTUVWXYZ'/
    101   FORMAT(A1,'FIELD'/)
    102   FORMAT(' ',A101)
          DO 10 I=1,101
            FLD(I,I) = 1.0
    10    CONTINUE
          N=101

          DO 19999 Y=N,1,-1

          DO 19998 X=1,N
              IDX=50.0*FLD(X,Y)
              IF(MOD(IDX,2).NE.0) GO TO 19996
             CONTINUE
             IDX=(IDX/2)+1
             IF((IDX.GE.1).AND.(IDX.LE.26)) GO TO 19992
             GO TO 19993

    19992 CONTINUE
          BFR(X:X)=LEVEL(IDX:IDX)
          GO TO 19994
    19993 CONTINUE
          BFR(X:X)='*'
    19994 CONTINUE
          GO TO 19997
    19996 CONTINUE
          BFR(X:X)=' '
    19997 CONTINUE
    19998 CONTINUE
          WRITE(*,102) BFR(1:N)
    19999 CONTINUE
          RETURN
          END

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10; the problem was corrected in Version 5.00.


 191. Reading and Writing to I/O Ports

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-DEC-1987    ArticleIdent: Q23885

 Question:
    How can I read from and write to the communication
 ports?

 Response:
    In order to read from or write to the communication
 ports using FORTRAN, it is necessary to use a special
 device driver. You may have to write the device driver
 yourself, in assembly language.
    To read information from the communication ports also
 requires an assembly language interrupt handler, which is
 very complicated. It is necessarily complicated due to the
 nature of device handshaking, which is required in order to
 read but not always in order to write.


 192. Internal Compiler Error: regMD.c 1.79, Line 1507

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q28659

 The following internal compiler error is generated by the code
 given below:

    regmdc.for(3) : fatal error F1001: Internal Compiler Error
                    (compiler file '@(#)regMD.c:1.79', line 1507)
                    Contact Microsoft Technical Support

 The compiler switch /Odclt turns on all optimization but does not
 disable alias checking, as demonstrated in the following code:

       COMMON X(10),A,B
       J=2
       DO 40 I=1,B
       GO TO (10,20,30) , J
 10    IF(X(I).EQ.A) K=0
 20    IF(X(I).EQ.A) K=0
 30    IF(X(I).EQ.A) K=0
 40    CONTINUE
       END

 The workaround is to compile with the compiler switch /Odclt.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.


 193. FORTRAN Compiler Error D1001: "Could Not Execute F1.EXE"

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-JUN-1988    ArticleIdent: Q23883

 Problem:
    When I compile my program, I get the following message:

    error D1001: could not execute F1.EXE

 Response:
    The specified file containing a compiler pass or the linker is
 found, but for some reason cannot be executed. Any of the following
 items can cause this problem:

    1. The F1.EXE file cannot be found. You may have a
 terminate-and-stay-resident program that can alter the setting of the
 environment variable PATH. PATH indicates the location of F1.EXE.
    2. There is not enough memory.
    3. You have a bad F1.EXE file with illegal .EXE file format.
    4. DOS and COMMAND.COM are incompatible. If their version numbers
 are different, the compiler may not be able to open the intermediate
 file. This means the COMMAND.COM command processor cannot create the
 TMP directory for the compiler intermediate file.


 194. Loop Optimization Does Not Preserve CX When Calling NINT

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q28667

 Using FORTRAN Versions 4.01 and 4.10 with optimization "On" to compile
 the simple loop generates bad code, which will give a run-time error.

 To correct this problem, use /Odct (disables loop optimization) when
 compiling.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.

 The following code demonstrates the problem:

       PROGRAM TEST
       DIMENSION X(9), NX(9)
       DATA X/ 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8, 9.9/

       DO 100 I=1, 9
       100 NX( I ) = NINT( X( I ) )

       STOP
       END

 With optimization on, the index becomes corrupted because it is
 contained in the CX register; the index is really a loop counter. CX
 is set to nine and is decremented during each pass until it reaches 0
 (zero).

 The index for NX is the SI register; for the X array, the DI
 register is used. When you call the intrinsic function NINT, the CX
 register is not preserved. It contains a bad value after returning to
 the main program, which causes the loop to disappear when the main
 program tries to decrement CX.

 Note that there are a number of run-time errors that can occur. They
 are usually math related errors, such as M6101 <invalid operation> and
 M6201 <domain error>.


 195. Incorrect INTEGER Parameters in the Source

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23957

    INTEGER*2 variables that have been assigned values in a parameter
 statement sometimes are listed incorrectly in the source listing. The
 following code is an example:

    PROGRAM TEST
      INTEGER*2
      PARAMETER(I=300)
      END

    In the source listing, "I" is listed as having a value of 44.
    When INTEGER*2 variables are assigned values greater than 256 in a
 parameter statement, they show up as value mod 256 in the source
 listing. However, the values are used correctly in the code. This
 problem will be corrected in the next release.


 196. Run-Time Error 6500 on File Names Similar to Special Devices

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  9-JUN-1988    ArticleIdent: Q23906

    When attempting to READ from file "PRM.DAT", the run-time error
 F6500, "file not open for reading or file locked" is received.
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The run-time compiler thinks it is dealing with file "PRN". This
 error affects all of the special devices (AUX, CON, NUL, and PRN).
 Examples of this problem are as follows:

    1. READing from "PRM" gives error 6500.
    2. WRITing to "COL" writes to "CON".
    3. WRITing to "NUM" produces no output (like NUL).

    The workaround for this problem is not to use any file names that
 are similar to any of the special device names, e.g. AUX, CON, NUL,
 and PRN.


 197. Integer Versus Character Comparisons

 Product Version(s): m4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q23941

 Problem:

 While the MS-DOS FORTRAN Optimizing Compiler allows the comparison of
 Character variables with Integer variables, some care should be taken
 to perform the proper comparison.

 As an example, you might expect the following program to produce two
 ".TRUE." comparisons. In one case, the Character variable is compared
 against an Integer variable containing a Character constant and, in
 the second case, an Integer variable contains the ASCII value
 corresponding to the same character.

        CHARACTER*4 C4
        C4 = 'A'
        I4 = 'A'
        WRITE (*,'(1X,A,Z8,A,Z8,A)') 'C4 IN HEX=<',C4,'>  I4 IN HEX=<',
     +  I4,'>'
        WRITE (*,*) 'C4 .EQ. I4? ',C4 .EQ. I4
        I4 = #41
        WRITE (*,'(1X,A,Z8,A,Z8,A)') 'C4 IN HEX=<',C4,'>  I4 IN HEX=<',
     +  I4,'>'
        WRITE (*,*) 'C4 .EQ. I4? ',C4 .EQ. I4
        END

 Response:

 That assumption is incorrect, as evidenced by the hexadecimal
 representation of the value of the I4 variable. The following is the
 output from the program:

    C4 IN HEX=<41202020>  I4 IN HEX=<20202041>
    C4 .EQ. I4? T
    C4 IN HEX=<41202020>  I4 IN HEX=<00000041>
    C4 .EQ. I4? F

 When the Character constant "A" is assigned, the unused three
 positions remaining in I4 are filled with blank characters
 (hexadecimal value 20). If the ASCII value equivalent to "A"
 (hexadecimal value 41) is assigned to I4, the remaining three
 positions are filled with zeros. Thus, the first comparison will
 succeed, while the second will fail.

 Please note that this caution does not apply to comparisons between
 Character and Integer*1 variables. Because no padding is necessary,
 the comparisons always will be correct.


 198. Problem with INCLUDE and LST Files

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q24061

    If you compile a FORTRAN program that contains an INCLUDE file, as
 in the example below, the $LIST fails to turn listing back on until
 the symbol table listings at the bottom. The INCLUDE file does not
 have a CTRL-Z in it.
    The following is an example:

    $NOLIST
                 INTEGER*2 INUM,X,Y
    $LIST

    This problem was corrected in Version 4.01.


 199. Help and Arg Compile "Not an Editor Switch"

 Product Version(s): 5.00    | 5.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q46262

 The following messages can be generated when the Microsoft Editor (M)
 is set to use the Quick configuration:

    Help is not an editor switch
    Argcompile is not an editor switch

 The following two lines must be deleted from the TOOLS.INI file to
 correct this problem:

    Argcompile:F5  (delete only the first occurrence of this)

    Help:F1

 Argcompile is correctly defined later in the TOOLS.INI file. Help is
 defined by default.


 200. $PAGE Metacommand Occasionally Does Not Work

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24172

    The $PAGE metacommand is supposed to begin a new page in the
 source-listing file, but occasionally it fails to do so.
    This problem was corrected in FORTRAN Version 4.01. There is no
 known workaround.


 201. Sending a File with a Control Character to the Printer

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q24212

 Question:

 When I send a control character to a file, then send that file to the
 printer, the control character is printed out. How do I get around
 this situation?

 Response:

 Carriage control characters are not used for disk files. Any character
 you send to a disk file actually appears in the disk file; therefore,
 the first character appears instead of being used for carriage
 control.

 If you want to produce a disk file that causes the printer to form
 feed when it is printed, you must insert a form feed character into
 the file itself. The ASCII form feed character is decimal 12, so you
 can write this into a file. For instance, the following program
 inserts a form feed character into the disk file "test":

        open(6,file = 'test', status = 'new')
        write(6,*) 'hello'
        write(6,1) char(12)
    1   format(a1)
        write(6,*) 'there'
        end

 When printed, "hello" will show on the first page of output, the
 printer will form feed, and "there" will be on the second page of
 output.


 202. Compiler Error "Omf_ms.c:1.108, Line 1078"

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.
 Last Modified: 31-MAY-1988    ArticleIdent: Q24287

    The following code produces the error "omf_ms.c:1.108, line 1078",
 if compiled without option -Od. If compiled with option -Od, the code
 produces this error as well as "error omf_ms.c:1.108 line 2458". Thus,
 the -Od option adds to the problem. The following is the code:

    INTERFACE TO SUBROUTINE A

    END
    INTERFACE TO SUBROUTINE B(X)
    EXTERNAL X
    END
    CALL A
    CALL B(A)
    END

    This is a confirmed problem in Version 4.00 of the compiler. This
 problem was corrected in Version 4.01.


 203. Internal Compiler Error: mactab.c 1.30, Line 647

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q24214

 Problem:
    The following code generates the internal compiler error
 mactab.c:1.30, line 647:

    complex*16 z1,z2,z3
    z1=z1*dconjg(z2) *z3
    end

    If you use a temporary variable to hold the result of the function,
 the error is corrected (the intrinsic function dconjg returns the
 conjugate of a complex16 number).

 Response:
    This is a known problem in Version 4.00.
    The only workaround is to not use COMPLEX*16. Using COMPLEX*8
 causes no error.


 204. Error F1043

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-SEP-1988    ArticleIdent: Q24213

 Problem:

 When I run the compiler, it generates "error F1043: cannot open
 compiler intermediate file".

 Response:

 The compiler was unable to open an intermediate file. There are two
 possible causes, as follows:

 1. The environment variable TMP was set to a nonexistent
    directory. Try not setting TMP at all, or setting TMP to an
    existing directory, as follows:

    tmp=[drive:existent directory]     ;no spaces after tmp

 2. There is not enough space on the hard disk or you have
    a terminate-and-stay-resident program loaded in memory.


 205. Compile Time Error F1901

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q24383

 Question:

 Why did I receive F1901 compiler error: "program too large for
 memory"?

 Response:

 One reason why you received this error message may be that the FORTRAN
 program is too large for memory and needs to be broken into smaller
 subprograms, then linked together.

 Also, the message may be due to multiple definitions of the program
 name. The following is an example:

        Program TEST
        Common /TEST/

 Finally, the message may be due to the way FORTRAN keeps track of
 variables that are not explicitly given a type. FORTRAN allows you to
 have variable declarations anywhere in the declaration block and
 variables can have a default type. Variables starting with I-N are
 assumed to be integer; the others are assumed to be real variables.
 The following is an example:

        DIMENSION X(10),I(20)
        EQUIVALENCE (X(1),I(1))

 Unless the X and I arrays are explicitly given a type, the compiler
 must remember what type they are until the end of the declaration
 block. It is this necessity of saving the type information that can
 cause you to run out of memory. Those programs that receive this error
 (from the first pass of the compiler) should compile normally if the
 arrays are explicitly typed. The previous example would then be as
 follows:

        REAL X(10)
        INTEGER I(20)
        EQUIVALENCE (X(1),I(1))

 Some guidelines to lessen the chance of getting a "program too big"
 error are the following:

 1. Explicitly type arrays (especially those used in EQUIVALENCE
    statements).

 2. Concerning array bounds (10, 20, and 1 in the examples), use as few
    unique values as possible and mention the most frequently used
    bounds as soon as possible.

 3. The following program organization is recommended:

       type statements
       EXTERNAL statements
       DIMENSION statements
       COMMON statements
       EQUIVALENCE statements
       DATA statements


 206. Using FORTRAN 3.13 or 3.2 with an 80286 AT-class machine

 Product Version(s): 3.13 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q24418

 Problem:

 My FORTRAN Versions 3.13 and 3.20 programs work properly on an IBM-XT,
 but when I run the programs on an AT or AT clone, all zeros are
 generated.

 Response:

 If you do not have the 80287 numeric coprocessor with your 80286, you
 can experience problems with floating-point calculations.

 For Version 3.20, the following corrects this problem. If you do not
 have a coprocessor and you link with the default MATH library
 (MATH.LIB), you must explicitly tell MATH.LIB that there is no
 coprocessor by issuing the following command in DOS before running the
 program:

    SET NO87=8087 Suppressed

 This command forces the use of the floating-point emulation software.
 This action is necessary because an AT with no coprocessor fools
 MATH.LIB into thinking that there is a coprocessor present. This
 behavior causes the MATH.LIB to return incorrect results.

 Additional information about this SET command is available in the
 README.DOC file on the MS-DOS FORTRAN distribution disk.

 You do not need to use this SET command if you do the following:

 1. Link with ALTMATH.LIB or DECMATH.LIB, which do not use or look for
    the coprocessor.

 2. Use the modified Version 3.20 with math libraries enclosed.

 FORTRAN Version 3.13 does not recognize the NO87 environment variable;
 therefore, if you use this version, you must link with the enclosed
 modified library Version 3.13.

 Note: The patch includes the specially modified math libraries that
 can operate normally on the 80286 whether or not there is a
 coprocessor present. With Version 3.20 of Microsoft FORTRAN, use
 MATH.LIB and 8087.LIB. With Microsoft FORTRAN Version 3.13, use
 FORTRAN.LEM and FORTRAN.L87.


 207. $TITLE and $SUBTITLE not taking effect in LST files

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q24427

 $TITLE and $SUBTITLE are not taking effect in the LST file.

 $TITLE:"This is the main" was added to the first line of DEMO.FOR, and
 $SUBTITLE:"This is the subroutine" was added to the 28th line.
 However, "This is the main" is not printed at the top of the listing,
 and "This is the subroutine" is not printed before the subroutine.

 Microsoft has confirmed this to be a problem in Versions 4.00, 4.01,
 and 4.10 of the FORTRAN compiler. This problem was corrected in
 Version 5.00.


 208. Run-Time Hang from the Use of the EOF Function

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24429

    The following program will cause your computer to hang when
 compiled with FORTRAN Version 4.00:

            LOGICAL X
            OPEN(1)
            DO 1 I=1,10000
            X = EOF(1)
    1       CONTINUE
            END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    Each call to the EOF intrinsic function costs two bytes from the
 stack. The program may run properly if the run-time stack size is
 greater than two times the number of calls to EOF; therefore, a
 possible workaround is to raise the run-time stack size (via EXEMOD).


 209. Problem with FX.0

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24428

    Numbers with a value of less than .1 appear incorrectly when
 written in F10.0 format, as illustrated in the following code example:

           A=0.03
           WRITE(*,10) A
    10     FORMAT(1X,F10.0)
           END

    The output of the program is two.
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. The problem was corrected in Version 4.01.


 210. The Optimizer and Arrays Greater Than 32K

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24426

    The following program causes an infinite loop (if $STORAGE:2 is
 included, it loops through only once):

               INTEGER*2 BIGARY(8000,3),I,J,KOUNT
               KOUNT=0
               DO 100 J=1,3
                 DO 50 I=1,8000
                   BIGARY(I,J) = 1
                   KOUNT= KOUNT + 1
  50             CONTINUE
               WRITE(*,*)'KOUNT = ', KOUNT
  100          CONTINUE
               END

    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 211. Compile Time Warning F4803 on ENTRY Statement in FUNCTION

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 fixlist4.10
 Last Modified:  1-JUN-1988    ArticleIdent: Q24628

    According to Section 15.7.3 of the ANSI standard, variables
 corresponding to entry names and the function of the same type should
 be associated; defining one defines all of them. However, the
 following program produces the warning message "warning F4803: GRONK :
 FUNCTION : return variable not set" when compiled:

    function grot(z,y)
    grot=z*(z-y)
    return
    entry gronk(z,y)
    grot=z*z+y
    return
    end

    program thing
    write (*,*) 'The answer is...'
    write (*,*) gronk(3.5,1.0)
    end

    This is a known problem in Versions 4.00 and 4.01 of the FORTRAN
 compiler. This problem was corrected in Version 4.10.
    The workaround for Version 4.01 is to define a return variable
 "gronk".


 212. Concatenation (//) with the Target Variable on the Right

 Product Version(s): 4.00 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-JUL-1990    ArticleIdent: Q24618

 Problem:

 Below is a program fragment which appears to generate incorrect
 results when using a concatenation operator:

        CHARACTER*20 CH
        CH = 'B'
        CH = 'A'//CH       <-- string concatenation

 CH equals 'AA' after the concatenation operation and not the
 expected 'AB'.

 Response:

 It is strictly against the FORTRAN 77 standard to have the target
 variable, in this case CH, on the right side of the assignment.

 Referencing the assignment statement

    v = e

 page 10-3, lines 5-6, of the FORTRAN 77 standard states

    None of the character positions being defined in v may be
    referenced in e.

 The character positions defined by CH (v in the ANSI standard) in
 the code above are also referenced in CH (e in the ANSI standard),
 making this operation illegal.

 An additional 32K of memory would have to be allocated for temporary
 storage to make this a legal operation.


 213. Problem with Heap Allocator

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q24728

 Question:
    Why does FORTRAN Version 3.31 crash at compile time or when generating
 strange and erroneous error messages?

 Response:
    The Version 3.31 compiler stack size has been increased to 40K, and it
 causes erroneous errors at compile time. You will get one of the following
 error messages:

    1. Null Pointer Assignment
    2. Error : Compiler Invalid Pointer Range
    3. Will hang on FOR1
    4. Divide Overflow

    To work around this problem, decrease the size of the stack for FOR1.EXE t
 about 20K or 30K using EXEMOD, or specify that the compiler create a listing
 file.


 214. Calling Other Programs

 Product Version(s): all
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-AUG-1987    ArticleIdent: Q24736

 Question:
    How can I run another program from my FORTRAN program?

 Response:
    The method for running another Program from the FORTRAN program varies for
 different FORTRAN versions.
    For Version 3.3 and 3.31 users, use the library called CEXEC.LIB that has
 been added for system and spawn support. CEXEC.LIB, a subsidiary of the C
 library, can be used to run other programs. The CEXEC.LIB library has to be
 typed in explicitly.
    For Version 4.0 users, the FORTRAN run-time libraries MLIBFORx.LIB and
 LLIBFORx.LIB include the system routine and a subset of the spawnlp routine
 (as well as other routines) from the C library. FORTRAN programs can access
 these routines in the FORTRAN run-time libraries. The demonstration program
 DEMOEXEC.FOR, included with the Microsoft FORTRAN Compiler, also gives
 examples of how to call these routines.


 215. FORTRAN 4.10 FLOPSET.DOC File, Setup on Floppies

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 28-APR-1988    ArticleIdent: Q28720

    The following information concerns the FORTRAN Version 4.10
 FLOPSET.DOC file:

 FLOPSET.DOC -- Removable Disk Setup Information
 (C) Copyright Microsoft Corporation, 1987

    The following information replaces Sections 2.4.4 and 2.4.5 of the
 Microsoft(R) FORTRAN Optimizing Compiler User's Guide.

 Installing on a 5 1/4-Inch Disk System
    Before you install the compiler on a 5 1/4-inch disk system, you
 should format at least eight blank disks. SETUP uses seven blank disks
 for the compiler software and libraries. In addition, you should copy
 source programs, including the DEMO.FOR demonstration program, to the
 eighth blank disk. Table 2.1 shows how SETUP organizes your 5 1/4-inch
 disks.
     If you request compatibility with Versions 3.20 and 3.30 of
 Microsoft FORTRAN, SETUP requires a ninth blank disk (which becomes
 the Compatibility disk), to which it copies the compatibility library,
 FORTRAN.LIB. This disk can be either a formatted blank disk or a disk
 with earlier-version object files that you want to link. Be sure to
 label the disk before using it with SETUP.

 Installing on a 3 1/2-Inch Disk System
    Before you install the compiler on a 3 1/2-inch disk system, format
 at least five blank disks. SETUP uses four blank disks for the
 compiler software and libraries. In addition, you should copy source
 programs, including the DEMO.FOR demonstration program, to the fifth
 blank disk. Table 2.2 shows how SETUP organizes your 3 1/2-inch disks.

 Table 2.1
 Organization for 5 1/4-Inch Disks
 --------------------------------------------------------------------------
 Disk Name           Files           File Contents
 --------------------------------------------------------------------------
 Driver              FL.EXE          Executable file for the FL command
                     FL.ERR          Error-message file for the FL command
                     FL.HLP          FL command help file
                     F1.EXE          Pass 1 of the compiler
                     F1.ERR          Error-message file for Pass 1 of the
                                     compiler
 Compiler 1          F2.EXE          Pass 2 of the compiler
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
 Compiler 2          F3.EXE          Pass 3 of the compiler
                     F3S.EXE         Alternate Pass 3 of the compiler. This
                                     pass is used if optimization is dis-
                                     abled during compiling. (See Section
                                     3.3.15, "Optimizing," of the User's
                                     Guide for more information.)
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
 Link                LINK.EXE        Executable file for the linker
                     xLIBFORx.LIB    Library created by SETUP
 Utility             LIB.EXE         Executable file for the LIB utility
                     MAKE.EXE        Executable file for the MAKE utility
                     EXEPACK.EXE     Executable file for the EXEPACK utility
                     EXEMOD.EXE      Executable file for the EXEMOD utility
                     ERROUT.EXE      Executable file for the ERROUT utility
                     SETENV.EXE      Executable file for the SETENV utility
 Debug               CV.EXE          Executable file for the Microsoft
                                     CodeView(R) debugger for MS-DOS
                     CV.HLP          Help file for the CodeView debugger
                                     for MS-DOS(R)
                     CVPACK.EXE      Executable file for the CVPACK utility
 Scratch             LIB.EXE         Executable file for the LIB utility,
                                     which is used to help build the
                                     run-time library. SETUP installs
                                     this file on this disk.
                     Intermediate    Present while SETUP is running;
                     versions of     deleted from the disk when SETUP
                     libraries       finishes normally
 ----------------------------------------------------------------------------

 Table 2.2
 Organization for 3 1/2-Inch Disks
 ----------------------------------------------------------------------------
 Disk Name           Files           File Contents
 ----------------------------------------------------------------------------
 Driver/Compiler     FL.EXE          Executable file for the FL command
                     FL.ERR          Error-message file for the FL command
                     FL.HLP          Help file for the FL command
                     F1.EXE          Pass 1 of the compiler
                     F1.ERR          Error-message file for Pass 1 of the
                                     compiler
                     F2.EXE          Pass 2 of the compiler
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
                     F3.EXE          Pass 3 of the compiler
 Link                F3S.EXE         Alternate Pass 3 of the compiler. This
                                     pass is used if optimization is dis-
                                     abled during compiling. (See Section
                                     3.3.15, "Optimizing," of the User's
                                     Guide for more information.)
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
                     LINK.EXE        Executable file for the linker
                     xLIBFORx.LIB    Library created by SETUP
 Utility             LIB.EXE         Executable file for the LIB utility
                     MAKE.EXE        Executable file for the MAKE utility
                     EXEPACK.EXE     Executable file for the EXEPACK utility
                     EXEMOD.EXE      Executable file for the EXEMOD utility
                     ERROUT.EXE      Executable file for the ERROUT utility
                     SETENV.EXE      Executable file for the SETENV utility
                     CV.EXE          Executable file for the Microsoft
                                     CodeView debugger for MS-DOS
                     CV.HLP          Help file for the CodeView debugger
                                     for MS-DOS
                     CVPACK.EXE      Executable file for the CVPACK utility
 Scratch             LIB.EXE         Executable file for the LIB utility,
                                     which is used to help build the
                                     run-time library. SETUP installs
                                     LIB.EXE on this disk.
                     Intermediate    Present while SETUP is running;
                     versions of     deleted from the disk if SETUP
                     libraries       finishes normally
 -----------------------------------------------------------------------------


 216. Error F6601: Direct Record Overflow on Rewind

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25009

    The following source code will generate run-time error F6601:

    open(file='test',access='direct',recl=50,status='unknown')
    write(5,rec=4) 'hello'
    endfile 5
    rewind(5)
    end

    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 217. Appending to CTRL-Z-Terminated File

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 fixlist4.10
 Last Modified: 31-MAY-1988    ArticleIdent: Q25010

 Problem:
    Attempting to append to a CTRL-Z-terminated file causes the file
 pointer to be positioned in an incorrect record. The typical symptom
 associated with this problem is that the first character of a file
 will be duplicated when the file is appended to.
    For example, a CTRL-Z-terminated file which contains the characters
 ABC will appear as AABCDEF when DEF is appended to it.

 Response:
    Microsoft has confirmed this to be a problem in Version 4.01 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.10.


 218. Programs Executed by PAUSE Statements

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25110

 Problem:
    When my program executes a second program following a PAUSE
 statement, input to the second program cannot be redirected from a
 file. For example, if the following program named fort1.for:

        pause
        end

 executes the following program named fort2.for:

        read(*,*) i,j
        read(*,*) k,l
        write(*,*) 'i,j,k,l=',i,j,k,l
        end

 and I want to obtain input for fort2.for from a file named fort2.dat,
 the following sequence of steps causes an end-of-file error:

        fort1
              pause - Please enter a blank line (to continue) or DOS
                      COMMAND
        fortr2 < fort2.dat

 Response:
    This error occurs because the child program, fort2, inherits file
 handle attributes from the parent program, fort1. Because you did not
 specify redirection for fort1, the run-time system assumes that fort2
 also does not use redirection.
    The workaround is to create a data file containing the command line
 that redirects input to the child program. For the above example,
 construct a data file named fix.dat containing the following
 statement:

    fort2 < fort2.dat

    Use this new data file as input when running the parent program.
 For the example above, run fort1 using following command line:

     fort1 < fix.dat

    This command line causes the PAUSE command to take its input from
 fix.dat and causes fort2 to recognize that its input has been
 redirected. This allows fort2 to take its input from fort2.dat.
    This is a known problem in Version 4.01.
    This feature is under review and will be considered for inclusion
 in a future release.


 219. FORTRAN 4.10 README.DOC: Requesting Assistance from Microsoft

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28721

 The following section of the FORTRAN README.DOC file provides
 information regarding reporting problems with the compiler.

 README.DOC -- (C) Copyright Microsoft Corporation, 1987, 1988
 Microsoft(R) FORTRAN Optimizing Compiler Version 4.10

 This document contains information about Version 4.10 of the
 Microsoft(R) FORTRAN Optimizing Compiler and libraries. Microsoft
 updates its documentation when it is reprinted, so you may find that
 some of the information in this file has already been included in your
 manuals.

 NOTE

 Microsoft CodeView(R) and the utilities have a separate readme
 file, CVREADME.DOC, on the CodeView for MS-DOS disk.

 REQUESTING ASSISTANCE FROM MICROSOFT -- [phone]

 When reporting problems with the compiler, please provide Microsoft
 Corporation with the following information to help in tracking down
 the problem:

    *   The compiler version number (from the logo that appears on the
        screen when you invoke the compiler using the FL command).

    *   The version of DOS you are running (use the VER command in DOS).

    *   Your system configuration (the machine, total memory, and total free
        memory at compiler execution time).

    *   The command line used in the compilation.

    *   All object files/libraries used to link, if necessary. You need
        not provide standard object files/libraries, but please state which
        ones you are using.

 Having this information will help solve your problem quickly.


 220. Converting Decimal Floating Point to IEEE Format

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-OCT-1987    ArticleIdent: Q25112

 Question:
    A program I compiled with Version 4.01 reads data files by a program
 compiled with Version 3.2 and decmath.lib. However, Version 4.01 no longer
 supports decmath.lib. Is there any way for me to read the data file?

 Response:
    Since you know the ordering of the variables in the files, you can convert
 the file by doing the following:

    1. Using a Version 3.2 program compiled with $decmath, read the old data
 file, and write a new file using formatted writes.
    2. Using a Version 4.01 program or a Version 3.2 program compiled without
 $decmath, read the new formatted file, and write a new unformatted (or binary
 whichever was used) file.


 221. Optimization Problem

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  7-OCT-1988    ArticleIdent: Q25113

 Problem:

 In the program fragment below, no code is generated for the assignment
 hibyt=hold. This problem does not occur if optimization is turned off
 or if line 36 is moved between lines 33 or 34. The statements are as
 follows:

    33  lowbyt=hold
    34  lowbyt=iand(lowbyt,lowmsk)
    35  call output(datprt,lowbyt)
    36  hibyt=hold
    37  hibyt=ishift(iand(hibyt,himsk),shift)
    38  call output(datprt,hibyt)

 Response:

 Microsoft has confirmed this to be a problem in Version 4.01. We are
 researching this problem and will post new information as it becomes
 available.


 222. "Invalid Object Module" Error

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25114

 Problem:
    When the following code is compiled with default options, the error
 "invalid object module at link time" is generated.

    character*128 string
    dimension string(640)
    data string/640*'help'/
    string(1)='bug'
    end

    The error is not generated when the last three lines are rewritten
 as follows:

     do 10 i=1,640
       string(i)='help'
 10  continue
     string(1)='bug'
     end

 Response:
    This is a known problem in Version 4.01 of the FORTRAN compiler.
    The error will exhibit itself if you try to initialize more than
 one CHARACTER array element with a size greater than 127 bytes.
    This problem can be worked around by reducing CHARACTER size below
 128 or initialize the array by using assignment statements.


 223. Large Arrays and Entry Statements

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25115

    After returning from the initial subroutine call and reentering
 through ENTRY statements, "incorrect address" is passed for the
 following code:

     real*4 a(20000)
     common /m1/m
     m=20000
     do 10 i=1,m
      a(i)=i
 10  continue
     call sub1(a)
     call el
     end

     subroutine sub1(a)
     real*4 a(m)
     common /m1/m
     write(*,*) a(1), a(m),m
     return
     entry el
     call e2
     return
     end

    This code works correctly if the variable m is not in common.
    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 224. Concatenation Results Passed to Function

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25133

    The concatenation operation will not pass the proper results to the
 formal argument when used within a function call. The proper results
 seem to be followed by part of the copyright message instead of
 blanks. The following program demonstrates this problem:

         CHARACTER*80 FUNCTION OKPLT(X)
         CHARACTER*80 X
         WRITE(*,'(A)') X
         OKPLT = X
         RETURN
         END
 C
         CHARACTER*80 OKPLT
         CHARACTER*80 DOIT
         CHARACTER*10 CHARVAR
         CHARVAR = '1234567890'
         DOIT = 'TEXT'// CHARVAR // ' TEXT2'
         WRITE (*,'(A)') DOIT
         DOIT = OKPLT('TEXT'// CHARVAR // ' TEXT2')
 C       The above line does not pass the concatenation results
 C       correctly.
         WRITE (*,'(A)') DOIT
         END

    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 225. Loop Optimization

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR65661 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25161

 Problem:
    The following code will generate an incorrect result when loop
 optimization is on:

           n=3
           nseq=1
           ns=21
           do 80 k=1,ns
           ni=k
           nbit=0
   1       nbit=nbit+mod(ni,2)
           ni=ni/2
           if(ni.gt.0) go to 1
           if(nbit.ne.n) go to 80
           nseq=nseq+1
   80      continue
           write(*,*) nseq
           end

    In the above example, "nseq" should be 7; instead, it returns 22.

 Response:
    This is a known problem in Version 4.01.
    The only workaround is to turn off loop optimization by recompiling
 the source with /Odct option.
    Microsoft is researching the problem and will post new information
 as it becomes available.


 226. Problem with Function INT and Optimization

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR65841 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25380

    The intrinsic function INT does not work correctly if optimization
 is on; it rounds the number off instead of truncating it. The
 following is a sample code:

       integer*4 i
       flt = 128.67
       i=nint(flt)
       write(*,*) 'flt,i,nint(flt),int(flt):',flt,i,nint(flt),int(flt)
       end

    With the default optimization, the output is the following:

    flt,i,nint(flt),int(flt):    128.670000     129     129   129

    The correct output should be:

    flt,i,nint(flt),int(flt):    128.670000     129     129   128

    This is a known problem with Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The workaround is to turn off optimization by recompiling the
 source with /Od option.


 227. Internal Compiler Error: grammar.c, Line 91 and FORTRAN 4.01

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 fixlist4.10
 Last Modified: 24-JUL-1990    ArticleIdent: Q25429

 Problem:
    The following program generates "fatal error F1001: Internal
 Compiler Error in file grammar.c, line 91":

         PROGRAM GRAMMAR
         DIMENSION ITIMES(11)
         DIMENSION ITOT(11,50),IBEG(11,50)
         COMMON/A2/IHRS,NPAR
         DATA NTIMES/0/
         DO 30 I=1,NPAR
         IF(ITOT(I,ITIMES(I)).LT.IHRS)THEN
            IBEG(I,ITIMES(I))=0
         ELSE
            ITIMES(I)=ITIMES(I)+1
         ENDIF
  30     IF(ITIMES(I).GT.NTIMES)NTIMES=ITIMES(I)
         RETURN
         END

 Response:
    Microsoft has confirmed this to be a problem with Version 4.01 of
 the FORTRAN compiler. This problem was corrected in Version 4.10.
    The workaround is to either turn off loop optimization with the /Od
 or /Odct, or to ensure floating point variable storage with the /Op
 switch.


 228. Repeated Use of BACKSPACE Causes Run-Time Error F6501

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25432

 Problem:
    The following program and data file cause run-time error F6501 "End
 of File Encountered":

    $storage:2
    $debug
            character*80 rtnstr
            integer fun/3/
            open(fun,file='test.dat')
            read(fun,1000) rtnstr
    1000  format(A)
            backspace fun
            backspace fun
            close(fun)
            end

 Response:
    The error seems to be caused by repeated use of BACKSPACE when the
 file pointer already is positioned near the beginning of the file. The
 data file TEST.DAT contains one integer number and no carriage return
 line feed.
    The workaround is to set the blocksize to a larger value, as in the
 following open statement:

    open(fun,file='test.dat',blocksize=2048)

    Microsoft is researching this problem and will post new information
 as it becomes available.


 229. Problem Evaluating Expressions with Complex Variables

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01
 Last Modified: 20-OCT-1988    ArticleIdent: Q25452

 Problem:

 The following program illustrates a problem with the Versions 4.00 and
 4.01 FORTRAN compiler regarding the evaluation of complex expressions:

        program cmplx
        complex*8 x, z

        z=(0., 1.)
        write(*,'(1x,''z=             '', 2(1x, f10.3))') z
        x = 1.-z
        write(*,'(1x,''x=1.-z         '',2(1x,f10.3))') x
        x = 1.+(-z)
        write(*,'(1x,''x=1.+(-z)      '',2(1x,f10.3))') x
        x = 1.+(-1.)*z
        write(*,'(1x,''x=1.+(-1.)*z   '',2(1x,f10.3))') x
        x = 1.+(0.-1.)*z
        write(*,'(1x,''x=1.+(0.-1.)*z '',2(1x,f10.3))') x
        x = 1.-z
        write(*,'(1x,''x=1.-z         '',2(1x,f10.3))') x
        end

 The program was compiled using the default compiler options; however,
 the option selected does not appear to impact the performance of this
 program. Also, the use of complex*16 produces the same result.

 The output under FORTRAN Version 4.00 is the following:

    z=                    .000      1.000
    x=1.-z               1.000      1.000
    x=1.+(-z)            1.000     -1.000
    x=1.+(-1.)*z         1.000       .000
    x=1.+(0.-1.)*z       1.000       .000
    x=1.-z               1.000      1.000

 The output under FORTRAN Version 4.01 is the following:

    z=                    .000      1.000
    x=1.-z               1.000     -1.000
    x=1.+(-z)            1.000     -1.000
    x=1.+(-1.)*z         1.000       .000
    x=1.+(0.-1.)*z       1.000       .000
    x=1.-z               1.000     -1.000

 The correct result is the following:

    z=                    .000      1.000
    x=1.-z               1.000     -1.000
    x=1.+(-z)            1.000     -1.000
    x=1.+(-1.)*z         1.000     -1.000
    x=1.+(0.-1.)*z       1.000     -1.000
    x=1.-z               1.000     -1.000

 Response:

 Microsoft has confirmed this to be a problem in Versions 4.00 and
 4.01. We are researching this problem and will post new information as
 it becomes available.


 230. Internal Compiler Error: trees.c, Line 1165

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25465

    The following program:

    program trees
    character ch(20)
    ch() = 'a'
    end

 causes the compiler to generate the following error message:

  trees.for(3) : fatal error F1001: Internal Compiler Error
            (compiler file '../trees.c', line 1165)
            Contact Microsoft Technical Support

    This program was compiled using the default compiler options.
 However, when options are selected, they do not appear to affect the
 error.
    This is a known problem in Versions 4.00 and 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The only workaround is to include an array index on Line 3 of the
 example.


 231. FORTRAN 4.10 README.DOC: OS/2 Demonstration Program

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER Doscalls API system
 Last Modified: 30-OCT-1990    ArticleIdent: Q28796

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 OS/2 Demonstration Program
    The program SORTDEMO.FOR on the distribution disks contains
 examples of how to make OS/2 calls from a FORTRAN program. See the
 PACKING.LST file for the location of the program.


 232. FORTRAN 4.10 README.DOC: Common Problems with SETUP

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28797

    The following information is from the FORTRAN Version 4.10
 README.DOC File:

 Common Problems with SETUP
    When run to create a library, SETUP may quit with an error message
 telling you that the LIB program cannot be found or run. Doing one or
 more of the following steps, in turn, should resolve the problem:

    1. Ensure that the LIB.EXE program is in one of the directories in
 the path. If necessary, modify your path and rerun SETUP.
    2. Remove all terminate and stay resident (TSR) programs from
 memory and try SETUP again.
    3. Reduce your system's environment space as much as possible and
 rerun SETUP.


 233. FORTRAN 4.10 README.DOC: Floating-Point Operations

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28798

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Floating-Point Operations under PC-DOS 3.20
    If you are running IBM(R) Personal Computer DOS (PC-DOS) 3.20 and
 trapping floating-point exceptions in your program, you may find it
 necessary to patch PC-DOS 3.20 to get proper operation when
 floating-point exceptions occur. Please refer to the file named
 README.DOC in the \PATCH subdirectory on the Setup distribution disk
 for instructions on making this patch.

 Floating-Point Operations under MS-DOS 3.20
    This information is important only if your system has ALL of the
 following characteristics:

    1. You use MS-DOS Version 3.20.
    2. You boot from a hard disk drive.
    3. Your system has a math coprocessor (for instance, an 8087 chip).
    4. You run programs that use floating-point math.

    For systems that satisfy all of the preceding conditions, you may
 be able to eliminate floating-point math problems by installing a
 small patch in DOS. If you are not sure whether you need the patch,
 perform the following steps:

    1. Copy the program PATCH87.EXE (included in this release on Disk
 1) to the root directory of your hard disk drive.
    2. Reboot your system from the hard disk and DO NOT PERFORM ANY
 FLOPPY-DISK OPERATIONS after rebooting. It is very important that you
 avoid floppy-disk I/O after rebooting, since that will affect the
 reliability of the diagnostic test that you are about to perform.
    3. If necessary, use the CD command to move to the root directory
 of your hard disk drive.
    4. Run the PATCH87.EXE program by entering this command at the DOS
 prompt:
             PATCH87

    5. The program performs a diagnostic test on your system to
 determine whether it needs the DOS patch, and, if the patch is needed,
 whether it can be performed successfully. If the program tells you
 that you need to install the DOS patch, and that it can be done,
 follow the procedure described in the next section.

    NOTE: The floating-point problem has been eliminated in versions of
 MS-DOS higher than 3.20. This includes MS-DOS Versions 3.21 and 3.30.
    If you performed the preceding test and determined that you should
 install the DOS patch on your system, perform the following steps:

    1. Format a blank floppy disk. (Do NOT use the /s formatting option
 to transfer system files to the disk.)
    2. Use the SYS command to copy IO.SYS and MSDOS.SYS from the root
 directory of your hard disk to the new floppy disk. For instance, if
 you boot from Drive C:, you would enter the following commands:

             C:
             SYS A:

    3. Use the COPY command to copy COMMAND.COM and SYS.COM to the same
 floppy disk.
    4. Use the COPY command to copy the program PATCH87.EXE (included
 in this release) to the same floppy disk.
    5. Change the current drive and directory to the floppy disk, by
 entering the following command:

             A:

    6. Install the DOS patch by entering the following command:

             PATCH87 /F

    WARNING: If you experience any disk errors during steps 2 through
 6, do not proceed with step 7. Reboot from your hard disk and repeat
 the entire process.
    7. If you have not experienced any errors, use the SYS command to
 transfer the files IO.SYS and MSDOS.SYS from the floppy disk back to
 your hard disk. For instance, if the boot directory of your system is
 the root directory of Drive C:, you would enter the following command
 at the DOS prompt:

             A:
             SYS C:

    8. The DOS patch has been installed. Reboot the system.


 234. FORTRAN 4.10 README.DOC: New Versions of LINK.EXE and LIB.EXE

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28799

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 GENERAL NOTES
    Version 4.10 of the Microsoft FORTRAN Optimizing Compiler fixes a
 number of errors in Version 4.01.
    This section provides additional information about the compiler,
 how the compiler optimizes programs, and about common problems and
 their solutions.

 New Versions of LINK.EXE and LIB.EXE
    Earlier versions of the linker will not correctly link programs
 compiled with FORTRAN Version 4.10. Use the Segmented-Executable
 linker (LINK.EXE) included on the distribution disks, or a later
 version. You may need to modify the path specified in your
 AUTOEXEC.BAT file to ensure that the correct version of the linker is
 used.
    Also be sure to use the version of the Library Manager, LIB.EXE,
 included on the distribution disks. You may need to modify your path
 to make sure the correct version of LIB is used.


 235. FORTRAN 4.10 README.DOC: Setting Up the Microsoft Editor

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28800

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Setting Up the Microsoft Editor
    The FORTRAN setup program does not install the Microsoft Editor.
 To install the Microsoft Editor, insert the Microsoft Editor disk and
 run the MSETUP batch file. To use the MSETUP batch file under
 protected-mode OS/2, rename MSETUP.BAT to MSETUP.CMD.
    For more information about the Microsoft Editor, see the Microsoft
 Editor User's Guide and the CVREADME.DOC file on the CodeView for
 MS-DOS disk.


 236. FORTRAN 4.10 README.DOC:Optimizations and End-of-File Checking

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28801

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Optimizations and End-of-File Checking
    With the default optimizations performed by the compiler, a READ
 statement like

    READ (1,*,END=100) (X(I), I = 1, 10)

 may cause problems because end-of-file checking is performed only when
 the loop is exited, not after each pass through the loop.
    If you encounter similar problems in a program, compile the program
 with the /Od option to disable optimizations.


 237. FORTRAN 4.10 README.DOC: Linking MS FORTRAN and MS C Modules

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28802

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Linking Microsoft FORTRAN and Microsoft C Modules
    If you use SETUP to create a library that is compatible with
 Microsoft C, then you MUST specify and use the actual Microsoft C
 Version 4.00 library (either LLIBC.LIB or MLIBC.LIB, depending on the
 memory model) when you link with the C-compatible FORTRAN library.


 238. FORTRAN 4.10 README.DOC: Floating-Point Options

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28803

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Library Considerations for Floating-Point Options
    See Section 8.3.1 of the Microsoft FORTRAN Compiler User's Guide
 for information about specifying libraries in addition to the default
 library for the floating-point option that you select on the FL
 command line.


 239. FORTRAN 4.10 README.DOC: Internal Compiler Assertions

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28804

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Internal Compiler Assertions
    In trying to perform optimizations on extremely complex code, the
 compiler may experience an internal error condition. Sometimes it is
 possible to work around this problem by disabling the optimization
 pass of the compiler with the /Od option.
    In all cases where you experience this type of compiler error,
 please contact Microsoft Corporation so that corrections can be made
 for subsequent releases.


 240. FORTRAN 4.10 README.DOC: Stack Size in OS/2 Programs

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28805

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Stack Size in OS/2 Programs
    Any FORTRAN program running in protected-mode should have at least
 2K of free stack space at the beginning of an operating system call.
 Because the FORTRAN program itself uses some of the stack before the
 system call, the default stack size of 2K may not be adequate. You
 should increase the stack size of your program to ensure sufficient
 free stack space for operating system calls. Use the /F driver option
 or the /ST linker option to increase the stack size. A stack size of
 3K to 4K should be sufficient in most cases.
    NOTE: All programs running in protected-mode make operating system
 calls through the run-time system and should use a stack size of 3K to
 4K.


 241. MS-DOS Device Names

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10200

 Question:
    DOS treats file names such as CON and ERR as device names when the
 DOS2FOR library is used.
    Can DOS treat any file name as a device?

 Response:
    The association of the name ERR to the DOS device handle "stderr"
 is done by FORTRAN (i.e., DOS2FOR, not DOS itself).
    There is no FORTRAN command, subroutine, or function to determine
 whether or not a given name is the name of a DOS device. It is
 possible to make this determination in an assembly language subroutine
 by doing the following:

    1. Open a handle using the file name
    2. Perform an IOCTL call on that handle


 242. FORTRAN 4.10 README.DOC: Iteration Counts for DO Loops

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28806

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Iteration Counts for DO Loops
    As explained in Section 5.3.13 of the Microsoft FORTRAN Optimizing
 Compiler Language Reference, the following formula is used to compute
 the iteration count for a DO loop:

      MAX(INT((stop - start +inc)/inc), 0)

    Note that the iteration count is computed in two-byte precision,
 the default for integers. If the iteration count overflows this
 precision, the results are unpredictable. The following is an example
 of code that causes this problem:

      IMPLICIT INTEGER*2 (A-Z)
      IEND = 32000
      ISTEP = 12000
      DO 10 I=0,IEND,ISTEP
        WRITE (*,*) 'I=',I
 10   CONTINUE
      END


 243. .LST Files and Parameter Statement

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10376

 Problem:
    .LST files do not list the data type of identifiers used in
 parameter definitions.

 Response:
    This problem was corrected in Version 3.30.


 244. FORTRAN 4.10 README.DOC: Path Specifications for the Linker

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28807

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Path Specifications for the Linker
    Please make sure that the linker that comes with the Microsoft
 FORTRAN Optimizing Compiler Version 4.10 is the first linker in your
 path specification.


 245. Source File Named "ERR.FOR"

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified:  9-MAR-1988    ArticleIdent: Q10411

 Problem:
    A source file with the name "ERR.FOR" hangs the first pass of the
 compiler (FOR1).

 Response:
    This is not a problem with the compiler but is a restriction that
 has been eliminated in Version 4.00.
    This file name does not hang the computer; rather, the computer is
 waiting for input from the keyboard. Issuing a CONTROL-C will return
 you to the DOS prompt.
    Both the FORTRAN compiler and the run-time library associate the
 name "ERR" with the MS-DOS standard error device handle. When you
 issue the command "FOR1 ERR;", the FORTRAN compiler expects source
 code from the keyboard rather than a file named "ERR.FOR".


 246. FORTRAN 4.10 README.DOC: Invariant Expressions in DO Loops

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28808

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Invariant Expressions in DO Loops
    Calculations in DO loops may involve variables whose values do not
 change within the loop. Such calculations should be performed outside
 of the loop. Performing calculations outside the loop saves time and
 allows you, rather than the compiler, to choose which invariant
 expressions are removed.
    The following sample program includes a DO loop that may cause
 program failure:

             REAL NUMER
             DIMENSION ARRAY(100)
             DO 10 I=1,100
               IF (DENOM .NE. 0) ARRAY(I) = ARRAY(I)+NUMER/DENOM
      10     CONTINUE
             END

    The compiler knows that NUMER/DENOM does not change within the
 loop, so it calculates NUMER/DENOM only once: before the start of the
 loop and before the IF statement within the loop can check for
 division by zero. You could rewrite the program as shown below to
 avoid this problem:

            REAL NUMER
            DIMENSION ARRAY(100)
            TEMP = 0.0
            IF (DENOM .NE. 0) TEMP = NUMER/DENOM
            DO 10 I=1,100
              ARRAY(I) = ARRAY(I)+TEMP
      10    CONTINUE
            END


 247. FORTRAN 4.10 README.DOC: Input/Output System

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28809

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 NEW AND CHANGED FEATURES
    The following notes describe important new and changed features in
 the Microsoft FORTRAN Optimizing Compiler and the software provided
 with the compiler.

 Input/Output System -- Limits on Left Tabbing
    Left tabbing is legal within records written to devices. However,
 if the record that is written is longer than the buffer associated
 with the device, you cannot left tab to a position corresponding to
 the "previous" buffer.
    For example, the buffer associated with the console is 132 bytes
 long. If a record of 140 bytes is written to the console, left tabbing
 is allowed for only eight bytes, since the first 132 bytes of the
 record have been sent to the device and are no longer accessible.

 IOCHECK and Run-Time Error Numbers
    If the IOSTAT option is set and an error or end-of-file occurs at
 run time, the "iocheck" variable is set to the number of the run-time
 error. For example, if the following READ statement encounters an
 end-of-file

    READ(1,'(I5)',IOSTAT=IER) JUNK

 the IER variable is set to 6501, the number of the run-time error for
 an end-of-file condition.

 The END= Option with Direct-Access Files
    The END= I/O option can be specified along with the REC= I/O
 option in I/O statements.


 248. FORTRAN 4.10 README.DOC: New and Changed Compiler Features

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28810

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Compiler -- Underscores (_) in Variable Names
    The underscore (_) can be used in variable names, as long as it is
 not the first character of a name.

 Character-Assignment Statements
    In a character-assignment statement, the variable to the left of
 the equal sign (that is, the variable having a value assigned to it)
 cannot appear as part of the character expression to the right of the
 equal sign (that is, the expression being assigned). For example, the
 following statement gives undefined results:

       var = varp // var

 The FUNCTION Statement
    In FUNCTION statements, the length specifier for the function type
 may follow the function name. For example, the following two
 declarations are equivalent:

       INTEGER*4 FUNCTION X(A)

       INTEGER FUNCTION X*4(A)

 Limits on Assigned-GOTO Statements
    The compiler limit on assigned-GOTO statements has been raised from
 64 per subroutine to 256 per subroutine.

 The PAUSE Statement
    If a string argument follows the PAUSE statement, then on output
 the argument appears without the "Pause" and the pause message. If a
 digit argument follows the PAUSE statement, then on output the "Pause"
 appears, followed by the digit. The following examples illustrate
 PAUSE statements and the messages that the statements display:

 C   EXAMPLE 1:  PAUSE STATEMENT WITH NO ARGUMENT

       PAUSE

 Pause - Please enter a blank line (to continue) or a DOS command.

 C   EXAMPLE 2:  PAUSE STATEMENT WITH STRING ARGUMENT

       PAUSE 'hit return to continue'

 hit return to continue

 C   EXAMPLE 3:  PAUSE STATEMENT WITH DIGIT ARGUMENT

       PAUSE 1

 Pause - 1


 249. Colon Required between the $NOTLARGE and Following Identifiers

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 19-SEP-1988    ArticleIdent: Q10538

 Problem:

 The following code sample generates the error message "Error 824 --
 $large already set":

 $LARGE $NOTLARGE A,B
    DIMENSION A(10),B(10)
    END

 Response:

 Contrary to Page 73 of the "Microsoft FORTRAN Compiler User's Guide,"
 a colon is required between the $NOTLARGE and the identifiers that
 follow it. When the colon is missing, the identifiers are ignored and
 an error is generated. The above code should be changed to the
 following:

 $LARGE $NOTLARGE: A,B
    DIMENSION A(10),B(10)
    END


 250. Cannot Detect End of File

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q10539

 Problem:

 I am unable to detect end-of-file for direct access files.

 Response:

 Page 81 of the "Microsoft FORTRAN Compiler Reference" manual
 incorrectly states ENDFILE works when linked with the DOS2FOR library.

 The file-handling methods under DOS Versions 1.x cannot work with
 direct-access files. However, you can detect end-of-file for direct
 access files if you link with the DOS2FOR library that uses DOS
 Versions 2.x file-handling methods.


 251. FORTRAN 4.10 README.DOC: OS/2 Calls from FORTRAN

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER Doscalls API system
 Last Modified: 30-OCT-1990    ArticleIdent: Q28811

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 OS/2 Calls from FORTRAN
    OS/2 functions can be called from FORTRAN as integer functions.
 The fragment below shows how to call the OS/2 function VioGetMode (the
 sample program SORTDEMO.FOR contains numerous examples of OS/2 calls):

 $NOTRUNCATE
         INTERFACE TO INTEGER*2 FUNCTION VioGetMode
      +  [ALIAS:'VIOGETMODE']
      +  (MODE, VioHandle [VALUE])
         INTEGER*2 MODE(6), VioHandle
         END

         IMPLICIT INTEGER*2 (A-Z)
         DIMENSION MODE(6)
         .
         .
         MODE(1)=12
         RetVal=VioGetMode(MODE,0)
         MAXCOLOR=2**ISHL(MODE(2),-8)
         .
         .
         END

 Declaring OS/2 Functions
    To call an OS/2 function, you must first declare the function using
 an INTERFACE statement. The INTERFACE statement declares the function
 type and the number and type of the function's arguments. All OS/2
 functions are declared as INTEGER*2 functions because they return a
 single two-byte value (see below).
    Because OS/2 function names are usually longer than the normal
 FORTRAN limit of six characters, you must use the ALIAS attribute, the
 $NOTRUNCATE metacommand, or both. If you change the OS/2 function name
 to fit in six characters, you must use the ALIAS attribute to make the
 link between your program's name for the function and its actual OS/2
 name. If you use the $NOTRUNCATE metacommand, you may omit the ALIAS
 attribute because $NOTRUNCATE ensures that FORTRAN accepts up to 31
 characters for a variable or procedure name.
    To determine the number and type of the OS/2 function's arguments,
 look up the function in the MS OS/2 Programmer's Reference and use the
 tables on pages 280-293 in the Microsoft FORTRAN Optimizing Compiler
 User's Guide to find the FORTRAN data type corresponding to the C data
 type in the function call. Notice that you must use the VALUE
 attribute in the INTERFACE statement for any OS/2 function argument
 that is not a pointer.
    Some OS/2 function calls take the address of a structure as an
 argument. Because FORTRAN does not have a structure or record data
 type, you must use an integer array to simulate the structure. In the
 example above, the VioGetMode function uses a twelve-byte structure,
 so MODE is declared as a six-element array of two-byte words. MODE
 could also have been declared as a twelve-element array of INTEGER*1.
    If you emulate a structure using an INTEGER*1 array and the
 structure contains word fields, or you use an INTEGER*2 array and the
 structure contains byte fields, your program will need to do some
 extra work to access the fields. You can use bit-manipulation
 functions or equivalenced arrays to get at byte fields in word arrays
 or word fields in byte arrays.
    See pp. 90-92 in the Microsoft FORTRAN Optimizing Compiler Language
 Reference for information about FORTRAN's bit-manipulation functions.
 Notice that if you use an INTEGER*1 array and the structure contains
 word fields, you'll use the bit functions to combine array elements.
 Similarly, if you use an INTEGER*2 array and the structure contains
 byte fields, you'll need to use the bit functions to manipulate the
 byte fields.
    Because bytes in a two-byte integer are stored in reverse order,
 you must be careful to select the correct byte when breaking down
 two-byte integer values.  For example, the twelve-byte structure used
 with VioGetMode begins with a word value followed by two one byte
 values: type and color. In the example above, the two one-byte fields
 are treated as a single integer, so color winds up in the high-order
 byte and type is the low-order byte. So, to get the value of color
 (the high-order byte of MODE(2)), you must shift MODE(2) right by
 eight bit positions.
    You can avoid doing bit manipulation by using the EQUIVALENCE
 statement. The following segment shows the fragment above rewritten
 to avoid bit manipulation:

 $NOTRUNCATE
         INTERFACE TO INTEGER*2 FUNCTION VioGetMode
      +  [ALIAS:'VIOGETMODE']
      +  (MODE, VioHandle [VALUE])
         INTEGER*2 MODE(6), VioHandle
         END

         IMPLICIT INTEGER*2 (A-Z)
         DIMENSION MODE(6)
         INTEGER*1 BMODE(2),Color,Type
         EQUIVALENCE (BMODE(1),MODE(2)),(BMODE(1),Type),(BMODE(2),Color)
         .
         .
         MODE(1)=12
         RETVAL=VioGetMode(MODE,0)
         MaxColor=2**Color
         .
         .
         END

    The EQUIVALENCE statement equates the start of the two-element
 INTEGER*1 array, BMODE, to the two one-byte fields in the MODE
 structure. The statement then equates two INTEGER*1 variables to the
 individual byte fields. Notice that when you use an EQUIVALENCE
 statement this way, you do not have to worry about reversed bytes.
    NOTE: OS/2 calls assume that all arguments passed by reference are
 passed as far references. Thus, if you use medium memory model (which
 uses near references), you must use the FAR attribute with any
 arguments that are passed by reference.

 Return Values
    The value returned by an OS/2 function indicates whether or not
 there was an error. A return value of zero indicates there was no
 error; any other value indicates an error. See the Microsoft OS/2
 Programmer's Reference for information about specific error values.

 Thread Restrictions
    Because FORTRAN library routines are not reentrant, FORTRAN
 routines that use any of the OS/2 functions involving threads or
 requiring reentrancy cannot use FORTRAN library routines. The OS/2
 functions that use multiple threads or require reentrancy include the
 following:

 DOSCREATETHREAD
 DOSRESUMETHREAD
 DOSSUSPENDTHREAD
 DOSSETSIGHANDLER
 DOSSETVEC
 DOSMONOPEN
 DOSMONCLOSE
 DOSMONREAD
 DOSMONWRITE
 DOSMONREG

    You may be able to write routines using these OS/2 functions and
 FORTRAN library routines if your program provides a way for each
 routine to test whether or not another routine is using the library
 routines. Or, you may want to write your own reentrant library
 routines. (This is an advanced technique that Microsoft does not
 support.)


 252. FORTRAN 4.10 README.DOC: Corrections to Documentation

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28812

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 CORRECTIONS TO DOCUMENTATION -- Version 4.10 Update

 LIBBUILD under Protected-Mode OS/2
    To use the LIBBUILD.BAT batch file under protected-mode OS/2,
 change the file's name to LIBBUILD.CMD.

 Additional Error Messages
    There are two new command line messages:

    Number  Message                      Description

    D2025   missing argument             A required argument was omitted
                                         from the option. Check the syntax
                                         of the option. This is an error
                                         message.

    D4019   string too long - truncated  A string of more than 40 characters
            to 40 characters             was specified for one of the followin
                                         switches: /NM, /NT, /St, or /Ss.
                                         The string is truncated to 40
                                         characters, and FL continues. This
                                         message is a warning.

    There is one new compiler warning message:

    F4186    string too long - truncated  A string of more than 40 characters
             to 40 characters             was used in a $TITLE or $SUBTITLE
                                          metacommand. The string is truncated
                                          to 40 characters.

 User's Guide -- Defining Macros for MAKE
    Section 6.7.1 states that macro definitions that include white
 space should be enclosed in double quotes. This statement is true only
 for macros defined on the MAKE command line. Macros with white space
 in MAKE description files should not be enclosed in double quotes.

 Quick Reference Guide
    In the Microsoft FORTRAN Optimizing Compiler Quick Reference Guide,
 the /Tf option of the FL command is misspelled as "/TF".


 253. FORTRAN 4.10 CVREADME.DOC: Mouse Driver

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28815

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 CVREADME.DOC -- (C) Copyright Microsoft Corporation, 1987, 1988
 Microsoft(R) FORTRAN Optimizing Compiler Version 4.10

 Notes on CodeView and Utilities -- The Mouse Driver
    If you will be using the Microsoft Mouse with the Microsoft
 CodeView debugger you must have Version 6.01 or later of the Microsoft
 Mouse. If you do not, use the version of the MOUSE.COM driver provided
 in this package. Copy MOUSE.COM to the appropriate mouse directory.
 When you are ready to use the mouse, type

         mouse

 at the DOS command level. If you want to install the mouse driver
 automatically every time you reboot, insert the "mouse" command in
 your AUTOEXEC.BAT file.
    Note that in earlier releases of Microsoft C, both the MOUSE.SYS
 and the MOUSE.COM driver were provided. If you have been using an
 earlier version of the MOUSE.SYS driver, delete the following line
 from your CONFIG.SYS file:

         device=\<directory>\mouse.sys

 where <directory> is the directory where the earlier mouse driver
 resides.


 254. FORTRAN 4.10 CVREADME.DOC: New Command-Line Option

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28816

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft CodeView(R) Debugger -- New Command-Line Option
    If you have an IBM Personal System/2, then you can use the /50
 command-line option to start the CodeView debugger in 50-line mode.
 Note that you must be in 25-line mode to effectively use either the
 /43 or /50 command-line option.


 255. FORTRAN 4.10 CVREADME.DOC: CONFIG.SYS Setting for CVP

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28817

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 CONFIG.SYS Setting for CVP
    To run the protected-mode CodeView debugger (CVP.EXE), you must
 have the following line in your CONFIG.SYS file:

    IOPL=YES


 256. Complex Division

 Product Version(s): 3.2
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR02493 buglist3.20 fixlist3.30
 Last Modified:  8-MAR-1988    ArticleIdent: Q10633

 Problem:
    Contrary to the documentation, the negative range of double
 precision complex numbers is 1X10**-154. Attempts to use greater
 negative numbers results in a real math overflow at runtime.

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
   The problem was corrected in Version 3.30.


 257. FORTRAN 4.10 CVREADME.DOC: CodeView Demonstration

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28818

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft CodeView(R) Debugger Demonstration
    The demonstration runs only under MS-DOS or real-mode OS/2. You
 must compile the program STATS.FOR before you can run the CodeView
 demonstration. Compile the program using the following command and
 place the EXE file in the same directory as the other demonstration
 files:

    FL /AM /FPc /Zi /Od STATS.FOR


 258. FORTRAN 4.10 CVREADME.DOC: IMAG and AIMAG

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28819

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 IMAG and AIMAG Intrinsic Functions
    The Microsoft CodeView(R) debugger considers the IMAG and AIMAG
 functions to be synonymous (it extracts the imaginary part of the
 complex number).

 Using the 7 Command in Protected Mode
    If you are using OS/2 protected mode and have a math coprocessor,
 then you need to use a patch before you can use the CVP 7 command. To
 apply the patch, use the OS2PATCH.EXE and PTRACE87.PAT files that come
 on the same disk that CVP.EXE is on. You also need to locate the
 PATCH.EXE file that comes with OS/2 and make sure that this file is in
 a directory listed in your PATH environment variable. Then follow
 these steps:

    1. Change the current drive and directory to the root directory of
 the boot disk. (If the boot disk is a floppy, make sure it is inserted
 in the drive you used to boot from.)
    2. Give the following command line at the DOS prompt:

    OS2PATCH /A PTRACE87.PAT

    Note that you may need to give the complete path names for the
 OS2PATCH.EXE and for the PTRACE87.PAT file. You do not need to give a
 path name for the OS2PATCH.EXE file if you have placed this file in a
 directory listed in your PATH environment variable.


 259. FORTRAN 4.10 CVREADME.DOC: Compatibility Box

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28820

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Using the Real-Mode Debugger in the Compatibility Box
    When running the real-mode CodeView debugger in the DOS 3.x
 compatibility box, start the debugger with the /S command-line option.
 Otherwise, the mouse pointer will not appear.


 260. FORTRAN 4.10 CVREADME.DOC: Codeview with BIND

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28821

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Using the CodeView Debugger with BIND
    The real-mode CodeView debugger cannot debug bound (dual-mode)
 applications. However, the protected-mode CodeView debugger, CVP, can
 debug bound applications.


 261. FORTRAN 4.10 CVREADME.DOC: BASIC Programs with CodeView

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28822

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Compiling BASIC Programs for CodeView Debugger
    To compile BASIC programs for use with the CodeView debugger,
 specify the /Zi option rather than the /D option.

 Expression Evaluator for BASIC Programs
    In the BASIC expression evaluator, "+" is not supported for string
 concatenation.


 262. Problems Reading an Array in Version 3.20

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified:  7-OCT-1988    ArticleIdent: Q10659

 Problem:

 Array reads that read the entire array do not function correctly if
 the array crosses a 64K boundary in a particular way. In the program
 below, support "array" is more than 64K in length, and "barray" is
 equivalenced to array so that barray crosses the 64K boundary in
 array. Reading barray with READ() (barray(i),i=1,dim) works properly,
 but READ()barray fails.

 The following is an example:

         integer*4 array(20000)
         integer*4 barray(2000)
         equivalence(array(16001),barray)
 c
 c
         write(*,*)' writing data'
         open(6,file='data',status='new',form='unformatted')
         write(6)(i,i=1,2000)
 c
 c
         write(*,*)' reading data'
         rewind(6)
         read(6)barray
 c
         ierr=0
         do 10 i=1,2000
         if (barray(i).eq.i) goto 10
         write(*,*)i,barray(i)
         ierr=ierr+1
         if (ierr.eq.10) goto 11
    10   continue
    11   write(*,*)' done checking implicit read'
 c
 c
         write(*,*)' reading data'
         rewind(6)
         read(6)(barray(i),i=1,2000)
 c
         ierr=0
         do 20 i=1,2000
         if (barray(i).eq.i) goto 20
         write(*,*)i,barray(i)
    20   continue
         write(*,*)' done checking explicit read'
         end

 Response:

 The reported behavior was due to an arithmetic overflow in the huge
 array I/O routines.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.


 263. FORTRAN 4.10 CVREADME.DOC: Error Message

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28823

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Error Messages
    The error message "? cannot display" indicates that the Display
 Expression command (?) has been passed a valid symbol that it cannot
 display. In previous versions of the debugger, structures could not be
 displayed. With current version of the debugger, only the enums type
 cannot be displayed.
    The error message "Expression not a memory address" occurs when the
 Tracepoint command is given without a symbol that evaluates to a
 single memory address. For example, the commands "TP?1" and "TP?a+b"
 each produce this error message. The proper way to put a tracepoint
 on the word at address 1 is with the command "TPW 1".
    The error message "Function call before 'main'" occurs when you
 attempt to evaluate a program-defined function before you have entered
 the main function. Execute to at least to the beginning of the main
 function before attempting to evaluate program-defined functions.
    The error message "Bad emulator info" occurs when CodeView cannot
 read data from the floating-point emulator.
    The error message "Floating point not loaded" has a special meaning
 for CVP (in addition to the explanation given in the CodeView and
 Utilities manual). Each thread has its own floating-point emulator.
 This message is issued when the current thread has not initialized its
 own emulator.


 264. Internal Compiler Error: getattrib.c 1.41, Line 170

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q29588

 An incorrectly written program causes the following error message to
 appear:

    fatal error F1001:  Internal Compiler Error
    (compiler file '@(#)getattrib.c:1.41', line 170)
    Contact Microsoft Technical Support

 The following program causes this error:

         SUBROUTINE SUB1(X)
         COMMON Y
         RETURN
         ENTRY SUB2(Y)
         RETURN
         END

 This problem can be avoided by changing the first line to the
 following:

         SUBROUTINE SUB1

 This is a known problem in Versions 4.00, 4.01, and 4.10. This
 problem was corrected in Version 5.00 under MS-DOS. However, the
 compiler gives a general protection violation in OS/2.


 265. Incorrect Integer Arithmetic with /Ot Optimization

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q29594

 The small program below demonstrates an optimization problem with
 integer calculation. The program contains about 15 COMMON variables.
 In subroutine TESTR, the following line is evaluated incorrectly:

    IST=KS+2*IS-2

 The line should evaluate to 143=141+2*2-2; however, it evaluates to
 163.

 To work around the problem, do the following:

 1. Disable the optimization with compiler option /Od.

 2. Delete any of the four statements after the COMMON statement in
    TESTR. (Note that none of these four lines changes any variables
    used in the calculation of IST.)

 3. Make the COMMON variables local variables.

 Microsoft has confirmed this to be a problem in Versions 4.00, 4.01,
 and 4.10 of the FORTRAN compiler. This problem was corrected in
 Version 5.00.

 The following program demonstrates the problem:

 C   PROGRAM TO TEST INTEGER CALCULATION FAILURE
       IMPLICIT REAL*8(A-H,O-Z)
       COMMON/TSTCOM/IPT,NU,NV,NPTS,MX,NX,KF,KS,KT,KNT,NPCH,LF,LS,LT,IND
       AVE = 0.0D0
       IX = 1
       KF = 1
       IS = 2
       KS = 141
       NU = 11
       NV = 7
       NX = 12
       CALL TESTR (IX,IS)
       END

       SUBROUTINE TESTR (IX,IS)
       IMPLICIT REAL*8(A-H,O-Z)
       COMMON/TSTCOM/IPT,NU,NV,NPTS,MX,NX,KF,KS,KT,KNT,NPCH,LF,LS,LT,IND
 C
 C************* IF ANY OF THE FOLLOWING 4 LINES IS OMITTED, COMMON IS
 C************* REMOVED AND VARIABLES MOVED TO LOCAL VARIABLES IN THIS
 C************* PROGRAM OR IF THE ROUTINES ARE COMPILED USING MICROSOFT
 C************* FORTRAN 3.20, THE VARIABLE "IST" IS CORRECTLY COMPUTED
 C************* AS 143.  IF THIS ROUTINE AND THE MAIN PROGRAM ARE USED
 C************* AS SHOWN HERE "IST" IS SET TO 163.
       IFT=IS
       IST=KF+2*IS-2
       IF(IX.EQ.2) GOTO 20
       IFT=(IS-1)*NU+1
 C*************
       WRITE(*,18)KS,IS
    18 FORMAT(' KS =',I4,', IS =',I3)
       IST=KS+2*IS-2
       WRITE(*,19)IST
    19 FORMAT(' IST =',I4)
    20 RETURN
       END


 266. Run-Time Error 2101

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10635

 Problem:
    The following program generates run-time error 2101:

    complex c1
    do 100 i=1,100
    c1 = cmplx (10.0**i,10.0**i)
    write (*,*) i,csqrt(c1),cabs(c1) 100 continue
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 267. ERRORLEVEL Flag Not Set to Attempted Compilation

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10639

 Problem:
    The compiler does not set the ERRORLEVEL flag according to the
 results of the attempted compilation.

 Response:
    This problem was corrected in Version 3.30.


 268. Formal Parameters Greater than 64K

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10640

 Problem:
    Formal parameters greater than 64K give specification errors if
 preceded by other formal parameters of particular byte sizes.
    It appears that 0-byte and 8-byte offsets are correct, but 4-byte
 and 12-byte offsets give an error.

 Response:
   Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
   This problem was corrected in Version 3.30.


 269. Invoking PAS2 from a Batch File

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10653

 Problem:
    A problem may occur when invoking PAS2 from a batch file. If there
 are any trailing blanks following the command "PAS2", PAS2 requests a
 RETURN before continuing.

 Response:
    Micorsoft confirmed this to be a problem in Version 3.2 of the
 FORTRAN compiler.
    This problem was corrected in Version 3.30.


 270. OPEN Statement Required or System Will Stop

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q10669

 Problem:
    Under the following conditions, an OPEN statement is required or
 the system will stop:

    1. Using Northstar Advantage.
    2. Running DOS Version 1.10.
    3. Using unit 0 rather than the * for console.

 Response:
    Microsoft is unable to duplicate this problem under DOS Versions
 1.00 or 2.00.


 271. Compile Error 835

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 13-JAN-1989    ArticleIdent: Q10663

 Problem:

 The example of SAVE on Page 119 of the "Microsoft FORTRAN Reference"
 manual produces compiler error 835 in pass 1 of the compiler (FOR1).
 The following program demonstrates this problem:

    integer*4 myvar
    common /mycom/ n
    save /mycom/, myvar
    end

 Response:

 Microsoft has confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 272. $DEBUG Metacommand

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10644

 Problem:
    The following program gives the run-time error "long integer math
 overflow" when compiled with $DEBUG, but runs properly without the
 metacommand:

    $DEBUG
       PROGRAM TEST
       INTEGER*4 IX

       X=327.64
       IX=32780

       DO 10 J=1,10
       IX=(X*100)
       WRITE(*,*)IX,X
      10 X=X+.01

       END

 Response:
    This problem was corrected in Version 3.30.


 273. Implied DO Loops on READ Statements

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10643

 Problem:
    READ statements with implied DO loops are always executed at least
 once. This is not the case with explicit DO loops or WRITE statements
 with implied loops.

 Response:
    This is correct behavior for READ statements.
    The ANSI Standard says the statement 'READ(*,*) (I,J=1,0)' should
 behave the same as a READ(*,*).
    An implied DO loop in a READ is not equivalent to a real DO loop
 containing a READ.


 274. SP Edit Descriptor

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10668

 Problem:

 The SP edit descriptor does not function correctly. It fails to put in
 plus (+) signs for positive numbers and negative numbers are
 incorrectly changed to positive. The following is a code sample that
 demonstrates this behavior:

        do 10 i1=-10,10,2
        write(*,100) i1,i1,i1
  10    continue
  100   format(' ',i3,' ',sp,i3,' ',i3)
        end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 275. READ to Unit 1

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified:  2-MAY-1988    ArticleIdent: Q10661

 Problem:
    A program opens the console as logical unit 1 in the main program.
 A subsequent "READ(1," in a subroutine fails to read any data from the
 keyboard. When the "READ (1," is replaced by a "READ (0," the program
 works properly.

 Response:
    The READ statement to unit 1 is correctly taking the error path
 because you cannot read from a unit to which you have just written
 without first doing a Rewind and BACKSPACE. You cannot rewind the
 console.
    One method to achieve your goal is to READ and WRITE from different
 units both connected to CON.


 276. Run-Time Error "Real Indefinite"

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified:  7-OCT-1988    ArticleIdent: Q10637

 Problem:

 DREAL(IMAG*16) compiles without error but gives the run-time error
 "Real Indefinite". The following is a short code example that
 demonstrates this problem:

 PROGRAM TEST COMPLEX*16 A REAL*8 X,Y

 A=DCMPLX(-.121E+04,.406E+04) WRITE(*,'(3H A=,2E10.3)')A
 X=DIMAG(A) WRITE(*,'(10H DIMAG(A)=,E10.3)')X Y=DREAL(A)
 WRITE(*,'(10H DREAL(A)=,E10.3)')Y

 END

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 277. Run-Time Error 1232

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20
 Last Modified: 20-OCT-1988    ArticleIdent: Q10627

 Problem:

 A BLOCK DATA subprogram following the main program in a source file
 generates a run-time error 1232. The following program demonstrates
 the problem:

        program tstblk
        common /tst/i
        write (*,1)i 1 format (' ',i10)
        stop
        end
        block data
        common /tst/i
        data i/5/
        end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.

 The workaround to this problem is to place the BLOCK DATA first in the
 source file or compile separately.


 278. AIMAG of a Complex Function

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10625

 Problem:

 If the intrinsic function AIMAG is passed to a complex function as an
 argument, incorrect results are returned. The following program
 demonstrates the problem:

        program oct03b
        complex func2,zz
        zz = (1111.,2222.)
        write (*,*) aimag (func2 (zz))
        end
        complex function func2 (yy)
        complex yy
        func2 = (1111.,2222.)
        end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 279. Array Greater Than 64K

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q10671

 Problem:

 Arrays are not always accessed correctly if they are greater than 64K
 and the subscript to the array is an expression that references the
 array itself. The following is a code sample that demonstrates this
 behavior:

        PROGRAM TEST
        DIMENSION IA(20000)
        DIMENSION IB(10)

        WRITE(*,'(12H LENGTH >64K)')
        DO 15 I=1,10
        IA(I)=I 15 WRITE(*,*)I,IA(I),IA(IA(I))

        WRITE(*,'(12H LENGTH <64K)')
        DO 18 I=1,10
        IB(I)=I 18 WRITE(*,*)I,IB(I),IB(IB(I))
        END

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. The problem was corrected in Version 3.30.


 280. Setting the Direction Flag with MASM

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10664

 Question:
    Setting the direction flag with an assembly language routine may
 cause the subsequent I/O operation to fail. The following source files
 demonstrate the problem:

    program dftst
    x = 1.2
    write(*, 100) 100 format(' Before direction flag has been set')
    write(*,*) x
    call dirflg
    write(*, 200) 200 format(' After direction flag has been set')
    write(*,*) x
    end

 data segment public 'data' data ends ; dgroup group data ; code segment 'code
    ASSUME CS:code, ds:dgroup, ss:dgroup
    public dirflg dirflg proc far
    std
    ret dirflg endp code ends
    end

 Response:
    The workaround for this problem is to link with DOS2FOR.


 281. Pas2 Hangs If Call Precedes Function Declaration

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10657

 Problem:
    If a function call precedes a function declaration, the compiler
 PAS2 hangs. If the function declaration precedes the call, the code is
 correctly flagged with the error message "subroutine name expected."
    The following small-code sample demonstrates this problem:

    PROGRAM A
    CALL I
    END

    FUNCTION I
    I=0
    RETURN
    END

 Response:
    Microsoft has confirmed this to be a problem in the FORTRAN
 Compiler Version 3.20.
    The problem was corrected in Version 3.30.


 282. Compile Error 84 "FUNCTION Type Conflict"

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10651

 Problem:
    The compiler generates an error 84 "FUNCTION type conflict" if an
 implicitly typed INTEGER function contains an IMPLICIT INTEGER*2
 declaration. The following program demonstrates the problem:

    function nvalue (nvar,mxcol,str)
    implicit integer*2 (a-z)
    real*4 fr
    dimension nvar(8,8),nfval(8,8),str(8,8),kpl(2)
    common fr
    mycol = 3 - mxcol
    do 1 i=1,8
    do 1 j=1,8 1 nfval(i,j)=0
    do 50 i=1,8
    do 50 j=1,8
    if (nvar(i,j).ne.0) nfval(i,j)=
    + ntot(i,j,nvar(i,j),nvar,str) 50 continue
    kpl(1)=0
    kpl(2)=0
    do 80 i=1,8
    do 80 j=1,8
    if (nvar(i,j).ne.0) kpl(nvar(i,j)) = kpl(nvar(i,j)) +nfval(i,j) 80 continu
    nvalue= kpl(mxcol) - kpl(mycol)
    if (kpl(mycol).eq.0) nvalue=nvalue + 500
    return
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    The problem was corrected in Version 3.30.


 283. Internal Error 828

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10648

 Problem:
    Pass one of the compiler (FOR1) generates an internal error 828.
 This occurs if the formal parameter of a subroutine is used as an
 index variable in a READ statement with an implicit DO. The following
 program demonstrates this problem:

    SUBROUTINE EXAMPLE(I)
    DIMENSION A(80)

 C EXPLICIT DO LOOP WORKS FINE
    DO 10 I=1,10
    10 CONTINUE

 C IMPLICIT DO LOOP WORKS FINE IF VAR IS NOT FORMAL PARAMETER
    READ(*,*)(A(J),J=1,79)

 C IMPLICIT DO LOOP FAILS IF VAR IS FORMAL PARAMETER OF SUBROUTINE
    READ(*,*)(A(I),I=1,79)

    RETURN
    END

 Response:
    Microsoft has confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. The problem was corrected in Version 3.30.


 284. Initialization of a Huge Array

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 24-OCT-1988    ArticleIdent: Q10645

 Problem:
    When using the Microsoft FORTRAN Compiler Version 3.20,
 initialization of a huge character array fails at the 64K boundary.
    In the following example, program arry(65336) is not initialized to
 "A":

    program arrytst
    character arry(100000)
    integer*4 n, nerr
    data arry / 100000 * 'A'/
    nerr = 0
    do 200 n = 1, 100000
    if (arry(n) .ne. 'A') then
    nerr = nerr + 1
    write(*,100) n, arry(n) 100 format(' ERROR! arry(',i7,') = ',a1)
    endif 200 continue
    if (nerr .eq. 0) then
    write(*,300) 300 format(' No errors occurred!')
    endif
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    This problem was corrected in FORTRAN Compiler Version 3.30.


 285. Symbol Defined More Than Once

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10620

 Problem:
    The following program specifies an external procedure IFRED. When
 linked with another module that defines IFRED, the linker generates
 the error "symbol defined more that once."
    The following program will produce this error:

    program darilek
    integer n(3)
    real pp,qq,r(100),pdif(6),rel,rels,er,ermax
    real vrince,xnr
    real ax,ans,zero,one,two,five
    double precision dseed,dzero,seed(2),sum,temp,amean
    external ifred
    i = 1
    call sub(ifred,i)
    write(*,*) i
    stop
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    This problem was corrected in FORTRAN Compiler Version 3.30.


 286. $Large Metacommand and Subroutines

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10622

 Problem:
    In the following example, the array "siwork" is not being
 recognized as a large array:

 $large
    subroutine fred(siwork)
    integer*2 siwork(1)
    write (*,*) siwork(33333)
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    The problem was corrected in Version 3.30.


 287. Read from * Causes Triple Space Rather Than Double Space

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified:  6-MAY-1988    ArticleIdent: Q10624

 Problem:
    A read from "*" causes a subsequent write to "*" to triple-space
 rather than double-space.
    The following is a short code sample that demonstrates the problem:

    character*1 ina(73)
    write(*,'(a)') ' Reference line.'
    read(*,'(73a1)')ina
    write(*,'(a)') '0< Using "0" here, double space gives triple'
    write(*,'(a)') '0double spaced.'
    write(*,'(a)') '0double spaced'
    end

 Response:
    Microsoft has confirmed this to be a problem in the FORTRAN
 Compiler Version 3.20.
    The problem was corrected in Version 3.30.


 288. DREAL Functions Used in Double Complex

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10636

 Problem:
    Pass one of the compiler (FOR1) generates "compile time error 87"
 when processing a DREAL function used as an argument for a DCMPLX.
    The following program demonstrates this behavior:

       complex*16 x, y
       x = (0.0d0, 0.0d0)
       y = dcmplx(dreal(x), 0.0d0)
       stop
       end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    This problem was corrected in Version 3.30.


 289. INT Function Producing Incorrect Answer

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q10647

 Problem:

 The function INT produces an incorrect answer if given a mixed-mode
 expression. The following code sample returns the value 94 (it should
 return the value 95):

        s = .95
        n = 100
        i = int (n*s)
        write (*,*) s,n,i
        x = n*s
        j = int(x)
        write (*,*) x,j
        end

 Response:

 This is not a problem with the compiler. The different values in the
 above example are obtained because, in the first case, truncation
 occurs after the value has been rounded to an 80-bit representation of
 the expression 100 * .95. In the second case, truncation occurs after
 the value has been rounded to a 32-bit representation.


 290. LEN Function

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-OCT-1988    ArticleIdent: Q10667

 Problem:

 The FORTRAN intrinsic LEN is missing from this version of the
 compiler; however, it will compile and link without error if you use
 the LEN function in a program. The result from the LEN function is
 always 538976288. The following is a code sample that demonstrates
 this behavior:

        character*20
        alphaline = 'This is a test'
        i = len(alphaline)
        write (*,10) i
 10     format (1x,i16)
        end

 Response:

 The LEN intrinsic function is not supported in this version of the
 compiler. However, the LEN intrinsic function was implemented in a
 peculiar manner in that the front end recognizes the LEN as an
 intrinsic, but generates incorrect code. In Version 3.30, LEN is not
 recognized at all. In Version 4.00, LEN is fully supported.


 291. FORTRAN Version 4.10 README DOC: Pascal Programs

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-JAN-1989    ArticleIdent: Q28824

 The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Pascal Programs

 In this release, Microsoft Pascal programs cannot be debugged with the
 CodeView debugger. However the Pascal 4.00, just released, does have
 CodeView support.

 The Pascal example on Page 61 of the Microsoft CodeView and Utilities
 manual should read

 PAS1 /Z TEST;

 rather than

 PAS1 /Zi TEST;

 Although, the PL driver does use the "/Zi" switch.


 292. FORTRAN 4.10 CVREADME.DOC: Overlay Restrictions

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28825

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Overlay Restrictions
    You cannot use long jumps (using the longjmp library function) or
 indirect calls (through a function pointer) to pass control to an
 overlay. When a function is called through a pointer, the called
 function must be in the same overlay or in the root.


 293. FORTRAN 4.10 CVREADME.DOC: Library Manager

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28826

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Library Manager (LIB) -- New Option
    There is a new option for LIB: /NOIGNORECASE (abbreviated as /N).
 This option tells LIB to not ignore case when comparing symbols.
 names. By default, LIB ignores case. Multiple symbols that are the
 same except for case can be put in the same library. An example of
 this is: "_Open" and "_open". Normally you could not add both these
 symbols to the same library.
    Note that if a library is built with /NOI, the library is
 internally "marked" to indicate /NOI. All libraries built with
 earlier versions of LIB are not marked.
    If you combine multiple libraries, and any one of them is marked
 /NOI, then /NOI is assumed for the output library.
    In addition, LIB also supports the option /IGNORECASE (/I), which
 is completely analogous to /NOIGNORECASE. /I is the default. The only
 reason to use it would be if you have an existing library marked /NOI
 that you wanted to combine with other libraries which were not marked,
 and have the output library be not marked. If you don't use
 /IGNORECASE, the output is marked /NOI (see above).

 Changed LIB Error Messages
    Warning messages U4152, U4155, and U4157-U4159 for LIB are now
 nonfatal error messages U2152, U2155, and U2157-U2159, respectively.
    Warning message U4151 has been changed to read as follows:

    U4151   '<name>' : symbol defined in module <name>,
                            redefinition ignored

 New LIB Error Messages
    The following new warning messages have been added for LIB:

    U4155   <modulename> : module not in library

    A module specified to be replaced does not already exist in the
 library. LIB adds the module anyway.

    U4157   insufficient memory, extended dictionary not created
    U4158   internal error, extended dictionary not created

    For the reason indicated, LIB could not create an extended
 dictionary. The library is still valid, but the linker is not able to
 take advantage of the extended dictionary to speed linking.


 294. FORTRAN 4.10 CVREADME.DOC: ILink Warning Messages

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q28827

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 ILINK Warning messages

    Fixup frame relative to an (as yet) undefined symbol - assuming ok
 See documentation for LINK error messages L4001 and L4002, in the
 Microsoft CodeView and Utilities manual.

    <name> contains TYPEDEFs - ignored
    <name> contains BLKDEFs - ignored
    The .OBJ file contains records no longer supported by Microsoft
 language compilers.
    Old .EXE free information lost The free list in the .EXE file has
 been corrupted. The free list keeps track of "holes" of free space in
 the EXE file. These holes are made available when segments are moved
 to new locations.
    File <name> has no useful contribution The given module makes no
 contribution to any segment.
    Main entry point moved The program starting address changed. You
 may want to consider doing a full link.


 295. FORTRAN 4.10 Patch README.DOC: IBM PC-DOS 3.20

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28828

    The following information is from the FORTRAN Version 4.10 Patch
 README.DOC file:

    There is a bug in IBM PC-DOS 3.20 which may cause improper
 operation of a program if a floating point exception is generated.
 This patch to IBM PC-DOS 3.20 is provided to insure proper operation
 of programs which may generate floating point exceptions. In
 particular, the C runtime routine signal with the SIGFPE parameter
 does not work with the unpatched version of IBM PC-DOS 3.20. IBM has
 also made a patch for this problem available.
    Procedure for patching IBM PC-DOS 3.20:

    1. Use the DOS sys command to transfer IBMDOS.COM and IBMBIO.COM to
 a writable diskette.
    2. Copy command.com, sys.com and debug.com from your IBM DOS 3.20
 diskette to the new diskette.
    3. Copy stkpat.bat, stkpat.scr, rmrhs.exe and setrhs.exe from the
 \patch directory to the new diskette.
    4. Reboot the system from the new diskette.
    5. Run stkpat.bat. This patches the IBMBIO.COM on the new diskette.
    6. Use the DOS sys command to transfer the patch to any other IBM
 PC-DOS 3.20 diskette.

    If you are running any version of DOS 3.20 other than IBM PC-DOS
 3.20, contact your hardware manufacturer (OEM) to find out if the
 problem exists in your DOS 3.20 version.


 296. FORTRAN 4.10 CVREADME.DOC: Stack Trace Command

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28829

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Stack Trace Command
    In order for the Stack Trace command (or the Calls menu) to work
 reliably, you need to execute to at least the beginning of the main
 function or procedure, and the current module should have full
 CodeView information (a module has full CodeView information if
 compiled or assembled with /Zi).


 297. FORTRAN 4.10 CVREADME.DOC: Exit Codes

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28830

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Exit Codes for Utilities
    The exit codes for LINK and the utilities in the Microsoft CodeView
 and Utilities manual should appear as follows:

 LINK

    Code    Meaning

    0       No error.

    2       Program error--something was wrong with the commands
            or files input to the linker.

    4       System error.  The linker

            - ran out of space on output files
            - was unable to reopen the temporary file
            - experienced an internal error
            - was interrupted by the user

 LIB, EXEPACK, EXEMOD, MAKE, and SETENV

    Code    Meaning

    0       No error.

    2       Program error--something was wrong with the commands
            or files input to the utility.

    4       System error.  The utility ran out of memory, was
            interrupted by the user, or experienced an internal
            error.

            Microsoft Segmented-Executable Linker (LINK)


 298. "END=" on Multiple Executions

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR50049 buglist3.20 fixlist3.30
 Last Modified:  6-OCT-1988    ArticleIdent: Q10666

 Problem:

 Using "END=" to branch works properly the first time, but can fail
 under multiple executions. The following code sample demonstrates this
 behavior:

         program contlz

         real*4 a,b

         i = 0
 10      write(*,*) 'real ?'
         read(*,*,end=200) a

         write(*,*) 'second real ?'
         read(*,*,end=200) b
         goto 100

 200     write (*,*) 'end of file encountered'
 100     write(*,*) 'end of program message'
         i = i + 1
         if (i.lt.3) goto 10
         end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. The problem was corrected in Version 3.30.


 299. FORTRAN 4.10 CVREADME.DOC: Changed LINK Error Messages

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28831

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Changed LINK Error Messages
    The explanation for fatal-error message L1008 is changed as
 follows:

    The /SEGMENTS option specified a limit greater than 3072 on the
 number of segments allowed.

    Error message L1009 has been changed to read as follows:

         L1009   <number> : CPARMAXALLOC : illegal value

    Error message L1053 has been changed to read as follows:

         L1053   out of memory for symbol table

    The program had more symbolic information (such as public,
 external, segment, group, class, and file names) than the amount that
 could fit in  available real memory.
    Try freeing memory by linking from the DOS command level instead of
 from a MAKE file or from an editor. Otherwise, combine modules or
 segments and try to eliminate as many public symbols as possible.
    Warning message L4050 has been changed as follows:

         L4050   too many public symbols for sorting

    The linker uses the stack and all available memory in the near heap
 to sort public symbols for the /MAP option. If the number of public
 symbols exceeds the space available for them, this warning is issued,
 and the symbols are not sorted in the map file but are listed in
 arbitrary order.


 300. FORTRAN 4.10 CVREADME.DOC: New LINK Error Messages

 Product Version(s):
 Operating System:   4.10   | 4.10
 Flags: MS-DOS | OS/2
 Last Modified: 29-AUG-1988    ArticleIdent: Q28832
 ENDUSER |

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 New LINK Error Messages

    L1003   /QUICKLIB, /EXEPACK incompatible

    You cannot link with both the /QU option and the /E option.

    L1006   <option-text>: stack size exceeds 65535 bytes

    The value given as a parameter to the /STACKSIZE option exceeds the
 maximum allowed.

    L1063   out of memory for CodeView information

    The linker was given too many object files with debug information,
 and the linker ran out of space to store it. Reduce the number of
 object files that have debug information.

    L1115   /QUICKLIB, overlays incompatible

    You specified overlays and used the /QUICKLIB option. These cannot
 be used together.

    L2013   LIDATA record too large

    An LIDATA record contained more than 512 bytes. This is probably a
 compiler error.

    L2024   <name>: special symbol already defined

    Your program defined a symbol name that is already used by the
 linker for one of its own low-level symbols. (For example, the linker
 generates special symbols used in overlay support and other
 operations.) Choose another name for the symbol in order to avoid
 conflict.

    L2025   <segmentname>: segment with > 1 class name not allowed with
 /INC

 ******<The following is a correction to the CVREADME.DOC file.>*******
    The above error number is not correct. L2025 refers to Symbol
 defined more than once.
 *****************************<END>************************************

    Your program defined a segment more than once, giving the segment
 different class names. Different class names for the same segment are
 not allowed when you link with the /INCREMENTAL option. Normally, this
 error should never appear unless you are programming with MASM. For
 example, if you give the two MASM statements

    _BSS segment 'BSS'

    and

    _BSS segment 'DATA'

 then the statements have the effect of declaring two distinct
 segments. ILINK does not support this situation, so it is disallowed
 when the /INCREMENTAL option is used.

    L2041   stack plus data exceed 64K

    The total of near data and requested stack size exceeds 64K, and
 the program will not run correctly. Reduce the stack size. The linker
 only checks for this condition if /DOSSEG is enabled, which is done
 automatically in the library startup module.

    L2043   Quick Library support module missing

    When creating a Quick library, you did not link with the required
 QUICKLIB.OBJ module.

    L2044   <name> : symbol multiply defined, use /NOE

    The linker found what it interprets as a public-symbol
 redefinition, probably because you have redefined a symbol that is
 defined in a library. Relink with the /NOEXTDICTIONARY (/NOE) option.
 If error L2025 results for the same symbol, then you have a genuine
 symbol-redefinition error.

    L4003   intersegment self-relative fixup at <offset> in segment
 <name> pos: <offset> Record type: 9C target external '<name>'

    The linker found an intersegment self-relative fixup. This error
 may be caused by compiling a small-model program with the /NT option.

    L4034   more than 239 overlay segments; extra put in root

    Your program designated more than the limit of 239 segments to go
 in overlays. Starting with the 234th segment, they are assigned to
 the root (that is, the permanently resident portion of the program).


 301. BACKSPACE Working Improperly

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q10711

 Problem:

 BACKSPACE does not seem to work properly using the DOS1 unit v. The
 following is a code sample that demonstrates this behavior:

        program xxx
        character*70 line
        open (1,file=' ',status='old') 100 continue
        read (1,110,end=200) line 110 format (a)
        write (*,*) line
        go to 100 200 continue
        if (eof(1)) write (*,*) 'unit 1 is at eof'
        backspace 1
        write (1,900) '*****this is new info****' 900 format
     (a)
        write (1,900) 'and so is this...!'
        end

 Response:

 A workaround to this problem is to link with DOS2FOR.LIB. Because
 future versions of the compiler will no longer support DOS1 unit v,
 the problem will no longer occur.


 302. FORTRAN 4.10 CVREADME.DOC: Mixed-Language Programming

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28833

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Mixed-Language Programming -- C Naming Conventions
    C recognizes the first 31 characters of a symbolic name.

 Accessing Parameters on the Stack
    In Section 6.1.5 of the Microsoft Mixed Languages Programming
 Guide, the instruction

         mov     bx, [bp+6]

 loads the argument into the BX register rather than the BP register.

 Setting Up Calls to High-Level Languages
    Section 6.6 of the Microsoft Mixed Languages Programming Guide
 gives instructions for setting up a call to a high-level language from
 assembly language. Before you execute a call to a BASIC, Pascal, or
 FORTRAN routine, remember to declare an additional parameter if the
 return value is noninteger. This additional parameter must contain the
 offset address of the return value, for which you must allocate room
 within the stack segment (normally DGROUP, the same as the default
 data segment).

 BASIC Return Values
    BASIC functions use the FORTRAN/Pascal conventions, rather than the
 C conventions, for receiving return values.

 Passing C Strings to BASIC
    In Section 8.4.3 of the Microsoft Mixed Languages Programming
 Guide, in the example illustrating how C passes string arguments to
 BASIC functions, the sd_len field should be declared as shown below:

         int sd_len

 BASIC Array Declarations
    The sample BASIC array declaration in Table 9.1 of the Microsoft
 Mixed Language Guide should read

         DIM x(c-1, r-1)

 Linking with MASM Files
    If you are linking C modules with modules created by the Microsoft
 Macro Assembler, either assemble the MASM modules with the /MX option
 to preserve case sensitivity in these modules; or, use the LINK
 command to link in a separate step, and do NOT specify the /NOI linker
 option.

 Linking Mixed-Language Programs
    This section explains how to link Microsoft C modules with modules
 created by other Microsoft languages. The discussions assume that you
 are linking with the Microsoft Segmented-Executable Linker, LINK.
 (This is the version of LINK provided with this version of FORTRAN and
 Version 5.10 of the Microsoft C Optimizing Compiler.)
    To link object modules created using the Microsoft C Optimizing
 Compiler, Version 5.10, with those created using the Microsoft FORTRAN
 Optimizing Compiler Version 4.00 or 4.01, you must create a special
 version of each of the FORTRAN libraries you intend to use. Create one
 FORTRAN library to correspond to each C library you are using; that
 is, create a FORTRAN library that supports the same
 memory-model/math-option combination as the corresponding C library.
 Be sure that you choose the "C compatibility" option when you build
 each FORTRAN library.
    Next, use the SETUP program provided with Microsoft C, Version
 5.10, to create all the combined C 5.10 libraries that you will need.
 SETUP creates a subdirectory named \MIXLANG under the C 5.10 base
 directory.
    Place the FORTRAN libraries you have created in this directory.
 Then make the \MIXLANG directory the current directory and run
 F4COMPAT, which brings the FORTRAN libraries up to date and makes them
 compatible with C 5.10. F4COMPAT takes two arguments: one specifying
 the memory model and one specifying the floating-point-math package
 that the library supports. For example,

         F4COMPAT L 7

 makes a C 5.10-compatible version of LLIBFOR7.LIB.

    Once the libraries are built, use the following LINK command line
 to link the appropriate C library with the FORTRAN library that you
 converted in the previous example:

      LINK objs,,,LLIBC7.LIB LLIBFOR7.LIB /NOE;

    The LINK command lines for other memory models and floating-point
 math packages are similar. Note that the C library must be given
 first on the command line. Specify the \MIXLANG subdirectory either in
 the LIB environment variable or on the LINK command line so that the
 linker can find the FORTRAN library. Use only large- and medium-model
 libraries. Huge-model programs use large-model libraries.
    To link other combinations of language libraries, the BASIC
 libraries (either BCOM40 or BRUN40) should be listed first on the LINK
 command line, since the main program must be written in BASIC.
 Otherwise, the C 5.10 library should be listed first. (Or, if you are
 using C 4.00 with FORTRAN 4.00 or later, the FORTRAN library should be
 listed first.) For best results, using large-memory-model C is
 suggested.


 303. FORTRAN 4.10 CVREADME.DOC: The BIND Utility

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28834

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 The BIND Utility -- Specifying Libraries
    You need to include DOSCALLS.LIB on the BIND command line. If
 DOSCALLS.LIB is not in the current directory, you must give the
 complete path name to DOSCALLS.LIB.
    BIND automatically searches for API.LIB by looking in directories
 listed in the LIB environment variable. However, if API.LIB is
 specified on the command line, then BIND does not check the LIB
 environment variable; instead, you need to give the complete path
 name.
    For example, the following command line successfully uses BIND, if
 API.LIB is located in a directory listed in the LIB environment
 variable:

 BIND FOO.EXE \LIB\DOSCALLS.LIB

 Using BIND with Packed Files
    The version of BIND released with this package does not work with
 files that have been linked with the /EXEPACK linker option.

 Running Bound Files with DOS 2.1
    A dual-mode executable file produced with BIND can be run in both
 DOS 3.x and DOS 2.x environments. However, if you change the name of
 an executable file produced by BIND, then it will not run under DOS
 2.1.


 304. FORTRAN 4.10 CVREADME.DOC: ILink Fatal Error Messages

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28835

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 The Microsoft Incremental Linker (ILINK) -- ILINK Fatal Error Messages

 .sym seek error
 .sym read error

    The .SYM file is corrupted. Do a full link. If the error persists,
 contact Microsoft.

 .sym write error

    The disk is full or the .SYM file already exists with the READONLY
 attribute.

 map for segment <name> exceeds 64K

    The symbolic information associated with the given segment exceeds
 64K bytes, which is more than ILINK can handle.

 can't ilink library <name>

    You tried to incrementally link an altered library. ILINK does not
 link .LIB files but only .OBJ files. Use a full link instead.

 .obj close error

    The operating system returned an error when ILINK attempted to
 close one of the .OBJ files. Do a full link. If the error persists,
 contact Microsoft.

 too many LNAMES in <modname>

    An object module has more than 255 LNAME records.

 too many SEGDEFs in <modname>

    The given object module has more than 100 SEGDEF records.

 too many GRPDEFs in <modname>

    The given object module has more than 10 GRPDEF records.

 symbol <name> multiply defined

    The given symbol is defined more than once.

 #3

    Please report this error to Microsoft.

 Out of Memory

    ILINK ran out of memory for processing the input. If you are
 running ILINK under MAKE, try running it from the shell. Otherwise, do
 a full link.

 could not run exec

    ILINK was unable to find the file EXEC.EXE, which should be placed
 somewhere in the search path or in the current directory.

 .exe file too big, change alignment

    The segment sector alignment value in the .EXE file is too small to
 express the size of one of the segments.  Do a full link and increase
 the alignment value with the /ALIGNMENT option to LINK.

 .ilk seek error

    The .ILK file is corrupted. Do a full link. If the error
 persists, contact Microsoft.

 Too many defined segments

    ILINK has a limit of 255 defined segments, which are segments
 defined in an object module as opposed to an executable segment.
 Reduce the number of segments if you want to use ILINK.

 too many library files

    ILINK has a limit of 32 runtime libraries (.LIB files). Reduce the
 number of libraries.

 too many modules

    ILINK has a limit of 1204 modules in a program. Reduce the number
 of modules.

 .ilk write error

    The disk is full, or else ILINK cannot write to the .SYM file
 because a .SYM file currently exists and has the READONLY attribute.

 file <name> does not exist

    ILINK was unable to open the given file. The file named was in the
 file list in the .ILK file.

 seek error on library

    A .LIB file was corrupted. Do a full link and check your .LIB
 files.

 library close error

    The operating system returned an error when ILINK attempted to
 close one of the .LIB files. Do a full link. If the error persists,
 contact Microsoft.

 error closing EXE file

    The operating system returned an error when ILINK attempted to
 close the .EXE file. Do a full link. If the error persists, contact
 Microsoft.

 Invalid module reference <module>

    The program makes a dynamic link reference to a dynamic link module
 which is not represented in the .EXE file.

 could not update time on <filename>

    The operating system returned an error when ILINK attempted to
 update the time on the given file. Possibly the file had the READONLY
 attribute set.

 invalid flag <flag>
 only one -e command allowed

    The ILINK command syntax is incorrect.

 User Abort

    The user issued CTRL+C or CTRL+BREAK.

 file <name> write protected

    The .EXE, .ILK, or .SYM file needed to be updated and has the
 READONLY attribute. Change attribute to READWRITE.

 file <name> missing

    One of the .OBJ files specified on the command line is missing.

 file <name> invalid .OBJ format
 file <name> has invalid <recordtype> record

    The given .OBJ file has an invalid format or one that is not
 recognized by ILINK. This may have been caused by a compiler or
 assembler.

 file <module> was not full linked

    An .OBJ file was specified as input to ILINK, which was not in the
 list of files in the original full link.

 LOBYTE seg-relative fixups not supported

    This error message should occur only with MASM files. See the
 Microsoft Macro Assembler 5.0 Programmer's Guide. This type of object
 module is not supported by ILINK.

 <number> undefined symbols

    The given number of symbols were referred to in fixups but never
 publicly defined in the program.


 305. FORTRAN 4.10 CVREADME.DOC: Incremental Violations

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28836

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Incremental Violations
    These errors cause a full link to occur if the -e option is used
 and -i is not used, or else they are fatal errors:

 symbol <name> deleted

    A symbol was deleted from an incrementally-linked module.

 <modname> contains new SEGMENT

    A segment was added to the program.

 <modname> contains changed segment <name>

    The segment contribution (code or data which the module contributes
 to a segment) changed for the given module: it contributed to a
 segment it didn't previously contribute to, or a contribution was
 removed.

 <modname>'s segment <name> grew too big

    The given segment grew beyond the padding for the given module.

 <modname> contains new GROUP <name>

    A new group was defined, via the GROUP directive in assembly
 language or via the /ND C compiler option.

 <modname> redefines group <name> to include <name>

    The members of the given group changed.

 symbol <name> changed

    The given data symbol was moved.

 can't add new communal data symbol <name>

    A new communal data symbol was added as an uninitialized variable
 in C or with the COMM feature in MASM.

 communal variable <name> grew too big

    The given communal variable changed size too much.

 invalid symbol type for <name>

    A symbol which was previously code became data, or vice versa.

 too many COMDEFS
 too many EXTDEFS

    The limit on the total of COMDEF records (communal data variables)
 and EXTDEF records (external references) is 2000.

 invalid CodeView information in .EXE file

    The CodeView information found is invalid.

 <name> contains new CodeView symbolic info

    A module previously compiled without -Zi was compiled with -Zi.

 <name> contains new linnum info

    A module previously compiled without -Zi or -Zd was compiled with
 -Zi or -Zd.

 <name> contains new public CV info

    New information on public-symbol addresses was added.

 invalid .exe file

    The .EXE file is invalid. Make sure you are using an up-to-date
 linker. If the error persists, contact Microsoft.

 invalid .ilk file
 .ilk read error
 .ilk seek error

    The .ILK file is invalid. Make sure you are using an up-to-date
 linker. If the error persists, contact Microsoft.

 .SYM/.ILK mismatch

    The .SYM and .ILK files are out of sync. Make sure you are using
 an up-to-date linker. If the error persists, contact Microsoft.

 <libname> has changed

    The given library has changed.

 can't link 64K-length segments

    ILINK cannot handle segments greater than 65,535 bytes long.

 can't link iterated segments

    ILINK cannot handle programs linked with /EXEPACK.

 Entry table expansion not implemented

    The program call tree changed in such a way that ILINK could not
 handle it.

 file <name> does not exist

    The .EXE, .SYM, or .ILK files are missing.

 <name> has changed

    The given library module name has changed.


 306. FORTRAN 4.10 CVREADME.DOC: Microsoft Editor

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28837

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Editor -- Setting Up the Microsoft Editor
    The FORTRAN setup program does not install the Microsoft Editor.
 To install the Microsoft Editor, insert the Microsoft Editor disk and
 run the MSETUP batch file. To use the MSETUP batch file under
 protected-mode OS/2, rename MSETUP.BAT to MSETUP.CMD.

 CALLTREE.EXE
    The CALLTREE program mentioned on page 112 of the Microsoft Editor
 User's Guide is not included with FORTRAN Version 4.10 because the
 utility can only be used with C and assembly programs.

 C Extension Files
    The files mentioned in Section 8, "Programming C Extensions," in
 the Microsoft Editor User's Guide are not included with FORTRAN
 Version 4.1, although this file includes corrections to the manual.

 Keystroke Configurations
    Some of the keystroke configurations listed in Table A.2 of the
 Microsoft Editor User's Guide may need to be changed.
    In the Quick/WordStar(R) configuration, the Sinsert function is
 assigned to ALT+INS, not CTRL+INS.
    In the BRIEF(R) configuration, the Plines function is assigned to
 ALT+D, and the Refresh function is assigned to CTRL+].
    In the EPSILON(TM) configuration, the Ppage function is assigned to
 PGDN, and the Sdelete function is assigned to DEL and CTRL+D.

 The Compile Function
    The commands

         Arg streamarg Compile
         Arg textarg Compile

 each use the command specified by the extmake:text switch. The editor
 does not check the extension of the file name given as an argument,
 but instead uses the "text" extension. The streamarg or textarg
 replaces a %s in the command. These commands are typically used to
 invoke MAKE.

 The Setfile Function
    The commands that use Setfile, along with a streamarg or textarg,
 accept a variety of input: either the name of a file, a file name with
 a wild-card character (* or ?), the name of a directory, or the name
 of a disk drive. File names can also include environment variables,
 such as $INIT. If the streamarg or textarg is a directory name, then
 the editor changes the current directory. If the argument is a drive
 name, then the editor changes the current drive. Environment
 variables are translated into directories to be searched for a file.
 For example, the following macro directs the editor to search the
 $INIT environment variable in order to find the tools.ini file:

     tools.ini := Arg "$TOOLS:tools.ini" Setfile

 Entering Strings in Macros
    When you enter a text argument directly, no characters have special
 meaning (except when the argument is interpreted as a regular
 expression). However, when you enter text as part of a macro, then
 strings inside of quotes are interpreted according to the C string
 format. This format uses a backslash followed by double quotes (\")
 to represent double quotes and it uses two backslashes (\\) to
 represent a single backslash. Therefore, to find the next occurrence
 of the string

     She wrote, "Here is a backslash: \ "

 you could use the following macro definition:

     findit := Arg "She wrote, \"Here is a backslash: \\ \"" Psearch

    Note that to indicate a backslash for a regular expression that is
 also part of a macro definition, you must use four consecutive
 backslashes.

 Using Text Switches
    The text switches extmake and readonly each take a special kind of
 syntax that allows you to specify drive, file name, base name, or file
 extension. The syntax consists of the characters:

 %|<letters>F

 where <letters> consists of any of the following: "p" for path, "d"
 for drive, "f" for file base name, or "e" for file extension. For
 example, if you are editing the file c:\dir1\sample.c, and you make
 the following switch assignment:

 extmake:c cl /Fod:%|pfF %|dfeF

 then each time you give the command <Arg><Compile>, the editor
 performs the following system-level command:

 cl /Fod:\dir1\sample c:sample.c

    The expression "%s" is equivalent to "%|feF" except that the former
 only works once, whereas the latter can appear any number of times in
 the extmake switch assignment. The expression "%|F" is equivalent to
 "%|dpfeF".

 The Filetab Switch
    The filetab switch is a numeric switch that determines how the
 editor translates tabs when loading a file into memory.  The value of
 the switch gives the number of spaces associated with each tab column.
 For example, the setting "filetab:4" assumes a tab column every 4
 positions on each line. Every time the editor finds a tab character
 in a file, it loads the buffer with the number of spaces necessary to
 get to the next tab column. Depending on the value of the entab
 switch, the editor also uses the filetab switch to determine how to
 convert spaces into tabs when writing to a file. The default value of
 filetab is 8.

 Functions Callable by C Extensions
    The following list summarizes functions from the standard compact-
 memory-model library, which should work when called by a C-extension
 module.  (The technique of programming C extensions is presented in
 Chapter 8 of the Microsoft Editor User's Guide.)  The memory model of
 the extension is assumed to be /Asfu (small code pointers, far data
 pointers, and stack segment unequal to data segment).  This list uses
 the function categories from Chapter 4 of the Microsoft C Optimizing
 Compiler Run-Time Library Reference (Version 4.0 or later.)

    Buffer Manipulation: All functions can be called.
    Character Classification and Conversion: All functions can be
 called.
    Data Conversion: All functions can be called except for

      strtod()

    Directory Control: All functions can be called except for

      getcwd()

    File Handling: All functions can be called.

    Low-Level I/O Routines: All functions can be called, but write()
 will not work in binary mode.
    Console and Port I/O: All functions can be called except for

      cgets()
      cprintf()
      cscanf()

    Searching and Sorting: All functions can be called except for

      qsort()

    String Manipulation: All functions can be called except for

      strdup()

    BIOS Interface: All functions can be called.
    MS-DOS Interface: All functions can be called except for

      int86()
      int86x()

    Time: All functions can be called except for

      ctime()
      gmtime()
      localtime()
      utime()

    Miscellaneous: All functions can be called except for

      assert()
      getenv()
      perror()
      putenv()
      _searchenv()

 Linking Extensions in Protected Mode
    To link C extension modules in protected mode, link with the object
 file EXTHDRP.OBJ, instead of the real-mode header EXTHDR.OBJ.


 307. FORTRAN 4.10 Startup README.DOC: Startup Sources

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28838

    The following information is from the FORTRAN Version 4.10
 Startup README.DOC file:

 FORTRAN Runtime Library Startup Sources
    The directory \startup and its subdirectories contain the files
 necessary for building the startup portion of the FORTRAN run-time
 library. The \startup directory contains the startup source files, the
 include include files, the batch file and the make file used to build
 the startup object files. The subdirectories of \startup contain OS
 specific sources.
    The startup object files can be built by invoking startup.bat from
 within the \startup directory. This batch file assumes the following:

    1. make.exe, link.exec, the FORTRAN compiler, and the assembler
 must be in the execution path. MASM 5.0 or later is required to build
 the startup sources.
    2. doscalls.lib must be in the directory specified by the LIB
 environment variable.
    3. For linking the nulbody program, startup.bat assumes that
 directories containing the FORTRAN libraries (llibfor7.lib and
 mlibfor7.lib, or llibfore.lib and mlibfore.lib) are in the library
 search path (LIB environment variable). (The alternative math
 libraries could be used if the option -FPa is added to $(FL) in the
 makefile.)

    Startup will create two memory model specific subdirectories (M and
 L) and place the appropriate object files there. Under each memory
 model subdirectory, startup creates two additional subdirectories, OS2
 and DOS, where OS specific objects reside.
    The message "<cEnd - nogen>" is generated when some of the assembly
 language source files are assembled. This message is expected and is
 totally benign.
    The startup batch file requires as arguments a list of capital
 letters describing the memory models you wish to build. For example,
 "startup M L" will build the medium and large model startup objects.
 Startup will then link the objects with a sample FORTRAN program
 called nulbody.for to produce nulbody.exe. [Invoking startup.bat with
 no arguments will give usage information.]
    Note: startup sources written in assembly language have been edited
 with tabstops set to 8.
    The following files are contained in the \startup directory:

 Startup source files (OS independent):

         chkstk.asm
         chksum.asm
         crt0fp.asm
         onexit.asm

 Startup source files (OS specific):

         crt0.asm
         crt0dat.asm
         crt0msg.asm
         nmsghdr.asm
         stdalloc.asm
         stdenvp.asm
         stdargv.asm

 Startup include files:

         brkctl.inc
         cmacros.inc
         msdos.inc
         version.inc

 Make and batch files:

         startup.bat:    invokes make file to build objs and link to
                         null program
         makefile:       contains rules for building startup sources
         nulbody.for:    null FORTRAN program
         nulbody.lnk:    link script for linking null program

 Documentation:

         readme.doc:     information about \startup directory structure
                         and contents

                                 --- End ---


 308. FORTRAN 4.10 CVREADME.DOC: Program Maintenance Utility

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28840

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Program Maintenance Utility (MAKE) -- New Error Message

    U1015: <file> : error redirection failed

    This error occurs if the /X option is given and error output cannot
 be redirected to the given file (for example, because the file is
 read-only).

 Inference Rules
    You cannot have inference rules in both the TOOLS.INI and the
 description file that use both the same inextension and outextension.
 For example, you cannot place the following inference rule in the
 TOOLS.INI file:

         .c.obj:
                 cl /c /Zi /Od $*.c

 while also placing the following line in the description file:

         .c.obj:
                 cl /Ot $*.c

    However, you can define the same macro in both the TOOLS.INI and
 the description file. In such cases, the definition in the description
 file takes precedence.

 Backslash (\) as Continuation Character
    Note that MAKE considers a backslash immediately followed by a
 new-line character to be a continuation character. When it finds this
 combination in a description file, MAKE continues the line
 immediately following the combination with the line where the
 combination appears.
    If you define a macro that ends in a backslash, make sure that you
 put a space after the terminating backslash. For example, if you want
 to define macros for the path C:\SRC\BIN and C:\SRC\LIB, you must use
 the format illustrated below:

         BINPATH=C:\SRC\BIN\<space><newline>
         LIBPATH=C:\SRC\LIB\<space><newline>

    To illustrate the problems that can result if you do not put a
 space before the new-line character, assume that the macros above
 appear as shown below instead:

         BINPATH=C:\SRC\BIN\<newline>
         LIBPATH=C:\SRC\LIB\<newline>

    Because a new-line character appears immediately after the
 backslash at the end of the first macro, MAKE assumes that you are
 defining the single macro shown below:

         BINPATH=C:\SRC\BIN\LIBPATH=C:\SRC\LIB\

 Microsoft STDERR Redirection Utility (ERROUT)
    The ERROUT utility does not accept batch files. To redirect
 standard-error output from a batch file, you must enter a command of
 the following form:

         ERROUT COMMAND /c <batchcommand>

    If no /f option is given, then ERROUT redirects standard-error
 output to the standard-output device.


 309. "Share Not Installed" Incorrectly Produced in Protected Mode

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q29562

    The following code will generate the error message "share not
 installed" when it is run in protected mode:

        OPEN(UNIT=7,FILE=FL,STATUS='NEW',MODE='READWRITE',
      +  SHARE='DENYWR')
        WRITE(7,'(A12)')'ARE YOU OPEN'
        write (7,*)'hello'
       END

    Trying to open a file with status = 'new' when the file already
 exists will incorrectly produce the error message "share not
 installed." The correct error message is "file already exists".
    This error only occurs in protected mode.


 310. Version 3.31 Cannot Pass a Logical Expression

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10822

 Problem:
    The following code generates incorrect results:

    real rsw
    logical ll
    real r

    ll = .TRUE.
    write (0,*) rsw(ll,1.0,0.0)
    ll = .FALSE.
    write (0,*) rsw(ll,1.0,0.0)

    r = 1.0
    write (0,*) rsw(r .gt. 0.0,1.0,0.0)

    write (0,*) rsw(r .lt. 0.0,1.0,0.0)
    end

    real function rsw (l,t,f)
    logical l
    real t,f

    rsw = f
    if (l) rsw = t
    return
    end

    The following output is produced:

    1.0000000
    .0000000
    .0000000
    .0000000

 Response:
    Version 3.31 of the compiler does not pass logical expressions in a
 parameter list correctly.
    The following are two workarounds:

    1. Define the function before calling it.
    2. Create an INTERFACE statement for the function.

    This problem was corrected in Version 4.00.


 311. Symbol Defined More Than Once

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.30
 Last Modified: 12-MAY-1988    ArticleIdent: Q10809

    The false link error "symbol defined more than once" is generated
 when an object module has an external reference to a function that is
 never used.

    A workaround is to remove the external statement for the unused
 function.
    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler. This problem was corrected in Version 3.31.


 312. Microsoft Floating Point Versus IEEE

 Product Version(s): 3.2 3.3x 4.0x
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified:  2-MAY-1988    ArticleIdent: Q10866

 Question:
    I have created files containing floating point values in BASIC and
 would like to use these files in FORTRAN. How would I accomplish this?

 Response:
    Since Basic uses Microsoft floating point binary format to store
 real values and FORTRAN uses the IEEE format, you would have to
 convert your real values from Microsoft floating point binary to IEEE.
    To accomplish this procedure using single precision, please see
 Page 167 of the FORTRAN user's guide.
    To accomplish this procedure using double precision numbers, you
 would have to do the following:

    1. Write a BASIC program to read the numerical data files, and then
 create an output file in text (ASCII) format.
    2. Write a FORTRAN program to read the text file, and then write a
 binary file that contains the double precision numbers in the IEEE
 floating point format (FORTRAN-readable format).


 313. Run-Time Error "No Room in Heap"

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10860

 Problem:
    I have developed a program that has about 150 subroutines (400K
 code and 120K data). Most of the data is in common blocks, but the
 error message "no room in heap" still is generated at run time.

 Response:
    The following is a list of possible reasons for this error:

    1. There may not be enough memory in your machine. The maximum
 memory you can have in your machine is 640K. You will constantly reach
 your limit unless you have a full 640K (and perhaps even if you do)
 because your data and code use 520K (400K for code, 120K for data).
    2. Something in your code may be using up DGROUP space. An error
 indicating there is no room in the heap may occur when you are opening
 a file in your program. Opening a file uses dynamic memory allocation,
 which requires space from DGROUP. If there is not enough space left in
 DGROUP, opening a file will result in a "no room in heap" error.
    3. Your format strings may be using up DGROUP space. If this is the
 case, you could put your format strings in a character variables file
 in a common block. Unfortunately, this action creates unreadable code,
 but it is a possible workaround.
    4. Long parameter lists may be using up DGROUP space, which you
 will have to break up.


 314. WRITE Statement and Parenthesis Expression

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10817

 Problem:
    The following code

    WRITE (*,*) (1+2)*3
    END

 generates the following errors:

    Error 59, line 1 -- "=" expected
    Error 162, line 1 -- unrecognizable I/O list element
    Error 59, line 1 -- "=" expected
    Error 152, line 1 -- end of statement encountered in
    implied DO

 Response:
    These errors are generated because the compiler considers the
 expression (1+2) an implied DO list. It is illegal to put a
 parenthesis at the beginning of an output list unless it is an implied
 DO-LOOP.
    You can avoid these errors by rewriting your program as follows:

    WRITE(*,*) 3*(1+2)
    END


 315. Run-Time Error 2136

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: enduser | buglist3.30
 Last Modified:  2-MAY-1988    ArticleIdent: Q10812

 Problem:
    Run-time error 2136 (Real indefinite) is generated when an
 expression contains an array declared in a COMMON block and the array
 is indexed by a variable declared in the same COMMON block (but
 contained in a different segment).

 Response:
    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler. The problem was corrected in Version 3.31.


 316. Floating Point Expression

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: enduser | buglist3.30
 Last Modified:  2-MAY-1988    ArticleIdent: Q10808

 Problem:
    Floating point expressions are being evaluated incorrectly in a
 compound IF statement if a combination of REAL and INTEGER COMMON
 variables is used.

 Response:
    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler. The problem was corrected in Version 3.31.


 317. FORTRAN: COMPLEX*8 Arithmetic Expression Evaluates Incorrectly

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q29565

 In some cases, when variables are declared as COMPLEX*8, arithmetic
 expressions evaluate to the wrong value.

 One way to work around the problem is to declare the variables as
 COMPLEX*16, rather than COMPLEX*8.

 The following code sample demonstrates the problem, with the suggested
 workaround in comments:

    COMPLEX*8 a,b,c

    c   This problem can be worked around by changing the above
    c   declaration to the following:
    c
    c       COMPLEX*16 a,b,c
    c
         a=(1.,0.)
         b=(0.,1.)
         write(*,'('' a ='',f10.3,1x,f10.3)') a
         write(*,'('' b ='',f10.3,1x,f10.3)') b
         c=a+(-1.0)*b
         write(*,'(''  a+(-1.0)*b=  '',2(1x,f10.3))') c
         write(*,'(''  correct answer is'',2(1x,f10.3))') (1.,-1.)
         end

 Microsoft has confirmed this to be a problem in Version 4.10; the
 problem was corrected in Version 5.00.


 318. FORTRAN: IOSTAT Returns an Invalid Run-Time Error

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q29787

 The code below will return an incorrect run-time error in "IOSTAT." To
 work around this problem, you must do one of the following:

    1. Use a temporary variable to perform the concatenation outside
       the open statement.

    2. Replace the integer variable 'long' with its numerical
       representation. Thus, the substring would look like
       'chaine(1:7)'.

    3. Define chaine as character*8 and remove substrings.

    4. Do not use substrings, leave chaine as character*80, and use
       in real mode. This workaround will not work in protected mode.

 The problem lies in the open statement. The concatenation and
 substrings inside the function cause this to fail:

       character*80 chaine
       integer ier,long
       ier = 0
       chaine = 'filename'
       long = 7
       open (unit=1,file=chaine(1:long)//'.cal',
      + status='unknown',err=10,iostat = ier)
 10    if (ier.ne.0) then
        write (*,*)'Errornumber',ier,'at opening file:',
      +    chaine (1:long)//'.cal'
        else
        write (*,*)'Correctly opened'
        write (*,*)'correctly opened'
        close(1)
        end if
        end

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.


 319. Internal Compiler Error: trees.c, Line 1165

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  8-NOV-1989    ArticleIdent: Q29792

 The programs below generate the following errors:

    initmin.for
    initmin.for(8) : warning F4202: PRINTV : formal argument NPOINT :
                     never used
    initmin.for(6) : fatal error F1001: Internal Compiler Error
                     (compiler file '../trees.c', line 1165)
                     Contact Microsoft Technical Support

 The problems occur because the code does not conform to the ANSI 77
 Standard. Following the standard, an adjustable-size array must be
 passed as one of the arguments to the subroutine. (For more
 information on adjustable-size arrays, see Section 5.5.1 of the "ANSI
 X3.9-1978 FORTRAN 77" manual.)

 To work around this problem, pass the array VBlock to the subroutine
 along with the array index.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following program should generate a syntax error:

    subroutine PrintVars ( inPoints )

    real VBlock ( nPoints )
    equivalence ( VBlock, S )

    call rvprint ( VBlock (nPoints) )
    return
    end

 In this case, only the array index is passed. If the program is
 changed to the following (to conform to the standard), the internal
 compiler error is not generated:

    subroutine PrintVars (VBlock, nPoints)

    real VBlock ( nPoints )

    call rvprint ( VBlock (nPoints) )
    return
    end


 320. L1103 Linker Error: Accessing Data Outside Segment Bounds

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q29883

 Problem:

 The following link error message occurs when I link and compile a
 large program:

    "L1103 attempt to access data outside segment bounds"

 I am compiling and linking as follows:

    fl /4I2 /FPi /c /Od /Zi program.for
    link /SE:320 /NOD /CO @program.rsp

 Response:

 You can work around this problem by changing the compile to the
 following:

     fl /4I2 /FPi /c program.for

 The generation of symbolic information may be part of the problem.

 Another workaround is to compile the different functions separately;
 doing this allows you to use CodeView and avoid the L1103 error.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.


 321. FL Automatically Adds the Extension .OBJ

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q29884

 Problem:

 Page 14, Section 3.6.5, of the "Microsoft FORTRAN Optimizing Compiler
 Version 4.10" update manual states that "FL automatically adds the
 extension .FOR." However, my source cannot be compiled unless I give
 the extension with the name.

 Response:

 The documentation is incorrect. The statement should read as
 follows:

 "FL automatically adds the extension .OBJ".


 322. F1901 Program Too Large for Memory on Array Initialization

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q30541

 Problem:

 I have an integer*2 array of 1100 elements that is initialized in the
 source code. The total size of the array is about 4K and it is the
 only thing in the program; however, I still get the error message
 "F1901 program too big to fit in memory."

 Response:

 Microsoft has confirmed this to be a problem in Versions 4.01 and 4.10
 of the FORTRAN compiler. This problem was corrected using F1L.EXE in
 Version 5.00.

 A workaround is to declare the array in the source code and to
 initialize it by reading in the data from a file. This procedure
 allows more flexibility in changing the data. You could then just
 change the data file, instead of modifying the source, recompiling,
 and relinking.

 The following code demonstrates the problem:

       PROGRAM ESSAI
       INTEGER*2 IT0(1101)
 C===
       DATA IT0/
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944/
       END


 323. FORTRAN 4.10 PACKING.LST

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q30570

 The following information is from the FORTRAN Version 4.10 PACKING.LST
 file:

 PACKING.LST
 for Microsoft(R) FORTRAN Optimizing Compiler Version 4.1
 (C) Copyright 1987, 1988, Microsoft Corporation

    This file describes the parts of the Microsoft(R) FORTRAN
 Optimizing Compiler Version 4.1 package.

 DOCUMENTATION
    There are three binders:

    1. Microsoft FORTRAN Optimizing Compiler Version 4.1 Update and
 Microsoft FORTRAN Optimizing Compiler User's Guide
    2. Microsoft FORTRAN Optimizing Compiler Language Reference
    3. Microsoft CodeView(R) and Utilities and Microsoft Editor

    The package also includes a quick reference guide and templates:

    Microsoft FORTRAN Optimizing Compiler Quick Reference Guide
    Two function-key templates for the Microsoft CodeView debugger

 DISKS
    The Microsoft FORTRAN compiler is distributed on ten 5-1/4" disks
 or five 3-1/2" disks. The 3-1/2" disks are not included in this
 package. To obtain 3-1/2" disks, telephone Microsoft Sales and Service
 at [phone]. Please have your manuals handy when you call.
    The following two lists describe the layout of the 5-1/4" disks and
 show how the contents of the 5-1/4" disks are combined to make up the
 3-1/2" disks.

 5-1/4" Disk Layout

      Disk 1:  Setup

           DEMOS    <DIR>
           PATCH    <DIR>
           EMOEM.ASM      MASM source to modify 87.LIB for
                          non-IBM(R) compatibles
           F3S.EXE        FORTRAN compiler, Pass 3, small model (non-optimized
           FL.ERR         Error message file for FL.EXE
           FL.EXE         FORTRAN compiler driver
           FL.HLP         Help file for FL.EXE
           FLOPSET.DOC    Floppy disk set up documentation
           PACKING.LST    Packing list (this file)
           PATCH87.EXE    MS-DOS 3.2 Patch program
           README.DOC     Information made available after manuals
                          were printed
           SETUP.DAT      Data file for SETUP program
           SETUP.EXE      FORTRAN SETUP program

                 (13 files)

           \DEMOS subdirectory (Demonstration Programs)

           CIRC.C         C-module for GRAPH.EXE program
           DEMO.FOR       FORTRAN demo program
           DEMOEXEC.FOR   FORTRAN demo program (calling a C procedure)
           DEMORAN.FOR    FORTRAN demo program (random number generator)
           DWHET.FOR      Popular benchmark program
           FOREXEC.INC    FORTRAN demo program (include file)
           GRAPH.BAT      Batch file for GRAPH.EXE file
           GRAPH.FOR      FORTRAN module for GRAPH.EXE program
           SECNDS.FOR     Subroutine for benchmarks
           SIEVE.FOR      Popular benchmark program
           SWHET.FOR      Popular benchmark program

                 (11 files)

           \PATCH subdirectory (PC-DOS 3.2 patch):

           README.DOC
           RMRHS.EXE
           SETRHS.EXE
           STKPAT.BAT
           STKPAT.SCR

                 (5 files)

      Disk 2:  Compiler 1

           F1.ERR         Error message files for compiler, Pass 1
           F1.EXE         FORTRAN compiler, Pass 1
           F3.EXE         FORTRAN compiler, Pass 3

                 (3 files)

      Disk 3:  Compiler 2

           EXEC.EXE       Utility used only by ILINK
           F2.EXE         FORTRAN compiler, Pass 2
           F23.ERR        Error messages for FORTRAN compiler,
                          Passes 2 and 3
           ILINK.EXE      Microsoft Incremental Linker
           LIBBUILD.BAT   Combined library builder

                 (5 files)

      Disk 4:  Utilities

           BIND.EXE       Operating System/2 BIND Utility
           ERROUT.EXE     STDERR Redirection Utility
           EXEHDR.EXE     Segmented EXE Header Utility
           EXEMOD.EXE     EXE File Header Utility
           EXEPACK.EXE    EXE File Compression Utility
           IMPLIB.EXE     Import Library Manager
           LIB.EXE        Library Manager
           LINK.EXE       Segmented-Executable Linker
           MAKE.EXE       Program Maintenance Utility
           SETENV.EXE     Environment Expansion Utility

                 (10 files)

      Disk 5:  Microsoft CodeView(R) for MS-DOS(R)

           DEMO.BAT       CodeView debugger demonstration file
           MOUSE.COM      Mouse driver
           C_AUTO.CV      CodeView debugger demonstration file
           E_AUTO.CV      CodeView debugger demonstration file
           L_AUTO.CV      CodeView debugger demonstration file
           M_AUTO.CV      CodeView debugger demonstration file
           Q_AUTO.CV      CodeView debugger demonstration file
           S_AUTO.CV      CodeView debugger demonstration file
           IN.DAT         Data file used with STATS.FOR
           CVREADME.DOC   Information about CodeView/Utilities
                          made available after manuals were printed
           CV.EXE         CodeView debugger
           WHAT.EXE       Program used by CodeView demo
           STATS.FOR      FORTRAN program used in CodeView demo
           CV.HLP         CodeView debugger help file

              (14 files)

      Disk 6:  Microsoft CodeView for OS/2

           CVP.EXE        OS/2 CodeView debugger
           CVP.HLP        OS/2 CodeView help file
           CVPACK.EXE     Debugging information packing utility
           MAKESORT.BAT   DOS batch file for SORTDEMO.FOR
           MAKESORT.CMD   OS/2 batch file for SORTDEMO.FOR
           OS2PATCH.EXE   OS/2 patch utility
           PTRACE87.PAT   Patch file for OS2PATCH.EXE
           SORTDEMO.FOR   OS/2 demonstration file

              (8 files)

      Disk 7:  Libraries (Large Model)

           87.LIB         8087/80287 math library (model independent)
           ALTMATH.LIB    Large-model FORTRAN 3.3x-compatible alternate math
                          library
           EM.LIB         Emulator library (model independent)
           FORTRAN.LIB    Large-model FORTRAN 3.3x-compatible library
           LCLIB1.LIB     Large-model DOS 3 C library
           LIBH.LIB       Helper library (model independent)
           LLIBFA.LIB     Large-model alternate-math library
           LLIBFOR.LIB    Large-model standard FORTRAN library
           LLIBFOR1.LIB   Large-model DOS 3 FORTRAN library
           LLIBFP.LIB     Large-model floating-point math library
           MATH.LIB       Large-model FORTRAN 3.3x math compatibility library
           NBUILD.OBJ     Error-message stub file (model independent)

                 (12 files)

      Disk 8 of 10:  Libraries (Medium Model)

           87.LIB         8087/80287 math library (model independent)
           EM.LIB         Emulator library (model independent)
           LIBH.LIB       Helper library (model independent)
           MCLIB1.LIB     Medium-model DOS 3 C library
           MLIBFA.LIB     Medium-model alternate math library
           MLIBFOR.LIB    Medium-model standard FORTRAN library
           MLIBFOR1.LIB   Medium-model DOS 3 FORTRAN library
           MLIBFP.LIB     Medium-model floating-point math library
           NBUILD.OBJ     Error-message stub file (model independent)

                 (9 files)

      Disk 9 of 10:  MS OS/2 Libraries

           STARTUP  <DIR>
           API.LIB        Family API emulation library
           APILMR.OBJ     64K stack object file (for use with BIND)
           DOSCALLS.LIB   Import library for API
           LCLIB2.LIB     Large-model OS/2 C library
           LLIBFOR2.LIB   Large-model OS/2 FORTRAN library
           MCLIB2.LIB     Medium-model OS/2 C library
           MLIBFOR2.LIB   Medium-model OS/2 FORTRAN library

                 (8 files)

           \STARTUP subdirectory (startup source code):

           DOS      <DIR>
           OS2      <DIR>
           BRKCTL.INC
           CHKSTK.ASM
           CHKSUM.ASM
           CMACROS.INC
           CRT0FP.ASM
           MAKEFILE
           MSDOS.INC
           NULBODY.FOR
           ONEXIT.ASM
           README.DOC
           STARTUP.BAT
           VERSION.INC

                 (14 Files)

           \STARTUP\DOS subdirectory (DOS-specific startup source code):

           CRT0.ASM
           CRT0DAT.ASM
           CRT0MSG.ASM
           NMSGHDR.ASM
           NULBODY.LNK
           STDALLOC.ASM
           STDARGV.ASM
           STDENVP.ASM

                 (8 Files)

           \STARTUP\OS2 subdirectory (OS\2-specific startup source code):

           CRT0.ASM
           CRT0DAT.ASM
           CRT0MSG.ASM
           EXECMSG.ASM
           NMSGHDR.ASM
           NULBODY.LNK
           STDALLOC.ASM
           STDARGV.ASM
           STDENVP.ASM

                  (9 Files)

      Disk 10:  Microsoft Editor

           INI      <DIR>
           MSETUP.BAT     Installation and setup routine
           FIXSHIFT.COM   Keyboard driver patching utility
           ECH.EXE        Character echoing utility used by Microsoft Editor
           EXP.EXE        Expunge utility (used with RM)
           M.EXE          Microsoft Editor
           MEGREP.EXE     Pattern finding utility (GREP)
           MEP.EXE        OS/2 Microsoft Editor
           RM.EXE         File removing utility
           UNDEL.EXE      File undeletion utility (used with RM)
           WHAT.EXE       Program used by MSETUP

                  (11 Files)

           \INI subdirectory (Initialization files for Microsoft Editor):

           BRIEF.INI      BRIEF(R) initialization file
           EPSILON.INI    Epsilon(TM) initialization file
           QUICK.INI      Quick-product initialization file
           WS.DLL         Protected-mode extension file
           WS.ZXT         Real-mode (DOS) extension file

                  (5 Files)

 3-1/2" Disk Layout
    The five 3-1/2" disks combine the 5-1/4" disks as follows:

      Disk 1:  Setup / Compiler 1
      Disk 2:  Compiler 2 / Utilities
      Disk 3:  Microsoft CodeView for MS-DOS / Microsoft CodeView for OS/2
      Disk 4:  Libraries (Large and Medium Models)
      Disk 5:  MS OS/2 Libraries / Microsoft Editor


 324. __Flclenv Should be __FCclenv

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 15-JUN-1988    ArticleIdent: Q30588

    There are three references to a global variable named "__FIclenv"
 on Page 261 of the "Microsoft Fortran Optimizing Compiler User's
 Guide."
    These references are incorrect; the correct name is "__FCclenv".


 325. Compile-Time Fatal Error F1914 Occurs When Using FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 26-JUL-1990    ArticleIdent: Q30589

 The "F1914 cannot open internal files" compile-time fatal error
 message may appear when you use Microsoft FORTRAN.

 This error occurs if you improperly set your environment. Your
 AUTOEXEC.BAT and CONFIG.SYS files must have the correct syntax; there
 should be no spaces in the settings with the exception of a space
 between SET and the particular variable being set.

 For example, the variable setting PATH = C:\DOS (note the spaces
 around the equals sign) must be changed to PATH=C:\DOS.

 FILES = 20 must be changed to FILES=20. In addition, there should be
 no space or hidden characters at the end of a line such as SET
 TMP=C:\TMP.

 The F1914 error also can occur if the specified directory does not
 exist. For example, the environment variable setting SET TMP=C:\TEMP
 is incorrect if C:\TEMP does not exist. Misspelling C:\TMP as C:\TEMP
 can cause this error.

 If there is no room on the disk for a file to be created, the F1914
 error occurs. This error can occur if a RAM drive is being used for
 the TEMP subdirectory. If the RAM drive is set too small or set
 incorrectly, error F1914 can be generated.


 326. Global Array Pointed to by __FCclenv

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | __FCclenv global array
 Last Modified: 19-SEP-1988    ArticleIdent: Q34972

 Question:

 What is exactly pointed to by the global variable __FCclenv in
 FORTRAN? I see it referenced on Page 261 of the "Microsoft FORTRAN
 Optimizing Compiler User's Guide," but I don't understand what is
 being stored.

 Response:

 The __FCclenv global variable contains the address to an array that
 contains the lengths of character arrays that are being passed to a
 FORTRAN subroutine or function. The compiler must keep track of the
 actual lengths of the character arrays, whether the arrays are varying
 or not, thus storing the information in this global array.

 The first element of this global array will contain the length of the
 character array for the return value of a character function. If the
 function returns anything other than a character array, or is a
 subroutine, the first value will contain whatever happens to be at the
 particular memory location (i.e., meaningless information). Consider
 the following two examples:

 character*80 function junk(a,b,c,d,e,f,g)
 character*(*) a,b,c,e,f,g
 character*4 d

 This declaration will put 80 in the first element of the global array
 pointed to by __FCclenv. This will be followed by the lengths of the
 arrays of a, b, c, d, e, f, g.

 subroutine junk(a,b,c,d,e,f,g)
 character*(*) a,b,c,e,f,g
 character*4 d

 This declaration will put nothing in the first element (so the memory
 location for this first element will be whatever value happens to be
 at that location). The remaining elements will contain the lengths of
 the passed arrays. This will also hold true for other functions that
 return values other than characters.


 327. NonPrintable Characters in Source File

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-JUN-1988    ArticleIdent: Q31022

    Page 13 of the FORTRAN Versions 4.00 and 4.10 Optimizing Compiler
 reference manual (section 2.2) states the following:

    "Microsoft FORTRAN source files can contain any PRINTABLE
 characters in the ASCII character set."

    This sentence in the manual is indicated to be an extension because
 the standard itself does not permit lowercase letters.
    Embedded control characters in source files generally are used to
 either control the screen cursor or a printer, or send a "beep" to the
 screen. You can do any of these without embedding control characters.
    For example, to send a message ending with a "beep" to the
 terminal, write the following:

    CHARACTER OUTSTR*20
    OUTSTR = 'This is the message'
    OUTSTR(20:20) = CHAR(7)
    WRITE (*,*) OUTSTR
    END

    This code conforms to the ANSI X3.9-1978 FORTRAN standard, so it
 will run on all standard conforming compilers. With this example, you
 can substitute any of the ASCII characters (i.e., CHAR(0) to
 CHAR(255)).
    However, the same is not true if you try to embed the character in
 the string itself.

    While some characters, such as BEL (CHARACTER(7)), may produce the
 desired results when embedded in a character string, others, e.g. NUL
 (CHAR(0)), CTRL-Z (CHAR(26), and BS (CHAR(8)), may cause unexpected
 behavior.
    The use of nonprintable ASCII characters embedded in source files
 is not supported. The same results can be achieved by using the CHAR
 function to insert the characters in their proper place at run time by
 either using character substrings or the // concatenation operator.
    The following is a source line that causes the error "F2031:
 closing quote missing":

    80 SUPB = '\033S\000\010'

    The following four characters were present in "SUPB" to change the
 printer to bold superscripting:

    1. ESC (hex 1B)
    2. "S"
    3. NUL (hex 00)
    4. BS (hex  08)

    This attempt has several flaws; it is nonportable, and both
 compiler and editor dependent.
    There are several more-preferable ways to do this, using either
 portable or nonportable features. Using standard features, the line
 could be rewritten as follows:

    80 SUPB = CHAR(27) // 'S' // CHAR(0) // CHAR(8)

    If the nonprintable characters have been defined individually as
 character variables, the line could be rewritten as follows:

    80 SUPB = ESC // 'S' // NUL // BS

    If you want to be nonstandard, the line could be rewritten as
 follows:

    80 SUPB = #1B530008



 328. How CTRL-Z Is Interpretted for Various File Types

 Product Version(s): 3.20 3.30 3.31 3.32 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-JUN-1988    ArticleIdent: Q31023

    The following list demonstrates the various file types, and whether
 or not an embedded CTRL-Z is allowed:

                         Embedded
                         CTRL-Z
 File Type               Allowed         Notes

 Binary                  Yes             Read or write; no restriction.
 Unformatted             Yes             Read or write; no restriction.
 Formatted               No (not on read)
                                         Trailing CTRL-Z and NULL (0)
                                         characters are stripped off.
                                         You can write CTRL-Z (using CHAR(26))
                                         into a file, but unless you are
                                         reading a character variable, you
                                         will get a run-time error if a
                                         CTRL-Z is found.
                                         A text file should not have
                                         any non-printable characters
                                         in it.

 Internal                No (not on read)



 329. Real*8 or Double Precision Must Contain an Exponent

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-JUL-1988    ArticleIdent: Q31173

    When using real*8 or double-precision variables, the FORTRAN manual
 says the variables should be significant to 15 digits. However, these
 variables use only the first seven digits correctly; the remaining
 eight digits are used randomly.
    To get 15 digits of precision into your real*8 variables, you must
 declare the constant with an exponent. If the exponent is omitted, the
 number is interpreted as a single-precision constant.
    For more information, please refer to the "Microsoft FORTRAN
 Optimizing Compiler Language Reference" manual, Section 2.4.3, Pages
 23-24.

    The following is a code example of the proper way to set a
 double-precision variable with the D:

          real*8 doub_real
    c      double precision doub_real
    c      either real*8 or double precision needs to use the D.

          doub_real = .55555555555555555555D0
          print '(f20.18)',doub_real
          end


 330. $DECLARE Fails on Nondeclared Argument-List Variables

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | Buglist4.1
 Last Modified: 16-JUN-1988    ArticleIdent: Q31320

    The $DECLARE metacommand does not generate a compile-time warning
 when a variable appearing in the argument list of a subroutine is used
 without being typed.
    The following code sample does not warn that "A" is undeclared, but
 it should generate a compile-time warning:

    $DECLARE
             SUBROUTINE POOT(A)
             A=1.0
             RETURN
             END

    Microsoft has confirmed this to be a problem with Microsoft FORTRAN
 Version 4.10.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 331. Passing Function Names as Arguments to NonFORTRAN Routines

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-JUN-1988    ArticleIdent: Q31322

    FORTRAN procedural arguments are not compatible with C-procedure
 pointers ( e.g. you cannot pass function names as arguments to C
 routines). Because FORTRAN treats function pointers differently then
 other pointers, the C routines do not "understand" what is being passed
 to them.
    For more information on this subject, please see Pages 287-288
 (Section 11.3.8.6) and Page 293 (Section 11.3.8.9) in the "Microsoft
 FORTRAN Optimizing Compiler User's Guide."


 332. Appending to a File

 Product Version(s): 3.x 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-MAR-1988    ArticleIdent: Q11271

 Problem:
    Under mainframe FORTRAN there is a function MOD; it adds data to
 the end of a file in FORTRAN. I cannot find a similar
 command in your compiler. I want to add some data to
 the end of an ASCII file.
    I have used the command ENDFILE as an example to solve the problem.
 However, a sequential file that is opened and written to will
 overwrite the existing data (as stated in the manual).

 Response:
    On Pages 15-23 and 15-23s of the ANSI FORTRAN standard (ANSI
 X3.9-1978, which both mainframe and microcomputers follow), in the
 section concerning functions and subroutines, a MOD function is
 described that is used for remaindering, not for appending data to a
 file.
    The only function we are aware of that you may be thinking of is
 the specifier that some FORTRANs have added to the OPEN statement for
 example, ACCESS=APPEND. However, this is not part of the ANSI
 standard.
    At any rate, there is no mechanism in the ANSI standard to append
 to the end of files, and we have not added one. The only way to append
 to the end of a file is to do the following:

    1. Read from an old file.
    2. Write to a new file.
    3. Repeat (1) and (2) until reaching end-of file on the old file.
    4. Write new information to the new file.


 333. Incorrect Expression Evaluation

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q11347

 Problem:
    The expression '(I - 1) * 256' is not being evaluated correctly.
    When $STORAGE:2 and $DEBUG metacommands are used and I is given the
 value 128, an integer overflow error occurs.
    The following code example demonstrates this behavior:

       $STORAGE:2
       $DEBUG
       PROGRAM TEST
       I = 128
       J = (I - 1) * 256
       END

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.00.


 334. Problem Assigning Format Label

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.31 fixlist4.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q11356

 Problem:

 There is a problem associated with assigning a format label to an
 integer variable using the ASSIGN statement, then using the format
 label more than once in a WRITE statement.

 The following is a code sample that reproduces this behavior:

        PROGRAM TEST
        ASSIGN 4 TO I
        WRITE(*,4)' HELLO'
        WRITE(*,4)' HELLO' 4 FORMAT(A6)
        END

 Response:

 Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler. This problem was corrected in Version 4.00.


 335. Incorrect Code Generated when Passing the Same Argument Twice

 Product Version(s): 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q31420

 The following program generates bad code when compiled with
 optimization on; it works correctly when compiled with -Od:

 C     Beginning of program
       call sub(i, i)
       end
 C--------------------------
       subroutine sub(i, j)
       i=17
       j=44
       write(*, *) i, j
       return
       end

 Because FORTRAN is passed by reference, this program should print out
 "   44    44   ". This is the result with optimization off; however,
 the result is "  17    44   " when the optimization is turned on.

 This problem occurs when the optimizer is on because it forces
 incorrect mov instructions, which causes a "pass by value" result.

 Microsoft has confirmed this to be a problem in FORTRAN Version 4.10.
 This problem was corrected in Version 5.00.

 The following assembly code was taken from an assembly dump of the
 program above.  This fragment comes after the initialization of I
 and J and before the CALL to __FFwr ( write function ):

 Optimization off:                       On:
 ( moves address )                       ( moves value )

 les   bx, dword ptr [bp+6]              mov ax, 44
 push  word ptr es:[bx+2]                cwd
 push  word ptr es:[bx]                  push dx
 ;                                       push ax
 ;
 les   bx dword ptr [bp+10]              mov  ax, 17
 push  word ptr es:[bx+2]                cwd
 push  word ptr es:[bx]                  push dx
                                         push ax

 The following command line was used:

    FL -AL -FPi -Zi -Fs -Fa -O? test.for.


 336. Carriage-Control Character Not Recognized

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q31421

    The carriage-control character, '1', is not recognized as a
 carriage-control character and is printed out as the character one.
    In the following example program, using the format specifier 'Nx'
 in a previous FORMAT edit list causes subsequent formatting to be
 corrupted. The string output is unexpectedly moved to the right by N
 spaces, and so the carriage-control character is not in position to be
 used by the printer.
    A workaround is to use the edit decriptor for end-of-record, '/',
 in the first position in the subsequent FORMAT's editlist.
    This is a known problem with Version 4.00. This problem was
 corrected in Version 4.01.

    The following is the example program:

       CHARACTER*72 RFMT,TITLE
       OPEN(5,FILE='TRY.INP')
       OPEN(6,FILE='PRN')
       READ(5,5)RFMT
     5 FORMAT(A)
       READ(5,5)TITLE
     1 READ(5,RFMT,END=3)X,Y
       GO TO 1
     3 WRITE(6,9)TITLE
     9 FORMAT('1',A)
       WRITE(6,2)X,Y
     2 FORMAT('-','X IS',F15.5/
      1     '-','Y IS',F15.5)
       STOP
       END

    The input file contains the following:

 (5x,f5.1,6x,f6.0)
 titlestring
   5.7  6.9  3797 36778
   6.5  6.9  4099 36588

    The output on the printer appears as follows:

      1titlestring
 X IS        6.90000
 Y IS    36588.00000

    The workaround statement is to replace the following FORMAT line:

    9 FORMAT('1',A)

    with the following:

    9 FORMAT(/'1',A)

    This process will produce the correct output, as follows:

 titlestring
 X IS        6.90000
 Y IS    36588.00000


 337. Logical Expressions in Parameter List

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.31
 Last Modified: 12-MAY-1988    ArticleIdent: Q11584

 Problem:
    There is an inconsistency in the way the compiler evaluates logical
 expressions when they are used as parameters in a function call.
    Specifically, if a logical expression involving a real number is
 used as a parameter in a function call, it is not properly evaluated
 before being passed to the function.
    The following is a program that demonstrates this behavior:

    integer iso
    real riso
    logical chkr,t1,t2
    iso=45
    riso=45.0

    if (chkr(.TRUE.,(riso.ge.0.0), (riso.lt.180.0))) then
    write(*,*) 'real true'
    else
    write(*,*) 'real false'
    endif

    t1=(riso.ge.0.0)
    t2=(riso.lt.180.0)
    if (chkr(.TRUE.,t1,t2)) then
    write(*,*) 'real true'
    else
    write(*,*) 'real false'
    endif

    stop
    end

    logical function chkr(b1,b2,b3)
    logical b1,b2,b3

    chkr=(b1.and.b2.and.b3)
    if (chkr) return
    write(*,*) 'error'
    return
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.00.


 338. Problem with LLE()

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: enduser | buglist3.31
 Last Modified:  2-MAY-1988    ArticleIdent: Q11583

 Problem:
    The function LLE() does not handle the characters "z" and "Z"
 correctly if they are embedded in a string. If the function is given
 two single characters to compare, it will return the correct value.

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler. The problem was corrected in Version 4.00.


 339. C Attribute on Named Common

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q11664

 Problem:
    The C attribute on a named common apparently has no effect. Because
 of this limitation, you must actually call a FORTRAN routine to access
 FORTRAN common from a C program. This will return a pointer to the first
 element in common.
    The following is a code sample that demonstrates this behavior:

    subroutine test
    common/stmt [C]/j(3)
    j(1)=3
    j(2)=5
    j(3)=8
    stop
    end

 Response:
    You can work around this problem by using the "ALIAS" attribute,
 which gives your variable a lowercase name preceded by an underscore.
 The following is an example:

    SUBROUTINE TEST
    COMMON /STMT [ alias:'_stmt' ] / j(3)
    j(1)=3
    j(2)=5
    j(3)=8
    STOP
    END

    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler.
    The problem was corrected in Version 3.31.


 340. Logical*1 Arrays Written Incorrectly

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified: 31-MAY-1988    ArticleIdent: Q26267

 Problem:
    The following program :

         LOGICAL*1 TBP(8)
         OPEN(1,FILE='B',STATUS='OLD')
         READ(1,*)TBP
         WRITE(*,*)TBP
         WRITE(*,*)TBP(1),TBP(2),TBP(3),TBP(4),TBP(5),TBP(6),TBP(7),TBP(8)
         REWIND(1)
         READ(1,*)TBP(1),TBP(2),TBP(3),TBP(4),TBP(5),TBP(6),TBP(7),TBP(8)
         WRITE(*,*)TBP
         WRITE(*,*)TBP(1),TBP(2),TBP(3),TBP(4),TBP(5),TBP(6),TBP(7),TBP(8)
         END

 produces the following output:

         F F F F F F F F
         F F F F F F F F
         T T T T T T T T
         T T T T F T T F

    Only the last line of the output is correct.

 Response:
    Changing the logical*1 declaration to logical*2 produces correct
 output for all write statements.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 341. Syntax Errors Hang Compiler

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified: 31-MAY-1988    ArticleIdent: Q26268

 Problem:
    The following program issues the expected messages for the syntax
 errors, then the compiler hangs:

               IF (I) THEN
                 X=0
               ELSE IF (I.GT.0) THEN
                 X=1
               ENDIF
               IF (I.EQ.0) THEN
                X=0.
               ELSE IF (I) THEN
                X=1.
               ENDIF
               END

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.


 342. FORTRAN: /4Yb Switch Causes F2367 Range Error

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10
 Last Modified: 16-JUN-1989    ArticleIdent: Q31422

 Compiling with the /4Yb debug switch causes the following error:

    F2367 : value nnnnn : INTEGER : range error

 This error occurs when the high order (sign) bit is set, i.e., for
 values between -32768 (#8000) to -1 (#FFFF) ), as follows:

       integer*2 i

       i = #7fff          OK
       i = #8000          Fails with /4Yb switch
       i = #ffff          Fails with /4Yb switch

 The compiler is not performing the correct conversion from an unsigned
 hexadecimal value to a signed decimal value when the /4Yb switch is
 used.

 This is a known problem with the FORTRAN compiler Versions 4.01 and
 4.10. Microsoft is researching this problem and will post new
 information as it becomes available.


 343. FORTRAN: Internal Compiler Error: ctypes.c 1.89, Line 428

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q31483

 The program below will cause the following error when compiled with FL
 /Od LINE482.FOR.:

 line482.for
 line482.for(18) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)ctypes.c:1.89', line 428)
                 Contact Microsoft Technical Support

 The program below should not generate the internal compiler error.
 However, the program code is incorrectly passing the wrong type of
 arguments to connect.

 To work around this problem, declare "x" and "y" as characters and
 initialize them as such. This will prevent the internal compiler error
 and allow the function to execute properly. Use the EQUIVALENCE
 function if you want to access the variables in different ways.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The program code is as follows:

     interface to integer*2 function connect[pascal](c,l)
       character*40 c, l
       end

       integer*2 connect, x, y, s
       x = 1
       y = 2
       s = connect(x,y)

       end


 344. Bound Programs in DOS Version 2.x Give Error SYS 2090

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | s_c h_masm s_pascal
 Last Modified: 23-JUN-1988    ArticleIdent: Q31499

    Bound programs generate the following error under DOS Version 2.x
 when that program does not reside in the current directory:

    SYS2090: The system is unable to load the program

    The workaround is to make sure that the following programs reside
 in the current working directory, or to switch over to DOS Version
 3.x. Make certain that that if you are using DOS Version 3.x , your
 version of COMMAND.COM reported by "command" matches your version of
 DOS reported by "ver".
    Microsoft is researching this problem and will post new information
 as it becomes available.

    This error is generated even if the full drive path of the program
 is given or if the program is in a directory that is in the PATH.
 These programs include the FORTRAN compiler Version 4.10, the PASCAL
 compiler Version 4.00, and bound versions of the following utilities
 that are packaged with C Version 5.10, MASM Version 5.10, FORTRAN
 Version 4.10, and Pascal Version 4.00:

      SETUP.EXE
      CREF.EXE
      CVPACK.EXE
      MAKE.EXE
      LIB.EXE
      EXEHDR.EXE
      LINK.EXE
      IMPLIB.EXE
      BIND.EXE


 345. FORTRAN: WRITE to Screen Truncates String in 4.10

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q31513

 The following code demonstrates an error in the FORTRAN Version 4.10
 compiler. A subroutine called prior to a WRITE statement fails to
 correctly process a character string unless a WRITE statement is
 present before a certain assignment in the subroutine, or optimization
 is turned off (/Od).

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following program demonstrates a problem with the FORTRAN
 compiler. The routine should print "N7A", but does not do so unless
 the WRITE statement in the subroutine below is installed, or /Od is
 used:

        IMPLICIT INTEGER (A-Z)
        DIMENSION WIN(4)
        DATA WIN/'N','7','A',' '/
        DATA BLANK/' '/
 C
        WOUT=BLANK
        DO 2 I=1,4
        CALL BYTE2(WIN(I),1,WOUT,I)
      2 CONTINUE
        WRITE(*,'(A,A4,A)') ' ** BYTE2:''',WOUT,''''
        STOP
        END
 ***********************************************************************
 ***********************************************************************
       SUBROUTINE BYTE2(WIN,INBYT,WOUT,IOBYT)
       IMPLICIT INTEGER (A-Z)
       CHARACTER*1 AIN,AOUT
       DIMENSION AIN(4),AOUT(4)
       EQUIVALENCE (AIN,XIN),(AOUT,XOUT)
 c
       XIN=WIN
       XOUT=WOUT
 C     WRITE(5,'(1x,a4)')wout
 C  Reinstalling the above WRITE statement corrects the problem.
       AOUT(IOBYT)=AIN(INBYT)
       WOUT=XOUT
       RETURN
       END


 346. L2029 "Unresolved Externals" Error in FORTRAN Library

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JUN-1988    ArticleIdent: Q31577

    It is likely that the FORTRAN libraries were built with C
 compatibility if many type L2029 "unresolved externals" errors occur
 on names beginning with an underscore when linking a FORTRAN program.
    A problem will occur when the FORTRAN library is built with C
 compatibility and the C libraries are not also linked in. This problem
 will occur even if no C modules, only FORTRAN modules, are linked in.
    When a FORTRAN library is set up to be C compatible, the routines
 that are in common between C and FORTRAN are removed from the FORTRAN
 library. The user must link with the C libraries each time to make
 those routines available to the linker, even if only FORTRAN modules
 are being linked in.
    This error also will occur if the linker being used is not the
 latest version; it also can be caused by TSR interference. When these
 two common reasons for the L2029 error are eliminated, check the
 libraries to see if they contain the module that is unresolved. This
 can be done with the library manager LIB.EXE file.


 347. Carriage-Control Processing only on Terminal Files

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-NOV-1988    ArticleIdent: Q37543

 Carriage-control processing is only performed on terminal files, i.e.,
 screen and printer files (LPT1). Therefore the following code will not
 process the carriage-control character:

       character*6 b
       integer c(31)
       open(unit=11,file='LPT2',form=formatted,status=new,iostat=ios);
       write(11,1,iostat=ios) b,c
 1     format('+',a,31a4)

 The '+' is printed out to LPT2 as a character instead of carriage
 control for printing. This is because LPT2 is not a terminal file.


 348. Linking FORTRAN and C, "L2044 _FF_MsgBanner Multiply Defined"

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C 5.00 5.01
 Last Modified: 20-APR-1989    ArticleIdent: Q31609

 Problem:

 When linking FORTRAN and C modules, I receive the error "L2044
 _FF_MsgBanner Symbol Multiply Defined." I have set up FORTRAN for C
 compatibility and I am linking with the /NOE switch.

 Response:

 When using FORTRAN Version 4.00 or 4.01 with C 5.00 or C 5.10, you
 need to run the F4COMPAT file to make your FORTRAN libraries C
 compatible because FORTRAN Versions 4.00 and 4.01 were written in C
 Version 4.00.

 If the /NOD switch is used, altering the order of the libraries may
 change the error message received. When the FORTRAN library is first,
 the error may be "R6002 Floating Point Not Loaded." When the C library
 is first, the error is "Symbol Multiply Defined."


 349. Infinite Loop and Protection Violation Error in FORTRAN 4.x

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q31649

 The following code will repeatedly loop when compiled and executed in
 real mode with FORTRAN 4.00, 4.01, or 4.10. In OS/2, this code
 produces a protection violation during compile time.

 The workaround is to compile with either /Od or /Odct.

 Microsoft has confirmed this to be a problem in the FORTRAN compiler
 Versions 4.00, 4.01, and 4.10. This problem was corrected in Version
 5.00.

 The following code demonstrates the problem:

        DATA LIMIT/57/, JUMP/14/
 C
   110  FORMAT(4I12)
        PAUSE 0
        DO 120 KOUNT = 1, LIMIT, JUMP
   120  WRITE(*,110) KOUNT, LIMIT, JUMP
        PAUSE 'DO-loop done'
        LOOP = JUMP
   130  WRITE(*,110) LOOP
        LOOP = LOOP - 1
        IF (LOOP .GT. 0) GOTO 130
        PAUSE 'GOTO-loop done'
        DO 140 KOUNT = 1, LIMIT, JUMP
   140  WRITE(*,110) KOUNT, LIMIT, JUMP
        PAUSE 'DO-loop done'
        WRITE(*, '(/'' Do we see this message???'')')
   150  END

 The line "Do we see this message???" appears only when this code is
 compiled with /Od or /Odct in real mode. When compiled in protected
 mode, the compiler will issue a protection violation error.


 350. System Languages Do Not Generate 386-Code, 32-Bit Addressing

 Product Version(s): 3.x 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER | S_Pascal h_masm S_C S_QuickC
 Last Modified: 18-AUG-1988    ArticleIdent: Q31663

    The system languages C, FORTRAN, MASM, and Pascal do not generate
 386-code or use 32-bit addressing. However, the Microsoft Macro
 Assembler will assemble 386 instructions, but it will not use 32-bit
 addressing. For more information on the Macro Assembler, please see
 the "Microsoft Macro Assembler Programmer's Guide" (Version 5.10).
    This limitation occurs because the operating systems on which our
 system languages operate, MS-DOS and OS/2, do not make use of the
 32-bit addressing available with the 80386 processor. These operating
 systems, and the system languages, will all execute on a 80386
 machine; however, they will behave as if it is a fast 80286 machine.
 The high-level system languages have the compile-time options /G0,
 /G1, and /G2. These options tell the compiler to generate code for the
 8086/88, 80186/188 and 80286, respectively.


 351. Returning a Floating-Point Value to FORTRAN from Assembly

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JUN-1988    ArticleIdent: Q31714

   The following FORTRAN and assembly code will demonstrate how to pass
 an integer value to an assembly routine from FORTRAN, perform some
 floating-point function, and then return the new floating-point value.
 (For more information on returning a floating-point value to a FORTRAN
 main from an assembly procedure, see Pages 78-79, Section 6.1.6, in
 the "Microsoft Mixed-Language Programming Guide.")

        INTERFACE TO REAL*4 FUNCTION M(I,J)
        INTEGER*4 I,J
        END

        INTEGER*4 I,J
 C*****Note that the function M is defined below*****
        REAL*4 L,M
        I =  1680649580
        J = 32
        L = M(I,J)
        PRINT *, L
        END

 ;***********Assembly Module**********
 .MODEL LARGE
 .CODE
         PUBLIC  M
 M       PROC FAR
         push    bp      ;Save old base pointer
         mov     bp,sp   ;Establish bp as the "framepointer"
         sub     sp,4
         finit
         les     bx,DWORD PTR [bp+8]     ;J
         fild    DWORD PTR es:[bx]       ;Push J on the coprocessor stack
         les     bx,DWORD PTR [bp+12]    ;I
         fild    DWORD PTR [bx]          ;Push I on the coprocessor stack
         fdiv    ST,ST(1)                ;Perform the division
         mov     bx,WORD PTR [bp+6]      ;Move the return value offset into bx
         fstp    DWORD PTR [bx]          ;Pop the coprocessor stack
         fwait
         finit
         mov     ax,bx              ;Move the return value offset into ax
         mov     dx,ds              ;Move the data segment value into dx
         mov     sp,bp              ;Recover old stack pointer(sp)
         pop     bp                 ;Get old bp
         ret     10                 ;Return 10 since 2 4-byte args were passed

 M       ENDP
         END



 352. EQUIVALENCEing Subroutine Argument in FORTRAN 4.10

 Product Version(s): 4.10 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q31831

 The following subroutine causes a protection violation while it is
 compiling with the default switches under OS/2 with FORTRAN Version
 4.10.

 The workaround is to perform the EQUIVALENCE outside of the
 subroutine, and then pass both arguments to the subroutine.

 Microsoft has confirmed this to be a problem with FORTRAN Version
 4.10. This problem was corrected in Version 5.00.

 The following is a code example:

         subroutine sub (line)

         equivalence (lyne,line)
         return
         end

 Using a subprogram argument in an EQUIVALENCE statement does not
 conform to the FORTRAN 77 Standard. This subroutine causes the
 following syntax error with the FORTRAN Versions 4.01 and 4.10
 compilers under DOS:

 eq.for
 eq.for(3) : error F2312: LINE : EQUIVALENCE : formal argument illegal


 353. Third-Party Libraries Available for Microsoft FORTRAN

 Product Version(s): 3.x 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1990    ArticleIdent: Q31838

 Microsoft FORTRAN for MS-DOS provides a number of utilities and math
 libraries. In addition, there are a number of subroutines and
 libraries that can be obtained through third-party software vendors
 that could further speed your development.

 There are a range of graphic libraries available, such as the
 following:

 1. Plotting libraries (ATC, Microcompatibles, GSS), 3-D graphics
    (Microcompatibles)

 2. ANSI/ISO graphics (GSS, ATC)

 3. Image processing (Werner Frei)

 4. General graphics (Media Cybernetics)

 For data management, Softcraft provides Btrieve for ISAM support
 and Microrim provides a Microsoft FORTRAN program interface to its
 RBase product.

 Although FORTRAN math support is extensive, there are other more
 specialized math libraries available, such as the following:

 1. Modeling (Mitchell & Gauthier)

 2. FFT (MicroWay, Wiley)

 3. Vector

 4. Matrix

 5. Numerical analysis

 6. Signal and image processing libraries (Wiley, Quantitative
    Technology Corporation, Systolic Systems)

 7. Statistic (Wiley, IMSL, MAGUS, IMSL)

 8. Broad engineering/scientific math libraries (Wiley, NAG)

 General-purpose libraries are available through MEF that provide
 the following support in one package:

 1. Communications

 2. File management

 3. Graphics

 4. DOS

 5. Screen handling

 6. String handling

 Even very specialized libraries such as IEEE 488 Support (Tecmar)
 are available.

 Contact these third-party vendors for more information on their
 libraries for Microsoft FORTRAN or obtain a copy of the Language
 Support Directory by contacting Microsoft Sales and Service at (800)
 426-9400.


 354. Internal Compiler Error: p2symtab.c 1.85, Line 915

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q31846

 If the EQUIVALENCE statement follows the initializing TYPE statement,
 the correct F2311 error is generated. If the EQUIVALENCE statement
 precedes the TYPE statement, then P1 does not produce an error and P2
 fails with a p2symtab.c assertion error.

 The workaround is to declare the variables before you EQUIVALENCE
 them.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 The following internal compiler error was produced by the code
 below:

 t71.for
 t71.for(4) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)p2symtab.c:1.85', line 915)
                 Contact Microsoft Technical Support

 The following code demonstrates the problem:

        equivalence (fmt(1),prefix)
        character*4 prefix/'73h '/
        character*1 fmt(80)
        end

 If the EQUIVALENCE statement is placed after the two character-type
 lines, then the compiler will produce the correct error message, as
 follows:

 t71.for
 t71.for(3) : error F2311: PREFIX : EQUIVALENCE : preinitialization
 illegal


 355. Program Statement in Incorrect Order in Graphics Examples

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 23-APR-1990    ArticleIdent: Q60843

 The PROGRAM statement in the code examples listed below is incorrect
 and should come AFTER the INCLUDE 'FGRAPH.FI' statement, but BEFORE
 the INCLUDE 'FGRAPH.FD' statement. The code examples are from the
 "Microsoft FORTRAN Advanced Topics" manual listed on the following
 pages:

 1. Function getcolor on Page 204

 2. Subroutine getcurrentposition, getcurrentposition_w on Page 205

 3. Subroutine getfillmask on Page 207

 4. Function getpixel, getpixel_w on Page 215

 5. Subroutine setfillmask on Page 256

 In the examples listed above, the (incorrect) heading for the source
 code is as follows:

        PROGRAM [program_name]

        INCLUDE 'FGRAPH.FI'
        INCLUDE 'FGRAPH.FD'

 The headings should instead be as follows:

        INCLUDE 'FGRAPH.FI'

        PROGRAM [program_name]

        INCLUDE 'FGRAPH.FD'

 The include file FGRAPH.FI includes interface statements for the
 graphics routines in the graphics library. Microsoft FORTRAN requires
 the interface statements to be located outside of a program block of
 code in a source file. In the first example above, the interface
 statements would be placed inside the main program code block, thus
 causing compile errors. The second example above solves the problem by
 placing the interface statements outside of the main program block of
 code.


 356. FORTRAN Academic 10-Packs

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-APR-1990    ArticleIdent: Q60978

 Microsoft FORTRAN Academic 10-Packs is a new product for academic
 users.

 The FORTRAN Academic 10-Packs are designed for math, engineering, and
 scientific professors in schools and universities. Like Microsoft's
 other academic 10-packs, the FORTRAN 10-pack consists of 10 disk sets
 and one complete set of documentation, and is intended for use in
 labs. The suggested retail price, before discounts, is $1395. That
 equates to a per-workstation price, before discounts, of $139.50.

 The planned availability date is June, 1990.

 To order, or to obtain further information about the Microsoft FORTRAN
 10-Pack, call Microsoft Education Sales at [phone].

 Some of the benefits to the Microsoft FORTRAN Version 5.00 10-Packs
 are the following:

 1. Certified ANSI 77 FORTRAN compiler

 2. Selected ANSI 8X extensions

 3. A complete product, including the FORTRAN compiler

 4. The CodeView debugger

 5. The Microsoft Editor

 6. The same professional-quality software as the retail FORTRAN 5.00
    product

 Additional manuals and conversion to 3.5-inch or 5.25-inch disk sets
 are available through Microsoft's Education Sales.


 357. FORTRAN and C Compatibility in Protected Mode

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q32044

    When FORTRAN libraries have been built with C compatibility, link
 the FORTRAN and C modules as follows:

    LINK objs,,,LLIBCEP.LIB LLIBFEP.LIB DOSCALLS.LIB /NOE /NOD;

    It is not necessary to use F4COMPAT.BAT for protected-mode
 programs. Any of the three math packages can be used as long as they
 are consistent between the languages. The C library must be the first
 library, the FORTRAN library and DOSCALLS.LIB must be linked
 explicitly, and the switches /NOE and /NOD must be used. The /NOE
 switch is used to prevent symbols from being defined more than once
 (error L2025). The /NOD switch turns off the default library search so
 that the order of these libraries can be given explicitly.
    For information on linking real-mode programs, please refer to the
 "Linking Mixed-Language Programs" section in the C Version 5.00
 README.DOC.


 358. Missing Files for Writing C Extensions

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  7-NOV-1988    ArticleIdent: Q32046

 Page 68 of the "Microsoft Editor User's Guide," Section 8.1, states
 the following requirements for creating C extensions for the Microsoft
 Editor:

 "To create C extensions, you need to have the following files and
 software present in your current directory:

    Microsoft C Version 4.00 or later

    Microsoft Overlay Linker Version 3.60 or later or Microsoft

    Segmented-Executable Linker Version 5.01 or later

    EXTHDR.OBJ  (supplied with the editor)

    EXT.H       (supplied with the editor)

    SKEL.C      (a template that you can replace with your own code)"

 The three files EXTHDR.OBJ, EXT.H, and SKEL.C are not found on any of
 the Microsoft FORTRAN Version 4.10 Optimizing Compiler product disks.
 These three files are available from Microsoft System Languages
 Product Support by calling [phone].


 359. Proper Use of SCWRQQ and LCWRQQ

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER | docerr
 Last Modified: 25-JUL-1988    ArticleIdent: Q32110

    On Pages 362-363 of the "Microsoft FORTRAN Optimizing Compiler
 User's Guide," there are references to the SSWRQQ and SCWRQQ functions
 and the LCWRQQ subroutine. These functions do not appear to work
 correctly (they are procedures to set and clear the floating-point
 exceptions).
    The documentation is incorrect; the last line of Page 362 refers to
 "SCWRQQ", which should be "SSWRQQ", as follows:

    INTEGER*2 FUNCTION SSWRQQ

    You cannot declare the subroutine "INTEGER*2 FUNCTION SCWRQQ", as
 stated in the documentation. The keyword function cannot be in the
 declaration. The FUNCTION statement is used for declaring user-defined
 functions and for the interface statement, as shown on Pages 218 and
 241 of the "Microsoft FORTRAN Optimizing Compiler Language Reference,"
 respectively.
    The following is an example:

       call rndzr
       stop
       end

       subroutine rndzr
 c   not "integer*2 function scwrqq" as the documentation states
       integer*2 scwrqq
       integer*2 cw

 c   get old control word
       cw = scwrqq()

 c   set new control word variable
       cw = 16#133f

 c   actually set new control word
       call lcwrqq(cw)
       return


 360. Minimal Support for Writing DLLs in FORTRAN 4.10

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q32144

    FORTRAN Version 4.10 should not be used to write Dynamic Link
 Libraries (DLL) for OS/2.

    Writing Dynamic Link Libraries in FORTRAN Version 4.10 is not
 feasible. Although it is possible to write a DLL using FORTRAN Version
 4.10, it may not be very useful: you cannot call any FORTRAN library
 routines. This includes the following restrictions:

    1. No floating point math
    2. Very little INTEGER*4 math
    3. No I/O
    4. No character operations except assignments
    5. No $DEBUG metacommand support for extended run-time error
       information

    A FORTRAN Version 4.10 DLL should be code only, no data, and no
 data or stack segment. The .DEF (module definition) file for the
 FORTRAN DLL should have the "NODATA" statement within it. This
 restriction requires that the process calling the DLL have MS-FORTRAN
 compatible initialization code for setting up a stack and data segment
 that the DLL could use, such as the initialization code produced from
 a main program module in Microsoft C, MS-FORTRAN, or MS-Pascal.
    Routines in a FORTRAN DLL should be able to receive arguments from
 the calling process by means of the formal parameters for the DLL
 routines. FORTRAN passes arguments by reference (by default);
 therefore, the DLL could modify the content of the arguments as long
 as the above restrictions are followed.


 361. Huge Addressing under OS/2

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q32206

 When a huge array is allocated space, OS/2 allocates segments from the
 Segment Selector Table in increments of n+0i, n+1i, n+2i, etc., where
 "n" is the starting selector and "i" is the incremental value. The
 value of "i" must be determined at load time for different versions of
 the OS/2 and for different configurations of the similar versions. The
 way that huge addressing is performed under OS/2 is identical to the
 way in which DOS accesses huge addresses. However, under DOS, "i" is
 always 4,096.

 Below is an example of how to obtain the value of "i" in a FORTRAN
 program. The value of "i" is 2 raised to the power returned by
 DosGetHugeShift. This information is discussed in detail in the
 Microsoft Press book "Inside OS/2" by Gordon Letwin, Section 9.2.2.

 The following example shows how to obtain the value of "i" in a
 FORTRAN program:

        INTERFACE TO INTEGER*2 FUNCTION DosGetHugeShift
       + [ALIAS: 'DOSGETHUGESHIFT'] (SHIFT)
        INTEGER*2 SHIFT
        END
        INTEGER*2 SHIFT,DosGetHugeShift
        INTEGER*2 I
        I = DosGetHugeShift(SHIFT)
        PRINT *,'DosGetHugeShift = ',SHIFT
        PRINT *,'i = ',(2**SHIFT)
        STOP
        END


 362. Protection Violation When Compiled with Defaults under OS/2

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q32227

 The program below generates a protection violation when compiled with
 the defaults under OS/2. When compiling under DOS, the program either
 hangs the compiler or generates code that does not function properly.
 The error occurs only when the statement labeled 6 is in the program.

 The workaround for this problem is to compile the program with the
 /Odclt option; this causes the compiler to enforce alias checking
 during optimization.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The program is as follows:

 $STORAGE:2
 $NOFLOATCALLS
       COMPLEX F
       DIMENSION NUMBER(7),F(8192)
       N=16
       NROOT=4
       NRTWO=NROOT+NROOT
       NRQRT=NROOT/4
 5     CALL FFTO(F,N)
       NUMBER(3)=NUMBER(3)+N
 6     IF (NUMBER(3).LE.4096) GO TO 5
       WRITE(*,'(5H   T=,i3)')KLOCK()-K
       WRITE(*,'(8F9.4)')(F(I),I=N-NRTWO+1,N,NRQRT)
       WRITE(*,'(8F9.4)')(F(I),I=1,NRTWO,NRQRT)
       STOP
       END


 363. FORTRAN: Setting /link Options with FL Environment Variable

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 docerr
 Last Modified: 16-JUN-1989    ArticleIdent: Q32245

 Page 12 of the "Microsoft FORTRAN Optimizing Compiler Version 4.1
 Update" states that /link options can be specified with the FL
 environment variable. However, setting any /link options with the FL
 environment variable will cause the compiler to cease compiling with
 the following command line error:

    Command line error D2003 : missing source file name

 This problem is caused by the compiler reading the /link option before
 it has read the source filename. The identical error will occur if the
 /link option is given at the FL command before the source file, as in
 the following example:

    FL /link /INFO source.for


 364. The FORTRAN Substitute for C-Style Pointers (DOS and OS/2)

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q32253

    This article applies to both MS-DOS and MS OS/2 FORTRAN.
    On many computer systems, advanced FORTRAN programmers have been
 able to get around the lack of C-style pointers by using the intrinsic
 function LOC to get the address of variables and then calculating the
 out-of-bounds index to an array variable that will access the value of
 another variable. When this is attempted in Microsoft FORTRAN, some
 problems occur that are not traditionally a problem for FORTRAN
 programmers.

    The idea is to access the value of a variable by indexing outside
 the bounds of an auxiliary array. This is the FORTRAN kludge that
 substitutes for C-style pointers, which FORTRAN does not have. The
 following program fragment illustrates the method for NON-HUGE
 addressing:

          INTEGER*2 BASE(1),VAL1,VAL2
          INTEGER*4 VAL1_PTR,VAL2_PTR
           ...
          VAL1_PTR=(LOC(VAL1)-LOC(BASE))/2+1
          VAL2_PTR=(LOC(VAL2)-LOC(BASE))/2+1
           ...
 C                         These should match.   These should match.
          WRITE(*,*) VAL1, BASE(VAL1_PTR), VAL2, BASE(VAL2_PTR)

    For this method to work, the array must be allocated at a lower
 address than the variables to be referenced, and the type of the array
 must be the same as that of the variable accessed. Also, because the
 "pointer" we create is really an element index rather than a byte
 pointer, the array and the variable accessed must be aligned so that
 the distance in bytes between the beginning of the auxiliary array and
 the beginning of the variable accessed is divisible by the size of the
 value in bytes.
    This is not a problem for INTEGER*2s, because they are
 automatically aligned, or for any 1-byte types. But for 4-byte
 integers, for reals, and for character types other than CHARACTER*1,
 steps must be taken to enforce alignment, e.g. by using equivalence or
 common statements.
    Another problem occurs when the difference between the byte
 addresses of the variable and the base array is greater than 65536
 bytes. This causes the following problems:

    1. The base array must be accessed using huge indexing.
    2. The LOC function returns a standard DOS far pointer, which is
       not a linear address.

    LOC returns a double-word value: the high word contains the segment
 number and the low word contains the byte offset within the segment.
 Under DOS, the segment selector offset is 12 bits. Therefore, to get a
 linear address you have to shift the high word to the right 12 bits
 and add it to the low word. Under OS/2, the segment selector offset is
 variable and a call to the OS/2 system call DosGetHugeShift is
 necessary. To get a linear address you have to shift the high word to
 the right by HI_SHIFT bits and add it to the low word.
    The following code fragment is an example of how to calculate the
 linear HUGE address of the variable ABC:

       INTERFACE TO INTEGER*2 FUNCTION DosGetHugeShift
      + [ALIAS: 'DOSGETHUGESHIFT'] (HI_SHIFT)
       INTEGER*2 HI_SHIFT
       END
 C     ...
       INTEGER HI_SHIFT,LOC_ABC*4
 C  For DOS, HI_SHIFT would always be set to 12
       INTEGER*2 HI_SHIFT,DosGetHugeShift
       INTEGER*2 I
 C     ...
       I = DosGetHugeShift(HI_SHIFT)
       IF (I.NE.0) WRITE (*,*) 'Error getting Huge Shift'
       LOC_ABC=ISHFT(IAND(LOC(ABC),#FFFF0000),-HI_SHIFT) +
      +              IAND(LOC(ABC),#0000FFFF)
 C     ...
       END


 365. M Editor Converts Spaces to Tabs, Columns 73-80 Not Ignored

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-OCT-1988    ArticleIdent: Q32323

 The ANSI standard for FORTRAN specifies that columns 73-80 are to be
 ignored by the compiler. The M editor, using the default settings,
 takes every eight spaces and converts them into a tab character to
 save file space. This process causes problems for the compiler because
 it does not convert these tabs back into spaces.

 Therefore, even if you press the SPACEBAR to move to Columns 73-80,
 the compiler will read this as Column 9 because 72 spaces are
 converted to nine tabs, with eight spaces per tab. If you set ENTAB:0
 in your TOOLS.INI file, the M Editor will not convert spaces to tabs
 and the files will be suitable to FORTRAN.


 366. Error F2600: "Function Directly Recursive" Not Documented

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-JUL-1988    ArticleIdent: Q32344

    The FORTRAN compile-time error F2600 is not documented in the
 manuals or README.DOC files. The text of the error is "Function
 Directly Recursive." Recursive functions are not allowed in Microsoft
 FORTRAN, as documented on Page 218, second paragraph, of the
 "Microsoft FORTRAN Optimizing Compiler Language Reference" for
 Versions 4.00, 4.01, 4.10.


 367. PC and XT Floating Point Exceptions for C and FORTRAN

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00 H_Fortran
 Last Modified: 30-MAR-1990    ArticleIdent: Q32385

 When equipped with coprocessors, certain 8086 machines (IBM, Compaq,
 and clones) have exhibited floating-point exceptions. These
 exceptions, identified by error messages M6111 "Stack underflow" and
 M6101 "Invalid" are never supposed to occur with code generated by
 Microsoft compilers, as discussed on Page 284 of the "Microsoft C 5.1
 Optimizing Compiler User's Guide" and Page 448 of the "Microsoft
 FORTRAN 4.1 Optimizing Compiler User's Guide."

 This problem apparently occurs because the 8087 requires the 8086 to
 issue an FWAIT instruction prior to a coprocessor instruction. Also, a
 potential cause is that the BIOS does not meet specifications.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. The FWAIT problem was corrected in Version 5.00.

 An application note called FPFIX corrects the FWAIT problem. This
 application note is available from Microsoft Product Support Services
 by calling [phone]. BIOS upgrades should be considered as well.

 This information also applies to Microsoft C 5.10.

 The following information describes some of the problems inherent to
 the generation of floating-point exceptions M6101, M6108, M6110, and
 M6111. The errors M6101 and M6111 are of particular concern because
 the others offer alternate explanations, such as "too complex an
 expression."

 In the course of processing floating-point numbers, the 8087
 coprocessor runs into processing exceptions, for which INTEL has
 provided a variety of solutions. One solution is to mask the exception
 from your software. For a precise definition of masked, see the INTEL
 iAPX86/88.

 The other solution is to unmask the exception so an interrupt is
 issued and a software interrupt handler is invoked to deal with the
 exception. Microsoft prefers this solution. The basic architecture of
 the exception handling situation is as follows:

         _______                _______                 _______
        |       |     INTX     |       |       IR      |       |
        | 8086/8| <----------- | 8259A |  <----------- | 8087  |<--
        |_______|       2      |_______|        1      |_______|  |
            |                                      --->|_______|  |
            |                                      |              |
            |                                      |              |
       INTY | 3       _______                      |              |
            |        |       |                     |              |
            |        | bios  |----------------------              |
            |        |_______|                                  4 |
            |       _______________________________________       |
            |      |                                       |      |
            -----> |       MS INTERRUPT HANDLER            |------
                   |_______________________________________|

 Upon experiencing an exception, the 8087 issues an interrupt request
 (IR), which in the case of the 86/88, is fielded by the 8259A, the
 Programmable Interrupt Controller. In the 286 configuration, there are
 two 8259As (see Page 417 of the "MS-DOS Encyclopedia"). The 8259A then
 issues a hardware interrupt (INTX), which is received by the CPU. The
 CPU then issues a software interrupt (INTY), which is fielded by our
 interrupt handler.

 The interrupt handler clears the status flags and restarts the
 process. It appears this problem occurs because of the FWAIT
 instruction's omission. Another potential cause of the problem is the
 the BIOS version.

 The BIOs reportedly generating this problem is as follows:

    phoenix 1.46

 To diagnose a Compaq AT, run the Norton SI utility. If the date is
 4/85 or earlier, the BIOS most likely is faulty.

 The following machines reportedly cause these problems:

    IBM PC upgraded to a hard-disk configuration

    IBM XT with 3.5-inch drive

    ITT XL

    Compaq portable

    Compaq AT (prior to 4/85)

    The following references were used to prepare this information:

 1. "INTEL iAPX86/88 Programmers Reference Manual," Pages 6-18

 2. "INTEL iAPX86/88 Users Manual Hardware Reference," Section 3

 3. "INTEL 80286 and 80287 Programmers Reference Overview of
    Numeric Processing"

 4. "Microsoft C 5.1 Optimizing Compiler User's Guide"

 5. "Microsoft FORTRAN 4.1 Optimizing Compiler User's Guide"


 368. Internal Compiler Error: srclist.c 1.58 Line 1367

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  8-NOV-1989    ArticleIdent: Q32118

 Using the $SUBTITLE metacommand with the NULL set as an argument, and
 compiling with the /Fs switch, will generate the following fatal error:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)srclist.c:1.58', line 1367)
    Contact Microsoft Technical Support

 The following code generates the fatal error above when compiled with
 the /c and /Fs switches:

             $TITLE: 'Test Title'
             $SUBTITLE: ''
             END

 To work around this problem, do one of the following:

 1. Do not use the $SUBTITLE command with the NULL set. If you do not
    use the $SUBTITLE metacommand, FORTRAN will assign the NULL set to
    the subtitle set by default; therefore, using this metacommand is
    unnecessary.

 2. Do not compile with the /Fs switch. This process will cause the
    $SUBTITLE metacommand to be ignored.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.


 369. Using FORTRAN Version 4.10 SETUP to Build Libraries Only

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-OCT-1988    ArticleIdent: Q32524

 To build FORTRAN Version 4.10 libraries using the SETUP.EXE
 program, it is necessary to have previously set up the entire FORTRAN
 package, either by using the F choice in SETUP's Main menu screen or
 by copying the necessary files from the distribution disks by hand.

 Specifically, the LIB.EXE needed by SETUP must already be in your
 path. In addition, before running SETUP for building additional
 libraries, it is necessary to set the PATH so that the correct version
 of the LIB utility can be found by SETUP. Without this step, the
 message "error trying to run library manager" appears, and you are
 then returned to the SETUP Main menu.

 The Main menu gives the following choice, among the three choices
 presented:

 "To build a new library, press L. Do not try to build a new library
 unless you have already set up Microsoft FORTRAN."

 This message does not explain the necessity of having previously set a
 path to the LIB.EXE utility.


 370. Passing a FORTRAN Common Block to C

 Product Version(s): 4.00 4.01 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 12-JUL-1988    ArticleIdent: Q32665

    The following example demonstrates how to pass COMMON variables
 from FORTRAN to C. Make sure the memory models are consistent because
 FORTRAN and C have different defaults.

 FORTRAN PROGRAM

       INTERFACE TO SUBROUTINE CFUNC[C,ALIAS:'_cfunc']
       END
       INTEGER*2 A
       REAL*4 B
       CHARACTER*12 C
       COMMON /ABC[C,ALIAS:'_PTR']/ A, B, C

       A = 1
       B = 2.5
       C = 'HELLO WORLD' C
       CALL CFUNC()
       END

 C ROUTINE

 #include <stdio.h>

 void cfunc(void);      /* Function prototype                    */

 extern struct common_block
        {               /* structure that looks like the FORTRAN */
        int a;          /* common block                          */
        float b;
        char c[12];
        } PTR;

 void cfunc()
 {
 printf( "Element a = %d\n", PTR.a );
 printf( "Element b = %f\n", PTR.b );
 printf( "Element c = %s\n", PTR.c );
 }

 OUTPUT

 Element a = 1
 Element b = 2.500000
 Element c = HELLO WORLD


 371. Page Update-19 Refers to "Programmer's Guide"

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 21-JUL-1988    ArticleIdent: Q32745

    Page Update-19 of the "Microsoft FORTRAN 4.10 Optimizing Compiler"
 manual, in the section marked "Update (FORTRAN 4.1)", refers to a
 manual titled "Microsoft Operating System/2 Programmer's Guide." This
 manual is not part of the FORTRAN Version 4.10 package.
    Manuals titled "Programmer's Reference" and "Programmer's Learning
 Guide" are provided with the Microsoft Operating System/2 Programmer's
 Toolkit.



 372. Redirected Input Incorrect after Error

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q33103

    The following program will work correctly when taking input from
 the console. However, when the input is redirected to take input from
 a file, it incorrectly rewinds to the beginning of the file if an
 error occurs.
    To work around this problem, open the input file and read from that
 unit, rather than reading from a redirected Standard Out.

    The error occurs when redirecting input (TEST < TEST.INP) from a
 file to the TEST.EXE program.
    The following is a sample code:

   character*40 line
       real  z
 10    continue
       read (*,*, err=30) z
       write(*,*) 'z = ', z
       goto 10

 30    read(*,'(a)') line
       write(*,*) line

       stop
       end

    The TEST.INP input file for the TEST.EXE program is as follows:

 1.0 this is first
 2.0
 3.0
 s
 5.0 this should print
 6.0



 373. /4Yb ($DEBUG) Not Checking for Integer Overflow in FORTRAN 4.1

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33107

 When compiled with the /4Yb option (or $DEBUG), the program below will
 not check for integer overflow, as stated in the manual.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 To work around this problem, use a temporary variable instead of "k";
 replace "k = j * k" with "l = j * k". This process enforces the
 overflow checking.

 The following is a sample program:

 $DEBUG
       integer*2 i,j,k
       k = 1
       j = 2
 10    k = j * k
       write (*,*) k
       goto 10
       stop
       end


 374. Incorrect Code Generation in FORTRAN 4.10

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33109

 The FORTRAN Version 4.10 compiler seems to be generating some
 incorrect code in the following particular loop:

       INTEGER*2 A(3)
 10    READ(*,100,ERR=200) A(1)
 100   FORMAT(3I2)
       STOP
 200   GOTO 10
       END

 The program executes properly when an integer is entered; however,
 if a character or a number of characters (garbage) is entered, the
 error routine is called and the program goes back to the READ
 statement but falls. This problem causes an infinite loop at that
 point, jumping from 10 to 200 and back again, hanging the machine.

 By inserting a PRINT statement before the READ statement outside of
 the loop, the program will execute correctly. For example, place the
 following code line just before the READ statement:

       PRINT *,"HI THERE"

 Microsoft has confirmed this to be a problem in Version 4.10.
 This problem was corrected in Version 5.00.


 375. How to Combine Segments in DGROUP Part 2

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr S_QUICKC S_C S_PASCAL h_masm B_BBASIC B_QUICKBAS
 Last Modified: 30-SEP-1988    ArticleIdent: Q33114

 On Page 93 of the "Microsoft Mixed-Language Programming Guide" (and
 Page 307 of the "Microsoft QuickC Programmer's Guide" for Versions
 1.00 and 1.01 and Page 334 of the "Microsoft QuickBASIC 4.0 Learning
 and Using Microsoft QuickBASIC" manual), in the section describing how
 to combine segments in DGROUP part 2, the declaration is incorrect.

 The text incorrectly states the following:

 GROUP    DGROUP  _DATA _BSS

 The declaration should be as follows:

 DGROUP   GROUP   CONST, _BSS, _DATA

 Without this correction, assembling under Macro Assembler Versions
 5.00 or 5.10 will generate the "A2105: Expected: instruction,
 directive, or label" error. Under Macro Assembler Version 4.00, the
 assembly code generates the "error 10: Syntax error."


 376. Loop Optimization Problem in FORTRAN 4.10

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33118

 K does not get set to two with loop optimization on.

 To work around this problem, compile with /Odct.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following is a sample program:

 $STORAGE:2
       PROGRAM F77BUG
       DIMENSION  II(7),IJ(7),IP(7),NJ(3),NE(3)
       DATA II/0,1,2,2,3,4,5/,IJ/1,2,3,4,5,5,6/,IP/3,3,3,15,3,3,28/
       DATA NJ/3*1/,NE/1,0,0/
       IU37 = 37
       OPEN(IU37,FILE='XXX.LIS',STATUS='UNKNOWN')
       ME = 1
       NA = 7
 CC     ORIGINAL PROGRAM CODE
       ISQ = 0
   400 continue
       MP = 32001
       K  = 1
       J  = NE(K)
       DO 440 I = K,ME
   440 continue
       NE(I) = NE(I+1)
       ME = ME - 1
       ISQ = ISQ + 1
       IP(J) = ISQ
       L = IJ(J)
       NJ(L) = NJ(L) - 1
       WRITE (IU37,441) K,ME,J,ISQ,L,NJ(L)
   441 FORMAT(' AFTER 440 ',6I6)
       IF(NJ(L))450,450,400
   450 continue
       I = 0
       J = NA + 1
   500 continue
       K = (I + J) / 2
       WRITE (IU37,501) I,J,K,L,II(K),NA
   501 FORMAT( ' 500 I,J,K,L II(K),NA',6I6)
       IF(J - I  - 1)400,400,460
   460 WRITE (IU37,*) ' 460   L K II(K) ',L,K,II(K)
       IF(L - II(K))470,490,480
   470 continue
       J = K
       GO TO 500
   480 continue
       I = K
       GO TO 500
   490 WRITE (IU37,*) ' 490 NOTE!!!! K VALUE IS 1 . K L ',  K ,L
       WRITE (IU37,*) ' IN LINE ABOVE K = 2      !! '
       WRITE (IU37,*) ' F77 MODIFIED K FROM 2 TO 1 !! '
       IF(K - 1)510,510,520
   520 IF(L - II(K-1))510,530,510
   530 continue
       K = K - 1
       GO TO 490
 CC REPLACED TO AVOID LOOP
 C 510 IF(L - II(K))400,540,400
   540 IF(K - NA)550,550,400
   550 continue
 9      ME = ME + 1
       NE(ME) = K
       K = K + 1
       WRITE (IU37,551) K,L,II(K),ME
   551 FORMAT( ' 550 K,L,II(K),ME',5I6)
       GO TO 510
   510 CONTINUE
  1100 END


 377. FORTRAN: F2124: Code Generation Error

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q33267

 The following program will cause a "code generation error" when
 compiled with /Od or /4Yb:

       real k3
       y = 2 * k3 + 2 * k6
       return
       end

 The following error is generated:

    flew.for(2) : error F2124: Code Generation Error
                 Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10. This problem was corrected in Version 5.00.

 To work around this problem, break up the expression into separate
 expressions, one for the real variable k3 and one for the integer
 variable k6, and then combine the two expressions. The integer
 variable k6 could also be converted to a REAL, as follows:

    y = 2 * k3 + 2 * REAL (k6)


 378. FORTRAN Version 4.10 and C Compatibilty

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q33297

    When setting up FORTRAN Version 4.10, and you are asked whether to
 include C compatibility, consider that this option only will work
 correctly with C Version 5.00 or later.
    If you use C Version 4.00 and a FORTRAN library built with C
 compatibility, you will receive the "L2029 : Unresolved External
 __wrt2err" error.
    To work around this problem, build the FORTRAN libraries without C
 compatibility and use the /NOE switch at link time.



 379. Accessing Command-Line Arguments

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER | appnote
 Last Modified:  7-NOV-1988    ArticleIdent: Q33307

 An application note called "Version 4.x Accessing Command Line," which
 explains how to access the command line arguments under FORTRAN
 Versions 4.00, 4.01, and 4.10, is available from Microsoft Product
 Support Services by calling [phone].

 The application note contains two files that must be compiled and
 linked with the your main program. Also included is an example
 program, which when compiled and linked with the other two files will
 demonstrate how a FORTRAN program can access the command line
 arguments.

 The following is a list of the files that make up the application note
 and a short description:

    CMDLIN.FOR   This routine returns the current command line
                 and its length.

    DREF.FOR     This routine is called from subroutine
                 CMDLIN and serves to "de-reference" the
                 arguments "CMDIN" and "NIN," which are sent
                 to this routine as addresses passed by value
                 (courtesy of the INTERFACE statement in subroutine
                 CMDLIN).

    TSTCMD.FOR   This routine tests subroutine CMDLIN, which
                 returns the current command line and its
                 length.

 The three provided routines may be compiled by the following FL
 command:

     FL TSTCMD.FOR DREF.FOR CMDLIN.FOR


 380. FORTRAN Gives "Error F2115: Syntax Error"

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q33308

 Page 296 of the "Microsoft FORTRAN 4.1 Optimizing Compiler Language
 Reference Mixed-Language Programming Guide" (Section 6.2.5) states
 that the $FREEFORM metacommand (or the /4Yf switch) is a specifier
 that tells the compiler that the source file is in the free-form
 format.

 In free-form FORTRAN programs, statement line numbers may start on a
 column other than column 1. Versions 4.01 and 4.10 of the compiler
 both generate "error F2115: syntax error."

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the Microsoft FORTRAN Optimizing Compiler. This problem was
 corrected in Version 5.00.

 To work around this problem, make sure all the labels start in the
 first column.

 The following sample code demonstrates the problem:

 $FREEFORM
 write (*,1)
 1           format( 1x, 'Label on column 1 is OK' )

  write (*,2)
  2          format( 1x, 'Gives error F2115: syntax error' )

 end


 381. FORTRAN: Common Subexpression Optimizer Fails in 4.10, 5.00

 Product Version(s): 4.10 5.00   | 4.10 5.00
 Operating System:   MS-DOS      | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33309

 The code below demonstrates a bug in the common subexpression
 optimizations of Versions 4.10 and 5.00 of the FORTRAN compiler. If
 you compile this code with the full optimization default, the
 resulting output for the variable C is incorrect.

 Microsoft has confirmed this to be a problem in Versions 4.10 and
 5.00. We are researching this problem and will post new information as
 it becomes available.

 To work around this problem, compile the code with /Odlt optimization,
 or change the line C=X(I) to an equivalent statement, as follows:

    TEMP = I
    C = X(TEMP).

 This problem occurs because the optimizer generates code for the line
 C=X(I) that reevaluates the division of A and B rather than doing a
 simple assignment. This process assigns C to 1.0 regardless of the
 input values of A, B, or X(I).

 The following is a sample code:

               real x(10)
               read(*,*) i,a,b

               x(i)=a/b
               a=b
               c=x(i)

               write(*,*) c
               end


 382. Interfacing between Assembly Language and FORTRAN

 Product Version(s): 4.00 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | h_masm
 Last Modified: 18-AUG-1988    ArticleIdent: Q33351

    When assembler routines are called from FORTRAN, the assembler
 routine should obey certain rules.
    The first rule applies if you compile your FORTRAN routine with /Os
 or /Op. Optimizing your program will cause FORTRAN to use the SI and
 DI registers extensively. An assembly routine that changes SI and DI
 is responsible for saving and restoring the registers. The Microsoft
 FORTRAN Compiler also assumes that the direction flag is always
 cleared.
    In assembler, the direction flag can be cleared by using the CLD
 instruction. As a general rule, the segment registers, DS, SS, and ES
 should also be preserved.
    For more information on this topic, see the "Microsoft
 FORTRAN Optimizing Compiler User's Guide", Chapter 11 "Interfaces with
 Assembly Language and C," section 11.2.9 "Register Considerations."



 383. Using C for Carriage Control for FORTRAN OUTTEXT

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-JUL-1990    ArticleIdent: Q63966

 The OUTTEXT graphics function included with Microsoft FORTRAN version
 5.00 does not provide any carriage control features. Some carriage
 control can be added by calling OUTTEXT from a C subroutine and
 passing a C string to the function. The C string can include some of
 the escape sequences described on Page 16 of the "Microsoft FORTRAN
 Reference" manual for version 5.00. The '\n' sequence, for example,
 will generate a new line.

 The following code shows an example of passing a string to a C
 subroutine and using the OUTTEXT function:

 FORTRAN CODE

       INTERFACE TO SUBROUTINE outc [C] (cstring)
       CHARACTER*(*) cstring [REFERENCE]
       END

       INCLUDE 'fgraph.fi'

       PROGRAM out

       INCLUDE 'fgraph.fd'

       INTEGER*2 dummy
       CHARACTER*10 cstring

       dummy = setvideomode($MAXRESMODE)

       cstring = 'LINE 1\n' C               ! C string with
       CALL outc(cstring)                   ! escape sequence

       cstring = 'LINE 2' C
       CALL outc(cstring)

       READ (*,*)
       dummy = setvideomode($DEFAULTMODE)
       END

 C CODE:

 void outc(char * string)
 {
     _outtext(string);
 }

 The output produced by this code is as follows:

 LINE 1
 LINE 2

 If OUTTEXT is called from FORTRAN, the C string escape sequence '\n'
 is not recognized, and a new line is not generated. There is a
 difference between the way in which OUTTEXT is used and interpreted
 between the two languages.

 Not all the C string escape sequences listed in the FORTRAN
 manual are supported in graphics mode.

 The sequences that are supported are as follows:

    \n, \r, \\, \'', \", \xhh, and \ooo

 The sequences that are not supported are as follows:

    \a, \b, \f, \t, and \v

 This program was tested using versions 5.10 and 6.00 of C under DOS
 and OS/2. To compile and link this program use the following:

         FL /c out.for
         CL /c  /AL outc.c

         (linking under DOS)

         LINK out outc,,,/nod /noe (flib) (clib) graphics;

         where:
                 (flib) is the FORTRAN library,
                 (clib) is the C library, and
                 'graphics' is the FORTRAN 5.00 Graphics Library.

 It is NOT necessary to link with the C Graphics Library. The OUTTEXT
 function is resolved correctly with the FORTRAN library.

         (linking under OS/2)

         LINK out outc,,,/nod /noe (flib) (clib) doscalls
                 grtextp;

         where:
                 'doscalls'is the import library for OS/2 API
                         calls, and
                 'grtextp' is the FORTRAN 5.00 OS/2 Graphics
                         Library.

 When linking with the C 6.00 libraries, it is possible to get the
 following errors:

    ...L2025: STKHQQ : symbol defined more than once
    ...L2025: __aaltstkovr : symbol defined more than once
    ...L2025: __chkstk : symbol defined more than once

 Under DOS this does not affect the program. Under OS/2, however,
 running the program causes a system error. This can be corrected by
 removing the CHKSTK module from the FORTRAN library. For more
 information on this process, query on the words following words:

    L2025 and CHKSTK.ASM


 384. Loop Optimization Problem

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33480

 The following program incorrectly executes the loop only once when
 compiled with loop optimization:

       PROGRAM TEST
          INTEGER J(16:30)
          DO 20 I=16,30
 20    J(I) = 2**(62-2*I)
          WRITE (*,'(I11)') J
          END

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 To work around this problem, either disable the loop optimization or
 make the following modification to the code:

 20       J(I) = 2**(62-(2*I))

 By forcing the desired order of precedence with parentheses, the loop
 is correctly executed.


 385. Internal Compiler Error ctypes.c 1.89 Line 1601

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33484

 When compiled with /Od, the code below generates the following error:

           fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)ctypes.c:1.89', line 1601)
                 Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00. The workaround is given below.

 The following is the code:

       subroutine feedch()

       double precision nr, sri, ssg, vgc, zabp, dent1,
      +                 dent2, dent3

       IF (NRSW.EQ.1)
      1 NR=117.4D0-363.D0*SRI+263.7D0*SSG+288.6D0*VGC-69.2D0
      2    *ZABP*1.D-3+40.6D0*ZABP*ZABP*1.D-6

       end

 This error can be avoided by compiling with any optimization other
 than /Od, or by changing the code to the following:

       IF (NRSW.EQ.1)
      1  THEN
         dent1 = 117.4d0 - (363.d0 * sri)
         dent2 = (263.7d0 * ssg) + (288.6d0 * vgc)
         dent3 = (69.2d0 * zabp * 1.d-3) + (40.6d0 * zabp *
      1         zabp * 1.d-6)
         nr = dent1 + dent2 - dent3
         endif


 386. Linking FORTRAN Version 4.10 with Version 3.3x Modules

 Product Version(s): 3.20 3.3X 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-JAN-1989    ArticleIdent: Q35397

 I am linking some FORTRAN Version 4.10 object modules with object
 modules that have been compiled with FORTRAN Version 3.20 or 3.3x. I
 have built the Version 4.10 libraries with Version 3.30 compatibility
 and I am linking with compatibility library, FORTRAN.LIB. I always
 receive the errors below.

 The solution to this problem is to use the /NOD switch and to
 link with the FORTRAN.LIB first.

 The following errors demonstrate the problem:

 Microsoft (R) Segmented-Executable Linker  Version 5.01.20
 Copyright (C) Microsoft Corp 1984-1988.  All rights reserved.

 d:\lib\FORTRAN.LIB(MANV) : error L2025: __fltused : symbol defined more than
 once
  pos: 4F38 Record type: 7D04

 LINK : error L2029: Unresolved externals:

 __cfltcvt_tab in file(s):
  d:\lib\LLIBFORE.LIB(..\fltused.ASM)
 __cfltcvt in file(s):
  d:\lib\LLIBFORE.LIB(..\fltused.ASM)

 There were three errors detected.

 This problem occurs because the linker first tries to resolve all the
 externals in the .OBJs. It will resolve as many externals as possible
 from the first library and then try to resolve the functions that the
 library has. It will then go to the next library and do the same
 thing. It will not go back to the previous libraries, so the order of
 the libraries is critical.

 The following is an example of a proper link line:

 LINK test1.obj test2.obj,,,fortran.lib llibfore.lib /NOD;

 For more information on Versions 3.20 or 3.30 compatibility, see
 section 2.4.6.6 in the "Microsoft FORTRAN Optimizing compiler User's
 Guide", Page 33.


 387. Integer Overflow Is Not Flagged for Some Values

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33719

 Version 4.10 of the FORTRAN Compiler does not flag the range
 2,147,614,720 to 4,295,229,439 as an integer overflow for an INTEGER*4
 variable. The maximum value for an INTEGER*4 is 2,147,483,647.

 The sample code below demonstrates this problem. If you enter a number
 within the above inclusive range, this program returns an erroneous
 value. If you enter a number that is larger than the largest INTEGER*4
 value, but not within this range, an integer overflow and subsequent
 read error occurs.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in version 5.00.

 The following is the sample code:

        INTEGER*4 TEMP
        TEMP = 0

        write(*,*) 'enter an integer value'
        READ(*,*,err=20) TEMP
        write(*,*) 'result:'
        write(*,*) temp

 20     write(*,*) 'Error in read statement'
 30     END


 388. FORTRAN Compiler Causes a Null-Pointer Assignment

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33727

 The sample code below causes the "F1900: Maximum memory allocation
 size exceeded" error, then generates a null-pointer assignment error
 R6001 when compiled under DOS.

 Under OS/2, the result is a general-protection failure. However, in
 the DOS compatibility box, the result is simply the error F1900 with
 no subsequent null-pointer assignment.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following is the sample code:

 $INCLUDE:'INFTST1.INF'
         SUBROUTINE INFTST1(A,N)

         INTEGER*2       N
         INTEGER*2       A(N)
         A(1) = 1
         END

 c      (include file: inftst1.inf)
         INTERFACE TO SUBROUTINE INFTST1(A,N)
         INTEGER*2       N
         INTEGER*2       A(N)
         END


 389. Internal Compiler Error exphelp.c:1.55, Line 1308

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  5-AUG-1988    ArticleIdent: Q33728

    The sample code below generates the following error:

    test.for(9) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)exphelp.c:1.55', line 1308)
                 Contact Microsoft Technical Support

    Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.01.
    This error can be avoided by compiling with /Odclt.

    The following sample code demonstrates the problem:

       program grid
       real gridd(4,4), nugrid(4), x(4)
       data x/-1000.0, -5000.0, 0.0, -7500./
       data ((gridd(i,J), i=1,4), J=1,4) /-3.0, 1.0, 0.0,0.0,
      +5.0,-24.0,5.0,4.0,0.0,1.0,-5.0,0.0,0.0,4.0,0.0,-34.0/
       print *, 'grid(4,4)  :'
       print *, ((gridd(I,j), i=1,4), j=1,4)
       do 20 k=1,4
         do 10  i=1,4
             do 10 j=1,4
 c            temp=gridd(i,j)*x(j)
             nugrid(k)=nugrid(k)+temp
 10    continue
 20    continue
       print *, 'nugrid = ',(nugrid(n), n=1,4)
       end


 390. Formatted READ Reads Past CTRL+Z in Disk File

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-JAN-1989    ArticleIdent: Q34060

 Question:

 I updated to FORTRAN Version 4.10 from FORTRAN Version 3.31. My
 program reads a formatted file that contains a CTRL+Z character to
 mark the end of the file. Because the file was created with an old
 program that uses File Control Block (FCB) I/O, the file is padded to
 a 128-byte boundary with random characters after the CTRL+Z.

 My program worked correctly under Version 3.31, stopping when it hit
 the CTRL+Z. However, it reads right past the CTRL+Z under Version
 4.10, not stopping until it reads all of the characters in the file.
 What is wrong?

 Response:

 The FORTRAN I/O library has been rewritten to increase the speed of
 I/O. One of the side effects of the rewrite is that the CTRL+Z
 character will not be recognized as marking the end-of-file in files
 that are in the format described above.

 To work around this problem, do one the following:

 1. Use binary mode and read character-by-character, checking for the
    CTRL+Z in each character. This process is likely to be quite slow.

 2. Read into CHARACTER*x variables in formatted mode and check each
    string read for CTRL+Z using the INDEX function. This process
    should be faster.

 3. Modify the input file so that its actual length is the same as
    its logical length or so all of the characters after the CTRL+Z
    are either CTRL+Zs or nulls (ASCII code = 0). This process is
    best if you do not mind passing the input file through a filter.


 391. File I/O Return Codes Using IOSTAT

 Product Version(s): 3.x 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33730

 Question:
    I opened a file and received a return code with IOSTAT. Where can
 I look to find out what this code means?

 Response:
    If the number you received is zero, there was no error; however,
 if you received a positive number back, there was an error and the number
 corresponds to a run-time error message.
    The run-time error messages are documented starting on Page 434 of
 the "Microsoft FORTRAN 4.1 Optimizing Compiler Users Guide."


 392. Passing a FORTRAN String to a C Function

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 16-AUG-1988    ArticleIdent: Q33763

    The following example illustrates how to pass a FORTRAN string to a
 C function and return a capitalized version of the string. The string
 passed remains unchanged. For additional information, see the
 "Microsoft Mixed-Language Programming Guide", sections 4.1, 4.2, and
 4.4.

    When passing a string from FORTRAN to C, the FORTRAN interface
 statement must have the following form:

    INTERFACE TO return_type FUNCTION func_name [C] ( ARG )
    return_type ARG [REFERENCE]

    In the above declaration "return type" can be any type, such
 as character*30. Note that all data types are references (addresses)
 in FORTRAN.
    The [C] attribute tells FORTRAN to treat the function as a C
 function. This attribute accomplishes the following:

    1. Pushes parameters from left to right
    2. Appends a leading underscore to the function name
    3. Prepares the calling program to take care of the stack unlike
       FORTRAN and Pascal, in which the called sub-program takes care
       of the stack.
    4. The C attribute is also used to tell FORTRAN that a string
       literal is to be treated as a C string; i.e., to place a NULL
       terminator after the literal in the CONST segment of DGROUP.

    The [REFERENCE] attribute tells FORTRAN to pass the address of ARG
 instead of its value. Note that the value of ARG is an address; as a
 result, its address is passed. There are two levels of indirection
 similar to a pointer in C (e.g. char **p).
    The following is an example of mixed language calling C from
 FORTRAN:

       interface to character*30 function UpCase [C] ( str )
       character*30 str [REFERENCE]
       end

       character*30 string
       character*30 buffer
       character*30 UpCase

       string = 'hello, world!'  C

 C     The C following 'hello, world!' NULL terminates the literal.

       buffer = UpCase( string )

       write(6, 10) string
       write(6, 11) buffer

   10  format( 1x, 'string = ', A13 )
   11  format( 1x, 'buffer = ', A13 )

       end

 =====================================================================
 PRINTOUT:

 string = hello, world!
 buffer = HELLO, WORLD!

 =====================================================================

 C:

 #include <malloc.h>

 char *
 UpCase( const char *string )
 {
      int   i=0;
      char  *str; /* Create buffer so you do not change string value */

      while ( string[i++] != 0 );   /* Get string length */
      str = malloc( --i );          /* Give buffer some space */

      i = 0;
      while ( string[i] != 0 ) /* Change to uppercase, copy into str */
      {
           if ( string[i] >= 'a' && string[i] <= 'z' )
                str[i] = string[i] - 32;
           else
                str[i] = string[i];
           i++;
      }

      return( str );
 }


 393. Using the Debug Option with /Zi Causes Problems

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER | s_pascal SR# G880727-1846
 Last Modified:  5-AUG-1988    ArticleIdent: Q33832

    The two compiler switches /Zi and /4Yb for FORTRAN, or /Pd for
 Pascal are mutually exclusive. The line information that each of these
 store, conflicts with each other. If both are used and the code is
 brought up under CodeView, the source comes up in assembly mode with
 the statement, No Symbolic Information.  There is no reason to turn on
 the debugging switch if you intend to do your debugging in CodeView.

    The use of the Pascal /Pd switch is identical to the PAS1 option
 /D, which turns on all debugging. The FORTRAN /4Yb switch also turns
 on all debugging. These are equivalent to the $DEBUG metacommand.


 394. FORTRAN: Error F2409 Erroneously Generated

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q33898

 The sample program below causes the error F2409: "nonstatic address
 illegal in initialization." If the $NOTRUNCATE command is given at the
 top of the program, it compiles cleanly. If INDEXER in shortened to
 INDEXE, i.e., six characters, the program compiles without error.
 Microsoft FORTRAN only recognizes the first six characters of the
 variable name unless the $NOTRUNCATE command is given.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 The following sample program demonstrates the problem:

        DIMENSION A(5,5)
        DATA (( A(INDEXER, J), INDEXER=1,5), J=1,5) /25*1.0/
        END

 bug.for(2) : error F2409: A : nonstatic address illegal in initialization


 395. How to Avoid Compiler Error F6700: "Heap Space Limit Exceeded"

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  7-SEP-1988    ArticleIdent: Q33995

 Problem:

 I have received the F6700: "heap space limit exceeded" run-time error.
 The error documentation implies that I may have too many files opened
 at once; however, this is not the case. I have files=20 in my
 CONFIG.SYS and I only have opened five files myself.

 Response:

 This problem may occur because there is not enough memory to allocate
 another file control block (FCB). A FCB must be allocated from the
 heap for each file opened. Try using the /Gt switch, which frees up
 space in the default data segment and allows more room for the near
 heap and consequently the FCBs.


 396. How to Avoid Compiler Error F2220: "Length Redefined"

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33996

    The sample program below generates the following compiler error:

    doub.for(9) : error F2220: PA : length redefined

    Function return types must be defined within subprograms that make
 calls to these functions. Within function F1, variable PA must be
 explicitly typed to be double precision to match the previous function
 definition of PA. The error is generated because the default type of
 PA would be REAL*4 or single precision. This process causes the
 compiler error F2220.

    The following sample program demonstrates the problem:

       double precision function pa (w, x)
       w = 1.5
       x = 2.4
       pa = w + x
       return
       end
 C
       double precision function f1 (x)
       f1 = pa (w, x) - sig1
       return
       end

    The function definition of F1 should be as follows:

       double precision function f1 (x)
       double precision pa
       f1 = pa (w, x) - sig1
       return
       end



 397. Benchmarks for Microsoft FORTRAN

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | benchmark
 Last Modified:  7-SEP-1988    ArticleIdent: Q34138

 The following periodicals contain articles that compare the Microsoft
 FORTRAN Optimizing Compiler to other FORTRAN compilers:

 1. November 1987 "Byte Magazine"
 2. July 1988 IEEE "Software Magazine"


 398. L2025 Error: "Symbol Defined More than Once"

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | _main
 Last Modified: 10-AUG-1988    ArticleIdent: Q33998

    When a FORTRAN program generates the link error L2025: "symbol
 defined more than once" occurring on the symbol _main, it usually means
 that more than one of the object modules being linked appeared to the
 linker as a main program.
    Make sure all the subprograms in all object modules, other than the
 main, have the FUNCTION or SUBROUTINE statement.


 399. How to Avoid Compiler Error 803

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-AUG-1988    ArticleIdent: Q33999

 Question:
    When I compile my FORTRAN program I receive an error 803 "Starting
 location is odd." What is wrong with my code?

 Response:
    This error is usually generated by one or more of the following
 conditions:

    1. Characters and reals or integers have been declared in one
       COMMON block. You can reorder the declaration or make the
       character declaration of even type. You can also put the
       character declarations in a different COMMON block than the
       integers and reals.

    2.  An EQUIVALENCE statement was made between a character string
        of odd length with integers or reals.

    Correcting the above situations in your code eliminates the
 compiler error.


 400. Floating-Point Option Causes Error D2011

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q34270

    It is possible to get the FORTRAN Version 4.10 compiler error
 "D2011 only one floating-point model allowed" when the floating-point
 option is given after the source or object file. This error can occur
 if the FL environment variable contains a source or object file before
 the floating-point option. All options always should occur before
 source and object files on the command line.

    The following is an example of an incorrect FL environment setting:

    SET FL=FL /FPi

    This setting causes the error D2011.
    This error occurs because the compiler assumes that the second FL
 is a filename. Because there is no extension, the compiler assumes
 that "FL" is "FL.OBJ;" as a result, it does not try to compile it.
 Because the filename "FL.OBJ" appears on the command line before the
 /FPi option, the /FPi option does not apply to "FL.OBJ," applying only
 to the file(s) that follow on the command line.
    The "FL.OBJ" is assumed to have the default option /FPi87, so the
 "only one floating-point model allowed" error occurs.
    The error D2011 also can be produced by invoking the compiler using
 the command FL FL /FPi filename.for with no environment variable set.
 Compiling with FL FL /FPi87 filename.for will not produce the error
 because the floating-point option is consistent, /FPi87 is the
 default. (The linker will give an error when it fails to find the
 FL.OBJ file.)
    The correct FL environment setting is as follows:

    SET FL=/FPi


 401. FORTRAN 4.1 F1001 Error in omf_ms.c:1.115, line 1093

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q34271

 The code below produces the following error, which produces a
 protection violation during compile time under OS/2:

    fatal error F1001:  Internal Compiler Error
                 (compiler file '@(#)omf_ms.c:1.115', line 1093)

 To work around this problem, remove the interface statement.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The same internal compiler error is produced when a function, which is
 being passed to another function, is not declared as being EXTERNAL
 inside a subprogram. An example of this process would be a program
 that has Function 1, Function 2, and a subroutine. If Function 2 is
 passed to Function 1 inside the following subroutine, then Function 2
 must be declared inside the subroutine as being EXTERNAL:

    result = Function1 (Function2)

 The workaround to this problem is to make sure the function (Function
 2, in this case) is declared as EXTERNAL.

 The following sample code demonstrates the problem:

        interface to integer function f0 ()
        end

        integer f1, f0, x

        write (*,*) f0()
        x = f1(f0)
        write (*,*) x
        end

        integer function f0 ()
        f0 = 88
        end

        integer function f1 (fx)
        integer fx
        f1 = 12 + fx()
        end


 402. Building LLIBFOR7.LIB Using the Library Manager

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 16-AUG-1988    ArticleIdent: Q34272

    To build the library LLIBFOR7.LIB (large-model, coprocessor-math
 FORTRAN library) the component libraries below must be combined using
 the Library Manager. These libraries should be placed in one directory
 and the PATH environment variable should be set so that the most
 current version of LIB.EXE is in the path. The Library Manager should
 be run from the directory that contains the component libraries.

    The syntax is as follows:

 LIB LLIBFOR7.LIB

 ( the LIB utility will ask you to create ) Y

 OPERATIONS: +LIBH.LIB +LLIBFP.LIB +LLIBFOR.LIB +LLIBFOR1
                   +87.LIB +LCLIB1.LIB

 LIST FILE:  <cr>

 OUTPUT LIBRARY:  <cr>

    At this point, the Library Manager will combine the component
 libraries into the combined library LLIBFOR7.LIB.


 403. F2124 Error Caused by a Real Array Index

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q34328

 The program below generates the following error when compiled with the
 /Od:

    error F2124 : CODE GENERATION ERROR
                Contact Microsoft Technical Support

 In the following sample code, the i variable is used incorrectly in
 the second loop as an integer when it is declared as a real*8. Using a
 real as an array index should cast the real to an integer. If the i
 variable is changed to the j variable, which is defined as an integer,
 the program compiles correctly.

 The following sample code demonstrates the problem:

 c
 c         Main program that generates a code generation error
 c
        complex*16 carr, carr2
        real*8 data,i
        integer nn,isign,j
           dimension carr(128),data(256),carr2(128)
 c
        nn = 128
        isign = 1
 c
        do 100 i = 0.001,0.128,0.001
        carr(i) = dsin(i*360/(2*3.14159))
   100  continue
 c
        do 200 i = 1,128
        data((2*i)-1) = real (carr(i))
        data(2*i) = imag(carr(i))
   200  continue
 c
        stop
        end

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.


 404. External Data and Public Variables in FORTRAN

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr s_c h_masm s_pascal
 Last Modified: 20-JUN-1990    ArticleIdent: Q34370

 FORTRAN cannot declare individual variables as public. Common blocks
 are the only way to declare publicly accessible variables.

 Section 9.3, "External Data," of the "Microsoft Mixed-Language
 Programming Guide," and Section 5.3.3, "External Data," of the
 "Microsoft FORTRAN Advanced Topics" guide for version 5.00 discuss
 possibilities for shared data. The guide states the following:

    You can always share data between two languages by passing
    parameters. In the case of local variables and all BASIC variables,
    passing parameters is the only convenient way to share data.

    However, C, FORTRAN, and Pascal routines can access data directly
    that are external.

 FORTRAN can access variables declared external in C and Pascal
 routines; however, FORTRAN cannot declare a single variable as public.
 The example on Page 131 of the "Microsoft Mixed-Language Programming
 Guide" and Pages 109-110 of the "Microsoft FORTRAN Advanced Topics"
 incorrectly shows C and Pascal accessing a public variable in the
 FORTRAN routine. This process is impossible because all FORTRAN
 variables are local. Only common blocks and subprogram names are
 public in FORTRAN.

 To declare a variable or set of variables public in FORTRAN, place
 them in a common block. Because common blocks are public, you can
 access the variables through that common block, but not individually.
 For example, you can declare a common block in a FORTRAN program, then
 access that block in a C routine by declaring an external structure
 with the same form.


 405. Opening More than 20 Files under OS/2

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-NOV-1989    ArticleIdent: Q34395

 You cannot open more that 20 files with FORTRAN 4.1 under OS/2. You
 can change this limit in FORTRAN 5.0. See pages 405-407 of the FORTRAN
 5.0 Reference manual for more information.

 FORTRAN 4.1 has the 20 open-files limit hard coded into the compiler.
 This is not a limitation of OS/2, which has the limit of open files at
 255. However, to get the full 20 files in FORTRAN, you must call the
 OS/2 function DosSetMaxFH().

 You cannot open the full 20 files without calling DosSetMaxFH because
 OS/2 opens several files to start. This OS/2 function increases the
 OS/2 file limit. By increasing the OS/2 file limit, the preopened OS/2
 files are freed from the FORTRAN limit of 20 files. Freeing these
 preopened file handles will allow FORTRAN to open 20 files of its own.

 The following program demonstrates how to call DosSetMaxFH to
 open 20 files:

       INTERFACE TO INTEGER*2 FUNCTION DOSSET
      + [ALIAS:'DosSetMaxFH'](fhnum)
       INTEGER*2 fhnum[VALUE]
       END

       INTEGER*2 J, DOSSET
       CHARACTER*12 fname
       fname='FILE   .DAT'
       J = DOSSET(40)

       DO 10, I = 1, 40
       WRITE(fname(5:7),100)I
 100   FORMAT(I3.3)
       OPEN(UNIT=I,FILE=fname,STATUS='NEW',ERR=20)
       WRITE(I,*)fname
 10    CONTINUE
 20    WRITE(*,*) 'cannot open at i=', i
       STOP
       END


 406. Blank Interpretation BN Is the Default

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q35222

 In section 4.8.1.10 "Blank Interpretation (BN, BZ)" of the "Microsoft
 FORTRAN Optimizing Compiler Language Reference" there is a discussion
 of these two edit descriptors. In the fourth paragraph on Page 132, it
 correctly states that BN is the default. However in the last
 paragraph, on Page 133, it incorrectly states that, "If BZ editing
 were in effect, as it is by default,..."

 This statement is incorrect. BN is the default.


 407. Error F2328 (already typed) should be generated in FORTRAN 4.1

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q35234

 The following code should produce the error F2328 (already typed) on
 lines 2 and 4, respectively, when using FORTRAN Version 4.10:

       INTEGER A
       INTEGER A
       INTEGER B(10)
       INTEGER B
       END

 However, these errors are not generated. If these variables had been
 declared as reals and not integers, the appropriate errors would have
 been produced.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 In the following example, "I" gets set to integer in the first
 declaration, so it is actually redefined in the second declaration:

        SUBROUTINE SUB(A,I)
     INTEGER A(I)
     INTEGER I
     END

 In this example, a redefinition error would not be appropriate. The
 compiler should check to see if the variables being typed are dummy
 variables. If the redefined variable is not a dummy variable, then the
 redefinition error F2328 should occur.


 408. Implicit DO within Read May Fail in Certain Cases

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q35236

 In the example code below, the implicit DO within the read may cause
 the next access to file to fail. The code takes four strings of data
 from a file, but depending on how the data is organized, the program
 may or may not be able to retrieve the last line of data. It does not
 seem to recognize the end-of-record marker in the next-to-last line of
 the data file.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in version 5.00.

 A work around for this problem is to replace the (A80) with the
 default *.

 The following sample code demonstrates this problem:

       program showbug
       character*8 string(4),last*80
       open (1,file=' ', status='OLD')
       read (1,*) (string(I),I=1,4)
       do 10 i = 1,4
 10      print *,'string(',i,')=',string(i)
       read (1,'(A80)') last
 C     The workaround is to use the following read statement
 C     read (1,*)last
       print *,'last=',last
       stop
       end

 The segment will not retrieve the last line of code if the data is
 organized as follows:

 'one'
 'two'
 'three'
 'four'
 'Last line of text'

 However, if the file is organized as follows, it works correctly:

 'one'
 'two'
 'three' 'four'
 'Last line of text'


 409. Directory Listing for FORTRAN 4.10 Distribution Disks

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-SEP-1988    ArticleIdent: Q35237

 Below is a listing of the directories for each of the Microsoft
 FORTRAN Optimizing Compiler Version 4.10 distribution disks (5.25
 inches).

 The information is the resulting output when the DOS command "dir" is
 performed on each directory and subdirectory.

 A line of colons (:::::) separates each disk, and subdirectories are
 listed below their parent directory. The first line of each disk
 description is the name of the disk as it is printed on the label.
 Information in parentheses is supplemental and not contained on the
 disk label.

 The following are directories for FORTRAN Version 4.10 distribution
 disks:

 (Disk 1 of 10)  --  Setup

  Volume in drive A is SETUP
  Directory of  A:\

 DEMOS        <DIR>      2-23-88   9:25a
 PATCH        <DIR>      2-23-88   9:25a
 EMOEM    ASM    12125   2-12-88   2:00p
 F3S      EXE    99308   2-12-88   2:00p
 FL       ERR     1965   2-12-88   2:00p
 FL       EXE    45965   2-18-88   5:33p
 FL       HLP     1726   2-12-88   2:00p
 FLOPSET  DOC     5339   2-12-88   2:00p
 PACKING  LST     8307   2-19-88   4:33p
 PATCH87  EXE     4206   2-12-88   2:00p
 README   DOC    21503   2-22-88  11:53a
 SETUP    DAT    46520   2-12-88   2:00p
 SETUP    EXE    42501   2-22-88  12:24p
        13 File(s)     10240 bytes free

  Volume in drive A is SETUP
  Directory of  A:\DEMOS

 .            <DIR>      2-23-88   9:25a
 ..           <DIR>      2-23-88   9:25a
 CIRC     C       4605   2-23-88   8:30a
 DEMO     FOR     1244   2-23-88   8:30a
 DEMOEXEC FOR      981   2-23-88   8:30a
 DEMORAN  FOR     2940   2-23-88   8:30a
 DWHET    FOR    12463   2-23-88   8:30a
 FOREXEC  INC     5331   2-23-88   8:30a
 GRAPH    BAT      603   2-23-88   8:30a
 GRAPH    FOR     1349   2-23-88   8:30a
 SECNDS   FOR      768   2-23-88   8:30a
 SIEVE    FOR     1440   2-23-88   8:30a
 SWHET    FOR    12312   2-23-88   8:30a
        13 File(s)     10240 bytes free

  Volume in drive A is SETUP
  Directory of  A:\PATCH

 .            <DIR>      2-23-88   9:25a
 ..           <DIR>      2-23-88   9:25a
 README   DOC     1192   2-23-88   8:30a
 RMRHS    EXE      543   2-23-88   8:30a
 SETRHS   EXE      543   2-23-88   8:30a
 STKPAT   BAT       94   2-23-88   8:30a
 STKPAT   SCR       30   2-23-88   8:30a
         7 File(s)     10240 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 2 of 10)  --  Compiler 1

  Volume in drive A is COMPILER 1
  Directory of  A:\

 F1       ERR    15919   2-23-88   8:30a
 F1       EXE   167017   2-23-88   8:30a
 F3       EXE   155676   2-23-88   8:30a
         3 File(s)     21504 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 3 of 10)  --  Compiler 2

  Volume in drive A is COMPILER 2
  Directory of  A:\

 EXEC     EXE     9299   2-23-88   8:30a
 F2       EXE   218189   2-23-88   8:30a
 F23      ERR     2967   2-23-88   8:30a
 ILINK    EXE    88929   2-23-88   8:30a
 LIBBUILD BAT    23513   2-23-88   8:30a
         5 File(s)     17408 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 4 of 10)  --  Utilities

  Volume in drive A is UTILITIES
  Directory of  A:\

 BIND     EXE    36946   2-23-88   8:30a
 ERROUT   EXE    10729   2-23-88   8:30a
 EXEHDR   EXE    29942   2-23-88   8:30a
 EXEMOD   EXE    11765   2-23-88   8:30a
 EXEPACK  EXE    14803   2-23-88   8:30a
 IMPLIB   EXE    30166   2-23-88   8:30a
 LIB      EXE    49661   2-23-88   8:30a
 LINK     EXE   117001   2-23-88   8:30a
 MAKE     EXE    38613   2-23-88   8:30a
 SETENV   EXE    10313   2-23-88   8:30a
        10 File(s)      6144 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 5 of 10)  --  Microsoft CodeView for MS-DOS

  Volume in drive A is DOSCODEVIEW
  Directory of  A:\

 DEMO     BAT     5512   2-23-88   8:30a
 MOUSE    COM    14455   2-23-88   8:30a
 C_AUTO   CV      2385   2-23-88   8:30a
 E_AUTO   CV      5464   2-23-88   8:30a
 L_AUTO   CV      9631   2-23-88   8:30a
 M_AUTO   CV       721   2-23-88   8:30a
 Q_AUTO   CV        13   2-23-88   8:30a
 S_AUTO   CV      6754   2-23-88   8:30a
 IN       DAT       65   2-23-88   8:30a
 CVREADME DOC    36960   2-23-88   8:30a
 CV       EXE   232896   2-23-88   8:30a
 WHAT     EXE     2434   2-23-88   8:30a
 STATS    FOR     3469   2-23-88   8:30a
 CV       HLP    21552   2-23-88   8:30a
        14 File(s)     10240 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 6 of 10)  --  Microsoft CodeView for MS OS/2

  Volume in drive A is OS2CODEVIEW
  Directory of  A:\

 CVP      EXE   226591   2-23-88   8:30a
 CVP      HLP    21552   2-23-88   8:30a
 CVPACK   EXE    57437   2-23-88   8:30a
 MAKESORT BAT     1353   2-23-88   8:30a
 MAKESORT CMD     1305   2-23-88   8:30a
 OS2PATCH EXE     1069   2-23-88   8:30a
 PTRACE87 PAT      188   2-23-88   8:30a
 SORTDEMO FOR    29255   2-23-88   8:30a
         8 File(s)     17408 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 7 of 10)  --  Library (Large Model)

  Volume in drive A is LIBRARIES 1
  Directory of  A:\

 87       LIB     4121   2-23-88   8:30a
 ALTMATH  LIB     7168   2-23-88   8:30a
 EM       LIB    16921   2-23-88   8:30a
 FORTRAN  LIB    34816   2-23-88   8:30a
 LCLIB1   LIB    21893   2-23-88   8:30a
 LIBH     LIB    13673   2-23-88   8:30a
 LLIBFA   LIB    82473   2-23-88   8:30a
 LLIBFOR  LIB    73427   2-23-88   8:30a
 LLIBFOR1 LIB    17539   2-23-88   8:30a
 LLIBFP   LIB    64207   2-23-88   8:30a
 MATH     LIB     6656   2-23-88   8:30a
 NBUILD   OBJ      596   2-23-88   8:30a
        12 File(s)     13312 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 8 of 10)  --  Library (Medium Model)

  Volume in drive A is LIBRARIES 2
  Directory of  A:\

 87       LIB     4121   2-23-88   8:30a
 EM       LIB    16921   2-23-88   8:30a
 LIBH     LIB    13673   2-23-88   8:30a
 MCLIB1   LIB    21379   2-23-88   8:30a
 MLIBFA   LIB    81449   2-23-88   8:30a
 MLIBFOR  LIB    71891   2-23-88   8:30a
 MLIBFOR1 LIB    17539   2-23-88   8:30a
 MLIBFP   LIB    62669   2-23-88   8:30a
 NBUILD   OBJ      596   2-23-88   8:30a
         9 File(s)     66560 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 9 of 10)  --  MS OS/2 Libraries

  Volume in drive A is LIBRARIES 3
  Directory of  A:\

 STARTUP      <DIR>      2-23-88   9:35a
 API      LIB    81408   2-23-88   8:30a
 APILMR   OBJ      105   2-23-88   8:30a
 DOSCALLS LIB    29184   2-23-88   8:30a
 LCLIB2   LIB    18833   2-23-88   8:30a
 LLIBFOR2 LIB    18059   2-23-88   8:30a
 MCLIB2   LIB    17809   2-23-88   8:30a
 MLIBFOR2 LIB    17547   2-23-88   8:30a
         8 File(s)      1024 bytes free

  Volume in drive A is LIBRARIES 3
  Directory of  A:\STARTUP

 .            <DIR>      2-23-88   9:35a
 ..           <DIR>      2-23-88   9:35a
 DOS          <DIR>      2-23-88   9:35a
 OS2          <DIR>      2-23-88   9:35a
 BRKCTL   INC      779   2-23-88   8:30a
 CHKSTK   ASM     2036   2-23-88   8:30a
 CHKSUM   ASM     3506   2-23-88   8:30a
 CMACROS  INC    12061   2-23-88   8:30a
 CRT0FP   ASM     2207   2-23-88   8:30a
 MAKEFILE         3113   2-12-88   2:00p
 MSDOS    INC     6087   2-12-88   2:00p
 NULBODY  FOR       11   2-12-88   2:00p
 ONEXIT   ASM     2793   2-12-88   2:00p
 README   DOC     2826   2-12-88   2:00p
 STARTUP  BAT     1407   2-12-88   2:00p
 VERSION  INC      398   2-12-88   2:00p
        16 File(s)      1024 bytes free

  Volume in drive A is LIBRARIES 3
  Directory of  A:\STARTUP\DOS

 .            <DIR>      2-23-88   9:35a
 ..           <DIR>      2-23-88   9:35a
 CRT0     ASM    14422   2-23-88   8:30a
 CRT0DAT  ASM    21296   2-23-88   8:30a
 CRT0MSG  ASM     3055   2-23-88   8:30a
 NMSGHDR  ASM     5132   2-23-88   8:30a
 NULBODY  LNK      156   2-23-88   8:30a
 STDALLOC ASM     3336   2-23-88   8:30a
 STDARGV  ASM    14371   2-23-88   8:30a
 STDENVP  ASM     3692   2-23-88   8:30a
        10 File(s)      1024 bytes free

  Volume in drive A is LIBRARIES 3
  Directory of  A:\STARTUP\OS2

 .            <DIR>      2-23-88   9:35a
 ..           <DIR>      2-23-88   9:35a
 CRT0     ASM    10303   2-23-88   8:30a
 CRT0DAT  ASM    10016   2-23-88   8:30a
 CRT0MSG  ASM     2891   2-23-88   8:30a
 EXECMSG  ASM     2203   2-23-88   8:30a
 NMSGHDR  ASM     3475   2-23-88   8:30a
 NULBODY  LNK      175   2-23-88   8:30a
 STDALLOC ASM     3234   2-23-88   8:30a
 STDARGV  ASM    13612   2-23-88   8:30a
 STDENVP  ASM     5316   2-23-88   8:30a
        11 File(s)      1024 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 10 of 10)  --  Microsoft Editor

  Volume in drive A is MS EDITOR
  Directory of  A:\

 INI          <DIR>      2-23-88   9:37a
 MSETUP   BAT     2982   2-12-88   2:00p
 FIXSHIFT COM      690   2-23-88   8:30a
 ECH      EXE    19351   2-23-88   8:30a
 EXP      EXE    32220   2-23-88   8:30a
 M        EXE    94821   2-12-88   2:00p
 MEGREP   EXE    31915   2-12-88   2:00p
 MEP      EXE    97063   2-12-88   2:00p
 RM       EXE    24884   2-12-88   2:00p
 UNDEL    EXE    30046   2-12-88   2:00p
 WHAT     EXE     2434   2-12-88   2:00p
        11 File(s)      8192 bytes free

  Volume in drive A is MS EDITOR
  Directory of  A:\INI

 .            <DIR>      2-23-88   9:37a
 ..           <DIR>      2-23-88   9:37a
 BRIEF    INI     2094   2-23-88   8:30a
 EPSILON  INI      978   2-23-88   8:30a
 QUICK    INI     1058   2-23-88   8:30a
 WS       DLL     2609   2-23-88   8:30a
 WS       ZXT     2084   2-23-88   8:30a
         7 File(s)      8192 bytes free


 410. FORTRAN: Complex Expression Causes mactab.c 1.34 Line 639

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q35265

 The code below causes the following internal compiler error:

 bug.for
 bug.for(7) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)mactab.c:1.34', line 639)
                 Contact Microsoft Technical Support

 The workaround for this problem is to simplify the offending line. You
 can use temporary variables, or just simplify the expression. To
 simplify the line, replace the line

 b =-(x/2d0-ima/2d0)

 with the following simplified line:

 b = (ima - x)/2d0

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following sample code demonstrates the problem:

       subroutine ose4x4()
       complex*16      ima,x,b,temp1,temp2
       x = (1,0)
       ima = -(1,1)
       b =-(x/2d0-ima/2d0)
       return
       end


 411. How to Clear the Coprocessor Status Word

 Product Version(s): 3.31 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | 8087 80287 80387 80X87 status exception
 Last Modified: 16-JAN-1989    ArticleIdent: Q35434

 Appendix D on Page 359 of the "Microsoft FORTRAN 4.1 Optimizing
 Compiler User's Guide" states the following:

 "When one of the exception conditions occurs, the appropriate bit in
 the status word is set. This flag remains set, indicating that the
 exception occurred, until the user clears it."

 There only is a "load" instruction for the control word (LCWRQQ).

 The status word should be cleared by your interrupt handler. If
 written in C you should use the _clear87() call or _fpreset(). If you
 are using Microsoft's Macro Assembler, you can issue the 8087
 instruction FCLEX directly.

 Unfortunately, just clearing the status word has the potential of
 causing the coprocessor to ignore an interrupt generated at the same
 time as your "clear" instruction.


 412. Calling C Graphics Function _floodfill from a FORTRAN Program

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 19-DEC-1989    ArticleIdent: Q35647

 When calling a C module from a FORTRAN module that draws a box with
 the _lineto function and then _floodfill(s) the box, the _floodfill
 function performs incorrectly. Instead of filling the box with the
 choosen color, _floodfill only draws a horizontal line that intersects
 the point specified in the function call. When the C module is called
 from a C main routine, the function performs correctly.

 To work around this problem, use the _rectangle function with the
 _GFILLINTERIOR option, instead of the _lineto  and _floodfill
 functions.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. The problem has been corrected in Version 5.00 of
 the compiler.

 The following program demonstrates the problem (if using a Hercules
 card, make sure to run MSHERC.COM before this program):

 ********************************************************************

 c      FORTRAN Main Module
 c
 c      This program calls a C module that does some graphics.
 c
        interface to subroutine test[c,alias:'_test']
        end
        call test
        stop
        end

 /* This C module draws a box with the upper left coordinates at (0,0)
    and the lower right coordinates at (300,300) by drawing lines.
    It then fills in the box with a color.                          */

 #include "io.h"
 #include "stdio.h"
 #include "graph.h"

 void test (void);

 void  test(void)
 {
    _setvideomode(_HERCMONO);  /* _setvideomode needs to be changed */
    _moveto(0,0);              /* according to your configuration */
    _lineto(300, 0);
    _lineto(300, 300);
    _lineto(0, 300);
    _lineto(0,0);
    _floodfill(132,80, 4);
    getche();
    _setvideomode(_DEFAULTMODE);
  }
 ***********************************************************************


 413. List File Incorrectly Truncates File at Column 72

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist 4.10 /Fs
 Last Modified:  2-NOV-1988    ArticleIdent: Q35650

 The list (.lst) file from the FORTRAN Version 4.10 Optimizing Compiler
 truncates the .lst file at the 72nd column, instead of column 73 as
 specified on Page 51 in the "Microsoft FORTRAN 4.1 Language Reference
 Guide." This process functions properly on FORTRAN Version 4.00.

 In Version 4.10, the source file compiles correctly, which is evidence
 that the compiler is not truncating the 72nd column. Yet the list file
 is incorrect.

 To work around this problem, use the $LINESIZE metacommand.

 Microsoft has confirmed this to be a problem in Version 4.10. We are
 researching this problem and will post new information as it becomes
 available.


 414. Printing with Control Characters

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JUN-1989    ArticleIdent: Q35867

 In FORTRAN, you can feed control characters directly to the printer
 without printing them.

 The following is a small example that prints the word "Hello", sends a
 form feed to the printer, then prints the word "World":

 OPEN(6, FILE='lpt1', STATUS='old')
 WRITE(6,*) 'HELLO'
 WRITE(6,*) char(12)
 WRITE(6,*) 'WORLD'
 END


 415. Parameter Statement Can't Define Negative Constant

 Product Version(s): 3.30 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.30 buglist3.31 fixlist4.00
 Last Modified: 16-JAN-1989    ArticleIdent: Q35868

 When using parameter to give a constant a symbolic name in FORTRAN
 Versions 3.30 and 3.31, the following statement generates compiler
 error 22: "interger constant expected":

 parameter (x = -0.5)

 However, the following statements do not generate the error message
 when compiling:

 parameter (x = 0.5)  or
 parameter (L = -1)

 Microsoft has confirmed this to be a problem with FORTRAN compiler
 Versions 3.30 and 3.31. This problem was corrected in Version 4.00.


 416. FORTRAN: Open Not Freeing Up Memory During Repetitive Calls

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q35869

 When FORTRAN opens a file, it opens a File Control Block (FCB). When
 it closes the file, the FCB should be freed. However, FORTRAN does not
 free the memory; after numerous openings and closings of PRN, the
 F6700: "heap space limit exceeded" error is generated.

 This problem also occurs with other devices such as CON. This problem
 does not occur with files. The device buffer takes up most of the heap
 space. The default is 1024 bytes.

 To minimize this behavior, use the BLOCKSIZE= option when opening the
 device. The minimum is 512 bytes. This process minimizes the heapspace
 used; however, it doesn't eliminate the problem.

 Microsoft has confirmed this to be a problem in Version 4.01 and 4.10
 of the FORTRAN Compiler. This problem was corrected in Version 5.00.

 The following code demonstrates this problem:

    $STORAGE:2
    $DEBUG
           REAL*4 ARRY(5)

       10  CALL POPEN
           WRITE(2,ERR=8000,IOSTAT=IERR) ARRY
           GOTO 10

     8000  CALL FILERR(IERR)
           END

    C *****************************************
           SUBROUTINE FILERR(IERR)
           IMPLICIT INTEGER*2 (I-N)

           WRITE(*,*) IERR
           END

    C *****************************************
           SUBROUTINE POPEN
           IMPLICIT INTEGER*2 (I-N)
           CLOSE(2)
           OPEN(2,FILE='PRN',FORM='BINARY',ERR=8000,IOSTAT=IERR)
           RETURN

     8000  CALL FILERR(IERR)
           END


 417. Passing Constants to Subroutines in FORTRAN

 Product Version(s): 4.00 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 30-SEP-1988    ArticleIdent: Q35871

 The code below will generate the following output:

         1.000000
         2.000000

 This behavior is not a problem with Microsoft FORTRAN. The FORTRAN 77
 ANSI standard, section 15.9.2, specifies that when passing a constant
 as an actual argument to a subroutine, the associated dummy argument
 (in this case x) cannot be modified.

 Microsoft FORTRAN does not generate error messages while compiling.
 The above code does not follow the standard; therefore, it will
 generate unpredictable results because FORTRAN passes by reference.

 If the associated dummy argument is going to be modified, pass a
 variable. For example, use "call sub1(y)" with y=1.

 The following code demonstrates this information:

         write (*,*) 1.0
         call sub1(1.0)
         write (*,*) 1.0
         end

         subroutine sub1(x)
         real x
         x = 2.0
         return
         end


 418. Domain and Range of FORTRAN Natural Log Functions

 Product Version(s): 4.00 4.01 4.10  | 4.10
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified: 30-SEP-1988    ArticleIdent: Q35872

 The program below demonstrates the use of the exp (e**n) and log
 FORTRAN natural logarithm functions, using the limits of real*4 (or
 real) and real*8 values. Both the domain and range of these functions
 must be valid real*4 values for exp and log, and real*8 values for
 dexp and dlog. Consequently, the highest acceptable argument to the
 exp functions is the natural log of the maximum real number for the
 respective floating-point precisions.

 The following demonstrates this information:

 c Program to manipulate natural log and exp functions with greatest and
 c smallest real*4 and real*8 values. The 16th decimal digit displayed
 c exceeds the 15 significant digits, and may not be accurate.

 c Define extreme real*4 and real*8 values, and double- and
 c single-precision "e"

       real*8 maxr8, minr8, pos0r8, neg0r8, e8
       real*4 maxr4, minr4, pos0r4, neg0r4, e4

       maxr8  =  1.7976931348623156d+308
       minr8  = -1.7976931348623156d+308
       pos0r8 =  2.23d-308
       neg0r8 = -2.23d-308
       e8     = dexp(1)

       maxr4  =  1.701411e+38
       minr4  = -1.701411e+38
       pos0r4 =  1.701411e-38
       neg0r4 = -1.701411e-38
       e4     = exp(1)

       write(*,*)
       write(*,*) 'Program to demonstrate use of natural log functions'
       write(*,*) 'with domain & range values at floating point limits.'
       write(*,*)
       write(*,*) 'There are 7 significant decimal digits in a real*4'
       write(*,*) '15 (or 16) significant decimal digits in a real*8.'
       write(*,*)
       write(*,*) 'The Intel coprocessor reference states that the'
       write(*,*) 'range of double precision (real*8) values is'
       write(*,*) 'approximately +/-2.23e-308 to +/-1.80e308. The'
       write(*,*) 'larger real*8 has been carried out to additional'
       write(*,*) 'digits of signifigance below.'
       write(*,*)
       write(*,*) 'Press ENTER to continue...'
       read(*,*)
       write(*,*)
       write(*,*) 'Display extreme real*4 and real*8 values:'
       write(*,*)
       write(*,*) 'max real*8           =  ', maxr8
       write(*,*) 'min real*8           =  ', minr8
       write(*,*) 'smallest positive r8 =  ', pos0r8
       write(*,*) 'smallest negative r8 =  ', neg0r8
       write(*,*)
       write(*,*) 'max real*4           = ', maxr4
       write(*,*) 'min real*4           = ', minr4
       write(*,*) 'smallest positive r4 = ', pos0r4
       write(*,*) 'smallest negative r4 = ', neg0r4
       write(*,*)
       write(*,*) 'Press ENTER to continue...'
       read(*,*)
       write(*,*) 'Perform real*4 and real*8 natural log and'
       write(*,*) 'exponentiation functions on limit values:'
       write(*,*)
       write(*,*) 'dexp(1) = real*8 e   =  ', e8
       write(*,*) 'dlog(maxr8)          =  ', dlog(maxr8)
       write(*,*) 'dexp(dlog(maxr8))    =  ', dexp(dlog(maxr8))
       write(*,*) 'dlog(smallest pos r8)=  ', dlog(pos0r8)
       write(*,*) 'dexp(minr8)          =  ', dexp(minr8)
       write(*,*)
       write(*,*) 'exp(1) = real*4 e    = ', e4
       write(*,*) 'log(maxr4)           = ', log(maxr4)
       write(*,*) 'exp(log(maxr4))      = ', exp(log(maxr4))
       write(*,*) 'log(smallest pos r8) = ', log(pos0r4)
       write(*,*) 'exp(minr4)           = ', exp(minr4)
       write(*,*)
       write(*,*) 'Program completed. Good-bye.'
       end


 419. FORTRAN Code Generation Error with COMPLEX types

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  5-DEC-1989    ArticleIdent: Q35874

 The source code sample below generates the following error:

 wolf1.for(10) : error F2124: CODE GENERATION ERROR
                 Contact Microsoft Technical Support.
 wolf1.for(11) : error F2124: CODE GENERATION ERROR
                 Contact Microsoft Technical Support.

 Microsoft has confirmed this to be a problem in Version 4.10. We are
 researching this problem and will post new information as it becomes
 available.

 To work around this problem, either use the temporary variable I3,
 commented out below, or compile the code with the /Od switch.

 The following sample code demonstrates the problem:

         PROGRAM TEST
 C***************************************************
         COMPLEX*16 c(5,5)
         DOUBLE PRECISION a(5,5)
         INTEGER*2 I1,I2, I3
 C
         DO 1 I1 = 1,5
            DO 2 I2 = 1,5
 c             I3 = I1*I2
               c(I1,I2) = DCMPLX(I1*I2)
               a(I1,I2) = DFLOAT(I1*I2)
   2        CONTINUE
   1     CONTINUE
         STOP
         END


 420. Too Many Errors Cause FORTRAN Compiler to Hang

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-APR-1989    ArticleIdent: Q36400

 A source file consisting of two subroutines, the first with a
 statement out of order, causes the compiler to hang.

 The workaround to this problem is to eliminate the errors and then
 recompile. The errors are due to the code. When this is corrected, the
 routines compile correctly. Please see the figure on Page 55, section
 3.5, "Order of Statements" in the "Microsoft FORTRAN Compiler Language
 Reference."

 Both subroutines compile without hanging if compiled separately.
 However, the first routine generates 38 errors of the following type
 before it exits:

    x1.for(nn) : error F2836: statement out of order

 When both subroutines are in the same source file, the errors show on
 the screen, then the compiler hangs, requiring a warm boot.

 When the DATA statement is placed at the end of the subroutine, where
 the ANSI FORTRAN 77 requires it to be, everything compiles correctly.
 See also the "American National Standard Programming Language FORTRAN,
 ANSI X3.9-1978" Section 3.5.

 The following code demonstrates this problem:

        SUBROUTINE SUB1
 C this subroutine gives many errors due to a line out of order
       INTEGER LAST LINE
       SAVE LAST LINE
 C here is a line out of order
       DATA LAST LINE /-1/
 C normal order resumes
       INTEGER BLANK, ALPHA, DIGIT, LEFTBRACKET, RIGHTBRACKET,
      *   SINGLEQUOTE, DOUBLEQUOTE, COMMA, SLASH, NUMBERSIGN,
      *   AMPERSAND, SEMICOLAN, ASTERIX, EQUALSIGN, OTHER
       PARAMETER (BLANK=1 ,ALPHA=2 ,DIGIT=3 ,
      *         LEFTBRACKET=4, RIGHTBRACKET=5, SINGLEQUOTE=6,
      *         DOUBLEQUOTE=7,COMMA=8, SLASH=9,
      *         NUMBERSIGN=10, AMPERSAND=11, SEMICOLAN=12,
      *         ASTERIX=13, EQUALSIGN=14, OTHER=15)
       CHARACTER NEWBUF(4000)*1,BUFF(4000)*1,IOBUFFER*72,COMMENT*100
       CHARACTER NEWSTR*4000, OLDSTR*4000
       INTEGER LEN,PNBUFF,PBUFF,CHRSET(0:127)
       INTEGER BUFFCODE(4000),$COMMENT,CURRENTLINE
       COMMON /NB1/ NEWBUF
       COMMON /NB2/ LEN,PNBUFF,PBUFF,$COMMENT,CURRENTLINE
       COMMON /NB3/CHRSET
       COMMON /NB4/ BUFFCODE
       COMMON /NB5/ COMMENT
       EQUIVALENCE (NEWBUF(201),BUFF),(NEWSTR,NEWBUF),(OLDSTR,BUFF)
       EQUIVALENCE (BUFF,IOBUFFER)
       INTEGER SCANTO
       LOGICAL AGAIN, DONE
       CHARACTER ALPSTR(40)*1,ALPSTR1*40
       COMMON /LYNLOC1/ SCANTO,AGAIN,DONE
       COMMON /LYNLOC2/ ALPSTR
       EQUIVALENCE (ALPSTR,ALPSTR1)
       INTEGER RECLEN(100),RECIND(100),RECPTR
       COMMON /OLDREC/ RECLEN,RECIND,RECPTR
       CHARACTER * 6  CONTINUE6(19)
       INTEGER  CONTPTR
       COMMON /CON1/ CONTINUE6
       COMMON /CON2/ CONTPTR
       END

       SUBROUTINE SUB2
 C this subroutine will compile if in a separate file
       IMPLICIT LOGICAL (A-Z)
       INTEGER FSTART, START, TAGNUM (200), TAGSTART (1000), I
       INTEGER TAGEND (1000), TAGBEGIN (200), SYMSIZE (200), SMALL
       INTEGER TAGPTR, SYMPTR, CNT, J, K, POINTER, SPACE
       CHARACTER SYMTAB (200)*31, SMALLNAM*31
       INTEGER BLANK, ALPHA, DIGIT, LEFTBRACKET, RIGHTBRACKET,
      *   SINGLEQUOTE, DOUBLEQUOTE, COMMA, SLASH, NUMBERSIGN,
      *   AMPERSAND, SEMICOLAN, ASTERIX, EQUALSIGN, OTHER
       END


 421. F2128: Huge Array Cannot Be Aligned to Segment Boundary

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 26-JUL-1990    ArticleIdent: Q36414

 The Microsoft FORTRAN compiler will give the error

    F2128: name : huge array cannot be aligned to segment boundary

 when an array element spans a segment boundary. This error is
 discussed at the top of Page 218 in the Section 9.3.1.2 "Arrays Larger
 than 64K," in the "Microsoft FORTRAN Optimizing Compiler User's Guide"
 for versions 4.x and on Page 32 in the Section 2.3.2.2, "Limits on
 Fixed-Size Arrays Exceeding 64K" in the "Microsoft FORTRAN Advanced
 Topics" manual for version 5.00.

 The workaround for this limitation is to break up the array into
 arrays smaller than two segments, or change the size of the array
 elements to a power of 2 (2**n) bytes so that no elements cross a
 segment boundary.

 The compiler will attempt to offset the start of a huge (larger than
 64K) array so that no array element spans a segment boundary. If a
 huge array is large enough to cross more than one segment boundary
 (larger than 128K), and if the array elements are not a type whose
 size is a power of two, then no possible offset exists that will
 correctly align the array elements with respect to the segment
 boundaries.

 The following code demonstrates this problem:

       CHARACTER*10 TEST(13107)
       END

 This code gives the following error:

    F2128: TEST : huge array cannot be aligned to segment boundary


 422. Unresolved external _cfltcvt_tab with FORTRAN 4.10

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 25-FEB-1991    ArticleIdent: Q36553

 Question:

 I am getting an error:

     Link : error L2029: Unresolved external __cfltcvt_tab

 Is this an important symbol? How do I resolve it?

 Response:

 There are two instances when you get this unresolved external.
 One is if you are doing mixed language programming between C4.0
 and FORTRAN 4.1 and use any floating point math operations.  The
 other cause can be third party FORTRAN libraries.

 This unresolved external is due to the fact that C Version 4.00 doesn't
 have _cfltcvt_tab but C Versions 5.00 and C 5.10 do. _cfltcvt_tab is not
 necessary, you can still do mixed-language calling or use these FORTRAN
 libraries; you just have to resolve _cfltcvt_tab. You resolve it by
 making a dummy C module that has only one line, as follows:

 char near _cfltcvt_tab[20] = {'0'};

 Compile this and then use the library manager to add this object
 module to your C Version 4.00 library. The command to add it to your
 library is as follows:

 lib llibfp +dummy_c_module;

 (Note: if they do not have our C package your must send them our
 application note that includes this object module.)
 This will take care of your unresolved external and everything
 will work correctly.


 423. Installing In-Line 8087 Instructions

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr appnote S_C
 Last Modified:  7-NOV-1988    ArticleIdent: Q36799

 The assembler code on Page 14 of the "Microsoft FORTRAN 4.1 Update" is
 not correct. When assembled and linked with your FORTRAN application.
 This code will cause divide by zero and overflows to be masked.

 This behavior occurs because the code on Page 14 is incomplete.
 The correct code is listed below. Case is important, so assemble with
 the -Mx switch. You should also link with the /NOE switch. This code
 is provided in line 8087 instructions on FORTRAN Version 4.x and C
 Versions 5.x.

 This application note is also available from Microsoft Product Support
 Services by calling [phone].

 ;************************************************************************
 ;rmfixups.asm -
 ;
 ;   Copyright (c) 1988-1988, Microsoft Corporation.  All Rights Reserved.
 ;
 ;Purpose:
 ;  Link with rmfixups.obj in order to prevent floating point instructions
 ;  from being fixed up.
 ;  The case of these names is important so assemble with the -Mx switch.
 ;
 ;*************************************************************************

 public  FIWRQQ,FIERQQ,FIDRQQ,FISRQQ,FJSRQQ,FIARQQ,FJARQQ,FICRQQ,FJCRQQ

 FIDRQQ  EQU     0
 FIERQQ  EQU     0
 FIWRQQ  EQU     0
 FIARQQ  EQU     0
 FJARQQ  EQU     0
 FISRQQ  EQU     0
 FJSRQQ  EQU     0
 FICRQQ  EQU     0
 FJCRQQ  EQU     0

 extrn   __fpmath:far
 extrn   __fptaskdata:far
 extrn   __fpsignal:far

 CDATA   segment word common 'DATA'
         dw      0
         dd      __fpmath
         dd      __fptaskdata
         dd      __fpsignal
 CDATA   ends

 end


 424. Largest REC Value in a WRITE Statement

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  1-DEC-1988    ArticleIdent: Q36800

 In the WRITE statement, the REC parameter is a positive integer
 expression specified for direct access or binary files. The largest
 value for the REC parameter is 32767.

 The REC parameter is discussed in the "Microsoft FORTRAN Optimizing
 Compiler for the MS-DOS Operating System Language Reference" section
 4.3.5, Page 107.


 425. The Standards to Which FORTRAN Version 4.10 Complies

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | 77
 Last Modified: 11-APR-1989    ArticleIdent: Q36801

 FORTRAN Version 4.10 is certified by the GSA as "error free" with
 respect to ANSI X3.9-1978, which is the FORTRAN77 ANSI standard. Two
 other names for ANSI X3.9-1978 are FIPS PUB 69 and ISO 1539-1980(E),
 so Microsoft conforms to those too.



 426. Loop Optimization with ibset Function

 Product Version(s): 4.00 4.01 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 fixlist4.10
 Last Modified:  1-DEC-1988    ArticleIdent: Q36956

 When compiled with loop optimization on, the sample code below does
 not produce the correct output. With loop optimization turned off, the
 program works correctly. Loop optimizaton can be turned off by using
 the compiler option /Od or /Odct.

 The problem occurs when passing to the intrinsic function "ibset", an
 array variable, instead of a variable. If an interger variable is
 passed to "ibset," or if loop optimization is turned off, the program
 works correctly. This behavior is a problem with the loop
 optimization.

 Microsoft has confirmed this to be a problem in Versions 4.00 and
 4.01. This problem was corrected in Version 4.10.

 More Information :

 The following code demonstrates this problem:

         integer*2 isum(2)
         isum(1) = 0

 c    integer i has fixed value 1 through the program
         i = 1

         do 100 k =1,8
         ii = ibset(isum(i),k-1)

 c   substitute the above line with following two lines, the problem
 c   goes away.
 c       jj = isum(i)
 c       ii = ibset(jj,k-1)

         isum(i) = ii
         write(*,*) isum(i),ii
 100     continue
         end


 427. Sample Code Included on the FORTRAN 5.00 Distribution Disks

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 23-APR-1990    ArticleIdent: Q60980

 The Microsoft FORTRAN Optimizing Compiler Version 5.00 package
 includes many sample programs. Among these are standard FORTRAN
 programs, nearly two dozen sample graphics programs, and a complete
 set of source code for an OS/2 Presentation Manager (PM) application.

 All of the sample programs are on the disk labeled "Source Code."

 The following is a list of the sample code:

 DEMOS Subdirectory  (Demonstration Programs)
 ------------------

    Filename             Description
    --------             -----------

    DEMOEXEC.FOR         FORTRAN demo program (calling a C procedure)
    SWHET.FOR            Popular benchmark program
    EXEC.FI              FORTRAN demo program (include file)
    SIEVE.FOR            Popular benchmark program
    DWHET.FOR            Popular benchmark program
    SORTDEMO.FOR         OS/2 demonstration file

 SAMPLES Subdirectory  (Sample Graphics Programs)
 --------------------

    Filename             Description
    --------             -----------

    REALG.FOR            Chapter 9 graphics example
    SINE.FOR             Chapter 9 graphics example
    COLTEXT.FOR          Chapter 9 graphics example
    CGA.FOR              Chapter 9 graphics example
    EGA.FOR              Chapter 9 graphics example
    HORIZON.FOR          Chapter 9 graphics example
    GRAPHIC.FOR          Chapter 9 graphics example
    COLOR.FOR            Chapter 9 graphics example
    SAMPLER.FOR          Chapter 10 graphics example
    ANIMATE.FOR          Chapter 11 graphics example
    CGAPAL.FOR           Chapter 11 graphics example
    CURSOR.FOR           Chapter 11 graphics example
    FIGURE.FOR           Chapter 11 graphics example
    FILL.FOR             Chapter 11 graphics example
    FONTS.FOR            Chapter 11 graphics example
    MODES.FOR            Chapter 11 graphics example
    PAGE.FOR             Chapter 11 graphics example
    MAGNIFY.FOR          Chapter 11 graphics example
    PALETTE.FOR          Chapter 11 graphics example
    WINDOW.FOR           Chapter 11 graphics example
    SETROWS.FOR          Chapter 11 graphics example
    TEXT.FOR             Chapter 11 graphics example
    WRAP.FOR             Chapter 11 graphics example

 PM Subdirectory  (Sample OS/2 Presentation Manager Program)
 ---------------

    Filename             Description
    --------             -----------

    PMLIST               PMLIST makefile
    PMLIST.DOC           Information about the PMLIST program
    PMLIST.FD            PMLIST declarations include file
    PMLIST.FOR           PMLIST source file
    PMLIST.H             PMLIST header file
    PMLIST.RC            PMLIST resource script file
    PMLIST.DEF           PMLIST definitions file


 428. Internal read of ascii Characters

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-NOV-1988    ArticleIdent: Q37075

 The following program

         character*2 dat2
         dat2=#0A
         read(dat2,'(a2)') n
         write(*,600)dat2,n
    600  format(z,' ',z)
         stop
         end

 produces the following output:

    0A00 2020

 When reading from an internal file, the file is treated as a formatted
 sequential file. When the file contains a hexadecimal 0x0A or 0x0D,
 they will be interpreted as a linefeed or carriage return. When they
 are read from a FORMATTED file, they are read as end-of-record markers
 and blanks are used to fill the record.

 This expected behavior is FORTRAN 77 ANSI standard. See the "American
 National Standard Programming Language FORTRAN ANSI X3.9-1978" section
 12.9.5.2.1 paragraph 45. Also, see the "Microsoft FORTRAN Optimizing
 Compiler for the MS-DOS Operating System Language Reference" section
 4.6 "Internal Files" Page 122.


 429. Internal Compiler Error ctypes.c 1.89 Line 1601

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-NOV-1988    ArticleIdent: Q37077

 When compiled with loop optimization on, the code below generates the
 following error:

        fatal error F1001 : Internal Compiler Error
        (compiler file '@(#)ctypes.c:1.89', line 1601)
        Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Version FORTRAN 4.10.
 We are researching this problem and will post new information as is
 it becomes available.

 The following code demonstrates this problem:

       call gettim(ihr,imin,isec,i100th)
       b=10.0
       c=2.0
       do 10 i=1,1000
        x1=-b+sqrt(b**2-c)
        x2=-b-sqrt(b**2-c)
        x3=x1**2+2*b*x1+c
        x4=x2**2+2*b*x2+c
        x5=-b-sqrt(b**2-c)
        x6=c/x1
        x7=x1**2+2*b*x1+c
        x8=x2**2+2*b*x2+c
 10    continue
       call gettimn(ihr,imin,isec,i100th)
       stop
       end

 The problem can be avoided by compiling with the /Odct optimization.


 430. Common blocks and Segment Limits in OS/2

 Product Version(s): 4.10
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-NOV-1988    ArticleIdent: Q37267

 A very large FORTRAN program you can compile and link under DOS with
 PLink86, compiles but does not link under OS/2 with the Microsoft
 Linker. Error "L1073 file-segment limit exceeded" is produced. Using
 the /SE switch with a large value to increase number of segments does
 not help.

 Although the 80286 allows a process to have 4095 segments in its local
 descriptor table, OS/2 only allows an application to have 254 physical
 segments. In FORTRAN Version 4.10, each common block is given its own
 physical segment. If a program has many common blocks, it may need
 more than 254 segments. Using the /SE switch to increase the number of
 segments will not work properly because this switch is only for
 logical, not physical, segments.

 Using the /PAC option to pack code segments may help. If it does not,
 the only workaround for this problem is to combine common blocks in
 the program.


 431. Manually Building FORTRAN Run-Time Libraries

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | run-time manual
 Last Modified:  4-DEC-1990    ArticleIdent: Q37268

 To build combined Microsoft FORTRAN libraries, use the Setup program
 to build the libraries. If you have problems running the Setup
 program or want to build the libraries manually using the LIB
 utility, follow the procedures below:

 1. Copy the appropriate files (the contents of either your Large- or
    Medium-Model Libraries Disk) to your hard disk.

 2. Copy LIB.EXE to your current directory or make sure it is in a
    directory listed in your PATH statement.

 3. If you are building an emulator or coprocessor library, perform
    the following (where the question mark is either M for medium model
    or L for large model):

       LIB ?LIBFP.LIB

       Operations: -CVT.OBJ

     If you are building the alternate math library, perform the
     following (where the question mark is either M for medium model or
     L for large model)

       LIB ?LIBFA.LIB

       Operations: -FCCVT.OBJ

 4. Run the library manager to create the appropriate FORTRAN library
    as follows:

       LIB <name of the library you want to build>
       Library does not exist. Create?  <y>
       Operations: <from the operations list below>
       List file: <cr>
       Output library: <cr>

 To build a library with C compatibility, leave out either the
 ?CLIB1.LIB or the ?CLIB2.LIB in the lists of operations that follow.

 The following are the operations for all combinations of the FORTRAN
 libraries. Replace the question marks (?) below with either M for a
 medium-model library or L for a large-model library.

 DOS Libraries
 -------------

 Emulator ?LIBFORE.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+EM.LIB+?CLIB1.LIB

 Coprocessor ?LIBFOR7.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+87.LIB+?CLIB1.LIB

 Alternate ?LIBFORA.LIB
    Operations: LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+?CLIB1.LIB

 OS/2 Libraries
 --------------

 Emulator
    Real mode: ?LIBFER.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+EM.LIB+?CLIB1.LIB

    Protect mode ?LIBFEP.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR2.LIB+EM.LIB+?CLIB2.LIB

 Coprocessor
    Real mode: ?LIBF7R.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+87.LIB+?CLIB1.LIB

    Protect mode: ?LIBF7P.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR2.LIB+87.LIB+?CLIB2.LIB

 Alternate
    Real mode: ?LIBFAR.LIB
    Operations: LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+?CLIB1.LIB

    Protect mode: ?LIBFAP.LIB
    Operations: LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB&
                ?LIBFOR2.LIB+?CLIB2.LIB

 The ampersand (&) is used for line continuation. If you place all of
 the operations on one line, replace the ampersand with a plus (+).


 432. Assumed-Sized Array Declarator Not Allowed in Common

 Product Version(s): 3.x 4.00 4.01 | 4.10
 Operating System:   MS-DOS        | OS/2
 Flags: ENDUSER | assumed-size adjustable common
 Last Modified:  7-NOV-1988    ArticleIdent: Q37544

 Question :

 I declare an array in a common block in my main FORTRAN program and
 want to reference it in another module. How can I declare the same array
 in a common block with an adjustable size or assumed-size array in the
 other module?

 Response:

 This CANNOT be done. As defined in ANSI standard (ANSI x3.9-1978,
 section 5.1.2), each array declarator is either an actual array
 declarator or a dummy array declarator. An adjustable array declarator
 and an assumed-size array declarator are dummy array declarators. A
 dummy array declarator is not permitted in a COMMON statement.
 Therefore, it is not possible to declare an array with an adjustable
 or assumed size in a common block.

 You may pass the array declared in your main program to a subroutine
 as an argument and declare the argument with an adjustable array
 declarator or assumed-size declarator in a DIMENSION statement.
 Notice, in the example below, the HUGE attribute must be used if the
 array has huge size.

 The following is an example::

 c source file 1
         program test
         common r(32000)
         ....
         call doit(r)
         end

 c source file 2
         subroutine doit (r)
         dimension r[huge](*)
         .....
         return
         end


 433. F6501 Error from Reading Hex 1A in Unformatted Format

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 23-APR-1990    ArticleIdent: Q60982

 The F6501 error "end-of-file encountered" can be generated if a
 record in an unformatted, direct-access file ends with the hex value
 1A.

 Microsoft has confirmed this to be a problem in FORTRAN Version 4.00.
 This problem was corrected in FORTRAN Version 4.01.

 FORTRAN mistakenly generates the F6501 error when an integer*1 is
 given the value 26 (Hex 1A) and is the last value of an unformatted,
 direct-access record. Hex 1A is an end-of-file marker, and FORTRAN
 mistakenly interprets that as an end-of-file marker, thus causing the
 F6501 error.

 The following sample code illustrates the problem:

       integer*1 d(4)
       open(3,file='test.dat',form='unformatted',
      +access='direct',recl=4)
       read(*,*)(d(j),j=1,4)
       write(3,rec=1)(d(j),j=1,4)
       read(3,rec=1)(d(j),j=1,4)
       end

 The input needed to generate the F6501 error is any three numbers
 separated by commas, followed by the number 26. For example, the
 following input to the above program generates the F6501 error:

    1,2,3,26


 434. FORTRAN: /Zi Switch Causes a .MAP File to Be Built

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q37636

 When compiling with the Microsoft FORTRAN compiler, the FL driver with
 the /Zi option forces the linker to generate a .MAP file.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 This problem does not occur with the Microsoft C Compiler Versions
 4.00, 5.00, 5.10, or with the Microsoft Pascal Compiler Version 4.00.


 435. FORTRAN Option /St Fails if in Enviornment Variable

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-DEC-1988    ArticleIdent: Q38330

 If the Microsoft FORTRAN Optimizing Compiler Version 4.10 option /St
 is placed in the fl= enviornment variable, the compiler stops the
 subtitle at the first blank space in the quotation marks instead of
 stopping at the closing quotation. It also includes the " as the first
 character of the subtitle.

 The following steps produce the problem:

 1. Set your enviornment variable as follows:

    set fl= /c /Fs /St"some subtitle"

 2. Run the Microsoft FORTRAN Optimizing Compiler Version 4.10 as
    follows:

    fl foo.for

 3. Take a look at your foo.lst file; the subtitle appears as
    follows:

    "some

 To get expected results, e.g. correct subtitles, use the following
 steps:

 1. Run the Microsoft FORTRAN Optimizing Compiler Version 4.10 from the
    command line as follows:

    fl /c /Fs /St"some subtitle" foo.for

 2. Take a look at your foo.lst file, the subtitle appears as follows:

    some subtitle


 436. Accessing System and spawnlp and forexec.inc File.

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-DEC-1988    ArticleIdent: Q38332

 The SYSTEM function passes a specified C string to the DOS interpreter
 (COMMAND.COM), which interprets and executes the string as a DOS
 command. The procedure to do this is described on Page 296 in the
 "Microsoft FORTRAN 4.1 Optimizing Compiler User's Guide."

 The manual also states that the INTERFACE statement is required to
 access SYSTEM and _SPAWNLP. Because the INTERFACE statements for these
 two functions are contained in the file forexec.inc (supplied with
 FORTRAN compiler), you can include this file instead of writing the
 INTERFACE statement yourself. The following is an example that uses
 the INCLUDE statement for SYSTEM defined in forexec.inc.

 The following program prints a directory of files in the current
 directory:

 $INCLUDE:'forexec.inc'
       INTEGER*2 SYSTEM
       I = SYSTEM('DIR'C)
       end

 The file forexec.inc is an interface file for C library routines. The
 interface to SYSTEM and _SPAWNLP is defined in the forexec.inc.


 437. Command-Line Switches Require Spaces between Them

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  4-MAY-1989    ArticleIdent: Q43606

 The compiler command-line switches require spaces between them to
 function normally.

 For example, the following command line will execute the compile and
 go directly into the linker, ignoring the /c switch and possibly
 others as well:

    FL/4I2/FPc/Od/c <filename>

 Moving the /c to the front of the command line will result in a
 command-line warning "D4002 ignoring unknown flag," and will continue
 with the compile and link.

 Specifying the line with spaces as shown below will alleviate the
 problem:

    FL /4I2 /FPc /Od /c


 438. Module Name Lost when Compiled with /Gt and /4Yb in FORTRAN

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |  buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q38693

 If the /Gt option is used in conjunction with /4Yb or with the $DEBUG
 metacommand when compiling a program with the Microsoft FORTRAN
 Optimizing Compiler, you will get only the line number, instead of
 both module name and line number.

 Microsoft has confirmed this to be a problem in Versions 4.00, 4.01,
 and 4.10. This problem was corrected in Version 5.00.

 The sample program below demonstrates this behavior. Compile with
 /Gt10 and /4Yb. The following sample purposely simulates a R6103
 divide-by-zero run-time error:

       program zerodivide
       real x, y
       x = 5.0
       y = x
       y = y - x
       x = x / y
       end

 Source filenames are stored in DGROUP. When the /Gt option is used, it
 moves out to a different segment. It appears that the problem occurs
 when the numerical argument to /Gt (i.e., /Gt10) is less than the
 length of the source filename plus 6.


 439. FORTRAN Setup on System with Only 5.25-Inch & 3.5-Inch Drives

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-JUN-1990    ArticleIdent: Q60983

 Microsoft FORTRAN 5.00 does not have a setup option for systems with
 one 5.25-inch drive and one 3.5-inch drive with no hard drive;
 therefore, the setup must be done manually. Below are the steps needed
 to manually set up FORTRAN on such a system.

 This setup is for running the compiler from your 3.5-inch disk drive
 (Drive B), with the source code on your 5.25-inch disk drive (Drive
 A). Copy the following files from the Setup, Compiler 1, and Compiler
 2 disks onto a single 3.5-inch disk. The files are as follows:

 Setup Disk          Compiler 1 Disk         Compiler 2 Disk
 ----------          ---------------         ---------------

 FL.ERR              F3S.EX                  F2.EXE
 FL.EXE              F1.EXE                  LINK.EXE
 FL.HLP              F1.ERR
 F3.EXE              F23.ERR

 The next step is to manually build the appropriate library that you
 will use to link your FORTRAN modules with. The first step is to
 consult the table titled "Library Build Table" below and copy all of
 these modules (for example, LIBH.LIB and LLIBFP.LIB, etc.) and the
 file LIB.EXE from the Utilities 1 disk onto a single 3.5-inch disk.
 Next, with this 3.5-inch disk in Drive B, do the following:

 1. Type the following from the B:\> prompt

       LIB libraryname.LIB <ENTER>

    where libraryname is the name associated with the type of library
    you are making (for example, LLIBFORE.LIB).

 2. The library manager will prompt you at this point with the
    following:

       LIBRARY DOES NOT EXIST, CREATE ?

 3. Type Y and press ENTER at the prompt.

 4. At this point, the library manager will prompt you with the
    following:

       OPERATIONS:

 5. At the prompt, type the following

       +firstmodule.LIB+secondmodule.LIB+...+lastmodule.LIB <ENTER>

    where FIRSTMODULE.LIB is the name of the first module listed below
    in the LIBRARY BUILD TABLE, SECONDMODULE.LIB is the next, and so
    on.

 6. At this point, the library manager will prompt you with the
    following:

       LIST FILE?

 7. Press ENTER at the prompt.

 8. The library manager will create the library that you named in the
    first step.

 Library Build Table
 -------------------

 Emulator Math Library:  ?LIBFORE.LIB  (where ? is M or L)
      OPERATIONS:    LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB+
                     ?LIBFOR1.LIB+EM.LIB+?CLIB1.LIB

 Coprocessor Math Library:  ?LIBFOR7.LIB
      OPERATIONS:    LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB+
                     ?LIBFOR1.LIB+87.LIB+?CLIB1.LIB

 Alternate Math Library:  ?LIBFORA.LIB
      OPERATIONS:    LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB+
                     ?LIBFOR1.LIB+?CLIB1.LIB

 Note: "M" is for building medium memory model libraries, while "L" is
 for large memory model libraries. "L" is the default.

 The following is an example of building a large-model Emulator Math
 Library:

 1. At the prompt, type the following:

       LIB  LLIBFORE.LIB <ENTER>

 2. The following prompt appears:

       LIBRARY DOES NOT EXIST, CREATE? (y/n)

 3. Type the following:

       Y <ENTER>

 4. The following prompt appears:

       OPERATIONS:

 5. Type the following at the prompt;

       +LIBH.LIB+LLIBFP.LIB+LLIBFOR.LIB+LLIBFOR1.LIB+EM.LIB+LCLIB1.LIB <ENTER>

 6. The following message appears:

       LIST FILE?

 7. Press ENTER.

 At this point, the Library Manager will create a large-model Emulator
 Math library named LLIBFORE.LIB. You then need to copy the library you
 just created onto your 3.5-inch compiler disk. The last part of setup
 involves setting up your environment variables. You need to add the
 following lines to the AUTOEXEC.BAT file that is located on your boot
 disk:

    PATH B:\
    SET LIB=B:\
    SET TMP=B:\
    SET INCLUDE=A:\

 The PATH statement tells the computer where to look for the compiler
 and linker files (here we assume that your 3.5-inch run disk is Drive
 B). The LIB statement tells the computer where your library will be,
 the TMP statement tells the computer where to write its temporary
 files, and the INCLUDE statement tells the computer where to look for
 include files.

 You also need to add the following lines to your CONFIG.SYS
 file:

    FILES=20
    BUFFERS=20


 440. No Utilities and Source Code Disk Shipped with FORTRAN

 Product Version(s):
 Operating System:   4.10   | 4.10
 Flags: MS-DOS | OS/2
 Last Modified: 10-APR-1989    ArticleIdent: Q39066
 ENDUSER | docerr

 Problem:

 Page 20 (section 2.4.3) of the "Microsoft FORTRAN 4.1 Optimizing
 Compiler User's Guide" incorrectly states the following:

    Source programs, including the DEMO.FOR demonstration program on
    the Utilities and Source Code distribution disk...

 This should read as follows:

    Source programs, including the DEMO.FOR demonstration program in
    the DEMOS subdirectory of the Setup distribution disk...

 There is no Utilities and Source Code distribution disk included with
 the FORTRAN package.


 441. Implied List in BLOCK DATA Generates Protection Violation

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 16-JUL-1990    ArticleIdent: Q63817

 The Microsoft FORTRAN Compiler version 5.00 generates a "Protection
 Violation" error under OS/2 when compiling the program below with the
 /4Ya switch. This problem does not occur under MS-DOS or in the DOS
 compatibility box of OS/2.

       block data
       integer var(2)
       common /test/ var
       data (var(i),i=1,2) /0, 1/
       end
       end

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for OS/2.

 The following are the workarounds to avoid the "Protection Violation"
 error:

 1. Do not use the /4Ya compiler option.

 2. Change all implied DO lists to lists of array elements and/or
    variables; for example:

        Change:     data (var(i),i=1,2) /0, 1/
        To:         data var(1), var(2) /0, 1/

 3. Compile the program in MS-DOS or the DOS compatibility box of OS/2.

 More information concerning the BLOCK DATA statement and implied DO
 lists can be found on Pages 123-124 and Page 141, respectively, in the
 "Microsoft FORTRAN Reference" manual.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 442. Complex Numbers and Error F2112

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  4-MAY-1989    ArticleIdent: Q39068

 You cannot use variables directly while manipulating complex numbers.
 For example, the program below produces the following error:

    Error F2112 : I : not symbolic constant.

 The workaround is to use an intrinsic function CMPLX, as follows:

    Z = CMPLX(I,1.2).

 The following program demonstrates the problem:

 COMPLEX*8 Z
 REAL*4 I
 Z = (I,1.2)
 end

 Page 24 of the "Microsoft FORTRAN Version 4.1 Optimizing Compiler
 Language Reference and Mixed-Language Programmer's Guide" describes
 complex data types as follows:

    The COMPLEX or COMPLEX*8 data type is an ordered pair of single
    precision real numbers. COMPLEX*16 data type is an ordered pair of
    double-precision real numbers. The first number in the pair
    represents the real part of a complex number, and the second number
    represents the imaginary part.

 For example, the complex number (7,3.2) represents the number 7.0+3.2i


 443. FORTRAN Common Blocks Must Have Same Size if Same Name

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1989    ArticleIdent: Q39069

 When you declare a FORTRAN common block and give it the name of a
 previously declared FORTRAN common block, you must be sure that the
 sizes of the two common blocks are exactly the same. If not, you will
 often receive the following error message:

    error F2323: "block name": COMMON: size changed

 This message is ANSI 77 FORTRAN standard as documented in the "American
 National Standard Programming Language FORTRAN" manual on Page 8-4. It
 states the following:

 "Within an executable program, all named common blocks that
 have the same name must be the same size."


 444. Calling C Graphics Routines From FORTRAN Example

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C S_QUICKC graphics
 Last Modified: 10-APR-1989    ArticleIdent: Q39231

 The Microsoft FORTRAN package does not include a graphics library. One
 effective method of getting Microsoft FORTRAN to do graphics is to
 interface to the graphics library included with either Microsoft
 Optimizing C or QuickC.

 This article presents an example FORTRAN program that demonstrates
 calling the C graphics library from FORTRAN. As written, this example
 will work correctly on a hercules-based system. The modification
 required for other graphics adapters is documented within the program
 below.

 For additional information, query the key words "Graphics For
 FORTRAN" on OnLine.

 The following is an example FORTRAN program:

 c**********************************************************************
 c This is an example FORTRAN program that demonstrates calling C      *
 c graphics library functions.  The interfacing examples presented     *
 c here may be used as a template for calling other graphics library   *
 c functions or other C Run-time Library functions from a FORTRAN      *
 c program.                                                            *
 c                                                                     *
 c To compile and link this program, issue the following command:      *
 c                                                                     *
 c      FL /FPi FGRDEMO.FOR GRAPHICS.LIB /link /NOI                    *
 c                                                                     *
 c The /FPi switch is included for machines that do not have a math    *
 c coprocessor.                                                        *
 c                                                                     *
 c                                                                     *
 c A few caveats of calling C from FORTRAN:                            *
 c                                                                     *
 c  - Every C function being called must have an interface statement   *
 c    because of reasons below.                                        *
 c                                                                     *
 c  - The 'C' attribute must appear in the interface.  This informs    *
 c    FORTRAN to use C calling conventions.                            *
 c                                                                     *
 c  - The alias attribute must appear in the interface.  This serves   *
 c    three purposes:                                                  *
 c     - This allows an underscore to be prepended to function         *
 c       names -- which is consistent with C naming conventions.       *
 c     - FORTRAN, by default, truncates identifiers to six characters. *
 c       An alias allows you to exceed this limit.                     *
 c     - FORTRAN converts all identifiers to uppercase.  An alias      *
 c       gives you the opportunity to declare a function in lower      *
 c       case.  This allows you to preserve case sensitivity during    *
 c       the link phase with /NOI.                                     *
 c                                                                     *
 c  - Any string being passed to C must be a C string (null            *
 c    terminated).                                                     *
 c                                                                     *
 c  - The manifest constants in the C include files are not available  *
 c    to FORTRAN programs.  Whenever a manifest constant is called     *
 c    for, its literal value must be substituted.                      *
 c**********************************************************************

 c
 c     Declare interfaces to C graphics library functions.
 c
       interface to subroutine outtext [C,alias:'__outtext'](string)
       character string [reference]
       end

       interface to integer*2 function setvid[C,alias:'__setvideomode']
      *(mode)
       integer*2 mode
       end

       interface to subroutine rectan [C,alias:'__rectangle']
      *(control,x1,y1,x2,y2)
       integer*2 control,x1,y1,x2,y2
       end

       interface to subroutine setpos [C,alias:'__settextposition']
      *(x,y)
       integer*2 x,y
       end

       Program FGRDEMO
 c
 c Define some variables.
 c
       character*50 greeting
       integer*2    ret
 c
 c The interface statement above is not enough.  We must again
 c state what type 'setvid' will return.
 c
       integer*2    setvid

 c
 c     The C attribute will null terminate this string for passing.
 c
       greeting = 'Hello, world!'C
 c
 c Switch to Hercules graphics mode.  Substitute other values as
 c appropriate (e.g. 16 for EGA/VGA).
 c
       ret = setvid(8)

       if (ret .eq. 0) then
 c
 c If the return value is zero, this mode is not supported.
 c
             write (*,*) 'Selected graphics mode not supported!'
          else
 c
 c Move cursor and display a greeting.
 c
             call setpos (2,5)
             call outtext (greeting)
 c
 c Draw a rectangle.
 c
             call rectan (2,10,5,220,90)
 c
 c Wait for user to hit <ENTER>.
 c
             call setpos (4,5)
             call outtext ('Hit enter to quit:'C)
             read (*,'(A)') ch
 c
 c Go back to the default video mode and terminate.
 c
             ret = setvid (-1)
          endif
       end


 445. Run Time "Please Insert Diskette...", "Cannot Load Overlay..."

 Product Version(s): 3.3x 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | s_link s_c
 Last Modified: 12-JAN-1989    ArticleIdent: Q39335

 When running a FORTRAN Version 3.3x program linked with overlays, the
 following message may be generated:

    Please insert diskette containing PROGNAME.EXE in drive C: and
    strike any key when ready.

 In FORTRAN Versions 4.00, 4.01, and 4.10, the following message may
 appear:

    Cannot load overlay:  too many open files

 The cause is probably a shortage of file handles. The overlay manager
 code didn't have a file handle available for the called overlay. Make
 sure the number of files set in CONFIG.SYS is correct, and close files
 when possible in the program. Resident software (TSR programs) also
 may use up file handles.

 DOS uses up the first five file handles, so the number available to
 the program is five less than the FILES= setting in CONFIG.SYS. If the
 version of DOS is one in which a files setting of greater than 20 is
 not supported (Versions 3.20 or earlier), and if FILES= is set to a
 number greater than 20, the actual files setting may revert to the
 default of 8 handles, leaving only 3 for the FORTRAN program.

 However, even if the DOS is a version that supports a files setting
 greater than 20 (Versions 3.30 and later), the FORTRAN program still
 recognizes only the limit of 20 handles (5 for DOS and 15 for the
 program). It is not possible to cause FORTRAN to recognize more than
 20 file handles.

 If the FILES= setting is correct, then using up all file handles in
 the course of the program will give this message. The program below,
 consisting of three source files, demonstrates this behavior. The
 object modules created from compiling these files should be linked
 using the overlay structure A+(B)+(C).

 The following is the sample program:

 C   This is file A.FOR, the main program.
       OPEN(1, FILE='TEST1')
       OPEN(2, FILE='TEST2')
       OPEN(3, FILE='TEST3')
       OPEN(4, FILE='TEST4')
       OPEN(5, FILE='TEST5')
       OPEN(6, FILE='TEST6')
       OPEN(7, FILE='TEST7')
       OPEN(8, FILE='TEST8')
       OPEN(9, FILE='TEST9')
       OPEN(10, FILE='TEST10')
       OPEN(11, FILE='TEST11')
       OPEN(12, FILE='TEST12')
       OPEN(13, FILE='TEST13')
       OPEN(14, FILE='TEST14')
       OPEN(15, FILE='TEST15')
       CALL X1()
       CALL X2()
       STOP
       END

 C   This is file B.FOR, in the first overlay.
       SUBROUTINE X1()
       WRITE(*,*) 'Here in X1'
       RETURN
       END

 C   This is file C.FOR, in the second overlay.
       SUBROUTINE X2()
       WRITE(*,*) 'Here in X2'
       RETURN
       END


 446. Using Properly Rated Numeric Coprocessors

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | s_c s_quickc s_pascal h_masm b_basiccom b_quickbas
 Last Modified: 18-APR-1989    ArticleIdent: Q39348

 The rated clock speed on coprocessors (8087, 80287, 80387) must be
 greater than or equal to what is recommended on the hardware.
 Otherwise, data integrity will be lost during the use of a
 coprocessor.

 For example, a Compaq 386/20 (20 megahertz) requires a 20 megahertz
 80387 for proper operation. If a floating-point coprocessor rated at a
 slower clock speed is installed, unpredictable results occur. It also
 is possible to damage the coprocessor.

 On some machines, it is not uncommon for the rated speed of the
 numeric coprocessor to be less than the clock speed of the CPU. If you
 do not know the correct coprocessor speed for your machine, check with
 the OEM (Original Equipment Manufacturer) before installing a numeric
 coprocessor.



 447. Bibliography of References for FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 14-MAY-1990    ArticleIdent: Q61298

 The following is a list of useful references for FORTRAN programmers.
 This information applies to Microsoft FORTRAN Compiler versions 4.00,
 4.01, 4.10, and 5.00, which follow the ANSI 77 standard. This list can
 also be found on Page xxiv of the "Microsoft FORTRAN Reference" manual
 that comes with FORTRAN version 5.00.  A similar list can be found on
 page 13 of the "Microsoft FORTRAN Compiler User's Guide" for versions
 4.00 and 4.10.

    "Applied FORTRAN 77 featuring Structured Programming"
    by Roy Agelhoff and Richard Mojena,
    published by Wadsworth (1981)

    "Programming with FORTRAN 77"
    by J. Ashcroft, R.H. Eldridge, R.W. Paulson, and G.A. Wilson,
    published by Sheridan House (1981)

    "Problem Solving and Structured Programming in FORTRAN" (2nd ed.)
    by Frank Friedman and E. Koffman,
    published by Addison-Wesley (1981)

    "The Elements of Programming Style"
    by Brian W. Kernighan and P.J. Plauger,
    published by McGraw-Hill (1978)

    "FORTRAN with Style"
    by Henry F. Ledgard and L. Chmura,
    published by Hayden (1978)

    "FORTRAN 77: Principles of Programming"
    by Jerrold L. Wagener,
    published by Wiley (1980)


 448. Optimization Problem, Assignment Not Made, Write Fails

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q39514

 The code below produces a loop-optimization problem.

 In DOS, the assignment TMP(I,K)=RBAD(K,I) does not affect the value of
 TMP; it remains 0.0, and you receive the following from the write
 statement:

    F6000F"garbage here"illegal unit number

 In OS/2, the write statement causes a segment violation. The problem
 occurs when the program is compiled as follows:

    FL /FPi /Od /AL  test.for

 Note: Turning ON optimization corrects the problem.

 The following code demonstrates the problem:

       IMPLICIT DOUBLE PRECISION (A-H,O-Z)
       DIMENSION TMP(5000,1)
       COMMON/BAD/RBAD(3,3)
       RBAD(1,1)=1
       CALL TRY1(TMP)
       WRITE(0,*)TMP(1,1)
       END
       SUBROUTINE TRY1(TMP)
       IMPLICIT DOUBLE PRECISION (A-H,O-Z)
       DIMENSION TMP(5000,1)
       COMMON/BAD/RBAD(3,3)
       I=1
       K=1
       TMP(I,K)=RBAD(K,I)
       RETURN
       END

 Microsoft has confirmed to be a problem with the Microsoft FORTRAN
 Optimizing Compiler Version 4.10 and 5.00. Microsoft is researching
 this problem and will post new information as it becomes available.


 449. Different Defaults for "SHARE=" under DOS and OS/2

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-APR-1989    ArticleIdent: Q39515

 The default value of the OPEN statement's "SHARE" argument is
 different under OS/2 protected mode and DOS (or real mode). The
 default value under DOS is "COMPAT"; under OS/2 protected mode it is
 "DENYNONE".


 450. Limit on Number of Assigned GOTO Statements in a Subprogram

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  1-SEP-1989    ArticleIdent: Q39516

 The limit on the number of assigned GOTO statements that can be used
 in any subprogram is 256 in FORTRAN 4.1 and 255 in FORTRAN 5.0.

 If this limit is exceeded, the following error will occur:

      F2842  too many assigned GOTO statements

 This information is documented on Page 23 in Section 6 of the "FORTRAN
 4.1 Update" section of the "Microsoft FORTRAN 4.1 Optimizing
 Compiler User's Guide" and on page 460 of the FORTRAN 5.0 Reference
 manual.

 There is a documentation error on page 402 of the FORTRAN 5.0
 Reference which indicates the limit to be 64.


 451. Creating Bound Executables with FL

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JAN-1989    ArticleIdent: Q39605

 You can use the FL command to create a bound program (a program that
 runs in either real or protected mode) by using the /Fb command-line
 option. For example, the following command creates a bound executable
 file, BESSELB.EXE, from the source file BESSEL.FOR:

    FL /Lp /FbBESSELB BESSEL.FOR

 Specifying a name causes FL to create a protected-mode executable file
 (BESSEL.EXE) in addition to the bound program (BESSELB.EXE).

 When you omit the extension for the bound program from the name,
 the bound program is automatically given the .EXE extension. If
 you omit the name altogether, the bound program has the same base
 name as the source file, but includes an .EXE extension. No
 protected-mode program is created when you omit the name. Using the /c
 (compile only) option overrides the /Fb option.

 For the /Fb option to work correctly, the files DOSCALLS.LIB,
 APILMR.OBJ, and API.LIB must be in the current directory or in one of
 the directories indicated by the LIB environment variable.

 The file APILMR.OBJ is always bound with the program unless the
 FL command includes the medium-memory model switch. If you are
 doing mixed-language programming using the medium-memory model
 and your routines allocate both near and far memory, you cannot
 bind your program through FL. Use the BIND command directly and
 include the /n switch and APILMR.OBJ.

 If you are binding mixed-language executable files that have non-
 Family API calls, you must use the BIND utility directly and include
 the /n switch. Please see Page 10 of the "Microsoft FORTRAN Optimizing
 Compiler for MS OS/2 and MS-DOS Operating Systems Version 4.1 Update"
 and section 5 of the "Microsoft CodeView and Utilities Software
 Development Tools for MS OS/2 and MS-DOS Operating Systems Update."


 452. FORTRAN: SAVE and Procedure and Function Names

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q39805

 The SAVE function in Microsoft FORTRAN causes variables to retain
 their values between invocations of the procedure in which they are
 defined.

 You cannot use any function or procedure names in the SAVE statement.

 In Microsoft FORTRAN, all function and procedure names are made
 global. The SAVE function forces variables to be static. If you are
 trying to force a global to be static, it will not be allowed.

 When attempting to do this under Microsoft FORTRAN Version 4.10, you
 receive the following error:

    Fatal Error : Error message too long

 This error message is incorrectly generated. Microsoft has confirmed
 this to be a problem in Version 4.10. This problem was corrected in
 Version 5.00.


 453. Declaring an External C Array from FORTRAN

 Product Version(s): 5.x    |  4.x
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c H_Fortran
 Last Modified: 19-APR-1989    ArticleIdent: Q39850

 If a FORTRAN module wants to access a C array, it must place the index
 of the array after the C external naming convention.

 Consider the following array declared in a C module:

    int test[5];

 If accessing this array from a FORTRAN module, the declaration is as
 follows, with the index of the array AFTER the external declaration
 brackets:

    INTEGER*2 TEST [C,EXTERN] (5)       <=== CORRECT

 If the index is placed directly after the variable name, as follows,

    INTEGER*2 TEST(5) [C,EXTERN]        <=== INCORRECT

 the compiler produces the following error:

    F2115   SYNTAX ERROR

 If FORTRAN tries to access any element of the array, such as TEST(1) =
 6, the compiler produces the following error:

    F2515   LEFT SIDE OF ASSIGNMENT ILLEGAL.


 454. Setting an Array Equal to Another Array

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  9-MAY-1990    ArticleIdent: Q61441

 The quickest and easiest way to set an array equal to another array of
 the same dimension is to just set them equal to each other; that is,
 ARRAY1 = ARRAY2.

 This is a new feature that is non-ANSI Standard. This feature was
 added to FORTRAN version 5.00; therefore, it is not compatible with earlier
 versions of the compiler.

 This information can be found in Section 1.7.5, "Array Expressions,"
 on Page 40 in the "Microsoft FORTRAN Reference" version 5.0 manual.

 Note: You can perform other operations with arrays. See the above
 section of the reference manual for more details.

 The following is an example of setting two arrays equal:

       INTEGER ONE(5),TWO(5)

       DATA ONE /1,2,3,4,5/

       TWO=ONE

       WRITE (*,*) ONE(5)
       WRITE (*,*) TWO(5)

       END


 455. Equivalencing Variables in Same Named Common Block

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 23-MAY-1990    ArticleIdent: Q61442

 In Microsoft FORTRAN version 5.00, errors are generated when compiling
 a program that uses an EQUIVALENCE statement to associate variables
 declared in the same named common block.

 Under OS/2, a "SYS1943: A program caused a protection violation" error
 occurs.

 Under DOS, a "fatal error : error message too long" error occurs.

 The compiler should generate an "error F2317: VAR2, VAR1 :
 EQUIVALENCE : both in common block COMN" compilation error message
 when compiling the following program:

       PROGRAM HELLO
       COMMON /COMN/ VAR1, VAR2
       EQUIVALENCE (VAR1, VAR2)
       END

 Microsoft is currently researching the problem and will post new
 information here as it becomes available.

 The EQUIVALENCE statement causes two or more variables or arrays to
 occupy the same memory location. More information about the
 EQUIVALENCE statement can be found on Pages 164-166 in the "Microsoft
 FORTRAN Reference" version 5.0 manual.

 Compiler compilation error message F2317 is described on Page 432 of
 the "Microsoft FORTRAN Reference: Error Messages" manual and has the
 following explanation:

    Two items specified in an EQUIVALENCE statement at different
    offsets were both in a named common block. These items were
    specified in the EQUIVALENCE statement to be at the same location
    in memory.


 456. Accessing Command Line Arguments and Finding psp Appnote

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 10-APR-1989    ArticleIdent: Q40097

 The accessing the command line appnote that uses the psp to determine
 the location of the command line arguments in memory do not work
 correctly in the OS/2 operating system. This behavior occurs because
 OS/2 does not implement the psp. This situation also leads to not
 being able to access the environment that is also performed through
 the psp.


 457. FORTRAN Does Not Output ASCII 26 (EOF) to LPTx: or COMx:

 Product Version(s): 3.10 3.13 3.20 3.30 3.31 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.x buglist4.00 buglist4.01 buglist4.10 buglist5.00
 Last Modified:  2-AUG-1989    ArticleIdent: Q44472

 Microsoft FORTRAN Versions 3.x, 4.x, and 5.00 does not output ASCII 26
 (EOF) to LPTx: or COMx: devices. It does output ASCII 26 to a file.
 Because ASCII 26 is nonprintable on most printers, this problem is
 difficult to demonstrate.

 There are two workarounds for this problem:

 1. Send the output to a file and then copy the file to the output
    device desired.

 2. Send the output to the screen and redirect screen output to the
    serial or parallel port.

 Microsoft has confirmed this to be a problem in Versions 3.x, 4.x,
 and 5.00. We are researching this problem and will post new
 information as it becomes available.


 458. Docerr: Passing FORTRAN Strings to BASIC

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr B_QuickBas B_BasicCom mixed-language
 Last Modified: 10-APR-1989    ArticleIdent: Q40099

 There is an error in the "Microsoft Mixed-Language Programming Guide"
 on Pages 118-119 in the section labeled "Passing FORTRAN Strings to
 BASIC."

 In the documentation, the positions of the address and length are
 reversed. The following sentence is incorrect:

    Next, assign the address of the string to the first element (using
    the LOC function), and assign the length of the string to the
    second element.

 The correct sentence should read as follows:

    Next, assign to the first element the LENGTH of the string, and
    assign the second element the ADDRESS of the string (using the
    LOC function).

 The following programs demonstrate the procedure.
 ----------------------------------------------------------------------

 The Basic main program:

 DECLARE SUB fsub ()

 CALL fsub                               'Call the FORTRAN subroutine
 END

 SUB pass (a$)
   PRINT a$
 END SUB                                 'Print the passed string

 ----------------------------------------------------------------------

 The FORTRAN subprogram:
 c
 c Compile in Medium or Large Memory model
 c
       subroutine fsub()
       character*20 string
       integer*2    sdesc( 2 )

       string = 'hello world !'

       sdesc( 1 ) = 13
       sdesc( 2 ) = loc( string )

       call pass( sdesc )

       end


 459. FORTRAN on Two-Floppy System Does Not Prompt for Next Disk

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | dual floppy docerr
 Last Modified: 11-APR-1989    ArticleIdent: Q40100

 According to Page 20 of the "Microsoft FORTRAN Optimizing Compiler for
 MS OS/2 and MS-DOS Operating Systems: Version 4.1 Update Guide," you
 will be "prompted" when you should swap disks when running on a
 two-floppy system. This is not correct. The "prompt" is as follows:

    UNABLE TO EXECUTE F2.EXE, PLEASE ENTER NEW FILESPEC:

 This example is the prompt referred to in the manual. You must enter
 the disk that contains the second pass of the compiler, then type the
 following:

    A:F2.EXE

 The process must then be repeated for F3.EXE.


 460. Invalid Object Module Given when Extension Is Not .FOR

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | invalid object module
 Last Modified: 12-JAN-1989    ArticleIdent: Q40132

 If you attempt to compile a FORTRAN source that does not end in .FOR,
 an error regarding an invalid object module is generated.

 This is expected behavior. If a file does not have a .FOR extension,
 the compiler will treat it as an object file.  The linker will detect
 this difference and report it as an invalid object module.

 If the compile line is as follows

    fl for100.777

 The complete error message would be as follows:

    Microsoft (R) Segmented-Executable Linker  Version 5.01.21
    Copyright (C) Microsoft Corp 1984-1988.  All rights reserved.

    Object Modules [.OBJ]: FOR100.777
    Run File [FOR100.EXE]: FOR100.EXE
    List File [NUL.MAP]: NUL
    Libraries [.LIB]:
    Definitions File [NUL.DEF]: ;
    FOR100.777 : fatal error L1101: invalid object module
     pos: 1 Record type: 844E

 The workaround to this error is to either rename the program to have a
 .for extension or use the /Tf command line switch to indicate that the
 file is a FORTRAN source file.


 461. FORTRAN Quick Reference Guide Incorrectly Identifies /TF

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 11-APR-1989    ArticleIdent: Q40135

 The "Microsoft FORTRAN Quick Reference Guide" supplied with FORTRAN
 Version 4.10 incorrectly states that the /TF switch can be used to
 specify a FORTRAN source that does not end with the .for extension.
 However, the correct switch for this is /Tf. This switch is case
 sensitive.


 462. Problem with Floating-Point Accuracy with Minor Code Changes

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | precision
 Last Modified:  2-MAY-1989    ArticleIdent: Q41017

 If there appears to be a problem with floating-point accuracy with
 minor code changes, it may be due to the optimization of the code. In
 the example below, the change was the addition to the write statement
 in the DO loop.

 The workaround to this problem is to use the /Od switch and add the
 options back on one at a time. In the case below, all options were
 turned back on and the code then compiled perfectly.

 The following is the first example:

        PROGRAM TJ1

        REAL X,Y

        X = 20.00
        XL = 0.0
        DO 10 I = 0, 100
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I = ',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM but Y = ', Y
          ENDIF
          XL = XL + 0.01
 10     CONTINUE
         pause' this one is no good, press a key to continue'

        XL = 1.0
        DO 20 I = 100,0, -1
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I =',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM and Y = ',Y
          ENDIF
          XL = XL - 0.01
 20     CONTINUE

        END

 The following is the second example:

        PROGRAM TJ2

        REAL X,Y

        X = 20.00
        XL = 0.0
        DO 10 I = 0, 100
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I = ',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM but Y = ', Y, 'X = ',X
          ENDIF
          XL = XL + 0.01
 10     CONTINUE
         pause' this one is no good, press a key to continue'

        XL = 1.0
        DO 20 I = 100,0, -1
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I =',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM and Y = ',Y, 'X = ',X
          ENDIF
          XL = XL - 0.01
 20     CONTINUE

        END


 463. Carriage Control Works Correctly Only on Terminal Devices

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JUN-1989    ArticleIdent: Q41018

 Question:

 I would like to write to a disk file using carriage control so that
 the file can be printed later. Can this be done?

 Response:

 Not directly. Carriage control is performed only on a unit that is a
 terminal device. There is no way to have carriage control performed on
 a disk file. To accomplish the same effect, the CHAR function or '/' edit
 descriptor must be used to send the desired control codes.

 For more information, see Page 124 of the "Microsoft FORTRAN 4.1
 Optimizing Compiler: Language Reference."


 464. Read Right Justifies If Alphanumeric Field Width Too Large

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q41019

 Problem:

 When I specify an alphanumeric field in a FORTRAN read format that is
 larger than the variable in which I try to store it, sometimes it
 reads blanks and at other times it doesn't read anything.

 Response:

 This is expected behavior according to the "American National Standard,
 Programming Language FORTRAN," approved April 3, 1978. On Page 13-13 it
 states the following:

 "Let len be the length of the input/output list item. If the specified
 field width w for A input is greater than or equal to len, the
 rightmost len characters will be taken from the input field."

 This means that if the alphanumeric format width is greater than the
 variable in which they will be stored, the read actually starts at
 width - variable length + 1. Therefore, as the example below shows, if
 the input record is shorter than the specified format width, the read
 may appear to read blanks or incorrect data.

 The following program shows this behavior (first create a data file to
 read):

 thisisthefirstlineofthefile
 thisisthesecondlineofthefile
 thisisthethirdlineofthefile
 thisisthelastlineofthefile

 Then type in and compile the following program:

       CHARACTER*20 STUFF
       OPEN(UNIT=1,FILE=' ')
       READ(1,'(A100)') STUFF
       WRITE(*,*) STUFF
       READ(1,'(A10)') STUFF
       WRITE(*,*) STUFF
       READ(1,'(A25)') STUFF
       WRITE(*,*) STUFF
       READ(1,'(A)') STUFF
       WRITE(*,*) STUFF
       CLOSE(1)
       STOP
       END

 When the program is run, the following is the output. The first line
 is blank because it starts to read at 100 - 20 + 1 = column 81, the
 second line gets the first 10 characters, the third line starts at 25
 - 20 + 1 = column 6, and the fourth line contains the first 20
 characters. The following is an example:

    thisisthes
    sthethirdlineofthefi
    thisisthefourthlineo


 465. FORTRAN Compiler Corrupts the Environment

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q41021

 The Microsoft FORTRAN Version 4.10 Optimizing Compiler generates the
 following error message:

    error F2836 : statement out of order

 Then, under DOS, it dumps some garbage control characters and corrupts
 the environment. As a result, DOS commands or programs run after the
 compilation do not behave correctly. Symptoms range from messages such
 as "bad file allocation table on drive C" to the machine hanging upon
 the next invocation of a command. Under Version 4.01, the compiler
 locks up.

 Under OS/2, after the F2836 message is displayed, you receive a
 general protection violation, as follows:

    SYS1942: A program attempted to reference storage outside the
    limits of a stack segment. The program was ended.

 The problem is that the DATA statement precedes the COMMON statement.
 This is not valid FORTRAN code. If the two statements are
 interchanged, the program compiles correctly.

 The following is the sample code that causes these problems:

       program foo
       complex*16 x, c
       data i/ 1 /
       common x(1), n(1,1)
       c=(x(n(1,i)) + x(n(1,1)) ) * ( x(n(1,1)) - x(n(1,1)))
       stop
       end

 Note: Once the DATA and COMMON statements are switched, the following
 line must be inserted before the assignment to the C variable for the
 code to run without a protection violation under OS/2:

       n(1,1) = 1

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10. This problem was corrected in Version 5.00.


 466. DNINT and ANINT Functions May Produce Unexpected Results

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  9-MAY-1990    ArticleIdent: Q61522

 The DNINT and ANINT intrinsic functions may return unexpected results
 if the decimal part of the argument passed is "exactly" 0.5.

 The problem is due to single-bit precision errors that occur because
 some values cannot be exactly represented in IEEE floating-point
 format. This is a limitation of the floating-point format, not a
 limitation of the functions.

 DNINT is an intrinsic FORTRAN function that returns the nearest
 integer value to the given argument. Its argument is a REAL*8, DOUBLE
 PRECISION number and it returns a REAL*8 number. ANINT is the same as
 DNINT except that it also accepts a REAL*4, SINGLE PRECISION argument.

 According to the FORTRAN-77 ANSI Standard, given a value of the form
 m.d, where m is the mantissa and d is the decimal part of the number,
 the following is true:

    if d <  0.5, the number returned should be m, and
    if d >= 0.5, the number returned should be m+1

 When compiled with the /Od switch, the following program demonstrates
 the unexpected results. The value returned is 141.52, where it is
 expected to be 141.53 ( DNINT(14152.5)/100.00 ).

      real*8 result,x,y

      x = 166.50d0
      y =   0.85d0
      result = DNINT(x * y * 100.00) / 100.00
      print *,result

      end

 In the example above, 0.85 could not be represented perfectly, thus
 leading to unexpected results. While the program above demonstrates
 the problem only when optimizations are disabled, this behavior is not
 directly related to optimization.


 467. FORTRAN Logic Precedence Example Error

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  4-MAY-1989    ArticleIdent: Q41576

 There is a documentation error on Page 47 in the "Microsoft FORTRAN
 4.10 Mixed-Language Programming Guide." On the fourth line from the
 bottom of the page, an example demonstrates precedence in logical
 expressions. The incorrect line reads as follows:

           go = ((.NOT. a) .OR. b) .AND. c

 The line should read as follows:

           go = (.NOT. a) .OR. (b .AND. c)


 468. Floating Point Numbers in Text File Need .0

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q42358

 If an editor is used to create a data file in which some real numbers
 are to be read, you should always place a ".0" (without the quotation
 marks) after all the numbers to ensure that all numbers are read in
 correctly.

 The following is an example:

 Text File:

 1100110021004100  7576400.0   50000.0    6000.0    8000.0

 FORTRAN Code:

         PROGRAM example

         open(10,file='test.dat',form='formatted')
         read(10,100) a,b,c,d,e,f,g,h
         write(*,*) a,b,c,d,e,f,g,h
 100     format(4(F4.0),4(f10.5))
         close(10)
         end

 If the ".0" were taken off the number 7576400.0, an incorrect value
 would be placed in "h".


 469. CodeView and the $DEBUG Meta Command

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q43066

 If the $DEBUG meta command is used in a FORTRAN program, it can cause
 CodeView to work incorrectly. Symptoms include execution when
 attempting to trace, inability to set either break or watch points,
 and hanging of the system.

 The workaround is to remove to meta command from the code and compile
 using the /Zi switch.


 470. Unresolved External _MAIN or ENTGQQ

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-FEB-1991    ArticleIdent: Q43067

 When linking a program in FORTRAN Version 4.10, if the error message
 received is

     Link : error L2029: Unresolved External:  ENTGQQ

 or

     Link : error L2029: Unresolved External:  _main

 This may indicate that the FORTRAN compiler could not identify
 an entry point into the code.


 471. Intrinsic Functions in Substring Evaluation Not Working Right

 Product Version(s): 4.10  5.00  | 4.10  5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-JUN-1989    ArticleIdent: Q43068

 The following program does not work correctly (the substring value
 does not evaluate properly):

         program string
         character *20 a,b
         b='abcdefghijklmnop'
         i=2
         j=6
         a=b(i:(i+idim(j,2)))
         write(*,*) a
         end

 The following is a workaround to the problem:

         program string
         character *20 a,b
         b='abcdefghijklmnop'
         i=2
         j=6
         k=i+idim(j,2)
         a=b(i:k)
         write(*,*) a
         end

 The workaround performs all computations with intrinsic functions
 before the substring operation.


 472. /Zi May Not Let Include File Open

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q43069

 Problem:

 When I compile without the /Zi switch, my program compiles correctly.
 If I use the /Zi switch, my program can't open the include files.

 Response:

 The problem exists because not enough FILES have been specified in the
 CONFIG.SYS. The /Zi switch will use a file handle.


 473. D, E, F, and G Edit Descriptors and Integer Input Values

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  9-MAY-1990    ArticleIdent: Q61523

 The manner in which FORTRAN's real number edit descriptors (D, E, F,
 and G) handle integer input values may be less than straightforward
 unless the method of interpretation is understood. This method is
 described below.

 The interpretation of integer input is identical for the D, E, F, and
 G edit descriptors. The F edit descriptor is used for the example
 below.

 Syntax: Fw.d

 The input field is w characters wide, with a fractional part d digits
 wide.

 If the decimal point is omitted upon input (that is, the data is an
 integer), the rightmost d digits of the input string, with leading
 zeros assumed if necessary, are interpreted as the fractional part of
 the value represented.

 An example is the following READ statement:

       READ (*, '(F9.4)') xnum

 Input      Number Read
 -----      -----------

 5          .0005
 23456      2.3456
 27         .0027
 -98113     -9.8113
 -286401    -28.6401
 59381      5.9381
 -596E3     -59.6000

 For more information about the real number edit descriptors, see Pages
 90-94 in the "Microsoft FORTRAN Reference" version 5.0 manual, or
 Pages 137-141 of the "Microsoft FORTRAN Language Reference" versions
 4.0 and 4.1 manual.


 474. DPATH Does Not Work for Data Files

 Product Version(s): 4.10
 Operating System:   OS/2
 Flags: ENDUSER | dpath append
 Last Modified: 18-APR-1989    ArticleIdent: Q43292

 When in DOS and using file I/O with FORTRAN Version 4.10, the APPEND
 DOS command allows you to find your data files in other directories.
 However, using the equivalent DPATH command in OS/2 does not work. You
 must specify the proper directory.


 475. INTERFACE Statement May Not Force Data Type Checking

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1989    ArticleIdent: Q43293

 When you use the INTERFACE keyword as in the example below, you must
 remember that data type checking for the specific function or
 subroutine may not be done. In the example below, the fact that the
 main is passing a real that is received as an integer in the function
 is a data mismatch that is not flagged by the compiler. If the
 interface statement is removed, then the data type mismatch is
 flagged.

      INTERFACE TO INTEGER FUNCTION EXAMPLE[C,VARYING] (A,B,C,D)
      INTEGER A,B,C,D
      END

      PROGRAM TEST
      INTEGER W,X,EXAMPLE
      K=EXAMPLE(W,X,Y,Z)
      END

      INTEGER FUNCTION EXAMPLE(E,F,G,H)
      INTEGER E,F,G,H
      EXAMPLE=3
      RETURN
      END


 476. Global Names Can Have Only One Global Definition in Program

 Product Version(s): 3.20 3.30 4.00 4.10 | 3.20 3.30 4.00 4.10
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAY-1989    ArticleIdent: Q43607

 Because global names are recognized anywhere in a given program, they
 can have only one global definition anywhere in that program. All
 subroutine, function, common-block, and program names are global.

 The compiler recognizes the first six characters of a global name and
 disregards spaces, as in the following examples:

          Program foofar
          common/foofares/I,J,K
          INTEGER*2 I,J,K
          END

 In the above example, you will receive the error message
 "F2325:FOOFAR:COMMON:function or subroutine name".

           Subroutine Paint gate
                   .
                   .
           COMMON/PaintG/I,J,K

 In the above example, you will receive the error message
 "F2325:PAINTG:COMMON: function or subroutine name".


 477. Using Fortran for Floating-Point Exceptions on Clones

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  4-MAY-1989    ArticleIdent: Q43768

 If floating-point exceptions are occurring during run time, there is a
 possible solution provided with FORTRAN. On the Setup disk is a file
 called EMOEM.ASM. This file can be used to modify the floating-point
 exception handler. The description of this file is located in the
 "Microsoft FORTRAN 4.1 Optimizing Compiler: User's Guide" under
 Floating Point Operations, Section 8.5, "Using Non-IBM Compatible
 Computers."

 Please note: Microsoft does not support the modification of this file.
 It is up to the manufacturer of the computer in question to provide
 the necessary modifications to correct any floating-point exceptions.


 478. FORTRAN: Division by .1 Yields Unexpected Result

 Product Version(s): 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-NOV-1989    ArticleIdent: Q45092

 The following code yields the expected result of 10 followed by
 significant zeros, as it should for a single-precision real:

                 X = 0
                 Y = 1
                 Z = .1

                 A = (Y - X)/Z
                 WRITE(*,*)' A  = ', A

 (OUTPUT)
           A = 10.000000

 However, if this expression is assigned to an integer as follows, the
 result can be varied:

                 I = (Y - X)/Z
            WRITE(*,*)' I  = ', I

 (OUTPUT)
                 I = 9

 The results are not correct because .1 is a nonterminating fraction in
 binary, and can never be represented exactly. This may result in an
 internal result of 9.99999... for the computation in the computer that
 is then rounded for use with real numbers but truncated at the decimal
 point for use with the integer representation. This is expected
 behavior.


 479. FORTRAN 5.00 Requires OS/2 1.10 or Later

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-NOV-1989    ArticleIdent: Q45221

 There is a documentation error on Page vi of the "Microsoft FORTRAN
 Getting Started." The text states:

    Operating System and Hardware Requirements...the Microsoft FORTRAN
    Compiler, Version 5.0, operates on any IBM or IBM-compatible
    computer running MS-DOS Version 3.0 or later, or OS/2 Version 1.0
    or later.

 The manual should say that Version 5.00 of the Microsoft FORTRAN
 Compiler requires OS/2 Version 1.10 or later.


 480. Error C1041 Occurs Instead of F1041 in FORTRAN

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-MAY-1990    ArticleIdent: Q45616

 FORTRAN version 4.10 may produce the error C1041 and/or the error
 message "Cannot open Compiler Intermediate File" if it does not have
 enough memory to compile. The error should be F1041 rather than C1041.

 This error may also be caused by an incorrectly set TMP environment
 variable or FILES= line in the CONFIG.SYS.

 The TMP environment variable must point to a directory that exists,
 and should not contain spaces around the equals (=) sign. For example,
 the following line points the TMP environment variable to the C:\TMP
 directory:

    SET TMP=C:\TMP

 The FILES= line in the CONFIG.SYS file should be set to a number such
 as 20. If the DOS version you use is earlier than DOS version 3.30 and
 the number of files is set to a number greater than 30, DOS defaults
 to eight. Five files are used by the operating system, so the default
 leaves three for use by the compiler, which may not be enough for any
 working files that must be created. The following line allows 20
 files to be open at one time:

    FILES=20



 481. CodeView Won't Recognize Non-Default File Extensions

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_CodeView
 Last Modified:  8-DEC-1989    ArticleIdent: Q46929

 When debugging a FORTRAN program that has been compiled with a
 "non-.for" extension, CodeView sometimes displays the following
 message:

    Cannot display

 The default FORTRAN source file extension is ".for". CodeView
 uses the extension to determine the language being used. For instance,
 if the source file "test.77" is compiled with the FORTRAN compiler
 (using /Tf to tell the compiler that "test.77" is a FORTRAN file), you
 must ensure that CodeView is also aware that a FORTRAN program is being
 used.

 You can manually select the appropriate language by using the
 pull-down Language menu inside CodeView.

 This problem can occur with any language if the source program has an
 extension different from the default extension for each language (e.g.
 ".for", ".bas", ".c" or ".asm").  You must manually select the
 appropriate language to rectify this problem.

 This problem also can occur with the C compiler, if you use the /Tc
 option to specify that a "non-.c" source file should be accepted. The
 Microsoft FORTRAN compiler will accept a "non-.for" extension on the
 source file if /Tf is used at compile time.


 482. Inline 8087/80287 Assembly Listing Incorrect

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 30-NOV-1989    ArticleIdent: Q46961

 The assembly code listing is incorrect on Page 9 of the "Microsoft
 FORTRAN Advanced Topics" manual and on Page 323 of the "Microsoft
 FORTRAN Reference" manual.

 The incorrect information reads as follows:

       extrn  __fpmath:for
       extrn  __fpsignal:for
       extrn  __fptaskdata:for

       CDATA  segment  word  common  'DATA'
              dw  0
              dw  __fpmath
              dw  __fpsignal
              dw  __fptaskdata
       CDATA  ends

       end

 The corrected information should read as follows:

       extrn  __fpmath:far
       extrn  __fpsignal:far
       extrn  __fptaskdata:far

       CDATA  segment  word  common  'DATA'
              dw  0
              dd  __fpmath
              dd  __fpsignal
              dd  __fptaskdata
        CDATA  ends

        end


 483. FORTRAN 5.00 Err Msg: F1901 Program too Large for Memory

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q47500

 When compiling a large program using FORTRAN Version 5.00, you may
 receive the following error:

    F1901: program too large for memory

 This error can be caused because the symbol table is too big to be
 placed in NEAR HEAP.

 To correct this problem, perform the following:

 1. Copy F1L.EXE from DISK 13, High Capacity Compiler Disk into the
 \BIN directory.

 2. Compile the program using /B1, as shown in the following example:

    FL /B1 D:\FORTRAN\BIN\F1L.EXE

 The complete pathname and filename must follow the /B1 switch.

 Using the high capacity compiler F1L.EXE to compile the program places
 the symbol table into the FAR HEAP.

 The High Capacity Compiler is documented in the README.DOC file which
 is included on the FORTRAN version 5.00 Setup Disk.


 484. Abbreviation for /INFORMATION Is /INF, Not /I

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q47640

 The following error message can be generated when using the incorrect
 abbreviation for the linker /INFORMATION switch:

    L1001 : I : option name ambiguous

 The "Microsoft FORTRAN 5.0 Quick Reference Guide" incorrectly states
 that the abbreviation for /INFORMATION is /I. The correct switch, as
 listed on page 243 of the "Microsoft FORTRAN 5.0 CodeView and
 Utilities User's Guide" is /INF.


 485. F2037: Asterisk with /4Ys, /4Yi, /4Yv Switches (Syntax Error)

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | F2037 comment buglist5.00
 Last Modified: 18-OCT-1989    ArticleIdent: Q47722

  Summary:

 The compiler generates the error message "error F2037 : illegal label
 field" when an asterisk is used in Column 1 to indicate a comment line
 with FORTRAN Version 5.00, and you compile with one of the following
 switches:

    Switch     Description
    ------     -----------

    /4Ys       Strict syntax checking
    /4Yi       SAA extensions
    /4Yv       VAX FORTRAN extensions

 This message is incorrect because the asterisk should be allowed to
 indicate a comment.

 To work around this problem, replace the asterisk with a "C".

 Microsoft is researching this problem and will post new information as
 it becomes available.


 486. Suppressing an 8087/80287/80387 Coprocessor with FORTRAN

 Product Version(s): 3.20 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q47749

 To prevent a FORTRAN program linked with the emulator library from
 using the math coprocessor, modify your environment so the math
 coprocessor is not recognized. You can type in the following line at
 the DOS prompt, or add it to your AUTOEXEC.BAT, and reboot:

    SET NO87=Use of coprocessor suppressed

 If NO87 is set equal to one or more characters, the usage of the
 coprocessor is suppressed. When a program executes and a math
 coprocessor is present, the message "Use of coprocessor suppressed" is
 displayed.

 For more information, consult Page 17 of the "Microsoft FORTRAN 5.0
 Advanced Topics" manual or Page 204 of the FORTRAN 4.X "User's Guide."
 It is listed in the index under Environment Variables, NO87.

 The FORTRAN 3.2 readme.doc also describes the NO87 environment
 variable.


 487. Internal Compiler Error:'@(#)srclist.c:1.59',line 1153

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 18-OCT-1989    ArticleIdent: Q47972

 If a non-existent common block name is placed in a SAVE statement, the
 following F1001 error can occur:

      fatal error F1001: Internal Compiler Error
      (compiler file '@(#)srclist.c:1.59', line 1153)

 To correct the problem, remove the name of the undeclared COMMON
 block.

 The following example demonstrates this situation:

           subroutine subr()
             save /c1/,/test/
             common /c1/ i,j,k
           end

 Remove /test/ from the second line to correct the problem.

 The following error is generated if the subroutine and common block
 have the same name and the /Fs switch is used:

      fatal error F1001: Internal Compiler Error
      (compiler file '@(#)p3io.c:1.93',line 605)


 488. Graphics Routines, Unresolved Externals and FGRAPH.FI & .FD

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | L2029
 Last Modified: 13-FEB-1990    ArticleIdent: Q48025

 Problem:

 I have FGRAPH.FI at the start of my main file and FGRAPH.FD inside my
 subroutine that is in a separate file. When linking the main and the
 file with the graphics call, the graphics routines get flagged as
 unresolved externals.

 Response:

 Page 138 of the "Microsoft FORTRAN 5.0 Advanced Topics" manual states
 that for every file that makes a graphics call, you must have the
 INTERFACE statements at the beginning of that file (INCLUDE 'FGRAPH.FI').
 You then must include FGRAPH.FD (variable declarations) in every
 subroutine that calls a graphics routine. Note: The INTERFACE statement
 needs to be in EACH FILE in which a graphics routine is called.

 The following examples demonstrate this idea:

 -------EXAMPLE #1-------
 CC  Main program and subroutine in same file:
       INCLUDE 'FGRAPH.FI'   ! interface statements at file beginning
       PROGRAM GRAPH
       CALL DUMMY
       END

       SUBROUTINE DUMMY()
       INCLUDE 'FGRAPH.FD'   ! declarations within the subroutine
       CALL clearscreen( $GCLEARSCREEN )
       RETURN
       END

 -------EXAMPLE #2-------
 CC  Main program in a separate file:
       PROGRAM GRAPH    ! No graphics calls in this file, so include
       CALL DUMMY       ! files are not necessary in this file
       END

 CC  Subroutine in a separate file:
       INCLUDE 'FGRAPH.FI'  ! interface statements at file beginning
       SUBROUTINE DUMMY()
       INCLUDE 'FGRAPH.FD'  ! declarations within the subroutine
       CALL clearscreen( $GCLEARSCREEN )
       RETURN
       END


 489. Using NMAKE to Compile FORTRAN Programs in M Editor in OS/2

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | S_EDITOR S_NMAKE
 Last Modified: 16-JUL-1990    ArticleIdent: Q63818

 To compile Microsoft FORTRAN version 5.00 programs using the NMAKE
 utility in the M Editor under OS/2, add the following line to the
 TOOLS.INI file:

    extmake: text nmake /f %s

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for OS/2, the Microsoft Editor version 1.02 for OS/2, and NMAKE
 version 1.01 for OS/2.

 The NMAKE utility (also known as the Microsoft Program-Maintenance
 Utility) interprets a text file of commands, the description file, to
 compare dates of files and carry out other operations on the basis of
 the comparison. That is, NMAKE will check to see if any of the FORTRAN
 programs listed in the description file have been modified. If any
 have, NMAKE will issue commands to recompile and relink the modified
 programs.

 More information regarding the NMAKE utility and the description file
 required by this utility can be found on Pages 285-306 in the
 "Microsoft CodeView and Utilities User's Guide."

 NMAKE is often utilized to compile and link several FORTRAN programs
 at once. For simplicity, only one FORTRAN program will be used here
 to demonstrate how to use NMAKE to compile FORTRAN programs in the M
 Editor.

 The extmake switch above indicates that the text setting, the %s
 symbol, should be used when a compilation is run. When running a
 compilation you pass the text argument to the COMPILE function and the
 editor executes the NMAKE utility according to this text argument.

 For more information about running a compilation according to the
 extmake switch, see Pages 44-45 in the "Microsoft Editor User's
 Guide."

 NMAKE uses the text argument, %s, as the description file because the
 /F option is used. The /F option specifies that the filename following
 it is the description file to use. Additional information about
 the /F option can be found on Page 287 of the "Microsoft CodeView
 and Utilities User's Guide."

 To compile a FORTRAN program, TEST.FOR, using the NMAKE utility in the
 M Editor under OS/2, do the following:

 1. Invoke the M Editor by typing "MEP TEST.FOR" (without the quotation
    marks) at the OS/2 prompt.

 2. If desired, add the following macro and keystroke definitions  to
    the TOOLS.INI file, and then press ALT+C to generate a compile
    window:

    CompWindow:= savecur home meta down  \   ;open compile log window
                 up up up up arg window  \
                 window arg "<compile>" setfile  \
                 window restcur
    CompWindow: alt+c       ;MACRO open compile window

 3. Run NMAKE according to the extmake switch above by pressing ALT+A,
    entering "MAKEFILE" or the appropriate description filename, and
    pressing SHIFT+F3.

 The following is the description file MAKEFILE for the FORTRAN program
 TEST.FOR:

 all : test
 test.obj : test.for
    fl /c $**
 test : test.obj
    link $**;

 The following is the FORTRAN program TEST.FOR compiled using NMAKE in
 the M Editor:

       write(*,*) ' It works!'
       end

 Compiling FORTRAN programs using the NMAKE utility in the M Editor
 in DOS or the DOS compatibility box of OS/2 is not possible because there
 is not enough memory to load all the files needed. For more
 information on this subject, query in this Knowledge Base on the
 following words:

    D2027 and M EDITOR


 490. FORTRAN Err Msg: F2348: Already Declared SAVE

 Product Version(s): 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00 appnote
 Last Modified: 23-JUL-1990    ArticleIdent: Q48624

 The SAVE statement cannot be used on any item more than twice in any
 source file. You will receive a message stating that SAVE is already
 declared.

 This problem has been corrected with an application note which is
 available from Microsoft Product Support Services at [phone].
 The application note is called "FORTRAN 5.0 F1.EXE and F1L.EXE
 Patch."

 The following is an example:

          subroutine a
          common /a/
          save /a/
          end

          subroutine b
          common /a/
          save /a/
          end

          subroutine c
          common /a/
          save /a/
          end

 You receive the following message:

    ERROR:

    F2348: a: already declared SAVE



 491. FORTRAN 5.0 Compiler Error F1001: omf_ms.c:1.118, line 1093

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q48632

 The "F1001: omf_ms.c:1.118, line 1093" internal compiler error is most
 often created in FORTRAN 5.0 by passing a structure to a subroutine
 and trying to use an item in that structure in a READ or WRITE operation.

 An application note called "F1.EXE and F1L.EXE PATCH" is available from
 Microsoft Product Support which corrects this problem.

 The following code produces the above error in DOS and produces a
 protection violation under OS/2:

          subroutine a(ms)
          structure /dataset/
            integer*2 number
          end structure

          record /dataset/ ms

          read(*,10) ms.number
  10   format(i2)
          end

 Another way to alleviate this problem is to use a temporary structure,
 as in the following:

          subroutine a(ms)
          structure /dataset/
            integer*2 number
          end structure

          record /dataset/ ms,fs
          read(*,10) fs.number  ! Read into fs which was not passed
          ms=fs                 ! Assign temp struct. to passed struct.
  10      format(i2)
          end


 492. Deallocating Memory to DOS

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q48636

 When using the DEALLOCATE command with FORTRAN Version 5.00, the
 storage space reserved by ALLOCATE is not returned to the system. Yet,
 the space is free for use inside of the FORTRAN program.

 To clarify Page 143 of the "Microsoft FORTRAN Reference" manual, the
 memory allocated by the ALLOCATE instruction is held by the program
 until the program terminates. The DEALLOCATE instruction frees the
 memory for use inside the main program. The space is not returned to
 DOS.

 If you must have the memory deallocate back to DOS, you can spawn to a
 child process where you ALLOCATE and DEALLOCATE. When the child
 process terminates, the memory that was claimed by the FORTRAN child
 process will be returned to DOS.

 The following code demonstrates this process:

 C----------------------------------------------------------
 C Main file.
 C
       interface to integer*2 function spawnlp
      + [C,VARYING] (mode)
       integer*2 mode
       end
 C
       integer*2 spawnlp
 C
       I=spawnlp(0,loc('child.exe'C),loc('child.exe'C),
      Xint4(0))
       end
 C----------------------------------------------------------

 C----------------------------------------------------------
 C Child process (separate file), called by spawnlp in
 C parent.
 C
       integer size
       character*1 arr1[allocatable] ()
       parameter (size=20000)
 C
       allocate (arr1(size))
       DEALLOCATE (arr1)
       end
 C----------------------------------------------------------


 493. FORTRAN 5.00 Error F2124: CODE GENERATION ERROR

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 31-OCT-1989    ArticleIdent: Q48637

 The following code example generates an F2124 ERROR: CODE GENERATION
 ERROR. The error is caused by using an integer as the argument to the
 AINT() function. The code should cause a syntax error because the
 argument for the AINT() function should only be a real.

 The same code compiles with no errors in FORTRAN Version 4.10.

 Code Example
 ------------

          real*4    x,y
          integer*4 i

          x=aint(y)
          y=aint(i)             <--- causes error
          end

 The following functions also generate the F2124 error when compiled
 with FORTRAN 5.0 and an integer is used as a parameter instead of a
 real variable:  AINT(), ANINT(), ASIN(), ACOS(), ATAN(), ATAN2(),
 COTAN(), AND TAN().


 494. First Error Message Doesn't Appear in M

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | mangled merged message S_EDITOR
 Last Modified: 30-APR-1990    ArticleIdent: Q48638

 The following information is true for MS-DOS only.

 Version 1.02 of the M Editor, which is supplied with FORTRAN version
 5.00, does not display the first error message when compiling a
 FORTRAN version 5.00 program from within M. The M.MSG file displays a
 mixed-up message for the first line. The problem is solved by using
 the /nologo switch for compilation. The compilation line will read as
 follows:

    FL /nologo test.for

 The /nologo switch is an undocumented switch that stops the Microsoft
 copyright logo from appearing when you compile.

 If the Quick or Epsilon configurations have been chosen for the
 Editor, a line must also be added to the TOOLS.INI to define the
 keystrokes for viewing the next error message.

 The following example assigns SHIFT+F3 to NextMsg:

    NextMsg:shift+F3


 495. Library Manager Failure During Installation

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | LIB.EXE tmp components manual build
 Last Modified:  6-DEC-1989    ArticleIdent: Q49253

 If the LIBRARY MANAGER fails during installation of the FORTRAN
 product, check for TSRs (terminate-and-stay-resident software) and
 available RAM memory. If your investigation proves sound (no TSRs,
 and as much free memory as possible), but the LIBRARY MANAGER
 continues to fail, you need to build the libraries manually.

 The easiest method is to create a temporary directory on your hard
 disk. Copy the contents of the appropriate library distribution disk
 (Large or Medium Model Libraries Disk) and the file LIB.EXE into this
 directory. LIB.EXE can be found on the Utilities distribution disk.
 You now can create the necessary library without concern for path
 environments or file locations.

 Upon completion, copy the created library into the \LIB directory and
 then delete the contents of the temporary directory.


 496. FORTRAN 5.00 SYSTEM and SPAWNLP Functions

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr sample demo
 Last Modified:  9-JUL-1990    ArticleIdent: Q48691

 The SYSTEM and SPAWNLP functions are included as part of the FORTRAN
 run-time library. The use of these two functions is demonstrated in a
 program included on the distribution disk labeled SOURCE. The program
 is in the DEMOS directory under the name DEMOEXEC.FOR.

 The comments in this program (and in the include file EXEC.FI)
 incorrectly state that more information is available in Chapter 3 of
 the "Advanced Topics" manual.

 The information is on Page 86 of Chapter 4 of the "Advanced Topics"
 manual under Section 4.2.5.


 497. F2225, NEAR/FAR Attribute Mismatch

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | f2225 addressing
 Last Modified:  6-DEC-1989    ArticleIdent: Q48787

 When using FORTRAN in the large model and calling a subroutine that is
 declared as NEAR, error F2225 "NEAR/FAR attribute mismatch" is
 generated if no INTERFACE statement exists for that subroutine.

 When the compiler passes a CALL instruction in a large model FORTRAN
 program, it reserves 4 bytes for the address of the subroutine. If you
 use the NEAR attribute on the subroutine, only 2 bytes are needed for
 the subroutine address.

 The problem occurs because the compiler assumes the subroutine is type
 FAR if the compiler reaches the call to the subroutine before the
 subroutine declaration. If you then specify the subroutine as NEAR,
 you get the attribute mismatch error.

 To eliminate this mismatch, you must use the interface statement at
 the beginning of the file to explicitly define the subroutine as NEAR,
 as shown in the following example:

       interface to subroutine foo [NEAR] ()
       end

 This procedure lets the compiler know that when it comes across a call
 to the subroutine foo, 2 bytes should be reserved for the address
 instead of 4 bytes.


 498. Increasing Maximum Number of Open Files in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER  | hard-coded
 Last Modified: 10-NOV-1989    ArticleIdent: Q48797

 To increase the limit on the number of open files under FORTRAN
 Version 5.00, follow the steps outlined below. Most of this
 information is also documented on Pages 405-407 of the "Microsoft
 FORTRAN Reference" manual for Version 5.00 and in the file UNIT.ASM,
 which is on the Source Code disk in the STARTUP subdirectory.

 The key point to note in the outline below is that CRT0DAT.ASM must be
 assembled with the following line [where the "l" in /Dmem_l is the
 lowercase letter "l", not the number 1 (one)]:

    MASM /Dmem_l CRT0DAT.ASM

 These alterations require DOS 3.30 or later, or OS/2. The use of
 Microsoft Macro Assembler Version 5.10 or later is also required.

 1. Edit the file CRT0DAT.ASM found on the Source Code disk in the
    \STARTUP\DOS directory (or \STARTUP\OS2 if working under OS/2).

    Change the following line

       _NFILE_=20

    to the following:

    _NFILE_=xx (up to 256)

    You also should delete the comment marks (;) from the following
    lines in CRT0DAT.ASM:

    ;     mov ah,67H
    ;     mov bx,_NFILE_
    ;     callos

    After you delete the comment marks, the lines should read as follows:

       mov ah,67H
       mov bx,_NFILE_
       callos

 2. Edit the UNIT.ASM file on the Source Code disk in the \STARTUP
    directory. Change the following line

       _NFILE_   equ 20

    to the following:

       _NFILE_   equ xx (same as specified in the CRT0DAT.ASM file)

 3. Edit the following line in the CONFIG.SYS file

       FILES=20

    to read as follows:

       FILES=xx (the same number as specified in UNIT.ASM and
                CRT0DAT.ASM files)

    Reboot the machine so the new FILES= statement takes effect.

 4. Assemble the UNIT.ASM and CRT0DAT.ASM files with the following
    lines [note that in mem_l, the last character is the lowercase
    letter "l", not the number 1 (one)]:

       MASM /Dmem_l CRT0DAT.ASM

       MASM UNIT.ASM

 5. Link the .OBJ files with the FORTRAN .OBJ file in the following
    statement:

       LINK /NOE FOO.OBJ + UNIT.OBJ + CRT0DAT.OBJ;

    (where FOO.OBJ is the FORTRAN object code)


 499. /Gt Switch Not Listed in FORTRAN 5.00 Manual Index

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 24-JUL-1990    ArticleIdent: Q48866

 The index for the "Microsoft FORTRAN Reference" manual for Version
 5.00 omits the listing for the /Gt Data Threshold switch. Information
 about the /Gt switch can be found on Pages 326-327 in Section 7.6 of
 the manual.

 The manual should have included the index listing under the topic
 "FL options."

 The /Gt switch places data exceeding a specified threshold into the
 far heap.

 The /Gt switch is documented on Page 232 of the "Microsoft FORTRAN
 Optimizing Compiler: User's Guide" for Versions 4.00 and 4.10.

 /Gt is not available in the FORTRAN Versions 3.x (3.10, 3.13, 3.20,
 3.30, and 3.31).


 500. Allocatable Arrays Not Allowed in Structures in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q48867

 Page 113 of the "Microsoft FORTRAN Reference" for Version 5.00 states
 that allocatable arrays may not appear in AUTOMATIC, COMMON, DATA, or
 EQUIVALENCE statements. This list is incomplete; it should also
 include STRUCTURES.

 Page 228 of the "Microsoft FORTRAN Reference" for Version 5.00 states
 that "Elements cannot be declared with attributes. For example,
 INTEGER var[FAR] is not permitted." Since allocatable arrays must be
 declared with attributes, they can't be used in structures.


 501. Sample Code on Page 165 in FORTRAN 5.00 Reference Is Correct

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q48868

 The sample code on Page 165 of the "Microsoft FORTRAN Reference" for
 Version 5.00 incorrectly states that when you equivalence a real and a
 character array so that the real falls onto an odd byte, the compiler
 generates an error. However, the sample code that is given compiles
 properly.

 The documentation states the following on Page 165 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00 (and Page 211 of the "Microsoft
 FORTRAN Optimizing Compiler: Language Reference" for Versions 4.01 and
 4.10):

    Microsoft FORTRAN permits character and noncharacter entities to be
    associated, but not in such a way that noncharacter entities start
    on an odd-byte boundary. If necessary, the compiler adjusts the
    storage location of the character entity so the noncharacter entity
    begins on an even byte. The following example causes a compile-time
    error:

       CHARACTER 1 char1(10)
       REAL reala, realb
       EQUIVALENCE (reala, char1(1))
       EQUIVALENCE (realb, char1(2))

 (Also note that the asterisk is missing in the character declaration.
 It should read "CHARACTER*1").

 If you compile the above code, not only does it compile properly,
 the following will be true if you create a listing:

 1. char1 has the offset 0000h.

 2. reala has the offset 0000h.

 3. realb has the offset 0001h.

 The equivalence statement appears to work correctly.


 502. F2836: "Statement Out of Order" for DATA Statement

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49730

 The first paragraph on Page 48 of the Version 5.00 "Microsoft FORTRAN
 Reference" states "All specification statements must precede all DATA
 statements, statement-function statements, and executable statements."
 If you do not follow this format, the compiler generates the following
 error message:

    F2836: statement out of order

 The following example generates the "statement out of order" error
 because a DATA statement precedes an integer declaration statement:

       integer n
       data n /1/
       integer m
       end

 The table on Page 47 of the "Microsoft FORTRAN Reference" outlines the
 order that statements must be in for the code to compile correctly.

 Consider the following rules when using the DATA instruction:

 1. The DATA statement must follow COMMON, DIMENSION, EQUIVALENCE,
    EXTERNAL, INTRINSIC, and SAVE instructions.

 2. The DATA statement can work in conjunction with the following:

       Executable statements
       Statement function statements
       ENTRY and FORMAT statements
       All metacommands except the following:

          $DO66,
          $[NO]FLOATCALLS
          $[NO]FREEFORM
          $STORAGE

 3. The DATA statement must follow every other command.

 4. The DATA statement must precede the END instruction.


 503. EXAMPLE Output Incorrect on Page 201 of FORTRAN 5.00 Reference

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 24-JUL-1990    ArticleIdent: Q48943

 The EXAMPLE output for the NAMELIST operation on Page 201 of the
 "Microsoft FORTRAN Reference" manual for Version 5.00 is incorrect.

 All NAMELIST interactions require the forward slash (/) to terminate
 the interaction.

 To correct the problem, add a line to the end of the example that
 contains only a forward slash. The example should read as follows:

        &EXAMPLE
        I1 =      11
        I2 =      12

        .
        .
        .

        C10 = '0123456789'
        IARRAY =      41      42      43
        /


 504. Reading Environment Variables from FORTRAN 5.00

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JAN-1990    ArticleIdent: Q48957

 The program shown below demonstrates how to obtain environment
 variables from the MS-DOS environment. The program calls the C
 getenv() function, which is a built-in part of the FORTRAN Version
 5.00 Library.

 The interface statement and the character function GETENV are the
 required portions, while the main program is for demonstration
 purposes.

 The problem occurs because the C function is designed to return a
 pointer to the contents of the variable. The function does not find
 the variable; it returns a NULL, which causes a problem under FORTRAN
 because there is no way to check for a NULL.

 To correct this problem, you need to look for a variable that does not
 exist. Use the following procedure:

 1. Call getenv() on non-existent variable.

 2. Call getenv(VAR) where VAR is what you want to find.

 3. If the results match, VAR does not exist.

 4. If the results do not match, you have a return value.

 Sample Program
 --------------

        program environment
        character name*20,  string*128, fgetenv*128
        write (*,*) ' Enter name of environment variable'
        read (*,'(A)') name
        string = fgetenv(name)
        write (*,*) 'Value is: ',string
        stop
        end

        interface to character*128 function getenv [c] (var)
        character*21 var [reference]
        end

        character*128 function fgetenv(var)
        character getenv*128, dummy*128, var*20, cvar*21
        integer n
        n = len_trim(var)
        cvar = var(1:n)//char(0)
        fgetenv = char(0)
        dummy = getenv(fgetenv)
        fgetenv = getenv(cvar)
        if (fgetenv.eq.dummy) then
            fgetenv = ' '
        end if
        fgetenv = fgetenv(1:index(fgetenv,char(0)))
        return
        end


 505. VERIFY Function Returns an Integer, Not a Logical

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q48984

 The table of Intrinsic Character Functions on Page 256 of the
 "Microsoft FORTRAN Reference" manual for Version 5.00 incorrectly
 lists the VERIFY function as type logical. The VERIFY function is an
 integer function.

 The examples of the use of the VERIFY function on Pages 257 and 268 of
 the FORTRAN reference correctly show that VERIFY returns an integer.


 506. Syntax, Description of NAMELIST Instruction in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q49254

 The NAMELIST instruction was introduced in FORTRAN Version 5.00.

 As stated on Page 200 of the "Microsoft FORTRAN Reference" for Version
 5.00, a NAMELIST "declares a group name for a set of variables so they
 may be read or written with a single namelist-directed READ or WRITE
 statement."

    SYNTAX:    NAMELIST /namelst/ varlst [/namelst/ varlst]

 namelst is the name for a group of variables (the name of the
 namelist), and varlst is all the variables in the NAMELIST.

 The main purpose of NAMELIST is to allow you to READ or WRITE groups
 of data with one READ or WRITE instruction.

 When a NAMELIST READ (or WRITE) is performed, the information is read
 (or written) in a specific format. This format has three parts: a
 header, the body, and the terminator. The header consists of the name
 of the NAMELIST preceded by an ampersand (&). The body consists of any
 of the NAMELIST variables you want to READ or WRITE. The terminator is
 a forward slash (/).

 The following code (where "example" is the name of the namelist):

    WRITE (*,example)

 produces output as follows:

 &example
 thischar = 'a'
 numint  = 256
 realval = 3.14
 /

 When reading a NAMELIST, start the READ with the header and then
 explicitly READ each variable. Because a NAMELIST allows you to read
 less then the total number of variables in the list, you must use the
 variable name as you enter the data. This allows the NAMELIST to fill
 that particular variable. If you leave off this assignment, you get
 the run-time error F6511 "variable name not found".

 The following is typical data that would be entered from the keyboard
 in response to the line "READ (*,example)":

 &example
 thischar = 'a'
 numint  = 256
 realval = 3.14
 /

 The header (&example) and terminator (/) must both be entered.


 507. FORTRAN: Internal Compiler Error: @(#)p2symtab.c:1.4 line 939

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49374

 The code below produces the following error:

  fatal error F1001: Internal Compiler Error
         (compiler file '@(#)p2symtab.c:1.4', line 939)
         Contact Microsoft Technical Support

 The code below should produce a syntax error because, according to the
 last paragraph on Page 135 in the "Microsoft FORTRAN Reference" manual
 for Version 5.00, "An item that appears in 'nlist' cannot be
 initialized in a type statement."

 Code
 ----

          integer*1 a(1,1) /10/
          common /st/a
          end


 508. Spaces Converted to Zeros; BZ Edit Descriptor

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr BN BZ
 Last Modified:  6-DEC-1989    ArticleIdent: Q49430

 The last paragraph on Page 86 of the "Microsoft FORTRAN Reference"
 manual for Version 5.00 incorrectly states the following:

    ...so the first thing the I/O system does is to pad
    the record 502 on the right with two blanks. If BZ
    editing were in effect, those two blanks would be
    interpreted as zeros,and the record would be equal
    to 50200.

 This is a documentation error. The BZ edit descriptor is designed to
 replace any spaces in the input with zeros, provided the space is not
 a leading space.

 Contrary to Page 86, the I/O system does not pad spaces to the right
 of the two; therefore, the BZ edit descriptor does not add zeros to
 the end of the number.

 With BZ editing, if the user types "502" (without the quotation marks)
 and presses ENTER, the variable that is being read equals 502, not
 50200.

 In contrast, if the user enters "502" followed by two spaces, then
 presses ENTER, the variable is read as 50200.


 509. SPAWNLP and Unresolved External: CLOC

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49432

 On Page 88 in the "Microsoft FORTRAN Advanced Topics" manual for
 Version 5.00, the code sample for calling SPAWNLP incorrectly has a
 lowercase  "c" on the end of the line. The "c" must be removed to
 properly LINK the program.

 If the "c" is included in the code, you get a link error regarding an
 unknown function called CLOC because the "c" is concatenated with
 "LOC" on the following line.

 The following error is generated:

     error L2029 : 'CLOC' : unresolved external

 The "c" should be removed from the end of the following line:

       I = SPAWNLP(0, LOC('EXEMOD'C), LOC('EXEMOD'C), c
      + LOC('DEMOEXEC.EXE'C), INT4(0))


 510. SHARE Not Installed in OS/2 with FORTRAN 4.10

 Product Version(s): 4.10
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49433

 The following error message incorrectly occurs if a program compiled
 with FORTRAN Version 4.10 is run under OS/2, and if an existing file
 is OPENed as NEW:

    run-time error F6412: OPEN(filename) - SHARE not installed

 The following is the correct error message generated under FORTRAN
 5.00:

    run-time error F6415: OPEN(filename) - file already exists

 The following code demonstrates the problem if the file TRY.DAT
 exists:

        OPEN (1,FILE = 'TRY.DAT',STATUS = 'NEW')
        AB = 15
        WRITE (1,*) AB
        END


 511. Order of C and FORTRAN Libraries at LINK time

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49446

 In the second paragraph under Specifying Libraries on Page 79 of the
 "Microsoft FORTRAN Advanced Topics" manual for Version 5.00, the
 following statement is made:

    If your program uses both FORTRAN and C, then specify the library
    for the most recent of the two language products first.

 The above information is correct; however, the following later
 sentence is incorrect:

    If you use C 5.1 or later, specify the C library first.

 The FORTRAN 5.00 library should come before the C 5.10 library because
 the FORTRAN 5.00 library is newer. The next line states that you
 should "...make sure you choose a C-compatible library when you
 install FORTRAN."

 In reality, if the FORTRAN is newer than the C, (e.g. FORTRAN 5.00
 being newer than C 5.10), FORTRAN should NOT be installed with C
 compatibility, and the LINK options /NOD and /NOE should be used to
 avoid errors about multiply defined symbols.


 512. /Fo Compiler Switch Moves Only the First Object File

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr buglist5.00
 Last Modified: 18-OCT-1989    ArticleIdent: Q49447

 The /Fo compiler switch doesn't produce any error messages; it also
 doesn't work as indicated on Pages 338-339 in the "Microsoft FORTRAN
 Reference" manual for Version 5.00:

    C:\> FL /FoD:\OBJECT\  *.FOR

 The above command line should place all the .obj files in the
 directory OBJECT on the D drive. Instead, it incorrectly places only
 the .obj of the first file it compiles in the directory OBJECT, while
 placing the remainder of the files in the current directory (i.e., the
 root directory on the C drive in the above example).


 513. $PACK Metacommand Syntax Incorrect in FORTRAN 5.00 Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49450

 Contrary to statements made on Page 305 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00, the syntax for the $PACK
 metacommand must include a colon, as shown in the following:

    $PACK:

 If a colon is not used, the following error occurs:

    F2030: unrecognized metacommand

 The following three documentation errors occur on Page 305:

 1. The first error pertains to the following syntax statement:

       $PACK[:{1|2|3}]

    This incorrect statement shows the colon as an optional character;
    it is not an optional character. It should read as follows:

       $PACK:[{1|2|3}]

    If the colon is left out, the compiler does not recognize "$PACK"
    as a metacommand.

 2. The second-to-last paragraph is also incorrect. It states the
    following:

       If $PACK is specified (no colon or number), packing reverts to
       whatever mode was specified in the command-line /Zp option.

    Because the $PACK metacommand must contain a colon, the sentence
    should instead read something similar to the following:

       If $PACK is specified (without a number)...

 3. In the example, the use of the metacommand is incorrect. The first
    line should read as follows:

       $PACK:


 514. Conditional Compiling with /4cc"string"

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49451

 /4cc<string> permits conditional compilation of a source file. Page
 335 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 states the following:

    The /4cc option permits conditional compilation of a source file.
    The string is a set of alphabetic characters controlling which
    lines in the source file are to be compiled.

 A similar paragraph is located on page 93 of the FORTRAN 4.00 and 4.10
 User's Guide.

 An example of code that can be conditionally compiled is shown below.

       program test
 L     integer*4 num
 S     integer*2 num
 R     real*4 number
       end

 When compiling this code, if you compile with /4ccL, the compiler
 reserves 4 bytes for num. If you compile with /4ccS, num is 2 bytes.

 If you leave off the /4cc switch, the L, S, and R lines are considered
 comment lines. Or, if you compile with /4ccLS, you get a multiple
 defined symbol error because num is defined twice. /4ccLR or /4ccSR
 define num as the appropriate size, and define number as a real.


 515. Conditional Compilation of Metacommands in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49466

 Question:

 How can I conditionally compile Metacommands? Metacommands require the
 "$" in the first column of the source line, and the /4cc switch also
 requires a character in the first column.

 Response:

 You cannot use the /4cc switch to conditionally compile metacommands.
 The metacommands $IF, $ELSE, $ELSEIF, and $ENDIF, as well as $DEFINE
 and /D, are designed for the conditional compiling of metacommands.
 Pages 281-284 and 335 of the "Microsoft FORTRAN Reference" manual for
 Version 5.00 cover the use of these commands.

 The following example demonstrates how to conditionally compile using
 these commands:

 $IF DEFINED (L)
 $INCLUDE 'large.inc'
 $ELSE
 $INCLUDE 'medium.inc'
 $ENDIF

 If the source file does not contain the line "$DEFINE L" preceding
 this $IF block, the $ELSE half is compiled and the file MEDIUM.INC is
 included. If "$DEFINE L" precedes this $IF block, the file LARGE.INC
 is included; this gives you the ability to hard code the conditional
 changes.

 If you'd like to change the compilation without hard coding it, the /D
 option on the command line allows you to define the variable that is
 used with the $IF block. This action eliminates the need for the
 $DEFINE metacommand. In the previous example, if you wanted to include
 the file LARGE.INC, you'd compile with a line such as the following:

    fl /DL name.ext


 516. FORTRAN Err Msg F3606, F3607: Type and Length Mismatch

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49467

 When calling a subroutine or function on a VAX with FORTRAN Versions
 4.x or 5.00, you don't need to be consistent when passing formal
 arguments. When porting VAX code down to a PC, the FORTRAN 5.00
 compiler catches this inconsistency with the errors F3606 (type
 mismatch) and F3607 (length mismatch).

 F3606 and F3607 are recoverable errors; the compiler produces an OBJ
 file. You can either ignore the errors or be consistent when passing
 formal arguments.

 For more information, see Page 462 in the "Microsoft FORTRAN
 Reference" manual for Version 5.00.

 The following code generates the errors:

       integer*4 intX
       logical*1 logic
       call sub1(logic)
       call sub1(intX)
       end
 c
       subroutine sub1 (intY)
       integer*4 intY
       end

 When the compiler interprets this code, it reserves 4 bytes for the
 intX variable and 1 byte for logic. It then finds the "call
 sub1(logic)" line and assumes the formal argument needs only 1 byte.
 When it comes across the next call to sub1, the compiler finds the
 formal argument has changed and flags the errors. Not only has the
 length of the formal argument changed, the type has also changed.


 517. Using FORTRAN to Check Syntax, /Zi and /Fs

 Product Version(s): 4.00 4.01 4.10 5.00 |4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49493

 If you compile with /Zs using FORTRAN Versions 4.x or 5.00, the
 FORTRAN compiler checks only the syntax of the source file.

 Using /Zs eliminates the bulk of the compiler's work, thus saving time
 during compilation. Using /Fs in conjunction with /Zs prompts the
 compiler to record the error messages to a file.

 The /Zs option should be used for the first few compilations. After
 the majority of the syntax errors are corrected, compile without /Zs.


 518. END DO Example Incorrect in FORTRAN 5.00 Reference Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49496

 If you compile the example on Page 159 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00, an F2115 syntax error occurs.

 This error occurs because the second print statement incorrectly
 contains a comma.

 The example from page 159 follows:

       Do ivar = 1, 10
          PRINT ivar
       END DO

       ivar = 0
       DO WHILE (ivar .LT. 10)
          ivar = ivar + 1
          Print , ivar     ! delete the comma in this line
       END DO


 519. FORTRAN Err Msg: D2027: Could Not Execute 'Filename'

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49497

 When invoking the FORTRAN compiler, I get the following error:

    D2027: could not execute F1.EXE

 This error very likely occurs because the system doesn't have enough
 memory to load the file F1.EXE (the first pass of the compiler).
 FORTRAN requires 320K of free memory to load (512K is recommended).

 To work around this problem, try to eliminate other programs [e.g.
 terminate-and-stay-resident programs (TSRs)] from memory, thereby
 making that memory available for FORTRAN.

 The "Microsoft FORTRAN Reference" manual for Version 5.00 states the
 following on Page 411:

    The specified file containing a compiler pass or the linker was
    found but for some reason could not be executed. An illegal EXE
    file format is the most likely cause.


 520. FORTRAN Err Msg: QuickBASIC Calling FORTRAN Error F6700

 Product Version(s): 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49498

 Question:

 When I compile and link a QuickBASIC program calling a FORTRAN
 subroutine, I get the following error message:

    F6700: Heap Space Limit Exceeded error

 Response:

 This error occurs because QuickBASIC needs to define a stack that
 FORTRAN can use, as demonstrated by the following code:

 QuickBASIC Code
 ---------------

     DIM heap%(2048)
     COMMON SHARED /nmalloc/ heap%()

     REM ** TO DECLARE 2K OF HEAP SPACE THE FORTRAN
     REM ** CAN USE

     DECLARE SUB ftest ALIAS "ftest"
     CALL ftest
     PRINT ""
     PRINT "Return from Fortran subroutine"
     END

 FORTRAN Code
 ------------

     SUBROUTINE ftest
     WRITE (*,*) 'Into the Fortran subroutine'
     RETURN
     END

 The QuickBASIC code must be compiled as stand-alone code. To compile
 and link, do the following:

 BC /o basic.bas

 FL /c fortran.for

 LINK /NOE basic+fortran,,,bcom45 llibfore;

    (Where basic.bas is the basic source code and fortran.for
    is the fortran source code.)

    You should link with the QuickBasic BCOM45 library first
    and specify which Fortran library to use (LLIBFOR7,
    LLIBFORE,...)


 521. Ways to Open a File from the Command Line in FORTRAN

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49507

 FORTRAN allows the following three different ways to open files:

 1. Hard coding the filename.

 2. Allowing the user to enter the filename.

 3. Letting the program create a temporary file.

 All of these options are covered on Pages 203-204 of the "Microsoft
 FORTRAN Reference" manual for Version 5.00 and Page 249 of the
 "Microsoft FORTRAN Optimizing Compiler: Language Reference" for
 Versions 4.x.

 To open a file from the command line, you must do the following:

 1. Set the FILE parameter in the OPEN statement equal to a blank
    (FILE=' ').

 2. Specify the full filename of the file to be opened on the command
    line when activating the program.

 Consider the following code as an example. The source file is called
 "test.for" and appears as follows:

       PROGRAM test
       OPEN (10,FILE=' ')
       END

 The data file to be opened is called "test.dat". To open the file from
 the command line, type the following:

       test test.dat

 If you fail to specify the data filename on the command line, the
 program prompts you for the file to be opened.


 522. FORTRAN Err Msg: F1050: Code Segment Too Large (4718)

 Product Version(s): 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | VAX port
 Last Modified:  6-DEC-1989    ArticleIdent: Q49515

 When I download a FORTRAN source code that contains 5878 lines of code
 from the Prime Mini-Computer and the entire source is contained within
 one module, the following error is generated during compilation:

    F1050: CODE SEGMENT TOO LARGE (4718)

 The amount of code within the one module exceeds 64K in size, so you
 need to modularize this program source code. Break the code into
 subroutines and place some of these subroutines into another file.
 This procedure results in several .FOR files, which can be compiled
 separately and then linked together to form one .EXE file.

 The limitation on the size of a code segment also applies to OS/2
 because OS/2 is based upon the segmented architecture of the 80286.


 523. L2029: Unresolved External _main in crt0.asm

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | L2029 F2830
 Last Modified:  6-DEC-1989    ArticleIdent: Q49526

 UNRESOLVED EXTERNALS referencing "crt0.asm in _main", "end not found"
 or ENTGQQ can occur because the compiler or linker cannot determine an
 entry point into the program.

 To correct this problem, make sure that the FORTRAN source code begins
 in column seven and that the program has an END statement.

 Each line of the following program starts in column one. The compiler
 views these lines as comments, and does not flag an error. However, at
 link time, the LINKer cannot find the end statement, and therefore
 cannot identify the main program. Thus, the unresolved external
 _main occurs.

 integer*4 i
 i=5
 write(*,*) i
 end

 ... crt0.asm) : error L2029 : '_main' : unresolved external

 If the same code is moved to column seven, but the end statement is
 removed, the following compiler error occurs:

    error F2830: END missing


 524. Writing Nonprintable Characters with FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | ascii ctrl-z escape esc lf linefeed
 Last Modified:  6-DEC-1989    ArticleIdent: Q49528

 If you need to print a nonprintable character with FORTRAN, you can
 use the CHAR intrinsic function. The CHAR intrinsic function accepts
 an integer and converts it to a character. The following code
 demonstrates this idea:

       write (*,'(A1)') CHAR(13)

 This line of code writes the nonprintable character, carriage return,
 to the screen.


 525. FORTRAN Err Msg D2027 When Compiling with FORTRAN, M Editor

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49534

 Problem:

 I tried to compile FORTRAN Version 5.00 source code while using the M
 Editor Version 1.02. M issued a beep almost instantly, and did not
 display any error messages.

 Examination of the M.MSG file located in the TMP directory revealed
 the following error message:

    Command line error D2027 : could not execute 'C:\BIN\f1.exe'

 Prior to entering the editor, a CHKDSK revealed 445,000 bytes of
 available RAM.

 Response:

 This error message occurs because of the lack of available memory to
 run the entire FORTRAN compilation process. If you want to compile
 from within the Editor, you need at least 480K free before invoking M,
 depending on the size of the source code. Larger programs consequently
 require more free memory.


 526. Conditional Compiling with $DEBUG

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49670

 Page 286 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 and Page 289 of the Microsoft FORTRAN Optimizing Compiler: Language
 Reference" for Versions 4.00 and 4.10 state that the $DEBUG
 metacommand can be used for conditional compilation. The example
 below demonstrates this.

 In the following code fragment, only the lines that start with either
 the letter "A" or "B" are compiled; the other lines are considered
 comments:

 $DEBUG:'AB'
 A     integer*2 N
 B     integer*2 M
 C     integer*4 N
 D     integer*4 M
 A     real*4 R
 C     real*8 R
 C

 The last paragraph on Page 286 of the "Microsoft FORTRAN Reference"
 for Version 5.00 states the following:

      If the optional string is specified, the characters
      in string specify that lines with those characters in
      column 1 are to be compiled into the program. Case is
      not significant. Note that the letter C always
      indicates a comment line; therefore, if string contains
      a C, the C is ignored.

 Page 290 of the "Microsoft FORTRAN Optimizing Compiler: Language
 Reference" for Versions 4.00 and 4.10 has a similar paragraph.

 For more information on conditional compiling, see the /4cc compile
 option on Page 335 of the FORTRAN 5.00 reference manual and Page 93 of
 the FORTRAN 4.00/4.10 user's guide mentioned above.


 527. FORTRAN Err Msg: F1901: Program Too Large for Memory

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49708

 If a program uses a DATA statement that contains an extensive amount
 of data, the compiler may generate the following fatal error:

    F1901: program too large for memory

 The FORTRAN compiler uses the near heap to store data during
 compilation. This space can be exceeded. To free up near heap memory,
 use the high capacity compiler, which became available with FORTRAN
 Version 5.00.

 To use the high capacity compiler, copy the file F1L.EXE from the
 FORTRAN 5.00 High Capacity Compiler Disk to the FORTRAN BIN directory
 and compile with the /B1 switch.

 For example, if the source file is TEST.FOR and the high capacity
 Compiler is in the C:\FORTRAN\bin directory, compile using the
 following line:

 FL /B1 C:\FORTRAN\BIN\F1L.EXE TEST.FOR

 The following source code demonstrates this problem. If the array
 subscript for tmp changes from 254 to 256, or if another data item is
 added to the file, the program is too large for memory. The problem is
 corrected by using the high capacity compiler.

       subroutine test ()
       real tmp(254) ! low cc limit 254
       DATA tmp / 0.0, .035, .049, .049, 0.0, 0.0, .068, .068, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            0.0, .145, .145, 0.0, .200, .200, 0.0, 0.0, 0.0, .281/
       write (*,*) tmp
       end


 528. Optimizing Logical IF Statements with FORTRAN

 Product Version(s): 4.00 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | label run run-time buglist5.00
 Last Modified: 16-JUL-1990    ArticleIdent: Q49731

 FORTRAN may not correctly optimize some logical IF statements inside
 GOTO loops. The result is execution of a different branch of code than
 expected. Try compiling without optimization (/Od).

 If optimization is required, one solution is to change a logical IF
 statement to a standard IF statement. The following is an example:

        if (j .GE. 3) GOTO 3100    ! logical IF statement

 Change to the following:

        if (j .GE. 3) then         ! standard IF statement
          GOTO 3100
        endif

 When the compiler encounters the logical IF and GOTO loop, as shown in
 the code shown below, it compiles and runs without errors, but the
 correct lines are not executed.

 When the code is optimized, the GOTO 3100 statement in the logical IF
 is ignored and the program prints "at 3200, loop failed".

 When the same file is compiled without optimization, the logical if
 statement works correctly and the program prints "at 3100, loop
 worked".

 Sample Code
 -----------

       j=0
 3190  continue
       if (j .ge. 3) Goto 3100       ! The logical IF
       j=j+1
       Goto 3190                     ! The Goto loop
 3200  continue
       write (*,*) 'at 3200, loop failed'
       stop
 3100  continue
       write (*,*) 'at 3100, loop worked'
       stop
       end


 529. Compiler Error in p2symtab.c at Line 939 in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49761

 The following error occurs when a variable is initialized in a type
 statement and then accessed with a COMMON or EQUIVALENCE statement.
 An F2311: 'COMMON or EQUIVALENCE preinitialization illegal' should be
 generated instead.

 The variable should be initialized within the body of the program
 rather than with the type statement if COMMON or EQUIVALENCE is to be
 used.

 fatal error F1001: Internal Compiler Error
               (compiler file '@(#)p2symtab.c:1.4', line 939)
               Contact Microsoft Technical Support

 Remove the /100/ from the following line, and the code compiles
 properly:

       integer*4 i/100/      !preinitialization illegal
       integer*4 j

       common /dow/i
 C     equivalence(i,j)
       i=100            !initialize the variable here instead
       j=3
       end

 The code should generate the following error:

    error F2311: I : COMMON (or EQUIVALENCE or STRUCTURE):
    preinitialization illegal

 Page 135 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 states that the following example causes a compile-time error:

       INTEGER i /1/
       COMMON i

 Page 165 of the same manual includes a similar statement about the
 EQUIVALENCE statement:

       INTEGER i /1/
       EQUIVALENCE (i, j)


 530. Increasing Units Documentation Error in FORTRAN Reference

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49894

 The information on Page 405, Section C.3.1.2, "Increasing Units," in
 the "Microsoft FORTRAN Reference" manual for Version 5.00 incorrectly
 states the following:

    ...so that the number in the line

       _NFILE_ = 20

    equals the same value...

 The correct information should be as follows:

    ...so that the numbers in the lines

          _NFILE_  equ 20
       else
          _NFILE_  equ 40
       endif

    both equal the value...


 531. F6405, End-of-File and the BACKSPACE Command

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 25-FEB-1991    ArticleIdent: Q49896

 The BACKSPACE command may not work correctly if used in conjunction
 with the END parameter in a READ statement. To solve this problem, use
 the EOF intrinsic function.

 One situation that demonstrates this problem is when reading through a
 file with the lines

 50    read(10,20,err=30,end=40) variable
       goto 50

 and you try to BACKSPACE command after encountering the end-of-file
 character. The BACKSPACE command will not work in this situation, and
 F6405 "external I/O illegal beyond end of file" will be generated
 because no BACKSPACING has occurred.

 To work around this problem, use the EOF intrinsic function instead of
 the END parameter. Try reading the file with the following code
 instead:

       do while ( .not. EOF(10))
         read(10,20,err=30) variable
       end do

 Microsoft has confirmed this to be a problem in FORTRAN Version 5.00.
 We are researching this problem and will post new information as it
 becomes available.


 532. The SYSTEM Function Won't Execute SET string=string

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49921

 The SYSTEM function included with the FORTRAN library will not execute
 the DOS command SET string=string. This limitation preserves the
 environment of the calling program, preventing it from being corrupted
 by the SYSTEM call.

 The following code will compile and run, and the line SET CL=/FPi /Lr
 appears on the screen, but the environment is not altered to set CL:

       INTERFACE TO FUNCTION SYSTEM[C] (STRING)
       INTEGER*2 SYSTEM
       CHARACTER*1 STRING[REFERENCE]
       END

       INTEGER*2 SYSTEM
       I=SYSTEM('SET CL=/FPi /Lr'C)
       END


 533. General Differences between /FPi, /FPc, /FPa Compile Options

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50320

 The compile options /FPi, /FPc, and /FPa instruct the FORTRAN compiler
 to generate an executable program in different ways.

 The /FPi option generates in-line instructions for a math coprocessor
 and places the name of the emulator library in the object file. If a
 math coprocessor is present at run time, the program uses the
 coprocessor, If it's not available, it simulates the coprocessor. The
 object file must be linked with the emulator library.

 The /FPc option generates floating-point calls to the emulator library
 and allows linking with either the 8087/287/387, alternate, or
 emulator libraries.

 The /FPa option generates floating-point calls and places
 the name of the alternate library in the object file.

 The above information is found in Chapter 1 of the "Microsoft FORTRAN
 Advanced Topics" manual for FORTRAN 5.0 and Chapter 8 of the FORTRAN
 4.X User's Guide.


 534. Precision of Reals with FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50325

 When using Microsoft FORTRAN, the precision of a REAL*4 variable is
 six or seven decimal places. The precision of a REAL*8 is fifteen or
 sixteen places.

 The "Microsoft FORTRAN Reference" manual for Version 5.00 covers
 single- and double-precision IEEE real data types on Pages 12 and 13.
 (For Versions 4.00, 4.01, and 4.10, please see Pages 22, 23, and 24 of
 the "Microsoft FORTRAN Optimizing Compiler: Language Reference."


 535. Spawnlp and Overlaying the Parent Process

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C S_QuickC
 Last Modified:  7-DEC-1989    ArticleIdent: Q50331

 While the Spawnlp function included with FORTRAN Version 5.00 supports
 the option of suspending the parent process, it does not support the
 option of overlaying (terminating) the parent process. This
 information is documented on Page 87 of the "Microsoft FORTRAN
 Advanced Topics" manual for Version 5.00.

 To overlay the parent process, write a dummy C routine that calls the
 Spawnlp function with the P_OVERLAY parameter. See the C documentation
 for more information about Spawnlp and P_OVERLAY.

 The sample code below illustrates the process that terminates the
 parent so the second message is not printed:

 The following is the FORTRAN parent process:

       INTERFACE TO SUBROUTINE SPC [C]
       END

       WRITE(*,*) 'I AM A PARENT. I AM ALIVE.'
       CALL SPC
       WRITE(*,*) 'PARENT STILL ALIVE'   !not printed
       END

 The following is a dummy C routine (this routine has been successfully
 tested with C 5.10 and QuickC 2.01):

  #include <process.h>
  #include <stdio.h>
  spc()
  {
   spawnlp (P_OVERLAY,"FORM.EXE","FORM.EXE",NULL);
  }

  File FORM.FOR:

       WRITE (*,*) 'HI THERE ! I AM A CHILD PROCESS...'
       END

 The following is the program output:

 I AM A PARENT. I AM ALIVE.HI THERE ! I AM A CHILD PROCESS...

 Make sure that you compile FORTRAN and C routines using the same
 memory model (FORTRAN and C have different defaults). When linking C
 and FORTRAN modules, use the /NOE switch and list the FORTRAN 5.00
 library first.


 536. FORTRAN Reserved File Names

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q50332

 The following is a list of reserved file names in Microsoft FORTRAN.
 This information is from the FORTRAN 5.0 README.DOC.

    Reserved word     Description
    -------------     -----------

    CON               Keyboard and screen
    USER              Keyboard and screen
    PRN               Printer (LPT1)
    COM1              Communications port 1
    LPT1              Printer
    NUL               Null device
    AUX               Communications port (COM1)
    ERR               Standard error output (screen)
    LINE              Communications port (COM1)

 You can use READ, WRITE, and OPEN statements (as appropriate) to
 access these devices, and CLOSE statements to disconnect them, just as
 you would with other files. FORTRAN carriage-control characters are
 recognized for these devices.

 Problems can occur if you use these reserved words incorrectly (e.g.
 if you try to use one as a regular disk filename). For example, if you
 open a file called LINE.DOC, reading from that file can cause your
 computer to lock unless there is an active data transmitting device
 connected to COM1.


 537. Parameter Syntax Not Correctly Interpreted

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49976

 Microsoft FORTRAN Version 5.00 does not correctly interpret the syntax
 of the parameter statement. If the parentheses are left off, either
 the compiler does not generate an error or, if there are any
 statements that follow the parameter statement, the compiler generates
 the error "F2836: statement out of order."

 The compiler does not catch the syntax error in the following program.
 The parameter statement should be "parameter (n=1)":

       integer*2 n
       parameter n=1
       end

 The compiler incorrectly generates the error F2836 when compiling the
 following code, not because the third line is out of order, but
 because of the improper syntax in the parameter statement:

       integer*2 n
       parameter n=1
       integer*2 m
       end


 538. EXEPACK.EXE Not Included with FORTRAN 5.00; Use Link /E

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | exepack
 Last Modified: 31-OCT-1989    ArticleIdent: Q50053

 The EXEPACK Utility is not included with FORTRAN Version 5.00. To pack
 an object file, use the linker /E switch.

 The above information is documented in the FORTRAN 5.0 README.DOC.
 A description of the /E switch is located on page 241 of the FORTRAN
 5.0 CodeView and Utilities User's Guide.


 539. Concatenation with /Gr switch Works Incorrectly

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50573

 When using the /Gr switch to enable FORTRAN code compiled with a
 FORTRAN compiler Version 4.x to be compatible with the code from
 FORTRAN Version 3.20, the character concatenation operator does not
 function correctly with variables.

 When attempting to concatenate two character strings using the
 following format

 j=4
 foo='test'
 foo2=foo(1:j)//'.one'

 the concatenation operation is ignored and foo2 equals 'test' if the
 /Gr switch, which enables backward compatibility to FORTRAN Version
 3.20, is used.

 When an explicit value is used in place of the variable "j", the
 concatenation operation is successful, as shown in the following
 example:

 foo='test'
 foo2='foo(1:4)//'.one'

 In this case, foo2 equals 'test.one'.


 540. FORTRAN Index Listing for Binary Records Incorrect

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q50574

 The index of the "Microsoft FORTRAN Advanced Topics" manual for
 Version 5.00 incorrectly states that information on binary records is
 on Pages 119-120.

 The information actually appears on Pages 122-124.


 541. "Issuing Fixup Warnings" Section Is 13.3.32 in FORTRAN Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | /WARNFIXUP docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q50575

 Under the Link warning message L4000 on Page 386 in the "Microsoft
 FORTRAN CodeView and Utilities User's Guide" for Version 5.00, the
 documentation incorrectly states that Section 13.3.31 is the "Issuing
 Fixup Warnings" section.

 The "Issuing Fixup Warnings" section actually is 13.3.32.


 542. \s Format Switch Information in MS-DOS, Not FORTRAN, Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q50576

 On Page 16 of the "Microsoft FORTRAN Advanced Topics" manual for
 Version 5.00, the first step suggests formatting a blank floppy disk
 without the /s option. It then incorrectly states that more
 information is available on the /s switch in the "Microsoft FORTRAN
 Reference" manual.

 For more information on the /s switch, you should consult an MS-DOS
 manual.


 543. Example of Using EXTERNAL for User-Defined Function

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50401

 The following is an example of how to use the EXTERNAL command in
 FORTRAN Version 5.00 to specify a user-defined function:

       function fn (x)
         real fn,x
         fn=x
       end

       subroutine s2 (f,x,y)
         real   f,x,y
         x=f(y)
       end

 The following is the main program:

       real      y,z,fn
         external  fn
         z=10.0
         call s2(fn,y,z)
         write (*,*) y
       end


 544. Compiling with /ND Option Causes Hang at Run Time

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 19-JUL-1990    ArticleIdent: Q50402

 Compiling the program below with /ND and FORTRAN Version 4.10 generates
 an internal compiler error and using /ND with FORTRAN 5.00 hangs the
 machine at run time.  No errors occur when the WRITE statement is
 removed.

 The /ND switch is used to name the data segment.

 The following code demonstrates both situations when compiled with the
 /ND switch.  No errors occur when the module does not perform I/O
 operations.

       integer*2 n
       n=1
       write (*,*) n
       end

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 545. Using an Internal Write and outtext/outgtext for Numeric Data

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | internal files
 Last Modified:  9-MAY-1990    ArticleIdent: Q61524

 Below is an example of an internal write to a character variable. This
 is useful when outputting numerical data in a graphics mode by using
 the functions outtext or outgtext.

 C Example of an internal write in FORTRAN
 C
       include 'fgraph.fi'
       include 'fgraph.fd'
       integer*4 var1
       character*15 output
       var1 = 1234
       write (output,100) var1 ! write var1 to output variable
       call outtext(output)    ! use outtext to write output to screen
 100   format ('VAR1 = ', I4)
       end

 The above code shows how an internal write can be used to write
 numerical data (formatted or unformatted) to a character string. The
 character string variable name is given as the unitspec for the WRITE
 statement. The formatspec and iolist are used normally. After the
 WRITE statement is executed the character string output contains the
 ASCII characters listed below in single quotation marks:

    output = 'VAR1 = 1234    '

 The graphics functions outtext and outgtext will only output character
 strings to the screen. This poses a problem when outputting integer
 and real values. An internal write will solve the problem.

 Internal files are explained on Pages 77-78 of the "Microsoft FORTRAN
 Reference" manual. Using the WRITE statement with internal files is
 explained on Pages 234-235 of the "Microsoft FORTRAN Reference"
 manual. Outtext and outgtext are explained on Pages 231-232 of the
 "Microsoft FORTRAN Advanced Topics" manual.


 546. Enabling/Disabling FORTRAN SAA, VAX Extensions

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50480

 The /4Ys, /4Yi, and /4Yv compiler switches control the use of
 Microsoft's non-ANSI standard (FORTRAN 77) options:

    Switch     Description
    ------     -----------

    /4Ys       Disables the use of all Microsoft FORTRAN extensions

    /4Yi       Disables all extensions except the IBM SAA extensions

    /4Yv       Disables all but the VAX extensions

 The following contains lists of supported IBM SAA and VAX extensions.
 Most of the information in these lists is located on Pages 330-332 of
 the "Microsoft FORTRAN Reference" manual for Version 5.00. See
 Appendix B in this reference manual for additional features new to
 FORTRAN 5.00.

 Microsoft FORTRAN includes all SAA extensions that are listed below:

  1. 31 character names

  2. Bit manipulation intrinsic

  3. Case insensitive source

  4. COMMON that allows character and noncharacter in same block

  5. CONJG, HFIX, IMAG intrinsic functions

  6. Data initialization in type statements

  7. EQUIVALENCE allows association of character and noncharacter

  8. Functions IOR, IAND, NOT IEOR, ISHFT, BTEST, IBSET, and IBCLR

  9. IMPLICIT NONE

 10. INCLUDE compiler directive

 11. INTEGER*2, COMPLEX*16, and LOGICAL*1 data types

 12. Optional length specifications in INTEGER, REAL, COMPLEX, and
     LOGICAL type statements

 13. Use of underscore (_) in names

 14. Z edit descriptor

 Microsoft FORTRAN also includes many, but not all, VAX extension as
 listed below:

  1. 31 character names

  2. ACCESS selector 'APPEND' in the OPEN statement

  3. Allowing integer arrays to contain FORMAT statements

  4. BLOCKSIZE and NML I/O keywords

  5. Debug comment lines

  6. DO statements without specified labels

  7. DO WHILE statement

  8. END DO statement

  9. EQUIVALENCE of character and noncharacter items

 10. EQUIVALENCE to a multi-dimensional array with only one subscript

 11. Exponentiation of REAL and COMPLEX statements

 12. IMPLICIT NONE

 13. INCLUDE compiler directive

 14. Initialization on the declaration line

 15. In-line comments

 16. Length specification within the FUNCTION statement

 17. Length specifications within type declarations

 18. Mixing of character and noncharacter items in COMMON statements

 19. NAMELIST

 20. Noninteger alternate return values

 21. Noninteger array subscripts

 22. Numeric operands for .AND., .OR., etc.

 23. Specified common-block variables in DATA statements outside a
     BLOCK DATA subroutine

 24. STRUCTURE, UNION, MAP statements

 25. Up to 99 continuation lines

 26. Use of dollar sign ($) in names

 27. .XOR. operator


 547. VAX Extensions Available with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50504

 Microsoft FORTRAN includes many, but not all, VAX extensions. Most of
 these extensions are found on Pages  331-332 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00. Appendix B of the same manual
 lists additional features that are new in FORTRAN 5.00.

 The supported VAX extensions are listed below:

  1. 31 character names

  2. ACCESS selector 'APPEND' in the OPEN statement

  3. Allowing integer arrays to contain FORMAT statements

  4. BLOCKSIZE and NML I/O keywords

  5. Debug comment lines

  6. DO statements without specified labels

  7. DO WHILE statement

  8. END DO statement

  9. EQUIVALENCE of character and noncharacter items

 10. EQUIVALENCE to a multi-dimensional array with only one subscript

 11. Exponentiation of REAL and COMPLEX statements

 12. IMPLICIT NONE

 13. INCLUDE compiler directive

 14. Initialization on the declaration line

 15. In-line comments

 16. Length specification within the FUNCTION statement

 17. Length specifications within type declarations

 18. Mixing of character and noncharacter items in COMMON statements

 19. NAMELIST

 20. Noninteger alternate return values

 21. Noninteger array subscripts

 22. Numeric operands for .AND., .OR., etc.

 23. Specified common-block variables in DATA statements outside a BLOCK
     DATA subroutine

 24. STRUCTURE, UNION, MAP statements

 25. Up to 99 continuation lines

 26. Use of dollar sign ($) in names

 27. .XOR. operator


 548. IBM SAA Extensions Available with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50505

 Microsoft FORTRAN 5.00 includes all IBM SAA extensions. These
 extensions are listed below (this list can also be found on Pages
 330-331 of the "Microsoft FORTRAN Reference" manual for Version 5.00):

  1. 31 character names

  2. Bit manipulation intrinsic

  3. Case insensitive source

  4. COMMON allows character and noncharacter in same block

  5. CONJG, HFIX, IMAG intrinsic functions

  6. Data initialization in type statements

  7. EQUIVALENCE allows association of character and noncharacter

  8. Functions IOR, IAND, NOT IEOR, ISHFT, BTEST, IBSET, and IBCLR

  9. IMPLICIT NONE

 10. INCLUDE compiler directive

 11. INTEGER*2, COMPLEX*16, and LOGICAL*1 data types

 12. Optional length specifications in INTEGER, REAL, COMPLEX, and
     LOGICAL type statements

 13. Use of underscore (_) in names

 14. Z edit descriptor


 549. FORTRAN Err Msg: Cannot Open Module Definitions Field

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | def file
 Last Modified:  7-DEC-1989    ArticleIdent: Q50583

 The L1092 'cannot open module-definitions file' link error occurs if
 some input is inadvertently given on the Definitions File prompt
 during linking, or if a response file inadvertently feeds input to the
 Definitions File prompt.

 The Definitions File field in the linker prompt should be used only
 when working with DLL's under OS/2. If the program is to be run under
 DOS, this field should be left blank.

 A semicolon at this prompt is treated as a null input.

 Section 13.2.2 of the "Microsoft FORTRAN CodeView and Utilities User's
 Guide" for Version 5.00 contains more information about linking with
 the LINK Command Line.


 550. FORTRAN Err Msg: "L1093 Object Not Found", Wrong Environment

 Product Version(s): 4.00 4.01 4.10 | 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50585

 The L1093 error "object not found" can occur if the environment is
 incorrectly set. For example, the L1093 error occurs if the fl
 environment variable is specified as follows:

 set fl=options

 or

 set fl=\FPi \Zi

 In the first case, the linker thinks it needs to link in an
 OPTIONS.OBJ file. In the second case, backslashes were used for the
 command switches instead of forward slashes. In the second case, the
 linker also thinks it needs to link in the \FPi.obj and \Zi.obj files.


 551. Compilation Errors with FORTRAN 5.00, $FREEFORM, Graphics

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  8-DEC-1989    ArticleIdent: Q50595

 If the $FREEFORM metacommand is placed at the top of a FORTRAN Version
 5.00 file that makes calls to the FORTRAN graphics library, you get
 compilation errors. The files FGRAPH.FI and FGRAPH.FD are not written
 to conform to the $FREEFORM format.

 If you must use the $FREEFORM metacommand, you must modify these two
 files. We recommend that you create customized include files that
 contain only the information that pertains to the graphics routines
 you are calling.

 The following is an example of a subroutine that uses the $FREEFORM
 metacommand and calls a subroutine in the FORTRAN graphics library:

 $FREEFORM
 include 'OHMAN.FI'
 subroutine foo()
 include 'OHMAN.FD'
 call setlinestyle(#AA3C)
 end

 For this particular example, the file OHMAN.FI contains information
 from the file FGRAPH.FI that pertains to the subroutine setlinestyle.
 This file, OHMAN.FI, looks like the following:

 INTERFACE TO SUBROUTINE setlinestyle[FAR,C,ALIAS:"__setlinestyle"] (mask)
 INTEGER*2 mask
 END

 Likewise, the file OHMAN.FD contains information from the file
 FGRAPH.FD that pertains to the subroutine setlinestyle. It looks like
 the following:

       EXTERNAL setlinestyle


 552. OS/2 Graphic Routines Available with FORTRAN 5.00 GRTEXTP.LIB

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | Advanced Topics Manual Page 148
 Last Modified:  7-DEC-1989    ArticleIdent: Q50600

 The OS/2 graphics library GRTEXTP.LIB supports the following routines:

    clearscreen         getvisualpage       settextwindow
    displaycursor       outtext             setvideomode
    getactivepage       setactivepage       setvideomoderows
    getbkcolor          setbkcolor          setvisualpage
    gettextcolor        settextcolor        wrapon
    gettextcursor       settextcursor
    gettextposition     settextposition
    getvideoconfig      settextrows

 This library must be linked instead of GRAPHICS.LIB to use these
 routines under OS/2. Routines not included in the above list are not
 available under OS/2.

 The OS/2 Presentation Manager can be programmed to use additional
 graphics routines under OS/2.


 553. Need INTERFACE Statement to Pass Address of Common Block to C

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q51245

 Section 5.3.5.1 on Page 111 of "Microsoft FORTRAN Advanced Topics"
 manual for Version 5.00 shows a code fraction, which demonstrates
 passing of the address of a FORTRAN Common Block to C. However, the
 requirement that you must also write an INTERFACE statement to the C
 subroutine to successfully pass the address is omitted in the manual.

 For the example on Page 111, either one of the following INTERFACE
 statements works correctly:

            INTERFACE TO SUBROUTINE INITCB [C] (N)
            INTEGER*2 N [REFERENCE]
            END

 or

            INTERFACE TO SUBROUTINE INITCB [ALIAS:_initcb]
            INTEGER*2 N
            END

 In the first INTERFACE statement, the REFERENCE attribute must be
 included because C attribute otherwise causes parameter N to be passed
 by value.


 554. FORTRAN Err Msg: Filename.for(9): Error F2725 Illegal Input...

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q51284

 The code below produces the following error on the READ line:

    filename.for(9) : error F2725 illegal input list item

 According to Page 218 of the "Microsoft FORTRAN Reference" for Version
 5.00, declaration of an array of records is allowed. Page 214 states
 that the iolist may contain structure elements. If LIMIT is changed to
 a single structure instead of an array of structures, the code
 compiles correctly.

 Microsoft has confirmed this to be a problem in Version 5.00 of the
 compiler and will post new information as it becomes available.

 Code Example
 ------------

       structure /speclimit/
       real*4  a
       end structure

       record /speclimit /limit(5)
       n=1
       limit(N).a=34.56
       read (*,1000) limit(N).a    !array causes error
 1000  format (f6.2)
       end


 555. Monitoring the Stack Using Assembly or C

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | debug watch view
 Last Modified:  7-DEC-1989    ArticleIdent: Q51294

 If, for any reason, you believe that the stack in a FORTRAN program is
 being corrupted, you can monitor the stack segment (SS) register and
 stack pointer (SP) register by using either the Microsoft Assembler or
 the QuickC with Assembler package. Since CodeView may use the stack
 for its own purposes, this allows a more direct monitoring method.

 A function for each package is shown below along with the appropriate
 interface statement. Each function returns an integer*4 to FORTRAN.

 To extract the hexadecimal values from that integer, use a format
 statement something similar to the following example:

       write (*,'(1x,A7,1x,4Z,A1,4Z)')
      + 'seg:off',stackloc(),':',ISHC(stackloc(),16)

 This write statement produces video output of the following form:

  seg:off 2BC0:111A

 The assembly code and interface statement are shown below.

       interface to integer*4 function stackloc()
       end
       integer*4 stackloc

 .model large
 .code
 public stackloc
 stackloc proc
        mov dx,ss
        mov ax,sp
        ret
 stackloc endp
        end

 The equivalent interface for the following QuickC with Assembler code
 is also listed below (keep in mind that this code must be compiled
 with the /AL switch for memory model compatibility):

       interface to integer*4 function stackloc [C,
      + alias:'_stackloc'] ()
       end
       integer*4 stackloc

 int * stackloc(void)
 {
         int j[2];

         _asm {
                 mov     j[0],ss
                 mov     j[1],sp
         }
         return j;
 }


 556. FORTRAN Err Msg: F4998: Variable Used But Not Defined

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q51295

 The FORTRAN Version 5.00 compiler will produce the following error
 when the variable is defined yet not used anywhere in the program
 other than in an intrinsic function:

    F4998: variable used but not defined

 To eliminate this warning, use the variable somewhere in the program
 other than just in the intrinsic function.

 The following program generates this warning error.

       integer tmp
       write (*,*) locfar(tmp)

 To eliminate this warning, set tmp equal to something before it is
 used in the program.

       integer tmp
       tmp=1
       write (*,*) locfar(tmp)

 The following is the current list of tested intrinsic functions that
 generate this error, although many more intrinsic functions are
 believed to generate this warning:

    locfar, loc, locnear, not, ior, sin, tan, exp, log, sqrt, max, mod,
    abs

 Microsoft is researching this problem and will post new information as
 it becomes available.


 557. String Replacement Macro for M Editor

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q51296

 The following example illustrates a macro that can be placed within
 the TOOLS.INI file to enable the replacement of a string(string1) with
 another string(string2). The macro is assigned to a function key (F5).

 The search and replace is conducted from the position of the cursor
 down through the end of the file.

 Macro
 -----

      MacRep:=Replace "string1" newline "string2" newline
      MacRep:F5


 558. FORPATCH Available in Software/Data Library

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | softlib FORPATCH.ARC
 Last Modified:  7-DEC-1989    ArticleIdent: Q51298

 There is a file in the Software/Data Library called FORPATCH that
 consists of a README file and a patched version of the first pass of
 the FORTRAN Version 5.00 compiler (F1.EXE) and a patched,
 high-capacity compiler (F1L.EXE).

 This update corrects the following problems:

 1. The I/O of the STRUCTURE element generates an F1001 Internal
    Compiler Error in omf_ms.c:1.118, line 1093, or a protection
    violation.

 2. NAMELIST statements in multiple subprograms in one file cause the
    machine to hang.

 3. SAVEing a common block in multiple subprograms causes a compiler
    error F2348: already declared SAVE.

 4. Using /4Yi, /4Ys, or /4Yv, and an asterisk in column one to
    indicate a comment generates a compiler error F2037: illegal label
    field.

 This file can be found in the Software/Data Library by searching on
 the keyword FORPATCH, the Q number of this article, or S12450.
 FORPATCH was archived using the PKware file-compression utility.

 This patch, called "FORTRAN 5.0 F1.EXE and F1L.EXE Patch," is also
 available from Microsoft Product Support Services at [phone].


 559. F1001 Error 'getattrib.c:1.4' line 174, Using LOC Functions

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 31-AUG-1990    ArticleIdent: Q65261

 The following error

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)getattrib.c:1.4', line 174)

 occurs when using the LOC, LOCNEAR, or LOCFAR intrinsic function with
 a Structure-Type as an argument. This should produce a compiler error
 because Structure-Types are used to define new data types and are not
 variables. Structure Variables are defined by a RECORD statement, and
 are legal arguments to a LOC function.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following sample code generates an internal compiler error:

       STRUCTURE /smallst/
         CHARACTER*1 letter
       END STRUCTURE

       i = LOC(smallst)
       END

 The correct use of the LOC function is as follows:

       STRUCTURE /smallst/
         CHARACTER*1 letter
       END STRUCTURE
       RECORD /smallst/ alphabet

       i = LOC(alphabet)
       END


 560. Data Type Conversion Utilities in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q51471

 This article lists FORTRAN 5.00 data type conversion utilities. It
 includes information on the following:

 1. Intrinsic functions dealing with data type conversions, documented
    on Pages 240-241 of the "Microsoft FORTRAN Reference" manual for
    Version 5.00

 2. The $STORAGE metacommand, documented on Pages 34 and 308 of the
    "Microsoft FORTRAN Reference" manual for Version 5.00

 3. The IMPLICIT statement, documented on Pages 8 and 181-182 of the
    "Microsoft FORTRAN Reference" manual for Version 5.00

 4. Internal READ and WRITE, documented on Pages 77-78 of the
    "Microsoft FORTRAN Reference" manual for Version 5.00

 1. Intrinsic Functions
    -------------------

       Function   Description
       --------   -----------

       INT        Converts integer, real or complex arguments to
                  integers

       INT1       Converts integer, real or complex arguments to
                  INTEGER*1

       INT2       Converts integer, real or complex arguments to
                  INTEGER*2

       INT4       Converts integer, real or complex arguments to
                  INTEGER*4

       INTC       Converts integer, real or complex arguments to
                  C language integers

       IFIX       Converts REAL*4 arguments to integers

       HFIX       Converts integer, real or complex arguments to
                  INTEGER*2

       JFIX       Converts integer, real or complex arguments to
                  INTEGER*4

       IDINT      Converts DOUBLE PRECISION or REAL*8 arguments to
                  integers

       REAL       Converts integer, real or complex arguments to
                  REAL*4

       DREAL      Converts COMPLEX*16 arguments to REAL*8

       FLOAT      Converts integer arguments to REAL*4

       SNGL       Converts REAL*8 arguments to REAL*4

       DBLE       Converts integer, real or complex arguments to
                  DOUBLE PRECISION

       DFLOAT     Converts integer, real or complex arguments to
                  DOUBLE PRECISION

       CMPLX      Converts integer, real or complex arguments to
                  COMPLEX*8

       DCMPLX     Converts integer, real or complex arguments to
                  COMPLEX*16

       ICHAR      Converts character arguments to integers (ASCII
                  value)

       CHAR       Converts integer arguments to characters (ASCII
                  equivalent)

       The documentation on the data type conversion intrinsic
       functions can be found on Pages 240-241 in the "Microsoft
       FORTRAN Reference" manual for Version 5.00.

 2. $STORAGE Metacommand
    --------------------

    $STORAGE:n allocates n bytes of memory for all variables declared
    as INTEGER or LOGICAL. For example, if INTEGER B variable
    declaration is used and the $STORAGE:2 metacommand is specified, B
    will be allocated 2 bytes instead of 4. $STORAGE does not affect
    the allocation of memory for variables declared with an explicit
    length specification, such as INTEGER*2 or INTEGER*4. The $STORAGE
    metacommand is documented on Pages 34 and 308 of the "Microsoft
    FORTRAN Reference" manual for Version 5.00.

 3. IMPLICIT Statement
    ------------------

    If a name is not explicitly defined, the first letter of a variable
    or function determines its type. By default, names starting with I,
    J, K, L, M, or N are given the type INTEGER, while variables
    starting with any other letter or a dollar sign are given the type
    REAL. An IMPLICIT statement can be used to override the default. An
    explicit type declaration overrides the type established by the
    IMPLICIT statement. The IMPLICIT statement is documented on Pages
    8 and 181-182 of the "Microsoft FORTRAN Reference" manual for
    Version 5.00.

 4. Internal READ and WRITE
    -----------------------

    Reading from an internal file converts the ASCII values into
    numeric, logical, or character values, and writing to an internal
    file converts values into their ASCII representations. Internal
    READ and WRITE are documented on Pages 77-78 of the "Microsoft
    FORTRAN Reference" manual for Version 5.00. The following code
    sample converts a character variable into an integer:

       character*5 num
       integer test
       num='12345'
       read(num,'(i5)') test
       write (*,*) test
       end


 561. Incorrect INTEGER Size Listed in Reference Manual, Page 191

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q51492

 The last line on Page 191 of the "Microsoft FORTRAN Reference" manual
 for Version 5.00 incorrectly reads as follows:

        INTEGER*22 q, m12*24, ivec(10)*24, z*24(10)

 Four extraneous 2s should be removed from the line as follows:

        INTEGER*2 q, m12*4, ivec(10)*4, z*4(10)


 562. Including BSE.FD Twice Causes Protection Violation

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  7-DEC-1989    ArticleIdent: Q51494

 The FORTRAN Version 5.00 compiler causes a protection violation, after
 a number of other errors, when the following code is compiled. It
 seems to have problems with the include files. If the files were
 entered properly, there would be both an "fi" and an "fd" include
 file. BSE.FD is included on the FORTRAN 5.00 OS/2 Support Disk 2.

 Example
 -------

 C **************************
       include 'bse.fd'
       include 'bse.fd'
       x = dosbeep(200,200)
       write (*,*) x
       stop
       end


 563. Use of ICHAR and CHAR Intrinsic Functions

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | type conversion
 Last Modified:  7-DEC-1989    ArticleIdent: Q51495

 The ICHAR intrinsic function converts a single character to the
 integer ASCII value of that character.

 The CHAR intrinsic function converts an integer to the corresponding
 ASCII character.

 In both cases, ICHAR and CHAR use decimal integer values and the
 Extended ASCII Character Set.

 The ICHAR function will not directly convert a number that is stored
 as a character to the same number stored as an integer.

 The integer in both cases must be between 0 and 255. A number larger
 than 255 will "wrap around" to a value between 0 and 255, e.g. 256
 would be interpreted as 0, 257 as 1, 511 as 255, etc.

 The character string in both cases must be a single character
 (CHARACTER*1). If the character string is longer than one (CHARACTER*2
 or more), the functions will recognize only the first character
 position and ignore the rest.

 Example of ICHAR and CHAR
 -------------------------

       PROGRAM example

       INTEGER*2   int1, int2
       CHARACTER*1 char1, char2

       char1 = 'A'
       int1  = ICHAR(char1)

       int2  = 90
       char2 = CHAR(int2)

       write(*,*) 'char1 = ',char1,' and int1 = ',int1
       write(*,*) 'char2 = ',char2,' and int2 = ',int2

       end

 The output of program example is as follows:

    char1 = A and int1 =          65
    char2 = Z and int2 =          90

 The values 65 and 90 are the corresponding ASCII decimal values for
 the capital characters A and Z, respectively.

 The ICHAR and CHAR intrinsic functions are described on Pages 240-241
 of the "Microsoft FORTRAN Reference" manual for Version 5.00 and on
 Pages 323 and 325 of the "Microsoft FORTRAN 4.1 Optimizing Compiler:
 Language Reference."


 564. Example of Using a BLOCK DATA Subprogram

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q51496

 A BLOCK DATA subprogram must come at the beginning of a main program
 file prior to the PROGRAM statement or at the end of the file after
 the END statement closing the main program.

 The variables initialized by the BLOCK DATA subprogram must be typed
 within the subprogram. The BLOCK DATA examples on Page 124 in the
 "Microsoft FORTRAN Reference" manual for Version 5.00 are incorrect
 because they do not type the variables prior to initialization.

 Below is an example of a program that uses BLOCK DATA.

 The following program shows how a BLOCK DATA subprogram can be used to
 initialize variables grouped within a named common block:

 C ******** BLOCK DATA statement at beginning of file ***

       BLOCK DATA foo
         integer*2   int1
         real*4      real1
         character*2 char1
         logical     log1
         common /test/ int1, real1, char1, log1
         data int1, real1, char1, log1 /1,4.0,'ZZ',.true./
       END

 C ******** Beginning of main program *******************

       PROGRAM block

       integer*2   int1
       real*4      real1
       character*2 char1
       logical     log1

       common /test/ int1, real1, char1, log1

       write (*,100) int1, real1, char1, log1
 100   format (1X, I1, 3X, F3.1, 3X, A2, 3X, L1)

       end

 The output of the program BLOCK is as follows:

    1   4.0   ZZ   T

 In the above program example, the BLOCK DATA subprogram could have
 been placed AFTER the END statement of the main program, producing the
 same results.


 565. Fatal Error F1001: compiler file'@(#)ctypes.c:1.11', line 448

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  7-DEC-1989    ArticleIdent: Q51507

 The following example using double parentheses causes an internal
 compiler error. To work around the problem, remove the double
 parentheses.

 If the /Fs switch is used on the FORTRAN command line, a protection
 violation is generated under OS/2, or a system lockup occurs under
 DOS.

 Example
 -------

       program papa
       character*10 a
       a='1234567890'
       call mama((a(4:8)))  ! Remove the outer parenthesis
       stop
       end

       subroutine mama(b)
       character*5 b
       write (*,*) b
       return
       end

 The errors generated are similar to the following (this file was named
 subroti.for):

    subroti.for(5) : fatal error F1001: Internal Compiler Error
              (compiler file '@(#)ctypes.c:1.11', line 448)
              Contact Microsoft Technical Support


 566. Creating a Pointer in FORTRAN

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q51607

 The two sample programs below demonstrate a way to simulate pointers
 in FORTRAN. The first is for DOS and the second is for OS/2.

 Example 1
 ---------

 c This program demonstrates the use of a pointer in FORTRAN
 c 5.00 in DOS. This program loads a far address into an
 c integer*4 and passes that to a subroutine.
 c
 c Next, an INTERFACE TO SUBROUTINE is used to "lie" to FORTRAN
 c about what is being passed. The interface tells FORTRAN
 c that it is passing an integer*4 by value. The actual
 c subroutine, which is referred to by the ALIAS attribute,
 c expects a far address to an array. The value of the
 c integer*4 is that address. Once inside that subroutine,
 c The entire segment can be accessed by specifying the
 c correct index to the array.
 c
 c The subroutine SETPOINT2 changes the screen attribute byte
 c to cause the characters on the video display to blink.

          interface to subroutine setpoint[alias:'setpoint2'] (abc)
            integer*4   abc  [value]
          end

          subroutine setpoint2 (abc)
             integer*2   abc(*),n

             do 100,n=1,2000
             abc(n)=ior(abc(n),#8000)
 100         continue
          end

          program graphtest
             integer*4      ptr

             ptr=#0b8000000
             write (*,'(z9)') ptr
             call setpoint (ptr)
          end

 Example 2
 ---------

 c This program demonstrates the use of a pointer in FORTRAN
 c 5.00 in OS/2. This particular program gets a selector to
 c the video buffer from the DOS function call VioGetPhysBuf().
 c Once the selector is acquired, it is converted to a far
 c pointer by shifting it 16 positions to the left.
 c
 c Next, an interface to subroutine is used to lie to FORTRAN
 c about what it is passing. The interface tells FORTRAN that
 c it is passing an integer*4 by value. The actual
 c subroutine, which is referred to by the ALIAS attribute,
 c expects a far address to an array. The value of the
 c integer*4 is that address. Once inside that subroutine,
 c The entire segment can be accessed by specifying the
 c correct index to the array.
 c
 c The subroutine SETPOINT2 changes the attribute byte to
 c cause the characters on the video display to blink.

          interface to function viogetphysbuf (buffer,handle)
              structure/buffstrc/
                integer*4  address
                integer*4  length
                integer*2  selector
              end structure
              record/buffstrc/buffer
              integer*2    handle   [value]
              integer*2    viogetphysbuf
          end

          interface to subroutine setpoint[alias:'setpoint2'] (abc)
            integer*4   abc  [value]
          end

          subroutine setpoint2 (abc)
             integer*2   abc(*),n

             do 100,n=1,2000
             abc(n)=ior(abc(n),#8000)
 100         continue

          end

          program graphtest

             structure/buffstrc/
                integer*4  address
                integer*4  length
                integer*2  selector
             end structure
             record/buffstrc/buffer

             integer*2      error,viogetphysbuf
             integer*4      ptr

             buffer.address = #0b8000
             buffer.length  = 4000

             error=viogetphysbuf (buffer,0)

             ptr=isha(buffer.selector,16)
             write (*,'(z10,i3)') ptr,error
             call setpoint (ptr)
          end


 567. Entry Point and F1001 in omf_ms.c, Line 1093

 Product Version(s): 4.10   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q51608

 Microsoft FORTRAN Versions 4.10 and 5.00 may produce the following
 fatal error under DOS or a protection violation under OS/2 if an
 executable statement contains a variable that is later used as a
 formal parameter in an ENTRY statement:

    F1001 : Internal Compiler Error
    (compiler file '@(#)omf_ms.c:1.118',line 1093)

 This programming practice is not allowed in FORTRAN. The
 fourth paragraph on Page 163 of the "Microsoft FORTRAN Reference"
 manual for Version 5.00 states the following:

    A formal argument cannot appear in an executable statement that
    occurs before the ENTRY statement containing the formal argument
    unless the formal argument also appears in a FUNCTION, SUBROUTINE,
    or ENTRY statement that precedes the executable statement.

 The next to last paragraph on Page 208 of the "Microsoft FORTRAN 4.1
 Optimizing Compiler: Language Reference" manual contains similar
 information.

 The following code produces the above mentioned error:

       a = 100.0
       call setpt (a)
       call frstc
       stop
       end

       subroutine frstc
       write(*,*) b     !b in an executable statement
       return
       entry setpt (b)  !b as formal parameter (for first time)
       return
       end

 If "b" is declared as a formal parameter for subroutine frstc, the
 program compiles with no errors.


 568. Mixed-Language Example: Accessing FORTRAN Common from C

 Product Version(s): 5.00    | 5.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | S_C S_QUICKC
 Last Modified:  2-MAR-1990    ArticleIdent: Q51614

 The following example demonstrates how to access a FORTRAN common
 block from a C function. The common block is declared in FORTRAN as a
 common block and in C as an external structure with a FORTRAN
 attribute. The common block can be referenced from both languages with
 these embedded language constructs. This program must be compiled for
 medium or large model. For more information on common blocks, see Page
 110 in the "Microsoft FORTRAN Advanced Topics" manual for FORTRAN
 5.00, or Page 132 in the mixed-language programming guide that is
 included with C 5.10, Pascal 4.00, and MASM 5.10.

 ------------------------COMMON.FOR-----------------------------
 C FORTRAN calling C, program used to show how to utilize common
 C blocks in a mixed-language application. This is the FORTRAN
 C main module that will declare the common block and call the C
 C procedure to modify the contents. After, it will display the
 C new common block values.
 C
 C The following shared common block is called "cblock".

       integer*4 I
       real R
       character*1 Ch
       common/cblock/ I,R,Ch
 C
 C The following FORTRAN code will display the contents of "cblock"
 C before and after the call to the C function.
 C
       I=10
       R=2.0
       Ch='d'
       Write(*,10) I,R,Ch
       call cproc
       Write(*,10) I,R,Ch
  10   format(1x,I3,1x,F7.2,1x,A)
       end
 ------------------------CBLOCK.C-------------------------------
 /*
   The C code declares a structure to look like a FORTRAN common
   block. This structure is declared extern with the FORTRAN
   attribute. Any common block can be declared the same way. The
   C function "cproc" simply assigns values to the elements in the
   common block (C structure).
  */

 struct mystruct { long i;
                   float f;
                   char c; };

 extern struct mystruct  cblock;

 void fortran cproc(void)
 {
   cblock.i = 100;
   cblock.f = 100.00;
   cblock.c = 'A';
 }
 ------------------------COMMON.MAK----------------------------
 # This make file will build the executable program COMMON.EXE.
 # The program is compiled for large or medium memory model and it
 # will include CodeView information. It is linked with no default
 # libraries and no extended dictionary search. This MAKE file can
 # be executed by typing:
 #
 #        MAKE common.mak
 # or
 #        NMAKE -f common.mak

 MODEL=L

 # The following line can be deleted if using MAKE.
 ALL : common.exe

 common.obj : common.for
   fl /Zi /A$(MODEL) /c $**

 cblock.obj : cblock.c
   cl /Zi /A$(MODEL) /c $**

 common.exe : common.obj cblock.obj
   link $** /nod /noe,,,$(MODEL)libfer.lib $(MODEL)libcer.lib;


 569. MODE='WRITE' Does Not Work with ACCESS='APPEND'

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q51749

 ACCESS='APPEND' does not work correctly if MODE='WRITE' is also
 included as one of the options in an OPEN statement. Under MS-DOS,
 instead of appending to a file, the file to be appended to is either
 partly or completely overwritten. Under OS/2, the following run-time
 error may be incorrectly generated:

    F6421:WRITE(test.dat) - file read-only or locked against writing

 Code Sample #1 -- Create TEST.DAT File
 --------------------------------------

 The following code creates a file TEST.DAT:

            integer a,b,c
            open (12,file='test.dat',status='new',mode='write')
            a = 10
            b = 20
            c = 30
            write (12,*) a,b,c
            end

 Code Sample #2 -- Append to TEST.DAT Fails
 ------------------------------------------

 The following code is supposed to append to TEST.DAT. However, the
 file is overwritten under MS-DOS, and the following run-time error is
 generated under OS/2:

    F6421:WRITE(test.dat) - file read-only or locked against writing

         integer a,b,c
         open (11,file= 'test.dat',access='append',
      +       mode='write')
         a = 1
         b = 2
         c = 3
         write (11,*) a,b,c
         end

 Code Sample #3 -- Append Works If MODE='WRITE' Is Removed
 ---------------------------------------------------------

 When MODE='WRITE' is removed, TEST.DAT is appended to properly, i.e.,
 the following code runs correctly:

         integer a,b,c
         open (11,file = 'test.dat',access='append')
         a = 1
         b = 2
         c = 3
         write (11,*) a,b,c
         end


 570. Dollar Sign in FORMAT Statement Equivalent to Backslash

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr undocumented VAX extension
 Last Modified:  2-MAR-1990    ArticleIdent: Q51750

 A dollar sign ($) can be used in a FORMAT statement to suppress the
 carriage-control character. It functions the same as the backslash
 edit descriptor (\). It is used for formatted I/O to terminal devices,
 such as the screen or a printer. It is ignored in all other
 situations.

 Backslash editing is described on Page 84 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00.


 571. PC Kwik RAM Disk May Cause Internal Compiler Errors

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | F1001
 Last Modified:  2-MAR-1990    ArticleIdent: Q57303

 The PC Kwik RAM disk software shipped with the Dell System Enhancement
 package for DOS Version 4.00 may cause spurious internal compiler
 errors when compiling with the Microsoft FORTRAN Compiler Version
 5.00.

 This problem was reported by a customer whose TMP environment variable
 pointed to the RAM disk.  Pointing the TMP variable to the hard disk
 corrected the problem.


 572. Statement Function Changes from FORTRAN 3.x to 4.x and 5.00

 Product Version(s): 3.x 4.00 4.01 5.00 | 4.10 5.00
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER | softlib STATFUNC.ARC
 Last Modified:  2-MAR-1990    ArticleIdent: Q57551

 The statement function defines a function in a single statement.

 There was a change in the internal operation of the statement function
 between Versions 3.x of FORTRAN and Versions 4.x and 5.00.

 In Versions 3.x, the code for the function generated by the statement
 function is generated once, and each use of the function generates a
 call to that code.

 In Versions 4.x and later, the code is inserted each time the function
 is called. This will increase code size, but cause faster operation.

 There is a file in the Software Library named STATFUNC that shows
 examples of the statement function in FORTRAN for Versions 3.31 and
 5.00. STATFUNC can be found in the Software/Data Library by searching
 on the keyword STATFUNC, the Q number of this article, or S21507.
 STATFUNC was archived using the PKware file-compression utility.


 573. MOVETO_W INTERFACE Statement Documentation Error

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr moveto graphics
 Last Modified:  2-MAR-1990    ArticleIdent: Q57570

 There is a documentation error on Page 230 of the "Microsoft FORTRAN
 Advanced Topics" manual for Version 5.00.

 The INTERFACE statement to subroutine MOVETO_W specifies that the
 first two parameters passed to subroutine MOVETO_W should be of type
 INTEGER*2. This is incorrect, they should be of type DOUBLE PRECISION.

 The INTERFACE statement in the include file FGRAPH.FI is correct.

 The correct INTERFACE statement reads as follows:

        INTERFACE TO SUBROUTINE
       +moveto_w[FAR,C,ALIAS:"__f_moveto_w"](wx,wy,s)
        DOUBLE PRECISION wx,wy     !manual incorrect here
        STRUCTURE/wxycoord/
         DOUBLE PRECISION wx
         DOUBLE PRECISION wy
        END STRUCTURE
        RECORD/wxycoord/s[FAR,REFERENCE]
        END


 574. Passing Variables with the SYSTEM Call

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q57571

 The C function, SYSTEM, is available within the FORTRAN Run Time
 Library. It is possible to pass a variable argument within that
 function call. The variable can also be a concatenated variable. Below
 is an example demonstrating this feature.

 Note: SYSTEM is a C function within the FORTRAN Library. Any
 limitation or characteristics that are encountered are those of the C
 convention and not of FORTRAN (for example, null terminated strings).

 c...This program will demonstrate the use of a concatenated
 c...variable argument for the SYSTEM function call. It has
 c...the same effect as typing DIR *.FOR at the DOS prompt.

 c..Interface statement

       interface to integer*2 function system[c]
      +(string[reference])
       character*1 string
       end

 c..Variable set up and function call

       integer*2 system
       character*4 foo
       character*5 bar
       character*9 all
       foo='dir'
       bar='*.for'c   ! c treats this as a null terminated C string
       all=foo//bar   ! Concatenate the string as 'dir *.for'
       i=system(all)  ! Pass a variable to SYSTEM
       end


 575. Formatted I/O, Carriage Control Characters, and LPT2

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q57572

 The section on "Carriage Control" on Page 78 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00 states the following:

    When formatted I/O is used to transfer a record to a terminal
    device, such as screen or printer, the first character of that
    record is interpreted as a carriage control character, and is not
    printed.

 This is not true for printers connected to LPT2. Thus, the carriage
 control characters listed on Page 79 of the FORTRAN 5.00 reference
 manual will not be interpreted properly for the printers connected to
 LPT2.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information as it becomes
 available.

 The following program is supposed to form feed and then print "5
 years". However, it does not form feed and it prints "15 years":

       open (10, file='LPT2', status='OLD')
       write(10,200)
 200   format ('15 years')
       end

 To work around this problem, either change 'LPT2' to 'LPT1' in the
 OPEN statement and connect the printer to LPT1, or use the CHAR
 function to send the carriage control characters to the printer on
 LPT2. The following code sample demonstrates the second workaround:

       open (10, file='LPT2', status='OLD')
       write(10,200) char(12)   ! Form Feed - ASCII 12
 200   format (a1,'5 years')
       end


 576. VAX/VMS FORTRAN Language Features NOT Supported in 4.10/5.00

 Product Version(s): 4.10 5.00      | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | extension
 Last Modified:  2-MAR-1990    ArticleIdent: Q57592

 Below is a list of VAX/VMS FORTRAN 77 language features that Microsoft
 FORTRAN Version 4.10 does not support. Some features that require
 VAX-specific architecture support (such as keyed access files) are not
 listed.

 Those features implemented in Microsoft FORTRAN Version 5.00 are
 preceded by an asterisk (*).

    *  IMPLICIT NONE
       Many intrinsic function names (but no new functionality)
    *  NAMELIST
    *  INCLUDE STATEMENT
    *  End-of-line comments (!)
       Tabs that are treated like tabs in the source
       Continuation lines can begin with a tab
    *  DOUBLE COMPLEX keyword (COMPLEX*16 is supported)
       BYTE data type
       REAL *16
       COMMON block vars can be initialized in DATA statements before
          COMMON statement
       Octal and hexadecimal constant notation ('017'O, 'FF'X)
    *  Records and structures
       LOGICAL and INTEGER variables are interchangable
          (the complication here is that .TRUE. is odd, .FALSE. is even
          on VAX)
    *  .AND., .OR., .XOR., etc. allow numeric arguments
       VOLATILE statement
       Some intrinsic functions are allowed in PARAMETER expressions
       DO  ...   END DO
    *  DO WHILE
       %LOC
       %REF, %VAL, %DESCR
       FUNCTION length specifications  (e.g. INTEGER FUNCTION FUN*2)
       ACCEPT and TYPE statements
       REWRITE statement
       Variable format descriptors
       O, $ edit descriptors
       OPEN statement keywords:
          ASSOCIATEVARIABLE
          DEFAULTFILE
          DISP[OSE]
          NAME
          MAXREC
          ORGANIZATION
          READONLY
          RECORDSIZE  (a synonym for RECL)
       CLOSE statement DISP[OSE] keyword
       READ(iunit'irec) syntax for direct access files
       INQUIRE statement keywords:
              DEFAULTFILE
              ORGANIZATION
    *  OPEN append

       FORTRAN 66 leftovers:
              ENCODE, DECODE statement
              DEFINE FILE
              FIND
              Old PARAMETER syntax and semantics


 577. MAXEXPONENT Function Documentation Error

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  2-MAR-1990    ArticleIdent: Q57608

 Page 242 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 incorrectly states that the return value of the MAXEXPONENT function
 is 38.

 The MAXEXPONENT function actually returns 308.


 578. Conversion Functions from BCD (DECMATH.LIB) to IEEE Formats

 Product Version(s): 3.20 3.30 3.31 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | softlib BCD2IEEE.ARC
 Last Modified:  2-MAR-1990    ArticleIdent: Q57871

 There is a file in the Software/Data Library named BCD2IEEE that
 includes Microsoft FORTRAN 5.0 source code for conversion between
 Binary Coded Decimal (BCD) floating-point format (used in FORTRAN Versions
 3.20, 3.30, and 3.31 DECMATH.LIB) and IEEE floating-point format (used in
 the Version 4.00, 4.01, 4.10, and 5.00 coprocessor and emulator libraries).

 BCD2IEEE can be found in the Software/Data Library by searching
 on the keyword BCD2IEEE, the Q number of this article, or S12521.
 BCD2IEEE was archived using the PKware file-compression utility.

 BCD2IEEE includes the following files:

    File           Description
    ----           -----------

    SDECCVT        A FORTRAN function that converts Binary Coded Decimal
                   floating-point format for single-precision real
                   numbers to IEEE floating-point format for
                   single-precision reals

    SDECTST.FOR    A FORTRAN program to demonstrate the use of SDECCVT

    DDECCVT        A FORTRAN function that converts Binary Coded Decimal
                   floating-point format for double-precision reals to
                   IEEE floating-point format for double-precision
                   reals

    DDECTST.FOR    A FORTRAN program to demonstrate the use of DDECCVT


 579. Handling Floating-Point Exceptions

 Product Version(s): 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q57918

 Section 1.5 of the "Microsoft FORTRAN Advanced Topics" manual for the
 Microsoft FORTRAN Optimizing Compiler Version 5.00 describes how the
 five exceptions of floating-point arithmetic required by the IEEE
 standard can be controlled. Similar information is contained in
 Appendix D of the "Microsoft FORTRAN 4.1 Optimizing Compiler: User's
 Guide" for Versions 4.x and Appendix F of the "Microsoft FORTRAN
 User's Guide" for Versions 3.3x.

 These exceptions are invalid operation, divide by zero, overflow,
 underflow, and precision. The following three routines, provided in
 the FORTRAN run-time library, allow you to obtain and set the value of
 the status and control words:

    The store-status-word (SSWRQQ) function returns the value of
    the status word.

    The store-control-word (SCWRQQ) function returns the value
    of the control word.

    The load-control-word (LCWRQQ) function set the control word
    to a certain value.

 The following program demonstrates usage of the LCWRQQ function to
 disable overflow and zero divide run-time errors:

      INTERFACE TO SUBROUTINE LCWRQQ(CW)
      INTEGER*2 CW
      END

      PROGRAM NOEXCEPTIONS

      INTEGER*2 CW
      PARAMETER(CW=16#133F)
      REAL*4 X,Y,Z

      X = 1.0
      Y = 0.0

      CALL LCWRQQ(CW)

      Z = X / Y

      END


 580. Internal Compiler Error: '@(#)omf.c:1.60', Line 185

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q58322

 The program below causes the following internal compiler error:

    fatal error F1001: Internal Compiler Error
                   (compiler file '@(#)omf.c:1.60', line 185)
                   Contact Microsoft Technical Support

 The program defines a common block of arrays that spans three
 segments. The program then initializes the arrays of the common block
 to zero. The error is generated because the program is initializing
 the arrays in a different order than they are specified in the common
 block.

 The workaround is to initialize the arrays in the same order that they
 appear in the common block.

 Microsoft is currently researching the problem and will post new
 information as it becomes available.

 The following program demonstrates the internal compiler error:

 C ============ FORTRAN SOURCE CODE == Fragment #1 ===============

       real*8 test1[huge](225,100), test2(300), test3(300)

       common /test/ test1, test2, test3

       data test3 /300*0/
       data test1 /22500*0/

       end
 C ===============================================================

 The workaround is to initialize the arrays in the order they appear in
 the common block as seen below.

 C ============ FORTRAN SOURCE CODE == Fragment #2 ===============

       real*8 test1[huge](225,100), test2(300), test3(300)

       common /test/ test1, test2, test3

       data test1 /22500*0/
       data test3 /300*0/

       end
 C ===============================================================


 581. Strange Characters in MAP File on 27th Segment Name and Above

 Product Version(s): 5.00   | 5.00
 Operating System:   MS/DOS | OS/2
 Flags: ENDUSER | S_LINK buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q58394

 When looking at a MAP file that was compiled with FORTRAN Version 5.00
 that has more than 26 segments, some strange characters start
 appearing on the 27th segment name. The characters could be smiley
 faces, diamonds, or hearts, in addition to the ASCII characters of
 132d and 128d.

 Microsoft has confirmed this to be a problem with FORTRAN 5.00 and
 linker Versions 5.03 and 5.01.20. This problem does not occur if the
 file was compiled under FORTRAN 4.10. We are researching this problem
 and will post new information as it becomes available.

 The following program demonstrates the problem:

 SOURCE CODE:
        PROGRAM strange
        COMMON /dummy/ x(500000) !makes over 26 segments
        STOP
        END

 The above program was compiled with the default options.

 The above code produces a MAP file upon link, as follows:

    Start     Length   Name             Code
    -----     ------   ----             ----

    0001:0000 00020H   STRANGE_TEXT     CODE
    0001:0020 02AB1H   _TEXT            CODE
    0001:2AD2 00000H   C_ETEXT          ENDCODE
    0002:0000 10000H   DUMMY$A          $DUMMY
     .    .     .        .                .
     .    .     .        .                .
    001B:0000 10000H   DUMMY$Z          $DUMMY
    001C:0000 10000H   DUMMY$AA###      $DUMMY
    001D:0000 10000H   DUMMY$AB###      $DUMMY
    OO1E:0000 10000H   DUMMY$AC###      $DUMMY
     .    .     .        .     ^^^        .
                                |
    These are the strange-------|
    characters.

 The strange characters usually are the ASCII characters of smiley
 faces, hearts, diamonds, an "a" with two dots over it, and a "c" with
 a squiggly line under it. These characters represent the ASCII decimal
 values of 1-4, 128, and 132.


 582. Registerfonts Function Returns -4 When Out of Memory

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr S_C S_QuickC _registerfonts
 Last Modified:  2-MAR-1990    ArticleIdent: Q58430

 The registerfonts function in the GRAPHICS.LIB graphics library may
 return a value of -4. This error code will be returned if there is not
 enough free memory to allocate space for the font(s). This return code
 should be documented on Page 239 of the "Microsoft FORTRAN Advanced
 Topics" manual for Version 5.00.

 Using the /CP:1 switch at link time may free up enough memory to
 enable registering of the font. The /CP or /CPARMAXALLOC switch limits
 the number of paragraphs the DOS loader may allocate at run-time.


 583. L1103 and Initialization of Large Common Blocks

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q58431

 The program below causes the following linker error:

    fatal error L1103: attempt to access data outside segment bounds

 The program defines a common block of arrays that span multiple
 segments. The program then initializes the arrays in the common block.
 The error is generated because the program is initializing the arrays
 in a different order than they are specified in the common block.

 The workaround is to initialize the arrays in the same order that they
 appear in the common block.

 Note: It is also possible to generate an internal compiler error by
 making simple modifications to the source code mentioned above.
 However, the workaround, is the same: initialize arrays in the order
 they are defined in the common block. For an example, query on the
 following in this Knowledge Base:

    internal and compiler and error and F1001 and line and 185

 Microsoft is researching this problem and will post new information
 here as it becomes available.

 The following program demonstrates the linker error L1103:

 C ============ FORTRAN SOURCE CODE == Fragment #1 ===============

       real*8    test1, test2

       common /test/ test1(1000,10), test2(100)

       data test2 /100*0/
       data test1 /10000*0/

       end
 C ===============================================================

 The workaround is to initialize the arrays in the order they appear in
 the common block, as shown below.

 C ============ FORTRAN SOURCE CODE == Fragment #2 ===============

       real*8    test1, test2

       common /test/ test1(1000,10), test2(100)

       data test1 /10000*0/
       data test2 /100*0/

       end
 C ===============================================================


 584. Invalid Filename Causes "SHARE Not Installed" in FORTRAN 5.00

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59093

 Trying to open a file with an invalid file specification incorrectly
 produces the following error message in OS/2.

    run-time error F6412: OPEN(filename.ext.)
     - SHARE not installed

 In the following example, the trailing period should be removed from
 the filename specification.

      OPEN(UNIT=7,FILE='filename.ext.')
      END

 Microsoft is researching the problem and will post new information
 here as it becomes available.


 585. Character String and PARAMETER Statement

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q59094

 When using the PARAMETER statement to define a symbolic constant, you
 can use the symbolic constant to define the length of a CHARACTER
 string. The following program demonstrates this:

     PROGRAM FOO
     parameter (length=80)
     character string_NAME*(length)
     end

 You must put the symbolic constant (LENGTH) in parentheses, or a
 syntax error will occur.


 586. PRECISION Intrinsic Function Yields Incorrect Results

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59227

 The FORTRAN intrinsic function PRECISION, which is documented on Page
 242 of the "Microsoft FORTRAN Reference" manual for Version 5.00,
 produces incorrect results when used to find the precision of a REAL
 number.

 Microsoft has confirmed this to be a problem with Microsoft FORTRAN
 Version 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The PRECISION function was introduced with FORTRAN 5.00.

 The following example demonstrates this problem:

 C ===== FORTRAN source code ================================

       real*4 var1
       double precision var2

       data var1, var2 /0,0/

       write (*,*) PRECISION (var1)
       write (*,*) PRECISION (var2)

       end

 C ==========================================================

 The program output is as follows:

    15
    15

 The expected output should be as follows

     6
    15

 (that is, 6 for the real*4 and 15 for the double precision).


 587. F1912 "Cannot Open File" Caused by Nonexistent File

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q59228

 The following error usually occurs because the file you are trying to
 compile does not exist (for example, you typed FL TXXT.FOR instead of
 FL TEST.FOR) or you are not compiling from the directory in which the
 file exists:

    fatal error F1912: (file name) : cannot open file

 To prevent this error, specify the correct filename or change to the
 directory in which the file resides, then proceed with compiling.


 588. "P" Edit Descriptor and Zero Output

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59229

 The "P" edit descriptor is described on Page 84 of the "Microsoft
 FORTRAN Reference" manual for Version 5.00.

 The "P" edit descriptor is a "scale factor" for output. It is useful
 when printing out percentages.

 When a ZERO value is printed out, it is inconsistent with the other
 values, printing an extra zero. There does not seem to be any way
 around this.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information here as it
 becomes available.

 The following example demonstrates the problem:

 CC When a zero value printed out, an extra zero is printed.
       var1 = 0.0000
       var2 = 0.0123
       write (*,'(2P,1x,2F10.5)') var1, var2
       end

 The following line is the incorrect output from this program:

    00.00000   1.23000

 The output of the program should be as follows:

     0.00000   1.23000


 589. "Out of Environment" Error After Language Installation

 Product Version(s): 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | Supercharging MS-DOS O_MSDOS S_C H_MASM S_PASCAL install set
 Last Modified:  2-MAR-1990    ArticleIdent: Q59230

 The MS-DOS "out of environment space" error can be caused by an
 environment that contains the following:

 1. Many directories in the command path or DOS APPEND command
 2. Many SET statements
 3. A large system prompt definition
 4. Anything else that will fill up the environment

 For example, this error can occur if several Microsoft languages have
 been set up on a system and their associated environment variables
 have been placed in the AUTOEXEC.BAT file.

 A SHELL statement can be placed in the CONFIG.SYS file to increase the
 size of the environment and eliminate the error.

 In MS-DOS Versions 3.20 and later, a typical shell statement is as
 follows:

    SHELL=C:\COMMAND.COM /p /e:512

 The default is 160 bytes. This example sets the environment to 512
 bytes. The size can be as large as 32768 bytes, but this is not
 recommended because it wastes memory if the space is not really
 needed.

 In MS-DOS Versions 3.00 and 3.10, a typical shell statement is as
 follows:

    SHELL=C:\COMMAND.COM /p /e:32

 The default size is 10 (160 bytes). Size is expressed in multiples of
 16 bytes. The above example sets the environment to 512 bytes
 (16 * 32). The size can't be greater than 64 (1024 bytes).


 590. F6099: INTEGER Overflow Error with Char Function

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59231

 The "F6099 run-time error - INTEGER overflow" may not be generated
 correctly when the /4Yb switch is used at compile time on code that
 contains a write statement and the char intrinsic function, in that
 order.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information here as it
 becomes available.

 The code below produces the F6099 run-time error when compiled with
 the /4Yb switch (extended error handling).

       character*1 jcha
       ic = 134
       write (*,*) ic
       jcha = char(ic - 68)
       end

 It gives the same error both in DOS and OS/2. The code compiles and
 runs without errors on previous versions of Microsoft FORTRAN.

 If the write statement is commented out, or if 76 is substituted for
 the expression "ic - 68", no error is produced.

 If the integer variable, ic, is initialized to a value of 127 or less,
 the error does not occur. Also, if the character variable, jcha, is
 typed as character*2 or greater, the error does not occur. Finally,
 the numeral 68 in the char function can be replaced with any integer
 greater than 0 and it will still generate the F6099 error at run time.


 591. Manually Patching the FORTRAN 5.00 8087 Control Word

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-MAR-1990    ArticleIdent: Q59379

 Using the Microsoft FORTRAN 5.00 coprocessor or math emulation library
 on an Intel 8087 math coprocessor (not an 80287 or 80387 coprocessor)
 may give incorrect results for math operations. The symptoms of this
 problem are incorrect results, loss of decimal place precision, or
 unexpected zero results. In some cases the machine may lock or hang at
 run time. The problem is caused by incorrect initialization of the
 8087 control word.

 To properly diagnose the problem, link the program with the emulator
 library, and set the NO87 environment variable (described on Page 17
 of the "Microsoft FORTRAN Advanced Topics" Version 5.0 manual). The
 patch listed below is necessary if the program runs correctly without
 the coprocessor (using NO87), but does not execute properly when the
 8087 coprocessor is used. Note: It is also possible, in this case,
 that the coprocessor is bad or there is another conflict on the
 machine.

 The FORTRAN 5.00 8087 Control Word patch is available from Microsoft
 Product Support Services by calling [phone]. This patch is for
 the FORTRAN coprocessor and math emulation libraries and is for use
 with the 8087 coprocessor, not the 80287 or the 80387.

 It is also possible to patch the library manually using LIB.EXE
 and DEBUG.COM. This process is outlined below.

 The procedure to patch the library first uses the library manager
 LIB.EXE to extract the module 87EXIST.OBJ. The module is then loaded
 into DEBUG, which is used to patch 7 bytes in the module. Finally,
 LIB.EXE is used to put the module back into the FORTRAN library.
 Familiarity with DEBUG is highly recommended for carrying out this
 procedure.

 To patch the FORTRAN 5.00 coprocessor library for use with the 8087,
 follow these steps:

 1. Make sure that the DOS directory and FORTRAN BIN directory are
    listed in the PATH.

 2. Change to the FORTRAN LIB directory.

 3. Type the following keystrokes verbatim (substituting the name of
    the FORTRAN coprocessor or emulator library you are using for
    LLIBFOR7.LIB below):

       LIB LLIBFOR7.LIB-*87EXIST; <ENTER>

       DEBUG 87EXIST.OBJ <ENTER>

       E 12DD:01E9 B9 1E 00 E2 FE DB E3 <ENTER>

       W <ENTER>

       Q <ENTER>

       LIB LLIBFOR7.LIB+87EXIST; <ENTER>

 The library is now patched and can be used normally.

 Notes
 -----

 1. If patching the math emulation library, use the library name
    LLIBFORE.LIB instead of LLIBFOR7.LIB.

 2. If, during any operation, something goes wrong and control is not
    returned to the DOS or DEBUG prompt, start over from the beginning.
    LIB.EXE will make a backup copy of the library when invoked, naming
    it with the .BAK extension. Simply rename the library to the .LIB
    extension and start over.

 3. OS/2 USERS: To be able to invoke DEBUG, you will have to boot to a
    version of DOS.


 592. L2029: Unresolved External ___aDBswpchk with GRAPHICS.LIB

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | S_LINK
 Last Modified: 27-MAR-1990    ArticleIdent: Q59421

 Linking with GRAPHICS.LIB in OS/2 may give the following error
 message:

    d:\lib\GRAPHICS.LIB(..\gr\qeswap.asm) : error L2029 :
      '___aDBswpchk' : unresolved external

 This is because GRAPHICS.LIB is designed for DOS and is being linked
 with a protected-mode FORTRAN library, which does not include the
 external references required by GRAPHICS.LIB.

 Link with the real-mode library to correct the problem.

 For example, the following sample programs included with FORTRAN
 Version 5.00 produce this error if linked under OS/2:

    MAGNIFY.FOR
    COLOR.FOR
    TEXT.FOR
    ANIMATE.FOR
    EGA.FOR


 593. FORTRAN 5.00 Loop Optimization, Subroutine, and Array Problem

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00 bad bogus wrong invalid
 Last Modified: 27-MAR-1990    ArticleIdent: Q59422

 In FORTRAN Version 5.00, the loop optimizer does not correctly
 optimize the subroutine MOVE in the code below, producing incorrect
 output.

 /Od or /Odt takes care of the problem.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information here as it
 becomes available.

       integer*2 buf(20)
       do 10 i=1,10
 10    buf(i) = 9

       call move(10,buf(11),buf)

       write(*,'(10(i8))') (buf(i),i=1,20)
       end

       Subroutine move(npts, y1, y2)
       integer*2 y1(*), y2(*)
       do 10 i=1,npts
         y2(i) = y1(i)
 10    continue
       return
       end

 The following is the correct output:

     0     0     0     0     0     0     0     0     0     0
     0     0     0     0     0     0     0     0     0     0

 The following is the incorrect output:

     0     0     0     0 21325 21024 28277 21549 28009  8293
     0     0     0     0     0     0     0     0     0     0


 594. Using the SYSTEM and SPAWN Functions with FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | 4.xx
 Last Modified: 27-MAR-1990    ArticleIdent: Q59602

 The DEMOEXEC.FOR sample program that is included with the Microsoft
 FORTRAN Optimizing Compiler demonstrates how to use DOS commands and
 execute programs from within a FORTRAN program.

 The SYSTEM command allows a FORTRAN program to execute DOS commands.
 For instance, a program may clear the screen by using the DOS CLS
 command.

 The SPAWN command allows a FORTRAN program to spawn -- or chain -- a
 program from itself. The FORTRAN program remains in memory while the
 spawned program is executed. Control is returned to the spawning
 FORTRAN program when the spawned program completes.

 For more information on the SYSTEM and SPAWN functions, please refer
 to the DEMOEXEC.FOR program included with your Microsoft FORTRAN
 Optimizing Compiler, or to Pages 87-88 in the "Microsoft FORTRAN
 Advanced Topics" manual for Version 5.00.


 595. Using Backslashes with the FORTRAN SYSTEM and SPAWN Functions

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | 4.xx
 Last Modified: 27-MAR-1990    ArticleIdent: Q59603

 Care should be taken when using backslash (\) characters in strings
 passed to the SYSTEM and SPAWN functions. The SYSTEM and SPAWN
 functions are actually C routines. In C, the backslash character is
 used to denote an editing descriptor, somewhat similar to the way the
 I, F, X, etc., editing descriptors are used in the FORTRAN FORMAT
 statement. The following sample SYSTEM call incorrectly uses the
 backslash character:

    I = SYSTEM('dir c:\fortran\src\*.for'C)

 The C function associated with the FORTRAN SYSTEM function will
 interpret the backslashes as editing descriptors. In C, if you want to
 print out a backslash you must follow the first backslash with
 another; this tells C to temporarily ignore the backslash as an
 editing descriptor. The following line demonstrates how to properly
 use the backslash character in the SYSTEM and SPAWN functions:

    I = SYSTEM('dir c:\\fortran\\src\\*.for'C)

 For more information on the SYSTEM and SPAWN functions, please refer
 to the DEMOEXEC.FOR program included with the Microsoft FORTRAN
 Optimizing Compiler, or Pages 87-88 of the "Microsoft FORTRAN Advanced
 Topics" manual for Version 5.00.


 596. Speeding Up the Coprocessor Library with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | /FPi87 docerr
 Last Modified: 18-JUL-1990    ArticleIdent: Q59604

 Pages 9-10 of the "Microsoft FORTRAN Advanced Topics" version 5.0
 manual and Page 323 of the "Microsoft FORTRAN Reference" version 5.0
 manual include Assembly source code that, when assembled and linked
 with a FORTRAN program and the coprocessor library, is supposed to
 increase the speed with which coprocessor functions are executed. The
 code is designed to create true inline coprocessor instructions.

 However, the code, as it appears on the above pages, contains several
 errors and will not assemble correctly. Minor changes can be made so
 that no Assembly or link errors occur, but the code will still not
 speed up calls to the coprocessor. The following code is a corrected
 version of the code in the advanced topics and reference manuals.
 Through informal testing, this corrected code has been found to speed
 up inline coprocessor code by as much as 2 to 3 percent.

 Please note that different switches must be used with the following
 code, depending on whether or not the coprocessor is an 8087.

      page ,132
      title     rmfixups
 ;
 ;rmfixups.asm -
 ;
 ;   Copyright (c) 1988-1990, Microsoft Corporation.
 ;         All Rights Reserved.
 ;
 ;Purpose:
 ;
 ;   To remove floating point fixups, create rmfixups.obj with:
 ;
 ;      masm -Mx rmfixups.asm,rmfixups.obj;
 ;
 ;   Then, link your .OBJs with rmfixups.obj and use the /noe link
 ;   switch. This .EXE will only run correctly on a machine with an
 ;   80x87 (or 80486).
 ;
 ;
 ;   To remove floating point fixups and fwait instructions that are
 ;   only needed with an 8087, create rmfwaits.obj with:
 ;
 ;      masm -Mx -DRM_FWAITS rmfixups.asm,rmfwaits.obj;
 ;
 ;   Then, link your .OBJs with rmfwaits.obj and use the /noe link
 ;   switch. This .EXE will only run correctly on a machine with an
 ;   80287, 80387, or 80486.
 ;
 ;*********************************************************************

 public FIWRQQ,FIERQQ,FIDRQQ,FISRQQ,FJSRQQ,FIARQQ,FJARQQ,FICRQQ,FJCRQQ

 ifdef  RM_FWAITS

     bFWAIT  equ     09bh
     bNOP    equ     090h

     FIDRQQ  equ     (bNOP - bFWAIT)
     FIERQQ  equ     (bNOP - bFWAIT)
     FIWRQQ  equ     0

     FIARQQ  equ     (bNOP - bFWAIT)
     FJARQQ  equ     0
     FISRQQ  equ     (bNOP - bFWAIT)
     FJSRQQ  equ     0
     FICRQQ  equ     (bNOP - bFWAIT)
     FJCRQQ  equ     0

 else ;not RM_FWAITS

     FIDRQQ  EQU     0
     FIERQQ  EQU     0
     FIWRQQ  EQU     0

     FIARQQ  EQU     0
     FJARQQ  EQU     0
     FISRQQ  EQU     0
     FJSRQQ  EQU     0
     FICRQQ  EQU     0
     FJCRQQ  EQU     0

 endif     ;not RM_FWAITS

 extrn     __fpmath:far
 extrn     __fptaskdata:far
 extrn     __fpsignal:far

 CDATA     segment word common 'DATA'
      dw   0
      dd   __fpmath
      dd   __fptaskdata
      dd   __fpsignal
 CDATA     ends

 end


 597. Multidimensional Array in Common Block Addressing Problem

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-MAR-1990    ArticleIdent: Q59605

 When accessing multidimensional arrays that are located within a
 common block, a protection violation may result at run time under
 OS/2, or incorrect results under MS-DOS.

 The following code illustrates the problem. At run time, this code
 generates a protection violation under OS/2:

       common /cbname/array1(5,5)

       integer*4 array1,array2(5,5)

       do 10 j = 1,5
       array1(i,j)=array1(i,j)+array2(i,j)
 10    CONTINUE
       end

 The above code results in various positions in the array being
 skipped when run under DOS.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 598. BLOCK DATA Routine, and FORTRAN and Library Files

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | S_LINK
 Last Modified: 27-MAR-1990    ArticleIdent: Q59606

 BLOCK DATA may not initialize data in common blocks when the block
 data routine is placed in a library.

 This is because of the operation of the linker program. The linker
 program only moves modules from library files into the executable if
 they are required to resolve external references.

 If the BLOCK DATA routine is the only thing in a particular module
 within a library, it will never be called into the executable.

 A BLOCK DATA routine generates a common block with initialized data.
 Because a common block is declared in each location it is used, it is
 not treated as an unresolved external when the linker is linking with
 other object modules.

 To make this work properly, make sure that the module the BLOCK DATA
 routine is located in is loaded by the linker to resolve some other
 external reference. This can be done by having a piece of executable
 code in the same module and making sure that it is needed in any
 program that wants to use the initialized block data.

 File in Library
 ---------------

 C ******** BLOCK DATA statement at beginning of file ***

       BLOCK DATA foo
         integer*2   int1
         real*4      real1
         character*2 char1
         logical     log1
         common /test/ int1, real1, char1, log1
         data int1, real1, char1, log1 /1,4.0,'ZZ',.true./
       END

       subroutine foo2 ! this is here to fulfill unresolved external.
       end

 File in Object File
 -------------------

 C ******** Beginning of main program *******************

       PROGRAM block

       integer*2   int1
       real*4      real1
       character*2 char1
       logical     log1

       common /test/ int1, real1, char1, log1

       write (*,100) int1, real1, char1, log1
 100   format (1X, I1, 3X, F3.1, 3X, A2, 3X, L1)
       call foo2 ! this causes Unresolved external, requiring load from
                 ! the Library file.

       end


 599. FORTRAN Setup Causes SYS2090 Error

 Product Version(s): 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-MAR-1990    ArticleIdent: Q59735

 The system error SYS2090 during FORTRAN setup may be caused by:

 1. Either of the following:

    a. Using DOS Version 2.x or a Version 2.x COMMAND.COM with a
       different version of DOS

    b. Running bound programs under DOS 2.x (query on "SYS2090" for
       more information on this situation)

    Note: DOS 3.00 or later is required for FORTRAN 5.00.

 2. Interference from TSRs or network software

 3. A corrupt FORTRAN file


 600. Opening More Than 20 Files Under OS/2 with FORTRAN 5.00

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | limit F6417 too many open files
 Last Modified: 24-JUL-1990    ArticleIdent: Q60046

 To increase the maximum number of open files with Microsoft FORTRAN
 5.00 under OS/2, follow the steps below. This procedure requires the
 use of Microsoft Macro Assembler Version 5.10 or later.

 The following information is also found on Pages 405-407 in the
 "Microsoft FORTRAN Reference" Version 5.0 manual.

 Note: The file CRT0DAT.ASM must be assembled using the /Dmem_l switch.
 This is not stated in the manual.

 1. Edit the file CRT0DAT.ASM found on the Source Code disk in the
    \STARTUP\OS2 directory.

    Change the following line

       _NFILE_=20

    to the following:

       _NFILE_=xx (replace xx with the number of files)

    Delete the comment mark (;) from the following line in CRT0DAT.ASM:

       ;  extrn DOSSETMAXFH:far

    You also should delete the comment marks (;) from the following
    lines in CRT0DAT.ASM:

       ;  mov ax,_NFILE_
       ;  push ax
       ;  call DOSSETMAXFH

    After you delete the comment marks, the lines should read as
    follows:

       mov ax,_NFILE_
       push ax
       call DOSSETMAXFH

 2. Edit the UNIT.ASM file on the Source Code disk in the \STARTUP
    directory. Change the following line

       _NFILE_   equ 20

    to the following:

       _NFILE_equ xx  (same as in the CRT0DAT.ASM file)

 3. Assemble (using Microsoft Macro Assembler Version 5.10) the
    UNIT.ASM and CRT0DAT.ASM files with the following lines [note that
    in mem_l, the last character is the lowercase letter "l", not the
    number 1 (one)]:

       MASM /Dmem_l CRT0DAT.ASM

       MASM UNIT.ASM

 4. Link the .OBJ files with the FORTRAN .OBJ file as in the following
    statement (where FOO.OBJ is your FORTRAN object code):

       LINK /NOE FOO.OBJ + UNIT.OBJ + CRT0DAT.OBJ;


 601. Accessing Mixed-Language, External Variables in FORTRAN

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 30-MAR-1990    ArticleIdent: Q60076

 The following is a sample C and FORTRAN mixed-language program
 demonstrating how to access external variables from within Microsoft
 FORTRAN.

 FORTRAN Code
 ------------

       SUBROUTINE ASSIGN
       INTEGER*2 X [EXTERN, ALIAS:'_extrn']

       X = 2
       END

 C Code
 ------

 #include <stdio.h>

 extern void fortran assign(void);
 int extrn;

 main()
 {
     extrn = 5;
     printf("Before call to FORTRAN:  %d\n",extrn);
     assign();
     printf(" After call to FORTRAN:  %d\n",extrn);
 }

 To use global variables exported from another language in FORTRAN, the
 EXTERN attribute must be used. EXTERN tells the FORTRAN compiler that
 the variable is not local to the FORTRAN subroutine or function.
 Variables declared EXTERN will instead be resolved by the linker. You
 can use the ALIAS attribute to assign a different name to the imported
 variable; in this example, it is required because the underscore
 prepended by the C compiler is invalid in the FORTRAN naming
 convention.

 No modifications should be necessary for the exporting module to allow
 FORTRAN to import the global variable(s).


 602. $DEBUG and /4Yb May Increase Executable File Size

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | large big
 Last Modified: 30-MAR-1990    ArticleIdent: Q60077

 If an executable file size, or the load size of the executable, seems
 to be larger with Microsoft FORTRAN Version 5.0 than it was when
 compiling under a previous version of FORTRAN, it could be due to the
 use of the $DEBUG metacommand or /4Yb switch.

 Both /4Yb and $DEBUG include extended error handling information in
 the .EXE file. Reports from customers and some informal testing show
 that with FORTRAN 5.00, there may be an executable file size increase
 of anywhere from 5 to 28 percent when either /4Yb or $DEBUG are used.
 The load size of the executable also increases at about the same
 percentage. Also, it seems the larger and more complicated the code,
 the percentage that the .EXE file increases is higher. Previous
 versions of FORTRAN (Version 4.00, 4.10, etc.) do not show as large an
 increase, although the increase may be anywhere from 3 to 19 percent.


 603. Using the NEAR Attribute with Common Blocks in FORTRAN

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-MAR-1990    ArticleIdent: Q60079

 On Page 34 of the "Microsoft FORTRAN Advanced Topics" guide is a
 description of using the NEAR attribute in conjunction with common
 blocks. In Microsoft FORTRAN, common blocks are by default put in
 their own segment. This saves space in the default data segment
 (DGROUP). The drawback to this method is that data in common blocks
 must be accessed through far pointers; code is therefore larger and
 slower. Use of the NEAR attribute with small, frequently used common
 blocks will speed up execution of the program and reduce code size.
 The only requirement is that there must be space in the default data
 segment.

 When using the NEAR attribute with common blocks, the data in each
 common block may appear to remain in its own segment rather than in
 DGROUP if a source listing (/Fs) is used. This may be confusing when
 there is obviously enough space in the default data segment. After
 examining an object listing (/Fl) or a map listing (/Fm), it becomes
 clear that the segments containing the NEAR common blocks are
 concatenated into the default data segment.

 The following code is a sample program using the NEAR attribute to put
 common blocks in the default data segment:

       integer*4 a,b,c
       common    /c1 [near]/ a,c
       common    /c2 [near]/ b
       end

 The source listing describes each common block:

    Global Symbols
    Name                      Class   Type              Size   Offset
    C1. . . . . . . . . . . . common  ***                  8    0000
    C2. . . . . . . . . . . . common  ***                  4    0000
    main. . . . . . . . . . . FSUBRT  ***                ***    0000

 The map file demonstrates that each common block is included in
 DGROUP. Note that the segment address of each common block is 005Dh,
 which is the same as DGROUP. The map file contains the following:

  Start  Stop   Length Name                   Class
  00710H 00713H 00004H C2$A                   $C2
  00720H 00727H 00008H C1$A                   $C1

  Origin   Group
  005D:0   DGROUP

   Address         Publics by Name
  005D:0130       C1
  005D:0120       C2

   Address         Publics by Value
  005D:0120       C2
  005D:0130       C1

 The object listing includes a description of the grouping of all the
 segments, including the common blocks, into DGROUP:

      NAME    common

 C2$A SEGMENT  PARA COMMON '$C2'
 C2$A ENDS
 C1$A SEGMENT  PARA COMMON '$C1'
 C1$A ENDS
 DGROUP    GROUP     CONST, _BSS, _DATA, C2$A, C1$A
      ASSUME  CS: COMMON_TEXT, DS: DGROUP, SS: DGROUP, ES: DGROUP


 604. FORTRAN 5.00 .FON Files Identical to Windows .FON Files

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 30-MAR-1990    ArticleIdent: Q60097

 On Page 187 in the "Microsoft FORTRAN Advanced Topics" Version 5.0
 manual, it states that FORTRAN's .FON font files are identical to the
 .FNT font files used in Microsoft Windows. This is incorrect.

 Instead, the manual should read as follows:

    FORTRAN's .FON files are identical to the .FON files used in the
    Microsoft Windows operating environment.

 All four occurrences of ".FNT" on that page should be changed to
 ".FON."

 Brief testing shows that the Windows .FON files will work with
 Microsoft FORTRAN Version 5.00. (Note: Windows Version 2.11 .FON files
 were used for this test.)


 605. FORTRAN 5.00 Differences from Previous Versions

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                             | OS/2
 Flags: ENDUSER | 3.xx 4.xx 5.xx
 Last Modified:  2-APR-1990    ArticleIdent: Q60151

 For information on what has changed in Microsoft FORTRAN as the
 language has evolved from Version 3.20 to 5.00, see Appendix B (Pages
 373-400) of the "Microsoft FORTRAN Reference" Version 5.0 manual.

 Information on changes is ordered as follows:

 1. Changes from Version 4.10 to 5.00 (Pages 373-377)

 2. Changes from Version 4.00 to 4.10 (Pages 377-379)

 3. Changes from Versions 3.20 and 3.30 to 4.00 (Pages 379-388)


 606. Improper Array Declaration May Cause Computer to Hang

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 23-MAY-1990    ArticleIdent: Q61530

 Microsoft FORTRAN permits operations on full arrays that would
 normally only work with single arguments (scalars); these operations
 are called array expressions. In cases where an array is declared
 improperly, an array expression involving that array may cause the
 computer to hang at run time.

 The following is a simple program that demonstrates this problem:

       integer*4 array(4:1)    ! Improper array declaration
       array = 0               ! Array expression
       end

 The problem with this program is that the array indexes are declared
 in reverse order. The FORTRAN compiler does not generate any error
 messages, but when run under DOS the program will cause the computer
 to hang; under OS/2 CTRL+C will terminate the program.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.


 607. Repeated Edit Descriptors Do Not Work with Implied-DO Loop

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  8-JUN-1990    ArticleIdent: Q61533

 Repeated edit descriptors in FORMAT statements used with implied-DO
 loops do not work properly. In this case, Microsoft FORTRAN version
 5.00 does not reset the FORMAT statement properly. On the second cycle
 through the FORMAT statement, the variables to be output have no edit
 descriptors associated with them; thus, a run-time error F6207 will
 result.

 The following program demonstrates the problem:

       integer*2 j
       real*4   x(4),y(4)

       write (*,10) (j,x(j),y(j),j=1,4)
  10   format (2x,i2,2(2x,f6.1))

 C  No errors are generated if the following line is used in place of
 C  the above FORMAT statement
 C 10  format (2x,i2,2x,f6.1,2x,f6.1)
       end

 The output is as follows:

   1      .0      .0
 run-time error F6207: WRITE(CON)
 - I edit descriptor expected for INTEGER

 The output should be the following:

   1      .0      .0
   2      .0      .0
   3      .0      .0
   4      .0      .0

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.


 608. L2029 and L2025 with Pascal 4.00 and FORTRAN 4.10 or 5.00

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00 S_PASCAL S_LINK
 Last Modified: 23-MAY-1990    ArticleIdent: Q61536

 When using real numbers and mathematical calculations between
 Microsoft Pascal version 4.00 and Microsoft FORTRAN version 4.10 or
 5.00, the following error messages may be generated, depending on the
 order of the libraries at link time:

    error L2029: Unresolved externals

    error L2025: symbol defined more than once

 The code should link without errors if the FORTRAN library is placed
 first on the link line.

 With FORTRAN 4.00 or 4.01, the code functions correctly.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.

 The following code generates the linker error messages listed below:

 PMIX.PAS
 --------

 program pmix(input,output);

 procedure fort(vars xold, xdata: real); extern;

 var xdata, xold: real;
 begin
   xold:=1.0;
   fort(xold, xdata);
   writeln('xdata = ',xdata);
 end.

 FMIX.FOR
 --------

       subroutine fort(xold,xdata)
       real xold, xdata
       integer*4 idec
       idec=3
       xdata=xold/10.**idec
       return
       end

 With the FORTRAN library first:

    link pmix fmix /nod /noe,,,llibfer libpaser;

    LINK : error L2029: Unresolved externals:

    __positive in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cftoe in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cftof in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cftog in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cropzeros in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cfltcvt in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __forcdecpt in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __fassign in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)

    There were 8 errors detected

 With the Pascal library first:

    link pmix fmix /nod /noe,,,libpaser llibfer;

    LLIBFER.LIB(dos\crt0.asm) : error L2025: __aexit_rtn :
    symbol defined more than once
     pos: 2B6F5 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __abrkp : symbol
    defined more than once
     pos: 2B72C Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __abrktb : symbol
    defined more than once
     pos: 2B738 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __asizds : symbol
    defined more than once
     pos: 2B744 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __astart : symbol
    defined more than once
     pos: 2B756 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __atopsp : symbol
    defined more than once
     pos: 2B768 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __abrktbe : symbol
    defined more than once
     pos: 2B775 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __cintDIV : symbol
    defined more than once
     pos: 2B788 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __amsg_exit :
    symbol defined more than once
     pos: 2B7E4 Record type: 7F04

    There were 9 errors detected

 With FORTRAN 4.00 or 4.01, the above code generates the following
 error message at link time, but it creates an executable and seems to
 function correctly if the Pascal library is placed first at link time:

 LLIBFORE(dbgmsg) : error L2025 : __FF_MSGBANNER : symbol defined more
 than once

 The above symbol can be removed from the FORTRAN library to eliminate
 the error message.


 609. Error in Example on Page 39 of 5.0 Reference Guide

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 23-MAY-1990    ArticleIdent: Q61778

 The example code on Page 39 of the "Microsoft FORTRAN Quick Reference
 Guide" for Microsoft FORTRAN version 5.0 is incorrect. The second
 example of logical expressions is not equivalent as the manual states.

 The text in the manual reads as follows:

    C  The following two statements are equivalent:

       go =  .NOT. a  .OR. b  .AND. c
       go =  ((.NOT. a) .OR. b) .AND. c

 These statements are not equivalent. One possible equivalent
 combination would be as follows:

    go = .NOT. a  .OR. b  .AND. c
    go = (.NOT. a) .OR. (b .AND. c)


 610. Line-Continuation Error in the $FREEFORM Sample Program

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 23-MAY-1990    ArticleIdent: Q61789

 There is a documentation error on Page 296 of the "Microsoft FORTRAN
 Reference" for version 5.0 in the sample program under the $FREEFORM
 metacommand. The error is on the 300 FORMAT... line, which is the
 second to the last line in the sample program.

 The $FREEFORM metacommand states that if the last nonblank or
 noncomment character of a line is a minus (-) sign, it is interpreted
 as a line continuation and discarded. However, the sample program uses
 the conventional character in column 6 for the line continuation and
 does not have the minus (-) sign to indicate a line continuation.

 When using the $FREEFORM metacommand, you must use the minus (-) sign
 to indicate a line continuation.

 If you compile the sample program, it causes the following errors:

    freeform.for(32) : warning F4988: unexpected end of format
    freeform.for(33) : error F2115: syntax error

 The following is the corrected example:

 $FREEFORM

 "The sine of the number x is calculated using a power
 series.
 "Successive terms are calculated until one is less than epsi.

     REAL x, epsi, z, sine, next
     INTEGER i
     epsi = 0.0001

     WRITE (*,100)

 100 FORMAT ( 1X, 'ENTER x: ' \ )

     READ (*,'(F10.5)') x

     z = AMOD( x, 6.2831853 )
     sine = z
     i = 4
     next = -z * z * z / 6.0

 200 IF ( ABS( next ) .GE. epsi ) THEN

      sine = sine + next
      next = -next * z * z / (i * (i + 1))
      i = i + 2
      GOTO 200

     END IF

     WRITE (*,300) x, sine

 300 FORMAT ( 1X, 'THE SINE OF ',F10.5, - ! This is the correct
           ' = ',F12.10 )                 ! line continuation
                                          ! for $FREEFORM

 END


 611. SETFILLMASK Graphics Routine and Integer Range Error F2367

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | sine fill
 Last Modified:  9-JUL-1990    ArticleIdent: Q62476

 If you use the SETFILLMASK graphics routine in Microsoft FORTRAN, you
 shouldn't use the $DEBUG metacommand in the source code or compile
 using the /4Yb compiler switch. The array used by the routine is
 declared as INTEGER*1 and if you have any values greater than 127 in
 the array, it produces an "F2367 Integer range error" at compile time.

 The SINE.FOR and FILL.FOR sample programs which are included on the
 Source Code Disk in the Samples subdirectory will produce the above
 error when either /4Yb or $DEBUG are used.

 SETFILLMASK uses an 8 x 8 bit array for the fill-mask design. The
 array must be initialized as INTEGER*1, which has a range of -128 to
 127. The values of the bit array must be able to range from 0 to 255
 in decimal and 00000000 to 11111111 in binary to get every combination
 of fill patterns. This, however, can exceed the range of the INTEGER*1
 array.

 Without using the debug options, the program compiles and works
 correctly, but if you add one of the above debug options and have a
 value in the mask array that is larger that 127, you receive the
 following compiler error:

    name.for(23) : error F2367: value 129 : INTEGER : range error

 The debug option performs range checking of variables. For example, if
 an INTEGER*1 variable exceeds 127 the compiler produces an error.

 If you compile the following example with the /4Yb compiler switch, the
 following errors are produced:

    fill.for
    fill.for(23) : error F2367: value 129 : INTEGER : range error
    fill.for(23) : error F2367: value 145 : INTEGER : range error

 The following is an example using the SETFILLMASK graphics routine:

 C Won't compile with $DEBUG metacommand or with the /4Yb
 C compiler switch because of the two elements in the array
 C mask that are larger than 127.

       INCLUDE 'FGRAPH.FI'
       INCLUDE 'FGRAPH.FD'

       INTEGER*2 dummy_2    ! Variables for Function Return
       INTEGER*4 dummy_4    !    Values

       INTEGER*1 mask(8)    ! Integer*1 has range of -128 to 127
                            !    Largest mask value can be
                            !    11111111b or 255d

 C               Binary      Decimal
 C              --------     -------
       DATA mask / 2# 00000000 ,   !  0d
      +            2# 00111100 ,   !  60d
      +            2# 01000010 ,   !  66d
      +            2# 10000001 ,   !  129d ! Error with /4Yb
      +            2# 10010001 ,   !  145d ! Error with /$Yb
      +            2# 01001010 ,   !  74d
      +            2# 00111100 ,   !  60d
      +            2# 00000011  /  !  3d

       dummy_2 = setvideomode( $VRES16COLOR )  ! Set 16 Color VGA Mode
       dummy_4 = setbkcolor( $BLUE )     !BLUE ! Set Background Color

       CALL clearscreen( $GCLEARSCREEN )

       dummy_2 = setcolor( 15 )          !WHITE

       CALL setfillmask(mask)

       dummy_s = rectangle( $GBORDER, 100,100,500,300 ) ! Border

       dummy_2 = rectangle( $GFILLINTERIOR, 100,100,500,300 ) ! Fill
                                                              ! with
       PAUSE                                                  ! Mask

       dummy_2 = setvideomode( $DEFAULTMODE )  ! Reset Video Mode

       END


 612. GetTextWindow Not Listed in Include Files and Does Not Work

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-JUN-1990    ArticleIdent: Q62484

 The GetTextWindow subroutine listed in the "Additional Graphics
 Routines" section of the README.DOC file on the Setup Disk does not
 work correctly. First, the corresponding routine in the GRAPHICS.LIB
 library does not work correctly. In addition, the include files that
 are needed with the graphics routines, FGRAPH.FI and FGRAPH.FD, have
 no entry for this subroutine.

 The first problem has no solution. The second problem can be corrected
 by adding the following information to the corresponding include files
 as shown below.

 Add the following to the FGRAPH.FI include file:

     INTERFACE TO SUBROUTINE
    1 gettextwindow[FAR,C,ALIAS:"__gettextwindow"]
    1 (r1,c1,r2,c2)
     INTEGER*2 r1
     INTEGER*2 c1
     INTEGER*2 r2
     INTEGER*2 c2
     END

 Add the following to the FGRAPH.FD include file:

    EXTERNAL gettextwindow

 Note: The GetTextWindow subroutine is not listed in the "Graphics
 Library Routines" chapter of the "Microsoft FORTRAN Advanced Topics"
 manual.

 The GetTextWindow subroutine gets the boundaries of the current text
 window and is included in the GRAPHICS.LIB library. However, after
 adding the information above to the include files, the GetTextWindow
 subroutine does not work correctly. The subroutine returns zeros for the
 coordinates of the window regardless of the coordinates the window
 actually has.

 Also, depending on the hardware/software configuration, the machine
 may hang or a "run-time error R6003: integer divide by 0" may occur
 when executing the program. An example of using the subroutine is as
 follows:

 c
 c Compile command line: fl /FPi test.for graphics.lib /link /NOI
 c
       INCLUDE 'FGRAPH.FI'
       INCLUDE 'FGRAPH.FD'

       INTEGER x1,y1,x2,y2

       call settextwindow(10,10,30,20)
       call gettextwindow(x1,y1,x2,y2)
 c
 c Returns zeros for all four values
 c
       write (*,*) x1,y1
       write (*,*) x2,y2

       END

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 613. PIE Declaration in Manual Is Incorrect

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-JUN-1990    ArticleIdent: Q62533

 There is a documentation error in the declaration of the PIE function
 on Page 233 of the "Microsoft FORTRAN Advanced Topics" manual for
 version 5.00.

 If the INTERFACE statement in the manual is used, an error "L2029 :
 '__f_pie' : unresolved external" occurs. The INTERFACE statement in
 the FGRAPH.FI include file contains the correct information.

 The incorrect line appears as follows:

       INTEGER*2 pie[FAR,C,ALIAS:"__f_pie"]

    "__f_pie" should be changed to "__pie" as follows:

       INTEGER*2 pie_w[FAR,C,ALIAS:"__pie"]

 The FIGURE.FOR sample program that is included with FORTRAN version
 5.00 illustrates the use of the PIE function.


 614. PIE_W Declaration in Manual Is Incorrect

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-JUN-1990    ArticleIdent: Q62534

 There is a documentation error in the declaration of the PIE_W
 function on Page 233 of the "Microsoft FORTRAN Advanced Topics" manual
 for version 5.00.

 The incorrect line appears as follows:

    INTEGER*2 pie[FAR,C,ALIAS:"__f_pie_w"]

    "pie" should be changed to "pie_w" as follows:

    INTEGER*2 pie_w[FAR,C,ALIAS:"__f_pie_w"]


 615. Incorrect RGB Line in Manual; "9" Should Be "g"

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-JUN-1990    ArticleIdent: Q62535

 There is a documentation error on Page 163 of the "Microsoft FORTRAN
 Advanced Topics" manual for version 5.00.

 The incorrect line appears as follows:

    RGB (r,g,b) = (#3f3f3f.AND.(ISHFT(b,16).OR.ISHFT(9,8).OR.r))

 The "9" should be changed to a "g" as follows:

    RGB (r,g,b) = (#3f3f3f.AND.(ISHFT(b,16).OR.ISHFT(g,8).OR.r))
                                                     |
                                        correction --|


 616. Example Using C or Assembly to Scroll Text for FORTRAN

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | mixed language S_C H_MASM
 Last Modified: 19-JUN-1990    ArticleIdent: Q62885

 With an OUTTEXT call, it is not possible to embed CR/LF characters to
 enforce scrolling of text on the screen. To scroll the text, an
 assembler or C routine may be used as follows:

 1. Use SETTEXTPOSITION to position the cursor on the screen.

 2. Use OUTTEXT to display the output at that position.

 3. Call an Assembly or C routine to scroll the screen by one line.

 4. Return to step 1 above, positioning the cursor at the same location
    on the screen.

 The following code sample illustrates the use of the assembly routine:

        interface to subroutine scroll_line()
        end
        include 'fgraph.fi'
        include 'fgraph.fd'
        record/rccoord/curpos
 c
        call settextposition (10,20,curpos)
        call outtext('Hello1')
 c
        call scroll_line()
 c
        call settextposition (10,20,curpos)
        call outtext ('Hello2')
        end

 The following is the code segment of the assembly module:

 .model large,fortran

 .code

 scroll_line proc far
      push bp
      mov bp, sp
      mov ah,6          ;function 6H
      mov al,1          ;number of lines to scroll
      mov ch,0          ;row of top left corner
      mov cl,0          ;col of top left corner
      mov dh,24         ;row of bottom right corner
      mov dl,79         ;col of bottom right corner
      mov bh,7          ;attribute of line
      int 10h           ;interrupt 10h
      pop bp
      ret
 scroll_line endp
      end

 To use the C subroutine, only the interface statement of the FORTRAN
 module should be modified to read as follows:

        interface to subroutine scroll_line [FAR,C] ()
        end

 The following is the code segment of the C module:

 #include <stdio.h>
 #include <dos.h>

 union REGS reg;

 void scroll_line()
 {

 /*
  *  The registers have the same significance as those in
  *  the assembly-language routine above.
  */

   reg.h.ah = 6;     // function 6H
   reg.h.al = 1;     // number of lines to scroll
   reg.h.bh = 0x7;   // attribute of line
   reg.h.ch = 0;     // row of top left corner
   reg.h.cl = 0;     // column of top left corner
   reg.h.dh = 24;    // row of bottom right corner
   reg.h.dl = 79;    // row of top right corner

   int86(0x10, ®, ®);
   return;
 }

 The following is the MAKE file when the assembly module subroutine is
 used:

 all=1.obj 2.obj

 update: 1.for
     fl /Zi /c 1.for

 update: 2.asm
     masm /Zi 2.asm;

 update: $(all)
 link /co $(all),,,/nod graphics llibfer;

 The following is the MAKE file when the C module subroutine is used:

 all=1.obj 2.obj

 update: 1.for
     fl /Zi /c 1.for

 update: 2.c
     cl /AL /Zi /c 2.c

 update: $(all)
     link $(all)/co,,,/nod /noe graphics llibfer llibcer;


 617. FORTRAN 5.00 and C 6.00 Character String and Integer Array

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: enduser |
 Last Modified:  6-JUL-1990    ArticleIdent: Q63308

 The following code is designed to show passing arrays and character
 strings from FORTRAN to C and from C to FORTRAN.

 There are two programs here. The first has a FORTRAN main and C
 subroutine; the second a C main and FORTRAN subroutine. Each program
 does essentially the same thing -- passes an array of 5 INTEGER*4 and a
 character string to the subroutine, which then prints the values.

 C version 6.00 and FORTRAN version 5.00 were used in this example.
 FORTRAN needs to be built with C compatible libraries, and the modules
 need to be linked with the /NOE switch. Each module needs to be
 compiled with the same floating-point and memory-module options (for
 example, /AL /FPi).

 The following is the FORTRAN main:

 C Note that the passed string has a zero length C style string
 C appended so that it appends a NULL terminating character.

       INTERFACE TO SUBROUTINE CPRINT [C] (I,STRING)
       INTEGER*4 I [REFERENCE]
       CHARACTER*(*) STRING [REFERENCE]
       END

       PROGRAM FMAIN

       INTEGER*4 I(5)
       CHARACTER*255 PRINTSTRING /'This example shows passing an array an
      +d a string.'/

       I(1) = 5
       I(2) = 4
       I(3) = 3
       I(4) = 2
       I(5) = 1

       CALL CPRINT(I,PRINTSTRING//''C)

       END

 The following is the start of the C subroutine:

 #include <stdio.h>

 void cprint(long int i[], char * printstring)
 {
   int count;

   printf("\n");
   for (count = 0; count < 5;count++)
     printf("\t%li",i[count]);
   printf("\n");

   printf("%s",printstring);
 }

 The following is the start of the C main program:

 extern void fortran fprint (long int *, char *);

 main ()
 {
     long int i[5];
     char printstring[255] = "This example shows passing an array and"
                             " a string.";

     i[0] = 5;
     i[1] = 4;
     i[2] = 3;
     i[3] = 2;
     i[4] = 1;

     fprint(i,printstring);
 }

 The following is the start of the FORTRAN subroutine:

 C The declaration of PRINTSTRING has to be equal to or less than the
 C size of the string passed from C. If it is not, other data will get
 C accessed, possibly causing a protection violation under OS/2.

       SUBROUTINE FPRINT (I,PRINTSTRING)
       INTEGER*4 I(*)
       CHARACTER*255 PRINTSTRING

       INTEGER  J

 C The following line truncates the string at the end of the C string.
 C (The C string end-of-string character is CHAR(0).)
       PRINTSTRING = PRINTSTRING(1:INDEX(PRINTSTRING,CHAR(0)))

       WRITE (*,*) (I(J),J=1,5)
       WRITE (*,*)
 C The substring (1:lentrim()) is printed instead of just the
 C variable because this way only the characters stored in the
 C variable are printed, and not the entire length of the variable
 C padded with spaces (255 spaces).
       WRITE (*,*) PRINTSTRING(1:LEN_TRIM(PRINTSTRING))
       END


 618. Multiplying by a Power of 2 Produces Wrong Results

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-JUL-1990    ArticleIdent: Q63360

 Incorrect results are produced in FORTRAN version 5.00 when
 multiplying an integer variable by a constant that is a power of 2
 if the result of the multiplication is larger than the range of the
 integer variable.

 This problem is a result of an overflow generated by the
 assembly-language code produced by the FORTRAN compiler. This problem
 does not occur if the result of the multiplication falls within the
 range of the integer variable. To work around this problem, use a
 variable instead of a constant to represent the multiplier.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.

 The following code example demonstrates the problem and the
 workaround:

   INTEGER*2 K/1234/
   INTEGER*2 L/31/, M/32/ ,N/33/
   WRITE(*,*) K*31, K*32, K*33 !Displays incorrect results for K*32
   WRITE(*,*) K*L, K*M, K*N    !Displays correct results for K*M
   END

 The following is the output from the program above:

    38254      -26048       40722
    38254       39488       40722

 The following is a fragment of the assembly listing, which shows the
 compiler does not detect overflow (use the /Fc compilation option to
 produce a combined source-assembly listing):

 ;|*** WRITE(*,*) K*31, K*32, K*33 !Displays incorrect results for K*32
         *** 00000f      a1 00 00                mov     ax,$S14_K
         *** 000012      b1 05                   mov     cl,5
         *** 000014      d3 e0                   shl     ax,cl
         *** 000016      99                      cwd
         *** 000017      52                      push    dx
         *** 000018      50                      push    ax
 ;|*** WRITE(*,*) K*L, K*M, K*N    !Displays correct results for K*M
         *** 000037      a1 00 00                mov     ax,$S14_K
         *** 00003a      f7 2e 04 00             imul    WORD PTR $S16_M
         *** 00003e      52                      push    dx
         *** 00003f      50                      push    ax

 In line 3a of the assembly-language listing, the integer variable K is
 correctly multiplied by the variable M (which is equal to 32), by
 using the IMUL instruction. The IMUL instruction is a signed multiply
 instruction that multiplies an implied destination operand by a
 specified source operand.

 In line 14, K is multiplied by 32 by shifting it left the number of
 positions specified by the corresponding power of 2. In this case, K
 is shifted five places to the left because 5 is the corresponding
 power of 2 for 32 (that is, 2^5 = 32). An overflow occurs because K is
 shifted left too many positions, which is what happens when the result
 of an integer is out of range.

 Overflow is not checked for, and thus, incorrect results are displayed
 as above. Also, if the number was converted to a double prior to the
 shift in the assembly-language code, the overflow would not have
 occurred (see lines 16 and 14 above).

 Disabling optimization has no effect.


 619. "R6001: Null Pointer Assignment" Caused by Loop Optimization

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-JUL-1990    ArticleIdent: Q63381

 Under some circumstances, programs compiled by the Microsoft FORTRAN
 compiler with loop optimization enabled cause the error "R6001: null
 pointer assignment" at run-time.

 The workaround for this problem is to disable loop optimization by
 compiling with either the /Od or /Odct switch. Using CHARACTER*10
 character strings also eliminates the problem in the example below.

 The following program demonstrates the problem:

       CHARACTER*1 STR1(10), STR2(10)
       DATA STR1 / 'T','.','B','.','C','.',4*' ' /
       CALL COPYSTR(STR1,1,10,STR2,1)
       END

       SUBROUTINE COPYSTR(IARRAY,IBEG,IEND,JARRAY,JBEG)
       CHARACTER*1 IARRAY(10),JARRAY(10)

       JPT = JBEG
       DO 100 IGET=IBEG,IEND
         JARRAY(JPT) = IARRAY(IGET)
         JPT = JPT+1
  100  CONTINUE
       RETURN
       END

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.


 620. FORTRAN Err Msg: R6009: Not Enough Space for Environment

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-JUL-1990    ArticleIdent: Q63382

 The run-time error "R6009: not enough space for environment"
 sometimes occurs when the default data segment, or DGROUP, is nearing
 the 64K segment limit. The solution is to use the /Gt switch when
 compiling all modules of the program.

 The /Gt switch frees space in the default data segment by moving data
 items greater than a specified size into far data segments. /Gt4
 should be used for optimal results.

 Please refer to Section 7.6, Page 326, of the "Microsoft FORTRAN
 Reference" manual for more information about the /Gt switch.


 621. L2025 Errors in CHKSTK.ASM with FORTRAN 5.00 and C 6.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C mixed language
 Last Modified:  9-JUL-1990    ArticleIdent: Q63440

 When linking Microsoft FORTRAN version 5.00 and C version 6.00 object
 modules, the following three errors may occur:

    error L2025: STKHQQ : symbol defined more than once
    error L2025: __aaltstkovr : symbol defined more than once
    error L2025: __chkstk : symbol defined more than once

 These three symbols reside in the CHKSTK.ASM module within the FORTRAN
 and C libraries. To eliminate these error messages, use the Library
 Manager (LIB.EXE) to remove the CHKSTK module from the FORTRAN library
 as follows:

    LIB LLIBFORE-CHKSTK;

 Substitute the name of the appropriate FORTRAN library for LLIBFORE
 above.

 The following code demonstrates the problem when compiled
 and linked as indicated below:

       read(*,*) i
       write(*,*) i
       end

 fl /FPi /c test.for
 link test,,,/noe /nod llibce.lib llibfore.lib;

 The FORTRAN library was built with C compatibility.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 622. Calling MS-DOS Interrupt 21 Hex from FORTRAN Version 5.00

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q63464

 The C INTDOS and INTDOSX routines in Microsoft FORTRAN version 5.00
 are built into the FORTRAN run-time libraries. These two routines can
 be used to call the MS-DOS interrupt 21 hex.

 INTDOS invokes the MS-DOS system call specified by registers passed to
 it and returns the result of the system call in another set of
 registers. INTDOSX invokes the MS-DOS system call in the same manner
 as INTDOS, but also accepts segment register values.

 Listed below are two FORTRAN sample programs and an include file that
 demonstrates how to use INTDOS and INTDOSX.

 Note: INTDOS and INTDOSX are not available with FORTRAN run-time
 libraries built for C compatibility. Using these routines with the C
 run-time libraries may cause unexpected results.

 Microsoft cannot guarantee that the information stated here regarding
 how to use INTDOS and INTDOSX will perform all MS-DOS system calls
 correctly because this information has not been tested rigorously and
 is not considered a feature of the product. Also, Microsoft cannot
 guarantee that this information will remain unchanged or work
 correctly in future releases of the Microsoft FORTRAN Compiler.

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for MS-DOS.
 The INTDOS and INTDOSX routines are not documented in either the
 "Microsoft FORTRAN Reference" manual or the "Microsoft FORTRAN
 Advanced Topics" manual. However, these routines are documented on
 Pages 247-248 in the Microsoft C Compiler version 6.00 "Microsoft C
 Reference" manual and Page 365 in the Microsoft C Compiler version
 5.10 "Microsoft C Run-Time Library Reference" manual.

 The file below, INTDOS.INC, is the FORTRAN include file for the INTDOS
 and INTDOSX routines. This file includes the INTERFACE to the C
 routines and the register structures needed for these routines.

 c INTDOS.INC : include file for INTDOS and INTDOSX.

       INTERFACE TO SUBROUTINE INTDOS [C] (inregs,outregs)
       structure /regs/
           integer*2 ax,bx,cx,dx,si,di,flags
       end structure
       record /regs/ inregs  [REFERENCE]   ! Regs into INTDOS
       record /regs/ outregs [REFERENCE]   ! Regs returned
       end

       INTERFACE TO SUBROUTINE INTDOSX [C] (inregs,outregs,segregs)
       structure /regs/
           integer*2 ax,bx,cx,dx,si,di,flags
       end structure
       structure /sregs/
           integer*2 es,cs,ss,ds
       end structure
       record /regs/ inregs   [REFERENCE] ! Regs into INTDOS
       record /regs/ outregs  [REFERENCE] ! Regs returned
       record /sregs/ segregs [REFERENCE] ! Segment registers
       end

       implicit a-g

       structure /wordregs/                  ! Full word registers
           integer*2 ax,bx,cx,dx,si,di,flags
       end structure

       structure /sregs/                     ! Segment registers
           integer*2 es,cs,ss,ds
       end structure

       record /wordregs/ inregs,outregs
       record /sregs/ segregs

 The following program is an example of calling the INTDOS routine:

 c Call the MS-DOS interrupt 21 hex, with function 2A hex to get the
 c system date.

       include 'intdos.inc'

       gethibyte (dataword) = dataword / 256
       getlobyte (dataword) = iand(dataword,255)

       inregs.ax=#2a00                    ! Function number
       call intdos(inregs,outregs)        ! Call DOS interrupt
       write(*,*) ' Month= ',gethibyte(outregs.dx) ! High byte is month
       write(*,*) ' Day  = ',getlobyte(outregs.dx) ! Low byte is day
       write(*,*) ' Year = ',outregs.cx            ! Year
       end

 The following program is an example of calling the INTDOSX routine:

 c Call the MS-DOS interrupt 21 hex, with function 41 hex to delete a
 c file. This example uses the segment registers.

       include 'intdos.inc'
       character filename*12              ! File to delete
       integer*2 flen                     ! Length of filename
       integer*4 addr                     ! Location of filename
       print 10
    10 format (' Enter name of file to delete -> ',$)
       read (*,'(a)') filename            ! Get the file to delete
       flen=len_trim(filename)            ! Remove extra spaces
       filename=filename(:flen)//char(0)  ! Must be an ASCIIZ filename
       addr=locfar(filename)              ! Get the segment and offset
                                          ! of the file
       inregs.dx=iand(addr,#FFFF)
       segregs.ds=ishft(addr,-16)
       inregs.ax=#4100                         ! Function number
       call intdosx(inregs,outregs,segregs)    ! Call DOS interruptx
       if (iand(outregs.flags,1).eq.0) then    ! No error on delete
         write (*,*) 'File deleted successfully!'
       else                                    ! Error if carry is set
         write (*,*) ' File not deleted!  Status= ', outregs.ax
       endif
       end

 Note: Using a similar method to call the INTDOS routine causes a
 "Protection Violation" under OS/2 and hanging under DOS. This occurs
 when compiling a program that uses the EQUIVALENCE statement to cause
 two variables defined as STRUCTUREs to occupy the same memory location
 and compiling with the /Zi option.  For additional information
 concerning this problem, query on the following words:

      INTDOS and PROTECTION VIOLATION and /Zi


 623. Compiling FORTRAN Programs in the M Editor

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_editor
 Last Modified: 11-JUL-1990    ArticleIdent: Q63536

 To compile Microsoft FORTRAN version 5.00 programs and view error
 messages within the M Editor, add the following lines to the TOOLS.INI
 file:

    extmake:.for.obj fl /c /nologo %|F
    Nextmsg:Shift+F3

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for MS-DOS and OS/2 and the Microsoft Editor version 1.02 for
 MS-DOS and OS/2.

 To compile a FORTRAN program that is loaded in the M Editor, type
 ALT+A, CTRL+F3. This will run a compilation according to the extmake
 switch above. In the extmake switch above, %|F tells the M Editor to
 compile the program that has been loaded. Other compile options can
 also be added to the extmake switch. If error messages are generated,
 they will appear at the bottom of the screen and the cursor will be
 placed at the corresponding error in the program. To move the cursor
 location to the next error message, press SHIFT+F3.

 At least 480K must be free before executing the M Editor when
 compiling FORTRAN programs that are loaded in the M Editor. A "D2027 :
 could not execute `C:\f1.exe'" error may occur if not enough memory is
 available. For more information on this topic, query on the following
 words:

      D2027 and M EDITOR

 Note: The /nologo compilation option is an undocumented option that
 stops the Microsoft copyright logo from appearing when compiling.
 Compiling programs in the M Editor under MS-DOS require use of the
 /nologo option; otherwise, the first error message will not be
 displayed. For more information on this problem, query on the word
 "NOLOGO".

 Additional information regarding compiling, invoking compilers and
 other utilities, and viewing error output can be found on Pages 44-47
 in the "Microsoft Editor User's Guide," which is included with FORTRAN
 version 5.00.


 624. Expression Too Complex on a CALL Statement in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  9-JUL-1990    ArticleIdent: Q63645

 In Microsoft FORTRAN version 5.00, "fatal error F1035: expression too
 complex, please simplify" is generated on the CALL statement when
 compiling the following FORTRAN program:

       CHARACTER*1 FILE8, FILE9, FILEA, FILEB
       CHARACTER*1 OUT1, OUT2, OUT3, OUT4, OUT5
       CHARACTER*1 TITLEE, TITLET
 C
       CALL IPEXP
      &  (DSFILE, DSOIL, EFFIRR, EXPTNO, FILE1, FILE2, FILE4, FILE5,
      &  FILE6, FILE7, FILE8, FILE9, FILEA, FILEB, IIRR, INSTE, ISIM,
      &  ISOILT, ISOW, ISWNIT, MTRT, NFEXP, NREP, NSFILE, NTRT,
      &  NWFILE, OUT1, OUT2, OUT3, OUT4, OUT5, PHINT, PLANTS, ROWSPC,
      &  RUNALL, RUNEND, SDEPTH, SITEE, THETAC, TITLEE, TITLET)
       END

 The following is the FL command line used to compile the FORTRAN
 program above and generate the "expression too complex" error:

    FL /c /Fs test.for

 The exact combination of variable declarations and CALL statement will
 generate the "expression too complex error." Rearranging the order of
 the variables in the CALL statement or in the declarations or changing
 the variable names will prevent this error from occurring.

 Microsoft is researching this problem and will post new information
 here as it becomes available.

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for MS-DOS and OS/2.

 Disabling optimization does not inhibit generation of the error "fatal
 error F1035: expression too complex, please simplify."

 For more information on the F1035 error, see Page 415 in the
 "Microsoft FORTRAN Reference" manual.


 625. Size Comparison Charts for FORTRAN 4.x and 5.00 Libraries

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  9-JUL-1990    ArticleIdent: Q63658

 The following tables include the sizes, in bytes, of the coprocessor,
 emulator, and alternate math libraries for Microsoft FORTRAN versions
 4.00, 4.01, 4.10, and 5.00. The libraries were built with and without
 C compatibility for the medium and large memory models, and for DOS
 and OS/2 as applicable.

 Note the following:

 1. All libraries listed below were built to include error message
    text. Subtract approximately 2.5K from the size of the library
    if error message text was not included.

 2. The libraries listed do not include compatibility with FORTRAN
    versions 3.20 and 3.30 (this option is available with FORTRAN
    versions 4.00, 4.01, and 4.10, but not version 5.00). Including
    3.20/3.30 compatibility increases the library size by approximately
    4K for the coprocessor and emulator libraries, and 6K for the
    alternate library.

 The following abbreviations are used in the tables below:

 L - Large memory model          7 - Coprocessor library
 M - Medium memory model         E - Emulator library
 R - Real mode (DOS)             A - Alternate library
 P - Protected mode (OS/2)

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 5.00 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------|-----------------------------|-----------------------------|
 | L  R | 205,741   218,541   218,287 | 186,173   198,973   199,745 |
 | L  P | 201,637   213,927   213,663 | 185,659   197,947   199,231 |
 |------|-----------------------------|-----------------------------|
 | M  R | 202,105   214,905   215,197 | 183,067   195,355   196,673 |
 | M  P | 198,003   210,293   210,575 | 182,553   194,841   196,159 |
 --------------------------------------------------------------------

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 4.10 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------------------------------------------------------------------|
 | L  R | 188,437   200,725   202,023 | 171,475   183,763   183,527 |
 | L  P | 185,389   197,679   198,967 | 171,995   184,283   183,535 |
 |------|-----------------------------|-----------------------------|
 | M  R | 184,807   197,095   198,937 | 168,371   180,659   180,455 |
 | M  P | 181,761   194,051   195,883 | 168,379   181,179   180,463 |
 --------------------------------------------------------------------

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 4.01 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------------------------------------------------------------------|
 | L  R | 185,955   197,731   197,821 | 167,933   179,709   177,749 |
 |------|-----------------------------|-----------------------------|
 | M  R | 181,813   193,589   194,223 | 164,317   176,605   174,677 |
 --------------------------------------------------------------------

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 4.00 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------------------------------------------------------------------|
 | L  R | 182,272   194,048   194,048 | 168,473   180,249   178,289 |
 |------|-----------------------------|-----------------------------|
 | M  R | 178,176   189,952   190,464 | 165,369   177,145   175,217 |
 --------------------------------------------------------------------


 626. Recursion Not Supported by FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 16-JUL-1990    ArticleIdent: Q63819

 Recursion is not supported by the Microsoft FORTRAN Optimizing
 Compiler. This information is stated in the following manuals:

 1. The "Microsoft FORTRAN Reference" manual for FORTRAN version 5.00
    on Pages 127, 172, 225, and 231

 2. The "Microsoft FORTRAN Optimizing Compiler Language Reference"
    manual for FORTRAN versions 4.00, 4.10, and 4.01 on Pages 174, 218,
    and 273

 3. The "ANSI X3.9-1978 FORTRAN 77" standard in Section 15.2 on
    Page 15-1

 This information applies to the Microsoft FORTRAN Optimizing Compiler
 versions 4.00, 4.01, 4.10, and 5.00 for MS-DOS and OS/2.

 The following is the information about support for recursion from
 Section 15.2 of the "ANSI X3.9-1978 FORTRAN 77" standard:

      A subprogram must not reference itself, either directly or
      indirectly.

 Direct recursion is when a subroutine calls itself. Page 231 of the
 "Microsoft FORTRAN Reference" manual for FORTRAN version 5.00 states
 that "any attempt at direct recursion results in a compile-time error
 [F2600: name : directly recursive]."

 Indirect recursion is when a subroutine calls another subprogram,
 which in turn calls the first subroutine before the first subroutine
 has completed execution. Page 231 of the "Microsoft FORTRAN Reference"
 manual for FORTRAN version 5.00 states that indirect recursion is not
 detected.


 627. /Zi and EQUIVALENCEing RECORD Variables Hangs Machine

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q63839

 In Microsoft FORTRAN version 5.00, you will receive a protection
 violation in OS/2 and will hang in DOS when you compile a program that
 uses the EQUIVALENCE statement to cause two variables specified as
 user-defined STRUCTUREs to occupy the same memory location and then
 compile with the /Zi option. The FORTRAN program listed below
 demonstrates this problem.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.

 The following is the Microsoft FORTRAN program that generates a
 protection violation in OS/2 and hangs in DOS when you compile with
 the /Zi option:

       structure /wordregs/          ! Full word registers
           integer*2 ax
       end structure

       structure /byteregs/          ! High and low registers
           integer*1 ah,al
       end structure

       record /wordregs/ inregs1
       record /byteregs/ inregs2

       equivalence (inregs1,inregs2) ! This statement causes the
                                     ! problem.
       end

 The sample program above is a fragment of a complete FORTRAN program
 that demonstrates how to use the C routines, INTDOS and INTDOSX to
 call MS-DOS interrupt 21 hex. Equivalencing the variables inregs1 and
 inregs2 allows accessing both the word and high-and-low bytes of the
 8086 general registers. For more information on how to use the INTDOS
 and INTDOSX routines, query on the following words:

    INTDOS and INTERFACE

 More information concerning the EQUIVALENCE and STRUCTURE statements
 can be found on Pages 164-166 and 228-229, respectively, in the
 "Microsoft FORTRAN Reference" manual.

 The /Zi option prepares for debugging with Microsoft CodeView
 debugger. More information concerning the /Zi option can be found on
 Pages 357-358 in the "Microsoft FORTRAN Reference" manual.


 628. Environment Variables in STARTUP.CMD in FORTRAN

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified: 23-JUL-1990    ArticleIdent: Q64018

 Contrary to what is stated in the "Microsoft FORTRAN Getting Started"
 booklet included with Microsoft FORTRAN version 5.00, SET statements
 for environment variables should not be included in the STARTUP.CMD
 file. These statements should be included in the CONFIG.SYS file, an
 OS2INIT.CMD file, or in another .CMD file that is executed before
 FORTRAN is used.

 The FORTRAN version 4.10 manuals do not contain this documentation
 error, but the information included below about setting up the
 environment also applies to version 4.10.

 Page 20 of the "Microsoft FORTRAN Getting Started" booklet included
 with FORTRAN 5.00 states the following:

    The environment-setting commands can be included in your
    AUTOEXEC.BAT or STARTUP.CMD file to ensure that the compiler
    environment is properly set up each time you reboot.

 This is correct for the DOS AUTOEXEC.BAT file but not for the OS/2
 STARTUP.CMD file. Both files are executed when a machine running their
 respective systems is booted, but the environment variables set in
 STARTUP.CMD are only recognized by the OS/2 screen group that executes
 the .CMD file. If another OS/2 screen group is started, STARTUP.CMD is
 not automatically executed and the environment set by it in the
 original screen group does not affect the new screen group.

 To ensure that the environment settings required by FORTRAN are set
 under OS/2, the PATH, SET LIB, SET TMP, SET INIT, and SET INCLUDE
 statements should be included in the CONFIG.SYS file, in an
 OS2INIT.CMD file, or in a .CMD file that is executed before working
 with FORTRAN.

 Environment variables can be set in the CONFIG.SYS file for OS/2
 versions 1.10 and later. The variables set there are recognized by
 each OS/2 screen group. This feature is not available in version 1.00
 of OS/2. In this case, an OS2INIT.CMD file can be used to set the
 environment.

 The OS2INIT.CMD file is the OS/2 equivalent to the DOS AUTOEXEC.BAT in
 terms of setting the environment for an OS/2 screen group. To use
 OS2INIT.CMD, the /K option for CMD.EXE must be included in the
 PROTSHELL statement of CONFIG.SYS.

 For example:

    PROTSHELL=... ... C:\0S2\CMD.EXE /K OS2INIT.CMD

 The file specified after the /K option is executed every time a new
 screen group is started. Any name can be used for the .CMD file.


 629. Multithreaded Programming Between FORTRAN 5.00 and C 5.10

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | S_C multiple threads
 Last Modified: 27-JUL-1990    ArticleIdent: Q64192

 Multithreaded programming between languages is not recommended, as
 stated on Page 51 of the "Microsoft FORTRAN Advanced Topics" manual
 for version 5.0. However, when certain guidelines are followed as
 outlined below, multithreaded programming between Microsoft FORTRAN
 version 5.00 and Microsoft C version 5.10 will work correctly.

 Use the following guidelines:

 1. I/O within a thread should be done only in the language that
    created the thread.

 2. The FORTRAN BEGINTHREAD, ENDTHREAD, and THREADID routines must
    be used for thread control in FORTRAN rather than the C
    _beginthread, _endthread, or _threadid routines.

 3. The OS/2 API calls DosCreateThread and DosExit should not be
    used with FORTRAN.

 The results are unpredictable if the above guidelines are not
 followed.

 The example below demonstrates multithread programming between FORTRAN
 5.00 and C 5.10. It will not function correctly with C 6.00 because of
 changes between C 5.10 and C 6.00.

 Pages 49-60 of the "Microsoft FORTRAN Advanced Topics" manual for
 version 5.0 contain additional information about OS/2 programming and
 threads with FORTRAN. The MTDYNA.DOC file that is included on the C
 5.10 Compiler 2 Disk contains similar information for C.

 The following code demonstrates how to include FORTRAN as a secondary
 thread. The FORTRAN subroutine fsub will perform input/output
 operations, so the thread containing fsub must be started from
 FORTRAN. The fthread subroutine begins the new thread. Notice that
 the FORTRAN subroutine can call C routines to access global variables
 or perform routine processing better handled by C.

 The output of the program below is as follows:

    Data received OK

 In this example the os2.lib and os2.h files were taken from the
 "Microsoft OS/2 Presentation Manager Toolkit."

 # ------------------ File test (MAKE file) ------------------

 test.obj: test.c
    cl -Zi -c -G2sw -FPi -Alfw test.c

 fsub.obj: fsub.for
    fl -Zi -c -G2sw -FPi -MT fsub.for

 test.exe: test.obj fsub.obj
    link /NOE /NOD /CO test+fsub, /align:16,,  \
    llibfmt+llibcmt+os2,test.def

 // ----------------- File test.c (Main Program) --------------------

 #define INCL_DOSPROCESS
 #include <os2.h>
 #include <mt\process.h>
 #include <mt\stdio.h>
 #include <mt\stdlib.h>

 short    n1=12, n2=6, n3=16, n4=8;
 ULONG    MySemaphore;

 void main(void);
 void far pascal fthread(void far *);
 void fdone(void);
 void getdat(short *,short *,short *,short *);

 void main()
 {
    BYTE     *abStack;

    DosSemSet(&MySemaphore);
    abStack = (BYTE *) malloc(8192);
    fthread(abStack);
    /*             ...
          Go about other business here
                   ...                     */
    DosSemWait(&MySemaphore,SEM_INDEFINITE_WAIT);
    if (abStack != NULL) free(abStack);
 }

 void fdone()
 {
    DosSemClear(&MySemaphore);
 }

 void getdat(i1, i2, i3, i4)
 short *i1, *i2, *i3, *i4;
 {
    *i1 = n1;
    *i2 = n2;
    *i3 = n3;
    *i4 = n4;
 }

 C --------------- File fsub.for (FORTRAN subroutines) --------------

       INTERFACE TO INTEGER*2 FUNCTION BEGINTHREAD(RTN,STK,SIZE,ARG)
       INTEGER*4      RTN [VALUE]
       INTEGER*1      STK(*)
       INTEGER*4      SIZE
       INTEGER*4      ARG
       END

       INTERFACE TO SUBROUTINE ENDTHREAD()
       END

       INTERFACE TO SUBROUTINE FDONE [C] ()
       END

       INTERFACE TO SUBROUTINE GETDAT [C] (N1,N2,N3,N4)
       INTEGER*2         N1 [REFERENCE]
       INTEGER*2         N2 [REFERENCE]
       INTEGER*2         N3 [REFERENCE]
       INTEGER*2         N4 [REFERENCE]
       END

       subroutine fthread(stack)
       integer*1   stack(*)
       integer*2   tid, beginthread
       external    fsub
       tid = beginthread(LOCFAR(fsub),stack,8192,0)
       return
       end

       subroutine fsub()
       logical     dataok
       integer*2   n1, n2, n3, n4
       call getdat(n1, n2, n3, n4)
       dataok = (n1 .eq. 12 .and. n2 .eq. 6 .and. n3 .eq. 16 .and.
      1          n4 .eq. 8)
       if (dataok) then
          write(*,*) 'Data received OK'
       else
          write(*,*) 'Data NOT received OK'
       endif
       call fdone
       call endthread()
       end

 ; ---------------- File test.def (DEFINITIONS file) -----------------

 NAME TEST WINDOWCOMPAT
 PROTMODE
 CODE LOADONCALL
 DATA LOADONCALL NONSHARED


 630. BASIC Code in FORTRAN 5.00 Advanced Topics Manual Is Incorrect

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr B_QuickBas B_BasicCom
 Last Modified:  1-AUG-1990    ArticleIdent: Q64318

 The example on Page 90 of the "Microsoft FORTRAN Advanced Topics"
 manual for version 5.0 has omitted some required BASIC source code.

 If the BASIC code is compiled as suggested, and then linked to the
 FORTRAN subroutine, running the program produces the following error:

    run-time error F6700
    - heap space limit exceeded

 This error occurs because the FORTRAN subroutine does not have any
 heap space set up for it to use. This must be done in the BASIC code
 by adding the following lines:

    DIM HEAP%(2048)
    COMMON SHARED /nmalloc/ HEAP%()

 This will declare a heap size of 2K for FORTRAN to use.

 The following is the corrected code for the BASIC main:

 ' BASIC source
 '
 DIM HEAP%(2048)
 COMMON SHARED /nmalloc/ HEAP%()
 '
 DEFINT A-Z
 DECLARE SUB Fprog ()
 CALL Fprog
 END
 '
 FUNCTION Dbl (N) STATIC
      Dbl = N*2
 END FUNCTION
 '
 SUB Printnum (A,B) STATIC
      PRINT "The first number is ";A
      PRINT "The second number is ";B
 END SUB


 631. SYS2070 Error with FORTRAN Dynamic-Link Libraries

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | sys 2070 DLL
 Last Modified:  3-AUG-1990    ArticleIdent: Q64447

 The error below occurs when running a Microsoft FORTRAN program that
 uses dynamic-link libraries and has been linked using the /NOI switch.
 The error may also occur if there are bad sectors on the hard disk or
 if a library is corrupt.

    SYS2070: The system could not demand load the
    application's segment.

 To alleviate this error, do not link with the /NOI switch or rebuild
 the library.

 The program below demonstrates the error when compiled and
 linked as follows:

 FL /MD /c sample.for
 LINK sample frtexe.obj,,,frtlib doscalls /NOI;

       PROGRAM SAMPLE
       WRITE(*,*) 'HELLO WORLD'
       END

 The above program generates the following error when run:

    SYS2070: The system could not demand load the
    application's segment.  FRTLIB __FFwr is in error.

 FRTLIB.LIB and FRTLIB.DLL were created by running the FDLLOBJS.CMD
 file that is included on the OS/2 Support 1 Distribution Disk for
 FORTRAN. FRTEXE.OBJ and DOSCALLS.LIB are also included with FORTRAN.

 To run the program, FRTLIB.DLL must reside in a directory that is
 pointed to by the LIBPATH variable in the CONFIG.SYS file.

 For more information about dynamic-link libraries and FORTRAN, see
 Pages 61-70 of the "Microsoft FORTRAN Advanced Topics" manual for
 version 5.0.


 632. Internal Compiler Error: getattrib.c:1.4, Line 174 in FORTRAN

 Product Version(s): 5.00    | 5.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist5.00 SR# S900727-117
 Last Modified: 14-AUG-1990    ArticleIdent: Q64596

 The code below generates the following error:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)getattrib.c:1.4', line 174).

 The error is produced when a program contains the following:

 1. The AUTOMATIC statement

 2. A structure variable that has an array as an element

 3. An implicit READ or WRITE of the array structure element

 The following code produces the error:

          AUTOMATIC

          STRUCTURE /struc/
            INTEGER var(2)
          END STRUCTURE

          RECORD /struc/ test

          READ(*,*) test.var

          END

 To work around this problem, either remove the AUTOMATIC statement or
 do not read or write the array implicitly.

 Microsoft has confirmed this to be a problem in the FORTRAN compiler
 version 5.00. We are researching this problem and will post new
 information here as it becomes available.


 633. $FREEFORM Allows Lines to Be 80 Characters Long in FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | docerr buglist5.00
 Last Modified:  9-JAN-1991    ArticleIdent: Q64611

 The standard format for lines in Microsoft FORTRAN allows for
 characters in columns 1 through 72. By using the $FREEFORM metacommand
 with FORTRAN versions 4.00, 4.01, 4.10, and 5.00, lines may have
 characters in columns 1 through 80. The limit is column 79 if the last
 character in the line is an apostrophe or single quotation mark (').

 The allowed line length in source code with the $FREEFORM metacommand
 is not explicitly stated in the FORTRAN manuals. Section 2.3,
 "Free-Form Source Code," on Page 46 in the "Microsoft FORTRAN
 Reference" manual for version 5.0 states that most of the rules
 applying to line formatting in Section 2.1 do not apply to free-form
 code. The rules state that any characters in column 73 and above are
 ignored. With the $FREEFORM metacommand characters in column 81 and
 above are ignored.

 The following code will demonstrate the limit:

 $FREEFORM

 aa  = 1
 aaa = 2

 WRITE (*,*)                     aaa !aaa starts in column 79
 END

 This program prints a "1" because the third "a" in the variable name
 is ignored.

 An exception to the 80-character length limit occurs when the last
 character in the line is an apostrophe or single quotation mark (').
 When this is the case, the compiler only accepts 79 characters on a
 line.

 Consider the following code:

 $FREEFORM

 WRITE (*,*)             'The closing quotation mark is in column 80'
 END

 When this code is compiled the following error is generated:

    ...error F2031 : closing quote missing


 634. $STORAGE:2 Causes Incorrect RETURN from a SUBROUTINE

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | STORAGE return
 Last Modified: 16-AUG-1990    ArticleIdent: Q64847

 When a subroutine contains the $STORAGE:2 metacommand, a RETURN to an
 alternate return label will fail if the subroutine is in a separate
 file from the calling routine and the calling routine does not contain
 $STORAGE:2. This is caused by the inconsistent use of the $STORAGE:2
 metacommand. This error occurs under both DOS and OS/2, and only
 occurs in version 5.00 of Microsoft FORTRAN.

 Removing the $STORAGE:2 metacommand from the subroutine file, placing
 the subroutine in the same file as the calling routine, or placing the
 $STORAGE:2 metacommand in the calling-routine file corrects the
 problem. Optimization has no affect on this error.

 This problem occurs because the alternate return labels are considered
 to be integer arguments of a subroutine call, and thus fall under the
 control of the $STORAGE metacommand.

 Page 126 of the "Microsoft FORTRAN Reference" manual for version 5.0
 states in the "NOTE" section that there must be type agreement between
 the integer arguments of a subroutine and a calling program. To
 guarantee that the alternate return label types agree, the $STORAGE
 metacommand must be the same in both the calling routine and the
 subroutine files. A warning about the usage of $STORAGE with source
 code in multiple files is also found on Page 308 of the "Microsoft
 FORTRAN Reference" manual.

 The code listed below illustrates the problem:

 FILE 1:
 ------

       CALL SUB1 (*10)
       STOP '*10 DID NOT WORK'
 10    STOP '*10 DID WORK'
       END

 FILE 2:
 ------

 $STORAGE:2
       SUBROUTINE SUB1 (*)
       RETURN 1
       END

 The above program will print to the screen as follows:

 *10 DID NOT WORK

 If $STORAGE:2 is removed from FILE 2 or added to FILE 1, the program
 will print as follows:

 *10 DID WORK

 The program will also work correctly if the subroutine is placed in
 the same file.


 635. Undocumented FORTRAN Error "F2347: Missing Type"

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# G900201-54
 Last Modified: 16-AUG-1990    ArticleIdent: Q64848

 If IMPLICIT NONE is specified in a program, then all user-defined
 names must be explicitly typed.

 An untyped name causes the following undocumented compile-time error:

    F2347: missing type

 The program below demonstrates this error:

       implicit none
       x = 3
       end

 f2347.for(2) : error F2347: X : missing type

 To alleviate the error, declare the variable as in the following
 program:

       implicit none
       integer*4 x
       x = 3
       end


 636. Accessing Command-Line Arguments with FORTRAN

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | appnote HF0220
 Last Modified: 28-AUG-1990    ArticleIdent: Q65236

 An application note called "Accessing Command-Line Arguments with
 FORTRAN," which explains how to access the command-line arguments
 under Microsoft FORTRAN versions 4.00, 4.01, and 4.10, is available
 from Microsoft Product Support Services by calling [phone].

 This article contains the same information as the application note.
 Below is the code for the following FORTRAN files.

 Filename      Description
 --------      ------------

 PSPTST.FOR    Main program that contains the INTERFACE to DMPCMD and
               calls DMPCMD

 DMPCMD.FOR    Subroutine that prints the contents of the command line

 Note: DMPCMD must be compiled in a separate source file.

 How to Use PSPTST
 -----------------

 Use the following command to compile the two programs:

    FL PSPTST.FOR DMPCMD.FOR

 If PSPTST is invoked with a command line such as

    PSPTST hello

 the output will be as follows:

    < hello>

 In FORTRAN version 5.00, command-line arguments can be accessed using
 the NARGS function and the GETARG procedure described on Page 271 of
 the "Microsoft FORTRAN Reference" manual for version 5.00.

 The PSPTST Program
 ------------------

 c The INTERFACE statement is used to pass the addresses of the start
 c of the command line and the number of characters in the command line
 c to the separately compiled subroutine, DMPCMD, by value, instead of
 c by reference. The variables are passed by value because they are
 c themselves addresses. The DMPCMD subroutine is compiled separately
 c so that it will accept its arguments by reference. This results in
 c the two passed addresses being properly "dereferenced."
 c
       INTERFACE TO SUBROUTINE DMPCMD( II,JJ )
       INTEGER*4 II [VALUE], JJ [VALUE]
       END
 c
 c --------------------------------------------------------------------
       PROGRAM PSPTST
       INTEGER*4 PSP, PSPNCH, OFFSET
 c --------------------------------------------------------------------
 c The method used in this program will work only if the Program
 c Segment Prefix precedes the main program, which it will by
 c default. Since the PSP starts 16 paragraphs (256 bytes) before
 c the main program, the first step is to load the variable OFFSET
 c with the hex value 0010:0000, as follows:
 c
       OFFSET = #00100000
 c --------------------------------------------------------------------
 c Use LOCFAR to find the segment:offset of the main program:
 c
       PSP = LOCFAR(PSPTST)
 c --------------------------------------------------------------------
 c To set PSP so that it points to the start of the text of the
 c command line, do the following:
 c
 c 1. Zero out the offset portion of the address in variable PSP.
 c
 c 2. Subtract 16 paragraphs from the segment:offset.
 c
 c 3. Add hex 81 so that PSP now points to the start of the text of the
 c    command line:
 c
       PSP = (PSP-MOD(PSP,#10000))-OFFSET+#81
 c --------------------------------------------------------------------
 c PSPNCH points to the byte (80 hex) in the PSP that contains the
 c length of the command line:
 c
       PSPNCH = PSP-1
 c --------------------------------------------------------------------
 c Call DMPCMD to list out the command line:
 c
       CALL DMPCMD(PSP, PSPNCH)
       END

 The DMPCMD Subroutine
 ---------------------

 Note: Compile this routine in a file separate from PSPTST.

       SUBROUTINE DMPCMD(CMDLIN, N)
       CHARACTER*80 CMDLIN
       INTEGER*1 N
 c
 c Write out N characters from CMDLIN (N is PSP+80 hex; CMDLIN is
 c PSP+81 hex).
 c
       WRITE (*,*) '<',CMDLIN(:N),'>'
       RETURN
       END


 637. Compiler Errors F1002, F1901, R6000 Using Large Namelists

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  3-OCT-1990    ArticleIdent: Q65047

 In the code sample below, errors are produced when a READ operation is
 performed on a namelist that contains more than 99 variables.

 If the namelist contains

    100 - 106 variables

 the following errors are produced:

    F1002: out of heap space
    R6000 - stack overflow

 If the namelist contains

    107 - 117 variables

 the machine hangs under DOS or produces a protection violation under
 OS/2. If the namelist contains

    118 + variables

 the error is as follows:

    F1901: program too large for memory

 If the READ in the code below is changed to a WRITE, the errors are
 the same, except when the namelist contains 104 - 106 variables under
 OS/2. In this case, the screen group running the compiler will hang.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code will produce the errors:

       NAMELIST /test/
      * a001,a002,a003,a004,a005,a006,a007,a008,a009,a010
      *,a011,a012,a013,a014,a015,a016,a017,a018,a019,a020
      *,a021,a022,a023,a024,a025,a026,a027,a028,a029,a030
      *,a031,a032,a033,a034,a035,a036,a037,a038,a039,a040
      *,a041,a042,a043,a044,a045,a046,a047,a048,a049,a050
      *,a051,a052,a053,a054,a055,a056,a057,a058,a059,a060
      *,a061,a062,a063,a064,a065,a066,a067,a068,a069,a070
      *,a071,a072,a073,a074,a075,a076,a077,a078,a079,a080
      *,a081,a082,a083,a084,a085,a086,a087,a088,a089,a090
      *,a091,a092,a093,a094,a095,a096,a097,a098,a099,a100
      *,a101,a102,a103,a104,a105,a106,a107,a108,a109,a110
      *,a111,a112,a113,a114,a115,a116,a117,a118,a119,a120

       READ (*,test)
       END

 The workaround to this problem is to reduce the size of the namelist.
 This can be accomplished by either splitting the namelist into
 multiple smaller namelists or by grouping variables of similar type
 together using arrays.

 The following code uses an array instead of individual variables:

       real a(120)
       namelist/test/ a

       read (*,test)
       end


 638. IMAGESIZE_W Type Definition Is Incorrect in FGRAPH.FD

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist5.00
 Last Modified: 22-AUG-1990    ArticleIdent: Q65048

 The graphics function IMAGESIZE_W is incorrectly typed in the
 FGRAPH.FD include file for Microsoft FORTRAN version 5.00. The
 function is typed as INTEGER*2 instead of INTEGER*4. It is typed
 correctly in both the "Microsoft Advanced Topics" manual and the
 FGRAPH.FI include file.

 When compiling a program that references IMAGESIZE_W, the following
 error is generated:

    F2220: IMAGESIZE_W : length redefined

 This error can be corrected by changing the line in the FGRAPH.FD file
 that reads

    INTEGER*2 IMAGESIZE_W

 to the following:

    INTEGER*4 IMAGESIZE_W

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 639. F2124: CODE GENERATION ERROR with Adjustable Arrays and $LARGE

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 22-AUG-1990    ArticleIdent: Q65049

 The error

    F2124: CODE GENERATION ERROR

 occurs when using adjustable-sized, three-dimensional arrays and the
 huge memory model with Microsoft FORTRAN version 5.00. Compiling with
 the /Od option will eliminate this error. Changing the order and size
 of the subscripts may also eliminate this error.

 The following sample code generates error F2124 when compiled with the
 /AH switch or $LARGE metacommand:

       SUBROUTINE X( a,b,i,j,m )
       DIMENSION a(m,2,2), b(2,m,2)

       a(i,2,1) = b(j,i,2)

       RETURN
       END

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 640. Problems Indexing Arrays with INTEGER*1 Variables

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  5-SEP-1990    ArticleIdent: Q65414

 Erroneous results can be generated when using an INTEGER*1 variable to
 index an array. Changing the index to an INTEGER*2 variable, or
 compiling with the /4Yb switch will correct the problem.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The sample code below generates improper values when compiled using
 FORTRAN version 5.00. The error occurs when the compiler calculates
 the offset of certain array elements. If the number of bytes per
 element is a power of two, the compiler uses a shift instruction to
 multiply the index, calculating the element's offset from the
 beginning of the array.  Depending on the number of shifts and the
 initial value of the index, bits may be lost and/or shifted into the
 sign bit, resulting in incorrect offset values.

 The following is a sample code:

          integer*1 k
          integer*2 iarray(100)

          iarray = 0

          do k=1,100
             write(*,*) iarray(k)
          enddo
          end

 The screen output appears as follows:

        0
        .
        .
        .
        0     ( 63 zeros )
    25972
    26998
     3376
    12336
    29807
     8296
        .
        .
        .

 This example runs correctly when compiled with the /4Yb option.


 641. FORTRAN Err Msg: R6001 Null Pointer Assignment Using Namelist

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 24-SEP-1990    ArticleIdent: Q65607

 The compile time error

    run-time error R6001
    - null pointer assignment

 is generated when a NAMELIST group name is declared as a variable or
 is initialized as a variable before the NAMELIST is defined.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 When the code below is compiled with Microsoft FORTRAN version 5.00, a
 null pointer assignment is generated:

       a=1
       NAMELIST /a/ b   ! 'a' is already a variable name
       END


 642. Incorrect Use of Structure Variable Hangs Compiler

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 24-SEP-1990    ArticleIdent: Q65608

 Compiling code that attempts to access an undefined element of a
 STRUCTURE hangs your machine under DOS and causes a protection
 violation under OS/2. The compiler should display the following:

    error F2509:  (element): not an element of (name)

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 When you compile with Microsoft FORTRAN version 5.00, the following
 code hangs the machine under DOS and causes a protection violation
 under OS/2:

       STRUCTURE /a/
          INTEGER b
       END STRUCTURE
       RECORD /a/ c

       c.b = c.b.d    ! b.d is not an element of c

       END


 643. PAUSE Command with Input Redirection in FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-NOV-1990    ArticleIdent: Q67098

 Beginning with Microsoft FORTRAN version 4.00, the PAUSE command
 allows you to execute operating system commands while program
 execution is suspended. When program input is redirected from the
 keyboard to a file, the PAUSE statement does not work correctly if the
 program READs from the redirection file or if the program contains
 multiple PAUSE statements.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.x
 and 5.00. We are researching this problem and will post new
 information here as it becomes available.

 When input is redirected from a file and the only data read from the
 file is one DOS command for a PAUSE statement, the program works
 correctly. The following short program gives an example:

 Code, TEST.FOR:

       write(*,*) 'Before PAUSE'
       pause
       write (*,*) 'After PAUSE'
       end

 Data file, TEST.DAT:

    Ver

 Command line:

    C:\> TEST < TEST.DAT

 Output:

    Before PAUSE
    Pause - Please enter a blank line (to continue) or a
      DOS command.

    MS-DOS Version x.xx

    After PAUSE

 If another PAUSE statement is added to the program, only the command
 for the first PAUSE is executed. The program appears to read to the
 end of the redirection file when it encounters the first PAUSE. If a
 READ statement is added to the program after the PAUSE statement, as
 in the next example, the program again reads to the end of the file.
 In this case, ERROR 6501 is generated.

 Code:

       integer i
       write(*,*) 'Before PAUSE'
       pause
       write (*,*) 'After PAUSE'
       read(*,*) i
       write (*,*) i
       end

 Data:

    Ver
    1

 Output:

    Before PAUSE
    Pause - Please enter a blank line (to continue) or a
      DOS command.

    MS-DOS Version x.xx

    After PAUSE
    run-time error F6501: READ(CON)
    - end of file encountered

 When the READ statement is before the PAUSE statement, the DOS command
 is not executed:

 Code:

       integer i
       read(*,*) i
       write (*,*) i
       write(*,*) 'Before PAUSE'
       pause
       write (*,*) 'After PAUSE'
       end

 Data:

    1
    Ver

 Output:

              1
    Before PAUSE
    Pause - Please enter a blank line (to continue) or a
      DOS command.

    After PAUSE

 These problems are caused by the PAUSE command not reading data from
 the redirection file in the same way a READ statement would.

 Workarounds
 -----------

 Do not use redirection on a program with more than one PAUSE
 statement or a combination of PAUSE and READ statements.

 Use the OPEN command to open a file to be used for input
 for READ statements.

 Use calls to the C functions SYSTEM or SPAWNLP instead of PAUSE
 statements to execute DOS commands. For more information on these
 functions, see page 86 of the "FORTRAN Advanced Topics" manual for
 version 5.00 or the DEMOEXEC.FOR program included with versions 4.x
 and 5.00 of FORTRAN.

 This problem does not occur in earlier versions of FORTRAN because the
 functionality of the PAUSE statement is different. In earlier
 versions, you are not allowed to execute DOS commands after a PAUSE.


 644. Problems Initializing Structure Arrays in DATA Statements

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-NOV-1990    ArticleIdent: Q67150

 Initializing indexed structures in DATA statements can produce the
 following compiler error in Microsoft FORTRAN when the DATA statement
 contains an implied DO-list and the structure contains an array as an
 element:

    F2414: DATA : not array-element name

 The following error occurs when the DATA statement contains an implied
 DO-list and the structure variable is an array:

    F2409: nonstatic address illegal in initialization

 The following errors occur when the array is specified without an
 index and the necessary amount of data to fill the array is then
 specified:

    F2537: VAR : array subscripts missing
    F4400 warning: DATA : more constants than names

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code produces the compiler error

    F2414: DATA : not array-element name

 when a structure with an indexed element is initialized in a DATA
 statement with an implied DO-list. The commented DATA statement works
 correctly.

       INTEGER i

       STRUCTURE /struct/
          integer var(3)
       END STRUCTURE

       RECORD /struct/ test

       DATA (test.var(i), i=1,3) / 1, 2, 3 /

 C     DATA test.var(1), test.var(2), test.var(3) / 1, 2, 3 /

       write(*,*) test.var

       END

 The following code produces the compiler error

    F2409: TEST : nonstatic address illegal in initialization

 when an indexed structure is initialized in a DATA statement with an
 implied DO-loop. The commented DATA statement works correctly.

       INTEGER i

       STRUCTURE /struct/
          integer var
       END STRUCTURE

       RECORD /struct/ test(3)

       DATA (test(i).var, i=1,3) / 1, 2, 3 /

 C     DATA test(1).var, test(2).var, test(3).var / 1, 2, 3 /

       write(*,*) test.var

       END

 The following code produces the compiler error and warning

    F2537: VAR : array subscripts missing
    F4400 warning: DATA : more constants than names

 when no index is specified for a structure variable array or a
 structure element that is an array, and the necessary amount of data
 to fill the array is then specified. The commented DATA statement
 works correctly.

       INTEGER i, dummy_array(3)

       STRUCTURE /struct/
          integer var(3)
       END STRUCTURE

       RECORD /struct/ test

       DATA test.var / 1, 2, 3 /

 C     DATA dummy_array / 1, 2, 3 /

       write(*,*) test.var

       END

 Workarounds
 -----------

 Use a DO-loop and assignment statements.

 List each structure element in the DATA statement rather than using an
 implied DO-list.

 Use a DO-loop to READ in each element from a file. This last option
 does not work when the structure variable is an array. Reading a
 structure element in this case produces error F2725. For more
 information about this error, query on the following word:

    F2725

 Note: Using the patched version of F1.EXE and disabling optimization
 have no effect. For more information on the FORTRAN 5.00 patch, query
 on the following word:

    FORPATCH.ARC


 645. Compiler Errors in INCLUDE Files Not Flagged in Listing File

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-NOV-1990    ArticleIdent: Q67167

 When a compiler error occurs in an INCLUDE file, the compiler error
 messages do not appear in the source listing file generated by the
 Microsoft FORTRAN version 5.00 compiler. However, the total number of
 detected errors tallied at the end of the listing file is correct.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 When the FL command is issued with the /Fs option, a source listing
 file is created that should contain any compiler errors next to the
 line of source code that generated the error. The errors are also sent
 to the screen and subsequently to the M editor, if compilation is
 being done from within the editor. If a compiler error is generated on
 a source line in an INCLUDE file, the error is correctly flagged on
 output to the screen and consequently to the editor, but not correctly
 inserted into the source listing file.

 In the following code, the INCLUDE file has one error (which is not
 flagged in the listing file), and the program source file has one
 error to demonstrate how the listing file should flag errors.

 Source file (foo.for):

       program main
       include 'test'
       write(*,*) 'This is a test'
       writ(*,*) 'This is also a bad line'
       end

 Include file (test):

       writ(*,*) 'This is a bad line'

 List file:

 PAGE   1

 11-14-90

 03:09:12

  Line#  Source Line          Microsoft FORTRAN Optimizing Compiler
 Version 5.00

      1        program main
      2        include 'test'
       ***** Begin listing of: test
      1        writ(*,*) 'This is a bad line'
       ***** End listing of: test
      3        write(*,*) 'This is a test'
      4        writ(*,*) 'This is also a bad line'
 ***** foo.for(4) : error F2115: syntax error
      5        end

 2 errors detected


 646. F1001: Internal Compiler Error, ctypes.c: with ICHAR Function

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 28-NOV-1990    ArticleIdent: Q67168

 When a nonarray character string is incorrectly used as an
 array in the ICHAR function, the following error is generated:

    F1001: Internal Compiler Error

 The compiler file listed depends on the version of FORTRAN used. The
 following are the different compiler files and line numbers listed
 by the errors generated by the different versions of FORTRAN:

    (compiler file @(#)ctypes.c:1.11, line 448)
       with FORTRAN 5.00,

    (compiler file @(#)ctypes.c:1.89, line 428)
       with FORTRAN 4.10,

    (compiler file @(#)ctypes.c:1.88, line 428)
       with FORTRAN 4.01,

    (compiler file @(#)ctypes.c:1.80, line 426)
       with FORTRAN 4.00.

 The following error should be generated:

    F2512: argument list illegal.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.10.
 We are researching this problem and will post new information here as
 it becomes available.

 The following sample code produces this error:

       CHARACTER*5 strg

       ival = ICHAR(strg(j))

       END

 Note that "strg" is a nonarray character string and the ICHAR function
 is attempting to reference "strg" as an array. This error could be
 caused by incorrectly trying to reference a single character of
 "strg." To reference a single character, the ICHAR statement would
 have the following form:

    ival = ICHAR(strg(j:j))

 Substring manipulation is discussed on pages 17 and 18 of the
 "Microsoft FORTRAN Reference" manual for version 5.00 in the Elements
 of FORTRAN chapter.

 Also, if the character string "strg" is changed to CHARACTER*4 or
 less, the program compiles without an error, even though it still
 should generate a F2512 error.


 647. How to Avoid the "Program Too Large for Memory" FORTRAN Error

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 27-NOV-1990    ArticleIdent: Q67194

 When you attempt to run a very large program in DOS, the error
 "Program Too Large For Memory" may occur. MS-DOS runs in real mode,
 which does not allow more than 640K of memory for applications. This
 article discusses possible methods to circumvent this limitation.
 These methods include using the OS/2 operating system instead of DOS,
 direct-access disk file(s) for data storage, ALLOCATABLE arrays, and
 overlays.

 Using Expanded and Extended Memory with Microsoft FORTRAN
 ---------------------------------------------------------

 Some DOS applications can use an expanded memory manager (EMM) driver
 program and expanded memory board(s) to access memory beyond the 1 MB
 limit of conventional memory. Microsoft FORTRAN, however, does not
 have the capability to use expanded memory. It can utilize extended
 memory (above 1 MB), but only when used with the OS/2 operating system
 and protected mode libraries. Extended memory is the term used to
 refer to the memory at physical addresses above 1 MB that can be
 accessed by an 80286 or 80386 CPU in protected mode.

 Using a Direct Access Disk File to Store Large Amounts of Data
 --------------------------------------------------------------

 A disk drive can be used to store large amounts of data in a direct-
 access disk file, thus freeing up the memory that would otherwise be
 used by the data. By using a direct-access file, records can be read
 from or written to in any order, simulating the use of an array. If
 expanded or extended memory is available, it can be used for a RAM
 drive. By using a RAM drive, I/O access to the data is much faster
 than when using a fixed disk drive.

 Using Allocatable Arrays in FORTRAN Version 5.00
 ------------------------------------------------

 An ALLOCATABLE array is an array that is dynamically sized at run time
 by using the ALLOCATE statement and the ALLOCATABLE attribute (see
 pages 21-25 of the "Microsoft FORTRAN Reference" manual). The ALLOCATE
 statement (see pages 113-114 of the "Microsoft FORTRAN Reference"
 manual) establishes the upper and lower bounds of each ARRAY dimension
 and reserves sufficient memory. The array can then be DEALLOCATED at
 run time by using the DEALLOCATE statement (see page 143 of the
 "Microsoft FORTRAN Reference" manual) to free memory for use by other
 arrays.

 For example:

   INTEGER data [ALLOCATABLE] (:,:)
   INTEGER error
   DATA i, j / 10,50 /
   ALLOCATE (data (i,j), STAT=error)

   DEALLOCATE (data, STAT=error)

 Using Overlays in FORTRAN Versions 4.00, 4.01, 4.10, and 5.00
 -------------------------------------------------------------

 Overlays (see pages 366-367 of the "Microsoft FORTRAN Reference"
 manual for versions 5.00 and pages 258-260 of the "Microsoft FORTRAN
 CodeView and Utilities User's Guide") allow several program modules to
 use the same memory area. When needed, a module or group of modules is
 loaded into memory from the disk. Module access time can be shortened
 if a RAM drive is used to store the executable. Modules that are to be
 overlaid are enclosed in parentheses. CODE (but NEVER DATA) is
 overlaid. Note: If the program consists of mostly DATA, then this
 procedure will be of little help.

 The following example is for versions 4.00, 4.01, 4.10, and 5.00:

    At LINK command line: LINK A (B C) (E F)

    Object modules B and C are swapped in and out of the same memory for
    Object modules E and F. Note: Object modules in parentheses are
    overlaid together so that they will be loaded into memory at the
    same time.

 The following example is for versions 4.10 and 5.00:

    At FL command line: FL MAIN.FOR (OVER1.FOR) (OVER2.FOR)

    FORTRAN code modules OVER1 and OVER2 are swapped in and out of the
    same memory location.


 648. Using ANSI Escape Sequences to Clear the Screen

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                             | OS/2
 Flags: ENDUSER |
 Last Modified: 27-NOV-1990    ArticleIdent: Q67195

 An ANSI escape sequence can be used within a FORTRAN program to clear
 the screen. Programs can use a subset of the ANSI 3.64-1979 standard
 escape sequences to erase the display, set the display mode and
 attributes, and control the cursor in a hardware-independent manner.

 In real mode, the ANSI.SYS device driver is used to support ANSI
 escape sequences. It is installed in the CONFIG.SYS file with the
 following command:

    DEVICE=[drive:][path]ANSI.SYS

 In protected mode, support for ANSI escape sequences come from an OS/2
 AVIO ("advanced video input/output") function.

 An ANSI escape sequence is a sequence of ASCII characters, the first
 two of which must be the escape character (char(27)) and the
 left-bracket character ([). The characters following the escape and
 left-bracket characters vary with the type of control function being
 performed.

 An escape sequence cannot be entered directly at the system prompt
 because each ANSI escape sequence must begin with an escape character.
 If you press the ESC key, MS-DOS cancels the command line.

 The following program uses the ANSI escape sequence (ESC[2J) to clear
 the screen:

       character*1 clrstr(4)
       data clrstr /' ','[','2','J'/
       clrstr(1) = char(27)            ! Escape character (ASCII 27).
       write (*,'(1x,4a1\)') clrstr    ! You must use a 1x as the first
       end                             ! part of the format specifier
                                       ! to ensure output of escape
                                       ! character.

 The CHAR(int) intrinsic function is used to form either printing or
 nonprinting characters using the corresponding integer from the ASCII
 table.


 649. Problem with Character*(*) Length Specifier in FORTRAN

 Product Version(s): 4.00 5.00 | 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 30-NOV-1990    ArticleIdent: Q67227

 In a Microsoft FORTRAN version 4.00 or 5.00 program, invalid output
 can be generated in a subroutine that accepts a character string with
 the CHARACTER*(*) length specifier. For the error to occur, the
 following conditions must also exist:

 1. There must be at least one initial CALL to a subroutine in which a
    character argument is passed.

 2. The CALL to the subroutine that produces invalid output must
    contain, as its first actual argument, a reference to a function.
    This function must accept a character argument. The length of the
    character argument it accepts must be different than the length of
    the character argument passed as the second actual argument in the
    faulty subroutine.

    Note: In this situation, the second formal argument to the
    subroutine, which is typed as CHARACTER*(*), assumes the length of
    the character string from the function reference, instead of the
    correct length.

 The following example produces the invalid output:

       integer*4 IFUN
       character*1 C1
       character*2 C2
        c2='xy'
        call sub1(c1)
        call sub2(IFUN(c1),c2)    ! line 7
       end
 C
       subroutine sub1(x)
        character *(*) x
       end
 C
       subroutine sub2(i,c)
        character *(*) c
        integer i
        print*,c             ! prints "x" instead of "xy"
        print*,len(c)        ! prints 1 instead of 2
       end
 C
       integer*4 function IFUN(c)
        character*(*) c
        IFUN=0
       end

 The actual length being returned for c2 is the length of c1.

 In Microsoft FORTRAN version 5.00, the compiler leaves out an assembly
 code line passing the length of the character string to the second
 subroutine. Versions 4.1 and 4.01 retain this assembly code and work
 correctly. Version 4.00 has many differences at the assembly level
 and nothing can be concluded.

 Note: The /Od switch does not affect this code.

 A possible solution would be to replace line 7 with one of
 the following:

 1. Switch the order of the following arguments:

       call sub2(c2,IFUN(c1))

 2. Use an intermediate variable, as follows:

       j=IFUN(c1)
       call sub2(j,c2)

 Microsoft has confirmed this to be a problem in FORTRAN
 versions 4.00 and 5.00. We are researching this problem and
 will post new information here as it becomes available.


 650. Extending a Common Block with an EQUIVALENCE Statement

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1990    ArticleIdent: Q67229

 An EQUIVALENCE statement can be used to extend a common block size by
 EQUIVALENCing the last element of a common block with the first element
 of an array that is not in a common block. This is demonstrated
 in the code below.

 This article expands upon the information in the EQUIVALENCE statement
 section of the "Microsoft FORTRAN Reference" manual, which discusses
 extending common blocks found.

 The following code fragment shows a common block being extended from
 4 bytes to 800 bytes in length.

 C ***** FORTRAN program fragment *****

       REAL*4 VAR, A(200)
       COMMON /TEST/ VAR
       EQUIVALENCE (VAR, A(1))

 In this fragment, the common block TEST is initially 4 bytes in
 length. The equivalence statement specifies that VAR and A(1) will
 share the same location in memory. Because all of A's elements are
 contiguous in memory, the common block TEST is extended to be 200 x 4
 or 800 bytes in length. This is shown graphically below:

    |01|02|03|04|05|06|07|08|09|0A|0B|0C|0D|0E|0F|10|
    |------------------------------------------------
    |....VAR....|
    |------------------------------------------------
    |....A(1)...|....A(2)...|....A(3)...|....A(4)...|
    |------------------------------------------------
    |<-- Beginning address of common block TEST

 The guidelines listed below must be followed when using EQUIVALENCE to
 extend a common block's length:

 1. A common block may only be extended by adding elements to the end
    of the common block. An EQUIVALENCE operation cannot add elements
    that precede the common block as in the following example:

 C ***** FORTRAN program fragment *****

       REAL*4 VAR, A(200)
       COMMON /TEST/ VAR
       EQUIVALENCE (VAR, A(2))

    Here VAR and A(2) will share the same memory location. Because A(1)
    precedes A(2) in memory, it will also precede VAR, which is the
    beginning of the common block. This is called extending a common
    block forward and is shown graphically below:

       |??|??|??|??|01|02|03|04|05|06|07|08|09|0A|0B|0C|0D|0E|0F|10
       ------------|------------------------------------------------
       ............|....VAR....|
       ------------|------------------------------------------------
       |....A(1)...|....A(2)...|....A(3)...|....A(4)...|....A(5)...
       ------------|------------------------------------------------
       ............|<-- Beginning address of common block TEST

    The following error is generated when the code listed above is
    compiled:

       F2320: A : EQUIVALENCE : extends common block TEST forward

 2. The ANSI FORTRAN 77 Standard states that a NAMED common block must
    be of the same size in all program units of an executable program
    in which it appears. For this reason, when a NAMED common block is
    extended, every subsequent subprogram accessing the common block
    must declare it according to its new size. For example, in the
    code below, a NAMED common block is again declared with one REAL*4
    element and then EQUIVALENCEd with a 200 element REAL*4 array. In
    the subroutine, the common block is then declared with its new size
    of 200 elements:

 C ***** FORTRAN program fragment *****

       PROGRAM main
       REAL*4 VAR, A(200)
       COMMON /TEST/ VAR
       EQUIVALENCE (VAR, A(1))
       CALL sub()
       .
       .
       END

       SUBROUTINE sub ()
       REAL*4 B
       COMMON /TEST/ B(200)
       .
       .
       RETURN
       END

    However, FORTRAN 5.00 will allow a NAMED common block to have
    different sizes in subprogram units. In this situation, the compiler
    generates the following warning:

       F4329: TEST : COMMON : size changed

    If the /4Ys compile option or $STRICT metacommand is used with
    FORTRAN 5.00, or if the program is compiled with FORTRAN 4.x, the
    error

       F2323: TEST : COMMON : size changed

    is generated when a NAMED common block's size is changed in a
    subprogram.


 651. No Error on Out-of-Range Read of INTEGER*1 Variable

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.x buglist5.00
 Last Modified: 30-NOV-1990    ArticleIdent: Q67230

 With a program compiled under Microsoft FORTRAN, reading a value that
 is less than -128 or more than +127 into an INTEGER*1 variable can
 fail to produce the expected error.

 The compiler should generate the following error:

    run-time error F6100:  READ
    -INTEGER overflow on input

 The following code reproduces the problem:

       integer*1 i
 10    read (*,*) i
       write (*,*) i
       goto 10
       end

 Entering the following values produces the corresponding results:

     0-127     Returns proper value

     128-255   Causes a Run-Time Error (RTE) as expected

     256-383   Returns value minus 256 (should cause an RTE)

     384-511   Causes an RTE

 This cycle repeats every 128 values.

 It appears that the run-time error management routine is inspecting
 the first byte of the input value to see if it is within range, and
 ignoring the remaining bytes. The following is an example:

     127 =  01111111               Returns the value 127

     128 =  10000000               Returns Run-time error

     255 =  00000000 11111111      Returns Run-time error

     256 =  00000001 00000000      Returns the value 0

 Thus, if the first byte is out of range, the program will correctly
 generate the error. However, if the first byte is in range, the
 program ignores all other bytes, fails to produce the error, and
 returns the value of the first byte. The /4Yb and $DEBUG metacommand
 do not affect the results.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.xx
 and 5.00. We are researching this problem and will post new
 information here as it becomes available.


 652. F1001: XX-2, Line 539, Allocating 43 Arrays in One Statement

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 30-NOV-1990    ArticleIdent: Q67231

 When you allocate 43 or more arrays with one ALLOCATE statement in
 Microsoft FORTRAN version 5.00, the following error is produced, where
 XX = ASCII characters 2 and 254:

    fatal error F1001:  Internal Compiler Error
    (compiler file "XX-2," line 539)

 Solution
 --------

 Breaking the ALLOCATE statement into two separate statements
 eliminates the error.

 The size of the arrays has no effect on the error. If only 42 arrays
 are defined and allocated, the error is not generated.

 The following code reproduces the internal compiler error:

       INTEGER
      + a1  [ALLOCATABLE] (:), a2  [ALLOCATABLE] (:),
      + a3  [ALLOCATABLE] (:), a4  [ALLOCATABLE] (:),
      + a5  [ALLOCATABLE] (:), a6  [ALLOCATABLE] (:),
      + a7  [ALLOCATABLE] (:), a8  [ALLOCATABLE] (:),
      + a9  [ALLOCATABLE] (:), a10 [ALLOCATABLE] (:),
      + a11 [ALLOCATABLE] (:), a12 [ALLOCATABLE] (:),
      + a13 [ALLOCATABLE] (:), a14 [ALLOCATABLE] (:),
      + a15 [ALLOCATABLE] (:), a16 [ALLOCATABLE] (:),
      + a17 [ALLOCATABLE] (:), a18 [ALLOCATABLE] (:),
      + a19 [ALLOCATABLE] (:), a20 [ALLOCATABLE] (:),
      + a21 [ALLOCATABLE] (:), a22 [ALLOCATABLE] (:),
      + a23 [ALLOCATABLE] (:), a24 [ALLOCATABLE] (:),
      + a25 [ALLOCATABLE] (:), a26 [ALLOCATABLE] (:),
      + a27 [ALLOCATABLE] (:), a28 [ALLOCATABLE] (:),
      + a29 [ALLOCATABLE] (:), a30 [ALLOCATABLE] (:),
      + a31 [ALLOCATABLE] (:), a32 [ALLOCATABLE] (:),
      + a33 [ALLOCATABLE] (:), a34 [ALLOCATABLE] (:),
      + a35 [ALLOCATABLE] (:), a36 [ALLOCATABLE] (:),
      + a37 [ALLOCATABLE] (:), a38 [ALLOCATABLE] (:),
      + a39 [ALLOCATABLE] (:), a40 [ALLOCATABLE] (:),
      + a41 [ALLOCATABLE] (:), a42 [ALLOCATABLE] (:),
      + a43 [ALLOCATABLE] (:)

       ALLOCATE (
      + a1  (1), a2  (1), a3  (1), a4  (1), a5  (1),
      + a6  (1), a7  (1), a8  (1), a9  (1), a10 (1),
      + a11 (1), a12 (1), a13 (1), a14 (1), a15 (1),
      + a16 (1), a17 (1), a18 (1), a19 (1), a20 (1),
      + a21 (1), a22 (1), a23 (1), a24 (1), a25 (1),
      + a26 (1), a27 (1), a28 (1), a29 (1), a30 (1),
      + a31 (1), a32 (1), a33 (1), a34 (1), a35 (1),
      + a36 (1), a37 (1), a38 (1), a39 (1), a40 (1),
      + a41 (1), a42 (1), a43 (1))
       END

 To avoid this error, limit each ALLOCATE statement to less than 43
 arrays.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 653. EXIT Statement Not Flagged as Nonstandard Statement

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1990    ArticleIdent: Q67232

 The EXIT statement, implemented in Microsoft FORTRAN version 5.00, is
 documented as an extension to the ANSI FORTRAN 77 standard (it appears
 in blue type in the "Microsoft FORTRAN Reference" manual). In
 addition, the EXIT statement does not appear in the list of IBM SAA
 and VAX extensions on pages 330-332 of the "Microsoft FORTRAN
 Reference" manual. For these reasons, the EXIT statement should
 generate the following error

    F2732 EXIT:  nonstandard statement

 when a FORTRAN 5.00 program is compiled with the $STRICT metacommand,
 or the /4Ys, /4Yi, or /4Yv compile option. This error is not generated
 under any circumstances.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 654. Opening More than 123 Files Causes Error F6415 or F6417

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  4-DEC-1990    ArticleIdent: Q67318

 After you increase the limit for the maximum number of open files to
 any number above 128, as discussed on pages 405 and 406 of the
 "Microsoft FORTRAN Reference" manual, the run-time error

    F6415: OPEN(file name)
    - file already exists

 or the run-time error

      F6417: OPEN(file name)
      - too many open files

 will be produced. FORTRAN generates these errors when you attempt to
 open more than 123 files at one time. Because FORTRAN reserves five
 file handles for its own use, the error occurs when the 129th file
 handle is requested. However, page 405 of the "Microsoft FORTRAN
 Reference" manual states that the maximum limit of open files is 256.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 If 123 files are already open and the 124th file does not exist, the
 following error will be generated:

    F6415: OPEN(file name)
    - file already exists

 If the 124th file to be opened exists, the following error will
 be generated:

    F6417: OPEN(file name)
    - too many open files

 On some systems, only 122 files can be opened; while on other systems
 if the 124th file does not exist, it is created before the error
 message is generated.


 655. F1001: omf_ms.c:1.118, line 2785; Common Block Too Large

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 10-DEC-1990    ArticleIdent: Q67420

 When the data in a COMMON block exceeds 45,940,736 (44,864K) bytes,
 the Microsoft FORTRAN version 5.00 compiler generates the following
 error:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)omf_ms.c:1.118', line 2785)

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code generates this error:

        INTEGER*1 A(45940737)
        COMMON  A
        END

 Any combination of data that adds up to more then 44,864K bytes will
 generate this error. The COMMON block can be named or unnamed.

 The following is another code sample that generates this error:

        REAL*4 A(3388,3388)
        INTEGER*1 B(26561)
        COMMON /TEST/ A,B
        END

 FORTRAN versions 4.x do not produce this error; instead, versions 4.x
 under DOS cause the following error:

    fatal error F1039: unrecoverable heap overflow in Pass 3

 FORTRAN 4.10 under OS/2 produces no compiler errors with the above
 code.

 Although using a slightly smaller amount of data allows compilation,
 using this much data in a single module will violate other limitations
 of the FORTRAN compiler and linker. For example, decreasing the size
 of the INTEGER array in the above code sample allows compilation with
 FORTRAN 5.00, but generates the following linker error:

    fatal error L1047: too many group, segment, and class names in
    one module

 The only practical solution is to decrease the size of the arrays
 significantly. The largest quantity of data that does not violate
 the limits on the number of group, segment, and class names is
 15,990,784 bytes, or 244 segments of 64K bytes per segment.


 656. Adjustable-Size Arrays Can Hang Machine in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 15-FEB-1991    ArticleIdent: Q67515

 Using the Microsoft FORTRAN 5.00 compiler on a program that contains
 an adjustable size array without the array being a formal argument to
 a subroutine can cause the machine to hang during compilation under
 DOS.

 This code will cause the compiler to generate an internal compiler error
 when compiling under OS/2.

 The compiler should generate the following error messages.

 In a Subroutine
 ---------------

 F2841:  adjustable-size array: not reference argument

 In a Main Program
 -----------------

 F2339:  adjustable-size array not in subprogram

 To eliminate the problem, include the array as an argument to the
 subroutine or declare it as ALLOCATABLE and allocate it. Page 145 of
 the "Microsoft FORTRAN Reference" manual explains how adjustable-sized
 arrays must be formal arguments to the program unit in which they
 appear. Allocatable arrays, however, must not be formal arguments.
 They are discussed on pages 25 and 113 of the "Microsoft FORTRAN
 Reference" manual. Versions 4.x of the compiler correctly report the
 error.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code reproduces the problem in a subroutine:

        SUBROUTINE a (b,c)
        DIMENSION b(1,1),d(c,1,1)
        e=1
        d(e,e,e) = d(1,1,1)+b(1,1)*d(1,1,1)
        END

 The error is dependent on both of the assignment statements and the
 arithmetic in the second statement. For example, changing the
 left-hand side of the equation in the second assignment statement to
 "d(1,1,1)" instead of "d(e,e,e)" will generate the correct error.

 The following code reproduces the problem in a main program:

        DIMENSION b(1,1),d(c,1,1)
        e=1
        d(e,e,e) = d(1,1,1)+b(1,1)*d(1,1,1)
        END

 In the main program, the following error is generated before
 causing a Protection Violation or hanging the machine:

    F2339: Adjustable-size array not in subprogram

 If an adjustable-size array is desired in the main program, declare
 the array as ALLOCATABLE and then allocate it using variables to
 establish the dimensions.


 657. Structure Element in OPEN Causes Protection Violation

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  9-JAN-1991    ArticleIdent: Q67615

 Using an element of a structure as a filename in an OPEN statement
 generates a protection violation when you compile under the OS/2
 operating system when you use Microsoft FORTRAN version 5.00. To work
 around this problem, assign the value of this member to a temporary
 variable and use this with your OPEN statement.

 There seems to be no problem compiling under DOS, and programs with
 this code appear to function correctly. Also, programs using this
 method of opening files, which are compiled under DOS but linked for use
 under OS/2, appear to run correctly under OS/2.

 Microsoft has confirmed this to be a problem in the FORTRAN compiler
 version 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The program below illustrates this problem:

       program test

       structure /io/
         character* 12 name
       end structure

       record /io/ ioinst

       ioinst.name = 'test.dat'

       open (10, file=ioinst.name)

       end

 To work around this problem, change the program to the following:

       program test

       structure /io/
         character* 12 name
       end structure
       character* 12 tmp

       record /io/ ioinst

       ioinst.name = 'test.dat'

       tmp = ioinst.name
       open (10, file=tmp)

       end

 Another possible solution to this problem is to compile the program
 under DOS and link for use under OS/2.


 658. Problem Reading Direct-Access File When RECL > BLOCKSIZE

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 buglist5.00
 Last Modified:  4-JAN-1991    ArticleIdent: Q68030

 In Microsoft FORTRAN versions 4.01 through 5.00, when a direct-access
 file is opened with a BLOCKSIZE set to a value that is less than the
 RECL (record length), incorrect records may be read from the file.

 The easiest way to avoid this problem is to always use a record length
 that is less than or equal to the BLOCKSIZE (the default BLOCKSIZE is
 1024). Other possible solutions are listed below.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.01,
 4.10, and 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The following code demonstrates this problem:

       CHARACTER*514 ALINE
       CHARACTER*10  SHORT

       OPEN(9,ACCESS='DIRECT',RECL=514,
      +FORM='FORMATTED', BLOCKSIZE=512)

 C Note that the BLOCKSIZE is smaller than the record length

       DO 10 J=1,4                        ! Create a file to read.
          ALINE = 'TEST '// CHAR(#30+J)   ! Put the record number
          WRITE(9,30,REC=J) ALINE         ! in each record.
 10    CONTINUE

 C This is the start of the READ sequence where the problem occurs.

       READ(9,30,REC=3) SHORT   ! This is the partial read
                                ! into record 3.

       DO 20 I=1,4
          READ(9,30,REC=I) ALINE
          WRITE(*,*) ALINE
 20    CONTINUE
 30    FORMAT(A)
       END

 The first DO-loop in the program constructs a four record
 direct-access scratch file. This is followed by a partial read of
 record 3 from the file. The following DO-loop reads the file from
 record 1 to record 4 and outputs the result to the screen.

 The program output indicates that the READ statement in the DO-loop
 improperly accesses the information in the scratch file. Because the
 RECL (record length) exceeds the BLOCKSIZE (buffer size), each READ
 forces the buffer to be filled twice. The extra information is not
 being flushed from the buffer, and is incorrectly read into the
 variable ALINE on every READ after the initial partial READ of record
 3.

 Some ways to avoid this problem:

 1. Make sure that RECL (record length) is less than BLOCKSIZE.

 2. Access the direct-access file with a variable or group of variables
    with a length in bytes that matches the record length, thus
    avoiding partial access to a record.

 3. Use a REWIND statement following any partial access to a record.
    This realigns the file pointer to the beginning of the file
    (BACKSPACE does not appear to solve the problem).

 This problem does not occur in FORTRAN versions 4.00 and 4.00a;
 however, it does occur in versions 4.01, 4.10, and 5.00.


 659. SELECT CASE with /4I2 Creates Oversized .OBJ Module

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 10-JAN-1991    ArticleIdent: Q68104

 The FORTRAN 5.00 compiler can create greatly oversized object modules
 when a program that uses the SELECT CASE statement is compiled with
 the /4I2 switch in the DOS environment. When the same program is
 compiled under OS/2, the compiler appears to hang.

 Because of the size of the object module, the following warnings are
 also generated when you compile with the /4I2 switch:

    F4063: function too large for post-optimizer
    L4020: code segment size exceeds 65500

 The resulting executable can cause the machine to hang.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching the problem and will post new information here as
 it becomes available.

 When the following sample program is compiled with the /4I2 compiler
 switch under DOS, the program produces an object file of over 160,000
 bytes. Without the /4I2 switch, an object module of several hundred
 bytes is generated. An assembly listing of the program shows that the
 compiler generates repetitive lines of invalid code.

 Program
 _______

       select case (i)
              case (  :-3)
              case (-2: 0)
              case ( 1 )
              case ( 2 )
       end select
       end

 To avoid this problem, do not use the /4I2 compiler switch when you
 are compiling programs that use the SELECT CASE...END SELECT
 statement.


 660. Problem Writing Array of Structure Variables with F1.EXE Patch

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 28-JAN-1991    ArticleIdent: Q68528

 Programs compiled with FORTRAN 5.00 using the patched version of
 F1.EXE or the patched High-Capacity Compiler F1L.EXE can generate
 incorrect output when you write an array of structure variables.

 If you use the patched High-Capacity Compiler F1L.EXE with programs
 containing such code, and link for OS/2, you may generate the
 following error:

    Error L2002: fixup overflow at 13 in segment _DATA
    pos: 15F Record type: 9C
    frm seg NULL, tgt seg_BSS, tgt offset E05

 The resulting executable will not run.

 These errors do not occur when you use the unpatched versions of the
 F1.EXE or the High-Capacity Compiler F1L.EXE.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The F1.EXE patch is used to correct, among other things, the error:

    F1001: Internal Compiler Error
           compiler file omf_ms.c:1.118, line 1093

 This error often results when I/O operations are performed on elements
 of a structure after that structure has been passed to a subroutine.

 The High-Capacity Compiler F1L.EXE is an alternate form of the first
 pass of the compiler. It should be used to compile programs that
 receive the error:

    F1901: program too large for memory

 The following program illustrates the problem.

       structure / rec /
        character*12 num
       end structure

       record / rec / allrec(3)

       allrec(1).num= 'one'
       allrec(2).num= 'two'
       allrec(3).num= 'three'

 10    format(' ',a12)
       do 20 i=1, 3
        write(*,10) allrec(i).num
 20    continue
       end

 The program should produce the output:

    one
    two
    three

 Instead, when the program is compiled using the patched F1.EXE and
 linked for DOS or OS/2, it produces the following output:

    one
    one
    one

 When the program is compiled with the patched High Capacity Compiler
 F1L.EXE and linked for OS/2, the linker produces the fixup overflow
 error and the resulting executable is nonfunctional. When the program
 is linked for DOS after using the patched High Capacity Compiler, it
 can generate three repeated lines of random text output. It may also
 produce three blank lines of output.

 Workaround
 ----------

 A workaround to this problem is as follows:

 1. Declare a temporary variable.

 2. Assign the structure element to the temporary variable.

 3. Then use the temporary variable in all I/O operations.

 Note: This is also a suggested workaround to problems solved by using
 the F1.EXE patch.

 Sample
 ------

 For example:

       structure / rec /
         character*12 num
       end structure

       record / rec / allrec(3)

       character*12 temp           ! 1)

       allrec(1).num= 'one'
       allrec(2).num= 'two'
       allrec(3).num= 'three'

 10    format(' ',a12)
       do 20 i=1, 3
        temp=allrec(i).num         ! 2)
        write(*,10) temp           ! 3)
 20    continue
       end


 661. Incorrect Output with Element of Structure in CHAR Function

 Product Version(s):
 Operating System:   5.00   | 5.00
 Flags: MS-DOS | OS/2
 Last Modified:  7-FEB-1991    ArticleIdent: Q69002
 ENDUSER | buglist5.00

 In FORTRAN 5.00, a program using the CHAR intrinsic function on a
 structure element within a WRITE or PRINT statement can produce
 erroneous output when executed under DOS, or result in a protection
 violation when executed under OS/2.

 To avoid these problems, remove the intrinsic function from the WRITE
 or PRINT statement by assigning the result of the CHAR intrinsic
 function to a temporary variable, and then use this variable in the
 output statement.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following example reproduces the problem:

        structure /a/
          integer*2 i
        end structure

        record /a/ name
        name.i=97                   ! ASCII lowercase a
        write(*,*) char(name.i)
        end

 1. When the above program is linked for DOS, the resulting executable
    prints the wrong character or no character at all.

 2. When it is linked for OS/2, the resulting executable generates a
    protection violation during runtime.

 3. When it is compiled under DOS with the patched version of F1.EXE
    (used to correct several problems with structures and NAMELIST
    statements) and linked for either DOS or OS/2, the executable
    generates the correct results.

 4. When it is compiled under OS/2 with the patched version of F1.EXE,
    a protection violation is generated during compilation in the F2.EXE
    pass of the compiler.

 One possible solution is to assign the result of the CHAR intrinsic
 function to a temporary variable as illustrated by the following
 example:

        structure /a/
          integer*2 i
        end structure

        character c
        record /a/ name
        name.i=97              ! ASCII lowercase a

        c=char(name.i)
        write(*,*) c
        end


 662. Problem Directing Listing and Object Files to a Directory

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-FEB-1991    ArticleIdent: Q69040

 The listing options and object file naming option used by FORTRAN 5.00
 do not function as documented in the "Microsoft FORTRAN Reference"
 manual. Compiling more than one source file at a time fails to create
 listing or object files in the specified path for every source file
 listed after the option on the command line. The first listing or
 object file is created in the specified path. The remaining listing or
 object files are either created in the current directory or not
 created at all.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 If you compile more than one source file at a time with one of the
 following compiler switches set to a path other than the current
 directory, you will create the first listing or object file in the
 specified path. The listing or object files for the other source files
 are created in the current directory.

    Option                    File Type
    ------                    ---------

    /Fs[[listfile]]           Source Listing
    /Fc[[listfile]]           Combined Source-Object Listing
    /Fo[[objfile]]            Object

 If you compile more than one source file at a time with one of the
 following compiler switches set to a path other than the current
 directory, you will create the first listing in the specified path.
 Listings for the other source files are not created.

    Option                    File Type
    ------                    ---------

    /Fa[[listfile]]           Assembly Listing
    /Fl[[listfile]]           Object Listing

 Using Microsoft FORTRAN 5.00 to compile more than one source file at a
 time with the listing options or object file naming option set to a
 path other than the current directory should create listing or object
 files using the specified path for every source file listed after the
 option on the command line (see pages 338-342 of the "Microsoft
 FORTRAN Reference" manual).

 This problem does not occur in FORTRAN versions 4.x.

 The following command line illustrates the problem:

    FL /FsD:\LISTINGS\ A.FOR B.FOR C.FOR

 If the current directory is D:\FORTRAN and the source files are A.FOR,
 B.FOR, and C.FOR, then the source listings for file A.FOR will be
 generated in the D:\LISTINGS directory and the source listings for
 files B.FOR and C.FOR will be generated in the D:\FORTRAN directory.

 To have all of the source listings in the D:\LISTINGS directory,
 compile with the following command line:

    FL /FsD:\LISTINGS\ A.for /FsD:\LISTINGS\ B.FOR /FsD:\LISTINGS\ C.FOR


 663. NAMELIST in Internal READ Yields Error F1901 in FORTRAN

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 12-FEB-1991    ArticleIdent: Q69071

 Using FORTRAN 5.OO, under DOS, to compile a program that uses an
 internal READ to read from a character variable into a NAMELIST
 generates the error:

    F1901:  Program too large for memory

 Under OS/2, a protection violation is generated during compilation.

 Using the high-capacity compiler F1L.EXE (normally used to correct the
 above error) can result in hanging the machine during compilation under
 DOS.

 An internal READ cannot be used in FORTRAN 5.00 to read in a NAMELIST.
 One solution is to put the NAMELIST data into a external file, either
 before or during program execution.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code illustrates the problem:

       character*21 test /' &in x=1 y=5 z=10 /'/
        namelist /in/ x,y,z
        read(test,in)
       end

 When compiling this code under DOS using the high-capacity compiler,
 the machine will hang. When compiling this code under OS/2 using the
 high-capacity compiler, a protection violation is generated. The
 high-capacity compiler F1L.EXE is a replacement for the first pass of
 the compiler, and is used to correct the error:

    F1901:  Program too large for memory

 The patched versions of F1.EXE and F1L.EXE, (used to correct problems
 with NAMELIST), produce the same results as F1.EXE and F1L.EXE
 respectively.

 One solution is to read in the NAMELIST data from an external file
 rather than an internal file:

 c test.for
        open(8,file='test.dat')
        namelist /in/ x,y,z
        read(8,in)
        write(*,in)
        close(8)
        end

 data file test.dat:

 &in
 x=1
 y=5
 z=10
 /
 c

 Alternatively, a scratch file can be created in which to temporarily
 store the NAMELIST data:

        character*21 test /' &in x=1 y=5 z=10 /'/
        namelist /in/ x,y,z

        open(8)
        write(8,*) test
        rewind(8)
        read(8,in)
        write(*,in)
        close(8)
        end


 664. Calling DOS and BIOS Interrupts Using FORTRAN 5.00 and MASM

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | softlib INTERPT.ARC q68908
 Last Modified: 13-FEB-1991    ArticleIdent: Q69152

 DOS and BIOS interrupts can be accessed in FORTRAN without the
 functions INTDOS and INTDOSX. Two assembly code routines INTERRUPT and
 INTERRUPTX are available in the Software/Data Library that allow
 access to most interrupts including interrupt number 21. In addition,
 an INCLUDE file and two FORTRAN sample programs are included in the
 Software/Data Library article that demonstrate how to use the
 INTERRUPT and INTERRUPTX function calls.

 This file (FORINTER) can be found in the Software/Data Library by
 searching for the filename FORINTER, the Q number of this article, OR
 S12908.

 FORINTER was archived using the PKware file-compression utility.

 To utilize the INTERRUPT AND INTERRUPTX functions, the statement

    INCLUDE 'INTERRPT.INC'

 must be contained at the top of the source file making the call.
 The two statement functions documented at the end of the
 INTERRPT.INC file must be uncommented and added to the source code
 of any program, function, or subroutine block where the assembly
 procedures are called. These statement functions must appear before
 any executable statements. INTERRUPT.OBJ must be linked with the
 object file produced from compiling the main program.

 *********************
 INTERRPT.INC : include file for INTERRUPT and INTERRUPTX.
 This file includes the INTERFACE to the assembler routines and the
 register structures needed for these routines.

 Copy these statement functions after your other declarations but
 before other executable statements in the program, subroutine, or
 function in which you call INTERRUPT or INTERRUPTX

       gethibyte (dataword) = dataword / 256
       getlobyte (dataword) = iand(dataword , 255)
 *********************

 *********************
 INTERRPT.ASM The assembler source listing of the INTERRUPT and
 INTERRUPTX routines.
 ***************

 ***************
 INT.FOR      A sample program which uses the INT 21, function 2A
 hex to get the system date.
 ***************

 ***************
 INTX.FOR:  A sample program which uses the INT 21, function 41 hex
 to delete a file.

 This example uses the segment registers.

 ***************


 665. Key Entry Routines in MASM with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | softlib q68703
 Last Modified: 12-FEB-1991    ArticleIdent: Q69153

 Two examples of simple key fetch routines written in the Microsoft
 Macro Assembler (MASM) version 5.10 for use with Microsoft FORTRAN are
 contained within the Software/Data Library. These routines use DOS
 interrupts and do not work under OS/2.

 This file (FORGETCH) can be found in the Software/Data Library by
 searching for the filename FORGETCH, the Q number of this article, or
 S12907.

 FORGETCH was archived using the PKware file-compression utility.

 Example A contains a function that, when called, waits for a
 keystroke and then passes back the keystroke to the FORTRAN calling
 program. This can be used to get single keystroke information from the
 user without requiring use of the ENTER key.

 Example B contains a function that checks to see if a keystroke has
 been previously entered. This function does not wait for the user to
 enter a character, but reports if a character has been entered. Once
 again, the user does not need to press the ENTER key for single-key
 data to be accepted.

 This program was not designed for redirected standard input.
 Furthermore, the interface routine is currently set up to only flag
 that a function or ALT+<KEY> sequence has been entered, and to print a
 message accordingly.


 666. ENTRY Statement Causes F2836: Statement Out of Order Error

 Product Version(s):
 Operating System:   4.00 4.01 4.10 5.00 | 4.10 5.00
 Flags: MS-DOS              | OS/2
 Last Modified: 13-FEB-1991    ArticleIdent: Q69188
 ENDUSER |

 Using the Microsoft FORTRAN compiler on code containing a subroutine
 that has an ENTRY statement preceding specification statements, type
 statements, implicit statements, or parameter statements will generate
 the following error:

    F2836: Statement Out of Order

 A subroutine that has an ENTRY statement preceding Statement Function
 statements will generate the following error:

    F2515: left side of assignment illegal

 A subroutine that has an ENTRY statement preceding the $LARGE or the
 $NOTLARGE metacommand (used with or without arguments) will generate
 the following respective errors:

    F2021: $LARGE illegal in executable statements
    F2021: $NOTLARGE illegal in executable statements

 Placing these statements before the ENTRY statement will not generate
 the errors.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.x
 and 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The ENTRY statement on pages 162-163 of the "Microsoft FORTRAN
 Reference" manual specifies an entry point to a subroutine or
 external function.

 According to the Order of Statements chart in the "Microsoft FORTRAN
 Reference" manual on page 47, figure 2.1, the ENTRY statement should
 be able to appear before or after all statements inside a BLOCK DATA,
 FUNCTION, PROGRAM, or SUBROUTINE block.

 The following program, which uses the ENTRY statement and a type
 statement, demonstrates the problem:

       call in
       end

       subroutine sub
       entry in
       integer a
       end

 The error is not generated if the integer type statement is placed
 before the ENTRY statement.


 667. Protection Violation with Array Structure Element in I/O

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist 5.00
 Last Modified: 20-FEB-1991    ArticleIdent: Q69405

 A protection violation is generated by the third pass of the Microsoft
 FORTRAN 5.00 compiler in OS/2 when you compile code containing a
 subroutine that uses an array structure element in an I/O statement.

 In DOS, the compiler will generate the error:

    warning F4202: Sub : formal argument : never used
    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)omf_ms.c:1.118', line 1093)
    Contact Microsoft Technical Support

 The F1.EXE patch, which is used to correct structure element I/O
 within subroutines, produces identical errors as the unpatched F1.EXE.

 One possible solution is to assign the structure variable, which is
 passed to the subroutine, to a temporary structure variable, and use
 the temporary structure variable in all I/O statements.

 If you are experiencing invalid output with structure array elements,
 query on "invalid output" for a related article.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code reproduces the problem:

        structure /t/
           integer j(100)
        end structure
       record /t/ st
       call sub(st)
       end

       subroutine sub(st)
         structure /t/
           integer j(100)
         end structure
       record /t/ st
       write(*,*) st.j    ! line 6
       end

 Accessing an element of the array in line 6 instead of the entire
 array will not result in any error.

 Assigning a temporary structure variable to the structure variable
 that is passed to the subroutine and using the temporary structure
 variable in all I/O statements will prevent these errors.

 The following program illustrates this solution:

         structure /t/
           integer j(100)
         end structure
       record /t/ st
       call sub(st)
       end

       subroutine sub(st)
         structure /t/
           integer j(100)
         end structure
       record /t/ st,temp
       temp=st
       write(*,*) temp.j
       end


 668. Structure Element in Internal File Causes omf_ms.c:1.118

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00 err msg
 Last Modified: 20-FEB-1991    ArticleIdent: Q69481

 If you use Microsoft FORTRAN version 5.00 under DOS to compile a
 program that does an Internal READ or WRITE on a structure element,
 the following error may be generated:

    fatal error F1001: Internal Compiler Error
                (compiler file '@(#)omf_ms.c:1.118', line 1093)

 When compiling under OS/2, a protection violation is generated by the
 second pass of the compiler.

 The F1.EXE patch, used to correct structure element I/O within
 subroutines, produces the same errors as the unpatched F1.EXE.

 One way to avoid this error is to assign the element of the structure
 to a temporary variable, and then use this temporary variable in the
 internal READ or WRITE.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following program illustrates this problem:

       structure /a/
       character*5 b
       end structure

       record /a/ c
       real x
       c.b = '10.0'
       read(c.b,'(f5.0)') x
       write(*,*) x
       end

 If you assign the structure element to a temporary variable, as shown
 below, and then use this temporary variable in the internal READ,
 the error will not be generated.

       structure /a/
       character*5 b
       end structure

       record /a/ c
       real x
       character*5 tmp
       c.b = '10.0'
       tmp = c.b
       read(tmp,'(f5.0)') x
       write(*,*) x
       end





 Microsoft Programmer's Work Bench [Development Environment]
 =============================================================================


 1. Using the Features of PWB to Build a Program with Overlays

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1990    ArticleIdent: Q60050

 A MAKE file built with PWB can be modified (within reason) with the
 user supplied information section. This section, coded as

    # << User_supplied_information >>

 can contain other instructions that PWB (actually NMAKE or NMK) is
 supposed to carry out during the MAKE cycle. All instructions that
 follow this "fence" are not changed by PWB.

 The following instructions detail two implementations of that "fence"
 to allow PWB to build a program that uses overlays.

 While the following steps appear tedious, they are simple in practice.

 Once the changes are made, the only time you need to edit the MAKE
 file directly is to change your overlay structure, or to add or delete
 modules. When adding or deleting modules, you must both edit the
 program list with Make.Edit Program List and modify the commands in
 the user section. If you are only modifying the overlay structure, you
 change just the user section.

 The overlay structure in the example is as follows:

    HELLO.OBJ  (root)
        |
        +----A.OBJ (first  overlay)
        |
        +----B.OBJ (second overlay)

 All of the .OBJs are built from .C files with the same base name.

 1. Use PWB to build the program list in the normal way. This step is
    the same for any new program list.

    a. Start PWB.

    b. Choose Make.Set Program List and specify a new name -- HELLO.MAK
       in this example.

    c. Add HELLO.C, A.C, and B.C to the list. (If you have additional
       .C or .OBJ files, you would add them as well.) When all the
       files are listed, select Set Dependencies.

    d. Choose Options.Build Options and click on the Set Initial
       Build Options button and select DOS EXE.

    e. From Options.Compile Options, select the proper memory model.

    f. From Options.Link Options.Set Debug Options, turn off
       Incremental Link.

    g. From the Options.Browse Options dialog box, turn Generate Browse
       Information on.

    h. Choose Make.Rebuild All to make sure that the program builds
       properly without overlays. If it doesn't, review your work in
       previous steps.

 2. Now that you have a working program list, add the non-PWB
    information to the end.

    a. Choose Make.Clear Program List so that you can edit the MAKE
       file. Attempting to edit the current program list results in the
       message "No-edit file may not be modified."

    b. Choose File.Open to open the MAKE file so you can modify it.

    c. Go to the end of the file and start a blank line.

       Starting in column 1, add the following line:

          # << User_supplied_information >>

       Be sure to enter the line exactly as shown -- spacing is
       significant. This line is a "fence". Everything below the fence
       is yours and is not modified by PWB. Conversely, you should not
       modify anything above the fence because that section belongs to PWB.

    d. Below the fence starting in column one, add the pseudo-target:

          OVERLAID : $(OBJS)

       Be sure it starts column 1. Do not put a blank line after this line.

    e. Copy the command section from the $(PROJ).EXE description block
       to immediately follow the pseudo-target. The command section begins
       on the line following the line that reads

          $(PROJ).exe : $(OBJS)

       and ends at the next blank line. Do not copy the $(PROJ).EXE
       line, and do not leave a blank after the target. After you have
       copied the commands, your file should appear as follows:

          ... PWB section here, unmodified ...

          # << User_supplied_information >>

          OVERLAID : $(OBJS)
          !IF $(DEBUG)                    # copy of commands...
                  $(LRF) @<<$(PROJ).lrf
          $(RT_OBJS: = +^
          ) $(OBJS: = +^
          )
          $@
          ...

    f. Use the following procedure to modify the commands to link an
       overlaid EXE instead of a normal EXE.

       Note: There are two subsections in this section: a debug section
       that starts at the first "!IF $(DEBUG)" and ends at "!ELSE", and
       a release section that starts after the "!ELSE" and ends at the
       first "!ENDIF".

       You need to make the following modifications to both
       subsections.

       i. Delete the line that reads as follows:

             ) $(OBJS: = +^

          After the right parenthesis on the line that moved up, put
          your list of .OBJ files with parentheses to indicate which
          ones go in which overlays. If you need to use more than one
          line for all of your objects, be sure to put a plus sign (+)
          at the end of each line except the last.

      ii. Replace "$@" on the next line with "$(PROJ).EXE".

          In our example,

                 $(LRF) @<<$(PROJ).lrf
             $(RT_OBJS: = +^
             ) $(OBJS: = +^     # delete this line
             )                  # append OBJ list here ...
             $@                 # replace this line with $(PROJ).EXE

          becomes:

                 $(LRF) @<<$(PROJ).lrf
             $(RT_OBJS: = +^
             ) hello.obj +
             (a.obj) +
             (b.obj)
             $(PROJ).exe

          Remember to make the changes in both branches of the !IF
          $(DEBUG).

    g. The last step is to modify the browser database build commands.
       These are the two lines at the very end of the file that begin
       with "$(NMAKEBSC...". PWB adds and deletes these lines in the
       PWB section as you turn browser information on and off.

       Since PWB won't delete and add these lines in the user section,
       enclose them in !IF $(BROWSE)...!ENDIF so they'll be executed
       only when you ask for browse information. You also need to
       delete the "$(NMFLAGS)" macro from the second line to prevent
       infinite NMAKE recursion.

       The following lines

          $(NMAKEBSC1) MAKEFLAGS=
          $(NMAKEBSC2) $(NMFLAGS) -f $(PROJFILE) $(PROJ).bsc

       become:

          !IF $(BROWSE)
              $(NMAKEBSC1) MAKEFLAGS=
              $(NMAKEBSC2) -f $(PROJFILE) $(PROJ).bsc
          !ENDIF

       If you need special NMAKE options for building the browser
       database, just add them where you removed $(NMFLAGS).

 3. Reactivate the MAKE file by selecting Make.Set Program List.

 4. With these changes, if you select Make.Rebuild All, you will still
    get a non-overlaid program because PWB normally builds the first
    target in the MAKE file. To build the overlaid program, modify the
    command line passed to NMAKE so that NMAKE builds your overlay
    target rather than the regular EXE. Select Options.NMAKE Options
    and specify "OVERLAID" as the target by putting it in the NMAKE
    options box, or use Make.Build Target.

 5. With "OVERLAID" in Options.NMAKE Options you can build your program
    by either selecting Make.Rebuild All or Make.Build *.EXE, as usual.
    If you want to build a non-overlaid program, delete "OVERLAID" from
    the NMAKE options box.

    Note that if you use debug options with overlays you will get a
    linker warning L4047. This warning, and the dialog box that says
    that CRT0DAT.ASM can't be found, are normal when building overlaid
    programs for debugging and can be ignored. You can debug the overlaid
    program normally, with full debugging information available.

    This MAKE file behaves almost identically to a regular PWB MAKE
    file. The only differences are that NMAKE options are NOT  passed
    to the browser build unless you add them to the browser build line,
    and that you must edit the user supplied section if you add or
    delete modules from the project.


 2.

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10 s_c
 Last Modified:  5-FEB-1991    ArticleIdent: Q60392

 TOOLS.PRE is a sample Programmer's WorkBench (PWB) initialization file
 that is installed (and modified) when C 6.00 is installed by running
 the Setup program. On pages 19 and 20 of "Microsoft C: Installing and
 Using the Professional Development System," it states that the
 contents of TOOLS.PRE can be merged with an existing TOOLS.INI file,
 if one exists, or it can be renamed to TOOLS.INI, if there isn't one.
 To work correctly, you must make sure that the contents of this file
 are preceded by a PWB tag (for example, [PWB]) because the supplied
 TOOLS.PRE lacks this tag.

 When merging the PWB 1.00 TOOLS.PRE file into an existing TOOLS.INI
 file, a [PWB] tag should be added just above the area where the file
 is merged. For example:

 [PWB]
   .
   .
   .
   (TOOLS.PRE contents)
   .
   .
   .

 [NEXT-TAG]

 If TOOLS.PRE is being renamed to TOOLS.INI, the tag should be added as
 the first line in the file. In either case, failure to add the tag
 will result in PWB ignoring the initialization information.

 Microsoft has confirmed this to be a problem in PWB version 1.00. This
 problem was corrected in PWB version 1.10.


 3. How to Abort Compilation When Using PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 17-JUL-1990    ArticleIdent: Q60500

 Question:

 How do I abort a compile that is in progress when using the
 Programmer's WorkBench (PWB) environment?

 Response:

 Under MS-DOS (or the OS/2 3.x compatibility box), use CTRL+C to abort.

 Under OS/2, use "Arg Meta Compile" to abort a compilation taking place
 in the background.

 The default keystrokes for Arg Meta Compile are ALT+A F9 CTRL+F3.

 You can also create a macro and assign it to a key to abort the
 compile process. Below is a sample macro that you could place in your
 TOOLS.INI file under the [pwb] tag.

    [pwb]
    Abort:=Arg Meta Compile
    Abort:Ctrl+F5

 Note: In either OS/2 or MS-DOS, the ESC key and CTRL+BREAK do not
 abort a compilation.


 4. PWB Makefiles Are Read-Only When Set as Active Program List

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-MAY-1990    ArticleIdent: Q60749

 When you choose the Make.Set Program List option within the
 Programmer's WorkBench (PWB) environment to set a program list for the
 current project, the makefile associated with the current program list
 is marked as read-only and is not editable.

 Code Example
 ------------

 // FOO.C

 #include <stdio.h>
 void main ( void )
 {
    printf ( "Foobar\n" ) ;
 }

 1. Using the above sample program, choose the Make.Set Program List
    menu options and call the program list FOO.MAK.

 2. Save the list.

 3. Choose the File.Open menu, and enter FOO.MAK as the file you want
    to open.

 4. Place your cursor anywhere in the file and press ENTER. You will be
    greeted with the following a pop-up message:

       No-edit file may not be modified.

 If you want to edit the makefile, choose the Make.Clear Program List
 options, and you can edit the makefile as you want.


 5. Why Zero-Length .SBR Files Are Left on the Disk by the PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 16-JAN-1991    ArticleIdent: Q61056

 When using the Source Browser functionality within the Programmer's
 WorkBench, you can expect to have zero-length .SBR files on your disk.
 This is by design of the PWBRMAKE utility.

 PWBRMAKE.EXE is a utility that converts the .SBR files created by the
 compiler for each program module into a single database file that can
 be read by the Programmer's WorkBench (PWB) Source Browser. The
 resulting Source Browser database file has the extension .BSC.

 When a Source Browser database (a .BSC file) is built from .SBR files,
 the .SBR files are truncated to zero length to save disk space since
 they can be quite large. .SBR files are truncated to zero length,
 rather than being deleted, because PWBRMAKE performs incremental
 updates to the database and, therefore, needs the time and date stamp
 from the files.

 When you rebuild part of your project, new .SBR files are built for
 those modules. Each .SBR file that has not been re-created during a
 build is included as a zero-length file. This tells PWBRMAKE that the
 file has no new contribution to make to the database, so no update of
 that part of the database is required.


 6. Do Not Start Programmer's WorkBench by Typing PWBED

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-JUL-1990    ArticleIdent: Q61307

 You cannot start the Programmer's WorkBench by typing PWBED. This is
 incorrect. Type PWB to start the Programmer's WorkBench environment.

 In the REAL MODE directory specified during setup, there will be two
 executables for the PWB, PWB.COM and PWBED.EXE. PWB.COM actually
 spawns PWBED.EXE. If you use PWBED to start the PWB, it will consume
 approximately 500K of memory. By executing a DOS SHELL from within the
 PWB and running CHKDSK, you will notice there is very little memory
 left.

 When you invoke the PWB the correct way (by typing PWB), then shell-
 out and do a CHKDSK, you will see that the PWB has only consumed
 approximately 8K of available memory.

 The PWB appears to work correctly if you invoke it with PWBED.
 However, since it is using so much memory, you will receive memory
 problems, such as "out of memory," "cannot compile," or "cannot
 build." These are caused because there is not enough memory to spawn
 either NMAKE, the compiler, or the linker.


 7. Steps Needed to Make Source Browser Usable

 Product Version(s): 1.00    | 1.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 11-JUL-1990    ArticleIdent: Q61309

 Before using the Browse menu options, you must first define and build
 the database the Source Browser will use. If this database is not
 already built, all options on the Browse menu will be grayed out and
 unusable.

 The following steps must be taken to define a database that is usable
 by the Source Browser menu options:

 1. Generate a program list using the Set Program List command in the
    Make menu. The PWB creates one internally if you do not specify one
    and the program only uses one source file. If a program is larger
    than one source file and a program list is not set, it is
    impossible to generate a Source Browser database.

 2. Choose Browse Options from the Options menu. You must select the
    Generate Browse Information field in the dialog box to create the
    Source Browser database.

 3. Build your program using the Make Menu option. You MUST have a
    successful build (compile AND link) of the program for a Source
    Browser database to be generated.

 The Browse Menu options should now be available for use.

 If, after taking the steps outlined above, the Browse Menu options
 are still unavailable for use, query on the following keywords:

    Browse and Options and Unavailable and Strange and Circumstances
 For printed documentation explaining the setup and use of the Source
 Browser, see Pages 50-52 of "Installing and Using the Professional
 Development System." You can also find information about the Source
 Browser in the online help under Programmer's WorkBench, Using the PWB
 Source Browser.


 8. SYS2070 Issued When Executing PWB.EXE for the First Time

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 13-JUN-1990    ArticleIdent: Q61572

 When running the Programmer's WorkBench (PWB) for the first time, the
 following OS/2 system error may be issued:

    Session Title:
    PWBED.EXE

    SYS2070: The system could not demand load the
    application's segment. MSHELP HELPSHRINK is in error.
    For additional detailed information also see message SYS0127

 This system error is caused by the PWB's use of a version of
 MSHELP.DLL that is not as current as the one that was shipped with C
 version 6.00. For the PWB to function correctly, the correct version
 of MSHELP.DLL must be in the LIBPATH.

 The README.DOC on the C version 6.00 Setup/Compiler 1 Disk warns of
 this potential problem, and suggests that QuickHelp (QH) be terminated
 as a background keyboard monitor before Setup is run.

 This problem is usually caused as a result of the Setup program not
 being able to copy its version of MSHELP.DLL over the old version of
 MSHELP.DLL. If another process (most likely a detached session of
 QH.EXE) was accessing this file during the execution of Setup, the
 Setup program will issue a message similar to the following:

    ERROR: Could not create file C:\OS2\DLL\mshelp.dll
    ERROR: File copy failed: A:\the PWB\mshelp.dll to C:\OS2\dll\mshelp.dll

 To solve this problem, take the following steps:

 1. Disable QH as a keyboard monitor:

    a. Press ALT+Q (to invoke QH).

    b. Press O (for the Options menu).

    c. Press T (to Terminate the monitor).

 2. Copy the up-to-date version of MSHELP.DLL from the distribution
    disk:

    a. Insert the Setup/Compiler 1 Disk into Drive A.

    b. Change the default Drive A.

    c. Run Setup with the /copy option by typing the following:

          setup /copy

    d. Press ENTER

    e. Press ENTER again (unless the setup files are in a drive other
       than A).

    f. At the prompt asking for the name of the file to copy, type
       MSHELP.DLL and press ENTER.

    g. At the prompt asking for the name of the directory to which to
       copy this file, type the directory in which the old MSHELP.DLL
       is located (most likely C:\OS2\DLL).

    h. Setup should then ask for the Programmer's WorkBench/Utilities
       for OS/2 Disk to be inserted into the setup drive.

    i. When Setup is finished copying the file, press ENTER at the
       next prompt.

 The PWB should now start up correctly.


 9. U1355 Bad Command or File Name

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr filename
 Last Modified: 27-SEP-1990    ArticleIdent: Q61607

 The following undocumented error may occur when attempting to run an
 executable file such as CL.EXE, LINK.EXE, NMAKE.EXE, etc., from inside
 the Programmer's WorkBench (PWB).

    U1355 Bad Command or File Name

 The error occurs because the directory containing the .EXE file is not
 specified in the search path or an incorrect LINK.EXE is being
 executed.

 This problem can be corrected by adding the missing directory name(s)
 to the path in the AUTOEXEC.BAT or STARTUP.CMD and rebooting, or
 executing NEW-VARS.BAT or NEW-VARS.CMD. If an incorrect linker is the
 problem, the search path can be rearranged to find the new version of
 the linker first, or the old linkers can be deleted or renamed.
 Finally, it may be necessary to delete the CURRENT.STS and PROG.STS
 files before the PWB will work correctly. This error is not documented
 in the PWB online help.


 10. Saving Compiler Results File in the PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-MAY-1990    ArticleIdent: Q61636

 The Programmer's WorkBench (PWB) deletes the compiler results file
 upon exiting the PWB. In DOS or OS/2, the file can be saved if the
 compiler results window is made current and the File.Save As menu
 option is selected.

 The compiler results file will appear similar to the following:

    +++ PWB  [E:\] Rebuild
            NMAKE  /z /a /f E:\pwb.mak
         cl /c /W4 /Fm /Ot /FoGLOBL.obj GLOBL.C
    Microsoft (R) C Optimizing Compiler Version 6.00
    Copyright (c) Microsoft Corp 1984-1990. All rights reserved.

    GLOBL.C
         echo @GLOBL.lrf > NUL
         link @GLOBL.lrf

    Microsoft (R) Segmented-Executable Linker  Version 5.10
    Copyright (C) Microsoft Corp 1984-1990.  All rights
    reserved.

    Object Modules [.OBJ]: GLOBL.obj,GLOBL.exe,NUL, /NOD:SLIBCE
    SLIBCEP , /NOI /BATCH /EXE /FAR /PACKC;


 11. Programmer's WorkBench Edit Switch Is Unimplemented

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 14-MAY-1990    ArticleIdent: Q61642

 The edit switch for the Programmer's WorkBench (PWB), documented on
 Page 79 of the version 6.00 "Microsoft C Reference" manual, is
 unimplemented in PWB version 1.00. The switch is designed to set the
 active file as read-only so that it cannot be edited.

 If you add an option in your TOOLS.INI file under the PWB tag to read
 either

    Edit:yes
    Edit:no

 PWB will return an error message saying "Edit is not an editor
 switch."

 As a workaround, invoke PWB with the /r option to open up the current
 file as read-only.


 12. Certain Key Sequences Cause R6003 or SYS1943 in PWB 1.00

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10
 Last Modified:  4-FEB-1991    ArticleIdent: Q61660

 In the Programmer's Workbench (PWB) version 1.00, it has been observed
 that certain unusual editing sequences can cause the following errors:

 In DOS:

    Run-time error R6003 - integer divide by 0

 In OS/2:

    SYS1943 protection violation, trap number 13

 The following sequences reproduce the errors:

    Procedure                             Keystrokes
    ---------                             ----------

 1. Bring up several files.               ALT+F O x3
    Select the Options menu.              ALT+O
    Select Linker options.                L
    Select Set Debug Options.             ALT+G
    Pull up help on the options.          F1
    Arg-refresh through several files.    ALT+A SHIFT+F7 x3
    Escape back to the Editor screen.     ESC x3

 2. Select the Options menu.              ALT+O
    Select Editor Settings.               S (or K)
    Go down thirteen lines.               DOWN ARROW key x13
    Backspace.                            BACKSPACE
    Undo.                                 ALT+BACKSPACE

 Note: Step 2 reproduces only the R6003 error in DOS, not the SYS1943
 error.


 13. PWB 1.00 Requires Decimal Value for Stack Size in LINK Options

 Product Version(s): 1.00    | 1.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10
 Last Modified:  5-FEB-1991    ArticleIdent: Q61871

 In the Programmer's WorkBench (PWB) version 1.00, there is a problem
 with changing a program's stack size in some situations. When
 specifying the stack size in the Link Options dialog box (from the
 Options menu), you must enter the value in the form of a decimal
 integer. Although the Help menu tells you this field accepts positive
 integers in octal and hexadecimal form, PWB 1.00 will not accept them.

 When an octal or hexadecimal value is entered in the stack-size field,
 any digits specified as A-F are discarded and replaced by 0 (zero). If
 digits precede a letter, the digits are retained and the letters are
 discarded.

 Microsoft has confirmed this to be a problem in PWB version 1.00. This
 problem was corrected in PWB version 1.10.


 14. SYS0002 Produced If MSHELP.DLL Not Installed

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | pwbhelp
 Last Modified: 23-JAN-1991    ArticleIdent: Q61955

 Under OS/2, if MSHELP.DLL is not installed correctly or is not on the
 LIBPATH, the following error may appear in a window when starting the
 Programmer's WorkBench (PWB):

                     Cannot Autoload Extension
                     e:\c600\binp\pwbhelp.pxt
 MSHELP:  SYS0002:  The system cannot find the file specified

                         < OK >   < Help >

 Make sure that the latest version of MSHELP.DLL (the one that was
 included with the Microsoft C Compiler version 6.00) is installed in a
 directory contained in your LIBPATH.

 If this file was not copied off the disks during setup, you can
 execute the following command with your Setup disk in Drive A:

    a:setup /copy

 Specify the file MSHELP.DLL at the prompt, then specify the
 destination directory.

 The default for SETUP.EXE is to put OS/2 DLLs in the C:\OS2\DLL
 directory. If you choose to install the DLLs in some other directory,
 you must edit the LIBPATH in your CONFIG.SYS file and restart the
 system.


 15. Enabling of Source Browser Menu Related to .BSC and .MAK Files

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 29-MAY-1990    ArticleIdent: Q61968

 The Source Browser feature of the Programmer's WorkBench (PWB) is
 enabled or disabled depending upon the existence of a database file
 (.BSC file) AND a program list (.MAK file). The existence of a .BSC
 database file alone does not guarantee that the Browse menu will be
 enabled for all modules in a project, even if the .BSC file was built
 from .SBR files for every module. The setting of a program list is
 also required.

 Thus, if a .BSC file is built outside of the PWB with PWBRMAKE, then
 upon entering the PWB, the Browser will be enabled for only one module
 at most (see below). The easiest method to enable the Browse menu for
 ALL modules is to select "Set program list" on the Make menu, then
 type in the base name of the .BSC file (with the .MAK or no extension)
 when it prompts you for the filename. If the .MAK file you enter does
 not exist, then the dialog box appears for adding files to the program
 list, whereas you can just select "Save List" without actually adding
 any files. At this point, the Browser menu will be enabled for all
 files you bring up into the PWB editor.

 The existence of a Source Browser database file means that the Browse
 menu will be enabled for a source file with a matching base name of
 the .BSC file.

 For example, assume a project consists of several modules, with the
 main source module called PROJECT.C. In addition, assume a Browser
 database file called PROJECT.BSC is built from the .SBR Browser
 information files produced by the compiler for every module in this
 project. If the file PROJECT.C is brought up in the PWB, the Browse
 menu will be enabled because the base name (PROJECT) is the same as
 the base name of the database file PROJECT.BSC.

 On the other hand, if any of the other source files in the project are
 opened in the PWB, the Browse menu will be disabled because the base
 names do not match the base name of the database file. Also, if
 PROJECT.C is made the current file (which enables the Browse menu) and
 an option is selected on the browse Menu, such as "Goto Reference"
 (which causes a jump to a different module), the Browse menu will
 become disabled. The only way to re-enable the Browse menu in this
 case is to make PROJECT.C the current file again.

 The way to enable the Browse menu for all modules is to set a program
 list to a file with the .MAK extension and the same base name as the
 .BSC file. Thus, in the example above, setting the program list to
 PROJECT.MAK will enable the Browse menu for all modules. In fact, this
 connection between the .BSC file and the .MAK file enables the Browse
 menu for the modules in the current project, and for ANY file opened
 under the PWB.

 The result is that if you bring up a file in the editor that is
 completely unrelated to the current project (and may not even have a
 related .BSC file), you can still use the Browse menu options.
 However, in this situation, the information available from the Browser
 still only pertains to the original project.

 In summary, the .MAK file and .BSC file relationship is based solely
 on the file existence, NOT the file contents. The program list does
 NOT need to contain the names of the modules in the current project
 (or even be an actual makefile) for the Browser to function.


 16. Modifying TOOLS.INI May Have No Effect on PWB Environment

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 17-JUL-1990    ArticleIdent: Q62170

 Changing settings in the TOOLS.INI file to modify the behavior of the
 Programmer's WorkBench (PWB) may not work under certain circumstances.
 For instance, if you decide to change the PWB to 50-line mode by
 setting "height:50" in the TOOLS.INI file, it will not work if the PWB
 was previously used in the 25- or 43-line mode.

 This is because some environment information is also recorded in the
 CURRENT.STS file, which is read in after the TOOLS.INI file --
 overriding the TOOLS.INI settings.

 The following are three workarounds for this problem:

 1. Use the /DS switch when invoking the PWB. This will ignore the
    CURRENT.STS file. However, this option also causes the current file
    history (of files being edited) to be ignored.

 2. Delete the CURRENT.STS file. This also causes the current list of
    programs being edited to be ignored.

 3. The better option is to select Editor Settings from the Options
    menu. When the list of editor switch settings appears, it can be
    changed and saved to the TOOLS.INI file by pressing SHIFT+F2. This
    will save the settings and cause the selection to take effect.


 17. Reversing Mouse Buttons in the PWB Cannot Be Done

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q62330

 Currently under the Programmer's WorkBench (PWB) released with version
 6.00 of the Microsoft C Optimizing Compiler, it is not possible to
 reverse the functionality of the mouse buttons.

 It is possible to change the functionality of the mouse buttons under
 OS/2 and DOS, but this will be overridden by the PWB environment.


 18. Attempting to Expand a Help Dialog Box Hangs DOS

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 25-JUL-1990    ArticleIdent: Q62331

 When one of the pull-down menus in the Programmer's WorkBench (PWB)
 version 1.00 is selected (File, Edit, View, etc.) and then F1 is
 chosen for help on that menu, a small help screen appears. If CTRL+F10
 is chosen in an attempt to expand the window to full screen, the
 machine will hang under DOS. If the machine doesn't hang, it may
 require another invocation of CTRL+F10 to cause the problem.

 Under OS/2, the machine may not hang, but the PWB's functionality will
 be disrupted and attempts to free oneself may cause a GP fault. It may
 be possible to exit the PWB, but at the very least, the CURRENT.STS
 file will be corrupted so that future entrances to PWB will result in
 very odd window configurations.

 Microsoft has confirmed this to be a problem with the PWB version
 1.00. We are researching this problem and will post new information
 here as it becomes available.


 19. PWB Doesn't Update Mark Location If Mark Moves Up or Left

 Product Version(s): 1.00 | 1.00
 Operating System:   OS/2 | 1.00
 Flags: ENDUSER | buglist1.00
 Last Modified: 13-JUN-1990    ArticleIdent: Q62388

 If you set a mark in a file, and that location then moves upward or
 toward the left in the file, PWB does not reset the mark location;
 however, it does correctly update marks that move downward or to the
 right in the file.

 Consider the following file:

 /* Test.dat */
 test1

 test2

 test3

 Place the cursor on the "2" in test2. Choose the Search.Define Mark
 menu option. Name the mark "mark1" and press ENTER. Now, move the
 cursor to another location in the file. Choose the Search.Go To Mark
 option from the menus. Go to "mark1". Note that the cursor is back on
 the "2" in test2.

 Next, add another blank line between test1 and test2. Again, move your
 cursor and go to mark1. Note that the cursor is back on the "2" in
 test2.

 Now, delete both the lines between test1 and test2. Select the
 Search.Go To Mark option from the menus. Note that the cursor is on
 the same location as it was before you deleted these lines. The same
 behavior will happen if you delete any of the characters before the
 "2" in the test2 line.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench (PWB) version 1.00. We are researching this problem and will
 post new information here as it becomes available.


 20. PWB 1.00 "Set Dependencies" Fails with Spaces in #include Line

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10 s_c
 Last Modified:  5-FEB-1991    ArticleIdent: Q62578

 The Programmer's WorkBench (PWB) version 1.00 (shipped with C version
 6.00) includes a "Set Dependencies" option in the "Set Program List"
 window. This option automatically sets up build dependencies for all
 include files used in the current project. This option will fail with
 a message that the include file does not exist if there are embedded
 spaces between the left angle bracket (<) and the include-file name in
 an include directive line.

 The Set Dependencies option will work correctly if the space(s) are
 removed or if a new build option is added to the TOOLS.INI file.

 Although embedded spaces are legal in C programming syntax, the
 Programmer's WorkBench fails to parse the include line correctly if
 spaces exist before the filename. The following line of code shows the
 situation where the "Set Dependencies" error will occur:

    #include < stdio.h >

 The space before the "s" in stdio.h prevents PWB from finding the
 STDIO.H include file. (The trailing space after stdio.h does not
 affect the behavior of "Set Dependencies".)

 The full text of the error message window for the line above is as
 follows:

         stdio.h does not exist
    Cannot build its dependency tree.
    Abort dependency lists generation?
         <Yes>    <No>    <Help>

 Selecting <Help> displays a help screen that describes the problem as
 being either a mistyped filename or a nonexistent file, but the actual
 file DOES exist. Removing the embedded space will correct the problem.

 You can also add two new "build" lines to the TOOLS.INI file to make
 the PWB recognize include directives that contain spaces. These lines
 should be included under the section with the [PWB] tag, and should
 have the following syntax:

    build: include .c                                              \
        "^[ \t]*#[ \t]*include[ \t]*\"[ \t]*\\([^\"]+[ \t]*\\)\""  \
        case
    build: include .c                                              \
       "^[ \t]*#[ \t]*include[ \t]*<[ \t]*\\([^>]+\\)[ \t]*>"      \
        case system

 (Note: These build switch statements are broken down into multiple
 lines with the line continuation character (\) because of space
 limitations; you may enter each of them into the TOOLS.INI file on a
 single line, rather than multiple lines.)

 There is one drawback to this workaround; you will still get the error
 message shown above because the "old" build switch is applied before
 the new one. To have the new build switch take effect, you need to
 select "No" when prompted to abort the dependency list generation.
 Once you have selected "No" for each file with spaces in the include
 directive, the dependencies will then be generated correctly.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.00. This problem was corrected in the Programmer's
 WorkBench version 1.10.


 21. PWB 1.10 Dialog Boxes May Blink After Dialog Help Is Obtained

 Product Version(s): 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.10 flicker
 Last Modified: 19-FEB-1991    ArticleIdent: Q69347

 When working with the Programmer's WorkBench (PWB) version 1.10 under
 DOS, there are several instances where a dialog box may start flashing
 incorrectly. This situation occurs when you obtain help on a PWB
 informational pop-up dialog box and then return from the Help dialog
 screen. At this point you may find that the original dialog box is
 rapidly blinking.

 This problem may occur when trying to get help on a topic for which
 there is no help, trying to use an unassigned key, or when PWB informs
 you that you changed a file but didn't save it before you tried to
 exit. In each of these cases, PWB gives you a pop-up dialog box
 informing you of the situation. If you get help on this informational
 dialog box and then press ESC or click Cancel, the original dialog box
 will start blinking.

 This is not normal behavior, however, PWB is still fully functional
 and you may proceed by selecting an appropriate choice from the
 flashing dialog box.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.10. We are researching this problem and will post
 new information here as it becomes available.


 22. R6000 Stack Overflow After Deleting Current Makefile

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q62668

 If you are viewing your makefile in a window in PWB 1.00, then delete
 the makefile from a shell; attempting to make the window containing
 the makefile active will cause a run-time error R6000, stack overflow.

 To duplicate this problem, bring up a sample program and set the
 program list to that file's makefile. Next, open up another window
 and open the makefile in that window. Now, either from the Run.Run
 <DOS-OS/2> Command menu or the File.<DOS-OS/2> Shell, delete that
 makefile.

 After returning back to the PWB, make the window containing the
 makefile the active program list either by pressing the F6 key to
 toggle windows or by clicking the left mouse button in that window.

 You will be faced with a popup message saying "File has been deleted
 from disk. Delete from memory?" Answering "yes" brings up the popup
 six to eight more times. Then, PWB will abort to the system prompt
 with an R6000 (stack overflow) error message and another message, "File
 has been deleted from disk."

 Microsoft has confirmed this to be a problem in PWB version 1.00. We
 are researching this problem and will post new information here as it
 becomes available.


 23. PWB 1.00 Extensions Only Return True Under DOS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 15-AUG-1990    ArticleIdent: Q63052

 Extensions written for use by the Programmer's WorkBench (PWB) version
 1.00 under the DOS operating system are recognized as returning true
 regardless of their actual return values.

 The use of return values as a way of providing conditional jumps
 inside PWB macros is a common practice that is affected by the above
 limitation for PWB extensions. The following sample extension and
 macro demonstrate the above problem. Once installed, both the foo()
 and foo2() functions will be seen as returning true to PWB.

 Sample Code
 -----------

 // foo.c

 #include <string.h>
 #include <stdlib.h>
 #include <ext.h>

 PWBFUNC foo( unsigned argData, ARG far *pArg, flagType fMeta );
 PWBFUNC foo2( unsigned argData, ARG far *pArg, flagType fMeta);

 // Switches.
 struct swiDesc swiTable[] =
 {
    { NULL, NULL, 0 }
 };

 // Commands.
 struct cmdDesc cmdTable[] =
 {
    { "foo", foo, 0, NOARG },
    { "foo2",foo2,0, NOARG },
    { NULL, NULL, 0, 0 }
 };

 void EXTERNAL WhenLoaded()
 {
     SetKey( "foo",         "alt+f" );
     SetKey( "foo2",       "ctrl+f" );
     return;
 }

 PWBFUNC foo( unsigned argData, ARG far *pArg, flagType fMeta )
 {
  return(FALSE);  /* FALSE is defined as 0 in ext.h */
 }

 PWBFUNC foo2( unsigned argData, ARG far *pArg, flagType fMeta)
 {
  return(TRUE);   /* TRUE is defined as 1 in ext.h  */
 }

 // End of foo.c

 ; macros in tools.ini to test foo and foo2

 load foo

 test:=foo ->loc1 arg "true" message => :>loc1 arg "false" message
 test2:=foo2 ->loc2 arg "true" message => :>loc2 arg "false" message

 test:alt+t
 test2:ctrl+2

 Microsoft has confirmed this to be a problem with PWB version 1.00. We
 are researching this problem and will post new information here as it
 becomes available.


 24. PWB Text Highlight with Mouse Acts Strange After Search

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-AUG-1990    ArticleIdent: Q63059

 The click-and-drag method of selecting text with the mouse in the
 Programmer's Workbench (PWB) sometimes works incorrectly when used
 after a search function.

 To reproduce this problem, do the following:

 1. Select a word in the text using the mouse (double-click on a single
    word).

 2. Execute the search function (select the Search menu, choose Find,
    then OK).

 3. Now try to highlight the text a few lines below the word you used
    to search on (using the click-and-drag method).

 The text will be highlighted starting at the original word that was
 searched for, rather than at the starting mouse position.

 To work around this problem, click the left button anywhere in the
 text window, then perform the text highlight.

 Microsoft has confirmed this to be a problem with the Programmer's
 Workbench version 1.00. We are researching this problem and will post
 new information here as it becomes available.


 25. PWB Does Not Return from DOS Shell with ";" in TMP

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q62702

 If there is a semicolon ";" in your TMP environment variable, you may
 not be able to return to the Programmer's Workbench by typing "exit"
 after selecting "DOS Shell" from the File menu in PWB.

 Since the TMP environment variable is used to specify a single
 directory rather than a path, the semicolon character should not be
 used.

 To re-create this situation, type the following at the command line:

    set TMP=C:\TMP;

 Then select DOS Shell from within PWB. Typing "exit" on the DOS
 command line will not bring you back into PWB.

 To correct the problem, remove the semicolon from the end of the TMP
 environment variable.


 26. PWB BACKUP.BAK Does Not Create Backup of Source File Correctly

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER| buglist1.00
 Last Modified: 24-JUL-1990    ArticleIdent: Q63234

 Version 1.00 of the Programmer's Workbench does not create a backup of
 your source file correctly if the PROJECT.MAK has the same base name
 as the SOURCE.C file. When you build or rebuild the project, the file
 saved as your backup is a copy of the CURRENT.STS file.

 A workaround to this problem is to name your PROJECT.MAK with a
 different base name than your SOURCE.C file. This will still save a
 copy of your CURRENT.STS file with the base name of the PROJECT.MAK.
 However, it will correctly save a backup of the SOURCE.C as
 SOURCE.BAK.

 Microsoft has confirmed this to be a problem in version 1.00 of the
 Programmer's Workbench and will post new information here as it
 becomes available.



 27. PWB menukey Switch Resets to ALT When Shelling Out to DOS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 10-JUL-1990    ArticleIdent: Q63267

 If the "menukey" switch in the DOS version of the Programmer's
 Workbench (PWB) version 1.00 is set to anything other than ALT (which
 is the default), it will be redefined to the ALT key after shelling
 out to DOS. This means the menukey switch will lose its assignment
 anytime you choose Compile, Run Program, Debug Program, or DOS Shell.

 The menukey switch determines which keystroke activates the PWB main
 menu bar. The ALT key is normally used for this, but menukey can be
 redefined to any keystroke. For example, menukey is automatically
 defined to F9 if you select Brief Editor emulation when installing the
 Programmer's WorkBench.

 Whenever you invoke any function (such as Build) that goes out to DOS
 for execution and then returns, the menukey switch is reset to ALT, so
 that both ALT AND the user-defined keystroke invoke the menu.

 To work around this problem, you can use the Restart command to invoke
 a macro that redefines the menukey to the desired value each time you
 return from a DOS SHELL command, which will then keep ALT from
 activating the menu. For example, to make it so that F9 is always
 reset as the only menukey, put the following line in the PWB tagged
 section of the TOOLS.INI file:

    restart:= arg "menukey:F9" assign

 Since the Restart command, if it exists in TOOLS.INI, is invoked
 automatically when returning from a SHELL command, this guarantees
 that the key assignment will always remain consistent.

 Microsoft has confirmed that the automatic reactivation of ALT as the
 menukey is a problem with the Programmer's WorkBench version 1.00. We
 are researching this problem and will post new information here as it
 becomes available.


 28. PWB: Print Does Not Put CR/LF at EOL If Text Selected

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 25-JUL-1990    ArticleIdent: Q63318

 Using the Programmer's Workbench version 1.00, when a region of text
 is selected and the Print function is invoked, the resulting output
 contains linefeed characters (0x0A) at the end of each line, rather
 than a carriage return/linefeed (<CR><LF>) combination (0x0D and
 0x0A).

 Some printer drivers do not recognize this as a valid end-of-line
 (EOL) character and do not print correctly.

 To reproduce this problem, open a file that contains the <CR><LF>
 combination at the end of each line. Highlight a region of text in the
 file and from the File menu choose Print. Tab to the second field and
 type in the following:

    copy %s test.txt

 This will copy the region of selected to the file TEST.TXT. Using a
 standard hex file viewer, you can see that the end of a line is
 denoted by a single 0A. If you look at the original file using the hex
 viewer, it will contain 0A 0D at the end of each line.

 The Programmer's Workbench will recognize this type of file (with a
 single 0A at each end of line) and display it correctly if you try to
 open it within the Workbench, but many printer drivers do not
 understand this type of file.
 The workaround for this problem is to write a program that translates
 each 0x0A found in the output file to the bytes 0x0D and 0x0A, or use
 a printer driver that understands this type of file. In fact, most
 printers have an escape sequence or dip switch to make it recognize
 this type of file.

 Microsoft has confirmed this to be a problem with the Programmer's
 Workbench version 1.00. We are researching this problem and will
 post new information here as it becomes available.


 29. Unknown Function psrch with Brief Emulation in PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q63319

 When using the Brief emulation feature of the Programmer's WorkBench
 version 1.00, reinitialization of the TOOLS.INI file will cause a
 number of unknown functions to appear when you try to use them. In
 short, most of the unknown functions that may be reported are related
 to search features such as the psearch switch. The error message
 associated with this search feature is commonly "Unknown function
 psrch."

 This error occurs only after you use the Initialize function.

 The Initialize function discards current macro definitions and rereads
 the appropriate section of TOOLS.INI. This is not exactly the same as
 restarting PWB; the Autostart macro is not executed after Initialize.
 The BRIEF emulation depends on the Autostart macro to define the
 search functions.

 To recover the definition of the missing macros, execute the toggle_re
 BRIEF emulation macro (CTRL+F6). To avoid having to remember to
 execute this macro, you can add this to the main section of TOOLS.INI:

    reinit:=Initialize Autostart
    reinit:Shift+F8

 Or you can define the macros as follows:

    psrch:=arg arg "String to Search for" prompt ->can
                                            psearch => :>can cancel
    msrch:=arg arg "String to Search for" prompt ->can
                                            msearch => :>can cancel
    qrepl:=arg arg qreplace
    srchname:="REoff"


 30. Problems Viewing README.DOC Inside PWB Online Help and QH

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER  |
 Last Modified: 15-AUG-1990    ArticleIdent: Q63661

 Problems can occur when attempting to access the README.DOC from
 within the DOS versions of Programmer's WorkBench (PWB) or QH via the
 online help.

 When attempting to view the README.DOC file using the online help
 inside the DOS version of PWB, the messages "Error displaying help"
 and then "Cannot process cross reference" may be displayed in
 successive dialog boxes.

 When attempting to view the README.DOC file from within QH, the
 message "The database README.DOC is not open, or the topic is not
 found" may be displayed.

 Again, these problems are found only in the DOS version of PWB and QH.
 Access of the README.DOC in this manner does not produce errors under
 the OS/2 versions of PWB or QH.

 The following are two possible workarounds for the problem in PWB:

 1. The README.DOC can be loaded into the help system by typing the
    following

       arg "$PATH:readme.doc!" arg pwbhelp

    with default keys:

       Alt+A $PATH:readme.doc! F1

    Note that this method may fail if there is another file named
    README.DOC in the path before the C 6.00 README.DOC. If this is the
    case, the other README.DOC will be loaded instead of the C 6.00
    README.DOC. This method can also fail if there is not enough memory
    to load the file into the help system.

 2. If the previous method fails, the C 6.00 README.DOC can be loaded
    into PWB as a normal text file via the File.Open menu option. The
    README.DOC can be found in the C 6.00 bound executable directory
    (for example, C:\C600\BINB).

 The following are three possible workarounds for the problem in QH:

 1. Inside QH, select View.Search, type "$PATH:readme.doc!" and press
    ENTER. Again, this will bring up the first README.DOC on the path.

 2. You can also select File.Open and load the the file by giving the
    full path and filename of the C 6.00 README.DOC. QH allows you to
    open any text file under 64K in size.

 3. To enable direct access of the README.DOC from within QH via the
    README.DOC button, it is necessary to point the QH environment
    variable to the directory where the README.DOC is located. For
    example:

       set qh=c:\c600\binb\readme.doc

    The QH environment variable is not documented in the C 6.00 printed
    or online documentation.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 31. CTRL+NUM/ May be Read as CTRL+/ in DOS with NUM LOCK On

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.10
 Last Modified: 15-NOV-1990    ArticleIdent: Q66740

 In versions 1.00 and 1.10 of Programmer's WorkBench (PWB), the
 CTRL+NUM/ (CTRL+/ on the numeric keypad) and ALT+NUM/ (ALT+/ on the
 numeric keypad) combinations may be interpreted as CTRL+/ and ALT+/
 (on the main keyboard). This problem happens only in DOS or the OS/2
 DOS 3.x box, and only on certain computers. This behavior will cause
 any macro or function assigned to CTRL+NUM/ or ALT+NUM/ to not execute
 when NUM LOCK is on.

 To reproduce this problem, assign a function or macro to CTRL+NUM/.
 Then execute the TELL function (CTRL+T by default) and press CTRL+NUM/.
 The TELL function prompts for a keystroke, then displays the name of
 the keystroke and the function assigned to it. With NUM LOCK on, TELL
 will return the following:

    unassigned:Ctrl+/.

 With NUM LOCK off, TELL will return the following:

    <function name>:Ctrl+num/.

 This behavior is identical for the ALT+NUM/ key name, but works
 properly for all other key names on the numeric keypad.

 If NUM LOCK is off, or if the protected-mode version of PWB is run,
 this behavior does not occur.

 This behavior has been observed on the following machines:

    Northgate 386-33
    PS/2 Model 70
    PS/2 Model 80-311

 Microsoft has confirmed this to be a problem in PWB version 1.00 and
 1.10. We are researching this problem and will post new information
 here as it becomes available.


 32. PWB Command-Line Option /DP Is Documented But Not Implemented

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 27-JUL-1990    ArticleIdent: Q63951

 The /DP switch for the Programmer's WorkBench (PWB), documented on
 Page 49 of the version 6.00 "Microsoft C Reference," is not
 implemented in version 1.00 of the PWB. This switch is designed to
 ignore the most recent program list upon starting the PWB.

 The /DP switch is mentioned only in the "Microsoft C Reference" and
 not in the online help.

 Upon invocation, the Programmer's WorkBench version 1.00 does not
 automatically set the program list to the last program list used.
 Therefore, the /DP command-line switch was not implemented because it
 would have no purpose.

 With the PWB version 1.00, there is no way to have the last program
 list set automatically at startup.


 33. With the "deflang" Switch PWB Prompts for Setting Program List

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  3-AUG-1990    ArticleIdent: Q64353

 As documented on Page 79 of the "Microsoft C Reference" shipped with C
 version 6.00 and in the online help, the "deflang" switch in the
 Programmer's WorkBench (PWB) sets the default filename extension for
 list boxes in PWB dialog boxes. Another (undocumented) feature of this
 switch is to enable you to be prompted to "Set Program List?" when
 loading a source file with a .MAK file associated with it in the
 current directory.

 By default, "deflang" is not set. You can set the deflang switch in
 the [PWB] tagged section of the TOOLS.INI file, for example:

    deflang:C

 This changes the default filename extension in the PWB's dialog boxes
 (such as Open in the File menu) from "*.*" to "*.c", so that only
 files with the .c extension show up by default. Other languages can be
 specified as well, as shown below:

    Switch Setting     Extension
    --------------     ---------

    no value            .*
    C                   .c
    Asm                 .asm
    BASIC               .bas
    FORTRAN             .for
    Pascal              .pas
    COBOL               .cbl
    LISP                .lsp

 Note that the online documentation specifies "Assembler" as the switch
 to use for .ASM files, but this is incorrect. "Asm" is the correct
 switch to use to make Assembler the default language.

 The deflang switch also enables you to be prompted as to whether or
 not the program list should be set automatically. If you load a file
 that has the extension specified by the "deflang" switch and you also
 have a .MAK file with the same base filename in the same directory,
 the PWB will prompt you about loading the program list.

 For example, assume that deflang is set to C and FOO.MAK and FOO.C are
 in the same directory. If you type PWB FOO.C at the command-prompt,
 the PWB will pause when loading and prompt with "Set Program List?
 FOO.MAK". At this point you can specify <yes> or <no>.

 When already in the PWB, if you select Open from the File menu, and
 select FOO.C as the file to open, the PWB will also prompt you at this
 point regarding whether or not you want FOO.MAK loaded as the program
 list, but only if NO program list is currently set.


 34. Can't Resize a Window with a Macro in PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-AUG-1990    ArticleIdent: Q64433

 A window cannot be resized using the "resize" function in a macro.
 After Programmer's WorkBench (PWB) performs the resize function, it
 waits for the you to respond with the UP ARROW or DOWN ARROW key.
 Functions that are placed in the macro after the resize function are
 ignored. If "record on" is selected and you try to record the resizing
 of a window, the macro will stop recording until the ENTER key on the
 numeric keypad is pressed.

 The following is an example:

    resizeit:= cancel arg arg nextmsg window resize up up up NumEnter

 The above example stops at the resize function and waits for you to
 resize the window. The remaining functions are ignored.

 To make a window a specified size, move the cursor to a location on
 the screen and then open the window with the "window" function.

 The following is an example of a macro that opens the "<compile>"
 window with a specified size:

 compile_size:= up up up up up up up up up up
 resize_it:=cancel meta down compile_size arg window window arg \
            "<compile>" setfile window
 resize_it:ALT+U

 Note: The size of the compile window can be adjusted by changing the
 number of ups on the compile_size line.


 35. PWB Hangs When Run with Some Communication Programs Under OS/2

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 30-AUG-1990    ArticleIdent: Q64435

 When running Programmer's WorkBench (PWB) under OS/2 while
 simultaneously running communication programs, PWB will appear to
 hang. To correct the problem, terminate any communication programs and
 PWB will resume as normal.


 36. "Cannot Open File current.$" May Mean Incorrect INIT Variable

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 17-DEC-1990    ArticleIdent: Q64566

 When using the Programmer's Workbench (PWB), the following message may
 appear as a pop-up dialog box when selecting Compile or DOS Shell (or
 OS/2 Shell for OS/2):

    +----- Cannot open file! -----+
    |   D:\TEST\SRC\X\current.$   |
    |  No such file or directory  |
    |-----------------------------|
    |      < OK >   < Help >      |
    +-----------------------------+

 One cause for this error is an incorrect setting of the INIT
 environment variable. To remedy the situation, exit PWB and make sure
 that the INIT environment variable is set to a valid directory name
 (for example, a directory that exists).

 To reproduce this message, set your INIT environment variable to an
 invalid directory, for instance (if a directory named X does not exist
 on your drive):

    SET INIT=X

 Then start PWB and try to compile a program. The message will appear
 in the middle of the screen.

 One possible reason why your INIT environment variable may be set
 incorrectly, even if your AUTOEXEC.BAT sets it correctly, is that you
 might have run out of environment space in the setting of the
 variable. You can refer to the "MS-DOS Encyclopedia," Article 2, for
 more information about increasing your environment space.


 37. How to Use the PWB with the Windows 3.00 SDK

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-AUG-1990    ArticleIdent: Q64788

 Detailed step-by-step instructions on how to set up the Programmer's
 WorkBench (PWB) for use with the Windows version 3.00 Software
 Development Kit (SDK) can be found in a file provided with the SDK
 called PWBINFO.WRI.

 The file explains how to set PWB switches so that Windows applications
 can be built from within PWB. The file also explains how to access the
 SDK's online help.

 This file can be viewed and printed with the WRITE program, which is
 packaged with the Windows 3.00 package.


 38. Tips for Using the Microsoft Advisor Online Help

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_quickc s_c s_qh
 Last Modified: 23-JAN-1991    ArticleIdent: Q64829

 The following are some tips for more effectively using the online
 documentation included with the Microsoft C Compiler version 6.00
 Programmer's Workbench (PWB) as well as the Microsoft Advisor
 command-line help system:

 1. Finding help on a topic for which the exact name is not known.

    If the exact spelling of a topic is not known, the help for that
    topic can't be accessed directly (for instance, by using the F1 key
    in PWB), but it can usually be found indirectly.

    By using the table of contents and selecting links that pertain to
    the subject in question, the topic can usually be found. To get to
    the table of contents from within QuickHelp, select the Categories
    menu, then "C 6.00".  From within PWB, choose the Help menu, then
    select Contents.

    If you know the general spelling of the topic, an alphabetical
    index is available by choosing Index from the main contents screen.

 2. "Paging" through the online documentation.

    The online documentation can be "paged through" like you would page
    through a manual.

    In PWB, CTRL+F1 takes you from one topic to the next sequential
    topic in the help file. In QuickHelp, Choose Next or Back from the
    View menu to move in either direction.

 3. Scanning a list of available topics (as in a printed index).

    There are alphabetical indices for every major component of the
    product. Just choose Index from the main contents screen and select
    the appropriate topic.

 4. Techniques for using the online help.

    For more information on how to use the help system, as well as on
    the general organization and structure of the help system, choose
    Using Help from the main contents screen.

    For additional help, see Chapter 4, "Using the On-Line Reference,"
    of the "Microsoft C Installing and Using the Professional
    Development System" manual that comes with C version 6.00.

 5. Printing out the online help files.

    By using the HELPMAKE utility, the help files can be decoded to
    readable text files, which can then be printed. For more
    information about the HELPMAKE utility, see Chapter 7 of the
    "Microsoft C Advanced Programming Techniques" manual that comes
    with C version 6.00.


 39. Predefined Identifiers in Microsoft C 6.00

 Product Version(s): 6.00   | 6.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_quickhelp s_c s_utils
 Last Modified: 24-OCT-1990    ArticleIdent: Q65472

 The following information is contained in the online help for the
 Microsoft C Compiler version 6.00.

 This information below can be accessed by using the following steps:

 1. Obtain help on the text "cl" using either the F1 key from the
    Programmer's WorkBench, or by using "qh cl" from the DOS or OS/2
    command lines.

 2. Select Preprocessor Options, then Predefined Identifiers.
 The compiler automatically defines identifiers useful in writing
 portable programs. You can use these identifiers to compile code
 sections conditionally. These identifiers are always defined unless
 otherwise stated.

    Identifier       Target Identified
    ----------       -----------------

    MSDOS            MS-DOS operating system
    M_I86            Member of the I86 processor family
    M_I86mM          Memory model type
                     <m> = T    Tiny
                           S    Small (default)
                           C    Compact model
                           M    Medium model
                           L    Large model
                           H    Huge model
    M_I8086          8088 or 8086 processor; default or with /G0
                        option
    M_I286           80286 processor; defined with /G1 or /G2 option
    _MSC_VER         Identifies the version of Microsoft C
    NO_EXT_KEYS      Disables Microsoft-specific language extensions
                        and extended keywords; defined only with /Za
                        option
    _CHAR_UNSIGNED   Changes default char type to unsigned; defined
                        only with /J option

 The _MSC_VER identifier has a value of 600 for the Microsoft C Compiler
 version 6.00. This identifier is not defined in Microsoft C versions
 5.10 and earlier.


 40. How to Add Other Language Compilers to PWB's Build Options

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_pascal b_basiccom s_c h_masm h_fortran b_cobol
 Last Modified: 24-OCT-1990    ArticleIdent: Q65568

 The Programmer's WorkBench (PWB) is an environment capable of
 utilizing different compilers for mixed-language programming. When
 installed during BASIC version 7.10 setup, PWB version 1.10 shows
 build options for the BASIC language only. However, it is possible to
 include other language compilers to utilize the full features of the
 PWB utility.

 The following information applies to the Programmer's WorkBench
 version 1.10 utility supplied with Microsoft BASIC Professional
 Development System (PDS) version 7.10 for MS-DOS and MS OS/2.

 Note that the 1.00 version of PWB is shipped with Microsoft C
 Professional Development System (PDS) version 6.00. The steps below
 should also apply to PWB version 1.00.

 The Programmer's WorkBench (PWB.EXE) is an advanced development
 environment capable of integrating several language compilers,
 NMAKE.EXE, LINK.EXE, and the CodeView debugger. It offers the ability
 to accomplish tasks, such as program development under protected mode
 and mixed-language programming. This ability is not available in the
 QuickBASIC extended development environment (QBX.EXE).

 Two special files, PWBC.PX$ (for protected mode OS/2) and PWBC.MX$
 (for DOS mode), reside on the BASIC PDS 7.10 disks and support the
 option of using the C compiler in PWB. Since SETUP.EXE (in BASIC PDS
 7.10) does not copy PWBC.PX$ and PWBC.MX$ during installation, these
 files must be unpacked and transferred to your machine, for example to
 the \BINP subdirectory located in the \BC7 directory. (Note: The
 UNPACK.EXE utility is found on disk 1 of the BASIC PDS package.) After
 unpacking, the files will have the names PWBC.PXT and PWBC.MXT.

 Next, the following command lines must be added to the TOOLS.INI file
 to make the C compiler available to PWB:

    [pwb - .BAS .BI]
       LOAD: LogicalDrive:\[Path]\PWBC.PXT

 For further information about installing PWBC.PXT and PWBC.MXT, see
 Page 54 of the "Microsoft BASIC 7.1: Getting Started" manual.

 If you want to program in languages other than BASIC or C [such as
 Microsoft Macro Assembler (MASM), Microsoft Pascal, Microsoft FORTRAN,
 or Microsoft COBOL 3.00/3.00a], the following steps will insert the
 initial build options to include other languages to PWB's build
 options menu. In the example below, options to include the MASM.EXE
 assembler are specified. If some other language's compiler is desired,
 substitute appropriate changes for that compiler, where noted in the
 specified areas:

  1. In PWB, go to the Options menu and select Build Options.

  2. Choose Save Current Build Options.

  3. Enter a meaningful message, such as "Options to Include MASM" in
     the window's edit field (if some other language is desired, change
     MASM to the appropriate name). Select the OK button from the "Save
     Current Build Options" and "Build Options" windows.

  4. Open the "TOOLS.INI" file in the PWB utility and go down to the
     bottom of the file. Somewhere near the bottom should be the tag
     "[PWB-Build Options: Options to Include MASM]" (or the language
     that was specified).

  5. In this section, add the following NMAKE instructions:

        build: inference .asm.obj masm_asm_obj
        build: command masm_asm_obj "masm $<;"

     Note: For languages other than MASM, distinguish a variable name
     in the inference rule to be used in the commands line (such as
     masm_asm_obj has been used above) and then specify the appropriate
     compiler in the commands line within the quotation marks. The
     special filename macro specified in the quotation marks, "$<",
     applies the command to any object that has an out-of-date
     executable file.

  6. Press SHIFT+F8 to reinitialize the file and then close it.

  7. Go to the File menu and select New (it is a good idea to close any
     files that are currently open before this step).

  8. Go to the Options menu and select Build Options.

  9. Choose Initial Build Options.

 10. Select the "Options to Include MASM" option (it should be near the
     bottom of the list).

 After completing these instructions, the PWB utility will now be ready
 to compile assembler along with BASIC source code, provided that paths
 to the necessary compilers are furnished.


 41. PWB Err Msg: Out of Local Memory. Unable to Recover.

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-OCT-1990    ArticleIdent: Q65913

 When setting a program list inside of the Programmer's WorkBench
 (PWB), the following message may occur:

    Out of Local Memory.  Unable to Recover.

 The error is printed on the screen and the PWB exits to DOS. This
 error may occur when the program list contains too many names. To
 resolve the problem, combine object modules into libraries whenever
 possible. Remove the .OBJ files from the program list and replace them
 with the new libraries. This will reduce the number of object modules
 that need to be defined in the program list.

 Another method that sometimes helps to alleviate the error is to open
 the File menu and close as many unneeded files as possible. This
 should be done before setting the program list.


 42. Situation Where PWB Online Help Text Disappears

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901010-118 B_BasicCom S_C B_cobol
 Last Modified: 24-OCT-1990    ArticleIdent: Q66229

 When requesting help in Microsoft Programmer's WorkBench (PWB)
 versions 1.00 and 1.10, the following sequence of events will cause
 the Help screen text to disappear, leaving only the hyperlinks.

 This information applies to Programmer's WorkBench version 1.00 (which
 comes with Microsoft C Professional Development System version 6.00
 for MS-DOS and MS OS/2), and to Programmer's WorkBench version 1.10
 (which comes with Microsoft COBOL Professional Development System
 version 4.00 and with Microsoft BASIC Professional Development System
 (PDS) version 7.10 for MS-DOS and MS OS/2).

 Microsoft has confirmed this to be a problem in PWB. We are
 researching this problem and will post new information here as it
 becomes available.
 Follow these steps to reproduce the problem:

 1. From the DOS or OS/2 prompt, enter PWB. From the File menu, select
    New. Type PLINES and request help by pressing F1 or single-clicking
    the right mouse button.

 2. In the Help dialog, double-click the left mouse button with the
    cursor on the hyperlink "Using PWB Functions."

 3. Double-click the left mouse button with the cursor on the hyperlink
    "PWB Functions by Category."

 4. Double-click the left mouse button with the cursor on the hyperlink
    "Moving Through Files."

 5. The vertical scroll bar will show that you are at the bottom of the
    dialog. Press PGUP and you will notice that the hyperlinks to Up,
    Index, Contents, and Back have disappeared. Double-click the left
    mouse button with the cursor on any of these empty hyperlinks; the
    text on the screen will disappear, with empty hyperlinks appearing
    on the screen.


 43. How to Insert Spaces Before a Block of Text in PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_EDITOR
 Last Modified: 24-OCT-1990    ArticleIdent: Q66231

 It is sometimes desirable to indent or move over a block of text in
 the Programmer's WorkBench (PWB) or the M Editor. The following steps
 can be used to insert spaces before a block of text to indent it:

 1. Get into boxarg mode. You can select this mode from the Edit menu
    under the Programmer's Workbench, or select the boxstream function
    under the Microsoft Editor.

 2. Highlight the area you want to contain the spaces. This may be
    anywhere in the file.

 3. Select the linsert function. By default, this is CTRL+N.

 The highlighted area should now be moved over and replaced by spaces.

 You don't have to be in boxarg mode for this to work; linsert always
 treats its argument as a boxarg regardless of the current mode.
 However, the highlight on the screen won't match the area that is
 going to be inserted unless you use boxarg mode.

 Also, ldelete can be used to unindent a block of text. However, you
 must be in boxarg or streamarg mode for it to work correctly. In
 linearg mode, it will delete entire lines.


 44. PWB's Use of Expanded Memory

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-OCT-1990    ArticleIdent: Q66308

 The DOS version of the Programmer's WorkBench (PWB) will utilize
 expanded memory to swap its own segment overlays if it detects that
 expanded memory is available in the system. When PWB needs a new
 overlay, the existing overlay in memory is first copied into expanded
 memory. If there is not enough room in expanded memory to copy the
 overlay, the least recently used overlay is discarded to make room for
 it. This scheme allows most overlays to be read from expanded memory
 instead of from disk.

 Note that this is the only method by which PWB will take advantage of
 available expanded memory, and that PWB versions 1.00 and 1.10 have no
 internal provisions to make use of extended memory in any way.


 45. PWB May Exit to DOS If TMP Not Set Correctly

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 buglist1.10
 Last Modified: 24-OCT-1990    ArticleIdent: Q66309

 If the tmp environment variable is set only to a drive (with no path
 specified), the PWB may "crash" out to DOS when a compile is
 attempted. The screen will still show the PWB, but there will be a
 prompt displayed.

 This problem may be reproduced using the following procedure:

 1. Set up the environment to run the PWB.

 2. Set the tmp environment variable to the current drive, without
    specifying a path. For example:

       SET TMP=C:

 3. Execute the PWB and create or load a simple source file.

 4. Attempt to compile the source file. (Note: If the COMPILE option is
    not available on the make menu, make sure the file has a name with a
    .c extension.)

 Microsoft has confirmed this to be a problem with the Programmer's
 WorkBench versions 1.00 and 1.10. We are researching this problem and
 will post new information here as it becomes available.


 46. MASM Build Switches for PWB 1.10

 Product Version(s): 1.10    | 1.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  5-DEC-1990    ArticleIdent: Q66339

 When setting a program list containing .ASM files in Programmer's
 WorkBench (PWB) version 1.10, the following error message occurs:

    Program List: file 'filename' will be ignored
    File type unused by current build options

 The .ASM files are not recognized because PWB 1.10 does not contain
 build switches specific to any language. Build switches are now loaded
 from language extension files (.MXT for DOS and .PXT for OS/2). If you
 have an assembly language extension file, you will not see this error
 message. Language extensions are not necessary and are only a
 convenience for controlling the build process; only the build switches
 are really needed.

 The following build switches can be added to a tagged section in your
 TOOLS.INI file. To use these build options, first choose your language
 options from the Options Build Options menu, then initialize this
 section by typing {arg} tag_name {reinitialize} (type the following to
 invoke the sample build switch below:

    ALT+A asm_rules SHIFT+F8

 These switches can also be added to a custom set of build options
 saved by Save Current Build Options. They may then be initialized by
 choosing Build Options from the Options menu, and then selecting Set
 Initial Build Options to choose the new custom language options.

 Sample Build Switches
 ---------------------

 [pwb-asm_rules]
 ;
 ;   MASM build rules
 ;
 build:macro ASM "MASM"
 build:macro AFLAGS_G "/Mx /T"
 build:macro AFLAGS_D "/Zi"
 build:macro AFLAGS_R ""
 build:inference .asm.obj as_asm_obj
 build:release command as_asm_obj  \
             "$(ASM) $(AFLAGS_G) $(AFLAGS_R) $<, $@;"
 build:debug command as_asm_obj  \
             "$(ASM) $(AFLAGS_G) $(AFLAGS_D) $<, $@;"
 build:include .asm "^[ \t]*include[ \t]+\\([^ \t]+\\)"
 build:include .inc "^[ \t]*include[ \t]+\\([^ \t]+\\)"

 These assembly flags can then be modified from PWB by using the
 following macros. The macros must be assigned to keystrokes to be
 activated. This can be done using the <ASSIGN> pseudo file. They can
 then be used to redefine the flags to pass to MASM.

 ;
 ;   MASM option-setting macros
 ;
 setAFG:= arg "Global MASM Options?"  prompt -> cancel lasttext home \
         "build:macro AFLAGS_G \"" endline "\"" assign

 setAFD:= arg "Debug MASM Options?"   prompt -> cancel lasttext home \
         "build:macro AFLAGS_D \"" endline "\"" assign

 setAFR:= arg "Release MASM Options?" prompt -> cancel lasttext home \
         "build:macro AFLAGS_R \"" endline "\"" assign


 47. Unexpected Behavior with the /Gt Switch and the PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 15-JAN-1991    ArticleIdent: Q66828

 Adding the /Gt compiler switch with an argument to the Additional
 Options section of the C Compiler Options on the Programmer's
 WorkBench (PWB) Options menu can cause the value of the argument to be
 changed or dropped.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.00. We are researching this problem and will post
 new information here as it becomes available.

 When you add the /Gt switch with an argument (for example, /Gt30) and
 click OK, then immediately go back into the Compiler Options dialog
 box; you will see that the /Gt30 switch you just set is now /Gt3.

 If you set a /Gt switch and specify a value, it will compile with that
 correct value because it was written to the file on disk that is used
 to build the program.

 If you go back in and look at the compiler options and see that the
 value is incorrect and Cancel the options dialog, you will still
 compile with your initial correct /Gt value.

 You will compile with the incorrect /Gt value only if you make another
 change in that dialog and select OK. This is because you changed the
 options, so PWB rewrites the options to the file on disk. In the case
 of /Gt, that option is written incorrectly and from that point on, you
 will compile with the incorrect /Gt value.

 Not all values of /Gt are incorrect. The most common incorrect values
 end in zero. The following are examples where the problem occurs:

    /Gt40 will turn into /Gt4
    /Gt0  will turn into /Gt
    /Gt20 will turn into /Gt

 Some other values that get changed are the following:

    /Gt113 will turn into /Gt3
    /Gt305 will turn into /Gt35
    /Gt14  will turn into /Gt4
    /Gt22  will turn into /Gt

 As a possible work around, do not set /Gt in the PWB, and set the
 environment variable CL to the desired threshold, as in the following
 example:

    set cl=/Gt40

 This value will be read by the compiler when it is called from the
 PWB.

 Also, you can set the /Gt switch on the Additional Options line in
 either Set Debug Options or Set Release Options, rather than the
 global Additional Options.


 48. REsearch() Function Prototype Not Found in EXT.H Header File

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.00 buglist1.10
 Last Modified:  4-DEC-1990    ArticleIdent: Q67274

 The Programmer's WorkBench (PWB) function REsearch(), although
 included in EXTSUP.LIB, is not prototyped in the EXT.H header file. To
 call REsearch(), use the following prototype:

 int REsearch( PFILE pFile, flagType fForward, flagType fAll,
               flagType fCase, flagType fWrap, char _far *pattern,
               fl *pflStart );

 For more information, see online help.

 Microsoft has confirmed this to be a problem in PWB versions 1.00 and
 1.10. We are researching this problem and will post new information
 here as it becomes available.


 49. PWB Help Crashes When Using "Moving Through a File"

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.10
 Last Modified: 14-DEC-1990    ArticleIdent: Q67361

 When using the online help through the Programmer's WorkBench (PWB),
 the help system will crash if you do the following:

 1. After entering help, choose Contents.

 2. Select the Microsoft Advisor from the list of contents.

 3. Select the Programmer's WorkBench button followed by the "Moving
    Through a File" selection.

 At this point a header will appear on the screen and the elevator for
 the window will appear as though it is at the bottom of a page.

 The page can be scrolled up and the contents viewed, especially if
 highlighted, but the menu items at the top will be blacked out
 (although they are present). From this point, no further help can be
 accessed.

 If you exit help and then reenter, nothing will come up.
 Re-initializing does not reinstate the help system. Only shelling out,
 exiting, and reentering will allow you to access the help system.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.10. We are researching this problem and will post
 new information here as it becomes available.


 50. PWB Hangs with Novell NetWare

 Product Version(s): 1.00 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | s_quickc s_codeview s_c
 Last Modified: 14-DEC-1990    ArticleIdent: Q67483

 On certain installations of a Novell network, the network will cause
 the Programmer's WorkBench (PWB) to hang. This problem may also occur
 in CodeView or QuickC. The hang usually occurs when an attempt is made
 to use the mouse.

 If you have a peripheral (such as a mouse) that uses Interrupt Request
 Level (IRQ) 3, and your system is part of a network using Novell
 NetWare version 2.15 or earlier, your system may hang when you load
 QuickC, PWB, or CodeView. As a temporary solution, set your peripheral
 to use another interrupt. For more information, contact your Novell
 NetWare dealer.

 If taking these steps does not solve the problem, please contact
 Microsoft Product Support Services.


 51. PWB Menu Hyperlink in PWB.HLP is Inconsistent in Version 1.10

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 23-JAN-1991    ArticleIdent: Q67614

 When selecting help on the Programmer's WorkBench (PWB) version 1.10
 from the Categories menu in QuickHelp version 1.70, the help screen
 for Microsoft Advisor Help System is presented instead. This behavior
 may be duplicated by following the procedure outlined below:

 1. Start QuickHelp without an argument to get help on any topic. This
    will bring up the main help screen.

 2. Select the Programmer's WorkBench choice under the Categories menu.

 Instead of bringing up the help screen for Programmer's WorkBench, you
 will see the screen for the Microsoft Advisor Help System.

 If the PWB.HLP help file is decoded using helpmake as follows

    helpmake /D /T /Opwb.doc pwb.hlp

 we can see that the reason for this is that the .context directive for
 Programmer's WorkBench appears in the wrong section in the decoded
 help file. The following line

    .context Programmer's Workbench

 appears above the section for "Microsoft Advisor Contents." To correct
 the problem, move the .context directive for Programmer's WorkBench to
 the proper section, which is the "Programmer's WorkBench Contents."

 The helpfile must then be recompressed, as follows:

    helpmake /E7 /T /Opwb.hlp pwb.doc

 The choice of /E7 is shown here for demonstration purposes only, and
 is strictly arbitrary in this case. If maximum compression is desired,
 the numerical argument to the /E switch may be left off, or /E15 may
 be specified. Maximum compression will restore the database as close
 to its original size and state as possible.


 52. "missing ':' in ->" Caused by Control Character

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 14-DEC-1990    ArticleIdent: Q67736

 When invoking the Programmer's WorkBench (PWB), if there is a control
 character at the end of the TOOLS.INI file, [usually a CTRL+Z (ASCII
 26) end-of-file marker] and you only have a [pwb] tagged section, an
 error message will appear stating "missing ':' in ->". Note that the
 "->" is the graphic right-arrow symbol.

 This is not a problem in the PWB. A control character is a legal macro
 name. The message indicates that a macro definition or key assignment
 is expected after the character. To keep this message from appearing,
 place the tag

    [end]

 before the control character at the end of your TOOLS.INI file. With
 this tag at the end of the file, you always suppress the message, even
 if you edit TOOLS.INI with an editor that inserts CTRL+Z's at the end
 of the file. This is because the -> symbol must be within the [pwb]
 tagged section for this error message to be displayed, and the [end]
 tag forces the -> into its own tagged section.

 Simply deleting the control character will work until you edit the
 file with an editor that replaces the CTRL+Z, then this message
 reappears. This may also when using the COPY command to concatenate
 files.


 53. Inconsistent Error Attempting to Load Nonexistent Extension

 Product Version(s): 1.00 1.10
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 28-DEC-1990    ArticleIdent: Q67777

 When attempting to load a Programmer's WorkBench extension through a
 macro definition in the TOOLS.INI file, if the extension file does not
 exist, or is not in the current path, the following error message is
 displayed in a dialog box:

    pwbhelp:  SYS0123:  A file name or volume label contains an
                        incorrect character

 This error message should indicate that the extension file could not
 be found; however, the message is generated by the OS/2 operating
 system's DLL loading code, and therefore, cannot be changed by PWB.

 The following error message is generated in the DOS version of PWB,
 which displays this message in a dialog box:

    No such file or directory

 To correct the problem, make sure that the directory in which the
 extension resides is in the current path.


 54. PWB May Record Incorrect Paths for Dependencies in Makefile

 Product Version(s): 1.00 1.10  | 1.00 1.10
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | buglist1.00 buglist1.10
 Last Modified:  6-FEB-1991    ArticleIdent: Q67780

 Creating a program list with dependencies in directories other than
 the project (makefile) directory may result in the Programmer's
 WorkBench (PWB) recording the wrong paths to these dependencies.

 The following steps illustrate the problem:

 1. Create subdirectories named TEST and TESTA under the same
    directory, with sample files FOO.C in TEST and GOO.C in TESTA.

 2. Invoke PWB from the TESTA directory.

 3. Create a program list.

 4. Add FOO.C and GOO.C with full path.

 5. Save the list.

 The resulting makefile will contain the line:

    OBJS = goo.c foo.c

 The correct line should read:

    OBJS = goo.c ..\TEST\foo.c

 Changing the location of the project makefile or changing the names of
 the subdirectories will generate the correct paths for dependencies in
 the makefile.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench versions 1.00 and 1.10. We are researching this problem and
 will post new information here as it becomes available.


 55. PWB Extensions in DOS Cannot Shell to DOS

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q67792

 Extensions written for the Programmer's WorkBench (PWB) that require a
 call to the operating system do not work correctly under DOS. One
 example of this is the FILTER.C sample extension packaged with
 Microsoft C 6.00.

 When PWB.COM is executed under DOS, it spawns the main editor
 (PWBED.EXE). PWBED.EXE is cleared from memory when a DOS shell is
 executed from within the editor. Once the shell has completed,
 PWBED.EXE is reloaded from disk and initialized. The initialization is
 what causes the problem because it also initializes any extensions to
 the editor at the same time. This means that any information that the
 extension was keeping track of is lost.


 56. Not Enough Core Message Caused by Lack of Memory

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q68070

 When loading the Programmer's WorkBench (PWB), a message box may
 appear on the screen containing the message "Cannot Autoload
 Extension, not enough core." The extension file that could not be
 loaded will be indicated. You need to free more memory so that the
 extensions can be loaded.


 57. Windows DLL Build Options Ignore .RC Files in PWB 1.10

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.10 S_C P_WINSDK
 Last Modified: 11-JAN-1991    ArticleIdent: Q68155

 In the Programmer's WorkBench version 1.10, the default build options
 for creating a Windows DLL will ignore any .RC files included in the
 Program List, and therefore, will not build them into the project.

 Use the following steps to correct this problem:

  1. If there is a Program List currently set, clear it.

  2. Set the Main Language to C.

  3. Set the Initial Build Options to Windows DLL.

  4. Create a new Program List containing all the files you want in your
     project.

  5. Save the Program List. At this point, PWB will tell you that your
     .RC file will be ignored. Choose OK when that dialog box appears.

  6. Choose Editor Settings from the Options menu.

  7. Find the line that starts:

        build: target $(PROJ).dll

  8. Change the word "res_dll" on that line to "rc_dll".

  9. Move the cursor off that line to highlight the change. Press SHIFT+F2
     to save the new settings.

 10. Press F2 to exit the ASSIGN pseudofile.

 11. Choose Edit Program List from the Make menu.

 12. Choose Save List. The .RC file will now be saved in the Program
     List and used as expected.

 After these steps are taken, the settings will be saved in the .STS
 file for that project, and will remain correct as long as Set Initial
 Build Options is never selected when this Program List is set. In
 order to keep from repeating these steps for future projects, the
 build options should be saved under a descriptive name, such as
 "Corrected Windows DLL Settings." They can then be chosen for any
 future Windows DLLs.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.10. We are researching this problem and will post
 new information here as it becomes available.


 58. PWB Build Switch Reference Available as an Application Note

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | appnote softlib SW0330
 Last Modified: 29-JAN-1991    ArticleIdent: Q68367

 The "PWB Build Switch Reference" contains detailed descriptions and
 examples for customizing PWB build switches.

 The Programmer's WorkBench (PWB) can build various types of projects
 based on the information contained in "build switches." These build
 switches are interpreted by PWB in order to create a makefile for a
 project. The switches are normally set for you by PWB for common types
 of projects, but you may define your own build switches to handle an
 advanced project where you require more control over the build
 process. For example, customized build switches will allow you to
 utilize different languages, to incorporate other tools into a
 project, or to build new kinds of targets.

 Although build switch customization is documented in the PWB online
 help, the information is somewhat limited. Therefore, an application
 note was created to cover the customization process in detail. The
 title of this application note is "PWB Build Switch Reference" and it
 can be obtained by calling Microsoft Product Support Services at (206)
 637-7096.

 The "PWB Build Switch Reference" can also be found in the Software/
 Data Library (as file SW0330.ARC) by searching on the keyword SW0330,
 the Q number of this article, or S12875. SW0330 was archived using the
 PKware file-compression utility.

 Note that the application note found in the Software/Data Library is
 an ordinary text file, which lacks the typefaces and formatting of the
 printed version that is available by calling Microsoft Product Support
 Services. Because the printed application note is clearer and easier
 to follow, it is highly recommended that you call for the printed
 version, and that you use the downloaded version only as an interim
 copy.

 Also note that you normally DO NOT need to modify build switches just
 to customize the compile and link operations -- this can generally be
 done by selecting commands from the Options menu. By selecting options
 from the Compile or LINK Options dialog boxes, the correct build
 switches are automatically modified to contain the desired
 information.


 59. Brown Screen Color Changes to Yellow After Running PWB

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | s_c buglist1.00 buglist1.10 remapping
 Last Modified:  6-FEB-1991    ArticleIdent: Q69064

 After running PWB, the brown screen color changes to yellow until the
 system is rebooted or the video mode is reset.

 For example, if you run PWB and then run the Microsoft editor, the
 brown characters will appear yellow.

 To work around this problem, you can create a batch file called
 PWB.BAT. In this file, you can start PWB and then reset the video
 mode. For example:

     pwb.bat
             pwb %1 %2 %3 %4
             mode co80,25

 Microsoft has confirmed this to be a problem in PWB versions 1.00 and
 1.10. We are researching this problem and will post new information
 here as it becomes available.


 60. Reinitializing After Changing Editor Settings Is Very Slow

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-FEB-1991    ArticleIdent: Q69142

 The current editor settings in the Programmer's WorkBench (PWB) may be
 changed by choosing Editor Settings from the Options menu, making a
 change to the <assign> pseudofile, and then saving that file. If
 SHIFT+F8 (initialize) is pressed while the <assign> pseudofile is
 still displayed, PWB may appear as though it is hung; it is actually
 reinitializing each statement of the editor settings (<assign>)
 pseudofile.

 The following steps will reproduce this behavior:

 1. Enter PWB and select the Options menu.

 2. Choose the Editor Settings menu.

 3. Make a change in the <assign> pseudofile and then save it.

 4. Press the "initialize" keystroke combination (SHIFT+F8) and a popup
    box will appear stating "reinitializing...". The reinitialization
    is actually taking place but it is very slow because PWB is
    rebuilding the <assign> pseudofile for each entry in your TOOLS.INI
    file.

 This behavior does not occur in PWB version 1.00. Version 1.10
 includes a change to the earlier version; you can see a new assignment
 (made via "arg textarg <assign>") immediately updated if you are
 viewing the <assign> pseudofile.

 This is expected behavior because the <assign> pseudofile is meant to
 show the settings that were in effect at the time the file was
 displayed. It is not recommended that it be dynamically updated except
 via the mechanism of actually editing the file. If you changed a
 setting via "arg textarg assign" (ALT+A textarg ALT+=), a better way
 to view your new setting(s) is by using "refresh" (SHIFT+F7), or by
 switching away and back again via "setfile" (F2).


 61. PWB Ignores Certain Compiler Switches in Additional Options

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 25-FEB-1991    ArticleIdent: Q69145

 The compiler switches

    /Fo, /Fe, /F hexnum, /Fm, and /link link-info

 are ineffective when entered in the Additional Options field of the C
 Compiler Options dialog box from the Options menu of the Programmer's
 Workbench (PWB). This is the intended behavior. The functionality of
 all of these switches is provided through the Compiler, Link, and
 Build Options dialog boxes from the Options menu.

 The /Fo switch is overridden by PWB as it creates the .MAK file needed
 to build the project. To perform this function correctly:

 1. Set a program list from the Make menu.
 2. Choose Build Options from the Options menu.
 3. Choose the Build Directory button.
 4. Enter the destination path in that field, such as:

       C:\C600\PROJECT\

 5. Rebuild the project, and both the .EXE and .OBJ files will be placed
    in that directory.

 The other switches are used only to pass information to the linker
 when the CL command is used outside PWB without the /c option. Because
 PWB always compiles and links separately, these switches are lost. To
 utilize these switches from within PWB, select the appropriate options
 in the Link Options dialog box from the Options menu.


 62. How to Increase the Size of the PWB Build Status Box Under DOS

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | window dialog
 Last Modified: 22-FEB-1991    ArticleIdent: Q69475

 In the DOS version of the Microsoft Programmer's WorkBench (PWB)
 versions 1.00 and 1.10, the status box displayed in the center of the
 screen during a compile can be made larger by increasing the length of
 the command being executed.

 When Build or Rebuild All is selected from the Make menu in PWB, a
 build status box appears on the screen showing the command currently
 being executed. Unfortunately, this box is often too small and the
 current command being displayed gets truncated. One way to increase
 the size of this box is to increase the length of the NMAKE command
 line.

 To increase the length of the NMAKE command line, add the following
 text (without the quotation marks) to the NMAKE Options dialog box,
 which can be selected from the Options menu:

    "                                                /NOLOGO"

 Be sure to include the spaces when you type this line. Then, when you
 select Build or Rebuild All from the Make menu, the build status box
 will be almost as wide as the screen, allowing most of the subsequent
 commands to fit completely into the box.

 If you use the PWB "compile" command, or choose the Compile File
 option from the Make menu, the build status box behaves similarly --
 the longer the command to be executed command, the larger the box will
 be.






 Microsoft CodeView
 =============================================================================


 1. Sequential Mode Not Available in CodeView Version 3.00

 Product Version(s): 3.00 3.01 3.11  | 3.00 3.01 3.11
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q69065

 The CodeView sequential mode (/T option) is not available in CodeView
 version 3.00.

 In CodeView versions 2.30 and earlier, the /T option caused the
 debugger to operate in "sequential mode," which means that only a
 command-line interface was available. You could then type the command
 "=COM1" to redirect the input and output to the COM port, which
 allowed debugging via a remote terminal.

 The /T option and the "=COM1" command are not available in CodeView
 3.00, 3.10, and 3.11 because of the new windowing environment used in
 these versions.

 However, you can still redirect CodeView output to COM1 using the
 Redirected Output command.

 The Redirected Output command causes the CodeView debugger to write
 all subsequent command output to a device, such as another terminal, a
 printer, or a file. The term "output" includes not only the output
 from commands but also the command characters that are echoed as you
 type them.

 The second greater-than symbol (optional) appends the output to an
 existing file. If you redirect output to an existing file without this
 symbol, the existing file will be replaced. For example:

    >>COM1

 In the example above, output is redirected to the device designated as
 COM1 (probably a remote terminal). You might want to enter this
 command, for example, when you are debugging a graphics program and
 want CodeView commands to be displayed on a remote terminal while the
 program display appears on the originating terminal.

    >>OUTFILE.TXT

 In the example above, output is redirected to the file OUTFILE.TXT.
 This command is helpful in keeping a permanent record of a CodeView
 session.


 2. How Interrupts Are Handled in CodeView

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR55548
 Last Modified:  9-AUG-1989    ArticleIdent: Q11817

 Question:

 How does CodeView handle interrupt vectors? Does it mask any
 interrupts when it runs?

 Response:

 CodeView saves and restores about 60 interrupt vectors as a safety
 feature. However, it only redirects the following nine vectors for its
 own use:

    0       Divide By 0
    1       Single Step
    2       NMI
    3       Breakpoint
    9       Keyboard
    21H     DOS functions
    22H     DOS terminate
    23H     ^C
    24H     Critical Error

 The remaining estimated 51 vectors are never altered by CodeView
 unless something else (e.g. the program being debugged) alters them
 after CodeView has started up. In this case, CodeView restores them to
 their original value as it exits.

 When you enter G(o) and let your program run, CodeView relinquishes
 control and lets all interrupts (except the nine listed above) flow
 into your application for processing. However, when you hit a
 breakpoint, the 8259 Programmable Interrupt Controller is masked. This
 prevents interrupts from coming into your application while your
 program is suspended. If you enter G(o) again, CodeView reenables
 interrupts to your application.

 To avoid a bug in the 8086 family, CodeView masks the interrupt
 controller during T(race) commands and some P(rogram step) commands.
 CodeView Versions 2.00 and above solve this restriction by emulating
 the interrupts for your application.

 You normally do not single-step or trace real-time code, so this
 should not be a problem for developers writing interrupt-driven code.
 However, it is something you should be aware of if you are depending
 on interrupts to get to your application. For example, it will not
 work if you enter "T 1000" and expect your program to catch and
 process interrupts during the trace. You will need to set a breakpoint
 at the instruction with which you are concerned, then enter G(o).


 3. Debugging Routines That Are in Libraries

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | TAR55321
 Last Modified: 21-AUG-1989    ArticleIdent: Q11877

 Question:

 When CodeView attempts to debug a function from a library module, it
 is unable to find the source even when that module was compiled with
 -Zi. It prompts me to "Enter Directory for Program (CR for None)?". I
 enter the directory in which PROGRAM.C resides, but CodeView cannot
 find it. Is there any solution other than not placing modules I wish
 to debug in libraries?

 Response:

 This is a consequence of the way the LIB utility works. When adding an
 object module to a library, LIB records only the source file's base
 name, not its extension. Therefore, "c:\c\source\module1.c" becomes
 "c:\c\source\module1" (no extension). When you are debugging an
 application that calls "module1", CodeView attempts to find
 "c:\c\source\module1". However, it does not accept the filename you
 give because the file is really named "module1.c".

 One way to work around this restriction is to rename your source file
 from "c:\c\source\module1.c" to "c:\c\source\module1" (no extension)
 after you have compiled it and put it into a library. This way, the
 actual name will match the name CodeView is searching for.

 Another solution is to use Library Manager Version 3.07 (which came
 with MASM 5.00) or later; this solves the problem by not stripping the
 file's extension as it is put into a library.


 4. CVP May Generate a Trap B with Large Programs Under OS/2 1.30

 Product Version(s): 2.20 2.30 3.00 3.10 3.11
 Operating System:   OS/2
 Flags: ENDUSER | gp fault protection violation
 Last Modified: 25-FEB-1991    ArticleIdent: Q69348

 Debugging a large application with CodeView under OS/2 version 1.30
 may result in a Trap B system error. Trap B is a "segment not present"
 exception, which results from changes that were made to this version
 of the operating system.

 In version 1.30 of OS/2, the code for DosPTrace() was made swappable,
 while in previous versions it was not. DosPTrace() is part of the OS/2
 API that allows a parent process to control the execution of a child
 process, and to access the child process's memory directly to insert
 breakpoints or change data.

 Because CodeView relies heavily on DosPTrace(), problems arise if this
 code is swapped from memory. The majority of problems occur when
 execution reaches a breakpoint while the DosPTrace() code is not
 present; control should then jump to code that is not currently in
 RAM.

 Because large programs (or heavily loaded systems) tend to result in
 more swapping, this problem appears much more readily when debugging
 large applications.

 The only sure workaround for this problem is to turn off swapping
 while debugging, but it also may help to increase or free up available
 memory. To disable swapping, modify the MEMMAN switch in CONFIG.SYS as
 follows:

    MEMMAN=NOSWAP

 To increase available memory, either install more memory in the
 computer itself or terminate all other unnecessary processes before
 debugging (to remove them from memory).

 This problem is the result of a design change with OS/2 1.30 and is
 not a problem with CodeView. This change is being reconsidered for
 future versions of OS/2. New information will be posted here as it
 becomes available.


 5. Using Two Monitors with CodeView

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | TAR56465
 Last Modified: 11-SEP-1989    ArticleIdent: Q11966

 Question:

 How do I use CodeView with two monitors? Where is this option
 documented?

 Response:

 Invoke CodeView with the following command:

    CV /2 PROGRAM

 This command tells CodeView to put its display on your secondary
 monitor and lets your program's output go to the default display. This
 option is documented in the "CodeView Options" section of the
 "Microsoft CodeView and Utilities Software Development Tools for the
 MS-DOS Operating System" manual in all products except Microsoft C
 Version 4.00, where it is documented in the README file.

 You must have two monitors and two display adapters to use this
 feature. You must have a monochrome and a non-monochrome monitor;
 because a monochrome monitor's video memory is in a different
 location than a CGA, EGA, or VGA's. This is how CodeView implements
 the /2 option, by writing to both sets of video memory.

 When you use the /2 option, your program's display appears on the
 current default adapter and monitor, while the debugging display
 appears on the secondary adapter and monitor. You can switch which
 monitor is the current default adapter with the MS-DOS MODE command.
 "MODE MONO" causes standard output to go to the MDA, while "MODE CO80"
 causes standard output to go to your CGA, EGA, or VGA.

 For example, if you have both a CGA and an MDA, you might want to set
 the CGA up as the default adapter. You could then debug a graphics
 program with the graphics display appearing on the graphics monitor
 and the debugging display appearing on the monochrome adapter.


 6. /L Must Give Full Pathname to .DLL Unless in Current Directory

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 16-AUG-1989    ArticleIdent: Q47937

 When debugging dynamic link modules with CodeView Protect (CVP), you
 must use the /L switch. Before invoking CVP, make certain that the
 .DLL is in the LIBPATH specified in the CONFIG.SYS file. When invoking
 CVP with the /L switch, if the .DLL is not located in the current
 directory, you must specify the full drive and pathname to the DLL. An
 example is the following:

    CVP /L d:\os2\dll\stdll.dll stmain.exe

 In this example, the full drive and pathname are given for the DLL to
 be debugged. If the full pathname is not given, CodeView will come up.
 However, you will be unable to step into the DLL. CodeView will simply
 step over that call.


 7. CodeView Cannot Trace into Single-Line Functions

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 15-SEP-1989    ArticleIdent: Q47624

 CodeView Versions 2.20 and 2.30 do not trace into a function that is
 contained in a single line of code. For example, if the following
 program is compiled and loaded into CodeView, an attempt to trace into
 the function funct() results in the trace stepping over the function,
 rather than tracing into it.

 Sample Program
 --------------

 /* SIMPLE.C ... a very simplistic sample program                    */

 int funct(void);
 int x;

 void main(void)
 {
   x = funct()
  }

 /* single-line function. It does nothing more than return a value.  */

 int funct(void){return 1;}

 If the above function is modified so that it performs exactly the same
 task but is located on multiple lines, as follows, then CodeView
 handles it correctly:

 int funct(void)
  {
    return 1;
   }



 8. Trace Stops on Line Following a Loop Before Loop Is Done

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 15-SEP-1989    ArticleIdent: Q47625

 In trace mode, CodeView stops on the line following a loop that does
 not have open and close braces ({}), before the loop is done.

 When tracing through a loop without the braces ({}), the trace stops
 on the statement immediately following the loop each time through the
 loop, giving the impression that the statement is being executed
 inside the loop. Actual program execution is correct.

 The following program was compiled with C Version 5.10 with the
 command line

    cl /Zi /Od program.c

 and run using CodeView 2.20, as follows:

     cv program.exe

 The trace stops at the printf each time through the loop even though
 printf is not part of the loop, but does not print anything until the
 end of the program.

 Sample Program
 --------------

 #include <stdio.h>

 void main(void)
 {
     int i;
     int count;

     count = 0;

     for(i=0;i<3;i++)
         if(i)
             count++;

     printf("Count is %d\n",count);
 }


 9. The 37th Call Added to the Calls Menu Corrupts CodeView Screen

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist2.20 fixlist2.30
 Last Modified: 10-NOV-1989    ArticleIdent: Q50496

 The CodeView Calls menu shows the current depth of function calls as
 well as the line number the routine was called from and the parameters
 passed. The current routine is always at the top and the routine from
 which the current routine was called is directly below.

 The routines in the Calls menu are first labeled 0-9, and if you are
 nested more than ten levels deep, CodeView labels the next 26 calls
 A-Z, for a display that can accept 36 levels of subroutine calls. If
 you exceed this limit and then select the Calls menu, the CodeView
 display becomes corrupted.

 If the display is corrupted in this manner, the Redraw ("@") dialog
 command can be used to restore the display to it's original state.

 The Stack Trace dialog command (K) has the same function as the Calls
 menu and correctly handles nesting of more than 36 levels deep.

 Microsoft has confirmed this to be a problem with CodeView Version
 2.20. This problem was corrected in Version 2.30.


 10. Quickwatch Seems to Hang When Expanding Very Large Arrays

 Product Version(s): 3.00 3.10 3.11 | 3.00 3.10 3.11
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | s_quickc
 Last Modified:  6-FEB-1991    ArticleIdent: Q68010

 When expanding an element in a large array (usually greater than 1000
 elements, but system dependent), the quickwatch function appears to
 hang. This apparent problem is caused by the time it takes to re-align
 the data in the window, and is actually normal operation. If you place
 the same array element in the Watch Window, it will expand instantly.


 11. Structures Declared with Near, Far, Pascal, and Fortran

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_C S_QuickC buglist2.20 buglist2.30
 Last Modified: 16-AUG-1989    ArticleIdent: Q47694

 CodeView is unable to display elements of structures declared with the
 following keywords:

    near
    far
    pascal
    fortran

 Using ?? to display a structure yields the structure table with only
 one value inside. This value is the first element in the structure.
 Using w? or ? yields the following error message:

    Operand types incorrect for this operation

 Microsoft has confirmed this to be a problem with CodeView Versions
 2.20 and 2.30. We are researching this problem and will post new
 information as it becomes available.

 To work around this problem, recompile without these keywords, or
 obtain the address of the structure element and put a watch on the
 memory location.

 Consider the following large model program:

 struct { int x;
          int y;
          int z;} near a;    /* or far, pascal, fortran */

 void main(void)
 {
   a.x = 1;
 }

 To put a watch on a.x, you could issue the following commands:

 ? &a
 0x0345:0000       <- result is the address of the structure
 ww 0x0345:0x0     <- address of x
 ww 0x0345:0x2     <- address of y (two byte int from x)

 This puts a watch on the first and second elements (x and y) in the
 structure.


 12. Older Vega VGAs Hang CodeView When in VGA Mode

 Product Version(s): 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 14-AUG-1989    ArticleIdent: Q27212

 Question:

 Why does my old Vega VGA card cause CodeView to hang when I start it
 in VGA mode? It works properly when I start CodeView when the card is
 in CGA mode.

 Response:

 Some of the older Vega VGAs do not work correctly with CodeView. The
 Vega VGA card uses the same maskable interrupt for detecting graphics
 mode as CodeView.

 We recommend that you contact Vega by calling 1 [phone] for
 advice if you experience this problem.


 13. Ambiguous Documentation of Enter ASCII (EA) Command

 Product Version(s): 2.10 2.20 | 2.10 2.20
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 16-AUG-1989    ArticleIdent: Q47764

 In the "Microsoft C 5.1 Optimizing Compiler" manual, the "CodeView and
 Utilities" section does not thoroughly document the EA command for
 CodeView. The following is a more complete explanation:

    EA address [list]

    The Enter ASCII (EA) command modifies array to the value of [list].
    Address refers to what you want to modify. [list] refers to a
    string literal such as "hello". EA wil