Re: Cobol compiler date

> kerravon86 wrote:

> > halfmeg wrote:

> > One of my future goals is to not include anything in 
> > TK that we don't have source for reproducing the 
> > shipped executables, but that has to wait for another 
> > TK version.

> Including MVS itself, or making MVS an exception?

There will be exceptions such as KICKS ( if ever included due to license issue ) or IMON ( Object Code Only commercial product licensed for use on TK ) and others.

I was referring to the general stuff we add to the 3.8j base system, not MVS itself.  One of the things which 'sensitized' me to wanting the source for things installed was KLINGON and SUPRTREK.  Load modules were brought in from the CBT Tape easy install load module file.  The only problem is they had been compiled with compilers which we don't have the run time for so didn't work.  KLINGON works after re-compiling with the compiler installed in TK3.  SUPRTREK source had been (?) modified so that our FORTRAN version chokes on 140+ errors which can be fixed as they are all the same type thing.  From another post where the problem is detailed a little:

""The source of SUPRTREK that needs fixing is in CBT249.FILE038 .
All the "READ(5,*" statements need a format label with valid format
statement instead of that * which if for a later version of Fortran
than H."

Later FORTRAN compiler accept the * and determine a length. Our FORTRAN version
needs a specific label of x length there which varies from place to place
depending upon the variable being compared to after the read. I believe a
proper fix involves adding a FORMAT statement for each * needed in each
subroutine. Think there were 140 or so errors of this type. Multiples might be
taken care of by one FORMAT in a particular subroutine."

><snip>

Stuff like the COBOL compiler and RUN time library were copied from the OS360/MFT DLIBs.  So that means the source we have for them may not match the actual load modules and object modules we are using in 3.8j.

Same goes for the ALGOL, PL/I, RPG and FORTRAN compilers and their runtime libraries.

The cosmetic 'fix' for the COBOL date was another 'exercise' for me to refresh myself with 'stuff' again after a long absence.  Only this week have I gotten my system back to proper working condition.

IIRC the search for the '19' began with discounting the COBLIB as possibly containing something which only shows up during the compile.  A test compile gave me the header line.  From it I 'grepped' the COBOL source looking for 'CB545', not found.  Using REVIEW looked at the COBOL load modules and found at least one without source, IKFCBL01 ( actually does have source but not named IKFCBL01 and in a totally unexpected location ).  Searched for 'CB545' again, found it, searched for '19', found it and a date formatted similar to the COBOL header line output.  ZAPped the 19 to a 20, tested and posted.  It wasn't rocket science by any means.

Phil