Program compiled through 4.2 or 6.2?

[Prakash Jha]

Hi,

We are changing our COBOL compiler to COBOL 6.2. We were on COBOL 4.2. The path we are following is that we compile one program by one program. Now many times when a program we pick up from baseline to for new development, it's touch to know whether the program was installed with COBOl 6.2 or 4.2? Is there an easy way to find this? We use ISPW.

I search online about this, CSECT can help in this. Does anyone know how to make easy for every junior programmer?

[Anuj Dhawan]

Should not the compile listing be a good enough source for this information?

[Priya]

Is not COBOL 4.2 already out of support?

[lchui]

Hi,

We are changing our COBOL compiler to COBOL 6.2. We were on COBOL 4.2. The path we are following is that we compile one program by one program. Now many times when a program we pick up from baseline to for new development, it's touch to know whether the program was installed with COBOl 6.2 or 4.2? Is there an easy way to find this? We use ISPW.

I search online about this, CSECT can help in this. Does anyone know how to make easy for every junior programmer?

(Posting for a colleague)
The AMBLIST LISTIDR function will show you the translator(s) that produced the CSECTs in an executable.

[lchui]

Is not COBOL 4.2 already out of support?

No, it is not. End of Service is currently planned for end of April, 2022.
You can find some COBOL compiler End of Service Dates here https://community.ibm.com/community/use ... vice-dates

[Priya]

Hi,

We are changing our COBOL compiler to COBOL 6.2. We were on COBOL 4.2. The path we are following is that we compile one program by one program. Now many times when a program we pick up from baseline to for new development, it's touch to know whether the program was installed with COBOl 6.2 or 4.2? Is there an easy way to find this? We use ISPW.

I search online about this, CSECT can help in this. Does anyone know how to make easy for every junior programmer?

(Posting for a colleague)
The AMBLIST LISTIDR function will show you the translator(s) that produced the CSECTs in an executable.

Who is the colleague?

Also, could you please guide how to use AMBLIST for this?

[Priya]

Is not COBOL 4.2 already out of support?

No, it is not. End of Service is currently planned for end of April, 2022.
You can find some COBOL compiler End of Service Dates here https://community.ibm.com/community/use ... vice-dates

Thanks for the link. It is interesting to know that COBOL 4.2 will be supported until 2022 while COBOL 5.1 and 5.2 are gone in April 2020 itself! COBOL 5.1 and COBOL 5.2 should be newer than COBOL 4.2, right?

[pinball]

Does that mean that every company has to migrate to COBOL 6.2?

[lchui]

Hi,

We are changing our COBOL compiler to COBOL 6.2. We were on COBOL 4.2. The path we are following is that we compile one program by one program. Now many times when a program we pick up from baseline to for new development, it's touch to know whether the program was installed with COBOl 6.2 or 4.2? Is there an easy way to find this? We use ISPW.

I search online about this, CSECT can help in this. Does anyone know how to make easy for every junior programmer?

(Posting for a colleague)
The AMBLIST LISTIDR function will show you the translator(s) that produced the CSECTs in an executable.

Who is the colleague?

Also, could you please guide how to use AMBLIST for this?

A simple google "IBM AMBLIST" returned quite a few results. Perhaps this one is useful:
https://www.ibm.com/support/knowledgece ... ambrun.htm

[lchui]

Does that mean that every company has to migrate to COBOL 6.2?

Check out the COBOL Migration Portal. It is an invaluable resource to help clients on their decision and journey to migrate their COBOL applications:

https://www.ibm.com/support/knowledgece ... ortal.html

[Robert Sample]

Does that mean that every company has to migrate to COBOL 6.2?

IBM has, for more than 50 years now, released updated versions of system programs (including the COBOL compiler). While it is never mandatory to migrate to the new version, what companies run into is that IBM eventually stops supporting the old version. Without support, if you have a problem or question with that version, IBM will tell you they don't support that version and you're on your own. Granted, it is rare to need support for a COBOL compiler when it is out of support but it does happen every now and then. The old version will continue to run, even across machine upgrades, until something is changed that prevents the old version from working any more. I have heard of companies running operating systems that are 15 to 20 years old (and even hardware that old) with no problems (no support, either, but they don't usually need support).

Also, could you please guide how to use AMBLIST for this?

The manual explaining -- in detail -- AMBLIST is the z/OS MVS Diagnosis: Tools and Service Aids manual for your version of z/OS.

The real issue, to me, is why do you care if it was previously compiled in 4.2 or 6.2? Just compile the program in 6.2 and you'll be done with it. Since 4.2 programs will continue to execute, your company can slowly migrate everything to 6.2 as programs need to be changed.

[Prakash Jha]

Thanks Robert.

(no support, either, but they don't usually need support).

Then how do they get it working, how they make the 'system level changes' happen?

[Robert Sample]

Then how do they get it working, how they make the 'system level changes' happen?

I'm not sure I understand the question. When a system programmer prepares to upgrade the operating system, one of the tasks is to determine which load libraries from the old release should be carried forward into the new release. If one of those load libraries is the COBOL compiler (version 4.2, 3.4, 5.1, or whatever) then when the new release is implemented, that old version of the COBOL compiler will be accessible and usually will run without issue. Yes, there may be a new version of the COBOL compiler installed with the new release and that's fine -- it will be in a different load library than the old version. So if a programmer is compiling an old version program, they point to one load library in the compile JCL, and if the programmer is compiling a new version program, they point to a different load library in the compile JCL (actually, depending upon the versions the compile JCL can be quite different -- COBOL added a batch of DD statements in I believe version 5.1 that were not present in earlier versions). There's nothing to "get it working" since it was working and continues to work.

[Priya]

Check out the COBOL Migration Portal. It is an invaluable resource to help clients on their decision and journey to migrate their COBOL applications:

https://www.ibm.com/support/knowledgece ... ortal.html

This is an excellent source, Thanks for sharing it.

[vagner.bellacosa]

Good afternoon, I use an academic environment in which until recently we used COBOL 4.2.

They recently changed to version 6.3, but my compilation jobs no longer work. Could anyone please provide a jcl copy for the new version?

- COBOL compilation
- COBOL + DB2 compilation
- COBOL + CICS compilation
- COBOL + DB2 + CICS compilation

Thank you very much
Vagner