If you use the BizTalk Adapter for DB2 to connect to a DB2 system, you may see errors similar to the following in the application event log if you use a connection string that does not include a Default Schema:

Event ID: 5743
Source: BizTalk Server
Level: Warning
Description:
The adapter failed to transmit message going to send port “Send Port name” with URL “url”. It will be retransmitted after the retry interval specified for this Send Port. Details: “DB2TEST1.TABLE1 IS AN UNDEFINED NAME SQLSTATE: 42704, SQLCODE: -204”

In this example, DB2TEST1 is the Initial Catalog value that was specified in the DB2 connection string. TABLE1 is the DB2 table name that the query was being submitted against.

If the Initial Catalog value in the connection string is longer than 8 characters in length (e.g. DB2TEST1_TEXAS) and you are connecting to an older version of DB2 (e.g. DB2 for z/OS V7), the error message that is logged will be similar to the following:

Event ID: 5743
Source: BizTalk Server
Level: Warning
Description:
The adapter failed to transmit message going to send port “Send Port name” with URL “url”. It will be retransmitted after the retry interval specified for this Send Port. Details: :"THE NAME DB2TEST1_TEXAS? 8 IS TOO LONG. MAXIMUM ALLOWABLE SIZE IS SQLSTATE: 42622, SQLCODE: -107".

If you don’t specify a value for the Default Schema in the connection string, the BizTalk Adapter for DB2 prepends that Initial Catalog value to the Table name when submitting the query (i.e. SELECT, UPDATE, INSERT) to DB2. This will generally result in an error because the resulting name is not a valid DB2 name.

A different error message occurs when using a long Initial Catalog value against an older version of DB2 because the maximum length for the Schema name is 8 characters. The Initial Catalog value is prepended to the table name in the location that the schema is usually included. Therefore, you get an error about the name being too long.

If a Default Schema is specified in the connection string, the query will include the Initial Catalog, the Default Schema (HISDEMO1 in this example) and the table name as shown here for an UPDATE command:

UPDATE DB2TEST1.HISDEMO.TEST1 SET COL1 = ?, COL2 = ?, COL3 = ? WHERE COL1 = ? AND COL2 = ? AND COL3 = ?

Without a Default Schema, the same UPDATE command would be sent to DB2 as follows:

UPDATE DB2TEST1.TEST1 SET COL1 = ?, COL2 = ?, COL3 = ? WHERE COL1 = ? AND COL2 = ? AND COL3 = ?

Note: You may not see the same behavior when using the same connection string (or UDL) in other scenarios. For example, I was able to use a UDL in the Data Access Tool (DAT) without a Default Schema and I was able to run the Sample Query in the DAT without any errors against the same DB2 system.

If you are using HIS 2010 and want to communicate with IBM DB2 for z/OS V7, you might encounter the following issues.

1) The sample query in the Data Access Tool (DAT) or Data Source Wizard (DSW) fails with the following error:

An internal network library error has occurred. The requested command included a parameter that is not recognized or is not supported by the target system. SQLSTATE: HY000, SQLCODE: –344

The same error occurs when using the BizTalk Adapter for DB2 in the Send Port configuration when trying to list the columns for an updategram.

The SQLSTATE: HY000, SQLCODE: –344 error indicates the following:

DB2 has detected an error while parsing a DDM command received from a local DB2. An instance variable, defined by DDM Level 3 as not valid for this command, has been received as a command parameter.

The error occurs when using the DB2 Adapter included with HIS 2010 because a new DDM code point was added that DB2 for z/OS V7 does not support. The new DDM code point is:

Query Instance Identifier (QRYINSID): This DDM code point was added to the DRDA V3 protocol to add a better mechanism to uniquely identify a query.

IBM added support for the QRYINSID DDM codepoint in IBM DB2 for z/OS V8.

This problem does not occur with the DB2 providers in HIS 2009 because they do not include support for this DDM code point.

2) The following error occurs when trying to create packages from the BizTalk 2010 Add Generated Items wizard:

An internal network library error has occurred. The requested command included a parameter value that is not recognized or is not supported by the target system. SQLSTATE: HY000, SQLCODE: –385

The SQLSTATE: HY000, SQLCODE: –385 error occurs when trying to create DB2 packages using the DB2 Adapter in HIS 2010 against DB2 for z/OS V7.

This error occurs in HIS 2010 because new DDM code points were added to the Create Package process within the DB2 Providers. For example, we added code points to keep prepared statements over commits, so that we could support OpenRowset with FastLoad for SSIS OLE DB Destinations.

IBM DB2 for z/OS V7 did not support these new DDM code points.

As with the first scenario, this problem does not occur with the DB2 providers in HIS 2009.
-----------------------------------------------------------------

HIS 2010 is supported with the following IBM DB2 versions":

Host System                                                                     Product and Version

Relational Database Management Systems                IBM DB2 for z/OS V8.1 and DB2 for z/OS V9.1

                                                                              IBM DB2 for i5/OS V5R4 and V6R1

                                                                                           IBM DB2 for Windows, AIX, HP-UX, Solaris, Linux
                                                                                           V9.1, V9.5, V9.7

The supported versions of IBM DB2 are based on the versions that IBM supports when a version of Host Integration Server is released. These are the DB2 versions supported when HIS 2010 was released.

If you have created DB2 Stored Procedures on an IBM iSeries (AS/400) that have a SPECIFIC name that differs from the PROCEDURE name, the BizTalk Adapter for DB2 does not correctly enumerate these Stored Procedures in the DB2 Adapter Schema Generation Wizard.

For example, I created the following Stored Procedure on an iSeries V7R1 system:

- CREATE PROCEDURE SP_TEST1LONGSTOREDPROCNAME2 (

                IN I_COL1 VARCHAR(8000) , 
                IN I_COL2 CHAR(160) , 
                OUT O_COL2 CHAR(160) ) 
                DYNAMIC RESULT SETS 1 
                LANGUAGE SQL
                SPECIFIC TEST1NAME2

                BEGIN

                            DECLARE R1 INT;
                            DECLARE C1 CURSOR FOR
                                             SELECT COL2 FROM TESTLIB.SPTEST1 WHERE COL1 = I_COL1 ; 
                            DECLARE C2 CURSOR WITH RETURN FOR 
                                             SELECT * FROM TESTLIB.SPTEST1 ; 
                            DECLARE C3 CURSOR for
                                             SELECT COUNT(*) FROM TESTLIB.SPTEST1;
                            INSERT INTO TESTLIB.SPTEST1 ( COL1 , COL2 ) 
                                             VALUES ( I_COL1 , I_COL2 ) ; 
                            OPEN C1 ; 
                            OPEN C2 ; 
                            OPEN C3;
                            FETCH C1 INTO O_COL2 ; 
                            FETCH C3 INTO R1;
                            RETURN 10;
                  END')

In this example, the Procedure Name is SP_TEST1LONGSTOREDPROCNAME2 and the SPECIFIC name is TEST1NAME2. The Stored Procedure has 3 parameters (2 IN and 1 OUT). If I run the DB2 Adapter Schema Generation Wizard from within Visual Studio while working on my BizTalk Adapter for DB2 Application project, SP_TEST1LONGSTOREDPROCNAME2  is returned as one of the Stored Procedures in my library, but it doesn’t list the parameters.

If I recreate this Stored Procedure, but I make the SPECIFIC name the same as the PROCEDURE name (or if I leave it blank), the DB2 Adapter Schema Generation Wizard shows the Stored Procedure and it lists all of the parameter for the procedure.

Upon further investigation, I found that the query issued by the BizTalk Adapter for DB2 to obtain the metadata (e.g. parameter information) for the Stored Procedure passes the PROCEDURE name as the SPECIFIC name when connecting to DB2/400 (iSeries) systems. The metadata query is shown here for this test scenario:

SELECT ''  AS PROCEDURE_CAT, RTRIM(SPECIFIC_SCHEMA)  AS PROCEDURE_SCHEM, RTRIM(SPECIFIC_NAME)  AS PROCEDURE_NAME, RTRIM(PARAMETER_NAME)  AS COLUMN_NAME, ORDINAL_POSITION AS ORDINAL_POSITION, RTRIM(PARAMETER_MODE)  AS COLUMN_TYPE, RTRIM(DATA_TYPE)  AS TYPE_NAME, CHARACTER_MAXIMUM_LENGTH AS COLUMN_SIZE, NUMERIC_PRECISION AS PRECISION, NUMERIC_SCALE AS DECIMAL_DIGITS, RTRIM(IS_NULLABLE)  AS NULLABLE, CCSID AS CCSID, RTRIM(LONG_COMMENT)  AS REMARKS FROM QSYS2.SYSPARMS WHERE SPECIFIC_SCHEMA = 'TESTLIB' AND SPECIFIC_NAME = 'SP_TEST1LONGSTOREDPROCNAME' ORDER BY PROCEDURE_CAT, PROCEDURE_SCHEM, PROCEDURE_NAME, ORDINAL_POSITION FOR FETCH ONLY

In this case, DB2 does not have a Stored Procedure with a SPECIFIC name = SP_TEST1LONGSTOREDPROCNAME so it is not located and no metadata is returned to the DB2 Adapter Schema Generation Wizard.

If the DB2 Adapter is unable to obtain the correct metadata for the Stored Procedure, you will encounter errors if the BizTalk Server application uses the DB2 Adapter to call the Stored Procedure.

This problem was just recently reported by a customer on the HIS Forum, so it appears that having Stored Procedures on IBM iSeries (AS/400) systems with different PROCEDURE and SPECIFIC names is not very common. However, it is something to keep in mind when using the BizTalk Adapter for DB2 to call Stored Procedures on iSeries systems.

The Host Integration Server Product Team has just released the sixth Cumulative Update (CU) for HIS 2009. The cumulative update model is used to package and release product fixes on a more consistent schedule.

HIS 2009 CU6 includes all released fixes for HIS 2009, including all the fixes included in the five previous HIS 2009 cumulative updates. HIS 2009 CU6 includes four new fixes. Details on the included fixes can be found in the following Knowledge Base article:

2851596 Cumulative Update 6 for Host Integration Server 2009

You can download HIS 2009 CU6 via the Hotfix Download Available link in the KB article. You would need to download the CU6 package that matches the HIS 2009 version (x86 or x64) that you have installed.

Thanks…

The HIS 2013 Software Development Kit (SDK) was not included with HIS 2013 as it has been with all prior releases of Host Integration Server. The HIS 2013 SDK has been packaged as a separate download package. This allows updates to the SDK to be made available before the next release of Host Integration Server.

For those customers that use the Transaction Integrator (TI) feature, you will want to go through the ApplicationIntegrationStarterGuide sample because it provides most of the documentation that is available for the many new features in the HIS 2013 version of TI. This sample is located under the \Microsoft Host Integration Server 2013 SDK v1.0\ApplicationIntegration\WindowsInitiated folder after the SDK is installed.

The following link provides an overview to what new with TI in HIS 2013, but the referenced sample includes more details:

http://msdn.microsoft.com/en-us/library/dn148363(v=bts.80).aspx#AppIntegration

Thanks…

The Host Integration Server Product Team has just released the ninth Cumulative Update (CU) for HIS 2010.

HIS 2010 CU9 includes fixes for HIS 2010 that were fixed after the release of HIS 2010, including all the fixes that are in the previous HIS 2010 cumulative updates.

HIS 2010 CU9 includes 13 new fixes in addition to all the fixes included in the previous HIS 2010 CUs. The majority of the fixes are in the Network Integration (e.g. SNA Gateway) feature.

Details on the included fixes can be found in the following Knowledge Base article:

2897923 Cumulative Update 9 for Host Integration Server 2010 is available

You can download HIS 2010 CU9 via the Hotfix Download Available link in the referenced KB article. You need to download the CU9 pacakge that matches the HIS 2010 version (x86 or x64) that you have installed.

The Host Integration Server Product Team has just released the first Cumulative Update (CU) for HIS 2013.

HIS 2013 CU1 includes fixes for HIS 2013 that were fixed after the release of HIS 2013, including some fixes that were previously released for HIS 2009 and HIS 2010. HIS 2013 CU1 also includes functional improvements for the new Transaction Integrator Configuration Tool as well as for the Microsoft Service for DRDA PowerShell module.

Details on the included fixes can be found in the following Knowledge Base article:

2908834 Cumulative update package 1 for Host Integration Server 2013

You can download HIS 2013 CU1 via the Hotfix Download Available link in the referenced KB article. You need to download the CU1 package that matches the HIS 2013 version (x86 or x64) that you have installed.

I ran across an error while doing some testing with Session Integrator in a distributed deployment scenario. By “distributed deployment”, I am referring to a deployment where you have a Session Integrator application running on a system that does not host the 3270 or LUA LUs that the application is using to communicate with the mainframe. The LUs are defined on another HIS Server system which is also the system where the Session Integrator Server service is running that the SI application will be using. The following is an example of the 2 server deployment scenario:

Application Server

• HIS 2013 Server
  • Configured with a Role of Secondary Configuration Server or Use Remote SNA Gateway
• Session Integrator application

HIS Server (SNA Gateway)

• HIS 2013 Server
  • Configured with a Role of Primary Configuration Server
    • This HIS 2013 Server doesn’t have to be the Primary Configuration Server if there are other HIS Servers in the HIS Subdomain, but it is for this example.
  • Host connection(s) to the IBM mainframe
  • LUs (either 3270 or LUA, depending on what you use in your environment) that the SI application will use to communicate with the mainframe application.

In this sample deployment, the SI application running on the Application Server uses the Session Integrator Client (SI Proxy) components of the Session Integrator feature to communicate with the Session Integrator Server service that us running on the backend HIS 2013 Server that hosts the LU(s) used to communicate with the mainframe application.

When I setup this type of environment and ran the LU0NET Session Integrator application included in the HIS 2013 SDK, the following error was displayed:

I knew for a fact that the LU that I was trying to connect to was available, so I started into normal troubleshooting to see what might be happening. Since Session Integrator uses DCOM to communicate between the Session Integrator Client and Session Integrator Server components, my first thought was that this might be happening due to a permission issue such as what I described in my Why does Session Integrator log Event ID 6 and Event ID 24 warnings? blog post. It turns out that this was not the cause of the problem. My next step was to enable Session Integrator Client traces via the HIS Trace Utility (histrace.exe) to see what might be happening. After I reproduced the problem with the traces enabled, I took a look at the Session Integrator Client internal (sicint1.atf) trace and I found the following trace statements when the SI Client was trying to connect to the SI Server service:

Try to create server object on SJACKHIS20131

Got handle 1ae66418 from server
Client providing cookie 0xa0a0a0a1

Failed to create session on SJACKHIS20131, hr = 800706ba

The 800706ba return code indicates RPC_S_SERVER_UNAVAILABLE. This indicated to me that the remote server where the SI Server service was running was not listening or not allowing communication over the network protocol/port being used. Therefore, I captured a network trace of the problem using Network Monitor to see what was happening on the network. What I found was that the Application Server was sending a TCP/IP Syn request to the remote HIS 2013 Server, but no response was being received. The Syn request was resent two additional times per the default TCP/IP retry behavior and then the connection attempt failed. This resulted in the error being displayed by the SI application.

This behavior led me to looking at the Windows Firewall settings on the two HIS 2013 Server systems.

First, I went to the HIS 2013 Server where the SI Server service was being used. The HIS specific firewall rules were enabled, but HIS doesn’t create a specific rule for the Session Integrator Server service. I decided to manually create an Inbound Rule for SIServer.exe (Session Integrator Server service) to allow TCP traffic over all ports to the HIS 2013 Server system to see if that would correct the problem.

Second, I went to the Application Server to modify the Windows Firewall settings to allow the Firewall to “Display a notification” when the firewall blocks a program from receiving inbound connections as shown here:

I did this just to see if I would see any messages when running the SI application.

After making these changes on the two servers, I ran the SI application again. The firewall on the Application Server displayed a popup message when I ran the SI application (LogonScriptClient.exe in this case) as shown here:

After clicking Allow access, the firewall adds two new inbound rules (one for TCP traffic and one for UDP traffic) for this application.

After enabling the new firewall rules, the SI application was able to connect to the SI Server service and it was able to connect to the mainframe application using the LU that was specified in the SI application configuration.

The summary is that to allow this type of Session Integrator distributed deployment to work, you may need to do the following depending on your firewall settings in your environment:

• Setup a firewall rule for the Session Integrator Server service to allow incoming TCP traffic from Session Integrator Clients that are running SI applications in the network.
• Setup firewall rules for the SI application on the Application Server to allow incoming connections for the application.

If the Session Integrator application and the Session Integrator Server service are running under different user accounts, then you may also need to setup the DCOM permissions as outline in the other blog post I referenced above.

Based on feedback from both internal and external sources regarding questions about what the latest updates (fixes) are for both Host Integration Server and the Microsoft OLE DB Provider for DB2 (which is included SQL Server Feature Packs), I created a page that lists the current updates fro these products.

I added the link to the Update Center for Microsoft Host Integration Server and Microsoft OLE DB Provider for DB2 page to the Host Integration Server Developer Center.

The goal is that the page will be updated when we release new Cumulative Updates for HIS and new fixes for the OLE DB Provider for DB2.

Hopefully, this new resource will be useful.

Host Integration Server uses two security groups to implement its security model.  The goal of the security model is to allow the runtime and administrators access to the appropriate HIS resources, but limited to only those resources.  This allows our runtime and administrators to operate as minimum privileged accounts (without the need to have local administrator or act as part of the operating system rights).

HIS Administrators group

This groups grants users the rights to manage and configure Host Integration Server.  The HIS Administrators group has the following rights:

• Rights to start and stop the HIS services
• Read/Write access to the HIS configuration
• Can be granted access to enable HIS traces by the local administrator

HIS Runtime group

This groups grants the HIS service account the rights needed by the Host Integration Server services.  The HIS Runtime group has the following rights:

• Run as a service
• Generate security audits
• Read/Write access to the HIS configuration
• Rights to generate traces

The following table contains various information about several versions of the DB2 Providers included with Host Integration Server (HIS) as well as the Microsoft OLE DB Provider for DB2 (DB2OLEDB) included in SQL Server Feature Packs.

As a side note for those that might not be aware, the Microsoft OLE DB Provider for DB2 included with SQL Server Feature Packs is based on the OLE DB Provider for DB2 that is included with Host Integration Server.

Here is an explanation of the information in each column of the table:

• Product – The product for which the rest of the row information applies to. For example, DB2OLEDBv1 is the Microsoft OLE DB Provider for DB2 V1.0 that was included in the SQL Server 2005 Feature Pack.
• File Version – This indicates the released file version of the DB2 Provider. If you were to install the Microsoft OLE DB Provider for DB2 V5.0 (DB2OLEDBv5) from the SQL Server 2014 Feature Pack, you would find that the file version of msdrda.dll is 9.0.2148.0.
• Supported for fixes? – This information indicates if the specific version is still in Mainstream support, which means that new fixes can still be provided for that version. “No” indicates that new fixes cannot be provided for that version. If the column contains a date, that is the date that the product transitions from Mainstream Support to Extended Support at which time new fixes will no longer be done.
• Dependent Product’s Lifecycle – This column lists product to which the DB2 Provider version’s lifecycle is associated with. This is pretty obvious for the DB2 Providers included with HIS because the HIS lifecycle applies. For the SQL Server Feature Provider versions, the lifecycle is associated with the lifecycle of the specific SQL Server version that that DB2 Provider was included with. The links take you to the product’s lifecycle information on http://support.microsoft.com/lifecycle.
• DB2 for z/OS (Mainframe) – The versions of IBM DB2 for z/OS supported by this version of the DB2 Provider.
• DB2 for iSeries (AS/400) – The versions of IBM DB2 for iSeries (AS/400) supported by this version of the DB2 Provider.
• DB2 for LUW (Linux, Unix, Windows) – The versions of IBM DB2 for LUW supported by this version of the DB2 Provider.

* The DB2 Providers included with HIS 2010 were not supported for use with IBM DB2 for z/OS V10 or IBM DB2 for iSeries V7R1 when HIS 2010 was released. Support for these two DB2 versions was added later. We recommend that you have the current HIS 2010 Cumulative Update (CU) applied when integrating with these DB2 versions. As of June 2014, the current HIS 2010 CU is CU9.

You can refer to the Update Center for Microsoft Host Integration Server and Microsoft OLE DB Provider for DB2 to see the latest updates for HIS and the DB2OLEDB providers.

In addition, please refer to the Microsoft Support Lifecycle site for details on the various lifecycle stages.

For any of you running HIS 2009 in your environments, you should be aware that HIS 2009 has entered the Extended Support phase of its lifecycle as of July 8, 2014.

When a product is in Extended Support, it means that Microsoft Support still provides support, but new hotfixes will no longer be created for any new issues that are identified as bugs. In order to get new hotfixes, you would need to purchase an extended support contract.

The HIS 2009 lifecycle is available at http://support.microsoft.com/lifecycle/?p1=14033.

One final Cumulative Update (CU7) will be released for HIS 2009. The exact release date is not finalized, but it is targeted for sometime in August. The CU7 update will include fixes for HIS 2009 that have been done since HIS 2009 CU6.

If you are using HIS 2009, you should start planning on a plan to move a newer version.

Thanks…

The Host Integration Server Product Team has just released the seventh and final Cumulative Update (CU) for HIS 2009. The cumulative update model is used to package and release product fixes on a more consistent schedule.

HIS 2009 CU7 includes all released fixes for HIS 2009, including all the fixes included in the six previous HIS 2009 cumulative updates. HIS 2009 CU7 includes nine new fixes. Details on the included fixes can be found in the following Knowledge Base article:

2975320 Cumulative Update 7 for Host Integration Server 2009

You can download HIS 2009 CU7 via the Hotfix Download Available link in the KB article. You would need to download the CU7 package that matches the HIS 2009 version (x86 or x64) that you have installed.

As noted above, this is the final Cumulative Update for HIS 2009 because HIS 2009 moved to Extended Support as of July 8, 2014. Please refer to the HIS 2009 lifecycle page for details.