Hey folks-
The following command:
guide REMAD.FILE -a

produces this result for GUIDE_STATS.LIS:

______________________

REMAD.FILE
  Basic statistics:
    File type............................... Dynamic Hashing
    File size
      [dat001].............................. 1073741824
      [dat002].............................. 1073741824
      [dat003].............................. 1073741824
      [dat004].............................. 1073741824
      [dat005].............................. 1073741824
      [dat006].............................. 271676416
      [over001]............................. 1073741824
      [over002]............................. 1073741824
      [over003]............................. 97075200
    File modulo............................. 5508183
    File minimum modulo..................... 10007
    File split factor....................... 75
    File merge factor....................... 40
    File split/merge style.................. WHOLEFILE
    File hash type.......................... 3
    File block size......................... 1024
  Handling status:
    File is skipped because of timeout while starting guide child processes.

Files processed:    1
Errors encountered: 0
____________________________________

Can anyone assist with the timeout issue?
Thanks in advance-
Rich

Richard,

On the off-chance - are you using an antivirus program that is scanning the U2 data files? If so it will be setting exclusive locks and can caise massive delays.

Exclusive lock or permissions would be the usual issues.

Regards

JJ

Hey folks-
The following command:
guide REMAD.FILE -a

produces this result for GUIDE_STATS.LIS:

______________________

REMAD.FILE
  Basic statistics:
    File type............................... Dynamic Hashing
    File size
      [dat001].............................. 1073741824
      [dat002].............................. 1073741824
      [dat003].............................. 1073741824
      [dat004].............................. 1073741824
      [dat005].............................. 1073741824
      [dat006].............................. 271676416
      [over001]............................. 1073741824
      [over002]............................. 1073741824
      [over003]............................. 97075200
    File modulo............................. 5508183
    File minimum modulo..................... 10007
    File split factor....................... 75
    File merge factor....................... 40
    File split/merge style.................. WHOLEFILE
    File hash type.......................... 3
    File block size......................... 1024
  Handling status:
    File is skipped because of timeout while starting guide child processes.

Files processed:    1
Errors encountered: 0
____________________________________

Can anyone assist with the timeout issue?
Thanks in advance-
Rich

The first thing the child guide processes have to do is perform a Windows Authentication Check and this is where the timeout is most likely to occur. The timeout is 300 seconds (5 minutes) on very old releases of UniData (7.2) it was 40 seconds. The message that would be returned is 'File is skipped because of timeout while starting guide child processes.'

You could connect to the console and use the sysinternals tool process explorer to see what the process is waiting on, as the process explorer tool allows you to see the low level api calls being made to the Windows.

Thanks again, Jonathan. You always step up to help. I'm on it.

On another subject:
If I attempt to open a file in UniBasic, when the file is inadvertently already open, UniData will crash and I have to reboot the server in order to start a new instance of UniData. I've corrected the Basic program to check for an open file condition, but is there a way to restart the UniData processes without the server reboot?
Rich

Richard,

I am a bit confussed why UniBasic would crash if a file is already open, can you expand on why needed to check to see if the file was open and what you wanted to do with the file. UniBasic should not crash, you may get a permissions or access denied message if you were trying to do something like delete the file and it was open at the OS level.

In terms of avoiding the reboot ... check out my knowledge base artice on this ... https://my.rocketsoftware.com/RocketCommunity/s/article/Shutdown-UniVerse-UniData-on-Windows

Thanks again, Jonathan. The following UniBasic snippet will absolutely crash my UniData instance if the target file, STLS_RPT.txt  is open:

    OSOPEN DIR_PATH : "STLS_RPT.txt" TO TGT_FILE ELSE
            ***** FILE DOESN'T EXIST → CREATE AN EMPTY ONE BY WRITING TO THE FILENAME
            OSWRITE "" TO DIR_PATH : "STLS_RPT.TXT"
                ***** NOW REOPEN IT
            OSOPEN DIR_PATH : "STLS_RPT.txt" TO TGT_FILE ELSE CRT "UNABLE TO OPEN " : DIR_PATH : "STLS_RPT.txt"
        END    
__________________________________________________________

Hah, I now see a problem right here:
OSWRITE "" TO DIR_PATH : "STLS_RPT.TXT"

...though that isn't the operative problem. The crash is happening on the OSOPEN command....but only if the text file is already open in a Windows text editor, for instance.

Rich

Richard,

Can I suggest a code change for you that will allow you to capture any fatal OS errors such as the file already being open or permissions etc, this is the standard code structure I use for dealing with OSOPEN and OPENSEQ it will avoid UniData aborting on a fatal error condition, in your example you had not coded for that and that's why UniData was aborting.

OSOPEN

001: EQUATE OTHERWISE TO 1
002: FATAL.ERROR = @FALSE
003: OSOPEN "ostext.txt" TO F.OS.FILE ON ERROR FATAL.ERROR = @TRUE THEN
004:   OPENED = @TRUE
005: END ELSE
006:   OPENED = @FALSE
007: END
008: BEGIN CASE
009:   CASE FATAL.ERROR
010: * Deal with Fatal Error
011:   CASE OPENED
012: * File Opened Fine
013:   CASE OTHERWISE
014: * File did not open but didn't encouter a fatal error
015: END CASE

OPENSEQ

001: EQUATE OTHERWISE TO 1
002: FATAL.ERROR = @FALSE
003: FILE.LOCKED = @FALSE
004: OPENSEQ "ostext.txt" TO F.SEQ.FILE ON ERROR FATAL.ERROR = @TRUE LOCKED FILE
.LOCKED = @TRUE THEN
005:   OPENED = @TRUE
006: END ELSE
007:   OPENED = @FALSE
008: END
009: BEGIN CASE
010:   CASE FATAL.ERROR
011: * Deal with Fatal Error
012:   CASE FILE.LOCKED
013: * Deal with File Lock
014:   CASE OPENED
015: * File Opened Fine
016:   CASE OTHERWISE
017: * File did not open but didn't encouter a fatal error
018: END CASE

------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------