|
|
| anguel@web.de 2005-08-18, 8:59 am |
| Does anyone know if there is a compiler for Cobol that creates
independently executable programs, e.g. that do not need to be run
using a runtime environment? Can be a commercial one. TIA.
| |
| anguel@web.de 2005-08-18, 8:59 am |
| anguel@web.de schrieb:
> Does anyone know if there is a compiler for Cobol that creates
> independently executable programs, e.g. that do not need to be run
> using a runtime environment? Can be a commercial one. TIA.
Forgot to mention: For linux. Sorry.
| |
|
| Microsoft had a COBOL compiler for PC many years ago. It would generate
..obj, .lst, and .exe files. I remember it came on 5 1/4 floppy
diskettes. I don't know what happened to it.
| |
| Frederico Fonseca 2005-08-18, 5:55 pm |
| On 18 Aug 2005 06:48:26 -0700, anguel@web.de wrote:
>anguel@web.de schrieb:
>
>
>Forgot to mention: For linux. Sorry.
www.microfocus.com
www.adtools.com (very limited on capabilities when compared to the
first one)
http://www.thekompany.com/products/kobol/
Maybe another 1 or 2 of the most well known.
IBM also have their own version that may or not work on Linux.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Richard 2005-08-18, 5:55 pm |
| > Microsoft had a COBOL compiler for PC many years ago. > .. I don't know what happened to it.
Originally (late 70s) MS had a CP/M Cobol. They converted this to
MS-DOS but it was not particularly good. In the late 80s they rebadged
MicroFocus Cobol until MF opened its USA office and stopped MS
distributing this.
| |
| Richard 2005-08-18, 5:55 pm |
| > Forgot to mention: For linux. Sorry.
OpenCobol and tinyCobol will generate complete executable but this will
still use dynamic libraries that are normally available.
Kobol (from TheKompany) does require that it be purchased for each
machine but it is only $60.00.
| |
| Richard 2005-08-18, 5:55 pm |
| >> that do not need to be run using a runtime environment?
> www.microfocus.com
> www.adtools.com
How do you get those to run without the run-time environment ?
| |
| Frederico Fonseca 2005-08-19, 4:12 pm |
| On 18 Aug 2005 12:34:03 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
>How do you get those to run without the run-time environment ?
Humm....
Fujitsu will require the runtime
MF did(does) at some stage, and depending on what is used require no
runtime as it can link the runtime modules with the executable.
My impression from the post, which may be wrong, was that a compiler
was required that would not need the final user e.g. customer, to pay
for a runtime. e.g. all applications developed with the compiler could
be distributed without further charges.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Richard 2005-08-19, 4:12 pm |
| > e.g. all applications developed with the compiler could
> be distributed without further charges.
That excludes microfocus then.
Fujitsu runtime can be distributed if the compiler license is not an
academic, student or free one. The Linux one is a couple of megabytes.
| |
| Frederico Fonseca 2005-08-19, 4:12 pm |
| On 19 Aug 2005 12:34:48 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>That excludes microfocus then.
Is MF now charging for ALL runtime options? they didn't a few years
ago.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Russell 2005-08-19, 9:55 pm |
| "Richard" <riplin@Azonic.co.nz> wrote in news:1124480088.937638.54090
@z14g2000cwz.googlegroups.com:
>
> That excludes microfocus then.
>
> Fujitsu runtime can be distributed if the compiler license is not an
> academic, student or free one. The Linux one is a couple of megabytes.
>
I have been told that the SORT included in the standard Fujitsu
runtime is somewhat slow. Is this still true, and what do most people do
about this?
| |
| HeyBub 2005-08-20, 2:55 am |
| Russell wrote:
> "Richard" <riplin@Azonic.co.nz> wrote in news:1124480088.937638.54090
> @z14g2000cwz.googlegroups.com:
>
>
> I have been told that the SORT included in the standard Fujitsu
> runtime is somewhat slow. Is this still true, and what do most
> people do about this?
Um, it's not so much slow as it is slower than others. We use SortSolutions
Active-X control for large(r) sorts. One time fee of $69.
| |
| Richard 2005-08-20, 2:55 am |
| > I have been told that the SORT included in the standard Fujitsu
> runtime is somewhat slow. Is this still true, and what do most people do
> about this?
SORTing seems a mainframe batch thing to do. If data is required to be
accessed in a particular way in an interactive system then it is
generally preferable to have this as an alternate key in indexed files
or SQL.
| |
| Lueko Willms 2005-08-20, 6:55 pm |
| .. On 19.08.05
wrote riplin@Azonic.co.nz (Richard)
on /COMP/LANG/COBOL
in 1124515542.433378.127380@g44g2000cwa.googlegroups.com
about Re: Cobol Compiler
r> SORTing seems a mainframe batch thing to do. If data is required to
r> be accessed in a particular way in an interactive system then it is
r> generally preferable to have this as an alternate key in indexed files
r> or SQL.
Sure, but when a batch of data is to be inserted in a database or
indexed otherwise, it is quite often faster to sort it first.
Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
Ängstlich zu sinnen und zu denken, was man hätte tun können, ist das Übelste, was man tun _kann_. -G.C.Lichtenberg
| |
| John Culleton 2005-08-20, 6:55 pm |
| anguel@web.de wrote:
> anguel@web.de schrieb:
>
>
> Forgot to mention: For linux. Sorry.
Tiny Cobol can generate self contained COBOL programs or so I am told. I
will test the feature and report back. I use Slackware Linux.
--
John Culleton
Able Indexers and Typesetters
| |
| John Culleton 2005-08-20, 6:55 pm |
| John Culleton wrote:
> anguel@web.de wrote:
>
>
> Tiny Cobol can generate self contained COBOL programs or so I am told. I
> will test the feature and report back. I use Slackware Linux.
It seems that one at least needs a control file and a library module. I am
trying again to see if there is a way to link the library module in
statically. The control file is trivial.
--
John Culleton
Able Indexers and Typesetters
| |
| Howard Brazee 2005-08-22, 6:55 pm |
|
On 19-Aug-2005, "Richard" <riplin@Azonic.co.nz> wrote:
> SORTing seems a mainframe batch thing to do. If data is required to be
> accessed in a particular way in an interactive system then it is
> generally preferable to have this as an alternate key in indexed files
> or SQL.
I remember a mainframe shop that didn't pay for a sort utility. They sorted by
copying to indexed files. Very inefficient.
There is no reason that smaller computers don't take advantage of general
purpose sort routines.
| |
| Richard 2005-08-22, 6:55 pm |
| > Sure, but when a batch of data is to be inserted in a
> database or indexed otherwise, it is quite often faster to
> sort it first.
Or it may be quite slower, depending on the implementation. In one
extreme case of a particular brand and version, if an indexed file was
loaded from sorted data the resulting index was horribly skewed to the
point of being a linked list (ie no 'left' branches) and access
performance was severly degraded. Sorting to random sequence and
loading made the load faster _and_ gave a significant improvement in
average access.
Many ISAM systems need to do rotations to keep the index tree balanced
and loading a file in key order maximises the number of rotations
required. In cases where the cost of rotations is large relative to the
cost of loading it is probably faster and more efficient to load the
data in unsorted order, and this saves the time for the sort.
It may be 'quite often' faster to sort on your system, but that doesn't
mean that it will be on some other.
[color=darkred]
You may also note that I had qualified my statement. In interactive
systems most data is created as the product or by-product of entering
data and directly capturing it. Even when data arrives from outside
(for example as sales orders via web, email, or file transfer) there
isn't a 'batch' of them as they are processed as they arrive (hence
'interactive').
| |
| Richard 2005-08-22, 6:55 pm |
| > I remember a mainframe shop that didn't pay for a sort utility. They sorted by
> copying to indexed files. Very inefficient.
That may well be the case for mainframes, but I have found situations
where using a indexed file is _faster_ than using a sort.
> There is no reason that smaller computers don't take advantage of general
> purpose sort routines.
There is often no reason that they should, especially when it is not an
'advantage'. Interactive systems are mostly shared (unlike batch
systems) and this means that files are accessed and updated by many
users with record locking (or similar) ensuring data consistency. The
output from a sort is (normally) sequential and thus cannot be shared
as easily, especially a sort cannot write an output file if another
user has a previous iteration open. The sorted file also gets out of
date very quickly.
In an interactive system, if data is required in a particular sequence
then it should be provided in that way for users to access as required,
this tends to exclude sorting as part of a system design.
| |
| HeyBub 2005-08-22, 6:55 pm |
| Richard wrote:
>
> SORTing seems a mainframe batch thing to do. If data is required to
> be accessed in a particular way in an interactive system then it is
> generally preferable to have this as an alternate key in indexed files
> or SQL.
Much of an interactive system is, in fact, interactive. There are times,
however, when sorting is appropriate.
Producing AR statements comes to mind.
As does producing packing lists in bin order for efficient picking.
As for alternate indexes on an ISAM file: phooey.
| |
| Richard 2005-08-22, 6:55 pm |
| > Much of an interactive system is, in fact, interactive. There are times,
> however, when sorting is appropriate.
> Producing AR statements comes to mind.
Why would you restrict accessing AR transactions in that particular
sequence to 'once a month' and 'all at once' ? Would it not be useful
to be able to access, say, the transactions for each customer on an
enquiry screen in statement sequence ?
For example in matching payments to open item transactions, displaying
these to the user in the same sequence as they appear on the 'payment
advice' tearoff from the statement makes it very much easier to match.
> As does producing packing lists in bin order for efficient picking.
In my systems the bin location is an important alternate key for the
stock file as it may be used frequently from, eg, radio terminals to
list all items at a specific location (there can be multiple products
in some locations), or for full pallets, reading the locations for a
product to select the 'closest'.
> As for alternate indexes on an ISAM file: phooey.
It would be a huge waste of resources if a file sort were required
everytime one wanted a particular sequence of records.
| |
| HeyBub 2005-08-23, 3:55 am |
| Richard wrote:
>
>
> Why would you restrict accessing AR transactions in that particular
> sequence to 'once a month' and 'all at once' ? Would it not be useful
> to be able to access, say, the transactions for each customer on an
> enquiry screen in statement sequence ?
And then mail the monitor?
>
> For example in matching payments to open item transactions, displaying
> these to the user in the same sequence as they appear on the 'payment
> advice' tearoff from the statement makes it very much easier to match.
And how did the customer GET the tear-off bit of paper if not by an upstream
sort?
>
>
> In my systems the bin location is an important alternate key for the
> stock file as it may be used frequently from, eg, radio terminals to
> list all items at a specific location (there can be multiple products
> in some locations), or for full pallets, reading the locations for a
> product to select the 'closest'.
>
>
> It would be a huge waste of resources if a file sort were required
> everytime one wanted a particular sequence of records.
Very few of our sorts access a disk drive at all - aside from getting the
data. The records are sorted in memory, thereby fulfilling the maxim: "The
fastest disk access is no disk access."
I understand your rule to be: "Suitably clever design, using alternate keys,
can eliminate sorting. If you have to sort, you haven't been clever enough."
I, personally, don't trust ISAM files with more than one key. So I suppose
it's a matter of personal experience and preference.
| |
| Richard 2005-08-23, 3:55 am |
| >> Would it not be useful ...
> And then mail the monitor?
Let us be pedantic then:
Would it not be useful to _ALSO_ be able to access ...
I can't see anywhere that I stated this ability to enquire replaced or
removed the printing of paper statements.
> And how did the customer GET the tear-off bit of paper if not by an upstream
sort?
"To a hammer all problems look like nails."
By having the debtors transaction file with an appropriate alternate
key one can use this to produce the statements when required and _ALSO_
use this key when displaying or otherwise processing these records,
such as when interactively matching payments.
> "Suitably clever design, using alternate keys, can eliminate sorting.
While that may be true, my 'rule' is that I meet the requirements of
the user. I find that users want to be able to press a button and have
the data displayed on their screens now. Sorts tend to write unsharable
files and this interferes with the need to have many users accessing
data (usually subsets) on demand.
> If you have to sort, you haven't been clever enough."
No. If I have to sort then I probably haven't met the user's
requirements adequately.
> I don't trust ISAM files with more than one key.
Well there yer go. I've never had a problem, or at least none
particularly troublesome - I did have one that reached the limit for
duplicate keys, but that was easy to fix.
> So I suppose it's a matter of personal experience and preference.
That may be true of batch systems where such a choice may be arbitrary.
| |
| Lueko Willms 2005-08-23, 3:55 am |
| .. On 22.08.05
wrote riplin@Azonic.co.nz (Richard)
on /COMP/LANG/COBOL
in 1124737211.896075.75560@g43g2000cwa.googlegroups.com
about Re: Cobol Compiler
r> It may be 'quite often' faster to sort on your system, but that
r> doesn't mean that it will be on some other.
That's why I chose such conditional formulations.
"It all depends" could have been the general answer.
Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
Die Wörter-Welt. -G.C.Lichtenberg
| |
| docdwarf@panix.com 2005-08-23, 7:55 am |
| In article <1124737211.896075.75560@g43g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Or it may be quite slower, depending on the implementation. In one
>extreme case of a particular brand and version, if an indexed file was
>loaded from sorted data the resulting index was horribly skewed to the
>point of being a linked list (ie no 'left' branches) and access
>performance was severly degraded. Sorting to random sequence and
>loading made the load faster _and_ gave a significant improvement in
>average access.
How very interesting... Mr Plinston, might you be able to recall and
relate this particular manufacturer's 'brand and version'? It might be a
Good Thing to Know... or it might be a justification of an archaic
practise.
DD
| |
| Richard 2005-08-23, 6:55 pm |
| > might you be able to recall and
> relate this particular manufacturer's 'brand and version'?
It was RM Cobol around 1982, I can't recall the version number.
| |
| docdwarf@panix.com 2005-08-23, 6:55 pm |
| In article <1124823060.925979.231780@f14g2000cwb.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>It was RM Cobol around 1982, I can't recall the version number.
I see... a package that's undergone a bit of development in the past
nigh-quarter-century, or so the Liant folks would have people believe.
Perhaps it is best left to the reader to determine whether this 'might be
a Good Thing to Know... or it might be a justification of an archaic
practise.'
DD
| |
| docdwarf@panix.com 2005-08-24, 3:55 am |
| In article <1124829095.878642.307940@g14g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
[snip]
>
>
>It may well be 'good to know' that different systems have different
>characteristics and 'one solution' does not fit all.
'Have', to the best of my knowledge, Mr Plinston, just might not,
possibly, be the same as 'had twenty-five years ago'.
>In particular,
>loading indexed files in key order maximises the number of b-tree index
>rotations required. It happens that in that version RM did not do
>rotations.
It happens, Mr Plinston, that RM released a new version of the software
which demonstrated that condition nearly a quarter-century ago... perhaps
it is best left to the reader to determine whether this 'might be a Good
Thing to Know... or it might be a justification of an archaic practise.'
DD
| |
| Richard 2005-08-24, 3:55 am |
| > just might not, possibly, be the same as 'had twenty-five years ago'.
Perhaps you are unaware that things can be different without being that
one example from some time ago.
| |
| docdwarf@panix.com 2005-08-24, 7:55 am |
| In article <1124868754.377347.54530@g47g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Perhaps you are unaware that things can be different without being that
>one example from some time ago.
Perhaps I am aware, as well, that the only example of this thing being so
is an example nigh a quarter-century old, as well.
DD
| |
| Richard 2005-08-24, 6:55 pm |
| >> Perhaps you are unaware that things can be different
[color=darkred]
> Perhaps I am aware, as well, that the only example of
> this thing being so is an example nigh a quarter-century
> old, as well.
It may well be the only example of that particular difference that you
are aware of, and then only within the last day or two, but that may
say more about your 'awareness', or specifically your lack of this,
than of the many material differences that can exist in different
systems.
|
|
|
|