[Discussion] OO204 startup problem with LVM

[Douglas Clark]

On Fri, 08 Jun 2007 18:19:06 -0500, mwizard99 at comcast.net wrote:

>For me, I don't think this is a to-do about nothing if I cant get OO to
>run on my system.   Putting the LVM.DLL into my system changed the
>problem, but didn't fix it enough to allow me to run the product.  I've
>followed up with eComstation support.  For those curious, the return code
>changed from 2 to 191.  But the rest of the behavior remains the same.

Mark,

I hesitate to suggest this since it sounds so Microsoft-ish, but you might want to give some 
thought to upgrading to ECS. The basic problem I believe you are running into is that 
developers have used the toolkit from ECS, which has available some features/items that 
don't exist in Warp 4. LVM is one of those features, and I am told that using LVM to query 
the drives on the system is faster than the older methods (haven't done that myself so I 
don't know.)

I don't think this is intentional so much as accidential: if a developer is using Watcom or 
GCC to compile then he probably is using the toolkit that comes with the ECS installation 
CDs, which is a later version than Warp 4. The developer may not even be aware that he is 
using functions that are not available on Warp 4.  If the developer is using VisualAge C++ 
(either version 3 or version 4) then there is a good chance that he is using the toolkit that 
works with Warp 4 since that comes bundled with the compiler - although that is not 
guarenteed because he may have installed the later version.

Most of the stuff that is ported over from Linux will probably be compiled by GCC, since 
that is the compiler of choice in Linux land. So my guess is that you may see this type of 
problem more often in the future, especially with OS/2 software that is ported over from 
Linux.

The problem of writing programs that are really compatible between (plain old) Warp 4 and 
ECS is especially difficult when writing TCP/IP stuff, because IBM "enhanced" the TCP/IP 
package from 16 bit to 32 bit after Warp 4 came out. 

IBM's official policy was to not add features in fix packs. However, many of the Warp 4 fix 
packs had additional / new features added, which apparently was a way for the IBM 
programmers to keep OS/2 up to date without bringing management attention what was 
happening. But the end result for programmers is that it can be pretty easy to use a feature 
that was added in a fix pack (or in a later toolkit) and thereby make a program not work on a 
Warp 4 machine at an earlier fix level.

This problem can also happen with Rexx programs, because IBM added functions to the 
Rexx utilities in fix packs as time went on. It was apparently the only way the programmers 
had to get new features out.

I am not trying to push you in a direction, but merely suggesting that it may be easier in the 
long run to convert than to try and fix individual applications. But you will have to be the 
judge of that - and it will of course depend on how many of these problems you encounter.
Thanks

Douglas Clark