For Programmers: Free Programming Magazines  


Home > Archive > Cobol > July 2006 > Help with running IBM-COBOL ver 1.0 on Windows 2000/XP









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Help with running IBM-COBOL ver 1.0 on Windows 2000/XP
thedevils.mail@gmail.com

2006-07-10, 3:55 am

Hi,
As part of academics I am using IBM COBOL ver 1.0 Details as given
below:

IBM Personal Computer COBOL Compiler
Version 1.00 (C)Copyright IBM Corp 1982
(C)Copyright Microsoft, Inc. 1982

I am trying to run the same on my home PC which runs Windows 2000/XP.
I have solved the problem of running 16-bit applications on windows
2000. But I am unable to compile my sample HELLO.COB application on it.
The command prompt output is appended below:

========================================
==========
E:\temp\cobol\MS-COBOL>cobol hello

IBM Personal Computer COBOL Compiler
Version 1.00 (C)Copyright IBM Corp 1982
(C)Copyright Microsoft, Inc. 1982

Object filename [HELLO.OBJ]:
Source listing [NUL.LST]:

Not ready reading drive A
Abort, Retry, Fail?a

========================================
======

Why is the compiler trying to read drive A ? How can I solve this
problem ? Kindly advice.

regards
dev

Richard

2006-07-10, 3:55 am


thedevils.mail@gmail.com wrote:

> IBM Personal Computer COBOL Compiler
> Version 1.00 (C)Copyright IBM Corp 1982
> (C)Copyright Microsoft, Inc. 1982


> Not ready reading drive A
> Abort, Retry, Fail?a
> Why is the compiler trying to read drive A ?


1982 ? This compiler was for PC-DOS 1.0. This only supported diskette
drives and not hard disks. Diskettes were A: and B: and were 160Kb or,
if you had PC-DOS 1.1 and the advanced double sided drives, 320Kb.

> How can I solve this problem ? Kindly advice.


Reformat your hard drive to FAT12 format.

Keith Lowe

2006-07-10, 7:55 am


"Richard" <riplin@Azonic.co.nz> wrote in message
news:1152524596.313142.46670@s13g2000cwa.googlegroups.com...
>
> thedevils.mail@gmail.com wrote:
>
>
>
> 1982 ? This compiler was for PC-DOS 1.0. This only supported diskette
> drives and not hard disks. Diskettes were A: and B: and were 160Kb or,
> if you had PC-DOS 1.1 and the advanced double sided drives, 320Kb.
>
>
> Reformat your hard drive to FAT12 format.
>


No reason why it should not run fine on 2000 / XP or another windows
variant. So long as its obsession to look for a disk in drive A are
satisfied nothing else should really matter.

Programs of this era were obviously geared up for floppy's but the hard disk
was invented back then and many machines used them.
They don't tend to care what partition type you use or what size your drive
it, they just do ar job in its simplest form and don't complain about it.

Keith





thedevils.mail@gmail.com

2006-07-10, 7:55 am


> No reason why it should not run fine on 2000 / XP or another windows
> variant. So long as its obsession to look for a disk in drive A are
> satisfied nothing else should really matter.
>
> Programs of this era were obviously geared up for floppy's but the hard disk
> was invented back then and many machines used them.
> They don't tend to care what partition type you use or what size your drive
> it, they just do ar job in its simplest form and don't complain about it.
>
> Keith


Yes thats exactly what I was thinking. If there is a work around by
which I can get the compiler to look for the disk in drive A. Please
advice if you have an idea.

Dev

Pete Dashwood

2006-07-10, 7:55 am


"Richard" <riplin@Azonic.co.nz> wrote in message
news:1152524596.313142.46670@s13g2000cwa.googlegroups.com...
>
> thedevils.mail@gmail.com wrote:
>
>
>
> 1982 ? This compiler was for PC-DOS 1.0. This only supported diskette
> drives and not hard disks. Diskettes were A: and B: and were 160Kb or,
> if you had PC-DOS 1.1 and the advanced double sided drives, 320Kb.
>
>
> Reformat your hard drive to FAT12 format.
>

Richard, that was unkind...

But very amusing :-)

Pete.



Michael Mattias

2006-07-10, 7:55 am

> Yes thats exactly what I was thinking. If there is a work around by
> which I can get the compiler to look for the disk in drive A. Please
> advice if you have an idea.


I had this same problem many many years ago. Not sure if it was specifically
with the MS COBOL compiler, but it was something which was looking at drive
A: for reasons known only to itself.

I think you can SUBST for A: in your autoexec.bat file (or whatever is used
on Win2K)..

....something like...

SUBST A: C:\path

where C:\path is that of your compiler files

Alternately, you may be able to just put a formatted blank disk in A:, and
once it gets past the "no disk" error the software might then search the
PATH.

MCM




Pete Dashwood

2006-07-10, 7:55 am


<thedevils.mail@gmail.com> wrote in message
news:1152521614.911821.32620@m79g2000cwm.googlegroups.com...
> Hi,
> As part of academics I am using IBM COBOL ver 1.0 Details as given
> below:
>
> IBM Personal Computer COBOL Compiler
> Version 1.00 (C)Copyright IBM Corp 1982
> (C)Copyright Microsoft, Inc. 1982
>
> I am trying to run the same on my home PC which runs Windows 2000/XP.
> I have solved the problem of running 16-bit applications on windows
> 2000. But I am unable to compile my sample HELLO.COB application on it.
> The command prompt output is appended below:
>
> ========================================
==========
> E:\temp\cobol\MS-COBOL>cobol hello
>
> IBM Personal Computer COBOL Compiler
> Version 1.00 (C)Copyright IBM Corp 1982
> (C)Copyright Microsoft, Inc. 1982
>
> Object filename [HELLO.OBJ]:
> Source listing [NUL.LST]:
>
> Not ready reading drive A
> Abort, Retry, Fail?a
>
> ========================================
======
>
> Why is the compiler trying to read drive A ?


It is obviously looking for something.

I suspect this will be a default because something hasn't been specified.

It might be looking for object libraries to link, or maybe it is expecting
source on drive A?

It would seem that you need the system path or the environment variables
used by the compiler, to be set to something, so it won't try and default to
A.

Have you tried Fail ing it? It might get over it and continue...

> How can I solve this
> problem ?


Not sure... it isn't an easy one without having the software to hand so a
few theories can be tested. I have a feeling that I actually used this
compiler many years ago, and I probably have the manuals for it sitting in
my garage (which is about 120 miles away from where I'm writing this, so not
much help... sorry. I'll be home at the wekend and will see if I can find
anything.)

> Kindly advice.

Above is the kindliest I can muster... :-)

Pete.



Keith Lowe

2006-07-10, 7:55 am

>
> Yes thats exactly what I was thinking. If there is a work around by
> which I can get the compiler to look for the disk in drive A. Please
> advice if you have an idea.
>
> Dev
>


Really as per my first message - either stick in a blank floppy or use the
subst command to redirect your A drive to hard disk.
e.g. subst a: c:\cpy

Keith



Pete Dashwood

2006-07-10, 7:55 am


"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:k0ssg.129083$dW3.78806@newssvr21.news.prodigy.com...
>
> I had this same problem many many years ago. Not sure if it was
> specifically
> with the MS COBOL compiler, but it was something which was looking at
> drive
> A: for reasons known only to itself.
>
> I think you can SUBST for A: in your autoexec.bat file (or whatever is
> used
> on Win2K)..
>
> ...something like...
>
> SUBST A: C:\path
>
> where C:\path is that of your compiler files
>
> Alternately, you may be able to just put a formatted blank disk in A:, and
> once it gets past the "no disk" error the software might then search the
> PATH.
>
> MCM
>
>
>
>
>




Pete Dashwood

2006-07-10, 7:55 am

Damn!

I was going to suggest using SUBST but I thought it probably wouldn't work
in win32...

After reading your mail I just tried it, and it does...!

Good job, Michael.

Pete.

TOP POST
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:k0ssg.129083$dW3.78806@newssvr21.news.prodigy.com...
>
> I had this same problem many many years ago. Not sure if it was
> specifically
> with the MS COBOL compiler, but it was something which was looking at
> drive
> A: for reasons known only to itself.
>
> I think you can SUBST for A: in your autoexec.bat file (or whatever is
> used
> on Win2K)..
>
> ...something like...
>
> SUBST A: C:\path
>
> where C:\path is that of your compiler files
>
> Alternately, you may be able to just put a formatted blank disk in A:, and
> once it gets past the "no disk" error the software might then search the
> PATH.
>
> MCM
>
>
>
>
>




epc8@juno.com

2006-07-10, 7:55 am

[re problem running IBM Personal COBOL 1.00]

thedevils.mail@gmail.com wrote:
>
> Yes thats exactly what I was thinking. If there is a work around by
> which I can get the compiler to look for the disk in drive A. Please
> advice if you have an idea.
>
> Dev


Ignore the suggestion to use SUBST. Ignore it! Just ignore it!

This program is so old that it uses the MS-DOS 1.0 (inherited from
CP/M) way of dealing with files via FCBs (file control blocks). The
first byte of this contains 01 which specifies drive A:.Change this to
a 00 (current drive) and this problem is revolved.

There are several other problems that also need to be fixed. First,
using the contermporary version of LINK expects libraries to also be on
A:. You can remedy this by using a more recent version of LINK.EXE, or
you can change 'A:' in several places to 'C:' (assuming that is your
hard drive). Second, some versions of this compiler fail if you have
more than 512K of memory installed. Again, this is a one byte patch to
change a compare instruction from signed to unsigned. Finally, there is
a bug in the run time library that gives a divide overflow trap on
displaying a COMP-0 value of -32768. This is because the author used a
CWD instruction to sign extend - which fails when the value is
negative. Note that the last problem is in an .EXE file. This requires
a tweak to patch using dos DEBUG.

I've seen these problems numerous times both in versions of this
compiler and in so called COBOL 650, which strongly resembles IBM
Personal COBOL ver 1.00 but does contain additional functionality
(SORT). (Fixing COBOL 650 requires some minor adjustments to this
procedure.)

Listed below are two files, one a BAT file and one a DEBUG script which
fix these problems (assuming drive C:).

FIX.BAT:

ren cobrun.exe cobrun.xyz
debug<fix.scr
ren cobrun.xyz cobrun.exe

FIX.SCR:

n cobol.com
l
e 7929 00
e 83d4 43
e 83e1 43
w
n cobol2.lib
l
e 8f2 73
w
n cobrun.xyz
l
a 17e2
xor dx,dx
mov bx,a
div bx
xchg dx,ax
add al,30
pop bx
dec bx
mov [bx],al
xchg dx,ax

w
q
-- END OF FILES --

If the OP is using stuff this old the he should understand what the BAT
file and debug script are doing. :-).

-- e-mail: epc8 at juno dot com

Michael Mattias

2006-07-10, 7:55 am

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4hf24qF1rgc8eU1@individual.net...
> Damn!
>
> I was going to suggest using SUBST but I thought it probably wouldn't work
> in win32...
>
> After reading your mail I just tried it, and it does...!
>
> Good job, Michael.


I'm pleased and proud to share this victory with all the rest of us old
farts.

MCM







epc8@juno.com

2006-07-10, 7:55 am


Michael Mattias wrote:
>
> I had this same problem many many years ago. Not sure if it was specifically
> with the MS COBOL compiler, but it was something which was looking at drive
> A: for reasons known only to itself.
>
> I think you can SUBST for A: in your autoexec.bat file (or whatever is used
> on Win2K)..
>
> ...something like...
>
> SUBST A: C:\path
>
> where C:\path is that of your compiler files
>


Using SUBST can cause other problems. It does not work on my XP system
which has a real drive A: unless I disable drive A:.

C:\temp>subst a: c:\temp
Invalid parameter - A:

> Alternately, you may be able to just put a formatted blank disk in A:, and
> once it gets past the "no disk" error the software might then search the
> PATH.
>


No. That does not work either.

C:\temp>cobol foo

IBM Personal Computer COBOL Compiler
Version 1.00 (C)Copyright IBM Corp 1982
(C)Copyright Microsoft Corp. 1982

Object filename [FOO.OBJ]:
Source listing [NUL.LST]:
?Overlay 1 not found

-- e-mail: epc8 at juno dot com

HeyBub

2006-07-10, 6:55 pm

epc8@juno.com wrote:
>
> Using SUBST can cause other problems. It does not work on my XP system
> which has a real drive A: unless I disable drive A:.
>
> C:\temp>subst a: c:\temp
> Invalid parameter - A:
>


Here's why:


subst /?
Associates a path with a drive letter

SUBST [drive1: [drive2:path]

drive1: Specifies a VIRTUAL drive to which you want to assign a path
(emphasis added)


thedevils.mail@gmail.com

2006-07-10, 6:55 pm

Hi ,
Thanks for the response. Yours was the answer that inspired some
confidence on how this could be done. I tried out your suggestion.
Didn't get the expected result though. I executed the batch file as
recommended. This is the command line output I got :

========================================
===================

C:\MS-COBOL>ren cobrun.exe cobrun.xyz

C:\MS-COBOL>debug 0<fix.scr
-n cobol.com

-l

-e 7929 00

-e 83d4 43

-e 83e1 43

-w

Writing 09280 bytes
-n cobol2.lib

-l

-e 8f2 73

-w

Writing 05800 bytes
-n cobrun.xyz

-l

-a 17e2

0BA3:17E2 xor dx,dx

0BA3:17E4 mov bx,a

0BA3:17E7 div bx

0BA3:17E9 xchg dx,ax

0BA3:17EA add al,30

0BA3:17EC pop bx

0BA3:17ED dec bx

0BA3:17EE mov [bx],al

0BA3:17F0 xchg dx,ax

0BA3:17F1

-

-w

Writing 04000 bytes
-q
C:\MS-COBOL>ren cobrun.xyz cobrun.exe

========================================
=================

But the compiler returns the same error message on compiling as listed
below:


-------------------
C:\MS-COBOL>cobol hello

IBM Personal Computer COBOL Compiler
Version 1.00 (C)Copyright IBM Corp 1982
(C)Copyright Microsoft, Inc. 1982

Object filename [HELLO.OBJ]:
Source listing [NUL.LST]:

Not ready reading drive A
Abort, Retry, Fail?f
?Overlay 1 not found
--------------

I hope you might be able to make out what the problem might be from
this. Thanks in advance for all help.

~Dev

epc8@juno.com wrote:


> Ignore the suggestion to use SUBST. Ignore it! Just ignore it!
>
> This program is so old that it uses the MS-DOS 1.0 (inherited from
> CP/M) way of dealing with files via FCBs (file control blocks). The
> first byte of this contains 01 which specifies drive A:.Change this to
> a 00 (current drive) and this problem is revolved.
>
> There are several other problems that also need to be fixed. First,
> using the contermporary version of LINK expects libraries to also be on
> A:. You can remedy this by using a more recent version of LINK.EXE, or
> you can change 'A:' in several places to 'C:' (assuming that is your
> hard drive). Second, some versions of this compiler fail if you have
> more than 512K of memory installed. Again, this is a one byte patch to
> change a compare instruction from signed to unsigned. Finally, there is
> a bug in the run time library that gives a divide overflow trap on
> displaying a COMP-0 value of -32768. This is because the author used a
> CWD instruction to sign extend - which fails when the value is
> negative. Note that the last problem is in an .EXE file. This requires
> a tweak to patch using dos DEBUG.
>
> I've seen these problems numerous times both in versions of this
> compiler and in so called COBOL 650, which strongly resembles IBM
> Personal COBOL ver 1.00 but does contain additional functionality
> (SORT). (Fixing COBOL 650 requires some minor adjustments to this
> procedure.)
>
> Listed below are two files, one a BAT file and one a DEBUG script which
> fix these problems (assuming drive C:).
>
> FIX.BAT:
>
> ren cobrun.exe cobrun.xyz
> debug<fix.scr
> ren cobrun.xyz cobrun.exe
>
> FIX.SCR:
>
> n cobol.com
> l
> e 7929 00
> e 83d4 43
> e 83e1 43
> w
> n cobol2.lib
> l
> e 8f2 73
> w
> n cobrun.xyz
> l
> a 17e2
> xor dx,dx
> mov bx,a
> div bx
> xchg dx,ax
> add al,30
> pop bx
> dec bx
> mov [bx],al
> xchg dx,ax
>
> w
> q
> -- END OF FILES --
>
> If the OP is using stuff this old the he should understand what the BAT
> file and debug script are doing. :-).
>
> -- e-mail: epc8 at juno dot com


epc8@juno.com

2006-07-10, 6:55 pm

thedevils.mail@gmail.com wrote:
> Hi ,
> Thanks for the response. Yours was the answer that inspired some
> confidence on how this could be done. I tried out your suggestion.
> Didn't get the expected result though. I executed the batch file as
> recommended. This is the command line output I got :
>
> ========================================
===================
>

[snip] patches being applied

> Writing 09280 bytes
> Writing 05800 bytes
> Writing 04000 bytes
> -q
> C:\MS-COBOL>ren cobrun.xyz cobrun.exe
>
> ========================================
=================
>
> But the compiler returns the same error message on compiling as listed
> below:


> C:\MS-COBOL>cobol hello
>
> IBM Personal Computer COBOL Compiler
> Version 1.00 (C)Copyright IBM Corp 1982
> (C)Copyright Microsoft, Inc. 1982
>
> Object filename [HELLO.OBJ]:
> Source listing [NUL.LST]:
>
> Not ready reading drive A
> Abort, Retry, Fail?f
> ?Overlay 1 not found
> --------------
>
> I hope you might be able to make out what the problem might be from
> this. Thanks in advance for all help.
>
> ~Dev
>
> epc8@juno.com wrote:
>

[patch snipped]

At this point, I would try the individual patches manually. Load up
COBOL.COM under DEBUG and search for the string COBOL1.OVR. Look for
the byte immediately before this string and verify that it is 01 before
changing it to 00. I would also save an old copy of the files, make the
changes and then verify using FC /b which bytes were changed and from
what value to what value.

If this fails, let me know. I would be more than happy to examine your
copies of the files if this suggestion fails. Also I would be happy to
explain what the other patches do, and what they replace if you need
this type of detail.

-- e-mail: epc8 at juno dot com.

epc8@juno.com

2006-07-10, 6:55 pm


epc8@juno.com wrote:
> thedevils.mail@gmail.com wrote:
> [snip] patches being applied
>
>
> [patch snipped]
>
> At this point, I would try the individual patches manually. Load up
> COBOL.COM under DEBUG and search for the string COBOL1.OVR. Look for
> the byte immediately before this string and verify that it is 01 before
> changing it to 00. I would also save an old copy of the files, make the
> changes and then verify using FC /b which bytes were changed and from
> what value to what value.
>
> If this fails, let me know. I would be more than happy to examine your
> copies of the files if this suggestion fails. Also I would be happy to
> explain what the other patches do, and what they replace if you need
> this type of detail.
>
> -- e-mail: epc8 at juno dot com.


Miserable beast! It's in a FCB so you may have to search for COBOL1
followed by spaces followed by OVR. Sorry about that. [It's Monday.
:-).]

Richard

2006-07-10, 6:55 pm


thedevils.mail@gmail.com wrote:

> Thanks for the response. Yours was the answer that inspired some
> confidence on how this could be done.


I wasn't sure whether your original request was serious or not. If you
have a desire to rum PC-DOS 1.x software as a retro-timewarp thing then
it should be done an an dual floppy IBM-PC (I do have a 5150 model B
here if you want).

If, however, you want to learn Cobol, then that software would be a
particularly bad choice. It is not even entirely ANS'74 standard (it
is MS so one doesn't expect it to follow anyone else's standard), it is
derived from the CP/M version and so has technical issues such as using
FCBs rather than file handles, and there is little or no documentation
freely available.

You would find that many or most examples will not compile. ANS'74 was
30 years ago and significant changes were introduced by ANS'85. MS
Cobol 1 did not have X/Open extensions like RM, MF and Acu did at the
time but had rather different ones.

I would suggest getting at least a ANS'85 compiler such as:

http://www.adtools.com/student/cobol.htm

epc8@juno.com

2006-07-10, 6:55 pm

Richard wrote:
> thedevils.mail@gmail.com wrote:
>
>
> I wasn't sure whether your original request was serious or not. If you
> have a desire to rum PC-DOS 1.x software as a retro-timewarp thing then
> it should be done an an dual floppy IBM-PC (I do have a 5150 model B
> here if you want).


Actually running old software is a lot of fun. And I prefer command
line tools to Fujitsu's "Programming Staff" IDE supplied with version
3.0.

>
> If, however, you want to learn Cobol, then that software would be a
> particularly bad choice. It is not even entirely ANS'74 standard (it
> is MS so one doesn't expect it to follow anyone else's standard), it is
> derived from the CP/M version and so has technical issues such as using
> FCBs rather than file handles, and there is little or no documentation
> freely available.


Unless he is using this textbook:

Cobol for the IBM Personal Computer
Kip R. Irvine

which does cover (later) versions of the compiler in more detail.

I found this at a local public library in 97 or 98. It's still listed
in one state university's catalog. Apparently this was at one time a
popular (community) college textbook.

epc8@juno.com

2006-07-10, 6:55 pm


Richard wrote:
> thedevils.mail@gmail.com wrote:
>
>
> I wasn't sure whether your original request was serious or not. If you
> have a desire to rum PC-DOS 1.x software as a retro-timewarp thing then
> it should be done an an dual floppy IBM-PC (I do have a 5150 model B
> here if you want).
>
> If, however, you want to learn Cobol, then that software would be a
> particularly bad choice.


Addendum to last post. I'm not sure the educational versions of
compilers supplied with a number of textbooks are that much better.
Have you ever seen the educational version of RM Cobol?

Richard

2006-07-10, 6:55 pm


epc8@juno.com wrote:

>
> Unless he is using this textbook:
>
> Cobol for the IBM Personal Computer
> Kip R. Irvine


Were you going to send him a copy ?

> which does cover (later) versions of the compiler in more detail.


Covering later versions is not particularly useful. It may for example
have code in ANS'85 which will give confusing and unhelpful error
messages.

IBM had several rebranded compilers at different times. The original
IBM-PC one was MS Cobol 1.x hacked from the CP/M version. Later they
rebranded an early MF Cobol/2 (version 1.3 I think) and then there was
VisualAge for Cobol.

If it ain't for that compiler it won't be useful and may be
conter-productive.

> I found this at a local public library in 97 or 98. It's still listed
> in one state university's catalog. Apparently this was at one time a
> popular (community) college textbook.


Maybe, but was it for the 1982 MS compiler ?

Try using a Ford Cortina service manual when working on a Model T.

Richard

2006-07-10, 6:55 pm


epc8@juno.com wrote:

> Addendum to last post. I'm not sure the educational versions of
> compilers supplied with a number of textbooks are that much better.
> Have you ever seen the educational version of RM Cobol?


I have a copy here in the books by Welburn & Price which I picked up at
the local car boot sale for a dollar or two. It is ANS'85 and contains
notes how to do the code in ANS'74 if required. The books tell how to
install and run the compiler, though not for XP of course as this was
published in 1995.

Anything that is ANS'85 and has the correct documention is hugely
better than what MS did in 1982.

Actually _anything_ is better than MS Cobol 1.x or 2.x, I know, I have
been forced to use them (admitedly by having money thrown at me).

epc8@juno.com

2006-07-10, 6:55 pm


Richard wrote:
> epc8@juno.com wrote:
>
>
> Were you going to send him a copy ?
>
>
> Covering later versions is not particularly useful. It may for example
> have code in ANS'85 which will give confusing and unhelpful error
> messages.
>
> IBM had several rebranded compilers at different times. The original
> IBM-PC one was MS Cobol 1.x hacked from the CP/M version. Later they
> rebranded an early MF Cobol/2 (version 1.3 I think) and then there was
> VisualAge for Cobol.
>
> If it ain't for that compiler it won't be useful and may be
> conter-productive.
>
>
> Maybe, but was it for the 1982 MS compiler ?
>
> Try using a Ford Cortina service manual when working on a Model T.


The only feature I found missing in the 82 compiler that was mentioned
in the text was SORT. Otherwise, AFAIK everything else from that book
compiled and ran with the 1.00 version.

epc8@juno.com

2006-07-10, 6:55 pm

Richard wrote:
> epc8@juno.com wrote:
>
> Actually _anything_ is better than MS Cobol 1.x or 2.x, I know, I have
> been forced to use them (admitedly by having money thrown at me).


OK. You are correct in that. Since you've used these products
professionally, I do respect your opinion!

Prompted by this discussion, I went back and looked at Fujitsu 3.0. (I
will comment on this in a new thread.)

Richard

2006-07-10, 9:55 pm


epc8@juno.com wrote:

> The only feature I found missing in the 82 compiler that was mentioned
> in the text was SORT. Otherwise, AFAIK everything else from that book
> compiled and ran with the 1.00 version.


Then it must be an old and archaic text.

Without ANS'85 features you will learn obsolete techniques.

epc8@juno.com

2006-07-10, 9:55 pm


Richard wrote:
> epc8@juno.com wrote:
>
>
> Then it must be an old and archaic text.
>
> Without ANS'85 features you will learn obsolete techniques.


Which features of '85 do you feel are most important for the student to
learn?

Richard

2006-07-10, 9:55 pm


e...@juno.com wrote:

> Which features of '85 do you feel are most important for the student to
> learn?


ANS'85 includes scope terminators which allows the code to be
structured in a more modern way. EVALUATE is useful for multi-branch
conditionals. CONTINUE eliminates NEXT SENTENCE.

You should avoid learning 'how they did it 30 years ago' and at least
move up to 'what they did in the late 80s'. If you learn how to write
30 year old code and get a job you will be given all the 30 year old
programs to look after.

Pete Dashwood

2006-07-11, 3:55 am


<epc8@juno.com> wrote in message
news:1152537522.317144.105620@m73g2000cwd.googlegroups.com...
> [re problem running IBM Personal COBOL 1.00]
>
> thedevils.mail@gmail.com wrote:
>
> Ignore the suggestion to use SUBST. Ignore it! Just ignore it!
>
> This program is so old that it uses the MS-DOS 1.0 (inherited from
> CP/M) way of dealing with files via FCBs (file control blocks). The
> first byte of this contains 01 which specifies drive A:.Change this to
> a 00 (current drive) and this problem is revolved.
>
> There are several other problems that also need to be fixed. First,
> using the contermporary version of LINK expects libraries to also be on
> A:. You can remedy this by using a more recent version of LINK.EXE, or
> you can change 'A:' in several places to 'C:' (assuming that is your
> hard drive). Second, some versions of this compiler fail if you have
> more than 512K of memory installed. Again, this is a one byte patch to
> change a compare instruction from signed to unsigned. Finally, there is
> a bug in the run time library that gives a divide overflow trap on
> displaying a COMP-0 value of -32768. This is because the author used a
> CWD instruction to sign extend - which fails when the value is
> negative. Note that the last problem is in an .EXE file. This requires
> a tweak to patch using dos DEBUG.
>
> I've seen these problems numerous times both in versions of this
> compiler and in so called COBOL 650, which strongly resembles IBM
> Personal COBOL ver 1.00 but does contain additional functionality
> (SORT). (Fixing COBOL 650 requires some minor adjustments to this
> procedure.)
>
> Listed below are two files, one a BAT file and one a DEBUG script which
> fix these problems (assuming drive C:).
>
> FIX.BAT:
>
> ren cobrun.exe cobrun.xyz
> debug<fix.scr
> ren cobrun.xyz cobrun.exe
>
> FIX.SCR:
>
> n cobol.com
> l
> e 7929 00
> e 83d4 43
> e 83e1 43
> w
> n cobol2.lib
> l
> e 8f2 73
> w
> n cobrun.xyz
> l
> a 17e2
> xor dx,dx
> mov bx,a
> div bx
> xchg dx,ax
> add al,30
> pop bx
> dec bx
> mov [bx],al
> xchg dx,ax
>
> w
> q
> -- END OF FILES --
>
> If the OP is using stuff this old the he should understand what the BAT
> file and debug script are doing. :-).
>
> -- e-mail: epc8 at juno dot com
>

Very Well Done, Elliot!

I can't decide whether you are a genius stuck in a timewarp, or just a very
person who is letting life pass him by... :-)

Either way, respect for this solution.

Pete.


epc8@juno.com

2006-07-11, 7:55 am

Pete Dashwood wrote:[color=darkred]
> <epc8@juno.com> wrote in message
> news:1152537522.317144.105620@m73g2000cwd.googlegroups.com...

[snip patch for very old software]

Thanks. Actually, I've been recycling this set of patches for about 25
years. Running old software is just a hobby. For real work I use more
modern tools.

-- elliot

Michael Wojcik

2006-07-11, 6:55 pm


In article <1152537522.317144.105620@m73g2000cwd.googlegroups.com>, epc8@juno.com writes:
>
> This program is so old that it uses the MS-DOS 1.0 (inherited from
> CP/M) way of dealing with files via FCBs (file control blocks). The
> first byte of this contains 01 which specifies drive A:.Change this to
> a 00 (current drive) and this problem is revolved.
>
> [snip discussion of binary patches]


Fond though I am of hacking binaries - I've zapped many a DOS program
in my day, too - another possibility might be running it under one of
the open-source DOS emulators. I haven't used them to any great
extent, but I believe at least some of them will remap drives in FCBs
on the fly, reduce the amount of RAM visible to the program, etc.

Try http://dosbox.sourceforge.net, for example.

These emulators can be quite handy for occasionally running ancient
DOS (or CP/M, etc) software. (And for mainframe fans there's
Hercules...)

--
Michael Wojcik michael.wojcik@microfocus.com

Auden often writes like Disney. Like Disney, he knows the shape of beasts --
(& incidently he, too, might have a company of artists producing his lines) --
unlike Lawrence, he does not know what shapes or motivates these beasts.
-- Dylan Thomas
Arnold Trembley

2006-07-11, 9:55 pm



Michael Wojcik wrote:
> (snip)
> Fond though I am of hacking binaries - I've zapped many a DOS program
> in my day, too - another possibility might be running it under one of
> the open-source DOS emulators. I haven't used them to any great
> extent, but I believe at least some of them will remap drives in FCBs
> on the fly, reduce the amount of RAM visible to the program, etc.
>
> Try http://dosbox.sourceforge.net, for example.
>
> These emulators can be quite handy for occasionally running ancient
> DOS (or CP/M, etc) software. (And for mainframe fans there's
> Hercules...)
>


DosBox works great. I have a copy of Realia COBOL educational
compiler version 1.0 (copyright 1990) from a mid-1990's textbook that
used to work fine under windoze 98. But in WinXP the compiler blows
up with the message: "The NTVDM CPU has encountered an illegal
instruction".

The compiler works fine in the DosBox 6.5 emulator, and the compiled
programs execute perfectly in a WinXP command-line window.

I would like to try OosBox out with IBM-COBOL version 1.0 for PC-DOS,
but I don't think there is a legal way to get a copy. And google
doesn't seem to think it's available for download anywhere, and I
don't have access to any working PC with a 5.25 inch floppy drive.


--
http://arnold.trembley.home.att.net/

epc8@juno.com

2006-07-22, 9:55 pm


Richard wrote:
> e...@juno.com wrote:
>
>
> ANS'85 includes scope terminators which allows the code to be
> structured in a more modern way. EVALUATE is useful for multi-branch
> conditionals. CONTINUE eliminates NEXT SENTENCE.
>
> You should avoid learning 'how they did it 30 years ago' and at least
> move up to 'what they did in the late 80s'. If you learn how to write
> 30 year old code and get a job you will be given all the 30 year old
> programs to look after.


As penance, I sat down and wrote up a set of test programs using the
features of the '85 standard. One of these was in response to a problem
(badly) posted in another thread about joining two data bases using a
fractional key. The "new" features made it fairly pleasant to write
this up. I would not have bothered to try if I had been restricted to
'74 standards. Of course the program listing looks a bit strange - more
like Pascal than traditional COBOL. :-).

Thanks for your advice and the push I needed to enter the late 20th
century!

-- elliot

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com