IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

STOP a Transaction


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
meltingmemories

New User


Joined: 13 Oct 2008
Posts: 16
Location: Bangalore

PostPosted: Mon Dec 08, 2008 7:27 pm
Reply with quote

I have a requirment such that if my cobol program gets any error during its processing I had to stop a transaction. Can any one please help me out.
Back to top
View user's profile Send private message
Srihari Gonugunta

Active User


Joined: 14 Sep 2007
Posts: 295
Location: Singapore

PostPosted: Mon Dec 08, 2008 8:09 pm
Reply with quote

Meenakshi,
You can use the following link.

www.ibmmainframes.com/viewtopic.php?t=13853&highlight=purge

Thanks,
Sri Hari G.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Mon Dec 08, 2008 10:44 pm
Reply with quote

Hello,

When this program "gets an error" do you simply want that program to terminate or do you want someone/something to force termination externally?

If you better define what is happening and how you want the system to react, we can offer better suggestions.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 1:00 pm
Reply with quote

Hoping its okay to repoen the thread... icon_smile.gif

Hi All,


I am having a requirement similiar to what the owner has posted.

I would like to stop the execution of the program completely, say if one of the conditions are met.... something like what STOP RUN does in batch programs. The program could be either a main program ( Level 0 ) or subroutines ( subsequent level - program LINK ed )...

I have been thinking of CICS ABEND NODUMP command but I guess it will still update the Log as it considers it to be a ABEND.

Please advice...
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 1:13 pm
Reply with quote

that' s just an issue of proper program design,
it should have been taken care of a long time ago,
when making the design and setting the coding standards,
usually one of the basics, very basic rules was ( looks not so any longer )
every called program must return a return code,
the calling program must test it and act accordingly
along the lines
4 - warning / ask the user to proceed or not
8 - error / leave immediately

if the issues raises at a later point in the development stages ,
well.... bad standards, bad requirements, bad too many other things

if on the other side the question is...
in case of a malfunction how to disable the program and the transaction,
then the only way is to abend and customze the PEP to take care of it
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 1:28 pm
Reply with quote

Hi Enrico,

Thanks for the reply... icon_smile.gif

Quote:
usually one of the basics, very basic rules was ( looks not so any longer )
every called program must return a return code,
most of the programs in the system is using the concept of return code.

I guess i need to give in some more details... icon_smile.gif .. currently the program is in Assembler.. and using ALCS. My "work" is to migrate from the same Assembler code in ALCS to Assembler in CICS.... In ALCS there is a macro, EXITC, which stops the transaction without any further processing. I am trying to simulate the same using a CICS statement.

As mentioned, I would like to stay away from the CICS ABEND option. But if that's the only way then i will use it... icon_cry.gif
Back to top
View user's profile Send private message
Srihari Gonugunta

Active User


Joined: 14 Sep 2007
Posts: 295
Location: Singapore

PostPosted: Fri Sep 04, 2009 1:32 pm
Reply with quote

Binop,
If you don't want to abend, you can XCTL to a subprogram which just does a RETURN.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 1:38 pm
Reply with quote

Hi Srihari,

Thanks for the response... icon_smile.gif

If my understanding is correct, RETURN statement will return control to the program in the higher level. If the program is at level 0, RETURN statement would work as per the requirement.

But if the program is at lower levels, RETURN will pass the control back to the calling program and continue execution... ( which is not what is required... icon_cry.gif )
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 1:38 pm
Reply with quote

Assembler code in ALCS
Assembler is ALCS ( obsolete term but still undersood by somebody )
it would be strange to write assember code in COBOL icon_biggrin.gif

look at the macro and determine its behavior...
but ....
for a cics program properly written the alternatives are ...
EXEC CICS RETURN managing properly the return code or
EXEC CICS ABEND

what would be wrong in managing the return codes ?
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 1:40 pm
Reply with quote

Quote:
if you don't want to abend, you can XCTL to a subprogram which just does a RETURN.


what would be different from RETURNING inline ?
Back to top
View user's profile Send private message
Srihari Gonugunta

Active User


Joined: 14 Sep 2007
Posts: 295
Location: Singapore

PostPosted: Fri Sep 04, 2009 1:42 pm
Reply with quote

In case if Binop wants to stop the transaction processing from a LINKed program, it would take him to the prior level. I think this is not what Binop is looking for.
Back to top
View user's profile Send private message
Srihari Gonugunta

Active User


Joined: 14 Sep 2007
Posts: 295
Location: Singapore

PostPosted: Fri Sep 04, 2009 1:43 pm
Reply with quote

Binop,

Thats why I am asking you to return from a XCTL'ed subprogram. This will safely return to CICS. No complications I believe.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 1:44 pm
Reply with quote

review Your understanging of LINK and XCTL

LINK nests down one revel
XCTL stays at the same level,

what counts is the nest level not how You got there

so link + xtcl the level does not change icon_biggrin.gif
Back to top
View user's profile Send private message
Srihari Gonugunta

Active User


Joined: 14 Sep 2007
Posts: 295
Location: Singapore

PostPosted: Fri Sep 04, 2009 1:53 pm
Reply with quote

Ok Enrico. I am not really worried about at what level I am in the hierarchy. I just wanted to return the control to CICS

From the XCTL'ed program if you issue
EXEC CICS RETURN END-EXEC

Is it going to take you back to the previous called program or CICS?
I believe its CICS. If I am wrong, I seriously need to review my basics.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 2:26 pm
Reply with quote

Hi,

Quote:
Enrico...
Assembler is ALCS ( obsolete term but still undersood by somebody )
it would be strange to write assember code in COBOL

ALCS, on a very high level, can be considered to a previous version of CICS. Its also an online and since it has macros, i guess its only compatible with Assembler.

Quote:
Enrico...
what would be wrong in managing the return codes ?

Yes Enrico.. this is the best way... but as far as my scope goes, no functional/processing change should be done until really necessary. So that's why I am trying to find a one to one replacement for the EXITC macro mentioned before.

Quote:
Srihari...
Is it going to take you back to the previous called program or CICS?
I believe its CICS. If I am wrong, I seriously need to review my basics.
I guess it is going to return the control back to the calling program... If its not, then its time for me to go back to basics... icon_biggrin.gif
Back to top
View user's profile Send private message
Srihari Gonugunta

Active User


Joined: 14 Sep 2007
Posts: 295
Location: Singapore

PostPosted: Fri Sep 04, 2009 2:35 pm
Reply with quote

Binop,
This can be useful for both of us.

publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dfhwp405/1.261?ACTION=MATCHES&REQUEST=XCTL&TYPE=FUZZY&SHELF=dfhwsh0p&DT=20060119100347&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT


XCTL transfers control from one application program to another at the same logical level. The program from which control is transferred is released. If the program to which control is transferred is not already in main storage, it is loaded.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 2:50 pm
Reply with quote

Hi Srihari,

Thanks for the info...

But i thought we had a small disagreement on what happens when we issue a RETURN statement from the XCTL'ed program... not the XCTL concept as such... icon_razz.gif
Back to top
View user's profile Send private message
Srihari Gonugunta

Active User


Joined: 14 Sep 2007
Posts: 295
Location: Singapore

PostPosted: Fri Sep 04, 2009 3:33 pm
Reply with quote

Enrico & Binop,
Sorry for the confusion I created.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 3:55 pm
Reply with quote

Hi,

Quote:
Sorry for the confusion I created.

its always nice to have a good discussion... icon_wink.gif ..

so coming back to the requirement... icon_razz.gif ... any advice...
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 4:03 pm
Reply with quote

Quote:
ALCS
if You mean Airline control system ...
You should have specified that in the OP not to confuse people icon_evil.gif

Quote:
I guess it is going to return the control back to the calling program... If its not, then its time for me to go back to basics...

yep icon_biggrin.gif

there are 3 things to take into account
caller callee/called level

the basic concept is as I already told ....
an EXEC CICS RETURN goes always up one level of the nesting hierarchy

CICS when starts the execution of the <main> program logically LINKS ( the internals are a bit different, but that is the concept)

a < RETURN > goes back to .... CICS

if the <main> XCTLS to some other program the level does not change,
so a < RETURN >, guess what icon_biggrin.gif, goes back to CICS

if any program LINKS the linked program is one level lower ,
so a < RETURN > goes up one level ... to the LINKING PROGRAM

same logic as plain OPSYS XCTL, LINK

also when a program XCTLS it' s use count is decremented, and the program itself might be <released/freed/unloaded>
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 4:11 pm
Reply with quote

enrico-sorichetti wrote:
Quote:
ALCS
if You mean Airline control system ...
You should have specified that in the OP not to confuse people icon_evil.gif


icon_redface.gif .. i thought ALCS was the short for Airline Control System like CICS for Customer Information Control System...
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 4:12 pm
Reply with quote

Quote:
But i thought we had a small disagreement on what happens when we issue a RETURN statement from the XCTL'ed program... not the XCTL concept as such


if You had had clear the concept of XCTL there would not have ben any disagreement icon_biggrin.gif

Quote:
XCTL transfers control from one application program to another at the same logical level. The program from which control is transferred is released. If the program to which control is transferred is not already in main storage, it is loaded.
Quote:
LINK passes control from an application program at one logical level to an application program at the next lower logical level. If the requested program is not defined to CICS, and AUTOINSTALL is active, CICS supplies a definition for the program. If it is not a remote program in another CICS region, and the linked-to program is not already in main storage, CICS loads it. If the SYSID option specifies the name of a remote CICS region, CICS ships the link request to the remote region. When the RETURN command is executed in the linked-to program, control is returned to the program initiating the link at the next sequential executable instruction.
Quote:
RETURN returns control from an application program either to an application program at the next higher logical level, or to CICS.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 4:29 pm
Reply with quote

Quote:
ALCS, on a very high level, can be considered to a previous version of CICS.

bullshit icon_biggrin.gif

search and read the IBM documents about
ACP,
en.wikipedia.org/wiki/IBM_Airline_Control_Program

ACP/TPF
a bit murky as far as docs are concerned

TPF
en.wikipedia.org/wiki/Transaction_Processing_Facility

zTPF
www-01.ibm.com/software/htp/tpf/index.html
publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp

for a literate treatmnt
www.ibmsystemsmag.com/mainframe/enewsletterexclusive/10019p1.aspx

ALCS
www-01.ibm.com/software/htp/tpf/alcs/
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Fri Sep 04, 2009 4:42 pm
Reply with quote

enrico-sorichetti wrote:
Quote:
ALCS, on a very high level, can be considered to a previous version of CICS.

bullshit icon_biggrin.gif


icon_razz.gif .. yup .. for someone who knows about ALCS.. the definition I gave is nonsense... for a moment i thought ALCS was a completely unknown factor ( thought streghthened by the fact that I could find only 1 or 2 topics regarding ALCS in the forum ).

When i said that "ALCS, on a very high level, can be considered to a previous version of CICS."... just to give a basic understanding its an online system with some features but not as much as CICS. Sorry for the confusion.. icon_redface.gif
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10888
Location: italy

PostPosted: Fri Sep 04, 2009 4:42 pm
Reply with quote

t
Quote:
hought ALCS was the short for Airline Control System


yes it is but not very common knowledge,
after Your hints was easy to understand the environment

ALCS used also to mean Assembler Language Code Support
ALC Assembler Language Code

anyway ...
ALCS/TPF/zTPF Assembler language even if compatible to some extent with the HLASM family running on zOS

provides additional facilities and macros for services not available on HLASM and zOS and related products

the macro You quoted, certanily belongs to that family,
the TPF family was designed to handle thousandths of transaction per second

Quote:
z/TPF’s largest customers are able to achieve throughput exceeding 1.4M I/O operations per second (IO/s) and transaction rates well over 25K tps


so it was reasonable to provide a quick exit to TPF itself from any level of the programming hierarchy, not so for CICS and IMS

also ACP/TPF/zTPF were/are operating systems themselves not applications running under an operating system

www-01.ibm.com/software/htp/tpf/pres/TPF_Performance_Whitepaper_rel1.pdf
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS Goto page 1, 2  Next

 


Similar Topics
Topic Forum Replies
No new posts Associating a USERID with a CICS-Libe... CICS 0
No new posts Help needed in automation cics transa... CLIST & REXX 1
No new posts How to identify the transaction categ... IMS DB/DC 3
No new posts Start CICS transaction every day at 2AM CICS 4
No new posts TWA size of the CPLT transaction CICS 0
Search our Forums:

Back to Top