Provide Feedback on this Broadcast

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Steve Smaller: Hello, everyone. My name is Steve Smaller. Valerie Thomas and I will be presenting today. This session is for enterprise developers and architects who want to move toward a service-oriented architecture (SOA) using the Microsoft® .NET Framework, but who need to leverage existing investments in line-of-business applications running on IBM mainframes and midrange systems. Host Integration Server 2004 Transaction Integrator, formerly known as COMTI, allows Windows® developers to publish and extend business applications and rules in the mainframe to the Windows environment.

(Slide 2) In this session, we are going to drill down into the features of application integration (AI). At the same time, you will learn how to import COBOL and RPG to efficiently publish XML Web services without knowing SNA networking.

HIS 2004 Application Integration enables modernization for mission-critical applications that reside on the mainframe and on mid-tier systems, such as AS/400. AI extends the line-of-business applications through the use of two features, Windows-Initiated Processing, known as WIP, and Host-Initiated Processing, known as HIP.

HIS 2004 has been updated to support bidirectional integration. In the past, we only supported WIP, but now we're doing the bidirectional, and it's known as HIP. Both WIP and HIP use the same development and administration tools philosophy, and make Host Integration Server seamless and easy to use.

From a HIP perspective, the AI design tool allows COBOL or RPG developers to access Windows services, Web services, and .NET class or COM objects using the programming models and services they are comfortable with, in the CICS, IMS, and AS/400 environments. In both the WIP and the HIP cases, the expertise of the development staff can be efficiently used. There is no need to train Windows development staff in the processes, tools, and languages used to develop host-based applications in CICS, IMS, and AS/400. In a similar vein, there is no need to train mainframe and COBOL and RPG developers on the Windows platform technologies.

HIS 2004 Application Integration features bridge this technology gap in a manner that allows the application developer to leverage expertise and knowledge as efficiently and as productively as possible.

In HIS 2004, the AI feature is designed around SOA. The design tool, TI Designer, is hosted in Visual Studio®, and is used to create the TI projects. This allows HIP and WIP projects to participate in the Visual Studio projects and solutions. The perspective is one of developing an application. So basically, when you create your project, you can have a BizTalk® project; you can have an HIS project; and you can have a Web form or a Windows application.

This level of integration improves development time, simplifies application development, and provides a consistent set of practices and processes for end-to-end application development.

The AI administration console, TI Manager, supports the development experience also. TI Manager is a Microsoft Management Console (MMC) snap-in. This snap-in contains consoles for working with IIS, COM+, and the TI HIP and WIP features. Metadata created in a TI project is consumed by the TI Manager to allow the HIS 2004 AI runtime to direct and execute requests from clients to services residing on Windows or mainframe computing environments.

Through the single console experience, the management and administration of end-to-end applications is from an environment with a single, consistent look and feel.

AI also provides the following functional benefits to end-to-end application design and reliability: 2PC transactions for WIP; the use of either APPC (LU 6.2) or TCP/IP transports for both WIP and HIP; and, of course, no host footprints, which simplifies installation and deployment.

(Slide 3) The mainframe and mid-tier line-of-business (LOB) applications are the mainstay of the enterprise customer's business. These applications are typically written in languages like COBOL and RPG, which contain mission-critical program logic and implement processes that are critical to running day-to-day business activities. These mission-critical applications service requests from end-users, service requests from distributed computing systems, or solicit batch information from branch offices to peer systems.

Application integration with enterprise mainframe and mid-tier computing environments are typically represented by two classes of programs. These are known as business logic interfaces (BLIs) and screen logic interfaces (SLIs). BLI applications are typically batch programs, or programs that are called from terminal applications. In the first case, the batch programs may be written as part of a nightly offline process, to process bulk data from distributed environments, or to solicit information from distributed systems. In the latter case, the terminal application would have been written with the presentation of business logic being separated.

SLI applications are those applications that were written to service online requests from terminal users. The terminal-oriented applications may have been written using different philosophical approaches: 1) Screen logic and business logic intertwined; and 2) screen logic separated from the business logic.

In HIS 2004, AI does not support screen-scraping for terminal-oriented applications. In the cases where the screen logic is separated from the business logic, AI can usually be used to access the program that implements the business logic. In cases where the screen logic and business logic are intertwined, partner screen-scraping technologies can be used. Some of these partners are NetManage, WRQ, ClientSoft, and Farabi.

The other alternative is to rewrite these applications, and in many cases this is very easy. In certain cases, the code may be almost straightforward. For CICS, if the screen logic program is separate from the business logic, and the screen logic program "links" to the business logic program, then AI can be used to access the link to program that implements the business logic. For IMS, if the program is written using MFS with the DLI GU, GN, and ISRT commands, then AI can easily be used to integrate with these applications.

(Slide 4) Now I'm going to go a little bit into SOA. So how does HIS help with SOA? By not having a host footprint, and by working all our application development on the middle tier.

What we're saying here is that basically we don't have to redesign the host application. Well, except on HIP you have to create the host application as a new application. After these applications are created, any changes are really done in the middle tier, basically in the HIP and WIP design interface tools.

What I'm saying is the fundamental business process and offline batch processing remain intact, and we have more efficient distributing processing centers that use current technologies to Web services, .NET objects, SQL Server™ computers, and BizTalk®. So we're allowing you, from a middle-tier point, to take advantage of both the host applications on the mainframe side, plus, on the Windows side, to take advantage of the .NET Framework Web services, and applications such as BizTalk Server.

On the WIP side, client applications that interface with human users can be modernized using current technology trends like Visual Studio .NET, Web services, and of course Windows Forms. On the host side, again, there are no changes at all. CIS, IMS, and AS/400 line-of-business applications stay the same. Again, the integration is being done using our AI feature.

(Slide 5) Now let's drill down a little bit into the first feature, which is Host-Initiated Processing. In HIP, the client application program resides in CICS, IMS, or AS/400 environments. In CICS and IMS, these programs are considered transaction programs and are usually written in COBOL. On the AS/400, the application programs are typically written in RPG.

The HIP client program initiates a request for execution of a service using WAN protocols like SNA and TCP/IP. These client programs are written to use APIs that are native to the environment that the programs are intended to execute in.

For CICS, we support SNA and TCP/IP for the clients. The CICS API for SNA is the set of EXEC CICS commands. There are two programming models that are supported. They are LINK and SEND and RECEIVE. The CICS LINK model is probably the easiest to program against. It involves no communication protocol logic, but only formatting the 32K COMMAREA.

The CICS SEND/RECEIVE model requires more sophisticated programming techniques. This model requires the programming to be explicitly written. The programmer must write APPC protocols for sending and receiving potentially large amounts of data, greater than 32 KB.

If you need 32 KB or less, definitely the CICS LINK model is the way to go. But if your program is going to send down more than 32 KB, yes, we support that too, by using SEND/RECEIVE.

In IMS those two WAN protocols are again supported. Again, we support SNA and TCP/IP. The IMS programs must use APPC or Sockets directly. On IBM mainframes, Sockets is driven through the EAZSOKET API. This API is BSD compatible, of course.

For the AS/400, we only support one protocol currently, which is TCP/IP, and we're making use of the IBM remote program call servers to access the host over TCP/IP.

(Slide 6) The Application Integration development tool is called the TI Designer. It assists the application developer in designing a service definition that bridges the gap between COBOL or RPG application programs that are executed in the mainframe environments, on the mid-range environments, and in the Windows environment.

The TI Designer is hosted in Visual Studio .NET as a Visual Studio Industry Partner (VSIP) environment, and is used to create the TI projects. For example, the TI project can expose a mainframe CICS application program as a Web service, or a BizTalk orchestration-oriented Windows Form.

The TI project interfaces the COBOL to Windows mapping. We're using the COBOL to RPG import wizards to create a .NET class that is a reflection of the COBOL data declaration or RPG data definition. What we're saying here is with COBOL, when you look at the TI Designer —we're going to jump to a picture of it.

(Slide 7) When you take a look at the designer, what we have, on the left-hand panel, is basically a Windows interface and methods. Then on the right-hand side, if we look down the side, we have the properties for that method. What we're doing in the designer is interfacing the COBOL to the .NET data types and the RPG to the .NET data types.

There are two ways to bring this in. You can import it or create it by scratch. In our demos, you're going to see where we're importing the RPG definitions and the COBOL definitions straight through.

On the right-hand side, what you're seeing is that we do most of the hard work in the designer itself. We'll take the mainframe source code, the COBOL or RPG source code, we'll import it, and we're going to map it out across to the .NET data types.

On the right side, and we'll see this better when Valerie does it, you can kind of see the mappings across. Basically, in this case, the tree view on the left and the list view pane in the center depict the details of mapping the .NET method parameters to COBOL data declarations.

Here we're doing the data conversion in our product.

(Slide 8) The HIP administration program, which is known as TI Manager, is used to manage the TI applications and to set them up. It is an NT HIP service. It maintains the execution environment for incoming requests. An application can receive requests from one or more TCP/IP or SNA endpoints.

So the host environment defines the characteristics of a mainframe, such as z/OS or AS/400, where the request would originate from.

For SNA, this is a PLU, a partner LU alias, defined in SNA Manager. For TCP/IP, this is the IP address or the DNS host name. Also, the code page and security characteristics that are expected from the mainframe applications are also defined here.

The local environment defines the characteristics of the endpoint that HIP service will listen on for a company request. For SNA, this is the local LU alias defined in the SNA Manager. For TCP/IP, this is the port number of the service name.

Security policies also must be defined here. Basic credentials are defined for the HIP service. In this circumstance, when a method is executed, it will be executed with the Windows credentials that the HIP service was set up to run under.

You can also use SSO, which is single-sign on capability. SSO can be used to map the mainframe user ID and password that is delivered to the HIP application from the client into valid Windows basic credentials. In this case, what we're doing is taking the mainframe credentials, and we're going to map those to a valid Windows credential.

.NET or COM objects that are to be used by the HIP execution environment must be registered with the TI Manager. These objects must also be created by using the TI Designer. So the objects you create with designer are then brought into the manager to create the actual runtime environment.

Method resolution refers to the process of inspecting the incoming request and determining what method on which object is to be created during the resolution process. The conversion metadata is also identified, allowing the HIP execution engine to receive the incoming data and transform the data stream into the input and output parameter of the method call.

HIP supports the following method resolution types:

Endpoint: Endpoint is where one port or LU/TP name maps to one method in one object. This is a strict one-to-one mapping.

Data: The incoming data stream is inspected for a specific/administrated sequence of characters. The specific character sequence is associated with a specific method on an object. One port or LU can execute more than one method on more than one object using data resolution.

TRM and ELM: These are variants of the data resolution method. They are similar to CICS, TCP/IP, TRM, and ELM programming models. The content of the TRM and ELM are well known. This differs from the data resolution, in that the matching of the character data stream in data resolution can occur anywhere within the data stream, but is a well-defined location in the TRM and ELM data stream headers.

Finally, link to program is a variant of data resolution that is associated with SNA-distributed program link. In this model, the resolution information is delivered in an SNA FMH43 header.

(Slide 9) After all that, let's look at a HIP usage scenario. This HIP scenario shows banking. During business hours, a bank office uses 3270-type terminals to access and update accounts for customer information. This information is maintained in VSAM dataset on the z/Series mainframe. During non-business hours, the production batch system processes the daily activity that was stored in the VSAM dataset, and updates the permanent repositories that are either used for the next business day or are used to update the branch office repositories that are used during the offline queries at distributed sites.

A CICS transaction program is shown as part of the offline process during non-business hours. Part of the processing on the CICS transaction program is to distribute critical data to the branch offices. The CICS transaction program is a HIP client. It reads the information from the daily or the permanent data store, and using HIP TCP/IP processing, delivers the data through one or more RPC calls to a .NET server object on the Windows platform. The .NET server object receives the data, and after additional processes, updates a SQL Server database. This enables the banking applications to efficiently integrate and synchronize online activity, batch processing, and branch office repositories.

(Slide 10) Now let's take a look at the HIP end-to-end flow. This is the HIP architecture. These are the basic building blocks of a HIP end-to-end application. The COBOL client, in this case, known as CedrClie, contains a data declaration in the form of a COMMAREA. The COMMAREA is imported into a TI Project using the COBOL Import Wizard in preparation for creating a TI .NET Object. So now basically we'll put it into the wizard. On the wizard, basically, we're going to create the TI metadata and the .NET assembly.

When the TI object is saved, the TI Designer creates two artifacts: A pristine assembly that represents the interface definitions for the .NET object, and then, also, we have our TI metadata file, which is known as a TIM.

The Transaction Integrator metadata file contains the conversion details used by the HIP runtime engine.

At this point we're going to go the TI manager. The TI manager is used to create the HIP service and application end-to-end, and it defines the listening endpoints — details that the client will use when the CICS program makes a request to Windows.

Now, at this point, we've created an assembly, and so now we can reference the .dll in our C# project. The C# CedarBank.dll is registered to a HIP application and is ready for execution.

The CedrClie transaction program now can make connection requests to the HIP services using the TCP/IP communications protocol. So now what we're going to do is run the CedrClie program and send data.

The HIP runtime receives the data, identifies the object to be created, identifies the method to be executed, converts the data stream into a set of parameters, and then invokes the method on the CedarBank.dll binary executable.

So now we're going through our runtime. At the same time, the HIP runtime converts the output parameters of the data stream and returns the results back to the CICS application, which is CedrClie. So what we've done is we've made the complete connection, where we've picked out the Cedar Bank client, and now we've come back from the Windows application and we supplied the host information we wanted.

At this point, Valerie is going to give us a demonstration of how it all works (slide 11). Valerie, go ahead.

Valerie Thomas: What we're going to do here is a Host-Initiated Processing demo that's going to a live mainframe that we have here at the Microsoft campus. I'm going to use what we refer to as our Cedar Bank tutorial (slide 12). The full tutorial includes the COBOL code that goes on the mainframe side. And this is a good place to start when beginning with Transaction Integrator. We have the tutorial for both HIP and for WIP.

This, right now, I will go through a HIP demo, and a little bit later, we will go through a WIP demo. For this demo, we'll be going through a mainframe, and in the WIP demo we'll be going through an AS/400 system. I'm going to share out my remote desktop here.

(Demonstration) I have a Demo folder where I have put the code for the Cedar Bank sample, and that's the code that I'm going to import through the COBOL wizard. So the first thing I need to do is start a Visual Studio project. I'm going to call this TIFiles. When you install Host Integration Server 2004, you get a new project, which is called HIS projects.

Now I'm going to come in here and I'm going to add a .NET server library, because I'm doing the HIP sample. I can go either with COM or with .NET, and either with a client, which would be a WIP, or with a server for HIP.

I'm going to name my client, CB_Net, and that name can be any name I choose. I just need to know what that name is for later, when I'm programming the .dll to implement this. The interface name I'm going to use is HIPDemo.

Now this is where we would choose whether or not we're going to AS/400 or a mainframe, and we will go mainframe for this demo.

Now I have this started. We have our interface, but there is absolutely nothing here. We don't have any methods yet. So what I'm going to do is import a host definition. That's where this brings up our COBOL Wizard. I can browse out to the COBOL program; that's just a text file. It needs to follow the COBOL rules. So the first seven characters are going to be ignored. We're expecting Zone A to start in column 8.

The method that I'm going to do here, I'm just going to name it GetBalance, because we're going to return a balance up to the mainframe, and we're going to select Use Link programming model here. This has been generated by the COBOL wizard from the working storage section of the sample program. And I need to know my COBOL program well enough to know where an actual data definition is for the data that I'm going to be receiving and then returning to the calling program. So I happen to know that it's under WORKING-STORAGE, under the IO-AREA, and it's COMMAREA-USER-DATA.

I'll select that check box and note that we select just the first of the redefines here. So this is exactly what I want to have. It will pass a name, which is 30 characters; an account, which is 6 characters; and then a balance, which is a COMP-3 field.

In this area, we can choose the whether the data is input, is output, or Both I/O. I'm going to leave this as Both I/O. Generally, for an actual production application, you would be going with one or the other. The program on the mainframe side is going to just be handing us down the name and the account number. We're going to return the balance to it.

This is an area where we can set up for data tables or structures. This is a very simple sample. We're not going to get into the data tables and structures here.

I'm finished with the wizard, so I will click Modify, and it will bring in that method. Now we could go through and manually create this, but the wizard makes things a lot easier. But after we've manually created it, we can certainly look in here to see what was created. The GetBalance method is right here, so that will be exposed with three parameters in it. You can see these parameters over here, it gives give you the information. The first two were String and the direction — that they're In/Out.

Also, we can go to the host data definitions, and we can see here what the COBOL code looks like, as to what we have created through the wizard. This is a good check to verify that it was created the way we expected it to be created.

For the people who are familiar with Host Integration Server 2000, this replaces the Component Builder program. We're going to do everything within .NET now.

So under GetBalance, when I have that highlighted, over in Properties we have all the information that could have been changed in HIS 2000 Component Builder.

Now I want this to be a link, so I'm going to come in here and say, "Yes, it is going to be a CICS link." Then we do have something new that's called Context Parameters. It's an advanced feature for Host Integration Server 2004, which we're not going to get to in this WebCast. We will have a future WebCast that will talk about the Context Parameters. For now, I'm going to set that to False. The Context Parameters would mean we'd have an optional context array that we would need to set up for the parameters when we call this method.

Now we have our TIM, the TI metadata all set up, with the right data types of what we want. So I'm going to click File, and select Save All. Now I'm going to close this solution, because I'm really finished, at this point, with creating the interface piece, all the metadata. And I'm going to go in and create a new project. This time it's going to be C#, and it's the Class Library that is going to actually implement that method and determine what balance we're going to send back to the host.

So we're going to call this csCB_Net. Now the first thing that we'll do is add a reference to the assembly generated when we created that metadata. So I'll add a reference here and browse out. Under my Demo folder I have the TIFiles project. And in that TIFiles project, when I saved everything, it created a .NET assembly, which is CB_Net.dll. So now I have my reference to that assembly.

Now what I'm going to do is add a new class. I'm going to call this class CBHIP for Cedar Bank HIP. This class is going to implement the CB_NetHIPDemo. Now what I need to do is add my code here for the GetBalance. It didn't have a return parameter, so I'm using void CB_Net.HIPDemo.GetBalance. It has three different parameters. They are all by Ref, so we'll do ref string. The first one is the person's Name. The next one is also string, and that's the account number (AccNum). The last one is of type decimal, and that's the account balance (AccBal), which is what we're going to be setting.

So I'm going to check to see what is the AccNum that is coming down. And if it a string that says 123456, then we're going to send back an account balance that is going to be $5,432.44. And the account balance is decimal, so I need the M there. Otherwise, if the AccNum isn't 123456, we're going to give those people an account balance of $75.75.

At this point we'll build the solution, and we succeeded at that. So now we're all set to be able to set this up so that the Host-Initiated Processing will use .dll to know the balance to send back up. We're going to close out of here.

Now after we have the .dll built, we do have to copy those .dll files out to the HIP-implementing assemblies. That's under the Host Integration Server\System\HIP Implementing Assemblies. So we'll get these two .dll files and copy them into that folder. If I don't copy those into that folder, then HIP can't find those .dll files.

Now we're going to go into the TI Manager and get our listener all set up. We have a wizard. One slide earlier showed the local environment, host environment, security, and then the objects. We do have a wizard that will take you through creating all of these. So that's what I'm going to go through right now, which is the new Application Deployment Wizard.

I'm going to call this MyHipDemo. It will be running as a service, so we need to know what account to use for running that service. So I'm using my account. We're going to do a local environment for Cedar Bank here (LE for CB). The network type here will be TCP/IP. There is also an option for SNA, but we're using TCP/IP today. Then there is only the one transport class. Although, in the future, there could be other classes that could be put in there.

I can choose whatever port I want to be listening on. Then, on the mainframe side, the people there have to know what port to send the message to. I can listen on more than one port as well. But for right now, I'm just going to listen on port 1114.

Now I need to set up my host environment. This means that just any host can't be calling down to us. We're only going to respond to a host that we have set up. So another box that wants to call into this has to be configured here so that we know who they are. The Data conversion drop-down box here, again, this is between the mainframe or an AS/400. This is going to be for mainframe. We're using standard EBCDIC.

Now the Remote endpoint manager, this is either the TCP/IP address or the DNS name of the host. The name of our mainframe here at Redmond is MVSRUS. So that's the DNS to use there.

Now here are the different method resolutions. We're using the TRM, so I will choose that one here. We're using MSLink. There are some other options here.

We'll bring that up again.

Steve: Valerie is using an earlier version of HIS. We're now at the RC1 version for this demo shoot. She had an earlier version on our box. I think it was Beta 2 or 3.

Valerie: Yes. So it got partway through the wizard. We have the local environment set up. The host environment was what I was working on when we failed, so I'm going to go into the properties there and just verify that everything is okay. We're TCP/IP, MVSRUS, OS390, EBCDIC, and the type that we want is a Transaction Request Message and the MSLink, so I'll apply that.

Then the wizard has taken us to the security policy, so we'll do that here. I'm just going to call it CedarSec. We're not doing the single-sign on here. We'll just use the Windows credentials of the Host-Initiated Processing application here.

Then, this is where we set up our objects. Again, the wizard would have brought it up for us. We go into the TI metadata that we set up. And we want to choose the one that was under my TIFiles. Then we're going to choose the assembly that we created. The assembly is this csCB_NET.dll. I know that I have the right thing, because the class shows up here. If it doesn't have the correct information within this assembly, the class stays blank.

Now what I need to do is set up a view. And this is a view into that object. So I'll call this a HIPView. This is where we can set up for different local environments and host environments if we want. But this shows our GetBalance method. Right now we don't have any resolution data specified yet, and we need specify that. So I clicked once, and this is all set up for endpoint 1114, meaning we're listening on port 1114.

The link program name, this is the name that the actual program on the mainframe side is going to call down to and say, "I want to call this program." So we're going to say that the mainframe needs to call down and ask for HIP. This could be HIPTest. This could be say XYZ. It doesn't have to be the word "HIP."

Now we're all set here, and we need to start our listener. We've started. We are now listening. I'm going to bring up a screen here to the mainframe and go into our CICS region. Now we have already compiled the programs up on our CICS region, so the program you need to bring up that will make the call down for us is ccli. And we include the mappings for you too, for compiling on the CICS side. That would bring up this sort of a screen.

So we're going to send the name of Jane Doe, and then the account number will start out as 123456. Now the address of the box that I'm working on right now, from the lab, is 172.30.138.80. The port I'm listening on is port 1114, and we are using a TRM. Now if I did a Link to Program Name here of CedarBank, it would fail, because we set it up to say that the Link to Program Name needed HIP. So when I do this, it comes back with the account balance of $5,432.44. If I change that account number to be something different than 123456, the account balance comes back as $75.75. So you can see that we are using the .dll that I wrote.

If I come down here and I call into a wrong port number — and I'm going to let us time out after two seconds — it comes back that there was a SELECT error that occurred on port 1115. So it gives us a little bit of information there. We'd have to go through and troubleshoot that and see what was going on. Of course we know what the problem was; it was the fact that I had changed the port number.

If I change it down here, so the port is again on 1114, but change this to be HIPTEST instead of HIP, it comes back with a message saying, "INVALID LINK TO PROGRAM NAME." So it actually is a very clear message on that one. Over here, look on the server itself, in the Event Viewer; we will see that we have an event that reports a failure. It says, "Unknown TRM Resolution Data: HIPTEST." So it actually gives you some good information in the event log as well.

We'll be going through some troubleshooting, and how to do tracing and some of that, in a later WebCast on Host-Initiated Processing. So I'm done with my demo.

Steve: Very good. It came out very nice. Now we're going to look at Windows-Initiated Processing.

(Slide 13) In previous versions of HIS and SNA Server, we've always had Windows-Initiated Processing, so we'll just have a quick overview. Windows-Initiated Processing (WIP) is similar to HIP, but the roles for where the client and server execute are reversed. In WIP, the client application program resides on the Windows platform, and the services are executed on the mainframe.

The clients are .NET applications or Web services, and are used to access application programs in CICS, IMS, or AS/400 environments. In CICS, these server programs are considered transaction programs, and are usually COBOL. On AS/400, they are just known as application programs and are written in RPG.

WIP clients instantiate TI COM or TI .NET objects as they would any other COM or .NET object. After the object is created, the client program executes the methods in the usual object-oriented manner, passing input, output, and input/output parameters. The WIP client is unaware that execution of the method is really executing a COBOL or RPG program.

The WIP runtime engine acts as a proxy for the client. The WIP runtime proxy intercepts the COM or .NET call and transforms the parameters into a data stream that can be consumed by the CICS, IMS, or AS/400 application.

Basically, just like on the mainframe side, we support TCP/IP and, of course, LU6.2. On the AS/400, again, we're using distributed program link, now known as distributed program call servers.

(Slide 14) We also made some enhancements in WIP. Of course, it's totally compatible with earlier versions. As you've seen already, we've improved the manager, as Valerie was showing, and I'll be showing more improvements and the new wizards that we now have. Of course, the design experience has totally been changed from Component Builder to the new designer built into Visual Studio. Again, we'll be seeing more of that in the demo.

We've also added a couple of new programming models. Of course we've already talked about the AS/400 application using DPC, or distributed program call servers. We've also added the CICS enhanced listener.

We've also added something that Valerie referred to earlier, called Client Context. Client Context allows the client application programs, such as C# and C++, to programmatically send information that will be used by the WIP Runtime engine to override default configuration information or change to communication characters of a method.

The Client Context can be used to allow you to provide override credentials. By this, I'm saying that I can now send the host credentials inside my application. In fact, in the demo we're going to be showing in a few minutes, we'll actually be using that. We'll be sending the AS/400 credentials through the program using client context.

I can also define the format of the of the TCP/IP CICS Transaction Request Message. Also, I can override the target RE set at administration time. Basically, the RE would be the host environment. So I can change the name of the remote host I'm going to. I can override the program I'm going to call on the host at run time, and override the transaction name of the transaction I'm going to call on the host. It's also used when we do the Persistent Connections, which I'm going to talk about next.

One other really cool feature we added was something known as Persistent Connections. A Persistent Connection allows the program to open and maintain a connection over TCP/IP or SNA to a server program across multiple method calls. This does several things of importance.

It improves performance and response time, because the connections are only set up and torn down once. The mainframe resource allocation occurs only on the first method call. Also, the mainframe server program can maintain context across multiple executions. Basically, this allows us to kind of keep state. Now, for a little extra programming, you can kind of keep state where you're at. You can now make sure that the data has been persisted onto the host, or vice versa.

One of the last things we did was we added some bidirectional support. Currently we're supporting Arabic, which is code page 420.

The WIP design tool, as you've seen already, is conceptually the same as the HIP. Again, it's seamless integration. In the demo we're about to do, we're going to have a WIP project, a Web service project, and a Web forms project all on the same solution. Again, it's basically the same thing, we have COBOL RPG importing, and you can also handcraft it, again, just like in HIP.

Data transformation: Again, we have COBOL to .NET, RPG to .NET, and elemental conversion and aggregate conversion also are supported.

(Slide 16) For WIP administration, again, it's similar to what you've seen for HIP. It's a little bit simpler now, because now what we have to define is the remote environment. The remote environment can consist of the IBM host you're going to. For SNA, again, this would be the local LU alias as defined in SNA Manager. And for TCP/IP it would be the DNS name and the port service number.

Again, for the objects, you have to define the environmental characteristics of the .NET and COM objects. Objects represent the .NET or COM interface. They are used by the WIP execution environment. Again, they must be registered with the TI Manager. And of course they must be created using the TI Designer.

One of the things that we're doing this time, when we create the object, is we're going to be creating the .NET proxy for the assembly that was created from the designer. In the project, when we create the Web service, we'll reference not the assembly that was created with designer, but the .NET proxy that was created with the TI Manager.

On the security side, the .NET components make use of the IIS security. And for the COM+ component we make use of the COM+ security. We also can make use of SSO. SSO can be used to map the client's Windows credentials to a valid host user ID and password that is delivered to the IBM host for SNA requests over TCP/IP.

(Slide 17) Let's look at a quick scenario. In this case what we have is a WIP .NET client in a real-time scenario. During business hours, users use Web clients to access and update customer information at the main data center. This information is maintained in a VSAM dataset on the z/Series mainframe.

In this scenario, we're using CICS LINK model. Again, like we said earlier, the CICS LINK model (SNA or TCP/IP) is by far the easiest to program against. It involves no communication protocol logic, only formatting the 32-KB buffer in the COMMAREA. The server program is written to use the CICS COMMAREA which contains the input, input/output, and output data. This allows for exceptionally fast development and deployment times.

On the other side, you'll notice in this case our Web services are going to call over the CICS application, and again, we're going to return the information back and forth.

(Slide 18) Now let's look at the .NET WIP architecture. The TI Designer is used to create the .NET COBOL or the .NET to RPG assembly that represents the interface definitions for the TI object. The TI Manager in turn uses the .NET assembly to create the proxy for the TI object, and locates it in the IIS virtual directory, because we're running under IIS.

The TI Manager also updates the Web config file to indicate that the TI .NET runtime (RBGen) will be executed in the .NET remoting stack at the interception point. The interception point is just prior to the "real" object execution. So what's happening is that we basically reference the client. Because we're using .NET remoting in SOAP, we need to go through the remoting stack, but at the last moment we also want to call our normal TI runtime.

So what's happening is that we're inserting ourselves into the remoting stack, and right before the actual call to the object would be done, we intercept that call and send it to our runtime. At this point, our runtime does the usual stuff, it munges it into a data stream for the host to consume at this time, when the conversion is being done and everything else.

One of the advantages of allowing us to do this is that we don't need any code. The only code that you need to write is to the TI Designer. That's the only thing we have to generate.

(Slide 19) At this point, let's take a look at what we have next. We'll walk through creating a WIP .NET object.

(Slide 20) For this demo we're going to create a WIP .NET object. In this case, we're going to show off our new AS/400 capability. We'll then take that .NET object we create and consume it into a Web service. And finally we're going to consume that Web service into a Web form.

(Demonstration) We're going to look at the program that we're going to call from the host. In this case it's called GetAccts. The AS/400 is a little bit different than the COBOL program. I don't know how many AS/400 programmers we have out there. The callable area in an RPG program is known as a PLIST. Let's take a look at what we have here. There is our PLIST.

In this program, what we're going to do is bring back a data table. In this case, what we have is six records. We've basically done it the easy way here and hard coded. Here's our first record. Our structure contains an account number, an account type, a current balance, if it's account basic or account interest-bearing, the state of the account, and the interest rate. Of course this happens six times.

Again, we have our data area, just like a normal part, and then our data structure. Then when we look at the PLIST, we see in this case we're going to be able to pass back and forth the data structure, the account name, and the account PIN number, and it's going to happen six times.

Let's create a new solution. Now we have a solution, let's add a project. Notice in this case, we're going to create an HIS project. Enter a name. Notice that now you can see this all the different libraries that we support. We have a COM client, server, client, and .NET server. In this case it is going to be a .NET client. This is going to be the name of the assembly. Then the name of the interface. Again, this is based off our Cedar Bank demos. They're included in the SDK.

The protocol is going to be TCP/IP, but this time, of course, we said we're going to use the OS 400, and it automatically picks it. We're only supporting one program model currently, so it comes up by default.

The program library is the actual library that the application is going to reside in. OS 400 is case sensitive. In this case, we want to make sure it's uppercase.

At this time, you can create the parameters by hand, or we can do it by importing. Let's import. I brought down the program earlier. Again, this can be the data area or the whole program. In this case it's the whole program.

Again, because of the fact that this is the name of the program, we can leave the name field alone, but the program name or library name has to be uppercase and spelled correctly. The reason I'm doing the library, for each method we allow you to go to different locations and libraries. So for each method we can actually change the library.

As you can see, we brought in our list. At this point, only the data structure would be returned to us. You can also do this at design time.

Also we can say we want this returned as a data structure, or in this case as a data table. I'm going to say return it as a data table. There's our method, our two input parameters, and our data structure.

Let's make this a little bit more of a friendly name. At this point, we are pretty much done here and we can save this. Now we'll add a new project. I'm going to jump out real quick.

I just said earlier that after I create it, the Web service is not going to take the TI. It's not going to reference the assembly, but I'm going to reference the proxy. That's what I'm creating in the TI Manager. So let's bring up the TI Manager.

We have an existing environment already set to host, and its name is CONDOR, so it's AS/400. Let's look at the properties on that real quick. It's going to be TCP/IP. Again, using a distributed program call. And again, like we said, the port number is 8475. This is a common port number to use for a distributed program call server on AS/400. This is pretty consistent. The DNS name for the box is, again, CONDOR.

Again, you can set the basic language types, local and remote.

Next comes a Security tab. We have an option to enable single-sign on. What we could have done, instead of passing the credentials up in the application, we could have, if we had SSO installed, just say, "Okay, let's just use the user credentials that the application is running on under Windows." Take those, call SSO, map those credentials over to Windows, the mainframe credentials, in this case the AS/400 credentials, and then pass those up with the application, which is a better way to do it. But I kind of want to show off the client contents today.

Now what we do is create the object. So I click New. Then I browse. New solution. There's the .dll. At this time if we needed it strongly signed, we could sign the .dll at this time. One of the things you can do is take one of these proxies and bring it straight into a BizTalk project, if it's simple enough, if it doesn't use arrays. In that case, BizTalk requires that every .dll be strongly signed, that the assembly be strongly signed. So you do want to sign this before you GAC it.

Now we're picking the remote environment we're going to. In this case, CONDOR. We're back to Visual Studio at this point. Now we can add a new project. And we'll use Visual Basic® for a change. I'm going to bring up an ASP.NET Web service.

Just like Valerie did for the HIP, we're going to start off by adding some references. We have to add three different references. We start off with the ClientContext, we're going to use that. We're also using DotNetInvoker, so we have to bring in that one in, the system.runtime.remoting. And there's the .dll.

What I didn't show you is that basically we stick this in a virtual directory, and one of the drop downs is a virtual directory I got to pick when I was creating the object. I'll make this a little simpler. So that I don't make mistakes, I'm going to use a little bit of code that I had lying around.

Looking at it really quickly, like Valerie's, we're going to turn this ByVal, so we have a reference. In this case, we're going to pass back the password. We're going to be take in a password and we're going to take in the account number, and then we're going to return a data set. Again, this is the Cedar Bank example.

This time, because we are using context, I Dim'ed a new object called myContext. This basically is our client context help with .dll. I just Dim'ed TIContext. The next thing I Dim'ed was a new data set, since I'm going to be returning a data set. They're basically the same, myContext, WriteContext, UserId, and Password.

We're going to use the client context, passing the password, and they have the keyword USERID and the keyword PASSWORD, in this case. At this point we should be able to compile it. It looks good.

The next step would be to add one more project. In this case it would be an ASP.NET Web application. I'm not calling any of these the same name. That's the only problem when you add solution after solution, and project after project. Let's add a button. You always need a button. And let's add the grid control. It comes back. Metadata is good.

Let's fancy this up with our auto-format tool. Now we have to add a reference here, and this time it's a Web reference. We're just going to browse for it on Local Machine. It's right here; it's Service 1, Account 6. Then notice you have the getaccts. So actually, at this point, we could enter the service description. Again, it shows that we're passing in. So far it looks good. Add the reference. There is code distilling here. Again, I Dim my dataset, and Dim myservice in this account. We have to get our service, and it should be localhost and Service1.

At this point there's not much else to it. I'm kind of cheating here, so I'm going to pass an ID and password with this call. We do have a couple of other new things, a little housecleaning. We have to set this project as our default project, a setup project. Of course we have set our page to be the default page.

And this is how it works. We click our button. And there are our accounts. Again, it's the same six accounts that we see back on out mainframe, looking back to our AS/400. And here they are again.

That concludes that demo. I think we have time, we're going to look at debugging, and Valerie is going to go through how to use our tracing tools.

Valerie: And then looking at the schedule.

Steve: We'll do that, too. Let's get back to our slides.

(Slide 21) Currently we're an RC1 version of the product, but we are still looking at it for rapid deployment technology people. So basically if you need at least one of these two features, we'd love you to get these as soon as possible and start testing them.

Even at RC1, we are still leaving the beta program open. So if you are interested, definitely give us a call. Or, in this case, go out to the Web site and sign up for the beta. We'll definitely get you up and running as soon as possible.

For a release date, we're still looking to release it by the end of this month; we hope to be out there in the market. Valerie?

Valerie: I'm going to go over some diagnostic information (slide 22). We have kept tracing very similar to what's available in Host Integration Server 2000. Within Transaction Integrator, we have the internal tracing logs. They are created as .log files, but they are just text files. So they can be opened in any text editor that you have. On WIP, we can do that tracing on a server basis. So any WIP components on the server are going to get traced.

With Host-Initiated Processing, we are able to trace on an application basis, and that will help to minimize what the size of the traces are. These traces will dynamically start and stop, so that the process does not have to be shut down for tracing to get going or to be stopped. The tracing is controlled through the TI Manager.

The other diagnostic tool we have that can be very helpful is under Windows-Initiated Processing. We have a feature that allows for record and playback of information, so that you do now have access to a host machine to do some testing. You can record some information from a live host, and then after that you don't need access to the host anymore. You just keep that record file, and you can play it back over and over again. Sometimes that can be helpful, if we're able to reproduce a problem. Get the record file, and we can just keep running through that so you can identify where the actual issue is.

(Slide 23) There is also a tracing line to determine what is going on. Our internal tracing that I was talking about previously does not give us information regarding what the actual data is that was sent to the host or received back from the host. So protocol tracing includes, for TCP/IP, the only thing we have available is the NetMon or some sort of a sniffer trace, just a line trace so that we can actually see what is going out of the box and what is coming into the box.

When you're working with the SNA protocol you can use the Host Integration Server SNA trace utility. That's brought up by clicking Start, clicking Run, and typing in snatrace, and it will bring up the utility for you.

One of the best traces is to just choose the SNA Server Trace item. On the Message Trace tab, the LU6.2 messages work real well. Also, the data link control messages can be helpful. There is a trace item, not SNA Server, but SNA Application, and sometimes it does help to get those. Generally, when we get to this point, you'd be working with a support professional here at Microsoft, and they would let you know what traces are necessary.

(Slide 24) Here's a screen shot for Host-Initiated Processing tracing. We have several categories. Generally, the Convert and the Read Lib, those are going to give you an awful lot of tracing. It depends on what the problem is, but oftentimes those are not necessary. So unless we're having problems with an actual conversion type of an issue, then we don't choose those.

(Slide 25) Here is the Windows-Initiated Processing tracing for TI. Again, it's very similar to Host-Initiated Processing.

(Slide 26) With SNA tracing, here is the screen shot showing us selecting the server Trace Items, going to the Message Trace tab and choosing LU 6.2 Messages at the bottom there.

Another good one that can be useful to us, if we need to get further into it, is the Data Link Control.

When this SNA tracing takes place, it is not a text file that is created. It's going to be an .atf file, and it can only be opened with our SNA Trace Viewer. That does get installed when you install the Host Integration Server product. So it is on the box.

(Slide 27) We do have some samples here of what internal trace looks like. This is getting pretty internal, but sometimes you're able to go in and take a look at these, just to find more about the error. Oftentimes these are very useful. We'll ask for you to send them to the support professionals, if you open a case through Premier Support Services.

(Slide 28) This is a sample of what the SNA trace looks like when you open it up through the SNA Trace Viewer. In this case it's showing the open LU 6.2 request, and then the response is just to come back there. The response is OK.

(Slide 29) Then here is a snippet of what a Network Monitor trace looks like. Now of course it's going to convert the data over on the right to ASCII if there is any EBCDIC data in there. It's not going to convert to EBCDIC all. So it does help. I don't really see any EBCDIC in that particular one.

In the advanced WebCast that we'll be doing, we will cover taking a look at the traces, and actually things to look for, and what it looks like when it's a correct call. It can be very helpful to get a call that's working traced, and then a nonworking call, so that you can compare the two.

Steve: That concludes our demonstration and our presentation for today. Of course, for any more information you want, go out to these two Web sites (slide 30), and you'll find lots more information on HIS and how to use the new features.

In a quick summary, HIS gives you a complete set of tools that lets you extend the mainframe to the Windows environment. We're letting you take them from the Windows environment. You can access your mainframe. And from the host, now you can also access your Windows environment. So the idea, again, is that we're going to extend this platform and let you keep those legacy applications longer, and give you time to migrate back down to a complete Windows solution if you want to. Or if not, just keep integrating. This is why these tools are there, for you to integrate with the Windows environment.

(Slide 32) Of course, this is just one of the many application servers that Microsoft is putting out. Not only do we have SNA Server, we have BizTalk Server, Commerce Server, and of course SQL Server. It's just one piece of the puzzle.

(Slide 33) One of the big things Microsoft is now doing, which we hope everybody will take advantage of, is we're really getting into helping the customer out with our Microsoft community ties. All these Web sites are basically a great place to go. If you have any questions or opinions, this is the place to go about Microsoft products.

Again, thank you very much.

Zherina Salamanca: Thanks, Steve and Valerie. If you find you need more complex technical assistance that might be outside the scope of this discussion, go to http://support.microsoft.com/, or call Microsoft Product Support Services directly to speak to a support professional.

If you would like more information on future Support WebCasts or to review any or our sessions on-demand, visit our main Support WebCasts site at http://support.microsoft.com/webcasts. For this particular session, you'll find a downloadable version of the slides and on-demand streaming media within 24 hours, and a full written transcript within three weeks.

I'd like to ask for any feedback on the sessions we produce or any topics you'd like to see covered in the future. Visit our Contact Us page at http://support.microsoft.com/servicedesks/webcasts/feedback.asp, and select the WebCast Comments link.

It looks like there are no questions today. So we hope this presentation has been helpful to you and your business, and we look forward to your participation in future WebCasts.

I'd like to thank Steve Smaller and Valerie Thomas for giving us a presentation about Host-Initiated Processing, and of course we'd like to thank you, our listeners, for attending today's session.

Thank you, everyone, and have a great day.