Skip to main content

GetLocalTime (kernel32.dll) Help

  • June 28, 2013
  • 10 replies
  • 1 view
D

I have the following WS setup:

       01 SYSTEMTIME.
           05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
           05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
           05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
           05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
           05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
           05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
           05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
           05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

and the following Code:

       SET-REFRESH-TIME.
           INITIALIZE SYSTEMTIME.
           SET ENVIRONMENT "DLL-CONVENTION" TO 1.
           CALL "@[DISPLAY]:kernel32.dll".
           CALL "@[DISPLAY]:GetLocalTime" USING
                BY REFERENCE SYSTEMTIME.
           CANCEL "@[DISPLAY]:GetLocalTime".
           CANCEL "@[DISPLAY]:kernel32.dll".

The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

Does anyone have a clue why the above logic will not work when called using Thin-Client?

    10 replies

    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • July 1, 2013

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    I believe it is a PATH issue, as the Thin client will only search the local directory for resources.

    The file path for a called DLL is relative to the directory that contains "acuthin.exe". For example, if "acuthin.exe" is located in C:\\Program Files\\Micro Focus\\Acucbl9xx\\AcuGT\\bin, then the following call:

    CALL "@[DISPLAY]:MYAPP\\MYLIB.DLL"

    refers to C:\\Program Files\\Micro Focus\\Acucbl9xx\\AcuGT\\bin\\MYAPP\\MYLIB.DLL. Note that the CALL statement ignores CODE_PREFIX when it searches for DLLs on the client. CODE_PREFIX is applied only to actions on the application host.

    D

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    So are you saying I need the full path to the kernel32.dll listed in the CALL?

    CALL "@[DISPLAY}:C:\\Windows\\System32\\kernel32.dll".

    I tried this also with no luck.

    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • July 1, 2013

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    When I run your original program through thin client, I placed a monitor on ws-year and it change when initialized and when the call occurred

    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • July 1, 2013

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    I did this with the object file running on a Linux box and the thin client returned the client values.

    D

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    When I attempt this original program the below is what I get...

               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".  
               DISPLAY MESSAGE BOX
                  WS-YEAR
                  "/"
                  WS-MONTH
                  "/"
                  WS-DAY-X
                  " - "
                  WS-HOUR
                  ":"
                  WS-MINUTE.

    YEAR = 56583

    MONTH = 1792

    DAY = 256

    HOUR = 3072

    MINUTE = 6912

    I am running this on AIX Unix called via Thin-Client to a Win7 machine...v 6.2 of Extend.

    Thanks for the help...I am not sure that the difference is an why this will not work correctly for me.

    D

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    When I attempt this original program the below is what I get...

               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".  
               DISPLAY MESSAGE BOX
                  WS-YEAR
                  "/"
                  WS-MONTH
                  "/"
                  WS-DAY-X
                  " - "
                  WS-HOUR
                  ":"
                  WS-MINUTE.

    YEAR = 56583

    MONTH = 1792

    DAY = 256

    HOUR = 3072

    MINUTE = 6912

    I am running this on AIX Unix called via Thin-Client to a Win7 machine...v 6.2 of Extend.

    Thanks for the help...I am not sure that the difference is an why this will not work correctly for me.

    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • July 1, 2013

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    I'm unsure when the @[DISPLAY] syntax was made available. I tested with a current version.

    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • July 1, 2013

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    I compiled with -c61 and -z61 and was still able to execute your code ... no idea why we are seeing differences.

    D

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    If you use one of the current versions (9.1 or 9.2) it will work as expected.  Version 6.2 is not supported on Windows 7.

    D

    I have the following WS setup:

           01 SYSTEMTIME.
               05 WS-YEAR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MONTH         PIC  9(4)  USAGE IS COMP-N.
               05 WS-DOW           PIC  9(4)  USAGE IS COMP-N.
               05 WS-DAY           PIC  9(4)  USAGE IS COMP-N.
               05 WS-HOUR          PIC  9(4)  USAGE IS COMP-N.
               05 WS-MINUTE        PIC  9(4)  USAGE IS COMP-N.
               05 WS-SECOND        PIC  9(4)  USAGE IS COMP-N.
               05 WS-MILLISECOND   PIC  9(4)  USAGE IS COMP-N.

    and the following Code:

           SET-REFRESH-TIME.
               INITIALIZE SYSTEMTIME.
               SET ENVIRONMENT "DLL-CONVENTION" TO 1.
               CALL "@[DISPLAY]:kernel32.dll".
               CALL "@[DISPLAY]:GetLocalTime" USING
                    BY REFERENCE SYSTEMTIME.
               CANCEL "@[DISPLAY]:GetLocalTime".
               CANCEL "@[DISPLAY]:kernel32.dll".

    The above logic works perfect in getting me the local machine time when run locally (without @[DISPLAY}:) logic.   Once I add that and compile to the server and run the logic via Thin-Client I get incorrect/strange values.

    Does anyone have a clue why the above logic will not work when called using Thin-Client?

    This is a byte-ordering issue.  The call to GetLocalTime sets the elementary parameters in the so-called "little-endian" byte order, which is the native ordering for Windows running on an Intel cpu.  When the code is run locally on Windows, or remotely (via Thin Client) on a Linux system, the result is interpreted correctly as both Windows and Linux are running on the "little-endian" Intel architecture (x86 or x64).

    When you run it via Thin Client from an AIX host, the result is mis-interpreted because the AIX system (on a PowerPC or its descendants) uses the "big-endian" architecture.

    I'm not sure if there's a more elegant way to deal with this, but here's a somewhat low-level, brute-force method:

    First, determine if you're on a Big-Endian machine:

           01 double-byte          pic x(2) comp-n.
       01 redefines double-byte.
           03 double-byte-b1   pic x comp-x.
           03 double-byte-b2   pic x comp-x.
...
           move 1 to double-byte
           if double-byte-b1 = 1
               continue            *> it's a Little-Endian system
           else
               perform swap-bytes
           end-if                  *> it's a Big-Endian system

    Then, if it's Big-Endian, swap the bytes:

          *  modified SYSTEMTIME structure with some redefines
      *  so we can address individual bytes
      *
       01 SYSTEMTIME.
           05 WS-YEAR               PIC  9(4)  USAGE IS COMP-N.
           05 redefines ws-year.
               10 ws-year-b1        pic  x     usage is comp-x.
               10 ws-year-b2        pic  x     usage is comp-x.
           05 WS-MONTH              PIC  9(4)  USAGE IS COMP-N.
           05 redefines ws-month.
               10 ws-month-b1       pic  x     usage is comp-x.
               10 ws-month-b2       pic  x     usage is comp-x.
      * ... and so on...

      *  add a tmp-byte variable
       01 tmp-byte                  pic  x     usage is comp-x.


...
      * swap the bytes in each element in the SYSTEMTIME structure

       swap-bytes.
           move ws-year-b1      to tmp-byte
           move ws-year-b2      to ws-year-b1
           move tmp-byte        to ws-year-b2

           move ws-month-b1      to tmp-byte
           move ws-month-b2      to ws-month-b1
           move tmp-byte         to ws-month-b2

      *  ... and so on ...

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement