>>> On 6/10/2009 at 4:49 PM, in message <[email protected]>, Dougie Lawson <[email protected]> wrote: > Quoting Frank Swarbrick <[email protected]>: > >> Such a useful tool >> would be a system level "JOBLIB" that would be searched by default if >> a module can not be located in a JCL level JOBLIB or STEPLIB. > > Don't use LINKLIST for user written problem state application programs. > Use LINKLIST for the stuff that MVS can't run without loading.
Sorry, I don't know what a "problem state application" is. > If you don't like coding JCL build one super ginormous member that has > everything and use // INCLUDE. Use symbolic variables in JCL with the // > SET statement to control stuff that gets // INCLLUDEd. That new stuff > has been in JCL for a long time, yet there's still an inertia when it > comes to application folks using nice "new" function. I have researched using // INCLUDE. Unfortunately it does not meet my needs. It is fine for production, but it falls short when it comes to my need to placing a "test" library at the head of the concatenation. Or am I misunderstanding what you are saying? Perhaps you can give me an example? I'm not trying to be stubborn. I would love to have a resolution that makes everyone happy! I for one love to take advantages of new features. Yes, there are some applications people who are resistant to change. But then again there are some systems folks who have the same problem. A "new" feature to IMS I fully intend to take advantage of is using AIBTDLI instead of CBLTDLI. It seems to solve an issue I had to work around in a very kludgy way in DL/I VSE. The ability to specify the *name* of a PCB instead of it's position will come in very handy in this particular situation. On the downside it requires a bit more coding (specifying the name of the PCB when previously that was not needed; specifying the length of the I/O area when previously that was not necessary, etc). So unless, as in my example about, AIBTDLI gives me additional functionality that I will actually *use* I can't see any reason to convert existing programs to use it, or even encourage it's use in general. One other thing that concerns me about AIBTDLI is I can't find any examples in the IMS documentation that actually use it. All of the examples still use the "old" interface. Documentation is good. Examples are better. (Well, not better; but both are often necessary since one is less likely to misinterpret an example than a verbal/textual description.) > That's going to keep the systems folks like me and Virgil happy and keep > the applications folks like you and countless others happy. It'll also > give you the scope to have nice //STEPLIB and //DFSRESLB DDs in your IMS > batch JCL. > > The other option is stop running DLI/DBB. Add an IO PCB (and code > CMPAT=YES for DLI/DBB) and CHKP/XRST calls so you can run as well > behaved BMPs. If you don't want to add symbolic checkpointing there are > OEM products that will do that for you with no application code changes. > > BMPs don't allocate the database datasets, that's done by the DLISAS. > They also don't spew 100s of logs that you have to manage that's done by > the IMS (possibly DBCTL) control region. I don't think this would work for us, especially not for update programs. We run many batch update programs during our nightly window, but we run them against an "offline" database. We don't update these changes to the online database until all batch processing is done. This is because we don't want a case where one account has been updated for the current day's processing while another account has not. This could be very confusing to customers. This seems to me to be a fairly obvious requirement, so it surprises me that it does not appear to be a prevalent one. I have the same concern about DB2 data. Though we actually did recently convert our safe deposit system to DB2 (from a vendor application that used VSAM), and we do in fact update it "online". As far as I know it has not been an issue. But then safe deposit is not really a transaction based account, so I think we felt pretty safe about doing it this way. If you (or anyone!) have a resolution to this issue (assuming I explained it well) I would love to hear it. Until then I think we are, for the most part, going to stay away from BMPs. Though we do have a few cases where we think they might be useful. These are cases where right now we have a "batch-like" CICS program which reads files and inserts segments into the online database. Doing this from a batch program instead would be very nice. Systems will like it because it will cut down on long running CICS tasks. I will say that as we convert all of our programs from VSE to z/OS I am considering having an I/O PCB inserted in to every DL/I program, and having CMPAT=YES specified for every PSB. This, as you know, allows one to run the same program both as a regular DLI/DBB or as a BMP. Very nice. One thing I do need to ask... Can a CICS PSB also have CMPAT=YES? We don't currently really distinguish between PSB's used by CICS and PSB's used in batch. I'm hoping I can just add CMPAT=YES to all of them without trying to figure out which PSB is used in which environment. I have not had time to test this yet, so if anyone knows the answer offhand I would be grateful. Thanks for your thoughts, Dougie. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- 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
