cobol12

cobol12 is a newly available freeware compiler
which is found at www.homepages.paradise.net.nz/jsoeberg/  Has anyone on
this group any comment on this compiler.
--
John Sampson

"""COBOL12 16-bit COBOL Compiler New

This is a 16-bit COBOL compiler for DOS and Windows. It supports some
of the ANSI74 specifications, lacks some features like SORT and STRING,
and includes other non-standard features such as the modules that allow
screen output. Compiled programs use video mode 12h, a 16 colour
graphical mode with a resolution of 640x480. The compiler comes with an
IDE, linker, a runtime module and a reference manual."""

Note: 'SOME of the ANSI74 specification'

"""Indexed sequential files are supported by the standard COBOL
statements for these files, and by the provision of the BTRIEVE indexed
file system."""

BTrieve was not a free system when I last looked at it. It now belongs
to Pervasive.

Richard wrote:
> """COBOL12 16-bit COBOL Compiler New
>
> This is a 16-bit COBOL compiler for DOS and Windows. It supports some
> of the ANSI74 specifications, lacks some features like SORT and
STRING,
> and includes other non-standard features such as the modules that
allow
> screen output. Compiled programs use video mode 12h, a 16 colour
> graphical mode with a resolution of 640x480. The compiler comes with
an
> IDE, linker, a runtime module and a reference manual."""
>
> Note: 'SOME of the ANSI74 specification'
>
> """Indexed sequential files are supported by the standard COBOL
> statements for these files, and by the provision of the BTRIEVE
indexed
> file system."""
>
> BTrieve was not a free system when I last looked at it. It now
belongs
> to Pervasive.

According to the documentation, this is an old version of BTrieve which
is distributed with permission but without support. This is a DOS
program which creates its own GUI screens. It looks like a low-res
Windows but it's all DOS. It seems to run well on my XP system.

I've cut and pasted from one of the HTML doc files:

Features not implemented
The following COBOL features are not implemented in this compiler.

SWITCH
ALPHABET name
CODE-SET
RESERVE n AREAS
BLOCK CONTAINS
I-O-CONTROL
SD sort-file; SORT, MERGE, RELEASE, RETURN
REPORT SECTION
SIGN LEADING, TRAILING
SYNCHRONIZED
Qualified data names: (data-item OF record-name)
DECLARATIVES (but see USE statement)
ACCEPT dataname
ALTER
COMPUTE
INITIALIZE
STRING, UNSTRING


Non-standard additional features
The following features, not part of standard COBOL, are implemented in
this compiler.

DIRECT file organization
LABEL RECORD dataname for sequential header records
NULL KEY for alternate indexed file keys
USAGE DATE, supporting date arithmetic
SCREEN SECTION for full screen editing, menus, and MOUSE use:
ACCEPT SCREEN, DISPLAY SCREEN
ACCEPT options: FROM PARAMETERS to access DOS call parameters
FROM [NEXT] FILE-ID to access file names
DELETE FILE to delete a file from disk
DISPLAY options: BELL, ATTRIBUTE, AT llcc
DISPLAY FORMAT to display a screen format from an ascii specification
display string in the Data Division.
EXIT PERFORM to discontinue inline Performs
PERFORM UNTIL EXIT for unconditional inline performs
READ - PRIOR RECORD to read previous record
SET DIRECTORY TO dataname to set current disk directory
SET condition-name TO FALSE
START, CANCEL, END TRANSACTION for BTRIEVE transaction processing.
WRITE - NO ADVANCING to support printer control codes
USE to trap file errors in the program

-- end cut and paste --

It also supports a limited form of reference modification.

The compiler (CCOB) compiles to an intermediate code which is run using
the runtime engine (RUN). Files also may be compiled to create a
standalone .EXE using LCOB which looks like it binds in the runtime.
This seems to be how the demonstration files were created.

This package is interesting to me as a programming work. Not only was
it written in 8088/8086 assembler, but accept and display screen
formats as well as GUI controls are described as data in working
storage in what looks like a little language. If this language is
interpreted at runtime, rather than compiled, this opens up some new
possibilities.

John  Sampson wrote:
> cobol12 is a newly available freeware compiler
> which is found at www.homepages.paradise.net.nz/jsoeberg/  Has anyone
on
> this group any comment on this compiler.
> --
> John Sampson

Yes, it crashes on trying to compile or run my simple test programs. If
you are looking for a free compiler a better bet is to go to
http://www.adtools.com/student/ register and download Fujitsu Cobol
version 3.

epc8@juno.com wrote:
> John  Sampson wrote: 
anyone
> on 
>
> Yes, it crashes on trying to compile or run my simple test programs.
If
> you are looking for a free compiler a better bet is to go to
> http://www.adtools.com/student/ register and download Fujitsu Cobol
> version 3.

On additional testing, it requires data names to start in area B but
does not flag errors if this is not so. In addition, at runtime the
program may crash or behave unexpectedly.

Also having a FD which contains only a group (level 01) item is
ineffective. Nothing is written to the output file unless there is at
least one elementary item below.

Do these two constraints actually adhere to a strict (or low level)
version of the 74 standard?

I think (but haven't checked) that data-names in the B-margin *was* a
restriction of the '74 Standard, i.e

01  THIS-ITEM. ....

The "T" had to be in the B-margin.

There certainly wasn't any requirement for there to be elementary items unde
r an
FD - but  I don't understand how you can have a "group item with an 01-level
 -
with no items under it".  If it has a PICTURE CLAUSE it is NOT a group item 
and
if doesn't have a PICTURE clause (and is a group-item) then it WOULD need an
elementary item under it.

FYI,
Neither the '74 or '85 Standard had any requirements about flagging syntax
errors (believe it or not).

--
Bill Klein
wmklein <at> ix.netcom.com
<epc8@juno.com> wrote in message
news:1115531071.327354.66550@f14g2000cwb.googlegroups.com...
>
> epc8@juno.com wrote: 
> anyone 
> If 
>
> On additional testing, it requires data names to start in area B but
> does not flag errors if this is not so. In addition, at runtime the
> program may crash or behave unexpectedly.
>
> Also having a FD which contains only a group (level 01) item is
> ineffective. Nothing is written to the output file unless there is at
> least one elementary item below.
>
> Do these two constraints actually adhere to a strict (or low level)
> version of the 74 standard?
>

> > epc8@juno.com wrote: 
programs. 
Cobol 
but 
at 

William M. Klein wrote:
> I think (but haven't checked) that data-names in the B-margin *was* a

> restriction of the '74 Standard, i.e
>
>   01  THIS-ITEM. ....
>
> The "T" had to be in the B-margin.

I guess I've been spoiled by extensions then.

>
> There certainly wasn't any requirement for there to be elementary
items under an
> FD - but  I don't understand how you can have a "group item with an
01-level -
> with no items under it".  If it has a PICTURE CLAUSE it is NOT a
group item and
> if doesn't have a PICTURE clause (and is a group-item) then it WOULD
need an
> elementary item under it.
>

Ooops. That's what I get for posting late at night. :-). What I meant
was that if the FD has only an 01-level

FD  OUTFILE
.........
01  OUTREC PIC 9(5).

then nothing gets written to the output file - the file contains 0
bytes. But

FD  OUTFILE
.........
01  OUTREC.
02  OUTNUM PIC 9(5).

does work. (In the first case data is moved to OUTREC and in the second
case to OUTNUM.)

> FYI,
>   Neither the '74 or '85 Standard had any requirements about flagging
syntax
> errors (believe it or not).

Ouch. And the resulting program is free to do as it pleases???

("The behavior of a non standard conforming program is undefined.")

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:DThfe.190137$R24.133237@fe05!news.easynews.com...
> I think (but haven't checked) that data-names in the B-margin *was* a
> restriction of the '74 Standard, i.e
>
>   01  THIS-ITEM. ....
>
> The "T" had to be in the B-margin.

Yes, the record-name or item-name of an 01-level or 77-level item had to be
in area B.
ANSI X3.23-1974 page I-107, 5.8.4 Data Division Entries, seventh paragraph.

> There certainly wasn't any requirement for there to be elementary items
under an
> FD - but  I don't understand how you can have a "group item with an
01-level -
> with no items under it".  If it has a PICTURE CLAUSE it is NOT a group
item and
> if doesn't have a PICTURE clause (and is a group-item) then it WOULD need
an
> elementary item under it.

Yes.  Ibid. page I-84, 5.3.3.2.1, Level numbers, allows for group items and
for elementary items.  A record may be either.  But a data item in this
context has to be either a group item or an elementary item.  If it lacks
subordinate items and thus doesn't qualify as a group item, and it lacks
sufficient description to mark it as elementary (e.g., PICTURE or something
like USAGE INDEX), then what the data item is is outside the rules of
standard COBOL.

-Chuck Stevens

Richard wrote:
> """COBOL12 16-bit COBOL Compiler New
>
> This is a 16-bit COBOL compiler for DOS and Windows. It supports some
> of the ANSI74 specifications, lacks some features like SORT and
STRING,
> and includes other non-standard features such as the modules that
allow
> screen output. Compiled programs use video mode 12h, a 16 colour
> graphical mode with a resolution of 640x480. The compiler comes with
an
> IDE, linker, a runtime module and a reference manual."""
>
> Note: 'SOME of the ANSI74 specification'
>
> """Indexed sequential files are supported by the standard COBOL
> statements for these files, and by the provision of the BTRIEVE
indexed
> file system."""
>
> BTrieve was not a free system when I last looked at it. It now
belongs
> to Pervasive.

According to the documentation, this is an old version of BTrieve which
is distributed with permission but without support. This is a DOS
program which creates its own GUI screens. It looks like a low-res
Windows but it's all DOS. It seems to run well on my XP system.

I've cut and pasted from one of the HTML doc files:

Features not implemented
The following COBOL features are not implemented in this compiler.

SWITCH
ALPHABET name
CODE-SET
RESERVE n AREAS
BLOCK CONTAINS
I-O-CONTROL
SD sort-file; SORT, MERGE, RELEASE, RETURN
REPORT SECTION
SIGN LEADING, TRAILING
SYNCHRONIZED
Qualified data names: (data-item OF record-name)
DECLARATIVES (but see USE statement)
ACCEPT dataname
ALTER
COMPUTE
INITIALIZE
STRING, UNSTRING


Non-standard additional features
The following features, not part of standard COBOL, are implemented in
this compiler.

DIRECT file organization
LABEL RECORD dataname for sequential header records
NULL KEY for alternate indexed file keys
USAGE DATE, supporting date arithmetic
SCREEN SECTION for full screen editing, menus, and MOUSE use:
ACCEPT SCREEN, DISPLAY SCREEN
ACCEPT options: FROM PARAMETERS to access DOS call parameters
FROM [NEXT] FILE-ID to access file names
DELETE FILE to delete a file from disk
DISPLAY options: BELL, ATTRIBUTE, AT llcc
DISPLAY FORMAT to display a screen format from an ascii specification
display string in the Data Division.
EXIT PERFORM to discontinue inline Performs
PERFORM UNTIL EXIT for unconditional inline performs
READ - PRIOR RECORD to read previous record
SET DIRECTORY TO dataname to set current disk directory
SET condition-name TO FALSE
START, CANCEL, END TRANSACTION for BTRIEVE transaction processing.
WRITE - NO ADVANCING to support printer control codes
USE to trap file errors in the program

-- end cut and paste --

It also supports a limited form of reference modification.

The compiler (CCOB) compiles to an intermediate code which is run using
the runtime engine (RUN). Files also may be compiled to create a
standalone .EXE using LCOB which looks like it binds in the runtime.
This seems to be how the demonstration files were created.

This package is interesting to me as a programming work. Not only was
it written in 8088/8086 assembler, but accept and display screen
formats as well as GUI controls are described as data in working
storage in what looks like a little language. If this language is
interpreted at runtime, rather than compiled, this opens up some new
possibilities.