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?
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?
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?
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.
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.
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 ?
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.
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.
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.
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.
Comments
I was thinking that was the issue - should NOT be copying any LH DLLs
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.
ENG0805: %3%, line %4%. Function %2% does not exist in dynamic link library %1%.
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.
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?
Which is weird since LH.DLL is a 9.x thing.
Did you ever test Barry's suggestion to test ServerOnly=0?
ENG0805
LH.DLL
GetNetworkType
Out Revparam back as it was. Exact same error.
Never seen that specific problem before in OI 10, so I can only speculate. Hard to guess when I am not seeing it myself.
This maybe why the conversion threw up.
Thanks!
Baby steps.
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!
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.
Again, sorry for the confusion. And thanks
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.
Thanks again! The adventure is just beginning