What happened to the Commarea passed by Program A in both of these examples?
Program A does an EXEC CICS LINK to Program B then Program B uses the GOBACK command
Program A does an EXEC CICS LINK to Program B then Program B uses the EXEC CICS RETURN command
See https://stackoverflow.com/a/28056695/1927206.
Nothing happens to the commarea.
If B changes it, it is changing the storage that A is aware of.
Only the address of data is "passed" between programs. Only the original data exists, Program B manipulates the original data. There is no copying of data between CALLing and CALLed programs.
Separate from what happens to the data (nothing) the two examples you show have identical behaviour. Use the local standards for your site.
GOBACK is an older COBOL construct used in the called program.
EXEC CICS RETURN gives up control to CICS. CICS determines what program gets control next.
Related
Is there any way to detect an environment variable change DURING the execution of a Tcl script (I use Tk so the execution can be long) ?
For instance, if I define an environment variable MYVAR=1, then I can access it from Tcl by writing $ENV(MYVAR). Let's say now that during the execution of the Tcl program, I switch MYVAR to 2. Is there a way, or maybe a command, that scans every environment variable again so I can get 2 when I call $ENV(MYVAR) ?
First off, other processes will not see changes to the environment variables of any process. Children get a copy of the current environment when they are created, and that's it.
Secondly, to see a change in the environment variables, put a trace on the ::env variable (but tracing an individual variable is not recommended). I can't remember if this works reliably between threads, but within a thread it's pretty good provided you don't have C code modifying the variables behind your back.
proc detectChange {name1 name2 op} {
# We know what name1 and op are in this case; I'll ignore them
if {$name2 eq "MYVAR"} {
puts "MYVAR changed to $::env(MYVAR)"
}
}
trace add variable ::env write detectChange
Note that Tk internally uses traces a lot (but the C API for them, not the Tcl language API for them).
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.
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.
I write a C program gets in an environment variable's name and print out it's memory address, simply use the getenv() function to do the job. Let's say I wanna have the address location of PATH --> ./test PATH. But when I debug that program in gdb, the memory location of that variable is different. Can you explain in detail why is there such a different?
To be more exact:
./test PATH --> 0xbffffd96
debug in gdb --> 0xbffffd53
[edit] Thanks for your explanations. What I actually in question about is, how the memory address of a variable (in this case, an environment variable) changes with different programs. For example, I have 2 program a.out and b.out
./a.out --> PATH's address is some number
./b.out --> another number
So, what causes this difference between 2 numbers? I hope I have clearly demonstrated what I want to ask. Thanks mates.
Typically, environment variables are part of some "process data block", and those are inherited from the starting process. If you are running a program in a debugger, that debugger will have its own process data block and your program will inherit its process data block from the debugger. That in turn might have inherited the program data block of the IDE.
This doesn't matter anyway, because the interface to the environment variables doesn't give you that kind of details. For instance, on Windows it's quite likely that the environment variables will be converted from Unicode to your local 8 bit codepage when you ask for them. You'd never see the original variable, just (an approximation of) its value.
Perhaps you want to do?
printf("%s",getenv("PATH"));
Getting the environment variable string does make sense.
But, the address where the system gives you the string, has no relevance anywhere
(particularly outside the scope of this program).
You should be interested in the environment string value rather than its address.
If you have any reason to use the address, please give that here.
For example,
echo $PATH
gives me,
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin: ... etc
All my programmatic interest with PATH would be in its contents not any sort of address.
Why would you expect it to return the same memory location every time? getenv returns "a pointer to a string containing the value for the specified name." It is not specified which memory location the string is located at, nor whether that location will later be overwritten.
I am trying to create an external stored procedure on an IBM i (V5R4), but I'm getting an error when I try to run it.
All I want to do is call an RPG program, without passing any parameters or worrying about returning any data. Sorry, I'm not an RPG programmer or an expert on IBM i, so I could be missing something very simple.
The SQL to create the procedure:
CREATE PROCEDURE SOMELIB.SOMEPROC ( )
LANGUAGE RPGLE
NOT DETERMINISTIC
NO SQL
EXTERNAL NAME 'OTHERLIB/SOMERG'
PARAMETER STYLE GENERAL;
The error I get when executing CALL SOMELIB.SOMEPROC() is:
SQL State: 38501
Vendor Code: -443
Message: [CEE9901] Application error. RNX1216 unmonitored by BB1002RG at statement 2100000001, instruction X'0000'. Cause . . . . . : The application ended abnormally because an exception occurred and was not handled. The name of the program to which the unhandled exception is sent is SOMERG SOMERG . The program was stopped at the high-level language statement number(s) at the time the message was sent. If more than one statement number is shown, the program is an optimized ILE program. Optimization does not allow a single statement number to be determined. If *N is shown as a value, it means the real value was not available. Recovery . . . : See the low level messages previously listed to locate the cause of the exception. Correct any errors, and then try the request again.
Your procedure is calling the RPG program without the library list set. You can do one of two things:
1) Change the F-spec in the RPG program to qualify the library using the EXTFILE keyword.
2) Call a CL program from the stored procedure that adds the appropriate library to the library list making sure to allow for the fact that the library may already be there from a prior call. Then have the CL program call the RPG program.
(a little bit more rude solution) Identify the user that starts the Stored Procedure. Change the jobdescription of that user to have the correct library list.
But in my experience is the CL program the most pragmatic solution too.
Assuming the file is in the same library as the program, add EXTFILE(variablename) and USROPN to the F-spec. Take the library name from the PSDS and construct the variablename value before you OPEN the file.
If the file and program are in different libraries, you might create a data area in the program library to hold the name of the data library. Retrieve the data area (using the PSDS) instead of using the PSDS (for the file library). If program and file aren't kept together, it can be a good idea to keep the data library name in an external object that can be changed rather than recompiling.
(Actually, I've rarely used data areas in the past ten years or so. Instead I create a user index. Each entry in the *USRIDX replaces a data area. The entries are keyed by a value that used to be a data area name. One object replaces many others and one procedure can manage all entries. One object to own and authorize reduces some system overhead.)
A suggestion to get rid of this trouble: make the user profile JOBD contains all libraries needed by the stored procedure.