Fortran (f80) on CP/M 2.2 - 'CALL OPEN' does not work

[sunnyboy010101]

I am having a problem with trying to use 'call open' on Microsoft FORTRAN (f80) for the Z80 CPU running under CP/M 2.2.

The version of FORTRAN is 3.1 (I beleive... it doesn't actually say when you compile). Link (L80) that came in the same bundle says 'Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft' if that helps.

According to the FORTRAN manuals, I should be able to open a file by name for CP/M using

CALL OPEN(10,'TEST.OUT ')


I get no compile or link error, but when I run the program I get the error:

'Bdos Err On Z: Select'

There is no Z disk. I have disks A,B,C,D, and am compiling/running from C. However, if I copy everything to A: I get the same error.

Most instructions say to pad the file name to 11 characters with blanks. Note that it doesn't work whether I do or not.

IF I comment out the open (above), then it outputs to FORT10.DAT as expected, so there is not problem with the rest of the program, nor with the write statements etc. Just the "CALL OPEN".

I found alternate instructions that say

CALL OPEN(10,'TEST.OUT ',0)

but that does not compile. (the 0 is supposed to be the drive where '0' means 'current drive').

Has anyone had 'GET OPEN' working with a FORTRAN program on CP/M and can point me in the right direction as to fixing this?

Thanks,
-Richard

[Tony Nicholson]

You can confirm the version easily by getting a listing file (to the console) - e.g.

A>f80 ,tty:=tty:
FORTRAN-80 Ver. 3.4 Copyright 1978, 79, 80 (C) By Microsoft -- Bytes: 35527
Created: 21-Nov-80
(type CTRL-Z to obtain the '*' prompt, then CTRL-C to exit to CP/M)


Try

CALL OPEN(10,'TEST OUT',0)

i.e. Concatenate the 8 character filename and 3 character file type to make an 11 character hollerith constant (do not include the '.').

From the Microsoft FORTRAN-80 Users Manual, page 12

"..
The format of an OPEN call under CP/M is:
CALL OPEN (LUN, Filename, Drive)
where:
LUN = a Logical Unit Number to be associated with
the file (must be an Integer constant or Integer
variable with a value between 1 and 10).
Filename = an ASCII name which the operating system
will associate with the file. The Filename should
be a Hollerith or Literal constant, or a variable
or array name, where the variable or array contains
the ASCII name. The Filename should be
blank-filled to exactly eleven characters.
Drive = the number of the disk drive on which the
file exists or will exists (must be an Integer
constant or Integer variable within the range
allowed by the operating system). If the Drive
specified is 0, the currently selected drive is
assume~; 1 is drive A, 2 is drive B, etc."

Tony

[sunnyboy010101]

...
>
> Tony

Thanks Tony! That did indeed do the trick!

Here's my session and program plus the working output. I have that very manual and read that bit several times, but I never would have figured out to try 'TEST OUT' (especially without the '.').

C>f80 ,tty:=tty:
FORTRAN-80 Ver. 3.44 Copyright 1978-1981 (C) By Microsoft -- Bytes: 33350
Created: 10-Dec-81

^C
C>
C>a:pcget filetst.for
Send the file now using XMODEM...

Transfer Complete

C>f80 =filetst
MAIN

C>l80 filetst,filetst/n/e

Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft

Data 0103 1ABD < 6586>

41366 Bytes Free
[0136 1ABD 26]

C>filetst
STOP

C>type filetst.for
program main

call open(10,'TEST OUT',0)

write(10,1000)
1000 format(1h ,' Test program for file opening ')

stop
end

C>type test.out
Test program for file opening
C>

Thanks again!
-Richard

[sunnyboy010101]

Oh, one more thing...

Don't use lowercase for the filename (i.e. CALL OPEN(10,'test out',0) or else one will be using NSWP to delete it! (ask me how I know...) :-)

-R

[Tony Nicholson]

That is a flaw (or feature) to protect files from an ERA command! It's in
Microsoft MBASIC and OBASIC too. One of the first things I wrote when I
upgraded to CP/M-Plus in the 1980s was an RSX to intercept file open
and directory serach BDOS calls to upper-case the file names in the file
control block.

Also, remember to close files in your FORTRAN-80 source with an

ENDFILE 10

A STOP statement takes care of this too - but if the program exits prematurely
you could lose that last written buffer from a file.

Tony

[sunnyboy010101]

Thanks Tony. I am using a STOP at the appropriate place.

I have one more question that I feel I should know or be able to find out, but it's got me stumped.

If I use LUN 3 (console), then linefeeds show up in my output without problem.

(i.e.

write(3,100)
100 format(1h ,'line1',//,'line2')

BUT - if I use LUN 10 as in my previous posts and use CALL OPEN to send it to a file, the output is all on one line - basically the '//' is ignored.

I know it's because LUN 10 is not considered a 'printer' (or other formatted output stream) but I can't figure out (nor can I find) a way to make it one, so that the '//' is again honored.

-R

[sunnyboy010101]

I think I have just answered my own question. From the FORTRAN manual, page 58 & 83 (section 8), LUN 2 is the line printer, while 1,3,4,5 are console teletype. Only the teletype and line printer recognize carriage control. So output to lun 10 (a file) needs explicit X'0A' linefeeds.

Since I don't want to rewrite these old programs, I've switched the output from LUN 10 to LUN 2. Testing now...

[sunnyboy010101]

Quick update: Nope. LUN 2 also ignores the linefeeds in the format statement.

[Tony Nicholson]

On Monday, February 10, 2020 at 1:51:23 PM UTC+11, sunnyboy010101 wrote:

[snip]

> Thanks Tony. I am using a STOP at the appropriate place.
>
> I have one more question that I feel I should know or be able to find out, but it's got me stumped.
>
> If I use LUN 3 (console), then linefeeds show up in my output without problem.
>
> (i.e.
>
> write(3,100)
> 100 format(1h ,'line1',//,'line2')
>
> BUT - if I use LUN 10 as in my previous posts and use CALL OPEN to send it to a file, the output is all on one line - basically the '//' is ignored.
>
> I know it's because LUN 10 is not considered a 'printer' (or other formatted output stream) but I can't figure out (nor can I find) a way to make it one, so that the '//' is again honored.
>
> -R

Formatted I/O in FORTRAN-80 requires an explicit line-feed character to be
output if you need it in a file. I think line-feed characters are ignored
on input (and you don't have to type them when you enter a line from the
console).

Tony

A>F80 T,TTY:/N=T
A:F80 COM

FORTRAN-80 Ver. 3.44 Copyright 1978-1981 (C) By Microsoft -- Bytes: 33350
Created: 10-Dec-81

1 program test
2 integer*1 lf
3 lf = x'0a'
4 call open(10,'T DAT',0)
5 write (10,5010) lf
6 5010 format(1X,'First line',/,A1,1X,'Second line')
7 endfile 10
8 stop
9 end

Program Unit Length=0049 (73) Bytes
Data Area Length=0034 (52) Bytes

Subroutines Referenced:

$I2 $INIT OPEN
$W2 $ND $EN
$ST

Variables:

LF 0001" H:0001 0002"

Labels:

$$L 0006' 5010L 000D"


A>L80 T/E,A:FORLIB/S,T/N
A:L80 COM

Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft

Data 0103 1ACD < 6602>

FORLIB RQUEST
43419 Bytes Free
[0137 1ACD 26]

A>t
A:T COM
STOP

A>dump t.dat
A:DUMP COM


CP/M 3 DUMP - Version 3.0
0000: 20 46 69 72 73 74 20 6C 69 6E 65 0D 0A 20 53 65 First line.. Se
0010: 63 6F 6E 64 20 6C 69 6E 65 0D 1A 00 00 00 00 00 cond line.......
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
A>

[sunnyboy010101]

Tony,

Again, thanks very much. I tried your program (below) and it does work fine. Interestingly, you can't just put 1HX'0A' in the format statement - you must use A1 with the integer*1 'lf' variable. (it prints '0A' in the file instead of a linefeed). Also, the '/' before the linefeed seems necessary as well.

All very complicated relative to converting an old program to write to a file instead of the console.

Cheers,
-Richard

[Tony Nicholson]

On Tuesday, February 11, 2020 at 5:21:11 AM UTC+11, sunnyboy010101 wrote:
> Tony,
>
> Again, thanks very much. I tried your program (below) and it does work fine. Interestingly, you can't just put 1HX'0A' in the format statement - you must use A1 with the integer*1 'lf' variable. (it prints '0A' in the file instead of a linefeed). Also, the '/' before the linefeed seems necessary as well.
>
> All very complicated relative to converting an old program to write to a file instead of the console.

That's the way it is.

There's many quirks in porting FORTRAN programs (and I've done my fair share
of porting programs - from CDC-3500 FORTRAN or something like the DEC PDP-10
range where a character is packed into a word that's not a multiple of eight
bits are the "most fun").

You might have seen the "1X" in the FORMAT statement at the beginning of a
record is my sample program. This was supposed to be the "advance one line"
carriage control in most vintage FORTRANs. Microsoft messed this up - but my
old habits won't die!

Tony

[dxforth]

On Tuesday, February 11, 2020 at 10:01:20 AM UTC+11, Tony Nicholson wrote:
> On Tuesday, February 11, 2020 at 5:21:11 AM UTC+11, sunnyboy010101 wrote:

> > ...

> > All very complicated relative to converting an old program to write to a file instead of the console.
>
> That's the way it is.

Also the way it is in Forth which makes no attempt to hide the difference
between console and disk. Each language tends to have its own solutions.

[sunnyboy010101]

Indeed. I started out with CDC Cyber FORTRAN as well. The worst job ever was porting that to Honeywell Multics FORTRAN simply because the maximum word size (and thus double-precision size) was half the CDC. We had tons of engineering programs that simply could not converge to a solution after the conversion.

I found the best solution for these programs (originally written on Honeywell Multics FORTRAN by coincidence) was to route the output to LUN 3 (console TTY). That LUN seems the best at honoring the old FORTRAN format statements.

I am able to use CALL OPEN for my data files though, which is very nice.

I recently installed DR PL/I on my Z80 / CM/M 2.2 machine, and have been having tons of fun converting the same FORTRAN programs to run under PL/I. The only significant difference is that file open works well, and formatting output is much nicer under PL/I.

-R