IWhen I signed on a few minutes ago I received the message that my password is going to expire soon. When I tried to enter a new password the message popped up that my new password is not compatible with the password rules.I was not able to find any information about valid characters in passwords on this website. What are valid passwords?

When I use the visual studio 2017 with Intel parallel studio 2018 to debug a Fortran program , the vs stuck and then crash.And if I ban the "intel fortran expression evaluator" plug-in, the vs can debug the program ,bug it can't show the value of the variable correctly.I have repaired the Intel parallel studio,but the problem is still unsolved.

Hi there,

Im trying to compile a programm .exe as a .dll to use it in a python script using ctypes. After making the adjustments to the program (variables structs for phyton, bind ctype functions), I complied the programm as a .dll. Unfortunately, ctypes was unable to detect the "binded" functions. After some research, I assumed, this must be related to the External Procedures of the project. I changed the External Procedures to STDCALL for this instance.

About the structure of the program. It includes XML Parser written in c++. The main program depens on the XML parser project. Before changing the External Procedures I was able to compile the .dll or .exe.

I use VS 2015 with the Intel XE Fortran Compiler 2017.

So now I get the following errors:

Severity	Code	Description	Project	File	Line	Suppression State
Error		error LNK2001: unresolved external symbol _GETCWD@4		Ausgabe_Mnkenn.obj		
Error		error LNK2019: unresolved external symbol _SYSTEM@8 referenced in function _DATEILOESCHEN_MOD_mp_DATEILOESCHEN		DateiLoeschen.obj		
Error		error LNK2019: unresolved external symbol _GETCWD@4 referenced in function _DATEILOESCHEN_MOD_mp_DATEILOESCHEN		DateiLoeschen.obj		
Error		error LNK2001: unresolved external symbol _SYSTEM@8		DateiSchliessen.obj		
Error		error LNK2001: unresolved external symbol _GETCWD@4		DateiSchliessen.obj		

These are mostly linked to some system functions. Does anybody have a possible solution to this issue? Thanks for your help in advance.

Here is the front end of a legacy package I am trying to port from Compaq/6 to Intel/18.  This program is a GUI to enter beam-line elements for
Monte Carlo simulation of neutron scattering instruments. As each element is "Built" into a file which will be used in the simulation, it
may also be rendered as a VRML <shape> block, allowing the user to see the complete instrument from any angle.

My current level of (lack of) understanding is how to include the INCLUDE files, such that they can be seen Globally.  I have found

     NISP_Win Property Pages
and under Resources > General, I specified
      Additional Include Directories C:\NISP\INCLUDES
but the result was not good - the include files were not found:
1>C:\NISP\NISP_Win\NISP_Win.f(67): error #5102: Cannot open include file 'mc_geom.inc'
etc. for the other files.

Command-line mode with "/Ic:\nisp\includes" did much better -- up to finding variables defined in module MouseFlags. What do I need to know
about using Modules with TYPEs and labeled COMMON blocks?

      PROGRAM NISP_WIN
!
!  Create or edit an instrument and write a geometry file for MC_Run,
!    using the Windows environment.  Adding or changing element types is
!    done in module ElementTypes.  All element definitions and geometry
!    file information are in a static library, ElmntDef.lib.  Layouts of
!    dialog boxes for each type are found in resource file Script1.rc.
!
      USE       IFQWIN
      USE       IFLOGM
      USE       IFPORT
      USE       ElmentTypes
      USE       MouseFlags
!
      IMPLICIT  NONE
      CHARACTER VERSION*(*)
      PARAMETER (VERSION='Version 3.1, 08 Sep 2018')
      INCLUDE   'RESOURCE.FD'
      INCLUDE   'mc_geom.inc'    !TYPE SURFACE, REGION, MC_GEOM, PARTICLE
      INCLUDE   'mc_elmnt.inc'   !TYPE MC_ELEMENT
      INCLUDE   'constant.inc'   !physical constants
      INCLUDE   'BuildData.inc'  !COMMON /Build_Data/, /VRML_Data/
!
      INTERFACE
         LOGICAL(4) FUNCTION INITIALSETTINGS
         END FUNCTION
      END INTERFACE
!

Dear all,

I am new to programming with Fortran's openMP application (using Intel Compiler version 18). I recently have run into a problem to which I could not find an answer (after 1 month of digging around). The issue is (see below for the code) that I would like to solve a function where I assign some limiting conditions in the main body of the code, which also should be used in the function. For example, I specify that my function should allow for a current value A_cur=a0(i,j) where i and j are my do-loop running variables. 

The issue is that in my main body of code, this assignment works fine. But as soon as I "call" my function f(x) where x not equal A_cur (but A_cur is a constant used in the function), my code reads A_cur=0 instead of A_cur=a0(i,j).

Hence, my question is how to solve this issue without defining the function f(x,a_in) where I set, a_in=A_cur? I would be really grateful for some insights on this issue as well as some recommendations. 

This code is supposed to illustrate my issue with a very simple assignment (which however captures the issue). In this code, I specify that a_com=i, whereby i is the running variable in my OMP loop. In the main code it correctly takes the assigned value but it does not do so in the function utility. (Note that this is a simplified version of the assignment problem I mention above where the assignment issue between main body of the code and the function does not affect the outcome, while in my example above it would).

---------------------------------------------------------------------------------------------------------------------------------

module constants

integer, parameter:: i4b=selected_int_kind(15)
integer, parameter:: ndp=selected_real_kind(15)

real(ndp), parameter:: zero=0.0d0
real(ndp), parameter:: one=1.0d0
real(ndp), parameter:: two=2.0d0

integer(i4b):: t_in, a_com
real(ndp):: y_cur,a_cur

    contains
    
    double precision function utility(in)
        real(ndp),intent(in):: in
        real(ndp):: v1, cons
        
        
        if((t_in)<two)then
            cons=1+in
            write(*,*) 't_in<2'
        else
            cons=2+in
            write(*,*) 't_in>2'
        endif
        
        write(*,*) 'a_com', a_com
        
        v1=sqrt(cons)
        utility=v1
        
    end function utility

end module constants

program test_openMP

    use constants
    
    !# Define some variables
    integer(i4b):: i,t,j
    integer(i4b), parameter:: i_max=10, t_max=3, j_max=3
    real(ndp):: result(0:i_max,0:t_max,0:j_max), a_pr(0:i_max,0:t_max), &
                income(0:j_max)
    real(ndp):: a_in,a_max
    
    
    
    a_max=100
    
    do i=0,i_max
        do t=0,t_max
            a_pr(i,t)=(a_max)/((1+0.05*t)**i)
        enddo 
    enddo
    
    do j=0,j_max
        income(j)=(1.07)**(1+j)
    enddo
    
    
    do t=0,t_max
        t_in=t
        write(*,*)'Run for t', t, 'of', t_max
    !$OMP PARALLEL DO PRIVATE (a_in,y_cur,a_cur,a_com)
    do i=0,i_max
    write(*,*)'Run for i', i, 'of', i_max
        a_in=a_pr(i,t)
        a_com=i
            do j=0,j_max
                y_cur=income(j)
                a_cur=a_in+y_cur
                result(i,t,j)=utility(a_cur)
            enddo
        enddo
    !$OMP END PARALLEL DO
    !a_com=o
    enddo
    
    
    do i=0,i_max
        t=2
        j=1
            write(*,*) 'i', '|', 'a_pr','|', 'Result','|', 'Utility'
            write(*,*)'###############################################'
            write(*,*)  i,'|', a_pr(i,t),'|', result(i,t,j),'|', utility(a_pr(i,t)+income(j))
    enddo

end program test_openMP

--------------------------------------------------------------------------------------------------------------------

Best,

Sebastian

I have a DLL which has been generated by Intel Fortran 2008 and an Excel file that calls\runs that DLL. Now, I'm trying to call that DLL in Visual Basic 2015 but I have a problem with the memory mismatch. The function within that DLL is "solutionize" that I am trying to call.

The source code for "solutionize" subroutine\DLL is attached. The command "MS$ ATTRIBUTES STDCALL" has been used.

You can find "solutionize" in the DLL file using the DumpBin command, please see the attached file. The name is: _solutionize@116

There is an Excel file calls the DLL and run the subroutine I'm interested in successfully. You can find the Excel file commands in attached files.

Now, I'm trying to call the subroutine\DLL in Visual Basic using Visual Studio 2015. I have tried many combinations and none worked. I have attached one example. Does anyone have any revision to the attached file for the loading and calling the subroutine\DLL in VB?

Looking forward to hear your suggestions.

PS1: I do have all the source codes, but I cannot compile them. The team who wrote them cannot compile them either. I tried Intel Fortran 2015, Absoft and the GFortran and I ran into different issues with each of them. This was compiled last with Intel 2008.

Best,

Does anyone have a phone number for the customer service? Is there any customer service for Intel Fortran, I should have asked first?!

Mehdi

See verbose build text I extracted:

Suppose I don't want to use that particular set of libraries - trying to find one that does not have that BUG that no one seems to know how to fix.

Now, if I want to try another library set (not 2016.4.246) how can I do that ?

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Searching libraries
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifcoremt.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifport.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqw_mdi.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqwin.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\user32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comctl32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\gdi32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comdlg32.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libmmt.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\lib\LIBCMTD.lib:
1>      Found __load_config_used
1>        Loaded LIBCMTD.lib(loadcfg.obj)
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libirc.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\svml_dispmt.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\lib\OLDNAMES.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\mkl\lib\ia32\mkl_intel_c.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\mkl\lib\ia32\mkl_sequential.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\mkl\lib\ia32\mkl_core.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\lib\libcpmt.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\kernel32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\ImageHlp.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\uuid.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifcoremt.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libifport.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqw_mdi.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\ifqwin.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\user32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comctl32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\gdi32.lib:
1>    Searching c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\PlatformSDK\lib\comdlg32.lib:
1>    Searching C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.4.246\windows\compiler\lib\ia32\libmmt.lib:
1>Finished searching libraries

Hi.

In my program I have several procedure pointers in a large derived type (with sub derived types). However, the pointers seem to become unassociated for some specific cases and I don't understand why. I would be very grateful if someone can give me hints on what I'm doing wrong and how a more stable behavior can be achieved!

Below is an as small example as I was able to create to show the behavior.

I get the following output depending on my settings (A,B,C):

A: As below
B: Comment out line 28
C: Comment out line 90 and 92, remove comment on line 89

Earlier in the digging down I also experienced a case D, but I haven't been able to reproduce this in a smaller example...

 Setting                              =  A | B | C | D
 get_lev2_2, lev2_2%addr              :  T   T   T   T
 get_lev1_2, lev1_2_tmp(1)%lev2_2%addr:  F   T   T   T
 get_lev1_2, lev1_2(1)%lev2_2%addr    :  F   T   F   T
 get_main, main%lev1_2(1)%lev2_2%addr :  F   T   F   T
 get_main, main%lev1_1%addr           :  T   T   T   T
 top_level, main%lev1_1%addr          :  T   T   T   T
 top_level, main%lev1_2(1)%lev2_2%addr:  F   T   F   F

This is running with Visual Studio 2012 and ifort 14.0.1.139

Running the same example on linux with ifort 18.0.1 and  gfortran 7.3.0 all tests are true.

module tmpl_mod
    implicit none
    abstract interface       
        subroutine sub_template(x,f)
            double precision, intent(in) :: x(:)
            double precision :: f(size(x))
        end subroutine
    end interface
    
    contains 
        
end module tmpl_mod
    
module types_mod
use tmpl_mod
    implicit none

    type lev1_1_typ
        integer                                :: k1
        procedure(sub_template),pointer,nopass :: addr
    end type
    
    type lev2_2_typ
        procedure(sub_template),pointer,nopass:: addr
    end type
    
    type lev1_2_typ 
        integer                        :: k1
        type(lev2_2_typ)               :: lev2_2
    end type
    
    type main_typ
        type(lev1_1_typ)                  :: lev1_1
        type(lev1_2_typ), allocatable     :: lev1_2(:)
    end type main_typ
    
end module types_mod
    
module ass_mod
    use tmpl_mod
    implicit none   
                
    character(len=4), parameter     :: lib_ext = '.dll'
    
    contains
    
    subroutine sub(x,f)
        double precision, intent(in) :: x(:)
        double precision :: f(size(x))
        f = 2.d0*x
    end subroutine
    
    subroutine ass_sub(proc_ptr)
    implicit none
        procedure (sub_template), pointer   :: proc_ptr
        proc_ptr => sub
    end subroutine
    
end module ass_mod
    
    
module get_mod
    use types_mod
    use ass_mod
    implicit none
    
    contains

subroutine get_main(main)
    implicit none
    type(main_typ) :: main
    
    call get_lev1_1(main%lev1_1)
    call get_lev1_2(main%lev1_2)
    write(*,*) 'get_main, main%lev1_2(1)%lev2_2%addr: ', associated(main%lev1_2(1)%lev2_2%addr)
    write(*,*) 'get_main, main%lev1_1%addr          : ', associated(main%lev1_1%addr)
    
end subroutine

subroutine get_lev1_1(lev1_1)
    implicit none
    type(lev1_1_typ)                  :: lev1_1
    call ass_sub(lev1_1%addr)
end subroutine

subroutine get_lev1_2(lev1_2)
    implicit none
    type(lev1_2_typ), allocatable       :: lev1_2(:)
   !type(lev1_2_typ)                    :: lev1_2_tmp(3)
    type(lev1_2_typ), allocatable       :: lev1_2_tmp(:)
    integer                             :: stype, k1
    allocate(lev1_2_tmp(3))
    k1 = 1
    call get_lev2_2(lev1_2_tmp(k1)%lev2_2)
    allocate(lev1_2(k1))
    lev1_2 = lev1_2_tmp(1:k1)
    write(*,*) 'get_lev1_2, lev1_2_tmp(1)%lev2_2%addr:', associated(lev1_2_tmp(1)%lev2_2%addr)
    write(*,*) 'get_lev1_2, lev1_2(1)%lev2_2%addr    : ', associated(lev1_2(1)%lev2_2%addr)
    
end subroutine

subroutine get_lev2_2(lev2_2)
    implicit none
    type(lev2_2_typ), intent(inout)        :: lev2_2
    
    call ass_sub(lev2_2%addr)
    write(*,*) 'get_lev2_2, lev2_2%addr: ', associated(lev2_2%addr)
    
end subroutine

end module get_mod
    
program top_level 
    use types_mod
    use get_mod
    implicit none
    type(main_typ)                 :: main
    
    call get_main(main)
    write(*,*) 'top_level, main%lev1_1%addr          : ', associated(main%lev1_1%addr)
    write(*,*) 'top_level, main%lev1_2(1)%lev2_2%addr: ', associated(main%lev1_2(1)%lev2_2%addr)
    
end program

At last I have decided to install IVF 2017 last update. 
My application development environment was IVF2016 integrated with VS2015.
Before this last step I have installed about 2 months ago MS VS2017.
My hope was to keep the IVF2016/VS2015 unchanged and integrate IVF2017 with VS2017 only. 
The installation of IVF2017 has provided NO WARNINGS and NO OPTION SELECTION and at the end IVF2017 has replaced IVF2016  in the VS2015 installation. 
How is it possible to destroy a professional development environment ??
Both Intel and MS products are professional version.
So a basic question to Intel engineers: how can I get the described limited integration ? 
Congratulations to Intel engineers !  

It takes me to a page that has the original one, and the three updates.

(this is after the down arrow that says Download VS 2015)

But when I click on one of these update, it only gives me information.

There is no link that I can see that actually does the download, just information.

Is there a special trick? I thought it was free.

I cant use a later version, since the source code (Fortran) interface is broken.

Otherwise I would buy the most recent one.

Hi,
I've compiled a fortran code as a DLL using the auto-parallization and auto-vectorization features in fortran compiler.
When I call the dll using a fortran compiled exe program, the dll runs faster on all the available cores on my PC.
However, when I call the DLL using a .net compiled exe, the dll runs slower and only on just one core.

Can I get help on this topic?

Thanks,

As I browse the LINK errors, most posters with LNK errors have the problem:

LINK: fatal error LNK1104: cannot open "xxx.lib". So the file can be addressed.

In my case, the error message is always:

LINK: fatal error LNK1104:                         so I have no idea which file is missing.

Any setting I need to change to fix this difference?

Many thanks!

Intel® Parallel Studio XE 2019, including Intel® Visual Fortran Compiler 19.0, is now available from the Intel Registration Center. Release notes can be found here.

The Intel® Fortran Compiler supports all features from the Fortran 2008 standard. Additional features from the proposed draft Fortran 2018 standard added in the Intel® Fortran 19.0 release are noted below:
 

• Coarray events
• Intrinsic function coshape
• Default accessibility for entities accessed from a module
• Import Enhancements
• All standard procedures in ISO_C_BINDING other than C_F_POINTER are now PURE 

Features from OpenMP*:

• User-Defined Reductions from the OpenMP* 4.5 specifications are now supported:
  !$omp declare reduction(reduction-identifier: type-list : combiner) [initializer-clause]
• The F2008 standard added the BLOCK/ENDBLOCK construct. It is now allowed to use this construct inside an OMP region.
• ASSERT clause for !$OMP SIMD directive
  Directs the compiler to assert when the vectorization fails. Similar to deprecated !DIR$ SIMD ASSERT.

Visual Studio 2013, 2015 and 2017 are supported. Visual Studio 2015 Shell is included for Commercial and Academic license types if you don't have a supported Visual Studio installed.

Please see the release notes for more details.

Hello,

the following program crashes with an access violation when compiled with "ifort /debug /recursive bug.f":

      program bug
        implicit none
        integer get_value
        external get_value
        print *, get_value()
      end program


      integer function get_value()
        implicit none
        get_value = 0
        call get_value_sub(get_value)
      end function get_value


      subroutine get_value_sub (outval)
        implicit none
        integer, intent(out) :: outval
        outval = 1
      end

Cause is the "call get_value_sub" with the argument "get_value". The compiler pushes a wrong address to the stack.

The bug doesn't appear when compiled with 18.0.3.210 or with 19.0.0.117 without the /resursive flag.

In the moment this prevents us from upgrading the compiler.

Best regards,

Christian

With 19.0 official release of Intel Parallel Studio and the integration of this product with Visual Studio, I am noticing an "Advisor Results" section getting introduced automatically in all my solutions regardless of whether an Intel Advisor analysis was requested explicitly.  Are other readers noticing this?  Does anyone know how to avoid this?

Last week I created a post on this forum describing a "floating invalid" error message I am getting.
Through some trial and error, I believe I have found the "smoking gun", or at least something that is contributing to the "(65) floating invalid" error.
I have recreated my code with a very simple example (see below).  I first initialize a large table array at zero.  Then I fill rows 1 and 2 of the table with some numbers.  I then simply divide the value in column 1 with the value in column 2, but only if the value in column 2 is positive.  I put the result in column 3.

I get the error if I compile using the compiler option "/Qinit:snan", as in:
    ifort /libs:dll /traceback /Qinit:snan /c test2.f90
 
The program runs fine if I remove the compiler option, as in:
    ifort /libs:dll /traceback /c test2.f90

Also, what is strange is that if I write out the values of column 1 and 2 before doing the divide, the program runs fine, even with the /Qinit:snan option.
In my example below, I have commented out this write statement.

-------------------------------------------------------------------------------------------------------------------------
      program test2

      double precision xa(3,3,100000)
      data xa /900000*0./

      xa(1,01,1) = 0.
      xa(1,02,1) = 0.
      xa(2,01,1) = 40000000.
      xa(2,02,1) = 100.
      xa(3,01,1) = 10000000.
      xa(3,02,1) = 5.

      do 800 i=1,3
!      write(6,50) i, xa(i,01,1), xa(i,02,1)
! 50   format(1x,'check here',i4,2f10.0)
        if (xa(i,02,1) > .01) xa(i,03,1) = xa(i,01,1) / xa(i,02,1)
 800  continue
       
      do 810 i=1,3
        write(6,100) i, xa(i,01,1), xa(i,02,1), xa(i,03,1)
 100    format(1x,'results',i4,3f10.0)
 810  continue
      end
-------------------------------------------------------------------------------------------------------------------------

I am running Visual Fortran Intel(R) 64 Compiler XE .... Version 15.0.7.287

So, thoughts experts?  Why is this compiler option causing problems?  Is removing this compiler option something I should be worried about?

Thanks in advance.

Jim

GETFILEINFOQQ

This code worked in the olden days, but since I am now compiling in x64 I have to use FILE$INFOI8 in place of FILE$INFO. (See p. 1511 of the Fortran 18 Guide and Reference document.) But I now get this message:

Compiler error #6284: There is no matching specific function for this generic function reference.   [GETFILEINFOQQ]

What have I done wrong? There is a little confusion in the document, which defined the derived type FILE$INFOI8 as if the name was still FILE$INFO, but I assume that is just a typo. Has that been fixed or changed in the new documentation?

Here is a truncated copy of the relevant portion of the code. I marked the line where the error occurs with -->.  I also uploaded the complete subroutine that fails, but I don't expect anyone to read it!

Thanks - Phil Seeger 

      INCLUDE  'BuildData.inc'

     COMMON /Build_Data/ NSURF, NREG, NPARAM, idum, NAME, SURF,

     &                    ICONNCT, REG, INDX, PARAM, DataPath
C  'DataPath' determined at Initialization, and saved in common
    ...
      TYPE(FILE$INFOI8) DIR_INFO
      INTEGER*8 hndl8
      INTEGER*4 NN
      DATA SourcePath, LenPath/'', 0/
      SAVE SourcePath, LenPath
    ...
         CASE ('S')
            SourcePath = DataPath(1:LEN_TRIM(DataPath))//'Tables\'
            LenPath = LEN_TRIM(SourcePath)
            FLAG = DLGSET(DBOX, 1000+I, 100, DLG_NUMITEMS)
            N = 0
!           Loop to find all possible Source Table (*.tbl) files
            hndl8 = FILE$FIRST
            DO WHILE (hndl8.NE.FILE$LAST .AND. hndl8.NE.FILE$ERROR)
  -->        NN = GETFILEINFOQQ(SourcePath(1:LenPath)//'*.tbl',
     &                            DIR_INFO, hndl8)
               IF (NN .GT. 0) THEN
C                 Add file name to a COMBOBOX for possible selection
                  N = N + 1
                  FLAG = DLGSET(DBOX, 1000+I, DIR_INFO%NAME(1:NN), N)
               END IF
            END DO
            FLAG = DLGSET(DBOX, 1000+I, N, DLG_NUMITEMS)
            FLAG = DLGSET(DBOX, 1000+I, STR(I), DLG_STATE)
         END SELECT

I use Quickwin to create a graphics window which is then sent to a 3rd-party routine to draw in. I find, by trial and error, that the routine is unable to use more than the top 1000 pixel rows or so; it rescales the vertical coordinate and apparently sets a clipping region (SETCLIPRGN). For example, if I create the window 800 wide by 1200 high, it creates its picture in the top of my window and leaves an empty strip about 400 pixels high across the bottom. If I want to access this strip, say to add some text below the picture, I have to call SETCLIPRGN to set a new clipping region to the full size of the window. Iow, I want to remove the 3rd party's clip region. Is there a way?

Also, I need to know exactly how high the clip region is. If I draw a line from the upper left to the lower right corner of the window, it will be clipped APPROXIMATELY 400 pixel rows from the bottom, but I only know this by measuring the height of the visible line on the screen. How can I determine programmatically the exact boundary of the clip region? Ideally there would be a routine such as GETCLIPRGN but there is not.

I recently installed PS 2019 XE Cluster edition with VS2017 community.  Everything (that I've check) works great, but I did notice that the environment setup for VS2017 does not properly set the path to the mpi dynamic library (impi.dll).  That is, when I run a program from VS2017 that uses MPI, it generates the error that it can't find impi.dll.   There is no problem running mpiexec from the PS2019XE command window, as the environment setup properly includes $(I_MPI_ROOT)\intel64\bin\release, which is where impi.dll is installed (or in the debug dir).  

However, from within VS2017, such as when running the debugger, path is only set to $(I_MPI_ROOT)\intel64\bin, so the dll is not found.  It is of course trivial to add $(I_MPI_ROOT)\intel64\bin\release to PATH, but it would be nice if that was setup when PS 2019 XE is integrated into VS2017.

Also, as others have noted, the debugger still has problems displaying values of arrays when hovering over a variable, but you can see them in the watch window.