Data Source on non-Windows Enterprise Servers

Hi All,

I have a question which might not be a burning issue but I am deeply curious about this one. Its known that FAT Clients and Windows Enterprise Servers connect to the DB via ODBC Data Sources, just wanted to know how do AS400s or Unix boxes communicate to DBs located on separate machines? I know the basic link is through JDBC drivers jt400.jar and classes12.jar and the like, but would like to know if there is more to it than meets the eye...

Any inputs would be really helpful...Long live JDEList

Regards,
Renganathan P.

The short answer is JDBNet

This is a very convoluted subject, and might take some time to explain. I already have a whitepaper on my website that explains how JDBNet works - but in effect, the following occurs.

In my example, we have an AS/400 and a Unix box running Oracle. There is some data mapped over to the Unix Box (for example, the Address Book table). This is an inherently bad example, since you should be very careful about what tables are mapped where - and JDBNet has performance issues as you will see in the example - BUT, lets say that this is two versions of OneWorld and you're trying to use OneWorld to copy across some data.

Services have to be installed onto each of the platforms - ie, JDE must be set up on the AS/400 AND the Unix box and correctly configured so that each box can communicate with their local database. This means that a datasource with DBDR needs to be created on the AS/400 and one with OCI needs to be created on the Unix/Oracle box.

Then a JDBNet datasource needs to be created in the SERVER MAP for the AS/400 that points to the Unix datasource.

When the AS/400 then needs data, that request is passed through JDENet as a message to the Unix box - who then grabs the required data (using OCI) and then sends it BACK through JDENet. This is not as efficient as if the data were local and was accessed by the local database - but it does work, and works well, for example, when you are converting from World to OneWorld on a unix platform - or copying data from a legacy system on a different platform.

Hope that explains JDBNet in a high level - it is a very powerful part of JDE and is not often utilized.

Jon,

My understanding is that JDBNET is officially de-supported from 8.95 tools and onwards (as is replication). It may work depending on the situation but that it only because the bits of code needed to make it work are still in the foundation code. I agree that it is a powerful tool despite being slower than native access. I used it pre-8.9 with much success. I would be interested to hear if people have it working in tools releases after 8.94.

Regarding the question posted I read it as more general technology question. e.g. JDE services on Unix hosts use the Oracle client and OCI to connect to a remote Oracle database. JDE services on AS/400 hosts use DRDA to connect to a remote DB/400 database (a remote database being cataloged via a Relational Database Entry).

Hi Jon and Justin,

Thanks for your replies and appreciate the information given. But one thing still remains unclear, if in the post 8.95 era, JDBNET is not being used purportedly, and if AS400 boxes need to access SQL Server as their DB on a Windows box(I know thats a far fetched example), how would they go about doing it...

Apologize if I have not got the concept, and would like you to explain in view of the scenario given above so that I may grasp it better...

Regards,
Renga.

[ QUOTE ]

in the post 8.95 era, JDBNET is not being used purportedly, and if AS400 boxes need to access SQL Server as their DB on a Windows box(I know thats a far fetched example), how would they go about doing it...


[/ QUOTE ]
then they can't (!) If JDBNet isn't supported, then CNC isn't supported either (!), INI files have all been placed into registries and TAM files don't exist either.

I doubt very much that JDE was stupid enough to make the statement that JDBNet was no longer supported without coming up with an alternative methodology. Its a major patent that JDE owns and the most powerful part of JDE's ability to be platform independent.

I checked the 8.12 (8.96) manuals - and they still have instructions on how to install and troubleshoot both JDBNet and replication. While replication isn't necessarily a viable solution anymore (and nobody should even attempt to place it into production) it IS a very powerful part of the JDE Technology, just as JDBNet is. Middlemanagement obviously have no idea about the JDE Technology and statements of support/lack of support with foundation technology are usually bullcrap.

I remember when some idiot stated that JDENet was no longer supported. He was a VP. Wasn't at JDE very long after making idiotic statements like that.

Anyhow, as I stated before - it REALLY isn't a good idea implementing a system with JDBNet - having an AS/400 pull data from a SQL Server isn't a good idea unless its some sort of Z table setup (and really, you should use a client as the go-between in that case). Its a powerful part of the technology - but it really shouldn't be used in production.

Take a look at Solution ID 201009028. It states that in 8.95 JDBNET is not supported. This was in response to a site experiencing intermittent connection failures. I didn't log that call but I saw similar things on 8.95 where datasources were coded to use JDBNET. Changing them to DBDR sorted things out.

Now, I trust that Solution document about as much as I trust the documentation. In other words I distrust them equally. JDBNET may still be supported or they may have just left that section in the manual. It wouldn't be the first time.

If JDBNET is still supported and the expected data volumes are low I would probably still use it. I'll have to give it a try under 8.96/8.97.

Renga,

If JDBNET is no longer an option there are middleware gateway products available for the iSeries that will connect to MS SQL or Oracle. They tend to be expensive though. I have not used a gateway on the iSeries in a long while so I can't speak for current products. In general a gateway product should allow you to connect an MS SQL server to the DB2 catalog in such a way that the tables in MS SQL would appear to be physical files on the iSeries. The foreign tables would then look just like native iSeries DB2 tables to E1 and be accessible to batch jobs and business functions.

A gateway will generally have two components, one that resides on the iSeries and another that resides on a Windows machine with ODBC access to the SQL server. (JDBNET works in this way). I have also worked with gateways that require only the iSeries component and achieve the rest through implementing the "wire protocol" required to talk to the remote database directly. I apologize that I can't give you specific advice on current gateway products.

Now, if JDBNET still works then you have the middleware gateway solution described above included for the price of your JDE license. If you have a current need for this I suggest you open a support case and get the current official answer on support for JDBNET on the latest tools releases. If you do log a case I would be interested to hear the result.

[ QUOTE ]
there are middleware gateway products available for the iSeries that will connect to MS SQL or Oracle. They tend to be expensive though.

[/ QUOTE ]

They also don't work for OneWorld/EnterpriseOne.

Data Dictionary items are handled differently between SQL and Oracle, nulls and zeros are handled differently and LONG RAW datatypes are different.

I tried the Oracle Gateway a while back with an AS/400 customer. It didn't work. JDBNet worked though.

[ QUOTE ]
Take a look at Solution ID 201009028. It states that in 8.95 JDBNET is not supported. This was in response to a site experiencing intermittent connection failures. I didn't log that call but I saw similar things on 8.95 where datasources were coded to use JDBNET. Changing them to DBDR sorted things out.

[/ QUOTE ]

I saw this solution as well. Most of these solution ID's are paraphrased because the technical support person doesn't have the time to fully type out exactly what they are stating. I read the solution ID as "for this requirement, JDBNet is not supported" - ie for connecting a websphere server to the platform, it was not recommended (or supported) to use JDBNet in this manner and DBDR was required.

However, when you connect an AS/400 to a SQL Server - or you connect an AS/400 to a Unix machine, the ONLY method of database connectivity is JDBNet - there IS no other alternative method.

For that situation, I see the 8.96 documentation clearly stating that JDBNet is REQUIRED. I'd go back to Oracle with regard to the original post in this thread, and ask them exactly what they'd recommend if JDBNet was no longer supported. My guess is that there is NO OFFICIAL WORD on "cessation" of JDBNet support - or replication support - and that for certain instances, its not recommended.

I certainly found NO OTHER REFERENCE on the knowledge garden to "cessation of support" for JDBNet. I'd be VERY interested in hearing from Oracle whether they have discovered a replacement for this functionality (or whether they'd rather just not support CNC any more).

This might sound petty - but JDE support personnel have a way of trying to ignore issues / reduce functionality by claiming non-support. We customers have to fight tooth and nail to be heard - otherwise you'll find the UDB will be a non supported platform, soon followed by AS/400 and maybe SQL Server too...

Hi Jon and Justin,

Thanks a ton for your replies! didnt know this post would elicit so much from you people Jon, I read the document on JDBNet on your site too, thanks for the tip...so correct me, if I am wrong, but I will surmise my own given scenario as follows:

JDBNET acting as the mediator, if a AS400 box needs to access a SQL Server DB, then the request is sent from the AS400 server through the Data Source defined in its Server Map and then accesses this particular Windows host through JDEBase middleware. Is that correct?

I didnt get two statements in your document though, which is as below:
[ QUOTE ]
First of all, each of the machines in the enterprise
require the JD Edwards services to be running, and the number of OneWorld “JDBNet” kernels must be set to a
relatively high number on the Enterprise Server

[/ QUOTE ]
Does this mean the DB also needs to have the host code? That does not seem likely to me...

[ QUOTE ]
it is highly recommended that Business Functions are also mapped to the Enterprise Server as much as possible for whatever environment testing is planned.

[/ QUOTE ]
I understand you implied that this setup is meant for JAS instances, but how do we get ESes to fetch data in a FAT or Citrix based scenario in 8.9-8.10?

Sorry if I am stretching this too far, but this is really getting interesting with you people chipping in

Regards,
Renga.