I'm unable to execute any programs that have internet connotations
plus my e-mail program.
Firefox, Mozilla, ProNews/2, Postroad Mailer etc
The error message is the usual i.e. opens the settings notebook to
check entries and to change if necessary. Nothing wrong with them
that I can see. Anyway, I don't see them all suddenly stopping at
the same time.
Running PRM at the CL gives the message that it cannot find
PMLSETIN.DLL and Firefox something like MOSJ.DLL.
I can only think something has wiped/corrupted some INI or
Table file. I've cleaned the OS INI files but nothing major.
Is there a way to get the programs to see their needed files
other than a re-install?
regards,
Kev
> I'm unable to execute any programs that have internet connotations
> plus my e-mail program.
>
> Firefox, Mozilla, ProNews/2, Postroad Mailer etc
>
> Running PRM at the CL gives the message that it cannot find
> PMLSETIN.DLL and Firefox something like MOSJ.DLL.
>
> I can only think something has wiped/corrupted some INI or
> Table file. I've cleaned the OS INI files but nothing major.
DLLs are nothing to do with INI files.
> Is there a way to get the programs to see their needed files
> other than a re-install?
Has something screwed up your LIBPATH?
You can download
http://hobbes.nmsu.edu/download/pub/os2/util/system/pmdll28.zip and load
the broken executable, eg firefox.exe or prm.exe and see if there is any
obvious missing DLL especially in common to the different programs.
As Paul said, double check your LIBPATH in config.sys and possibly
restore broken DLL from backup.
Dave
ps post results
Maybe it's time for a chkdsk?
Regards
Pete
I presumed some sort of link to call needed DLL's a program
to load. The error message always refers to being unable to
find a DLL.
>> Is there a way to get the programs to see their needed files
>> other than a re-install?
>
> Has something screwed up your LIBPATH?
Nothing that a dozen look sees is able to find. However, a very
old config.sys shows the start of the path with "." (full stop)
but the later ones show the root being the start <drive><slash>.
Thanks,
Kev
Dave,
I cannot believe ALL of the DLL's are corrupt - might be at an
address not expected but other than that I cannot see why it
does not see them. I don't think PRM3 has ever been in any
path (LIB or PATH) and thus all it's needed files are in it's
own directory. I will check some of the older saved config.sys
files to check this aspect,
Thanks,
Kev
Pete,
>Hi Kev
>
>Ke...@yorkie4.plus.com wrote:
>> I'm unable to execute any programs that have internet connotations
>> plus my e-mail program.
>>
>> Firefox, Mozilla, ProNews/2, Postroad Mailer etc
>>
>> The error message is the usual i.e. opens the settings notebook to
>> check entries and to change if necessary. Nothing wrong with them
>> that I can see. Anyway, I don't see them all suddenly stopping at
>> the same time.
>>
>>> snip >>>
> Maybe it's time for a chkdsk?
>
> Regards
>
> Pete
Done so a few times. Frustrating problem.
Kev
>>> I can only think something has wiped/corrupted some INI or
>>> Table file. I've cleaned the OS INI files but nothing major.
>>
>> DLLs are nothing to do with INI files.
>
> I presumed some sort of link to call needed DLL's a program
> to load.
?
I can't even parse this sentence.
> The error message always refers to being unable to find a DLL.
So why don't you believe it?
>>> Is there a way to get the programs to see their needed files
>>> other than a re-install?
>>
>> Has something screwed up your LIBPATH?
>
> Nothing that a dozen look sees is able to find. However, a very
> old config.sys shows the start of the path with "." (full stop)
So put it back.
> but the later ones show the root being the start <drive><slash>.
How many DLLs do you have in your root directory?
Precisely none I'd suspect.
Not corrupt, but not found usually due to the lack of the right LIBPATH
entry. As you noticed you're missing the . which refers to the current
directory. As Paul said, put the . back and things should work.
Dave
Should be:
I presumed some sort of link to call needed DLL's that a program
uses to load.
>> The error message always refers to being unable to find a DLL.
>
>So why don't you believe it?
I do, but the DLL is always present when checked and residing
in it's correct location.
>>>> Is there a way to get the programs to see their needed files
>>>> other than a re-install?
>>>
>>> Has something screwed up your LIBPATH?
>>
>> Nothing that a dozen look sees is able to find. However, a very
>> old config.sys shows the start of the path with "." (full stop)
>
>So put it back.
>
>> but the later ones show the root being the start <drive><slash>.
>
>How many DLLs do you have in your root directory?
>Precisely none I'd suspect.
Exactly why there should be no error in locating the DLL's.
The "missing" full stop in PATH should have read LIBPATH.
Kev
Also, isn't there a maximum length for LIBPATH?
I've never even come close to such a problem with my fairly simple OS/2
workstations, but it has been an 'item of concern' in these ng's in the
distant past.
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm
<snip>
>> The error message always refers to being unable to find a DLL.
>
> So why don't you believe it?
>
>>>> Is there a way to get the programs to see their needed files
>>>> other than a re-install?
>>>
>>> Has something screwed up your LIBPATH?
>>
>> Nothing that a dozen look sees is able to find. However, a very
>> old config.sys shows the start of the path with "." (full stop)
>
> So put it back.
Have now done so and everything executes now.
>> but the later ones show the root being the start <drive><slash>.
>
> How many DLLs do you have in your root directory?
> Precisely none I'd suspect.
None. That is why I didn't think it was the culprit.
I suppose it is to do with the fact that the OS needs
to know where to look and dot is the start. It's just
strange that chkdsk has had to be amended and the
dot and dot dot programmed to be excluded. Another
program I know but allowing different rules always
have the potential to be the cause of problems.
regards,
Kev
Dave,
<snip>
> Not corrupt, but not found usually due to the lack of the right LIBPATH
> entry. As you noticed you're missing the . which refers to the current
> directory. As Paul said, put the . back and things should work.
> Dave
Done this and everything now executes. I presume the
DOT and DOT DOT is the search start point even though
Chkdsk did operate differently by not looking for the root
and had to be amended. Also, it seemed strange that an
older (2006) backup of config.sys had the dot at start of
the LibPath but the current one worked for some years
before throwing a paddy. Oh, well!
regards,
Kev
Jonsey,
<snip>
> Also, isn't there a maximum length for LIBPATH?
> I've never even come close to such a problem with my fairly simple OS/2
> workstations, but it has been an 'item of concern' in these ng's in the
> distant past.
>
> Jonesy
Path certainly does and some length constriction may also
apply to LibPath. However, the solution was to re-insert
the root DOT to the start of LibPath. I hadn't appreciated
that it is required for LibPath besides Path. It took a time
to see that this was one of the differences seen in older
backup's of config.sys. The strange thing is the config.sys
in current use (though not now) has worked without the
dot at the start of LibPath since late 2006.
regards,
Kev
...
However, the solution was to re-insert
> the root DOT to the start of LibPath.
The dot represents the current directory and the double dot it's parent. It has nothing to do with
the root.