storm@ambush.UUCP (08/27/87)
Background ---------- One of our customers are planning to build a large database on an IBM/MVS system (this is where the disk space is), but they wish to use a UNIX system as a front-end to the system, i.e. extract a subset of the database (an address list, say) and process it on the UNIX system (that is where the tools are). Questions --------- Are there any database systems that support this setup ? I know that ORACLE runs on both MVS and on UNIX, but can they communicate on a higher level (i.e. share data) ? Which UNIX systems can talk to an IBM mainframe (besides providing 'dumb' 3270 emulation on a UNIX terminal) ? Is there any other way to do it (i.e. let a UNIX program emulate a 3270 terminal when talking to the IBM system) ? Since I don't know much about the IBM mainframe world, please provide any information on this subject - big or small. If you don't think it is possible to use a UNIX box as front-end to an IBM database, please tell me why. TiA -- Kim F. Storm, storm@ambush.uucp (or ..!mcvax!diku!ambush!storm) AmbraSoft A/S, Rojelskaer 15, DK-2840 Holte, Denmark. tel: +45 2424 111
bradbury@oracle.UUCP (Robert Bradbury) (09/03/87)
In article <463@ambush.UUCP>, storm@ambush.UUCP (Kim F. Storm) writes: > Questions > --------- > > Are there any database systems that support this setup ? I know that > ORACLE runs on both MVS and on UNIX, but can they communicate on a > higher level (i.e. share data) ? > The problem is that there are no "good" ways to connect IBM O.S. to the outside world. IBM is working on TCP/IP for VM and MVS but the availability is 6 months to a year (I think). IBM wants everyone to talk SNA and the hardware/software from outside vendors isn't there yet. (DEC is getting fairly close according to Computerworld). Oracle can run networked databases between UNIX boxes and UTS (currently in Alpha using TCP/IP). We should have MSDOS to VM/MVS running this fall (using a 3270 interface I think). I doubt there will be anything for UNIX to VM/MVS in the near future (there isn't much market demand for it yet). > Which UNIX systems can talk to an IBM mainframe (besides providing > 'dumb' 3270 emulation on a UNIX terminal) ? Is there any other > way to do it (i.e. let a UNIX program emulate a 3270 terminal when > talking to the IBM system) ? > Gregory Minshal wrote a program called tn3270 which provides a TELNET interface between IBM machines and UNIX machines. It is found in the user contributed software on our Pyramid and has a University of California copyright. It handles the mapping between the 3270 and dumb terminals quite well. It is heavily dependant on the BSD TELNET interface. (If anyone has adopted this to run on an EXCELAN telnet interface (on VMS) I'd like to hear about it.) -- Robert Bradbury Oracle Corporation (206) 364-1442 hplabs!oracle!bradbury
jdg@dolphy.UUCP (Jesse Goodman) (09/04/87)
> In article <463@ambush.UUCP>, storm@ambush.UUCP (Kim F. Storm) writes: > > Which UNIX systems can talk to an IBM mainframe (besides providing > > 'dumb' 3270 emulation on a UNIX terminal) ? Is there any other > > way to do it (i.e. let a UNIX program emulate a 3270 terminal when > > talking to the IBM system) ? > > IBM's SNA LU 6.2 facility, meant to support system-to-system communication, is an alternative. AT&T has a product which supports this. I don't know (but doubt) if any DBMS vendors have integrated support for it yet. There's stuff built in to handle transaction processing style applications with commits, backouts, etc. which is hardly surprising given IBM's fetishes. Jesse Goodman ..!allegra!phri!dolphy!jdg ..!cmcl2!phri!dolphy!jdg (212) 787-3318
dennisg@pwcs.StPaul.GOV (Dennis Grittner) (09/04/87)
In article <321@oracle.UUCP> bradbury@oracle.UUCP (Robert Bradbury) writes: >In article <463@ambush.UUCP>, storm@ambush.UUCP (Kim F. Storm) writes: Sorry to post this - but my Mail to ambush was returned 'host unknown' so I thought I'd post. Some people at Johns Hopkins ( I think ) wrote some RPC stuff for an IBM mainframe so that a Pyramid running Ingres was serving database info to the mainframe host. Wish I could be more specific, but I think all the origional folk that did it are now gone to other places and projects. Anyway, you might check with Johns Hopkins. -- Dennis Grittner City of Saint Paul, Minnesota (612) 298-4402 Room 700, 25 W. 4th St. 55102 "Let's just put Ollie, Ronnie, and the rest in jail!"
larry@postgres.uucp (Larry Rowe) (09/04/87)
tcp/ip implementations are actually being done by a group out of univ. of wisc. (larry landwebber is contact). they have implemented and delivered a VM implementation that can be purchased from ibm. i believe they are working on a MVS version, but i don't know the details. you might try sending email to larry at landwebber@uwisc.edu (or some such addr). as mentioned by bradbury, tcp/ip is not something that ibm wants to support so they don't really communicate it to their sales force. the odds are you're going to have to find someone else running it and get the details from them. btw, if anyone else has more details, i suspect several other readers on this newsgroup would be interested (including me!). larry
ron@topaz.rutgers.edu (Ron Natalie) (09/05/87)
First, I should point out that I hold Oracle and the Three Initial Corporation (RSI?) behind it in pretty low esteem. They're customer support is about the worse I've seen, which is compounded by the preponderance of bugs in their software. As for getting information between mainframe and UNIX machine there are essentially two ways. One, is that you can get TCP/IP for your IBM and write network utilities based on TCP. The second is to use an IBM based network product that talks IBM-ese to the IBM. An example of this is the SunLink products soon to be unleased on the public. -Ron
ron@topaz.rutgers.edu (Ron Natalie) (09/05/87)
> IBM is working on TCP/IP for VM and MVS but the availability > is 6 months to a year (I think). TCP/IP Networking code has been available for VM and MVS for a while now. You can even get it direct from IBM now. > IBM wants everyone to talk SNA and the hardware/software from outside > vendors isn't there yet. Not quite true. While this was the strategy in the past, IBM recently realized they were losing out big in the research/academic environment. I've seen lots of indications that the are on to TCP in a big way. Part of this is being helped by joint projects with a number of Universities around the country. These TCP/IPers in IBM are actually making some decent headway now. > IBM wants everyone to talk SNA and the hardware/software from outside > vendors isn't there yet. (DEC is getting fairly close according to > Computerworld). Of course, this involves the least amount of work for them. But, how many non-DEC things talk DECNET? Sun has recently announced a whole line of SunLink products for both DECNET and IBM. > Oracle can run networked databases between UNIX boxes and UTS. For those who don't know UTS is Amdahl's UNIX under VM. This is not much of a solution to the problem for IBM users. This really just converts your IBM hardware. Since it is ASCII it needs special hardware to directly connect terminal lines (fortunately they are working on TCP so you can telnet in). > We should have MSDOS to VM/MVS running this fall (using a 3270 interface I > think). I doubt there will be anything for UNIX to VM/MVS in the near > future (there isn't much market demand for it yet). -Ron
davy@ea.ecn.purdue.edu (Dave Curry) (09/05/87)
In article <3589@zen.berkeley.edu> larry@postgres.UUCP (Larry Rowe) writes: > >as mentioned by bradbury, tcp/ip is not something that ibm >wants to support so they don't really communicate it to >their sales force. the odds are you're going to have to >find someone else running it and get the details from them. IBM most certainly does have TCP/IP... at least for VM/CMS. In fact, they just announced a new version of it a month or two ago. It uses a DACU (Device Attachment Control Unit - a "7170", I think). It seems to understand subnets and the whole deal; Purdue has it running on their 3083 and one of their 4341s. I use "tn3270" to go from my Sun, through about three gateways, and onto the 3083 regularly with no problems. If you're truly desperate, I could dig up the product numbers and things for you, send me mail. FTP seems to work quite well. TELNET is there, but you have to run in ECMODE (full-duplex instead of half-duplex). TELNET'ing to a UNIX system using a 3270 block-mode terminal is "interesting", to say the least. It's usally easier to log in on UNIX and use "tn3270" (makes a serial terminal look like a 3278). --Dave
mjr@well.UUCP (Matthew Rapaport) (09/05/87)
Sorry I can't give you any details (I don't remember it all), but there were articles in various Unix publications over the last year or so regarding UNIX/SNA drivers running on Unix hosts. This might give you the data extraction capabilities you require... If I find the specific references over the next day or so, I will post them mjr@well ptsfa!well!mjr
mjr@well.UUCP (Matthew Rapaport) (09/06/87)
A very brief and cursory search in Knowledge Index's COMP4 database turned up the following three references on linking UNIX to IBM's VM and MVS under SNA. I do not know if any of the technologies described here are actually implemented in off the shelf products, but the articles themselves probably contain other references. If you need to find products, consultants, etc., I do this for a living (at least in part) so send me mail -- 'ptsfa!mjr!well' or 'mjr@well' if you know a good domain server! 1156562 DCM85H0111 Bringing Unix Machines within an IBM Network. Mendelsohn, M.P. AT&T Information Systems , Lincroft, NJ Data Communications Vol.14, No.9, Aug. 1985, P. 111-115. 5 Pages. COUNTRY OF PUBLICATION: U.S.A. LANGUAGE: English CODEN: DACODM ISSN: 0363-6399 DOCUMENT TYPE: Journal ARTICLE TYPE: Technology; How-To SPECIAL FEATURES: includes Chart UNIX-based machines can be linked to both BSC (binary synchronous communications) and SNA (system network architecture) protocols without altering the five UNIX system calls. Transmission between asynchronous terminals occurs one character at a time, contrasted to half-duplex protocols which are batch oriented and pass files in logical groups in one direction at a time. Both devices can request permission to transmit at the same time; one device designated as winner, one as loser, with the winner then going into a receive mode. Half-duplex protocols should have point-to-point arrangements which are either leased or switched with that information then passed on to the device driver. A 2780/3780 terminal can function as three devices: the card reader is used as the transmission device, the line printer and card punch are used as the two output devices. The biggest problem in implementing half-duplex contention protocols in the UNIX system is passing enough information to manage communication links between the user and the device driver. The solution is in four areas: building a structure to hold information that must be present before communications can begin; using an IOCTL system call to pass and obtain information not available on any other system call; having an information header precede all data passed between user and device driver; and expanding the set of return values for all system calls indicating to the user what action must be provided. Charts listing sequences between devices for both protocols are included. OPERATING SYSTEM: UNIX DESCRIPTORS: UNIX; Operating Systems; Communications Modes; Asynchronous; Half Duplex; Receive-Only; Send/Receive; Protocol; Networks; SNA; Interface; How-to Information 3/L/2 1144764 UNW84L0090 Pseudo-Device Provides SNA Communications for the Unix System. Heath, R.A. NCR Corp. , UNIX World Vol.1, No.7, Dec. 1984, P. 90-93. 3 Pages. COUNTRY OF PUBLICATION: U.S.A. LANGUAGE: English ISSN: 0739-5922 DOCUMENT TYPE: Journal ARTICLE TYPE: Technology SPECIAL FEATURES: includes Diagrams IBM's Systems Network Architecture (SNA) is not a component of the Unix operating system. The integration of both systems requires application software and kernel pseudo-devices. A diagram compares the interdependent SNA layers with the layers of Unix. Five layers of SNA must be distributed within three layers of Unix. Layers must be able to communicate without using pipes. A diagram shows how a pseudo-device bridges the SNA layers within Unix. Data flows in and out of a kernel when it crosses the SNA layers. A diagram shows how batch and interactive traffic can be combined over a single communications line. Such a technique greatly reduces line costs. A SDLC device driver controls the SDLC functions for SNA. Other standard protocols can be combined in a similiar way. OPERATING SYSTEM: UNIX DESCRIPTORS: SNA; Protocol; Networks; Data Communications; UNIX; Micro-Mainframe Communication; Network Architecture; Technology 3/L/3 1124247 MIC85A0038 SNA to UNIX; UNIX to SNA. Wise, T.; Forgetta, V. Pathway Design , Wellesley, MA Micro Communications Vol.2, No.1, Jan. 1985, P. 38-42. 3 Pages. COUNTRY OF PUBLICATION: U.S.A. LANGUAGE: English DOCUMENT TYPE: Journal ARTICLE TYPE: Technology SPECIAL FEATURES: includes Diagrammatic Models UNIX needs a connection to the IBM mainframe environment in order to achieve a long term presence. In order to ensure a consistency of operation and data sharing and integrity, UNIX-based systems must be able to communicate with IBM hosts. Pathway Design examined four approaches in designing a UNIX-to-SNA connection. The approaches differ due to the organization of the SNA layers as they are incorporated into the UNIX architecture. Diagrammatic models of the SNA models, application implementation approaches, and future alternatives are included. Layers are grouped into three categories: the device driver, the deamon and the user layer. Approach one includes only the comms layer in the device driver. Approach two includes the comms and SDLC layers in the device driver. Approach three includes the PC,SDLC and comms layers in the device driver. Approach four places all SNA and SDLC layers within the kernel. The optimal approach for designing a UNIX gateway is difficult to select. OPERATING SYSTEM: UNIX PRODUCT NAME: uniPath , , Pathway Design , Network Control Processors DESCRIPTORS: Micro-Mainframe Communication; Multiuser Microcomputers; Distributed Systems; Kernels; UNIX; Network Architecture; SNA; SDLC; Protocol; Networks; Presentation Layer Control
whwb@cgcha.UUCP (09/07/87)
> Questions > --------- > > Are there any database systems that support this setup ? I know that > ORACLE runs on both MVS and on UNIX, but can they communicate on a > higher level (i.e. share data) ? > > Which UNIX systems can talk to an IBM mainframe (besides providing > 'dumb' 3270 emulation on a UNIX terminal) ? Is there any other > way to do it (i.e. let a UNIX program emulate a 3270 terminal when > talking to the IBM system) ? As far as I know there is only one product around which give you the connection at this time. It is the backend-database system TERADATA, which is channel-attach to the IBM and has a TCP/IP connection out of their own machinery to UNIX. Since you have to buy soft- and hardware for this connection, you must spend at least spend 300.000 $ for it. The address of TERADATA is 12945 Jefferson Boul.,LA, CA 90066, (213) 827-8777 and 138b High Street, Esher, Surrey KT10 9QI, ENGLAND (372) 68933. The other manufacturers still have problems to support a common set of protocols to connect the two machines in the necessary functionality. But I suppose that in a year .... H.W.Barz, WRZ, CIBA-GEIGY, CH-4001 Basel
tmp@j.cc.purdue.edu (Tom Putnam) (09/08/87)
In article <3589@zen.berkeley.edu> larry@postgres.UUCP (Larry Rowe) writes: >tcp/ip implementations are actually being done by a group out >of univ. of wisc. (larry landwebber is contact). they have >implemented and delivered a VM implementation that can be >purchased from ibm. Your information is a year or more out of date. Landwebber et.al. were responsible for the initial project, but they have not been active with this stuff for quite a while. Check IBM Programming Announcement dated April 21, 1987 for the announcement of the TCP/IP for VM. The new product is based upon the old WISCNET stuff but looks very much more up to date. We are running the old WISCNET, but we just received the new TCP/IP from IBM last week. The IBM stuff now includes FTP, SMTP (mail), TELNET, interfaces to TCP and UDP for C and PASCAL, Internet subnet routing, domain name servers and resolver, and more. The product set also includes a corresponding IBM PC software set (based upon the MIT PC/IP stuff). The announcement also includes a new DACU (Device Attached Channel Unit) which is now a fully supported product. Now if we could get Oracle or others to build a TCP/IP client/server set using SQL queries, we might be able to answer the initial question... -- Tom Putnam Assistant Director ARPANET: tmp@j.cc.Purdue.EDU Purdue University Computing Center BITNET: TMP@PURCCVM Mathematical Sciences Bldg. Phone: (317) 494-1787 West Lafayette, IN 47907
purdom@rabbit1.UUCP (Chris Purdom) (09/09/87)
In article <463@ambush.UUCP>, storm@ambush.UUCP (Kim F. Storm) writes: > > Which UNIX systems can talk to an IBM mainframe (besides providing > 'dumb' 3270 emulation on a UNIX terminal) ? Is there any other > way to do it (i.e. let a UNIX program emulate a 3270 terminal when > talking to the IBM system) ? Rabbit Software sells C source-code for 3270 SNA systems including Programmer Interface Modules. Executable versions are also available for a number of different Unix versions. -- Chris Purdom Frith-Inle Rabbit Software Corporation Great Valley Corporate Center Seven Great Valley Parkway East Malvern, Pennsylvania 19355 (215) 647-0440
bradbury@oracle.UUCP (Robert Bradbury) (09/10/87)
In article <14459@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > First, I should point out that I hold Oracle and the Three Initial Corporation > (RSI?) behind it in pretty low esteem. They're customer support is about the > worse I've seen, which is compounded by the preponderance of bugs in their > software. > Relational Software Incorporated (RSI) changed its name to Oracle Corporation about 4 years ago. (The other 3 initial corporations are/were Relational Technology Inc (RTI)/Ingres and Informix (RDS)) I would be interested in knowing whose customer support Ron is comparing us with. In the process of porting Oracle to a wide variety of machines I've dealt with customer support at Pyramid, AT&T, HP, Apollo and Amdahl. I would put HP at the top of the list and AT&T at the bottom. I base my impressions on two things: a) How responsive (caring) the support is and b) how good the answers/solutions are I get from them. HP rates high on both counts. AT&T used to have good support (for 3B20s) but in their efforts to be everything to everybody support seems to have suffered. I would say that Oracle is good on (a) and has some work to do on (b). Much of the problem at Oracle is that much of the support organization is very new. It is impossible to double the size of a company (and therefore the # of customers and # of customer support people) each year and expect the people at the interface points to be able to know all the answers. At best they can only be eager-to-please go-fors who try to get back to you with an answer until they have served as a pipe for enough information to know many of the answers. Even this may be insufficient as changes in the existing products and new products make keeping up with the flow of information a full time job. We have been through several cycles of centralized/decentralized support trying to find the best combination of keeping support people in the field (close to the customers) or at corporate headquarters (close to the answers). Ultimately the best support (for technical questions) is gotten when the person answering the phone is the developer (or sits next to him). Unfortunately if developers spend all day on the phone (or answering questions for support people) they don't get any development done. Where would we be today if Ken or Dennis or Bill had to support a customer base of several thousand people instead of just throwing the tapes over the fence? As far as bugs go, yes we have them. I think the bug database is assigning numbers in the 8000 range currently. Considering that is over a 5 year period involving several megabytes of code on 6+ major operating systems on dozens of different machines we are probably doing fairly well. I think bug database at Pyramid is in the thousands and the numbers they assign at AT&T range between 300,000 and 400,000 (I don't know when and how they started counting). I would be interested in hearing of other support experiences (good and bad) and especially how people think support should work given the problems of a fast development pace; a huge amount of information to be juggled (Oracle documentation occupies as much shelf space as a full set of UNIX documentation); and limited resources. -- Robert Bradbury Oracle Corporation (206) 364-1442 hplabs!oracle!bradbury
ron@topaz.rutgers.edu (Ron Natalie) (09/10/87)
I'll admit that it has been probably close to four or five years since I've had to work with Oracle. We had over 120 reported bugs and some were quite serious. Customer support was, as I said, underwhelming. I've seen companies turn around (notably places like Wollengong) in short periods of time than that, so I hope that the new "Oracle" company is much better. -Ron
bww@k.gp.cs.cmu.edu (Bradley White) (09/11/87)
In article <5242@j.cc.purdue.edu>, tmp@j.cc.purdue.edu (Tom Putnam) writes: > Now if we could get Oracle or others to build a TCP/IP client/server set > using SQL queries, we might be able to answer the initial question... The Scylla database project at CMU is working on just such an approach. So far we have taken Informix-SQL and split it into a client/server pair communicating via a UDP/IP remote procedure call mechanism. [Aside: For those familiar with the structure of Informix-SQL the current split is at the obvious place, but we plan to experiment with making the split at different levels.] The system is currently used to present uniform access to databases from the hundreds of workstations (Suns, Vaxen, and IBM-RT's) on the CMU campus. This work will be described in a forthcoming technical report. We also have the remote procedure call mechanism up and running on the IBM, so an obvious direction - and one we are currently planning to take - is to set up an SQL/DS server so that a UNIX workstation user can access the IBM databases just as if they were local Informix-SQL databases. -- Bradley White <bww@cs.cmu.edu> +1-412-268-3060 CMU Computer Science Department 40 26'33"N 79 56'48"W
bradbury@oracle.UUCP (Robert Bradbury) (09/12/87)
In article <14620@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > I'll admit that it has been probably close to four or five years since > I've had to work with Oracle. We had over 120 reported bugs and some > were quite serious. Customer support was, as I said, underwhelming. > I've seen companies turn around (notably places like Wollengong) in > short periods of time than that, so I hope that the new "Oracle" company > is much better. As always the "context" in which a statement is made is important. In 1982 Ron was probably dealing with the first release of Oracle for the VAX (or worse yet one of the early UNIX releases). The entire package had just been converted from PDP-11 assembler to C by some people who had never programmed in C before. Needless to say this resulted in more than a few problems. At that time the company was probably only about 30-40 people and finding one who could do customer support was hard. I would say at the current time there are between 50 and 100 people in the support organization alone. -- Robert Bradbury Oracle Corporation (206) 364-1442 hplabs!oracle!bradbury
DBLCU@CUNYVM.BITNET (09/28/87)
I do not know if this answer will solve your problem about sharing
data using a database system but...
At this installation we have a Unix system (att sys v rel 2 compatible)
which runs on IBM or Amdahl Mainframe hardware. Amdahl calls it UTS
and it may solve your problem. UTS supports 327x terminals and in fact
has a program which is similar to DMS on vm/cms that will allow a user
to create full screen templates for data acquisition. We have been
using this product for over a year now and it seems pretty good. It is
a REAL unix system (not like ibm's 370/ix product which pretends its
unix by utilizing xedit macros and such). You might try calling up
Amdahl to see if they have what you need. I don't have a number that
you can call up (sorry about that).
disclaimer: non of the above statements are the opinion of my employer
dave
bitnet address : dblcu@cunyvm.bitnet
rjh@ihlpa.ATT.COM (Herber) (09/30/87)
In article <733DBLCU@CUNYVM>, DBLCU@CUNYVM.BITNET writes: > At this installation we have a Unix system (att sys v rel 2 compatible) > which runs on IBM or Amdahl Mainframe hardware. Amdahl calls it UTS... . > We have been using this product for over a year now and it seems pretty good. > .... You might try calling up Amdahl to see if they have what you need. > I don't have a number that you can call up (sorry about that). > disclaimer: non of the above statements are the opinion of my employer > dave > bitnet address : dblcu@cunyvm.bitnet Try 1-800-538-8460, ask for Al Greene at extension 7536. Randolph J. Herber, Amdahl Sr Sys Eng, ..!ihnp4!ihlpa!rjh, (312) 979-6553, IH 6X213, AT&T Bell Labs, Naperville, IL 60566