Re: Cobol compiler date

> > A side note, while I think of it:  I had a heck of a time
> > getting a version of IFOX00 that would run on MVT.  Any
> > modern version will at some point exhibit an error in
> > which the location counter goes nuts and is suddenly
> > incremented by a very large amount, such that everything
> > becomes unaddressable.  
> 
> Are you sure you didn't just use mismatched
> source when building IFOX?

I didn't build it from source.  The version I initially tried
to use was the version that's built by MVS 3.8 stage 2 sysgen,
from distribution libraries taken from the TK3 MVS 3.8J DLIB volume.

> Could you document this properly please? ie
> provide an example of valid source that
> fails to assemble (provide the JCL to) on MVT,
> but the exact same source works on MVS?

Unfortunately I didn't collect test cases; I was focused on
getting something that worked out the door.  So I've been poking
around in my MVT source, seeing what would fail.  One thing I
found fairly quickly that would fail is a TSO command to display
user information.  It assembles correctly with the VM assembler
code.  With the MVS 3.8J level, the CSECT length is reported as
zero, with lots of errors like:

  164  IFO209      ADDRESSABILITY ERROR- BASE AND DISPLACEMENT CANNOT BE RESOLVED AND ARE SET TO 0
  165  IFO209      ADDRESSABILITY ERROR- BASE AND DISPLACEMENT CANNOT BE RESOLVED AND ARE SET TO 0
   ...
  910  IFO209      ADDRESSABILITY ERROR- BASE AND DISPLACEMENT CANNOT BE RESOLVED AND ARE SET TO 0
 1033  IFO172      VALUE OF ORG OPERAND IS LESS THAN THE CONTROL SECTION STARTING ADDRESS

Another program that fails with the MVS 3.8J assembler under MVT
is the TAPEMAP program.  Pages and pages of:

   64  IFO209      ADDRESSABILITY ERROR- BASE AND DISPLACEMENT CANNOT BE RESOLVED AND ARE SET TO 0
   71  IFO209      ADDRESSABILITY ERROR- BASE AND DISPLACEMENT CANNOT BE RESOLVED AND ARE SET TO 0
   76  IFO209      ADDRESSABILITY ERROR- BASE AND DISPLACEMENT CANNOT BE RESOLVED AND ARE SET TO 0

I looked at the instructions that were failing.  In the WHO command:

000058 0000 0000      00000         164          AH    R0,=H'19'           ADJUST 0C
         *** ERROR ***
00005C 0000 0000      00000         165          MH    R0,=H'100'           FOR 20TH CENTURY BASE
         *** ERROR ***

A whole bunch of failures on lines that referred to literals.  As an
experiment, I changed all the literals to constants.  The result:

000058 4A00 A5FC      005FC         164          AH    R0,H19           ADJUST 0C
00005C 4C00 A5FE      005FE         165          MH    R0,H100           FOR 20TH CENTURY BASE

assembled without error.

As a further experiment, I tried assembling both programs (with
literals unmodified) using the IFOX00 assembler version that's
included in the MVS 3.7 starter system.  Again, the result assembled
without error.

Comparing the maintentance levels of the MVS 3.8J and 3.7 assemblers
using IDR CSECT history data, I found several PTFs integrated into
the TK3 assembler.  Looking through PTF source I came across a PTF:

++ PTF (UZ56206)        /*    5752-SC103-EAS1102-SCP                   
//UZ56206  JOB 5752-56206-0,SC103,MSGLEVEL=(1,1),CLASS=A     */  .     
++ VER (Z038) FMID (EAS1102)                                           
   SUP (AZ42243,AZ46156,AZ52752,AZ54553,AZ59051,                       
        UZ31800,UZ31801,UZ36815,UZ37628)                               
 /*                                                                    
   PROBLEM DESCRIPTION(S):                                             
     OZ59051 - BASE AND DISPLCEMENT CANNOT BE RESOLVED FOR LITERAL OR  
               OTHER UNPREDICTABLE ERRORS                              
   COMPONENT:  5752-SC103-EAS1102                                      
   APARS FIXED:  OZ59051                                               
++ MOD (IFNX4M) DISTLIB(AOS03) 
++ MOD (IFNX4T) DISTLIB(AOS03) 

not installed on the 3.7 assembler, superseded by UZ81148 on the
TK3 assembler.  That sounds promising.  Maybe I can build a version
of the assembler with all the PTFs up to UZ56206 and see if it works,
then add UZ56206 and see if that breaks it.

> With a bit of luck someone will see a challenge
> in finding what's causing something to work in
> MVS but not MVT.

Maybe, but IFOX00 is unpleasant code.  Someone got carried away
with private macros.  It looks like something written by a CICS
macro level assembler programmer.

-- 
Kevin