[J3] Questions about dusty CDC 3400 deck

[Van Snyder]

Thanks to Dick for these explanations.
On Mon, 2024-03-25 at 07:44 -0500, Dick Hendrickson via J3 wrote:
> On Sun, Mar 24, 2024 at 3:31 PM Van Snyder via J3 <
> j3 at mailman.j3-fortran.org> wrote:
> > I'm trying to resurrect a CDC 3400 program.
> > 
> > It has weird stuff that is easy to repair, such as numeric common
> > block identifiers
> 
> Be careful with numeric common blocks. There was something odd about
> them. Possibly the way they interacted with the OVERLAY loader or
> maybe where they were placed in memory. Might have been harmless as
> they were placed in high memory so they "recovered “ the storage used
> be the linker/loader and ,thus, couldn’t be DATA initialized.
> Remember the CDC family didn’t have virtual memory and 32 thousand
> words was “big iron”

There wasn't any information about overlays or linking, so I assume the
program all fit in one lump. If I get it working, it will definitely
now fit in one lump. There are no BLOCK DATA subprograms.
> > the same labels for FORMAT and executable statements, references to
> > vendor-specific intrinsics such as TIMELEFT and SKIPFILE. and weird
> > but obvious IF statements such as IF(EOF,60) 1,2. There is a manual
> > online, but there's stuff it doesn't expalin.
> > The program changes a DO index. Does anybody remember whether that
> > changes the looping, or is that established when the DO statement
> > is executed?
> 
> I’m sure it changed the looping count. At least it would on
>  immediate predecessor the 1604. IIRC, the “iteration count “ was a
> FORTRAN 77 invention. 

This explains how to convert to an IF loop: I need only one variable.
> > It references a 2D array using one subscript (albeit only in a
> > PRINT statement). Does anybody remember which element that would
> > access? Would it be the one in array-element order?
> 
> Yes definitely tha array element order. A common extension when
> optimizers couldn’t optimize nested loops and memory was scarce

The only place the offending variable appears with one subscript is in
a PRINT statement, next to a rank-one variable dimensioned PO(101),
using the same subscript. The offending one is dimensioned P(2,101),
so it's almost surely a bug.
> Dick Hendrickson
> > Thanks,
> > Van
> > 
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20240325/d47417a7/attachment.htm>