LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (June 2000)Back to main CICS-L pageJoin or leave CICS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Wed, 7 Jun 2000 22:45:18 -0700
Reply-To:     CICS List <CICS-L@LISTSERV.UGA.EDU>
Sender:       CICS List <CICS-L@LISTSERV.UGA.EDU>
From:         Bob Halpern <Bob@CPUPERFORM.COM>
Organization: CPU http://www.CPUperform.com
Subject:      Re: Copy Books with EXEC CICS Commands
Content-Type: text/plain; charset=us-ascii

This topic has come up a lot. Would there be interest in an inexpesive product to provide this facility? This might be something I would think of doing. Basically, all the user would have to do is provide DD cards for libraries to be processed.

Timothy Fansler wrote: > > Hi Bob, > > I listened, but since your reply was only 18 words long it wasn't at all clear to me > how this approach would work. Now I have a better idea of what you were thinking. > Thanks for elaborating, and please accept my apologies. Sometimes - no, many times I > think email stinks as a means of communication because it's too easy to infer vocal > inflections that were never intended. > > Now, another question... I still don't understand why you would want to take this > approach. What are the advantages? Let me explain where I'm coming from. We have 100+ > application programmers, 100+ CICS regions, and only 5 systems programmers to support > all of that - and that includes everything, not just CICS. In these circumstances > there's no way we would want to take on the responsibility of developing/maintaining > a mechanism of expanding copy books into program source prior to execution of the > translator when there's already an IBM-supplied utility that would do the same thing. > The only thing that's required to use it is an additional jobstep in a cataloged > procedure. Why reinvent the wheel? If there's a problem with the IBM utility then > they need to fix it ASAP, and you have leverage because you're paying them money for > support; if you're using a home-grown process and it breaks, then it's your problem > and you have to fix it ASAP, which takes time away from your own projects, and > jeopardizes your own deadlines. > > I can see now how it's possible, but I still don't understand why you would want to > do it. > > Tim Fansler > > Bob Halpern wrote: > > > Seems nobody listened. What you do is set up a single assembler program > > as a user mod. Using SMP exits catch the changes to db2 interface > > (exec sql) and drive the single assembler program. Once the smp has > > completed normally, you release the assembler job. It invokes the > > processes needed. One would assume that all the source code is in some > > set of pds libraries that can be processed by the assembler code. It would > > need, for example, a set of dd cards named //INP00001, //INP00002, etc. > > If the input was a dataset name the code can work its way through all the > > members. If the input was a sysin, read it to get the member list. > > > > I have had such a program (long, long ago) to work its way through a > > pds. Was a couple of days code writing and testing. > > > > The CICS api, while extending, does not change (only once did they change > > it, and then had to do it twice to correct the correction - had to do > > with file open states and was back around 1980). Only new api calls are > > added, so mass recompile should never be needed. > > > > Even the entry to cics, DFHAICB TYPE=LOCATE, will work with the old > > version (cics 2.x) which went via the tcb double word, vs the new > > way which uses psatold. Saves a couple of instructions and a page > > reference. > > > > Timothy Fansler wrote: > > > > > > Bruce Baxter wrote: > > > > > > > Please pardon my attitude here, but WHY would you even want to consider > > > > this? With SMP being akin to voodoo to so many people (including many > > > > SYSPROGS) why would you want to unleash it upon mere application > > > > programmers? > > > > > > Not to mention the fact that we have literally thousands of them (copybooks, > > > that is). Who has the time, even if they have the desire and expertise, to > > > create that many usermods when it can be accomplished very simply with JCL > > > executing an IBM-supplied ISPF utility program? And how would programmers make > > > changes to all those usermods when doing maintenance? Would you have to restore > > > them, reject them, rework them, re-receive them and reapply them? And what if > > > they then failed in testing because of logic errors? Wouldn't you then have to > > > go through the same restore, reject, rework, receive, apply cycle again? Please > > > pass the aspiring.... This is overkill, and I'm getting a headache... 8-) > > > > > > Tim Fansler > > > > > > > > > > > > > > > |--------+-----------------------> > > > > | | Bob Halpern | > > > > | | <Bob@CPUPERFO| > > > > | | RM.COM> | > > > > | | | > > > > | | 06/05/00 | > > > > | | 07:03 PM | > > > > | | Please | > > > > | | respond to | > > > > | | CICS List | > > > > | | | > > > > |--------+-----------------------> > > > > >-------------------------------------------------------------------| > > > > | | > > > > | To: CICS-L@LISTSERV.UGA.EDU | > > > > | cc: (bcc: Bruce Baxter/ISM/NYSTAX) | > > > > | Subject: Re: Copy Books with EXEC CICS Commands | > > > > >-------------------------------------------------------------------| > > > > > > > > How about setting up all your exec books as user mods and driving an > > > > update/retranslate from smp? > > > > > > > > Timothy Fansler wrote: > > > > > > > > > > "Richardson, Gerry" wrote: > > > > > > > > > > > Another solution is to use some process ( such as a REXX exec ) to copy > > > > the > > > > > > CICS commands into the source prior to translation. It seems that IBM > > > > has > > > > > > warned against keeping translated commands in copy members for > > > > computability > > > > > > reasons. > > > > > > > > > > Ageed... learned this lesson the hard way. We ran into problems when > > > > > implementing the COBOL3 translator parm in place of COBOL2. > > > > Pre-translated COBOL > > > > > Procedure Division copybooks which had been created using the COBOL2 > > > > translator > > > > > parm caused compile errors because of undefined WORKING-STORAGE > > > > variables, which > > > > > are inserted by the translator. COBOL2 and COBOL3 are incompatible, > > > > because the > > > > > WS variables generated by the translator are not the same for both > > > > parameters. > > > > > We had to replace all pre-translated copybooks with the original > > > > untranslated > > > > > source to get around this incompatibility. > > > > > > > > > > I believe there is an ISPF exit/utility program that you can use to > > > > expand all > > > > > copybooks into the source code before it is input into the translator > > > > step. I > > > > > don't recall what its name is. You should be able to find it in the > > > > CICS-L > > > > > archives, or maybe some kind soul who remembers what it is will remind us > > > > all > > > > > one more time. > > > > > > > > > > Our change management software (Changeman) has a program that does the > > > > same > > > > > thing. > > > > > > > > > > Tim Fansler > > > > > > > > > > > > > > > > > > > > > > > Gerald D. Richardson > > > > > > Charles Schwab & Co., Inc. > > > > > > Technical Director > > > > > > Schwab Technology-STAMP > > > > > > 211 Main Street 16-145 > > > > > > San Francisco, CA 94105 > > > > > > (415) 667-0941 > > > > > > (877) 658-8356 (Pager) > > > > > > (415) 667-9060 (FAX) > > > > > > Gerry.Richardson@Schwab.com > > > > > > > > > > > > WARNING: All e-mail sent to this address will be received by the > > > > Charles > > > > > > Schwab & Co., Inc. corporate e-mail system and is subject to archival > > > > > > and review by someone other than the recipient. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Larry.A.Gray@LOWES.COM [mailto:Larry.A.Gray@LOWES.COM] > > > > > > Sent: Monday, June 05, 2000 10:04 AM > > > > > > To: CICS-L@LISTSERV.UGA.EDU > > > > > > Subject: Re: Copy Books with EXEC CICS Commands > > > > > > > > > > > > The CICS translator at present does not resolve copy statements. If > > > > you > > > > > > want EXEC CICS statements in copybooks, you must translate them and put > > > > the > > > > > > translated statements in the copybook for the COBOL compiler to > > > > resolve. If > > > > > > you look at the CICS-L archives on this subject, you will find an > > > > extensive > > > > > > discussion of this problem. > > > > > > > > > > > > Larry Alan Gray Phone: 336-658-7944 > > > > > > Technical Support Fax: 336-658-2124 > > > > > > Lowe's Companies Inc. Email: Larry.A.Gray@lowes.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: MIKE HUNLEY [SMTP:MHUNLEY@USAGROUP.COM] > > > > > > > Sent: Monday, June 05, 2000 12:56 PM > > > > > > > To: CICS-L@LISTSERV.UGA.EDU > > > > > > > Subject: Copy Books with EXEC CICS Commands > > > > > > > > > > > > > > I have a question... > > > > > > > > > > > > > > We have a concern regarding the use of nested copy statements for > > > > linkage > > > > > > > section and procedure division code. > > > > > > > Can I use a copy or nested copy for any procedure division code which > > > > > > > contains EXEC CICS statements? Can I use a copy or nested copy in > > > > the > > > > > > > linkage section of a CICS program? Where does the copy statement > > > > get > > > > > > > resolved by the CICS translator or by the COBOL compiler? > > > > > > > > > > > > > > How do other shops handle this problem ? > > > > > > > > > > > > > > Thanks, Mike


Back to: Top of message | Previous page | Main CICS-L page