My mention of being a new z/OS with IMS shop got a few surprised replies, so I thought I'd give a bit more information...
We have been a VSE (DOS) shop since at least 1979. (Not sure what we did before that, but I was only in elementary school at the time...) The vendor for a major business application that we use announced that they were dropping support for VSE. (CheckFree's PEP+ is the application, by the way: http://www.checkfreesoftware.com/cda/software/L5.jsp? layoutId=42417&contentId=62072&menuId=60524&pId=60524) We couldn't find an alternative on VSE and nothing in the "open systems" world met our requirements. So we ended up buying z/OS just for this one application. Currently we are *considering* moving everything to z/OS. It is by no means a done deal. But I am tasked with seeing what it will take to move our Cobol jobs (batch and CICS) to z/OS. We are a DL/I VSE shop. Thus we need to have IMS/DB on z/OS. We also are just starting using DB2. Interestingly, we decided not to host our DB2 database on VSE. DB2 for VSE is *way* back-leveled (feature-wise) when compared to z/OS, Linux/UNIX/Windows, and System i. So we ended up getting DB2 9.5 for Linux, UNIX and Windows, and we host it on an IFL on our mainframe. We use "DB2 Server for VSE Client Edition" to access the server from VSE batch and CICS programs. So that's who we are. Just recently we were notified by Visa Inc. that we are the last VSE shop in the U.S. that runs their "Visa Edit Package" product and they are dropping support. Luckally it's a pretty small and standalone product, and we have z/OS already, so moving it to z/OS should be fairly simple. z/OS certainly does have many nice things about it. But I am also running it to several "gotcha" type things. The lack of the JCL DATE card that I posted about previously is one of them. Since I'm already typing I may as well detail those places where I find VSE to be better, at least as far as I can tell so far. 1) Symbolic parameter support is better on VSE. In VSE you can set a parm and then programatically query it. In z/OS the parms are resolved to their actual values during JCL resolution (or whatever it's called) so it doesn't even really exist at the time the program executes. Or something like that. Having something similar in z/OS could also possibly solve my DATE card issue. Specifically, something like this: // SET DATE=20081001 //STEP01 EXEC PGM=PGM1 //STEP02 EXEC PGM=PGM2 // In VSE PGM1 and PGM2 can use a VSE macro to query the value of the DATE symbolic parameter. And yes, I do realize that you can do something like the following: // SET DATE=20081001 //STEP01 EXEC PGM=PGM1,PARM=&DATE //STEP02 EXEC PGM=PGM2,PARM=&DATE // The problem with this is that it will not work for IMS batch, since the program that is executed is the IMS driver program, DFSRRC00. The parm date is not passed to the Cobol program that the IMS program executes. 2) z/OS's conditional processing (whether using the COND clause on the EXEC statement or using IF/ELSE/ENDIF) can only check the results of jobs (return code, did it abend, did it run at all?). You can't check the value of a symbolic parameter (I'm guessing since, as I stated above, the symbolic parm has already been resolved and doesn't really exist as a parm by then). 3) No JCL GOTO! In VSE its nice to have a job that has many steps, each starting with a label ('/. label') and ending with a GOTO $EOJ. Then you can just change a GOTO at the top to execute just the step you are interested in. More for user level jobs rather than production jobs, but still nice. 4) I'm iffy about the lack of "system standard labels" and "partition standard labels". In some ways I like that the DD statements for all files are required explicitly. That way you can easily tell what files a job uses. Then again, for some very commonly used files it might be nice to have system standard DD names. Anyway, I'll probably be posting many questions from this point forward. Many will sound like complaints, but I'm just looking for the best information. Hope no one takes it personally! I guess I may as well get in to our RDBMS issue... As I said above, we are only this year starting to use DB2. For the last ten years or so our distributed platforms (Java J2EE and Windows) have used Oracle (and occasionally MS SQL Server, but only for vendor applications) for their data. We have developed some web-services stuff for them to be able to access mainframe data. Going the other direction there is, with only a single exception, no real time access of their data from our mainframe applications. (The single exception uses the VSE "VSAM Redirector" to access an Oracle table using VSAM calls. It works, but it's not something we want to rely on for more important data. And in any case, I don't think z/OS has an equivalent.) We decided to get DB2 so we could have a database that can be shared real- time between all of our platforms, including the mainframe. It's worked fine so far, though we only have a few small things using it. What we still do not have, though, is access from the mainframe to the Oracle databases. We do know about the IBM Federated Server product which would allow us to access Oracle from a DB2 DRDA client. We may end up doing this. Obviously we'll need to get DB2 on z/OS. Unfortunately IBM does not offer on z/OS a "client only" product. On VSE the DRDA client application requestor code has no direct dependancy on the DB2/VSE Server product (even though it has Server in the name!). On z/OS, however, this is not the case. So we seem to be heading toward needing to purchase the entire DB2 for z/OS product, even if we do not actually host any databases on z/OS! Suffice it to say we are not thrilled about that. To be honest, ideally we would buy the Oracle client for z/OS (which, again, does not require the server part on z/OS). In this case we would use Oracle exclusively (no DB2). But as you may know, Oracle has "stabilized" their support of z/OS at Oracle 10.2g. Being back-leveled to much on VSE we have no desire to run in to the same problem with Oracle. Thus, we're back to DB2 on z/OS. One crazy thought I had the other day is, could we convince IBM to port the DB2 Unix client code to run under z/OS Unix System Services? That would be the absolute ideal for us (as long was we could access it from regular MVS batch jobs)! But I have a hard time imaging that IBM would take that request seriously unless there were a lot of other possible customers. OK, I'm done now. Congratulations if you made it this far! Frank -- Frank Swarbrick Senior Systems Analyst - Mainframe Applications FirstBank Data Corporation Lakewood, CO USA ---------------------------------------------------------------------- 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
