Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Going to OI10

2»

Comments

  • Barry - He is referring to the LH related DLLs. This was discussed earlier in this thread.


    I was thinking that was the issue - should NOT be copying any LH DLLs
  • Anyone know what error ENG0805 means? Just a generic error or ?

    This is the help for GetNetworkType:

    /* after the call to GetNetworkType(), NetworkType will be assigned the name of the current driver */

    declare subroutine GetNetworkType

    NetworkType = str(\00\,99) ;* a null string

    GetNetworkType(NetworkType, len(NetworkType)) ;* execute the function

    NetworkType = NetworkType[1,\00\] ;* NetworkType will contain the driver.



  • Anyone know what error ENG0805 means? Just a generic error or ?

    ENG0805: %3%, line %4%. Function %2% does not exist in dynamic link library %1%.
  • Good morning all.. So I did another, separate install of OI10. LH.DLL is not present in the root OI folder. LH.DLL is referenced in the error msg, so I thought I might copy over a re-installed copy. LH.DLL Is in the 9.4 OI folder.

    When I first installed OI, I was able to log into SYSPROG no problem. But when I did the conversion of the first application, I could no longer log in to SYSPROG or the new application.

    Is OI looking for the DLL in a different location now or?

    Somehow I knew this wasn't going to be simple.
  • LH.DLL is not present in the root OI folder. LH.DLL is referenced in the error msg, so I thought I might copy over a re-installed copy. LH.DLL Is in the 9.4 OI folder.

    You might not have understood me when I previously wrote "If this was a problem with OI9, I might have thought that the LH.DLL itself was changed to a different version. But that DLL should not have been changed. In fact, that DLL doesn't exist in OI10. It has been replaced by RevLH.dll."

    Bottom line, LH.dll does not ship with OI10. That is an OI9 specific DLL.

    I'm not sure if you indicated that this second fresh install of OI10 works or not. Can you confirm?
  • Neither install works now. They both throw the same error. LH.DLL

    Which is weird since LH.DLL is a 9.x thing.
  • I don't know what to tell you. If a fresh install of OI 10 won't launch then this suggests nothing was changed in OI 10 itself, but something else is impacting how OI 10 is launching.

    Did you ever test Barry's suggestion to test ServerOnly=0?
  • Are there any new/different parameters in an OI10 Revparam?
  • Changed Revparam to ServerOnly = 0. Tried to log into SYSPROG. I get same error:
    ENG0805
    LH.DLL
    GetNetworkType

    Out Revparam back as it was. Exact same error.

  • I'm about to uninstall/reinstall and start from scratch
  • Uninstalled and reinstalled. I was sure to rename All revparam files in 9.4 system. Followed the instructions exactly. Same result, same error msg. Cannot run either the "new" application or SYSPROG now.
  • Given that you've had one successful install that ran without issue and two successful installs that did not run, I'm inclined to think there is an environmental issue. A/V, malware, blocked files, etc.
  • It's kind of weird that, when launching OI10, I'm getting an error referencing a DLL from 9.4 that's not used in 10 at all.
  • I have had no experience with the dual LH Sevice 5.2. So, does any of the setup instructions require a pointer to the OI9 system, if so, is that still correct location. Looks like to me that the client side LH exe is expecting to find it.
  • ¯\_(ツ)_/¯

    Never seen that specific problem before in OI 10, so I can only speculate. Hard to guess when I am not seeing it myself.
  • Hopefully quick question. The client app in 9.4 has a number of OSFILE entries in the repository. What's the best/safest/most thorough way to get rid of the? Just delete the SYSREPOS records or ?

    This maybe why the conversion threw up.

    Thanks!
  • Nevermind.. got it. We'll see if that fixes the conversion
  • Mystery solved. There are a number of OSFILES referenced in the repository of the 9.4 system. One was REVBOOT. I had to remove the OSFILE pointers before converting; but even then the REVBOOT was overwritten. I replaced that and now I can log into both SYSPROG and the application in OI10.

    Baby steps.
  • That's all very good news except for one thing: this in no way explains why a fresh install still failed to run.
  • When first installed OI10 ran fine. When I created the new application in OI10 it ran fine. It was the conversion tool that caused problems. There were OSFILE pointers in 9.4 that caused those DOS files to be copied over to OI10, specifically the REVBOOT file.

    When I got rid of those, ran the conversion and copied in a REVBOOT file, it's running ok. Now I need to bring in the DLLs that weren't copied in and try setting up the 3 other applications.

    Thanks to Mike Ruane for some serious direction!
  • It was the conversion tool that caused problems. There were OSFILE pointers in 9.4 that caused those DOS files to be copied over to OI10, specifically the REVBOOT file.

    That makes sense for the system that you ran through the migration process. But what about the second clean installation you reported as not working? This would have not gone through any migration process, thus the OI10 files should have been untouched. Something about your story isn't lining up.
  • My apologies. I've actually installed a few times now. The initial installs always work. It is indeed the conversion utility that's been the problem. And you have identified why.

    Again, sorry for the confusion. And thanks
  • I appreciate the apology, but not really needed. I just regret that our communication wasn't clearer as I think we could have helped you identify the problem much sooner. This is why early on I suggested this approach:
    If you can't identify the issue, you might want to just re-install OI10 into a separate folder, confirm that it can launch, and then do a compare of the OS files in REVBOOT to see if anything looks off

    I never got a confirmation that a fresh install would launch (in fact, it seemed that you suggested it wouldn't launch) and I never got a report back saying how the fresh install files compared to the migrated files. That would have spotted the wrong REVBOOT file (and any others) rather quickly.

    Hopefully the above summary will be of use to another person who stumbles onto the same issue you did. That's why we have this forum.
  • It honestly never occurred to me that the problem would be repository entries pointing at OSfiles. But now we know.

    Thanks again! The adventure is just beginning
Sign In or Register to comment.