COBOL - Subroutines

[@TutorialsPoint_]

To Get Certification, Click Here: www.tutorialspoint.com/cobol_online_training/index.asp Use coupon "KZbin12" to get ‘’FLAT 12%’’ OFF at Checkout.

[@nickjohnson4500]

Thanks for taking the time to show us the basics of cobol!

[@redcrimson718]

Thank you for presenting this series. You are a good teacher.

[@nawar6624]

Thank you very much for your valuable tutorials. They were of great help to me

[@mikew7104]

Your cobol videos are well done, and I like them. However, in this video of cobol - subroutines you have a typo at 5:10 in PGM2 that could be confusing to new to cobol viewers. In the called program's IDENTIFICATION DIVISION. PROGRAM ID. is set to PGM1 and should be PGM2.

[@bradleyrigg7137]

Hi! Thanks for your great videos. Could you share the JCL you used to compile and link the COBOL programs. Try as I may I cannot get sub routines to not abend when called. Thanks.

[@jaycahow4667]

First lets get our terminology correct. You write individual stored COBOL Programs (you never Execute them). Completed Programs are then successfully Compiled into individual stored Object Modules Stored individual Objected Modules are then successfully Linked together to create stored Load Modules. Stored Load Modules are what is actually Executed. A Stored Load Module will contain at least one COBOL Object Module but may contain many more (one Object Module for each Statically Called sub module). Dynamically Calls reference separately called Load Modules which which have been pre-created and may contain multiple Object Modules as well. A Load Module even with only one COBOL Object Module still has other things combined with it by the Link Process and Object Modules themselves are Not executable. As part of the Link process you need to have an Entry Card which tells the OS where to stare executing the combined Load Module. You also need a Name so the Link Process knows what Loadlib Member is created in the Output Load Library. You also need Include Cards for the Main program and each Statically Called sub program so the Link Process knows where to get each Object Module it is combining together as it creates the Load Module. The Link process then creates an internal table within the Load Module with a list of all Object Modules combined together and where each starts so those modules can be transferred to when a Static Call to them is invoked in the Load Module. The Link process knows from each Object Module you are combining together all the Static Calls that are made in each Program. It checks that it can find an Object Module for every Statically called Program. If it can locate every Statically Called program then you will get a Reurn Code of Zero. If one or more is missing you will get a Non Zero return code. A Load Module can be created with one or more sub referenced Object Modules missing but the Job will Abend if the Call Statement to one that is missing is actually Executed. If you Browse a Load Modules you should be able to do a Search on the name of each Statically Called sub module and it should be present along with the Date and Time it was Compiled into an Object Module. If you find all the Sub Modules present then the Compile and Link Process is probably working correctly and you need to make sure the same number of items are being passed and received on each side of the Static Call. The passed items also have to be in the same order on each side of the call otherwise you will be referencing incorrect Storage Locations.

[@SatyendraJaiswalsattu]

Good job😊👍

[@weforinfo2712]

Can we expect CICS tutorial as well??

[@SagarKumar-pr2hj]

When to use static call and when to use dynamic call, for what circumstances each of them would be preferred?

[@jaycahow4667]

Static calls cause the calling and called programs to be combined at Link time when the executing Load Module is created. The called program cannot be changed without relinking. Dynamic calls cause the called program to be loaded from a Load Library upon the first invocation of the call. That means normally all subsequent invocations of the call use the same version as the first as it is not reloaded. Because it is loaded separately the called program can be changed and relinked on its own. Usually programs that are called from multiple programs or systems are good candidates for Dynamic Calling as they can be changed one time and everyone picks up the new code upon next execution. That makes maintenance easier, but on the flip side if you screw up the Dynamically called program you could cause errors or abends in multiple jobs.

[@VinayKumar-rc3sh]

Sir say about dynamic how to execute program

[@nibbie1000]

Why didn't you show dynamic and static call execution in detail? That is a difficult concept to understand. Could you please make another video to explain that in depth?

[@lakshman3135]

is it possible to call morethan one subprograms?

[@jaycahow4667]

You can have hundreds of Statically called programs combined together in a single Load Module. The can be dozens of layers deep as well (A -> B -> C -> D -> E). Remember that you either pass the actual location of Storage to a Sub Program (in which case any changes made to that Storage in the Sub Module reflect in the Calling Program as well) or you pass the location of a copy of the original Storage (in which case any changes made to that Storage in the Sub Module are Not reflected in the Calling Program). What Storage you Pass is determined by how you code the Static Call to the Sub Module.