WildVlad wrote:...
Вы меня не правильно поняли. Я не пытаюсь из-под z/OS подцепиться к AS/400. Более того, используя z/OS-овские дрова это возможно.
.........:
I found on IBMLink (see below). Two links mentioned there:
http://www.ibm.com/software/data/pubs/papers/sqlj/
http://www.stldug.org/pdfs/Vonau.pdf
IBMLink gives:
"Item RTA000174817
Source..........: US DASYS
Last updated....: 08/19/2003
Abstract........: SQLJ Compilation Issues - workstation development - run on z/OS
Q:
Topic thread:
WebSphere and OS390 Servers (WAS390-WEB TECH SALES)
Wepsphere Application Servers for z/OS and OS/390
V4 (Enterprise Edition)
I have a customer developing WebSphere Applications for zOS WAS
4.01. To improve performance the application is using SQLJ to make
calls to DB2. When you use SQLJ with DIRECT BIND option, you must use
DB2 tools "dbprofc.sh" to generate what is known as DBRMLIB entries
for each SQLJ program that will contain the instructions to directly
bind the SQL to the database. DBRMLIBs are PDSs and can only be
generated on 390 (i.e. not portable)
The customer is really up in arms about the 390 Java compile
performance. IBMs 390 JAVA strategy is to develop on a workstation and
run on the mainframe. I am not sure where do go with this but can you
help me find out what recommendations I can make to the customer.
A:
The answer is complicated and I hope you will allow me to back
track somewhat. As of this moment, the SQLJ translator
produces uncustomized .ser file output as well as the input to the
javac. The customization which must occur if SQLJ is to be statically
bound must take place on z/OS. db2profc is run and produces the
customized profile (.ser) and DBRMs. The DBRMs are bound into packages
and the .ser file must be sent back to wherever the application is being
developed (typically WSAD). The .ser file is then packaged into
an .ear file for deployment. I am just recapping what happens today.
There are better times ahead, soon. There is currently a Java
Universal Driver available with DB2 for Multiplatforms (both type
2 and Type 4 drivers).The manner of generating SQLJ will be
changed drastically as is the .ser file. The key is the word
"universal", as the driver to be "universal" across the DB2 family.
That is, it will be the same code executing across all platforms, so
behaviors will be the same.
A new way of creating SQLJ will be universal across the DB2 family.
A new SQLJ translator will produce a portable .ser as well as the input
to javac. db2profc is replaced by a new utility, db2customize that
will customize the profile for the 390 platform while it is on the
workstation. It will bind the packages directly from the
workstation to zDB2. There will be no more DBRMs produced.
The Type 4 Universal Driver has Application Requester code built in
and therefore, from a workstation, has the ability to use DRDA to
connect to zDB2, customize and bind WITHOUT using DB2 Connect as
a conduit. For this functionality the Type 4 driver will be required.
So that takes care of the portability of the SQLJ. And the
.ser remains on the workstation. What else is needed? Help from
WSAD. WSAD 5.1, announced 8/05/03, is expected to provide support
for SQLJ, as a recognized object, and the capability for the developer
to remain on WSAD as he creates SQLJ, invokes the translator and
customizer. WSAD 5.1 is available during August, 2003. And you just
need the "base" WSAD.
These are the WSAD 5.1 functions in support of SQLJ:
Version 5.1 adds SQLJ wizards, editor, and builder support
1. Wizard creates a new SQLJ file in a "Java" project (Web, EJB)
2. Editor extends the Java editor to understand the SQLJ syntax
3. SQLJ errors will appear in the task list
4. The SQLJ translator will be run automatically (as a Studio builder)
It generates the .SER file and Java files
5. Generates Ant script for execution of the profiling operation
6. Can debug SQLJ at a source level (SQLJ files, not generated
Java files)
7. Has wizards to create a new Stored Procedure
8. Includes user selected predefined fragments to simplify creation
9. Editor can view and manipulate the stored procedure
10.Procedure can be built, debugged and executed from Studio
Session EJB or Java bean can be generated to invoke the Procedure
The Universal Driver will be provided in DB2 for z/OS V8 (no announced
GA) and will be retrofitted into the current DB2 for OS/390 V7 via the
service stream. It is planned to be available by year end (2003), but
as with plans, unexpected events can prevent it.
I can't offer your customer relief instantly, but IBM recognizes the
process is cumbersome at best, and I wanted to give you hope.
Q:
Thank you so much for the comprehensive answer below. One point of
clarification. Is this new universal driver going to require
WebSphere V5 with the SKD 1.4?
A:
No. It requires SDK/JDK 1.3. Support is planned for WAS
V5, as WSAD 5.1 aligns with WAS V5.0.2. I don't know if I mentioned
it but the Universal Driver by year end will also be JDBC 3.0
compliant. The main source for the Universal Driver is the README at
http://www.ibm.com/software/data/pubs/papers/sqlj/
A good presentation on it, though I think it is for Universal Driver
V1 is on
http://www.stldug.org/pdfs/Vonau.pdf
Actually I did a Google search on: DB2 Universal Driver SQLJ
and found the above presentation and some other info. Scanning the
articles, I observed most of them are for the V1.0 driver which provided
only the Type 4 driver.
S e a r c h - k e y w o r d s:
Java .ser .ear WSAD WAS V5 WebSphere db2profc db2customize classes
DB2 SPB wizard BIND DBRM"
). Спрашивается чего им не хватило виндовской версии дров? Более того, запустить виндовские дрова на z/OS не получилось - чего то типа не хватило (есть смутное подозрение на EBCDIC, но это может быть и не так).
