>I was thinking of CGIs. I was also thinking of the HTTPD server. We >don't have Websphere. Perhaps Websphere has things in it to make >developing CGI-like applications in COBOL easier. When we tried to do >CGI in COBOL a few years ago, it was very difficult due to not being >able to use "stdin" and "stdout" directly from COBOL code, using COBOL >verbs. I haven't looked at this since installing Enterprise COBOL, so >maybe it is easier now.
Ah. Well, J2EE is a complete replacement for CGI (and then some). There's something called JNI if you absolutely positively must make a native platform-specific call, but there are vanishingly few reasons to do that. CGI has fallen out of fashion (industry wide) for a variety of reasons. Aside: WebSphere Application Server for z/OS is unique in being able to run COBOL as EJBs (Enterprise Java Beans -- don't take the "Java" too literally here). The COBOL code appears as "Java" objects within the WebSphere runtime, interacting with ordinary EJBs. None of that is CGI, though, and it wouldn't require a C compiler. >Plus, I'm trying to get my C compiler back <grin>. Not likely as I'm the >only C literate person here on the z/OS side. The Windows side might >have some C people. Although from what I know of them, they are all >VB.Net people now. OK. Well, in that case, you should probably go into the z/OS Web Services business. Make everything (or at least almost everything) accessible as VB.Net-friendly Web Services. "Update account" a Web Service. "Query account(s)" a Web Service. Everything you possibly can, starting with the important ones (from an application perspective). Then you're relevant -- you have a directory (yes, directory) of oh-so-easy to use services that VB.Net developers can just grab-and-go. (It's also pretty easy to do in many different ways.) VB.Net really doesn't know much about anything else -- including core business function -- unless it looks like a database (ODBC) or a Web Service (SOAP/WSDL). (Yes, it's that stupid. :-)) If all the valuable stuff (i.e. your mainframe apps) doesn't look like either one (especially SOAP/WSDL) then, of course, that mainframe stuff will be everything you mentioned. It'll be like an interstate highway with no on-ramps. Now I can't think of anything more proprietary than VB.Net, and even Microsoft isn't sure what to do with legacy VB. (Q: How do you bring classic VB to the Web? A: With major difficulty.) But the beauty of Web Services is that when your company changes its mind about its primary development environment you're still in very good shape because you've abstracted your core business functions into reusable, language-neutral Web Services. In fact, the more rewriting of existing code you do in VB.Net -- without abstracting as services -- the worse off your company will be in the future. Another aside: I'll let you in on a little secret. IBM treasures its ~300 MIPS customers -- a brand new z890 starts at 26 MIPS, after all -- but, just as with its ~30,000 MIPS customers, it doesn't work if everything is frozen at circa 1976. It's a mixed workload platform with significant economies of scale, and that means it should run code you wrote 30 years ago alongside code you wrote 5 minutes ago. What IBM is saying is pretty simple, actually: put something "new," anything "new," on your mainframe and you will enjoy the best cost-of-ownership (and qualities of service) any IT money can buy. Making your VB.Net programmers more productive (and more architecturally sensible) could be your "new." Probably no surprise (or secret), actually, come to think of it. But hope it helps someone. What you're probably not going to win is the argument about "primary" development platform. Sounds like it's VB.Net in your shop. A VB.Net developer is going to take a dim view of someone arguing that *their* next line of code ought to be written in COBOL or C on z/OS. It's like asking someone to change their brand of cola. But Web Services -- well, that's a different story. Now you're actually making their job easier and simpler because they don't have to figure out how to write thousands of lines of code to recreate that accounting system you already have (for example). If they could only plagarize that business function from the comfort and convenience of the only development environment they know in the ways they're used to working.... Oh, one more thing. Ask for help. Go to your friendly IBM rep and say, "Let's find out more about a zIAW." (That stands for zSeries Integration Architecture Workshop, also known as a SOA Workshop.) Your friendly IBM rep will go to w3.ibm.com/search and figure out what you mean, then they'll understand. See if it makes sense to have a workshop at your company. As it happens the workshop doesn't cost anything except a couple days' time. Good luck! (Or is it "Lose a bit"? :-)) - - - - - Timothy F. Sipples Consulting Enterprise Software Architect IBM Americas zSeries/z9 Software Phone: +1 312 529 1612 E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
