Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / August 2005

Tip: Looking for answers? Try searching our database.

Architecture question on building a wrapper dll around another dll

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Richard - 26 Aug 2005 00:12 GMT
Hi,

I need to wrap a DLL written in Cobol into a .net Dll. I am hoping of some
design guidance.

To call the Cobol DLL basically there 3 data areas that get passed into the
call.

Comm area (which contains the data returned from the call to the Cobol DLL)

Transaction area (which contains the data instructing the Cobol DLL of what
function to execute, login information, return code for success/failure).

Request area (which contains the parameter data Cobol DLL function needs).

All the areas are positional (and dynamic based on the function call) so
without a lot of work on the programers side it is difficult to make sure you
have everything set correctly so you get the required result. That is why I
am wrapping it. So other users can make a simple GetUserInfo(username) and
get a object back that contains the named members.

I have this working for some of the function. But am not sure I am designing
it correctly. I am looking at the patterns books and kind of think Facade or
Adapter. But not quite sure either of them are correct.

I expect I should have one place in the .net DLL that actually makes the
call to the DLL and in the separate functions (GetUserInfo(username)) set the
Transaction and request areas and pass them into the single call. My concern
is the comm area is pretty big (about 3000 bytes). And passing that around
may not be the best solution.

Any guidance is greatly appreciated!

Thanks,
Rich

Signature

Richard Beyea
SoftStuf Software, Inc

David Browne - 26 Aug 2005 02:00 GMT
> Hi,
>
[quoted text clipped - 35 lines]
> is the comm area is pretty big (about 3000 bytes). And passing that around
> may not be the best solution.

I assume that the commarea is a byte array.  Don't worry about "passing it
around" it's a reference type, and you are only passing a reference to it.

here's the right pattern:

public class UserInfo
{
 string FirstName;
 string LastName;
 string Department;
}
public class CobolAdapter
{

 public static string GetUserInfo(string UserName)
 {
   byte[] commArea = new byte[3000];
   byte[] transactionArea = new byte[300];
   byte[] requestArea = new byte[300];

   //set appropriate data into buffers
   CallCobolRoutine(commArea,transactionArea,requestArea);
   bool success = false;
   string errorMessage;
   //marshal the return code into success
   if (!success)
   {
      throw new RuntimeExeption("Cobol Routine Failed " + errorMessage);
   }
   UserInfo rv = new UserInfo();
    //pull info from requestArea and marshal it into rv
   return rv;

 }

 private static void CallCobolRoutine(byte[] CommArea, byte[]
TransactionArea, byte[] RequestArea)
 {
    //PInvoke COBOL .dll here
 }
}

A possible optimization is to use a "Object Pool Pattern" to recycle the
buffers.

David
rbeyea - 26 Aug 2005 02:13 GMT
David,

Thanks! It is about the same I was was thinking. I think I get too hung up
on what the patterns should be.

I will look into then "Object pool pattern".

Thanks again!

rich

Hello David Browne" davidbaxterbrowne no potted,

>> Hi,
>>
[quoted text clipped - 87 lines]
>
> David

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.