|
View previous topic :: View next topic
|
| Author |
Message |
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
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 |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
yes.. quite often in my experience
usually needed when making local changes or corrections to third party software packages |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
Thanks Enrico and Marso - this helps...
So, that means - they keep a copy of older compiler as well in some "private-libraries", do they? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
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  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| 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 |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| 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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| 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 |
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..).
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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
Thanks Dick...
| 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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
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. 
Agreed, cost is involved in migrations but then duh... |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
We're drifiting a bit....
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Thanks Dick. I'll stop here and will get back when my time permits and have more questions... |
|
| Back to top |
|
|
|
|
