Posted on

XBLAS – requirement for some LAPACK images – built and used

Downloaded xblas and accompanying VMSPATCH container from TU Delft, and installed it after setting up the environment. Again, the content of the patch file was put into the package itself, because including the intended structure would require quite a lot of changes in the VMS build-files.
Started the building process, the only changes needed were (again) splitting some lines that cases problems with LIBR commands – lines exceeding the maximum length of 1091 bytes. Also, one more change was added to VMS_Auto64: reading the sourcefile (unit 42) would fail if the linesize exceeded some length (128?). It was solved by adding recordsize of 512 in the OPEN statement.

XBLAS built without problems in the end.

Now I could finish LAPACK built – one of the link commands required XBLAS…

To make things easy, I created subdirectories for each system – XBLAS, LAPACK, NUMPY and SCIPY – under VMSBuild. Each of these hold the structure:

  • [.EXE] to hoild executables (and shared images)
  • [.LIS] to hold list and mapfiles
  • [.LIB] to hold libraries
  • [.OBJ] to hold .OBJ files

    • and after building the subsystem, al files that are to be used elsewhere, are placed in this structure. Files that are only local will be kept within the package.

    It also meant changes in the procedure creating the environment, and in the procedures that build the subsystem.

    Also, I reversed the usage of symbol vms_auto64 – where the mms-files state “sys$library:vms_auto64” that I commented-out in favour of “vms_auto64”. Main reason for this is that both LAPACK and XBLAS referred to sys$library: for the local object-library, but that resides within the sy=ubsystem itself. It meant I had to redefine sys$library anyway, so the [.EXE] directory that is within VMSBuild – and holds vms_aut64.exe – could be added as well.

    All files will be added to the repository

    Posted on

    Lapack 3.9.0 done

    Installed Lapack 3.9.0 aside 3.8.0, and merged the changes that I had to make in the MMS files into the files of 3.9.0 – except what I had to remove from those in 3.8.0. No problems in building – except lines that are too long, but after adding option “recl=512” when one of the files is opened; it seems that default maximum length for read function is 256 – or less. After I extended this to 512, the error was gone.

    It takes several hours before everything is done – but Lapack 3.9.0 is complete.

    Posted on

    LAPACK/BLAS passed – almost

    There is still one thing to do in VMS_AUTH64.exe: if a line – typically a comment) exceeds some size (assumed 256 bytes) the program fails on “input line too long”. The answer is to edit the source, limit the comment lines to 128 bytes (or so) so it won’t hurt anymore.

    In fact, all will now compile, but in the end of BLAS.TESTING there is a problem to be solved:

    link/exec=xblat2s_64.exe sblat2_64.obj,[--]libblas.olb/lib
    %LINK-W-NUDFSYMS, 1 undefined symbol:
    %LINK-I-UDFSYM, lsame64__
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SGBMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SGEMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SSBMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SSPMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SSPR2_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SSPR_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SSYMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SSYR2_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__SSYR_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__STBMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__STBSV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__STPMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__STPSV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__STRMV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %LINK-W-USEUNDEF, undefined symbol lsame64__ referenced
    in psect $LINK$ offset %X00000030
    in module DUMMY__STRSV_64__ file USER:[etw.Lapack380]libblas.olb;2
    %MMS-F-ABORT, For target xblat2s_64.exe, CLI returned abort status: %X10648268.
    %MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.

    No idea where that comes from. I found one file that defines it: DOPMTR_64.f:
    ...
    * =====================================================================␍
    SUBROUTINE DOPMTR( SIDE, UPLO, TRANS, M, N, AP, TAU, C, LDC, WORK,␍
    $ INFO )␍
    !DEC$ ATTRIBUTES ALIAS:'dlarf64__' :: dlarf
    !DEC$ ATTRIBUTES ALIAS:'dopmtr64__' :: dopmtr
    !DEC$ ATTRIBUTES ALIAS:'lsame64__' :: lsame
    !DEC$ ATTRIBUTES ALIAS:'xerbla64__' :: xerbla
    !DEC$ ATTRIBUTES ADDRESS64 :: AII
    ...

    and there are quite a lot of sources that define LSAME – as a logical
    * .. External Functions ..␍
    COMPLEX*16 ZLARND␍
    DOUBLE PRECISION DLARND␍
    LOGICAL LSAME␍
    EXTERNAL ZLARND, DLARND, LSAME␍
    * ..␍
    It may be that there was something during build that failed.

    Posted on

    Building lapack package once more

    Lapack again

    Re-installed lapack 3.8.0 from the netlib.org site, via via: the tar.gz file didn’t untar on VMS, so did it on the workstation, zipped the result and transferred that to Diana – and that did indeed unzip properly. Next, unzipped the VMS_Patch.zip onto the machine and copied the files into Lapack3.8.0 – as is done specificly. Started mms to build it all: and ran into the very same issues as before.: It meant I might need to changed sources (comment lines too long, so split them up). But I did have made changes before to cope with that, and that version was not on SSY$LIBRARY as supposed in decrip.mms but in a separate, central directory. I had to make another change in that code, LINK added the full path – including “000000” – to the filespecification in the .MAP file…
    One that was done, the second descript.mms file still helt the “make” command – the image was added in the same central directory, downloaded from TU Delft as well and build locally – but that found the Makefile descrtiption that doesn’t hold the ‘lapack’ target so failed. Changed that to mms – and now it builds…

    Posted on

    Started bullding LAPACK package on VMS

    The top level of LAPACK contains the descript.mms file that build it all:
    all :
    set default [.install]
    $(MMS)$(MMSQUALIFIERS)
    set default [-.src]
    $(MMS)$(MMSQUALIFIERS)
    set default [-.blas]
    $(MMS)$(MMSQUALIFIERS)
    set default [-.TESTING]
    $(MMS)$(MMSQUALIFIERS)
    set default [-]

    so a simple
    $ mms
    should do the trick. but first, there is this extra file to build. Again, life is made easy using mms:

    $ set def [.vms_auto64_2^.8]
    $ mms

    cc/define=(VMS)/comment=as_is/prep=vms_auto64_.f90 vms_auto64.f90
    f90/list/show=all/obj=vms_auto64.obj vms_auto64_.f90
    delete vms_auto64_.f90;*
    link vms_auto64.obj
    f90/name=lower dummy_auto64.f90
    All done
    $ dir

    Directory USER:[000000.prj.vms_auto64_2^.8]

    descrip.mms;1 dummy_auto64.f90;1 dummy_auto64.OBJ;1 MODULE_FIRSTNS.F90$MOD;1
    MODULE_IARGC.F90$MOD;1 MODULE_LASTNS.F90$MOD;1
    vms_auto64.EXE;1 vms_auto64.f90;1 vms_auto64.obj;1 vms_auto64_.LIS;1

    Total of 10 files.
    $ copy vms_auto64.EXE sys$library

    Next, running the .mms file in the [.INSTALL] directory of LAPACK this works until an error occurs:

    cc/define=(VMS)/comment=as_is/prep=slamch.f_ slamch.f
    fortran/name=lower/float=ieee/ieee=denorm/nowarn/list/show=all/obj=slamch.obj slamch.f_
    pipe link/map/full/exec=nl: slamch | copy sys$input nl:

    mc sys$library:vms_auto64 slamch.map slamch.lis
    %FOR-F-INPRECTOO, input record too long
    unit 442 file USER:[prj.lapack.INSTALL]slamch.f;1
    user PC 00000000
    -RMS-W-RTB, 140 byte record too large for user's buffer
    %TRACE-F-TRACEBACK, symbolic stack dump follows
    image module routine line rel PC abs PC
    LIBRTL 0 00000000000741FC FFFFFFFF80CA41FC
    DEC$FORRTL 0 000000000004E284 FFFFFFFF810D4284
    DEC$FORRTL 0 0000000000071318 FFFFFFFF810F7318
    vms_auto64 MODULE_LASTNS VMS_AUTO64 558 0000000000003968 0000000000033968
    0 FFFFFFFF8037FC44 FFFFFFFF8037FC44
    %TRACE-I-END, end of TRACE stack dump
    %MMS-F-ABORT, For target slamch.obj, CLI returned abort status: %X101880B4.
    %MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.
    $
    Examining why this happend, I found that line 157 in slamch.f exceeds 128 bytes; this is just a comment, it seems CRLF at the ‘normal’ length (72 characters) is missing so the line extends to 140 – causing the problem. breaking the line in two at position 72 solved the problem. The same happened in dlamch_64 where I also split the line. I notified Jouk Jansen (who did the porting) of this issue.
    Further down the line creating and populating the oject library missed an object file and that file indeed was missing:
    ibrary/crea [-]liblapack.olb dlamch.obj,dsecnd_INT_CPU_TIME.obj, ilaver.obj,lsame.obj,second_INT_CPU_TIME.obj, slamch.obj
    library [-]liblapack.olb dlamch_64.obj,dsecnd_INT_CPU_TIME_64.obj, ilaver_64.obj,lsame_64.obj,second_INT_CPU_TIME_64.obj, slam
    ch_64.obj
    link LAPACK_version.obj,[-]liblapack.olb/lib
    link/exec=LAPACK_version_64.exe LAPACK_version_64.obj, [-]liblapack.olb/lib
    %LINK-F-OPENIN, error opening USER:[prj.lapack.INSTALL]LAPACK_version_64.obj; as input
    -RMS-E-FNF, file not found
    %MMS-F-ABORT, For target LAPACK_version_64.exe, CLI returned abort status: %X1064109C.

    Next I built BLAS – by changing defaut add run the mms-file: here no problems at all, should be placed in the library.

    Next, downloaded SciPy and Numpy, and MatPlotLib and it’s subsets. However, this requires Python 3.5 which is not available on VMS = being 2.7. Perhaps there are older version,s but where to get them? The site sint very clear on that: So ask around.