IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Compile a Cobol -Db2 program with older compiler version


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Tue Oct 11, 2011 6:49 pm
Reply with quote

From the thread: www.ibmmainframes.com/viewtopic.php?t=56396, picked this

dbzTHEdinosauer wrote:
Anuj Dhawan wrote:
mfguy01 wrote:
I have a requirement to compile a Cobol -Db2 program with older compiler version.
Why do you want to do this? (Possibly something you don't want to hear!?) What purpose does this serve?


could be part of a legacy system.

My lil experience at its best -- Does this happen, practically?
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10886
Location: italy

PostPosted: Tue Oct 11, 2011 6:57 pm
Reply with quote

yes.. quite often in my experience
usually needed when making local changes or corrections to third party software packages
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1353
Location: Israel

PostPosted: Tue Oct 11, 2011 9:12 pm
Reply with quote

Some products (like DumpMaster, Intertest and Xpediter) use the compilation listing to map the program.
I've had some cases (usualy whith old programs) where the compilation listing was missing. And because these are old programs they were compiled with an old compiler version.

As Intertest and Xpediter usualy run only in test environments, there is no problem recompiling and retesting with the new module and the new listing.

As DumpMaster runs also (mostly?) in production, it's different because you can't just recompile or even reproduce the abend.

So, yes, maybe sometimes it would be nice to be able to re-generate the compilation listing with an old compiler...
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Wed Oct 12, 2011 1:10 pm
Reply with quote

Thanks Enrico and Marso - this helps...icon_smile.gif

So, that means - they keep a copy of older compiler as well in some "private-libraries", do they?
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10886
Location: italy

PostPosted: Wed Oct 12, 2011 3:26 pm
Reply with quote

the need to carry on older software comes out from the impact analysis
done, in any decently managed environment, while planning for a zOS migration
and since it has been a while that IBM ships everything ( well... almost ) with a dataset naming that contains the info about the version/release
we might start a bloody debate if when carried along to the new system they should considered as private or system stuff icon_biggrin.gif
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Wed Oct 12, 2011 7:18 pm
Reply with quote

Hi Anuj,

Quote:
So, that means - they keep a copy of older compiler as well in some "private-libraries", do they?
Some places do, some places don't. Often this depends on how long the "old" system/compiler is to be used.

If the old application(s) are being replaced, they are sometime not upgraded to the new compiler. Which means the old compiler stuff must be maintained if any changes are to be made.

Most of my sites have upgraded "everything" to whatever release of the compiler is being implemented. Most places have a common way to compile/link and to double this for 2 compile/link processes is undesirable.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10886
Location: italy

PostPosted: Wed Oct 12, 2011 7:40 pm
Reply with quote

confirm ..
never seen for full in house developed things
only for
maintenance of third party software packages

once upon a time a few software companies used to associate a certain version of a package to a certain version of the compilers
a change of the compiler often meant migrating the software to an higher version with the relative fees
pretty stupid approach !
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Oct 12, 2011 8:43 pm
Reply with quote

we have a package (bought in middle 90's),
we OWN the software and do as we please.

3000+ modules in COBOL2 (online and batch, with some 'DUALS')

40-50 E-COBOL modules.

New - standalone - development is E-COBOL,
done mainly to allow for DB2-9
instead of V7 for the COBOL-2.

there is no way my QA group could do a comprehensive test if we were
to convert all the COBOL-2 to E-COBOL.

costs money. No cost benefit to converting to E-COBOL
(making it easier on the development and prod-support group does not count).
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Wed Oct 12, 2011 11:59 pm
Reply with quote

After years of indecision, the shop I am working in decided to force all new work to be compiled using the latest available Cobol compiler. When you check out a program compiled with an older Cobol version (such as OS/VS Cobol or COBOL II), the source management system (Endevor) forces you to use Enterprise Cobol when you compile your changes. Migration issues are the responsibility of the programmer. (Not a big deal; the issues are well documented by IBM in the various Migration Guides).
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL

PostPosted: Thu Oct 13, 2011 12:21 am
Reply with quote

dbzTHEdinosauer wrote:
New - standalone - development is E-COBOL,
done mainly to allow for DB2-9
instead of V7 for the COBOL-2.

there is no way my QA group could do a comprehensive test if we were
to convert all the COBOL-2 to E-COBOL.

costs money.

Which is why older compilers linger on. My shop is in the final months of a multi-year (5-6, IIRC) project to convert from MVS PL/I to Enterprise PL/I...which we would never have undertaken save that IBM no longer supports MVS PL/I.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Oct 13, 2011 1:28 am
Reply with quote

am not debating the benefits gained by the upgrade.

before as a consultant (4 years), now as an employee of the firm(1 year +)
i have been fighting this battle.
after several 'test conversions'
the whole thing is automated by rexx scripts.
to convert the complete system (to include replacing sql where benefits would be gained)
takes about 30 hours wall-clock to create a new e-cobol load

the problem, as I said,
qa is not in a position to test everything against production in parallel.
nor will they accept the responsibility for doing it.
they are so afraid of the project, that they have estimated that it would take 6 months.

now, try to get 6 months past a bean-counter,
when there is no change to the application,
except faster thru-put,
but we don't really pay for machine time on a 'use-basis'.
same cost if our batch runs for 8 hours or 4.

and ibm still receives money for extending maintenance for a db2 vsn7 precompiler,
though they supposedly will not longer modify the cobol2 compiler.
no need.

my contract is up at the end of this month,
and i don't think i will stay.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Tue Oct 18, 2011 4:03 pm
Reply with quote

enrico-sorichetti wrote:
the need to carry on older software comes out from the impact analysis
done, in any decently managed environment, while planning for a zOS migration
and since it has been a while that IBM ships everything ( well... almost ) with a dataset naming that contains the info about the version/release
we might start a bloody debate if when carried along to the new system they should considered as private or system stuff icon_biggrin.gif
Make sense. I've not been involved in such compiler migrations but then at one of the shops we had one SORT product replacing other and then these libraries were known to me.(How? Don't ask - just ate the head of the admin invloved in this. Systems programmers are not that friendly always, you know - Okay, Robert -- you are an exception..icon_smile.gif).

I met application programmers who don't even know, what happens under the covers when they use some "front end tool" to compile their programs -- so was wondering (keeping the thread in mind I linked to) why a "front end tool" be botherd to choose a compiler per the programmers wish. Unless, specifically required - all the programs being compiled currently, in test LPAR of some shop, are using the same compiler. I think, I stand corrected.

Thanks Enrico, it's always fun to have you guys around.

Regards,
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Tue Oct 18, 2011 4:20 pm
Reply with quote

Thanks Dick... icon_smile.gif

dick scherrer wrote:
Some places do, some places don't. Often this depends on how long the "old" system/compiler is to be used.
may be this can happen in Prod but when one talk about a development LPAR, I doubt if that's still applicable? As every next release will backward-compitible.

Quote:
If the old application(s) are being replaced, they are sometime not upgraded to the new compiler. Which means the old compiler stuff must be maintained if any changes are to be made.
That make sense however, as I sais, every next release will backward-compitible, then what are the case where we might need this - if we strictly talk about COBOL compilers?
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Tue Oct 18, 2011 4:32 pm
Reply with quote

I was thinking on the lines of what don.leahy has stated. But the replies from Dick (dbz) makes me think why to do that (having two different versions of compiler)? Is not it like working-in-two-shops-at-the-same-time? One is on COBOL 2 and another is COBOL E? Once you are wokting on COBOL 2 and are thinking about all the constraints it can apply and the next moment you are on COBOL E. icon_neutral.gif

Agreed, cost is involved in migrations but then duh...
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Oct 18, 2011 4:50 pm
Reply with quote

Anuj,

I deal with 2 cobols, rexx, a little assembler, focus when I have to, java, and C
on the mainframe.
(not to speak of perl, groovy and a mess of other tin-can stuff)
I doubt that I am that unique.

it is sort of dealing with one of my girl-friends and their mothers.
i know instinctly how to act/what to do with each.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Tue Oct 18, 2011 6:27 pm
Reply with quote

We're drifiting a bit...icon_smile.gif.

Other thing is if we continue to support two differnt versions of COBOL compiler -- we can do that now, because we have some competent people around but how the younger generation will do that? They don't even understnd COBOL E, COBOL 2 is a distant dream and soon IBM will stop suporting it too (COBOL 2), wont he -- then what is next, after that?

I understand that's the way it had been but are there any benefits of being that way?

PS. No argument intentended, a pure discussion - my tone is simple and smooth when 'am asking this.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Tue Oct 18, 2011 8:07 pm
Reply with quote

Hello,

Quote:
every next release will backward-compitible,
As far as functionality, they will be close. Sometimes things are removed completely (i.e. EXAMINE). Sometimes undocumented "features" are removed. . .

Many have gotten an ugly surprise when they thought they would simply compile all of the "old code" with the new compiler.

When a new release of a compiler becomes available, the documentation includes a "changes" write-up.
Back to top
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India

PostPosted: Wed Oct 19, 2011 6:42 pm
Reply with quote

Thanks Dick. I'll stop here and will get back when my time permits and have more questions...
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts COBOL sorting, with input GDG base COBOL Programming 7
No new posts Need help with ADABAS query (COBOL-AD... All Other Mainframe Topics 0
No new posts Replacing FILLER with FILLER<SeqNu... DFSORT/ICETOOL 2
No new posts Error to invoke MPP program through B... IMS DB/DC 3
No new posts Compile Sp Cobol base COBOL Programming 1
Search our Forums:

Back to Top