Cobol - Cobol/Java/etc

Author

Cobol/Java/etc

Sergey Kashyrin

2006-03-18, 3:55 am

Ladies (if present here?) & Gentlemen,

Speaking of languages it's just came to my mind the old "task" published
relatively long time ago by the American writer (unfortunatly I've forgot
his name, but actually I can figure out).

The task is to write the program which prints it's own source code (so it
can be accepted by compiler) but of course not reading any file.

For all Cobol funs I can suggest to try :-))
(I'm not sure anybody has a guts to do that in Cobol but I'll definitely
take my hat off if I see that source)

As I remember it took for me 40 minutes and 9 statements in PL/I language.

Regards,
Sergey

Michael Mattias

2006-03-18, 6:55 pm

Peter Lacey

2006-03-18, 6:55 pm

Michael Mattias wrote:
>
> "Sergey Kashyrin" <ska@resqnet.com> wrote in message
> news:D8MSf.55$Th7.117876@news.sisna.com...
>
> Cannot be done, since you can get the same compiled program file from an
> infinite number of source code inputs.
>
> Since datanames and symbols do not exist in the compiled file, any such
> program - often called either a disassembler or decompiler - would have to
> make them up, de facto making the generated source code something other than
> the original, absent absolutely terrific dumb luck.
>
> MCM

Not so. There's a book called "Etudes for programmers" which presents
this as an "etude" - borrowed from the musical sense of the word. The
article describing the assignment states that there's a theorem which
proves that this can be done in any language "powerful" enough - and
also that all languages are "powerful" enough.

The only way I could think of to do this was to print a bunch of
literals which duplicated the actual source - but that leads only into
an ever-regressing loop. So I don't know how it's done, in Cobol or any
other language.

PL

Michael Mattias

2006-03-18, 6:55 pm

"Peter Lacey" <lacey@mts.net> wrote in message
news:441C52CC.E102AE63@mts.net...[color=darkred]
> Michael Mattias wrote:
published[color=darkred]
forgot[color=darkred]
it[color=darkred]
to[color=darkred]
than[color=darkred]

If you mean could I create a program which prints its own source code 'from
within' , if it can be a Windows executable I can do that in say, twenty
minutes. You simply make the source code file a program resource and print
it from there:

1. Finish editing source code, save
2. Compile resource file with source code file as a resource
3. Compile executable program file from source code
4. Run linker to embed resource in executable

For an example, go to my web site at http://www.talsystems.com. Click on
"Tech Corner" and download the file "835did.exe" (near the bottom of the
page). Run this program on a Windows machine. Forget what it's supposed to
do, just click on the "Info" button. The text that comes up is an ordinary
"rich text" document file I embedded in the executable at compile time
(well, technically it would have been at "link" time) . No reason this file
could not have been the source code file.

I'm not sure if other environments support "program data embedded in the
executable module" but if they do you could apply the same principle. And
this technique is perforce source-language independent!

Depending on what you mean by "print" the source code, it would not even
take much code. To just dump the source code to a text file would take me
maybe twenty (20) lines of procedural code. (In either COBOL or BASIC). (ID,
ENVIRONMENT and DATA DIVISIONs as well as Windows header files not
included).

But I thought you meant 'given the executable code in this executable file -
and only the executable code - print the source code." This cannot be done
for the reasons stated above.

MCM

Michael Wojcik

2006-03-18, 6:55 pm

In article <D8MSf.55$Th7.117876@news.sisna.com>, "Sergey Kashyrin" <ska@resqnet.com> writes:
> Speaking of languages it's just came to my mind the old "task" published
> relatively long time ago by the American writer (unfortunatly I've forgot
> his name, but actually I can figure out).

You're probably thinking of W. V. Quine. Such programs are commonly
called "quines". There are loads of web pages dedicated to quines in
various languages, and to various debates about them (eg whether the
Basic program "1 PRINT" is a legitimate quine).

> The task is to write the program which prints it's own source code (so it
> can be accepted by compiler) but of course not reading any file.

There are COBOL quines on the web, but of course many people enjoy
writing their own.

--
Michael Wojcik michael.wojcik@microfocus.com

It wasn't fair; my life was now like everyone else's. -- Eric Severance

Michael Wojcik

2006-03-18, 6:55 pm

In article <iHUSf.1867$4L1.1293@newssvr11.news.prodigy.com>, "Michael Mattias" <michael.mattias@gte.net> writes:
> "Sergey Kashyrin" <ska@resqnet.com> wrote in message
> news:D8MSf.55$Th7.117876@news.sisna.com...
>
> Cannot be done, since you can get the same compiled program file from an
> infinite number of source code inputs.

I think you misunderstand the nature of the problem. A quine is not
expected to determine its original source code through some magic
computation; it's supposed to contain a computation that represents
that source code (in a finite manner) such that it can restore it
when executed. It's entirely possible, many exist, and the fact that
compilation is an information-reducing transformation is no obstacle.

Quines are discussed extensively (more so than they warrant, probably)
on the net.

--
Michael Wojcik michael.wojcik@microfocus.com

If Mokona means for us to eat this, I, a gentle person, will become

! -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_

Joe Zitzelberger

2006-03-18, 6:55 pm

In article <iHUSf.1867$4L1.1293@newssvr11.news.prodigy.com>,
"Michael Mattias" <michael.mattias@gte.net> wrote:

> "Sergey Kashyrin" <ska@resqnet.com> wrote in message
> news:D8MSf.55$Th7.117876@news.sisna.com...
>
> Cannot be done, since you can get the same compiled program file from an
> infinite number of source code inputs.
>
> Since datanames and symbols do not exist in the compiled file, any such
> program - often called either a disassembler or decompiler - would have to
> make them up, de facto making the generated source code something other than
> the original, absent absolutely terrific dumb luck.
>
>
> MCM

Easy enough on z/OS. Look in the PPA for the address of the actual
module, find the ADATA records, filter on source records and display
them.

Perhaps a few minutes of code...

Peter Lacey

2006-03-18, 6:55 pm

Michael Mattias wrote:
>
> "Peter Lacey" <lacey@mts.net> wrote in message
> news:441C52CC.E102AE63@mts.net...
> published
> forgot
> it

Michael has snipped all that I (Pater Lacey) posted; readers will have
to refer back to my message. The above lines come from Sergei Kashyrin,
the original poster.
[color=darkred]
> to
> than
>
> If you mean could I create a program which prints its own source code 'from
> within' , if it can be a Windows executable I can do that in say, twenty
> minutes. You simply make the source code file a program resource and print
> it from there:
>
> 1. Finish editing source code, save
> 2. Compile resource file with source code file as a resource
> 3. Compile executable program file from source code
> 4. Run linker to embed resource in executable
>

This problem was proposed long before such techniques were available.
But by the
terms of the problem, the "resource" to which you refer must be part of
the original source, not something linked in. Otherwise the problem is
trivial.

> But I thought you meant 'given the executable code in this executable file -
> and only the executable code - print the source code." This cannot be done
> for the reasons stated above.
>
> MCM

That is what I meant. I did say >>I<< hadn't worked it out! But see
the posts by Michael Wojcik on the subject of "quines".

PL

epc8@juno.com

2006-03-19, 6:55 pm

Peter Lacey wrote:
> Michael Mattias wrote:
>
> Not so. There's a book called "Etudes for programmers" which presents
> this as an "etude" - borrowed from the musical sense of the word. The
> article describing the assignment states that there's a theorem which
> proves that this can be done in any language "powerful" enough - and
> also that all languages are "powerful" enough.
>
> The only way I could think of to do this was to print a bunch of
> literals which duplicated the actual source - but that leads only into
> an ever-regressing loop. So I don't know how it's done, in Cobol or any
> other language.
>
> PL

The trick is to encode the data in some fashion and then decode it at
run-time. This avoids the problem of literals quoting themselves,
quoting themselves......

see http://www.madore.org/~david/computers/quine.html

Often the language chosen to illustrate this is "C" in the context of
an obfuscated programming contest.

While this of course has no real application to the world of business
D.P., it might stimulate the mind of the COBOL programmer to think
about some interesting things:

1. Programs which write other programs.
2. Data tables which are created at run time or unpacked at run time.

-- Elliot

William M. Klein

2006-03-19, 6:55 pm

"Joe Zitzelberger" <zberger@knology.net> wrote in message
news:zberger-57A7B5.17450518032006@ispnews.usenetserver.com...
> In article <iHUSf.1867$4L1.1293@newssvr11.news.prodigy.com>,
> "Michael Mattias" <michael.mattias@gte.net> wrote:
>
<snip>
> Easy enough on z/OS. Look in the PPA for the address of the actual
> module, find the ADATA records, filter on source records and display
> them.
>
> Perhaps a few minutes of code...

Joe,
If you can "decode" ADATA in a few minutes, you are a better programmer than I
am <G>.

--
Bill Klein
wmklein <at> ix.netcom.com

Oliver Wong

2006-03-21, 7:04 pm

"Sergey Kashyrin" <ska@resqnet.com> wrote in message
news:D8MSf.55$Th7.117876@news.sisna.com...
> Ladies (if present here?) & Gentlemen,
>
> Speaking of languages it's just came to my mind the old "task" published
> relatively long time ago by the American writer (unfortunatly I've forgot
> his name, but actually I can figure out).
>
> The task is to write the program which prints it's own source code (so it
> can be accepted by compiler) but of course not reading any file.
>
> For all Cobol funs I can suggest to try :-))
> (I'm not sure anybody has a guts to do that in Cobol but I'll definitely
> take my hat off if I see that source)
>
> As I remember it took for me 40 minutes and 9 statements in PL/I language.

I wrote such a program in Java. The strategy I used was to have the
source code get doubled; once as the contents of a string, and once again as
actual code. The actual code would print the string twice, plus a bit of
fiddling.

If I apply the same strategy in COBOL, it would sort of look like this, I
guess.

DATA DIVISION.
WORKING-STORAGE SECTION.
77 code1 VALUE "
DATA DIVISION.
WORKING-STORAGE SECTION.
"
77 code2 VALUE "
PROCEDURE DIVISION.
DISPLAY code1
PEFORM VARYING I FROM 1 TO 2
DISPLAY ""77 code"" I "" VALUE """""" code(I) """"""""
END PERFORM
DISPLAY code2

Sergey Kashyrin

2006-03-22, 3:55 am

Oliver,

The idea for C++,Java,C# etc is relatively clear.

And in Cobol it's not that easy to do. It should be a little bit another
idea as well as for Fortran-77.

You cheated twice - at first with CR/LF (or end-of-lines) and at second with
a quote (you have to double it :-)).
If you try not to cheat you'll realize that for Cobol it's not doable
exaclty this way.

Elliot (epc8@juno) already gave a good URL where the second approach is
present (encode from data)

I think it's hard to do better than in PL/I
I might forgot it's exact syntax (it was like 27 years ago) but I'll try:

M:PROC OPTIONS(MAIN); DCL (A,B) CHAR(1000) VAR;
A = 'A:PROC OPTIONS(MAIN); DCL (A,B) CHAR(1000) VAR;';
B = 'PUT SKIP LIST(A); PUT SKIP DATA(A); PUT SKIP DATA(B); PUT SKIP LIST(B);
END;';
PUT SKIP LIST(A); PUT SKIP DATA(A); PUT SKIP DATA(B); PUT SKIP LIST(B); END;

9 statements in PL/I :-))))

Regards,
Sergey

"Oliver Wong" <owong@castortech.com> wrote in message
news:XoYTf.6052$nQ6.1869@clgrps13...
> "Sergey Kashyrin" <ska@resqnet.com> wrote in message
> news:D8MSf.55$Th7.117876@news.sisna.com...
>
> I wrote such a program in Java. The strategy I used was to have the
> source code get doubled; once as the contents of a string, and once again
> as actual code. The actual code would print the string twice, plus a bit
> of fiddling.
>
> If I apply the same strategy in COBOL, it would sort of look like this, I
> guess.
>
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 77 code1 VALUE "
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> "
> 77 code2 VALUE "
> PROCEDURE DIVISION.
> DISPLAY code1
> PEFORM VARYING I FROM 1 TO 2
> DISPLAY ""77 code"" I "" VALUE """""" code(I) """"""""
> END PERFORM
> DISPLAY code2
> .
> "
> PROCEDURE DIVISION.
> DISPLAY code1
> PEFORM VARYING I FROM 1 TO 2
> DISPLAY "77 code" I " VALUE """ code(I) """"
> END PERFORM
> DISPLAY code2
> .
>
> I cheated a bit, 'cause I'm not that familiar with the OCCURS 2 TIMES
> INDEX BY FOO syntax and how you could initialize the values of each
> occurrence, but hopefully the idea should be clear. Also, you gotta do
> some fancy string manipulation so that the number of quotation characters
> are doubled when actually printed out. That's easy to do in Java, but I
> have no idea how to do it in COBOL.
>
> So the above program is not a quine, but it gives an idea of how to
> write one generically.
>
> - Oliver

Oliver Wong

2006-03-22, 3:55 am

"Sergey Kashyrin" <ska@resqnet.com> wrote in message
news:%U_Tf.112$Gk.108651@news.sisna.com...
> Oliver,
>
> The idea for C++,Java,C# etc is relatively clear.
>
> And in Cobol it's not that easy to do. It should be a little bit another
> idea as well as for Fortran-77.
>
> You cheated twice - at first with CR/LF (or end-of-lines) and at second
> with a quote (you have to double it :-)).
> If you try not to cheat you'll realize that for Cobol it's not doable
> exaclty this way.

Yeah, I mentioned the "quote cheat', but for the CR/LF, I thought COBOL
would allow it, though maybe what I saw was something to do with
line-continuations rather than literal CR/LFs embedded in the strings.

>
> Elliot (epc8@juno) already gave a good URL where the second approach is
> present (encode from data)
>
> I think it's hard to do better than in PL/I
> I might forgot it's exact syntax (it was like 27 years ago) but I'll try:
>
> M:PROC OPTIONS(MAIN); DCL (A,B) CHAR(1000) VAR;
> A = 'A:PROC OPTIONS(MAIN); DCL (A,B) CHAR(1000) VAR;';
> B = 'PUT SKIP LIST(A); PUT SKIP DATA(A); PUT SKIP DATA(B); PUT SKIP
> LIST(B); END;';
> PUT SKIP LIST(A); PUT SKIP DATA(A); PUT SKIP DATA(B); PUT SKIP LIST(B);
> END;
>
> 9 statements in PL/I :-))))

Not that I know PL/I, but it seems that this follows the same structure
as my (correct) solution for Java and my (incorrect) solution for COBOL.
Namely that you need 2 variables, one that contains the "header" of the
program, and one that contains the "footer". Then you write code to print
out these variables twice, with some fiddling.

As for writing something shorter than 9 statements, you can do it in C
using zero statements. Providing an empty file (e.g. zero bytes) to certain
C compilers will generate an executable without compile errors (thought they
may issue warnings), and the resulting executable emits an output also of
length zero. I.e. the output is identical to the source.

- Oliver

Richard

2006-03-22, 3:55 am

Sergey Kashyrin wrote:

> And in Cobol it's not that easy to do.

It is important that for any application a suitable language is chosen.
Cobol is not a good language to do a complete waste of time, so choose
a language better suited to that task.

Sponsored Links