Is there a way of identify the program name in the call stack?
i.e., I've got a PGM X that links to a PGM B and this one links to a PGM C, and then, in C, I want to know which program originates the call (PGM X)?
If you're in CICS, you can do EXEC CICS ASSIGN and get the name of the current program with the PROGRAM option, and the program that linked to it with INVOKINGPROG. That will give you Program C and Program B in this case.
To get the original highest level program is more difficult. You can inquire on the current transaction (EIBTRNID) to get what program that runs, but if you've been routed somewhere then that won't be Program X but DFHMIRS for example.
You can do this, but it will take a little assembler. Essentially, you need to chase up the save areas and execute a CSVQUERY on the return address, this will give you the name of the module that owns that save area.
There are a few quirks, you need to watch out for Cobol runtime modules (prefixed with IGZ) and/or Language Environment modules (prefixed with CEE). When you do a Cobol Call, it invokes a runtime module that then calls the program you called.
Also, this will not identify programs that did a E. C. LINK or E. C. XCTL, only Cobol Call invocations that use OS save area conventions.
Example:
CSVQUERY SEARCH=JPALPA,INADDR=<R14_from_savearea>,OUTEPNM=<module_name_output>,MF=(E,PLIST)
Do that repeatedly for every return address on the save area chain and you will know all the callers.
There is no supported way to do that. Some people try chasing save areas and walking through the executable code to determine its name, but I suspect that all ends in tears.
One problem is that you have no guarantee of how LINK or XCTL have been implemented. In the case of dynamic calls you might be able to follow the save area chain, but then you need to figure out how to identify the module. Not something you're likely to be able to do in just COBOL.
Related
I'm working with Delphi 10.4.
At some places of my code I have to write long identifiers on long statements (e.g. ProductsForSale.fieldByName('quantity').asInteger * ..... / .... etc.). Is there a way to assign a friendly alias (e.g. TheCost) to this piece of code to substitute it everywhere in the application?
I don't want to use a variable or a function to do this. Only text substitution.
No, Delphi (and Pascal) knows
neither aliases (using a different name for a type/variable/function still needs you to define it anew),
nor macros (executing code in the compiler's context is very limited, mostly definings and conditions).
Even if, chances are you'd have to define it bound to a given context/scope: i.e. your favorite alias TooMuchToType might access three variables named one, two and three, but as per scope those variable's types can vary drastically. Its usage would be prone to obfuscated code and a lot of hassle the compiler has to go thru when trying to give you an error message he wants you to understand.
Why not doing exactly that at the end, but in the opposite way? First using a placeholder and when you're done you replace all of them with the actual code. Otherwise this is bascially what functions are there for, if you want it or not.
What is the benefit of using paragraphs and sections for executing pieces of code, instead of using a subprogram instead? As far as I can see paragraphs and sections are dangerous because they have an non intuitive control flow, its easy to fall through and execute stuff you never meant to execute, and there is no variable (item) scoping, therefore it encourages a style of programming where everything is visible to everything else. Its a slippery soup.
I read a lot, but I could not find anything related to the comparative benefit of paragraphs/sections vs a subprogram. I also asked online some people in some COBOL forum, but their answers were along the lines of "is this a joke" or "go learn programming"(!!!).
I do not wish to engage in a discussion of stylistic preferences, everyone writes the way that their brain works, I only want to know, is there any benefit to using paragraphs/sections for flow control? As in, are there any COBOL operations that can be done only by using paragraphs/sections? Or is it just a remnant of an early way of thinking about code?
Because no other language I know of has mimicked that, so it either has some mechanical concrete essential reason to exist in COBOL, or it is a stylistic preference of the COBOL people. Can someone illuminate me on what is happening?
These are multiple questions... the two most important ones:
Are there any COBOL operations that can be done only by using paragraphs/sections?
Yes. A likely not complete list:
USE statements in DECLARATIVES can only apply to a paragraph or a section. These are used for handling file errors and exceptions. Not all compilers support this COBOL standard feature in full.
Segmentation (primary: a program that is only partially loaded in memory) is only possible with sections; but that is to be considered a "legacy feature" (at least I don't know of people actually using it this way explicitly); see the comment of Gilbert Le Blanc for more details on this
fall-through, many other languages have this feature with a kind of a switch statement (COBOL's EVALUATE, which is not the same as a common switch but can be used similar has an explicit break and no fall-through)
GO TO DEPENDING ON (could be recoded to achieve something similar with EVALUATE and then either PERFORM, if the paragraphs are expected to fall-through, which is not uncommon, then that creates a lot of extra code)
GO TO in general and especially nice - the old obsolete ALTER statement
PERFORM statement, format 1 "out-of-line"
file state is only shared between programs when you define it as EXTERNAL, and you often want to have a file state being limited to a single program
up to COBOL85: EXIT statement (plain without anything else, actually doing nothing else then a CONTINUE would)
What is the benefit of using paragraphs and sections for executing pieces of code, instead of using a subprogram instead?
shared data (I guess you know of programs with static data or otherwise (module)global data that is shared between functions/methods and also different source code files)
much less overhead than a CALL is
consistency:
you know what's in your code, you don't know what another program does (or at least: you cannot guarantee that it will do the same some years later exactly the same)
easier to extend/change: adding another variable (and also removing part of it, change its size) to a CALL USING means that you also have to adjust the called program - and all programs that call this, even when you place the complete definition in a copybook, which is very reasonable, this means you have to recompile all programs that use this
a section/paragraph is always available (it is already loaded when the program runs), a CALLed program may not be available or lead to an exception, for example because it cannot be loaded as its parameters have changed
less stuff to code
Note: While not all compilers support this you can work around nearly all of the runtime overhead and consistency issue when you use one source files with multiple program definitions in (possibly nested) and using a static call-convention. This likely gives you the "modern" view you aim for with scope-limitation of variables, within the programs either persistent (like local-static) when defined in WORKING-STORAGE or always passed when in LINKAGE or "local-temporary" when in LOCAL-STORAGE.
Should all code of an application be in one program?
[I've added this one to not lead to bad assumptions] Of course not!
Using sub-programs and also user-defined functions (possibly even nested providing the option for "scoped" and "shared" data) is a good thing where you have a "feature boundary" (for example: access to data, user-interface, ...) or with "modern" COBOL where you have a "language boundary" (for example: direct CALLs of C/Java/whatever), but it isn't "jut for limiting a counter to a section" - in this case: either define a variable which state is not guaranteed to be available after any PERFORM or define one for the section/paragraph; in both cases it would be reasonable to use a prefix telling you this.
Using that "separate by boundary" approach also takes care of the "bad habit of everything being seen by everyone" issue (which is in any case only true for "all sections/paragraphs in the same program).
Personal side note: I would only use paragraphs where it is a "shop/team rule" (it is better to stay consistent then to do things different "just because they are better" [still providing an option to possibly change the common rule]) or for GO TO, which I normally not use.
SECTIONs and EXIT SECTION + EXIT PERFORM [CYCLE] (and very rarely GOBACK/EXIT PROGRAM) make paragraphs nearly unnecessary.
very short answer. subroutines!!
Subroutines execute in the context of the calling routine. Two virtues: no parameter passing, easy to create. In some languages, subroutines are private to (and are part of) the calling (invoking) routine (see various dialects of BASIC).
direct answer: Section and Paragraph support a different way of thinking about programming. Higher performance than call subprogram. Supports overlays. The "fall thru" aspect can be quite useful, a feature rather than a vice. They may be necessary depending on what you are doing with a specific COBOL compiler.
See also PL/1, BAL/360, architecture 360/370/...
As a veteran Cobol dinosaur, I would say asking about the benefit is not the right question. I used paragraph (or section) differently than a subprogram. The right question in my opinion is when to use them logically. If I can make an analogy, if you have a Dog java class, you will write Dog-appropriate methods within it. If there's a cat involved, you may need a helper class. In this case the helper class is the subprogram. Though, you can instead code the helper class methods inside the Dog class, but that will be bad coding.
In any other language I would recommend putting self contained functions into subroutines.
However in COBOL not so much. If the code is very likely to be used in other programs then a subroutine is a good idea. Otherwise not!
The reason being the total lack of any checks on the number type or existence of passed parameters at compile time. Small errors in call statements lead to program crashes at run time. Limiting the use of sub-routines and carefully checking the calling code for errors makes for a more reliable program.
Using paragraphs any type mismatch will be flagged at compile time, or, an automatic conversion will occur.
I am responsible for converting an old UNIX based COBOL batch application that was developed by a consultant back in the 1990s to a Windows environment but still in COBOL using Microfocus (Eclipse, etc).
This is a pretty straight-forward task except for one little glitch.
The old application never did any explicit file handling within the COBOL. That is there are no FDs, OPENs, READs, WRITEs or CLOSE commands in the COBOL programs. Instead they wrote a C program that would do one of those different functions based on parameters passed to it (including, but not limited to file name, rec length, and the function desired.)
I would like to rewrite that subroutine in COBOL, which would require very little modifications to the COBOL main programs being converted. That is, it would still call that subroutine, but it would now be in COBOL instead of C.
But the challenge is how to write that subroutine so that it is able to act on most any file. I would think I have to go the route of variable length records because they could literally be any length up to to-be-determined maximum size, but seems like it would be vulnerable to error (as it tries to open different types of files).
Does anybody have any experience on this or ideas on a task like this? If not,l I may have to go the blunt force route of replacing each call statement to that subroutine with the specific COBOL command (Open, Read, etc) that needs to be performed and obviously FD and SELECT for every file would need to be added to the main program.
Thanks in advance.
You might be able to
CALL "subprogram" USING fd-name
where fd-name is
FD fd-name.
...
So, yes? maybe?, you might be able to pull off a subprogram that can take generic COBOL files. But, then you get into matching record layouts and other fun things, so, be wary. This might not work COBOL to COBOL, but it does work COBOL to C and back, as you end up passing a reference to the file control block.
You'll likely be better off looking into stock system libraries. Things like CBL_OPEN_FILE and CBL_READ_FILE if they are available. This will give you a much closer match to streaming IO that will be assumed in the current C subprogram.
Or, as Bill is suggesting in the comments, try and figure out why C was used and if you don't want the foreign functions, just dig in and write new COBOL procedures, as that will likely read better in the end.
I am trying to print AFP to sysout but the FORMS parameter is not known (and cannot be known) by the JCL. My current solution is to create dynamic JCL and spin it to INTRDR, but this is a weak solution because the job will not be under the control of our scheduler... and thus, an abend or other issue will go unnoticed by night-time operators.
I started concocting a way to print the AFP via a COBOL program. I use BPXWDYN to create the SYSOUT DD dynamically, which allows me to set the FORMS parameter however I want. But the next step is dumping the AFP to that DD.
I thought I could call IEBGENER dynamically from my COBOL program, but that pulls a S0C4.
I can move the AFP records from one DD to the other in the COBOL program, but that limits me to one LRECL... and I have many different LRECL definitions for AFP throughout my system, and COBOL MUST know the LRECL at compile time.
Any thoughts? Is it possible to call IEBGENER dynamically and not get the S0C4? Any other ideas I haven't thought of?
Thanks in advance...
Have you thought of writing a small assembler program? You can specify the LRECL in your BPXWDYN call, and the DCB does not need to specify an LRECL; it will get it from the DCB parameters at OPEN time. A program to simulate IEBGENER is quite trivial.
Alternatively, look at calling SORT with a FIELDS=COPY parameter. SORT doesn't need the LRECL either. Or write a REXX script.
There are many ways of doing this; you just need to look outside the COBOL box.
Your question is not extremely clear but I'm wondering if you should consider using the ACIF utility program called APKACIF instead of IEBGENR. The utility will merge your data and resolve the AFP FORMDEF, PAGEDEF objects to a dataset or print stream.
I need to pass the SYSUID and JOBID to the cobol program for logging purpose, how is this possible?,
can the same be passed as an input for a query in a JCL.
Thanks in advance.
SYSUID is simple, you just add it to the PARM parameter of your EXEC statement.
//ASTEP EXEC PGM=A#PGM,PARM='&SYSUID'
JOBID isn't available as a parameter. You will have to write COBOL code to chain through z/OS control blocks (see the Data Areas books at that link) if you need it. This can be done, but I don't recommend it.
If you actually want to get the job number, you write code to go to the PSA control block, which is at relative memory location 0. From there you get a pointer to the current TCB which is in the PSATOLD field of the PSA, from the TCB you get the TCBJSCBB field which is a pointer to the JSCB, from the TCBJSCBB fielf in the JSCB you get a pointer to the SSIB which contains the SSIBJBID field which is the job number. All of these control blocks, PSA, TCB, JSCB, and SSIB are documented (for z/OS 2.4) at the link above. And I reiterate that I don't recommend doing this.
There's a tutorial on chaining through z/OS control blocks in two parts from Longpela.
I agree with #cschneid that you don't want to do all of the pointer chaining just to get the job number. But of course we did do it while creating a "banner page printing" program. We based ours off the code at http://gsf-soft.com/Freeware/COB2JOB.shtml.
If you are comfortable with using SET ADDRESS OF items in the LINKAGE SECTION, REDEFINE--ing POINTER and COMP-5 items, along with creating 01 level structurs from assembler DSECTs, then by all means do it. As a lightweight COBOL subroutine, it's not that much more overhead than an assembler routine (but assembler is better). If you are comfortable with the REXX STORAGE function, you can look at Dave Alcock's IPLINFO program.
However, if the COBOL language constructs I mentioned are unknown to you, then write an assembler subroutine, or ask someone to write it.