SUCCESS!!!

Strangely enough, the only location on DSMRDCRD02 that contains
icuin32.dll
is the E:\Remedy root where we installed version 7.1.

On DSMRDCRD03, I found icuin32.dll in four folders: E:\Remedy,
E:\Remedy\AREmail,
E:\Remedy\AREmail\AssignmentEngine\bin, and E:\Remedy\Aeserver\Api\lib.

That is a puzzle for us to figure out.

At any rate, I added E:\Remedy to the Path on DSMRDCRD02 and the package
now
Works great.

Thanks again for everone's help, particularly Thilo and Jeff.

-----Original Message-----
From: HEWITT, DARRYL 
Sent: Wednesday, March 05, 2008 12:08 PM
To: 'ARSperl User Discussion'
Cc: HEARLSON, KENNY
Subject: RE: [Arsperl-users] ARS 1.90 Can't load ARS.dll

That was great advice, Thilo!  I always forget the Event Viewer!

The following messages were on DSMRDCRD02:

Event Type:     Information
Event Source:   Application Popup
Event Category: None
Event ID:       26
Date:           3/5/2008
Time:           12:00:24 PM
User:           N/A
Computer:       DSMRDCRD02
Description:
Application popup: perl.exe - Unable To Locate Component : This
application has failed to start because icuin32.dll was not found.
Re-installing the application may fix this problem. 

Event Type:     Information
Event Source:   Application Popup
Event Category: None
Event ID:       26
Date:           3/5/2008
Time:           8:14:20 AM
User:           N/A
Computer:       DSMRDCRD02
Description:
Application popup: perl.exe - Unable To Locate Component : This
application has failed to start because arapi70.dll was not found.
Re-installing the application may fix this problem. 

I think I have fixed the message about arapi70.dll.  Now I just have to
resolve icuin32.dll.

Will let you know what happens but I am pretty optimistic that this will
get me there.

Thanks again for you help!

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thilo Stapff
Sent: Wednesday, March 05, 2008 11:57 AM
To: ARSperl User Discussion
Subject: Re: [Arsperl-users] ARS 1.90 Can't load ARS.dll

I've also run into the "Can't load DLL" problem sometimes, but in those 
cases always appeared a popup dialog telling me the name of the DLL that

was missing (e.g. icuuc32.dll).

Apparently that message is also logged in the system events, so you 
might take a look into the Windows Event Viewer messages (in the 
"System" section.


Thilo


HEWITT, DARRYL wrote:
> Thanks, Thilo!
> 
> Oddly enough, the Path on DSMRDCRD02, where ARS.dll does NOT load, has
> "E:\Remedy\AREmail\dsmrdcrd02" and "E:\Remedy\pluginsvr".  The Path on
> DSMRDCRD03, where ARS.dll does load, has "E:\Remedy\AREmail" and
> "E:\Remedy\pluginsvr".
> 
> The ar dll's are in these locations.  The icu...32.dll files are in
the
> AREmail locations as well.  These are the only locations in the Path
> variable that have these files. 
> 
> I copied the arxxx70.dll files to the "E:\Remedy\AREmail\dsmrdcrd02"
> folder but that made no difference.
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Thilo Stapff
> Sent: Wednesday, March 05, 2008 9:21 AM
> To: ARSperl User Discussion
> Subject: Re: [Arsperl-users] ARS 1.90 Can't load ARS.dll
> 
> 
> -- The DLLs need to be in a directory that is contained in your
system's
> 
> PATH variable, exactly as if they were .exe files.
> 
> -- The user tool itself is not needed.
> 
> -- You might, however, need the icu...32.dll files from the user tool 
> directory.
> 
> 
> Thilo
> 
> 
> HEWITT, DARRYL wrote:
>> I am still getting "Can't load 'E:/Program 
>> Files/Perl/site/lib/auto/ARS/ARS.dll' for module ARS: load_file:
>> The specified module could not be found at E:/Program 
>> Files/Perl/lib/DynaLoader.pm line 229".
>>  
>> What I have done since our last email exchange:
>>  
>> 1) Deleted and re-installed ARS Perl package just to make sure I had 
>> done it correctly.
>>     (DOS commands and results are attached)
>>  
>> 2) Copied arxxx70.dll's to the root folder where our Remedy AR Server

>> was installed.
>>  
>> 3) Ran perl -MARS -e "print $ARS::VERSION" to test and received the
> same 
>> error.
>>  
>> 4) After checking the registry, I tried to register dll's with
>>     REGSVR32 "E:\Program Files\AR System\User\arapi70.dll"
>>     but received error:
>>   
>>  
>> 5) Rather than mess with figuring out the dll registration issue, I 
>> installed Remedy User 7.0.1
>>     since I had found registry settings in
>>     
>>
>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDll's
> 
>> folder
>>     for "E:\Program Files\AR System\User\arapi70.dll" on the server
> that 
>> works.
>>     Remedy User 7.1 was already installed on this server.
>>  
>> 6) Ran perl -MARS -e "print $ARS::VERSION" to test and received the
> same 
>> error.
>>  
>> All of the above raises some questions that I hope you will answer.
>>  
>> -- Where is ARSPerl expecting to find the Remedy API's?
>>  
>> -- Does the Remedy User for the correct version need to be installed
> on the
>>    server, or PC, running the Perl package?  Does this also need to
be
> 
>> run where
>>    AR Server is installed?
>>    I had always assumed that ARSPerl was basically mimicking someone
> running
>>    Remedy User.
>>  
>> -- We have been using ARSPerl since 2002 and it has worked well.
>>    However, all I have ever done when moving the location of the Perl

>> scripts
>>    is make sure that the following 3 dll's were present in the Perl
> scripts
>>    folder for the Perl script issuing the "USE ARS": arapixx.dll, 
>> arrpcxx.dll, and arutlxx.dll.
>>    Is this all that really needs to be present?
>>  
>> To repeat some of my previous, we have two Windows 2003 SP1 servers:

>> DSMRDCRD02 and DSMRDCRD03.
>>  
>> I have installed the ARSPerl 1.90 package on both using the same
> procedure.
>>  
>> Running the DOS command line perl -MARS -e "print $ARS::VERSION"
works
> 
>> on DSMRDCRD03
>> but receives the load failure error on DSMRDCRD02.
>>  
>> DSMRDCRD02 was built with the Remedy AR software from scratch, i.e.
> new.
>>  
>> DSMRDCRD03 was built with the Remedy AR software as an upgrade over
an
> 
>> existing install of version 7.0.1.
>>  
>> Any help or suggestions would be greatly appreciated.
>>
>>
>
------------------------------------------------------------------------
>> *From:* [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] *On Behalf Of *jeff murphy
>> *Sent:* Tuesday, March 04, 2008 8:12 AM
>> *To:* ARSperl User Discussion
>> *Subject:* Re: [Arsperl-users] ARS 1.90 Can't load ARS.dll
>>
>> Yes, you'll need to use the same revision of the API that the perl 
>> module was compiled against. The good news is that, from a perl
script
> 
>> perspective, it doesn't matter if you use a 7.0 API against a 7.1 
>> server, or even a 6.3 API against a 7.1 server. There are only a few 
>> edge cases that you might hit against (currency fields iirc) but in 
>> general you should be OK.
>>
>> jeff
>>
>>
>> On Mar 4, 2008, at 11:05 AM, HEWITT, DARRYL wrote:
>>
>>> Thanks for your quick response!
>>>  
>>> Yes, ARS.dll does exist at E:\Program Files\Perl\site\lib\auto\ARS.
>>>  
>>> I have a theory that I would like to run by you.  Does the Perl code

>>> version check the ARS api's when the USE clause is executed?
>>>  
>>> On the server that is not working, we have installed and are running

>>> AR version 7.1 (arxxx71.dll's).
>>>  
>>> On the server that works, we have installed AR version 7.1 
>>> (arxxx71.dll's) but
>>> there also exist arxxx70.dll's, arxxx63.dll's, and arxxx51.dll's.  I

>>> won't even try to
>>> explain how that happened but could that be affecting the load of
> ARS.dll?
>>>  
>>> I realize that ARS 1.90 was written to AR version 7.0.1.  Does that 
>>> mean it will not work with AR version 7.1?
>>
>>
>
------------------------------------------------------------------------
>>
>
------------------------------------------------------------------------
> -
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>>
>>
>
------------------------------------------------------------------------
>> _______________________________________________
>> Arsperl-users mailing list
>> Arsperl-users@arsperl.org
>> https://lists.sourceforge.net/lists/listinfo/arsperl-users
> 
> 
>
------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Arsperl-users mailing list
> Arsperl-users@arsperl.org
> https://lists.sourceforge.net/lists/listinfo/arsperl-users
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Arsperl-users mailing list
> Arsperl-users@arsperl.org
> https://lists.sourceforge.net/lists/listinfo/arsperl-users
> 


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Arsperl-users mailing list
Arsperl-users@arsperl.org
https://lists.sourceforge.net/lists/listinfo/arsperl-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Arsperl-users mailing list
Arsperl-users@arsperl.org
https://lists.sourceforge.net/lists/listinfo/arsperl-users

Reply via email to