cobol_IVAL.pl1

[h***@balcab.ch]

testing the multics sources with my pl1gcc project
the following error happens in a number of files.

How did the multics compiler handle this ?

eg.
ldd/unb/source/cobol_IVAL.pl1

cobol_IVAL.pl1

dcl cobol_ddalloc$b_to_d entry (fixed bin(15), ptr) returns(fixed bin(31));

%include cobol_IVAL;
%include cobol_type9;
%include cobol_ext_nonnum;
%include cobol_ext_num;
%include cobol_;
end cobol_IVAL;
<<<<<<<<<<<<<<

cobol_IVAL.incl.pl1

/* used by NTrtn for finding the data extensions */
1 parea ,
2 res bit(8),
2 reladdinseg bit(24),
2 numrep fixed bin(15),
2 lnval fixed bin(15),
2 value char(256),
1 temp static, /* work area for alligning initial values */
2 zeros char (18) initial ((18) "0"),/* must remain zeros, used as zero
fill for numeric literals */
2 work char (36) initial ((36) "0" ); /* work area for alligning initial
values */
/* END INCLUDE FILE ... cobol_IVAL.incl.pl1 */
<<<<<<<<<<<<<<

and the include file cobol_type9.incl.pl1, begins with
Note, include filename might have been chg to lowercase.

cobol_TYPE9.incl.pl1

/* begin include file ... cobol_TYPE9.incl.pl1 */
/* Last modified on 06/19/77 by ORN */
/* Last modified on 12/28/76 by FCH */

/* header */
2 size fixed bin,
2 line fixed bin,
2 column fixed bin,
<<<<<<<<<<<<<

Now, pl1gcc detects an error, since the '2 size fixed bin,'
is not preceed with a DCL of a level structure member.

How did the multics compiler handle this ?

thanks for your help
Henrik

[Peter Flass]

***@balcab.ch wrote:

I had a little trouble following the flow with the comments and such.
It sounds like the problem is the ';' at the end of cobol_IVAL.incl.pl1.

Post by h***@balcab.ch
1 temp static,

...

Post by h***@balcab.ch
2 work char (36) initial ((36) "0" ); <===

[followed by cobol_type9.incl.pl1]

Post by h***@balcab.ch
/* header */
2 size fixed bin,

...

So that without the ';' the structure flows along from one include file
to the other. Is this correct?

[h***@balcab.ch]

Post by Peter Flass
...

  2 work char (36) initial ((36) "0" ); <===

[followed by cobol_type9.incl.pl1]

  /* header */
  2 size fixed bin,

So that without the ';' the structure flows along from one include file
to the other.  Is this correct?

much better presentation of the problem ... thanks

well, removing the ';' would make the code compile, but I doubt the ';' got
inserted by accident.

Did the multics compiler simply use the 'previous' structure for the
declare ?

Henrik

[Paul Green]

testing the Multics sources with my pl1gcc project
the following error happens in a number of files.
eg. ldd/unb/source/cobol_IVAL.pl1

Post by h***@balcab.ch
cobol_IVAL.pl1

%include cobol_IVAL;
%include cobol_type9;
%include cobol_ext_nonnum;
%include cobol_ext_num;
%include cobol_;
end cobol_IVAL;
<<<<<<<<<<<<<<

Post by h***@balcab.ch
cobol_IVAL.incl.pl1

1 parea ,
2 res bit(8),
2 reladdinseg bit(24),
2 numrep fixed bin(15),
2 lnval fixed bin(15),
2 value char(256),
1 temp static,
2 zeros char (18) initial ((18) "0
2 work char (36) initial ((36) "0" );
<<<<<<<<<<<<<<
and the include file cobol_type9.incl.pl1, begins with
Note, include filename might have been chg to lowercase.

cobol_TYPE9.incl.pl1

2 size fixed bin,
2 line fixed bin,
2 column fixed bin,
<<<<<<<<<<<<<
Now, pl1gcc detects an error, since the '2 size fixed bin,'
is not preceed with a DCL of a level structure member.
How did the multics compiler handle this ?

Hello Henrik,

Your hunch is correct that the discrepancy between the way the Multics PL/I
compiler handled the compilation and your compiler is due to the case of the
identifier "cobol_TYPE9.incl.pl1".

There are two similarly-named include files:

cobol_TYPE9.incl.pl1
cobol_type9.incl.pl1

Since Multics has a case-preserving, case-sensitive file system, these two
file names can co-exist in the same directory and they are distinct.

Take a look at the listing file for the compilation of cobol_IVAL.pl1 and
you can see how this worked on Multics:
]
http://web.mit.edu/multics-history/source/ldd_listings/unb_2/cobol_IVAL.list

Here is the hierarchy of source files:

cobol_IVAL.pl1
cobol_IVAL.incl.pl1
cobol_type9.incl.pl1
cobol_TYPE9.incl.pl1
cobol_ext_nonnum.incl.pl1
cobol_ext_num.incl.pl1
cobol_.incl.pl1

The Multics PL/I compiler produces a handy table showing all of the include
files encountered, and lists them in the order that they were encountered.
Here is the table for cobol_IVAL.pl1.

LINE NUMBER DATE MODIFIED NAME PATHNAME
0 05/24/89 0833.1 cobol_IVAL.pl1

spec>install>MR12.3-1048>cobol_IVAL.pl1

253 1 03/27/82 0439.6 cobol_IVAL.incl.pl1

ldd>include>cobol_IVAL.incl.pl1

254 2 03/27/82 0439.9 cobol_type9.incl.pl1

ldd>include>cobol_type9.incl.pl1

2-17 3 11/11/82 1712.7 cobol_TYPE9.incl.pl1

ldd>include>cobol_TYPE9.incl.pl1

255 4 03/27/82 0439.7 cobol_ext_nonnum.incl.pl1

ldd>include>cobol_ext_nonnum.incl.pl1

256 5 03/27/82 0439.7 cobol_ext_num.incl.pl1

ldd>include>cobol_ext_num.incl.pl1

257 6 11/11/82 1712.7 cobol_.incl.pl1

ldd>include>cobol_.incl.pl1Hope this helps.

PG

[h***@balcab.ch]

cobol_TYPE9.incl.pl1
cobol_type9.incl.pl1

aha !

Thanks for pointing this out.

This certaintly explains a lot of compilation errors I see :-)

Is there any easy way to extract all the cobol_*.incl.pl1 files ?

thanks for your help
Henrik

[Paul Green]

Post by h***@balcab.ch

cobol_TYPE9.incl.pl1
cobol_type9.incl.pl1

aha !
Thanks for pointing this out.
This certaintly explains a lot of compilation errors I see :-)
Is there any easy way to extract all the cobol_*.incl.pl1 files ?

I suggest you start by porting the Multics archive command to an operating
system that has a case-sensitive, case-preserving file system. In other
words, avoid Windows, which has a case-insensitive, case-preserving file
system.

The archive command is located in "System Library Standard", which is on the
web at (watch out for the line-wrap):

http://web.mit.edu/multics-history/source/Multics_Internet_Server/Multics_ldd_system_library_standard_source.html

You can then download the Multics source code archive and extract it on your
host system.

Of course, if you are fluent in C or Perl or a similar language, then you
could just write a short program to extract the files. The format is pretty
simple. I leave this as an exercise for the reader.

PG

P.S. In case someone is reading this message and wonders how to find the
Multics source code, the short cut is http://web.mit.edu/multics.

[Barry Margolin]

cobol_TYPE9.incl.pl1
cobol_type9.incl.pl1
Since Multics has a case-preserving, case-sensitive file system, these two
file names can co-exist in the same directory and they are distinct.

Even on a case-sensitive system, I think naming files like this was an
incredibly horrible idea. Although it worked, it's certainly going to
cause confusion.

Similarly, the PL/I compiler was case-sensitive for variable names, but
I would never write a program that used variables that differed only in
case.