I came across a piece of cobol program which got me confused, this is the page containing the code, it try to demonstrate how bad ALTER is but at the same I don't understand the program flow.
PERFORM 2100-PROCESS-RECORD THRU 2199-EXIT.
...
2100-PROCESS-RECORD.
GO TO 2110-PROCESS-HEADER.
*
2110-PROCESS-HEADER.
* code to process a file header
ALTER 2100-PROCESS-RECORD TO 2120-PROCESS-DETAIL.
GO TO 2199-EXIT.
*
2120-PROCESS-DETAIL.
* code to process a detail record
GO TO 2199-EXIT.
...
*
2199-EXIT.
EXIT.
In my mind, the flow is like this:
PERFORM 2100-PROCESS-RECORD THRU 2199-EXIT.
...
2100-PROCESS-RECORD.
GO TO 2110-PROCESS-HEADER.
*
2110-PROCESS-HEADER.
* code to process a file header
ALTER 2100-PROCESS-RECORD TO 2120-PROCESS-DETAIL.
GO TO 2199-EXIT.
2199-EXIT.
EXIT.
If ALTER is to change the destination of a GO-TO, how can it be useful if the GO-TO was already executed and the program exited?
http://home.swbell.net/mck9/cobol/style/alter.html explains it. you're correct for the first execution, but on subsequent runs the behavior is changed:
"The first time we execute the PERFORM, control passes through 2110-PROCESS-HEADER. However, the ALTER at the end of that paragraph changes the destination of the GO TO in 2100-PROCESS-RECORD. As a result, on all subsequent executions of the PERFORM, control does not pass through 2110-PROCESS-HEADER. It passes through 2120-PROCESS-DETAIL instead.
"The potential for confusion is obvious. The altered GO TO does not go where it claims to go -- instead, it goes to a place specified in some remote piece of code. To understand how the code works you need to know that the ALTER is present, and you need to know all the circumstances which execute the ALTER."
it's called self-modifying code, and it's very hard to understand and debug. for some light reading before bed, I recommend http://www.pbm.com/~lindahl/mel.html the story of Mel.
in Cobol, the EXIT statement does not mean "exit the program": http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/com.ibm.etools.iseries.langref.doc/evfeb4ls124.htm
Related
I have encountered an issue recently while processing a CICS transaction. My CICS transaction is calling a chain of dynamically linked COBOL modules. The transaction runs fine for the first time after the PGM-A load is new copied into the region. When I try to process the transaction for the second time, I keep getting CEE3DD abend saying the module not found for PGM-B which is being called from PGM-A. IF I do a new copy for PGM-A in CICS, the transaction again runs fine.
Something is wrong with the CICS setup or memory but I am not able to figure it out. PGM-A is working fine in batch processing. PGM-B has no issues when it is called from any other PGMs except PGM-A.
Can someone share some thoughts on what may be wrong with this?
To invoke your program via CICS, it must be compiled with the NODYNAM option.
It admittedly seems counter-intuitive, but using the DYNAM option will cause CICS stubs to be loaded, instead of your intended programs, and result in the CEE3501S condition.
So, compile your programs with the NODYNAM option to avoid this error condition.
See the following links for additional info:
https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.3.0/com.ibm.cics.ts.applicationprogramming.doc/topics/dfhp3_cobol_subprog_rules.html
http://www-01.ibm.com/support/docview.wss?uid=swg21054079
Does PGM-A use "CALL VARIABLE" to invoke PGM-B? If so check the contents of VARIABLE on the second run (the contents of that variable will probably be reported in the error message. The contents of the variable may be overwritten by a bug in PGM-A. That might explain why the program always fails after the (seemingly) succesful run and after a newcopy.
Converting this from dynamic to static worked. But the question remains why it was not working with dynamic linking.
I use Xcode7 to debug a App.
Seems step into behave like the step over, can't jump into the execution of a sub procedure? It's just jump to the next line in the source code each time.
And if I'm debug in the UIKit method(I don't have source code), it's jump to the next instruction.
As you have found, step-in avoids frames with no debug information. Most people like to just hit one step command, rather than switching between step & next depending on the line they are on, and in my experience, tend to choose step. This is made more pleasant if the debugger doesn't stop in printf & other code you have no debug info for.
However, lldb's "step" command has an option to control this:
-a <boolean> ( --step-in-avoids-no-debug <boolean> )
A boolean value that sets whether stepping into functions will step over functions with no debug information.
If you use this frequently, you can either reset the step alias to include this option, or make another alias that includes it. Use the command alias command to do this.
And if you always want step-in to step into code with no debug information, just set the global setting:
settings set target.process.thread.step-in-avoid-nodebug 0
either at the start of a debug session or in your .lldbinit.
Note, most of lldb's commands are documented in the help system. For instance, help step would have shown the above option for the step command, and apropos step would have shown the setting.
From GDB Manual:
Also, the step command only enters a function if there is line number information for the function. Otherwise it acts like the next command. This avoids problems when using cc -gl on MIPS machines. Previously, step entered subroutines if there was any debugging information about the routine.
And I found Step into works well when I have source file.
So maybe I have make a mistake. But the lldb is very lack of documents.
I'm trying to do something a little fancy here, but the docs suggest it should be possible. Maybe LLDB is still too new, but I'm getting a lot of debugger crashes / deadlocks and even when that doesn't happen it does't seem to work like I expected.
I'm trying to put together a debug wrapper around all selector calls, to extract the message call graph inside a certain chunk of code. (I could explain why if you really want to know, but it isn't really relevant to the debugger issue.)
I start out with an Xcode breakpoint on the line where I want to start tracking things (for bonus points, this is happening on a secondary thread, but before you ask, no, nothing on any other thread is doing any accesses to this object or anything in its property subgraph):
[myObject startProcessing];
The breakpoint triggers, and I run "bt", just to extract:
* thread #5: tid = 0x2203, 0x000277d2 .........
I then do something mildly evil: I put a breakpoint in objc_msgSend, right at the instruction where it calls out to the real object selector. objc_msgSend looks like:
libobjc.A.dylib`objc_msgSend:
...(instructions)...
0x37babfa4: bx r12
...(more instructions)...
(Actually there are two bx calls but let's keep things simple.) I run:
breakpoint set -a 0x37babfa4 -t 0x2203
(TID included because I'm having enough trouble tracking this one thread and I don't need irrelevant stuff interfering.)
Here's where the scripting comes in. The setup described above works exactly as I'd like it to. If I resume execution until the breakpoint triggers, I can run:
frame select 0
thread step-inst -m this-thread 5
frame info
continue
and the effect will be that the debugger:
moves to the objc_msgSend frame
steps by one instruction, advancing it into the object selector frame it was pointing at
displays relevant details (object type, selector called)
resumes execution
at which point I can keep pasting in those four commands over and over and copying the output until I hate myself.
If, on the other hand, I run:
breakpoint command add -s command
and paste in those exact same commands, everything breaks. It does not advance to the object selector frame. It doesn't show the frame details, or at least not the correct ones -- depending on various tweaks (see below), it may or may not show "objc_msgSend" as being the current function. It doesn't resume execution.
In this case, if I could get that example working, I'd be mostly happy. But for even more bonus points, I've also tried this with python, which I would prefer because it would allow for much more sophisticated logging:
breakpoint command add -s python
> thread = frame.GetThread()
> thread.StepInstruction(1)
> newFrame = thread.GetFrameAtIndex(0)
> print " " * thread.GetNumFrames() + newFrame.GetFunctionName()
> process = thread.GetProcess()
> process.Continue()
> DONE
Again no good. Again depending on tiny details, this may or may not print something (usually objc_msgSend), but it never prints the correct thing. It never steps the instruction forward. It never resumes execution afterwards.
And again, the python version works fine if I do it by hand: if I wait till the breakpoint fires, then run "script" and enter those exact same lines, it works as expected. Some parts will even work in isolation, e.g. if I remove everything except the parts that get the process and call process.Continue() and trigger those automatically, that "works" (meaning I see the lldb prompt flashing rapidly as it suspends and resumes execution. Usually I regret this because it becomes unresponsive and crashes shortly after.)
So: Any ideas? Is the technology Not Ready Yet, or am I just missing some clever piece of the puzzle that will fix everything? Or should I give up entirely and just live with the fact that there are some parts of object internals that I will never understand?...
Breakpoint commands cannot resume execution and then get control back again, at least today. There are a lot of unresolved questions about what would happen if breakpoint 1 is running the process and then breakpoint 2 is hit. Besides the whole question of whether the code base can really handle nested breakpoints correctly (it was designed to...), what does it mean if breakpoint 2 decides execution should stop? Is breakpoint 1's state thrown away?
It seems a little esoteric to worry about a breakpoint hitting another breakpoint while stepping the inferior process but unless all the details have been worked out, it's easy for the user to shoot themselves in the foot. So for today, breakpoint commands can either stop when the breakpoint is hit or continue to run - but there isn't any ability to run a little bit and do more processing. I know this would be a really useful capability for certain tasks but there are a lot of gotchas that need to be thought out before it could be done.
For some cases, it is possible to handle it the other way around ... if you want to stop in function parser() only when it has been called by function lexer(), it is easy to put a breakpoint on lexer() with some a few python commands to go one stack frame up the stack and see what the calling function is. If it's not lexer(), continue. I don't think this will apply to what you're trying to do, though.
Is it possible to abend your job intentionally through COBOL program.
suppose I have an Input file having Header,Detail and Trailer records. I will write a COBOL pgm which reads this file.If no Detail records are found in this file then I want to abend my job by giving some Abend Message and some Abend Code.Is it Possible?
Do you want to ABEND your program or just set a RETURN-CODE?
I suspect setting a RETURN-CODE, writing a message
and then terminating the program via a STOP RUN or GOBACK is all that
you really want to do. Causing an actual ABEND may not be necessary.
In an IBM batch environment, the RETURN-CODE set by your program becomes the
RC for the JCL job step the program was run under. This is typically what you
want to set and test for.
The RETURN-CODE is set by MOVEing a numeric value to it. For example:
DISPLAY 'No Detail Records found in file.'
MOVE 16 TO RETURN-CODE
GOBACK.
You may also issue a program dump from a program run under Language Environment (IBM
Mainframe option) using
the CEE3DMP--Generate dump
utility.
In older IBM Mainframe COBOL programs, you might see calls to the ILBOABN0 routine. This call
abended your program and issued a dump. This routine is now depreciated in favour of the
technique outlined above.
Finally, really old programs might have code in them to generate abends. This can be done in any number of ways, but division by zero was
often a favourite:
DIVIDE SOME-NUMBER BY ZERO GIVING SOME-NUMBER.
Works every time!
Personally, I recommend setting the RETURN-CODE over calling ILBOABN0 or data-exception tehcniques.
Note: The RETURN-CODE special-register is not part of the COBOL-85 standard. It is available as an IBM extention to the language. You may need to resort to a different mechanism if you are working in a non-IBM compatible environment.
see the following link on how to set the return code passed back to a JCL job step as well as force an Abened code.
http://www.tek-tips.com/viewthread.cfm?qid=1058302&page=22
First, you should check what is accepted by your own shop's/site's working standards. Most teams will already have an accepted way to deliberately abend a program for a 'logic' reason. One company I worked at has a very simple program called SYSABND2, which I believe is written in assembler, which is called just to abend the program.
That said, to ABEND (not just set return code), you should call module CEE3ABD (or previous version ILBOABN0, which is now deprecated).
For details, see:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceea300/clcdump.htm
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ceea400/ceea4150320.htm
One method for doing an abnormal end of run is to output a message to the user terminal or to the operator at a mainframe computer centre and possibly to a printer if necessary, all depending on the type of computer the program is to be run on. In cobol it is possible to use DISPLAY UPON .. and use an identifier for the terminal, operator console, or printer as defined in an entry in the SPECIAL-NAMES section of the ENVIRONMENT DIVISION. An example may be similar to this using the correct device names for your case
OPERATOR-CONSOLE IS OUT-OP2 in special-names with DISPLAY "RUN ERROR - NO DETAIL RECORDS, ABORTING" UPON OUT-OP2 and
DISPLAY "REPORT TO OPERATIONS MANAGER" UPON OUT-OP2 and STOP RUN. in procedure division.
A reference to the circumstance would need to be included in any job or macro and operating instructions.
Yes, it is possible to abend your job intentionally through COBOL program by simply calling one module which doesn't exist. It will give S806 abend code.
What's the best way to do the semantic equivalent of the traditional sleep() system call from within an Informix SPL routine? In other words, simply "pause" for N seconds (or milliseconds or whatever, but seconds are fine). I'm looking for a solution that does not involve linking some new (perhaps written by me) C code or other library into the Informix server. This has to be something I can do purely from SPL. A solution for IDS 10 or 11 would be fine.
#RET - The "obvious" answer wasn't obvious to me! I didn't know about the SYSTEM command. Thank you! (And yes, I'm the guy you think I am.)
Yes, it's for debugging purposes only. Unfortunately, CURRENT within an SPL will always return the same value, set at the entry to the call:
"any call to CURRENT from inside the SPL function that an EXECUTE FUNCTION (or EXECUTE PROCEDURE) statement invokes returns the value of the system clock when the SPL function starts."
—IBM Informix Guide to SQL
Wrapping CURRENT in its own subroutine does not help. You do get a different answer on the first call to your wrapper (provided you're using YEAR TO FRACTION(5) or some other type with high enough resolution to show the the difference) but then you get that same value back on every single subsequent call, which ensures that any sort of loop will never terminate.
There must be some good reason you're not wanting the obvious answer:
SYSTEM "sleep 5". If all you're wanting is for the SPL to pause while you check various values etc, here are a couple of thoughts (all of which are utter hacks, of course):
Make the TRACE FILE a named pipe (assuming Unix back-end), so it blocks until you choose to read from it, or
Create another table that your SPL polls for a particular entry from a WHILE loop, and insert said row from elsewhere (horribly inefficient)
Make SET LOCK MODE your friend: execute "SET LOCK MODE TO WAIT n" and deliberately requery a table you're already holding a cursor open on. You'll need to wrap this in an EXCEPTION handler, of course.
Hope that is some help (and if you're the same JS of Ars and Rose::DB fame, it's the least I could do ;-)
I'm aware that the answer is too late. However I've recently encountered the same problem and this site shows as the first one. So it is beneficial for other people to place new anwser here.
Perfect solution was found by Eric Herber and published in April 2012 here: How to sleep (or yield) for a fixed time in a stored procedure
Unfortunately this site is down.
His solution is to use following function:
integer sysadmin:yieldn( integer nseconds )
I assume that you want this "pause" for debugging purposes, otherwise think about it, you'll always have some better tasks to do for your server than sleep ...
A suggestion: Maybe you could get CURRENT, add it a few seconds ( let mytimestamp ) then in a while loop select CURRENT while CURRENT <= mytimestamp . I've no informix setup around my desk to try it, so you'll have to figure the correct syntax. Again, do not put such a hack on a production server. You've been warned :D
Then you'll have to warp CURRENT in another function that you'll call from the first (but this is a hack on the previous hack ...).