info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Accessing VSAM Data from non-zOS platform
525 views
Skip to first unread message
Timothy Sipples
Oct 9, 2014, 1:10:08 AM10/9/14
to
I think we can safely set aside all the file transfer options discussed in
this thread as nonresponsive. The original poster specified there's a
requirement for live/real-time data access -- that CICS TS, z/OS Batch, and
Java programs must all concurrently read and update the VSAM-based data.
Please don't recommend FTP for application integration purposes, at least
as a general principle. Practically everybody who has ventured down that
path is trying to remediate the resulting business problems.
That warning aside, I've seen some good suggestions, and I'll elaborate on
a couple of my favorites. The IBM software product's exact name is IBM
InfoSphere Classic Federation Server for z/OS, and one of the functions it
provides is JDBC access to VSAM data. You may also need VSAM RLS and/or
Transactional VSAM (DFSMStvs) depending on how much true write/update
concurrency you require and your circumstances.
A really effective approach not yet mentioned is to simply run the Java in
CICS Transaction Server for z/OS itself. CICS Transaction Server Version
5.1 and higher support the WebSphere Liberty Profile (WLP) as a standard
feature at no additional charge, so moving the Java code to CICS TS has
become rather easy. That Java code can then access VSAM directly and
concurrently with non-Java programs running in CICS TS. It's also possible
(and common), as another responder alluded to, to run a portion of the
total Java code in question -- let's call that portion the "data access
objects" -- in WLP within CICS TS, then run other Java components elsewhere
if desired, and if there's merit. (You can often run all the Java in CICS
TS itself.)
If you don't have CICS Transaction Server Version 5.1 or higher yet, have a
chat with IBM. One perfectly viable approach would be to run the current
release of CICS Transaction Server initially only for the wonderful latest
WLP functionality, leaving your other CICS regions at whatever release(s)
they are (initially). You don't have to upgrade everything all at once --
or even anything, initially. (CICS TS is designed to interoperate between
releases this way.) A Single Version Charge (SVC) period may apply (12
months), but talk with your friendly IBM representative about such issues
if they exist.
Yes, Java code running within CICS TS/WLP can access any JDBC-compliant
database, including Oracle Database.
I'm not sure why VSAM transparency into Datacom would be a common solution
unless you happen to have Datacom, so I'm not sure where that idea came
from. However, if you happen to have DB2 then IBM's CICS VSAM Transparency
would provide the analogous approach. That is, you'd move at least the
relevant data from VSAM into DB2 but use IBM CICS VSAM Transparency -- a
product which doesn't actually require CICS, oddly enough -- to keep the
applications that access VSAM data thinking they're still accessing VSAM as
VSAM. DB2 is obviously then reachable via JDBC.
You've also got the various access options via CICS TS, and CICS TS
obviously knows how to access VSAM. Nowadays I would certainly have the
JSON-related options on my short list, but there are many, many options.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
this thread as nonresponsive. The original poster specified there's a
requirement for live/real-time data access -- that CICS TS, z/OS Batch, and
Java programs must all concurrently read and update the VSAM-based data.
Please don't recommend FTP for application integration purposes, at least
as a general principle. Practically everybody who has ventured down that
path is trying to remediate the resulting business problems.
That warning aside, I've seen some good suggestions, and I'll elaborate on
a couple of my favorites. The IBM software product's exact name is IBM
InfoSphere Classic Federation Server for z/OS, and one of the functions it
provides is JDBC access to VSAM data. You may also need VSAM RLS and/or
Transactional VSAM (DFSMStvs) depending on how much true write/update
concurrency you require and your circumstances.
A really effective approach not yet mentioned is to simply run the Java in
CICS Transaction Server for z/OS itself. CICS Transaction Server Version
5.1 and higher support the WebSphere Liberty Profile (WLP) as a standard
feature at no additional charge, so moving the Java code to CICS TS has
become rather easy. That Java code can then access VSAM directly and
concurrently with non-Java programs running in CICS TS. It's also possible
(and common), as another responder alluded to, to run a portion of the
total Java code in question -- let's call that portion the "data access
objects" -- in WLP within CICS TS, then run other Java components elsewhere
if desired, and if there's merit. (You can often run all the Java in CICS
TS itself.)
If you don't have CICS Transaction Server Version 5.1 or higher yet, have a
chat with IBM. One perfectly viable approach would be to run the current
release of CICS Transaction Server initially only for the wonderful latest
WLP functionality, leaving your other CICS regions at whatever release(s)
they are (initially). You don't have to upgrade everything all at once --
or even anything, initially. (CICS TS is designed to interoperate between
releases this way.) A Single Version Charge (SVC) period may apply (12
months), but talk with your friendly IBM representative about such issues
if they exist.
Yes, Java code running within CICS TS/WLP can access any JDBC-compliant
database, including Oracle Database.
I'm not sure why VSAM transparency into Datacom would be a common solution
unless you happen to have Datacom, so I'm not sure where that idea came
from. However, if you happen to have DB2 then IBM's CICS VSAM Transparency
would provide the analogous approach. That is, you'd move at least the
relevant data from VSAM into DB2 but use IBM CICS VSAM Transparency -- a
product which doesn't actually require CICS, oddly enough -- to keep the
applications that access VSAM data thinking they're still accessing VSAM as
VSAM. DB2 is obviously then reachable via JDBC.
You've also got the various access options via CICS TS, and CICS TS
obviously knows how to access VSAM. Nowadays I would certainly have the
JSON-related options on my short list, but there are many, many options.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Govind Chettiar
Oct 9, 2014, 9:26:44 AM10/9/14
to
Since I'm having some difficulty with the quote option, copy-pasting this content
"
We are currently using JRIO (last supported release will be JAVA7). The replacement is the JZOS Toolkit (under application development at this time).
The application connects to a JAVA applet on the mainframe. The data is a VSAM file on z/OS.
Both products are no fee licenses available from IBM.
HTH, "
Alan- but sounds like JRIO/JZOS run on zOS?
"
We are currently using JRIO (last supported release will be JAVA7). The replacement is the JZOS Toolkit (under application development at this time).
The application connects to a JAVA applet on the mainframe. The data is a VSAM file on z/OS.
Both products are no fee licenses available from IBM.
HTH, "
Alan- but sounds like JRIO/JZOS run on zOS?
Govind Chettiar
Oct 9, 2014, 9:38:56 AM10/9/14
to
On Tue, 7 Oct 2014 10:39:03 -0400, Bill Ashton <bill00...@GMAIL.COM> wrote:
>If you need near-time or real-time access to the data, I would recommend
>you look at CA Technologies product called VSAM Transparency for
>Datacom/DB. Having used this for a lot of years, it was great. The
>20-second description is that it allows your application programs to
>continue accessing the database as if it was VSAM, but you also get the
>benefit of a full-blown database file (concurrent online and batch updates,
>SQL access, access through a server, etc.). It is really pretty great to
>use, fairly easy to implement (I believe - I didn't do it), but it is not
>free. We used it for quite a while and converted a couple vendor
>applications using VSAM to the database, and the vendor code had no
>problems. The only real changes were to JCL and to the FCT in CICS.
>
>Billy
>
Billy,
We're not a Datacom shop and I'm not sure if this is a product that enables access to the VSAM datasets from a Linux platform either. Based on what you have said it looks like this is meant for applications that are on zOS? In fact the datasheet at this link
http://supportconnectw.ca.com/public/datacom_ideal/infodocs/vseesa_dbtransoptvsam21.asp
says operating platform is VSE.
Thanks!
>If you need near-time or real-time access to the data, I would recommend
>you look at CA Technologies product called VSAM Transparency for
>Datacom/DB. Having used this for a lot of years, it was great. The
>20-second description is that it allows your application programs to
>continue accessing the database as if it was VSAM, but you also get the
>benefit of a full-blown database file (concurrent online and batch updates,
>SQL access, access through a server, etc.). It is really pretty great to
>use, fairly easy to implement (I believe - I didn't do it), but it is not
>free. We used it for quite a while and converted a couple vendor
>applications using VSAM to the database, and the vendor code had no
>problems. The only real changes were to JCL and to the FCT in CICS.
>
>Billy
>
Billy,
We're not a Datacom shop and I'm not sure if this is a product that enables access to the VSAM datasets from a Linux platform either. Based on what you have said it looks like this is meant for applications that are on zOS? In fact the datasheet at this link
http://supportconnectw.ca.com/public/datacom_ideal/infodocs/vseesa_dbtransoptvsam21.asp
says operating platform is VSE.
Thanks!
Bill Ashton
Oct 9, 2014, 10:39:13 AM10/9/14
to
Well, I am not sure about that document, but we have been z/OS forever,
with no VSE. The VSAMT tool allows the VSAM file to be incorporated into
the Datacom database environment, and is therefore treated like almost
every other database. This means that it is accessible from other mainframe
applications. Also the Datacom Server allows access to Datacom databases
from ODBC and JDBC connections. So I would expect that if your Linux
applications support the use of JDBC/ODBC, then they could use Datacom
Server as well.
--
Thank you and best regards,
*Billy Ashton*
with no VSE. The VSAMT tool allows the VSAM file to be incorporated into
the Datacom database environment, and is therefore treated like almost
every other database. This means that it is accessible from other mainframe
applications. Also the Datacom Server allows access to Datacom databases
from ODBC and JDBC connections. So I would expect that if your Linux
applications support the use of JDBC/ODBC, then they could use Datacom
Server as well.
Thank you and best regards,
*Billy Ashton*
Staller, Allan
Oct 10, 2014, 10:04:12 AM10/10/14
to
Correct!
Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664-3565 | allan....@kbmg.com
<snip>
Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664-3565 | allan....@kbmg.com
<snip>
Since I'm having some difficulty with the quote option, copy-pasting this content "
We are currently using JRIO (last supported release will be JAVA7). The replacement is the JZOS Toolkit (under application development at this time).
The application connects to a JAVA applet on the mainframe. The data is a VSAM file on z/OS.
Both products are no fee licenses available from IBM.
HTH, "
Alan- but sounds like JRIO/JZOS run on zOS?
</snip>
We are currently using JRIO (last supported release will be JAVA7). The replacement is the JZOS Toolkit (under application development at this time).
The application connects to a JAVA applet on the mainframe. The data is a VSAM file on z/OS.
Both products are no fee licenses available from IBM.
HTH, "
Alan- but sounds like JRIO/JZOS run on zOS?
Wayne Bickerdike
Oct 13, 2014, 1:48:46 AM10/13/14
to
Not wishing to denigrate CA-Datacom or VSAMT but the original request was
to retrieve data from VSAM. Your proposal would require CA-Datacom, VSAMT,
CICS Service Facility. You are proposing a million dollar solution together
with the requirement to install and maintain a database with a shrinking
expertise base.
--
Wayne V. Bickerdike
to retrieve data from VSAM. Your proposal would require CA-Datacom, VSAMT,
CICS Service Facility. You are proposing a million dollar solution together
with the requirement to install and maintain a database with a shrinking
expertise base.
Wayne V. Bickerdike
0 new messages