Forget how or why your Web project is in Active Server Pages and the whole debate that accompanies it, and let's discuss something you can use.

The IIS Web server is a DCOM environment. DCOM works like a client/ server application by using proxies to make remote procedure calls to objects. The proxies allow a COM server to acquire a pointer to an object interface, which is a set of functionally related methods; in EAServer this would be called a package's IDL. There are differences between a COM IDL and a CORBA IDL. COM specifies that an interface should follow a memory layout the same way C++ does, which is why you need to create .tlb and .reg files for an IIS Web server for each package in EAServer that you want to call methods on.

The .tlb and .reg files are used in conjunction with the Jagproxy.dll that's installed on the Web server as part of the EAServer client software. They're used to create a CORBA object in a COM wrapper. ASPs then use that object to talk to EAServer components. This is important since the ASP that's using the COM implementation doesn't understand CORBA. The problems associated with bridging COM and CORBA are directly related to the differences in the IDL implementations. The CORBA IDL can specify exceptions while the COM IDL does not, which can obviously cause problems.

Here are a few simple things you can do to save hours of time and eliminate many of the frustrations of using ASP.

• Use the IsObject( ) before the method call on objects.
  It's important that the ASP successfully creates an object and obtains a pointer to an object interface or your method call won't work. This one is pretty obvious and generates an error.

  VBScript runtime error '800a01a8' Object required:

If the Jagproxy.dll wasn't successful in setting the interface pointer for COM correctly, you'll get this generic error that will eventually crash IIS.

error 'ASP 0115' Unexpected error /webapp/mypage.asp A trappable error occurred in an external object. The script cannot continue running.

Using good naming conventions for packages and components helps avoid this. In addition, be sure you're using the right version of the Jagproxy.dll.
• Make sure all variables in the ASP page are typed.
  ASP isn't a strongly typed language. For example, in ASP you can say var = request ("myvar") where myvar can be a string on an integer. ASP can do this by saying every variable is a variant datatype and is automatically subtyped only when the variable is assigned a value. If myvar is a string, var would be a variant datatype with a subtype string; if myvar is an integer, var would still be a variant datatype, subtype integer. If your ASP doesn't have variables subtyped, you may become well aquainted with this somewhat cryptic ASP error message.

  Remote method invocation error '800af157'

The error "800af157" is usually caused by CORBA/ASP conflicts traceable to an ASP variant datatype. IIS doesn't know how to correctly subtype variants from a CORBA datatype and therefore causes this invocation error.

The solution is to strongly type or cast variables into CORBA datatypes so any variables passed to an ORB are not using the ASP variant datatype.

My personal preference in ASP is to declare and type a variable right away.

szString = ""

• Don't return PB exceptions (CTS.PBUserException).
  Don't write bad code. This type of error happens when the PB application code crashes. You can find more detailed information in the srv.log in the bin directory of the EAServer regarding the error. A CORBA exception message, even one that's just indicating the method didn't work, will still cause ASPs to choke.

  The ASP error you see when this is happening is:

  Remote method invocation error '800a2328'
  The invocation of method of_mymethod on Component mypackagename/mycomponent failed

  The method implementation threw a user-defined exception while executing on the Jaguar Server.

• Modify the tx_outcome setting of your components to "Failed."
  Even if your code is bulletproof, sometimes transactions fail for a variety of reasons. When a transaction does fail, an exception is generated. By default, a component in EAServer tries to return this exception to the Web server. In the Jagmanager console, right click on the component and select "component properties". Next, go to the All Properties tab and set com.sybase.jaguar.component.tx_outcome = failed.

• If you have upgraded to EAServer 3.6, there are client-side error messages you can use in your ASP applications.
  Use the Err object in the ASP scripts as described in Chapter 4, "Active X Client Interfaces," of the User Documentation for EAServer.

...exceptions are mapped to the built-in Err object. The exception number maps to Err.Number and the description is available as Err.Description. You can handle exceptions by activating error handling code...

For further details, see the documentation.

Remember, to quickly build robust and effective applications using ASP, be sure variables are subtyped and don't send Null values or CORBA exceptions from EAServer to the Web server.