View previous topic :: View next topic
|
Author |
Message |
meltingmemories
New User
Joined: 13 Oct 2008 Posts: 16 Location: Bangalore
|
|
|
|
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 |
|
|
Srihari Gonugunta
Active User
Joined: 14 Sep 2007 Posts: 295 Location: Singapore
|
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
Hoping its okay to repoen the thread...
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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
Hi Enrico,
Thanks for the reply...
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... .. 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... |
|
Back to top |
|
|
Srihari Gonugunta
Active User
Joined: 14 Sep 2007 Posts: 295 Location: Singapore
|
|
|
|
Binop,
If you don't want to abend, you can XCTL to a subprogram which just does a RETURN. |
|
Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
Hi Srihari,
Thanks for the response...
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... ) |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
Assembler code in ALCS
Assembler is ALCS ( obsolete term but still undersood by somebody )
it would be strange to write assember code in COBOL
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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
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 |
|
|
Srihari Gonugunta
Active User
Joined: 14 Sep 2007 Posts: 295 Location: Singapore
|
|
|
|
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 |
|
|
Srihari Gonugunta
Active User
Joined: 14 Sep 2007 Posts: 295 Location: Singapore
|
|
|
|
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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
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 |
|
Back to top |
|
|
Srihari Gonugunta
Active User
Joined: 14 Sep 2007 Posts: 295 Location: Singapore
|
|
|
|
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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
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... |
|
Back to top |
|
|
Srihari Gonugunta
Active User
Joined: 14 Sep 2007 Posts: 295 Location: Singapore
|
|
Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
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... |
|
Back to top |
|
|
Srihari Gonugunta
Active User
Joined: 14 Sep 2007 Posts: 295 Location: Singapore
|
|
|
|
Enrico & Binop,
Sorry for the confusion I created. |
|
Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
Hi,
Quote: |
Sorry for the confusion I created. |
its always nice to have a good discussion... ..
so coming back to the requirement... ... any advice... |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
if You mean Airline control system ...
You should have specified that in the OP not to confuse people
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
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 , 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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
enrico-sorichetti wrote: |
if You mean Airline control system ...
You should have specified that in the OP not to confuse people
|
.. i thought ALCS was the short for Airline Control System like CICS for Customer Information Control System... |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
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
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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
|
|
|
|
enrico-sorichetti wrote: |
Quote: |
ALCS, on a very high level, can be considered to a previous version of CICS. |
bullshit
|
.. 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.. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10888 Location: italy
|
|
|
|
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 |
|
|
|