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
| 
