Simple COBOL question

[Bill Gunshannon]

In a discussion in another group the limits of compilers came up.
Apparently IBM COBOL can do up to 999,999 lines of code in a source
file. What is the limit for Unisys COBOL?

Thanks.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Paul Kimpel]

Bill Gunshannon wrote:
> In a discussion in another group the limits of compilers came up.
> Apparently IBM COBOL can do up to 999,999 lines of code in a source
> file. What is the limit for Unisys COBOL?
>
> Thanks.
>
> bill
>

Which Unisys COBOL are you interested in? MCP or OS2200? COBOL-74 or
-85? Those are all very different implementations.

With respect to COBOL-85 for the MCP systems, I'm not aware there is an
explicit limit based on number of lines of source, but you would have a
difficult time editing a file larger than 999,999 lines using standard
MCP tools, as COBOL has only a six-digit sequence number field.

There are limits, of course, but I suspect they would be in the area of
symbol table size or addressing within the generated object code, and
those would depend more on how the program was written, the mix of data
and procedure division statements, etc., than on LOC.

The largest MCP COBOL program I've ever seen was well over 100,000
lines, and that was more than 20 years ago. It did not come close to any
limits that I'm aware of.

I'm trying to visualize a line-printer listing for a program with
999,999 lines. Assuming 60 lines per inch and 16 lb paper, that would
require about 6.5 boxes of greenbar, so the listing would be over six
feet thick. Oof.

--
Paul

[Marc Wilson]

In comp.sys.unisys, (Bill Gunshannon) wrote in
<aqrclr...@mid.individual.net>::

>In a discussion in another group the limits of compilers came up.
>Apparently IBM COBOL can do up to 999,999 lines of code in a source
>file. What is the limit for Unisys COBOL?

*which* Unisys COBOL? If it's UCOB, I suspect the limits are "More than
any sane person would consider putting in a single program."

What *might* be an issue is the number of records possible in an SDF
element or file.

I do recall debugging an ACOB compilation that went wrong, once, because
the symbol table was too full, but I believe UCOB removed most of the
earlier limits.
--
Marc Wilson

Cleopatra Consultants Limited - IT Consultants
Fernrhoyd, Chester Road, Alpraham, Tarporley, Cheshire CW6 9JE
Tel: (44/0) 1829 262696 Tel: (44/0) 161 408 6449
Fax: (44/0) 844 779 0968 Mobile: (44/0) 7973 359850
Skype: cleo-marc Mail: enqu...@cleopatra.co.uk
Web: http://www.cleopatra.co.uk
Registered in England and Wales no: 2588943 VAT Reg: 561 1182 69
Registered office: St George's House, 215-219 Chester Road
Manchester M15 4JE

https://plus.google.com/100816173414569062406
_________________________________________________________________
Try MailTraq at https://my.mailtraq.com/register.asp?code=cleopatra

[Kurt Duncan]

On Mar 19, 1:11 pm, Marc Wilson <m...@cleopatra.co.uk> wrote:
> In comp.sys.unisys,  (Bill Gunshannon) wrote in

> <aqrclrF12m...@mid.individual.net>::

>
> >In a discussion in another group the limits of compilers came up.
> >Apparently IBM COBOL can do up to 999,999 lines of code in a source
> >file.  What is the limit for Unisys COBOL?
>
> *which* Unisys COBOL?  If it's UCOB, I suspect the limits are "More than
> any sane person would consider putting in a single program."
>
> What *might* be an issue is the number of records possible in an SDF
> element or file.
>
> I do recall debugging an ACOB compilation that went wrong, once, because
> the symbol table was too full, but I believe UCOB removed most of the
> earlier limits.
> --
> Marc Wilson

There might be some issue with large, but smaller than maximum source
elements/files in the following cases:
1) large source file, and large change image sets
2) large source file, including many large copy procs

In either case, the individual source elements might be reasonably-
sized, but the resulting output (or lines processed, either one) could
be limit-tipping...
With Ascii Cobol, you're going to hit a relocatable output limit
before an input source limit, in all likelihood.
UCS Cobol... I've never used, so cannot say.

[andrew....@t-online.de]

Ascii Cobol will probably hit the I-Bank upper address limit first unless you are prepared to start segmenting the program - if that still works. Around 30 years ago on a conversion project, someone combined something like 17 subroutines into one massive program which he then could not get through the compiler. After working 48 hours non-stop on this he left the project. I got given the mess and ended up backing out all of his changes and reverting to the original 17 subroutines. It took me a day or so to work out how to handle multi-ibanks but that was pretty much all that was needed.

UCS Cobol can handle 'very big', I have had to convert programs from ACOB to UCOB because of addressing limits.

Why would anyone want to write a monolithic program that large anyway? It seems like a horrible idea.

[Paul Kimpel]

Andrew has an excellent point in his last comment.

My experience is that once the source for a COBOL program gets beyond
about 10K lines, it starts to become unwieldy. The only places I have
seen programs significantly larger than that are on-line transaction
handlers and the output of COBOL macro source generators such as PROGENI
and XGEN. Usually it's a combination of on-line programs and source
generators.

That 100K+ program I mentioned a few posts ago was a monetary
transaction handler for a financial system. It was the product of a
PROGENI expansion, coming from a 44K base source. I had to convert that
sucker from V Series to A Series about 20 years ago, and it was not fun.

A third case of large programs would be massive use of the COBOL COPY
statement, where the size of the base source might be quite manageable,
but the effective size, in terms of lines compiled, is very large.

I think the reason for these very large source programs is primarily
historical, at least on the Burroughs side of the house. We have had a
tradition of relatively fast compilers that would (a) more or less
automatically segment the compiled code and (b) produce object files
that were ready to run -- no separate link-editing step or merging with
external libraries was necessary. In fact, the B5500 and Medium Systems
didn't even have a link editor. The Large Systems and later have had a
Program Binder from the beginning, but my experience has been that it
has never been used that much, except possibly with FORTRAN and C.

Thus, sort of by default, the only forms of program abstraction in the
legacy Burroughs environments tended to be large source files and
lexical binding methods such as COPY statements (which eventually led to
the use of macro generators as a better form of COPY). That has changed
somewhat since the advent of dynamically-bound libraries around 1980,
but that tradition of large source files and compile-time source
inclusion is still very much with us.

I would guess that older on-line programs tend to be large because (a)
the early datacom environments had limitations on how many programs
could be supported (sometimes only one, as the earliest programs talked
to the datacom interfaces directly), and (b) on-line applications tend
to grow like topsy, with no single enhancement seemingly justifying a
refactoring of the code. As a result, the module just keeps growing
until it reaches a size where it's Too Big to Refactor. I know that's
what happened with that 100K monster I had to deal with.

--
Paul

[Scott Lurndal]

Paul Kimpel <paul....@digm.com> writes:

>andrew....@t-online.de wrote:

>That 100K+ program I mentioned a few posts ago was a monetary
>transaction handler for a financial system. It was the product of a
>PROGENI expansion, coming from a 44K base source. I had to convert that
>sucker from V Series to A Series about 20 years ago, and it was not fun.

From COBOL9? Or COBOL-74? V-Series cobol9 programs sometimes used
ENTER SYMBOLIC to embed assembler into the cobol code - that I could
well believe was problematic to port to A-series. Was this before
or after EVA?

>I think the reason for these very large source programs is primarily
>historical, at least on the Burroughs side of the house. We have had a
>tradition of relatively fast compilers that would (a) more or less
>automatically segment the compiled code and (b) produce object files
>that were ready to run -- no separate link-editing step or merging with
>external libraries was necessary. In fact, the B5500 and Medium Systems
>didn't even have a link editor.

By the late 70's, medium systems had the BINDER, which was used to
bind BPL subroutines into COBOL/Fortran/Pascal codefiles. By
the mid-80's we had LINKER as well to produce Omega codefiles.


scott

[Paul Kimpel]

Scott Lurndal wrote:

> Paul Kimpel <paul....@digm.com> writes:
>
>> That 100K+ program I mentioned a few posts ago was a monetary
>> transaction handler for a financial system. It was the product of a
>> PROGENI expansion, coming from a 44K base source. I had to convert that
>> sucker from V Series to A Series about 20 years ago, and it was not fun.
>
> From COBOL9? Or COBOL-74? V-Series cobol9 programs sometimes used
> ENTER SYMBOLIC to embed assembler into the cobol code - that I could
> well believe was problematic to port to A-series. Was this before
> or after EVA?

This was 1990-1991. I think the customer was still using a couple of
B3900s. As I recall, the app was a mix of COBOL-74 and an older
compiler, which I think was used only in core parts of the on-line
infrastructure. There was a little bit of ENTER SYMBOLIC, but not much.
EVA did not come along until towards the end of the project, so we
didn't use it.

As I recall, the big problems in the conversion (aside from the size of
some of the programs and many fine examples of '60s spaghetti code) were
the Core-to-Core and STOQUE IPC mechanisms, the ZIP-like tasking
mechanism (and the way you could monitor and control completely
independent tasks from any other task on V Series), digit program
switches (they are binary on A Series), and the (expletive deleted)
six-character file names. The data flow through the on-line system was a
mess, so another big problem was figuring out how to take the
combination of the SWITCH DCH interface, tasking, and data flow, and
torquing that into something that A Series COMS could handle.

Another challenge was that we couldn't just convert the system and have
an A Series application. The vendor was still maintaining the V Series
application and releasing new versions on a yearly basis, so we had to
do the conversion so that we could port the updates to A Series as well.
As a result, the A Series version had to retain a lot of its V Series
character.

I ended up writing a DCAlgol library that implemented much of the
capability of Core-to-Core and STOQUE. As I recall, it supported
everything except complex wait. This was before those mechanisms were
available on A Series (which were eventually available only in COBOL-85,
and since we were using -74, couldn't use them anyway). That library
also implemented a tasking mechanism that emulated enough of what the V
Series version was doing with ZIPs and mix interrogation to make it work
using the A Series PROCESS mechanism. The use of PROGENI helped, as we
were able to hide a lot of interface changes behind existing macros.

We actually got this mess to work, and work quite well. It ran initially
on an A6, which the customer later upgraded to an A11. The A Series
version ran for several years until my customer's relationship with the
vendor soured, eventually collapsing into lawsuits that had nothing to
do with the technical merits of either the V or A Series versions of the
app, and everything to do with halfwits in suits.

>
>> I think the reason for these very large source programs is primarily
>> historical, at least on the Burroughs side of the house. We have had a
>> tradition of relatively fast compilers that would (a) more or less
>> automatically segment the compiled code and (b) produce object files
>> that were ready to run -- no separate link-editing step or merging with
>> external libraries was necessary. In fact, the B5500 and Medium Systems
>> didn't even have a link editor.
>
> By the late 70's, medium systems had the BINDER, which was used to
> bind BPL subroutines into COBOL/Fortran/Pascal codefiles. By
> the mid-80's we had LINKER as well to produce Omega codefiles.
>

I knew that V Series eventually had some sort of linking capability, and
dynamically-bound libraries, but as I understand it, BINDER could not
link COBOL-to-COBOL, which is the case that is relevant to this thread.
In any case, the point I was trying to make was that by the time in the
early '80s that more modern program abstraction facilities began to
penetrate the consciousness of developers in the Burroughs environment,
the architecture of most apps was pretty well set, and in most cases,
not going to change.

--
Paul

[Scott Lurndal]

Paul Kimpel <paul....@digm.com> writes:
>Scott Lurndal wrote:
>> Paul Kimpel <paul....@digm.com> writes:
>>
>>> That 100K+ program I mentioned a few posts ago was a monetary
>>> transaction handler for a financial system. It was the product of a
>>> PROGENI expansion, coming from a 44K base source. I had to convert that
>>> sucker from V Series to A Series about 20 years ago, and it was not fun.
>>
>> From COBOL9? Or COBOL-74? V-Series cobol9 programs sometimes used
>> ENTER SYMBOLIC to embed assembler into the cobol code - that I could
>> well believe was problematic to port to A-series. Was this before
>> or after EVA?
>
>This was 1990-1991. I think the customer was still using a couple of
>B3900s.

I visited a customer a couple of years ago that was decomissioning a
V340 (2010). They ended up replacing it with 24 windows boxes. The
V340 had been powered off for the last two years, recently one of the
FE's tried to bring it back up, but no dice. Need to swap around
some cards, I think.

> As I recall, the app was a mix of COBOL-74 and an older
>compiler,

That would be COBOL9, the only compiler that supported ENTER SYMBOLIC.

>which I think was used only in core parts of the on-line
>infrastructure. There was a little bit of ENTER SYMBOLIC, but not much.
>EVA did not come along until towards the end of the project, so we
>didn't use it.
>
>As I recall, the big problems in the conversion (aside from the size of
>some of the programs and many fine examples of '60s spaghetti code) were
>the Core-to-Core and STOQUE IPC mechanisms, the ZIP-like tasking

Ah yes, C2C and STOQUE. Nice innovative IPC features, for the time.
STOQUE-style publish/subscribe interfaces still exist in modern transaction processing
subsystems like tuxedo & heirs.

>mechanism (and the way you could monitor and control completely
>independent tasks from any other task on V Series), digit program
>switches (they are binary on A Series), and the (expletive deleted)
>six-character file names.

Weren't particularly popular at the time, either, but a remnant
of small address space systems (until 1984, the V-series
were limited to 150kbytes of OS code, part of which was an overlay
area for MCP overlays). All kinds of tricks were invented in the 70's
to ameliorate this limit (e.g. an overlay pool so a memory-to-memory
copy was used instead of a disk I/O to load a frequently used overlay).

With Omega architecture (MCP/VS 2.0) in 1984, the OS size was basically unlimited.

It would have been quite, hmm difficult, to expand the file name
without a completely new MCP API (which we were set to do with the
hypercall interface that replaced BCT's in Omega) which was OBE.

>The data flow through the on-line system was a
>mess, so another big problem was figuring out how to take the
>combination of the SWITCH DCH interface, tasking, and data flow, and
>torquing that into something that A Series COMS could handle.

SWITCH. A mag-tape DLP talking to an HP-2000 line processor (CP3680).
I much preferred the B974 myself, but we used B874's in Pasadena for all
the engineers TD830's.

[snip]

>We actually got this mess to work, and work quite well. It ran initially
>on an A6, which the customer later upgraded to an A11. The A Series
>version ran for several years until my customer's relationship with the
>vendor soured, eventually collapsing into lawsuits that had nothing to
>do with the technical merits of either the V or A Series versions of the
>app, and everything to do with halfwits in suits.

As usual :-)

>>
>>> I think the reason for these very large source programs is primarily
>>> historical, at least on the Burroughs side of the house. We have had a
>>> tradition of relatively fast compilers that would (a) more or less
>>> automatically segment the compiled code and (b) produce object files
>>> that were ready to run -- no separate link-editing step or merging with
>>> external libraries was necessary. In fact, the B5500 and Medium Systems
>>> didn't even have a link editor.
>>
>> By the late 70's, medium systems had the BINDER, which was used to
>> bind BPL subroutines into COBOL/Fortran/Pascal codefiles. By
>> the mid-80's we had LINKER as well to produce Omega codefiles.
>>
>I knew that V Series eventually had some sort of linking capability, and
>dynamically-bound libraries, but as I understand it, BINDER could not
>link COBOL-to-COBOL, which is the case that is relevant to this thread.

I'm pretty sure that you could bind cobol to cobol, at least by the
early 90's with the COBOL-74, and probably COBOL-85 compilers.

From the BINDER Prog Ref:
<blockquote>
Three kinds of ICMs can be created with COBOL:

� The first kind of ICM is created from the main program and contains
the program entry pointor first executable code.

� The second kind is created from a source that contains only
sections that are referenced with the CALL MODULE statement. This
kind of ICM is created by specifying $RESET MAIN.

� The third kind is created from a source that contains only code
that is referenced with the IPC mechanism. This kind of ICM is
created by specifying $RESET MAIN and $RESET LEV2IPC. If $RESET
LEV2IPC is used in one module, it must be used in all modules used
to create a single program.

To save an ICM created by the COBOL ANSI-74 compiler, the $ICM option
must be set, naming the ICM to be saved. The module-name for a COBOL ICM
is the name in the PROGRAM-ID paragraph

Any reference between modules must be done with either the CALL MODULE
statement or the IPC CALL statement. A PERFORM or GO TO statement cannot
refer to a paragraph or section that is not part of the same ICM. Any
data blocks that are to be shared between modules must be declared in
identical 01-level items and must use the COMMON clause. The IPC
mechanism can be used for parameter passing.
</blockquote>

>In any case, the point I was trying to make was that by the time in the
>early '80s that more modern program abstraction facilities began to
>penetrate the consciousness of developers in the Burroughs environment,
>the architecture of most apps was pretty well set, and in most cases,
>not going to change.

Now that's truth. Much work went into Omega to ensure that codefiles
from the B3500-B4800 systems would still run unmodified.

scott

[Crash McBash]

On Fri, 29 Mar 2013 06:56:46 -0700, Paul Kimpel <paul....@digm.com>
wrote:

A little OT but this reminds me of a project launched to look at the
options available to (FISERV(?) (sp?)) - a major V Series customer.
This would have been about 1991 - Jim Unruh was CEO, end-of-life for V
Series was to be announced in a few months and I was wondering if
Unisys could afford the weekly hotel bills (IIRC stock price sank to
$1.75 during this project!). This project was tasked with evaluating
how to move the customer's applications to A Series and one of the
considerations was to redevelop in LINC running on V - because LINC
was largely source-code-compatible across all MCP platforms.

Ultimately redevelopment in LINC was deemed too risky/costly with not
enough non-migration benefits. I believe the non-LINC output from
this project formed the basis of EVA design but I could be wrong here
- certainly EVA came much later.
--
Crash McBash

[Ken Wheatley]

On 2013-03-29 14:41:09 +0000, Scott Lurndal said:

>
>
>> As I recall, the app was a mix of COBOL-74 and an older
>> compiler,
>
> That would be COBOL9, the only compiler that supported ENTER SYMBOLIC.
>

My involvement with Medioum Systems COBOL was a long time about but I
don'r remember a Cobol9. There was COBOLL and COBOLV. My memory may be
faulty but I thought COBOL in those days supported ENTER SYMBOLIC and I
think these were the only COBOL compilers in town for MS.

Not sure if both supported ENTER SYMBOLIC but I thought the copilers
were identical apart from certain limits.

[Scott Lurndal]

Ken Wheatley <k...@birchanger.com> writes:
>On 2013-03-29 14:41:09 +0000, Scott Lurndal said:
>
>>
>>
>>> As I recall, the app was a mix of COBOL-74 and an older
>>> compiler,
>>
>> That would be COBOL9, the only compiler that supported ENTER SYMBOLIC.
>>
>
>My involvement with Medioum Systems COBOL was a long time about but I
>don'r remember a Cobol9. There was COBOLL and COBOLV. My memory may be
>faulty but I thought COBOL in those days supported ENTER SYMBOLIC and I
>think these were the only COBOL compilers in town for MS.

Yes, I meant COBOLV (the Cobol-68 compiler). When COBOL-74 came along,
ENTER SYMBOLIC was not supported.

>
>Not sure if both supported ENTER SYMBOLIC but I thought the copilers
>were identical apart from certain limits.

By 1980, COBOLL was no longer available.

There were three compilers available at the end-of-life, COBOLV, the
COBOL-74 compiler and the COBOL-85 compiler. Here's COBOLV and COBOL-74:

==> RY 6/0
06/0 GCR (6250) CBV702/TAPDIR U RL# 001 03/03/10 PT# 10066
==> DIR = ON CBV702(TAPE)
BOJ SYSTEM/COPY=002 (MCP) 10:54

SYSTEM/COPY=0002 DIRECTORY ANALYSIS
CBVDOC COBOLV COBEXP COBXR COBEXV

EOJ SYSTEM/COPY=002 10:54 IN 00:10 CHG 00:00
** 06/0 GCR NOW SAVED

==> RY 6/0
06/0 GCR (6250) COB333/TAPDIR U RL# 001 10/04/07 PT# 07277
==> DIR = ON COB333(TAPE)
BOJ SYSTEM/COPY=002 (MCP) 10:55

SYSTEM/COPY=0002 DIRECTORY ANALYSIS
COBDOC COBOL COFLTR COI331 MAN331 IND330 REL330 BSR330 ISH330 ISAMDB
ISMFLT RECOV

EOJ SYSTEM/COPY=002 10:55 IN 00:00 CHG 00:00
** 06/0 GCR NOW SAVED