[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU-COBOL] New to COBOL
Boris and David,
Boris did an excellent job of addressing your questions, probably better
than I could have. Just a few comments...
Boris Kortiak wrote:
>
> David,
>
> Please forgive the GroupWise lousy quoting. I will prefix statements with -DO for Davyd, -DN for you and -BK for me.
>
> >>> "David L. Nicol" <david@kasey.umkc.edu> 10/26/99 03:39PM >>>
> Davyd Ondrejko wrote:
>
> -DO
> > The internal storage of PIC 9() fields is weird, as well. Normally, a
> <snip>
>
> -DN
> But internal storage is an implementation detail. Would not any
> arbitrary-precision arithmatic package be able to APPEAR AS these data
> types?
>
> -BK
> For the most part yes.
I think that needs some expansion, and depends on what exactly we're
talking about here. If we're talking about a program written in COBOL
intending to run it through this new Perl program, then yeah it would
probably work OK. However, there is extant code which takes advantage
of the different storage schemes to perform various functions, e.g.,
encryption and data validation. Yes, you could write new code without
doing any of that, and for such code your proposed program would work.
Older code would have some problems.
> -DN
> What kinds of file systems or other persistence abstractions exist in
> the general COBOL environment? Does COBOL give low-level calls to
> things
> like "read a block of records from tape drive 2" or what? Do you have
> to mount the tape with a name and then read the records from the device
> with the name?
>
> -BK
> Some of these things are platform specific (see JCL).
Very true. Mainframes are different from PC's, both of which are
different
from Unix boxes.
> Your I-O classes are covered by: OPEN, CLOSE, START, READ, WRITE,
> REWRITE, DELETE. Each of these have clauses which modify their inherent
> functioning.
Also very true. Interacting with CICS gets even more complicated,
although
I assume that we're just talking about a straight COBOL converter.
> OPEN: INPUT, I-O, OUTPUT, APPEND. The clauses allow for input, input
> and output, output and appending to the end of a file; respectivly.
> This shows the simplest case, the trick comes from the file's definition
> in the SELECT clase. Is it a SEQUENTIAL, RANDOM or INDEXED organization?
> Is it SEQUENTIAL, RANDOM or DYNAMIC access?
>
> An example from a specific platform (HP 3000 MPE/iX)
>
> SELECT MYFILE ASSIGN TO "MYNAME".
>
> This is sufficient to define a file's basic characteristics. The logical
> file name is MYFILE, that is to say this is how it will be referenced in
> the program. The physical name is MYNAME, that is how it is expected to
> be called on the device (disk, printer, tape, &c) where it resides.
On a DOS/VSE platform, you might see something like:
SELECT MYFILE ASSIGN SYS050-MYNAME
ORGANIZATION INDEXED
ACCESS IS DYNAMIC
RECORD KEY IS MYFILE-KEY.
And the device that SYS050 referred to would be system-dependent and
accessed by means of the JCL, and the file would have to be defined as
(most likely) a VSAM file with that key. A mainframe requires a lot
more forethought and planning than most other platforms that I've worked
on; you can't just create new disk files on the fly.
> Besides, it IS a heck of lot easier to maintain than any of the others, IMNSHO.
Despite a personal preference for COBOL, I think that the
maintenanceability (is that a word? it is now) of a program has more to
do with the original programmer than it does with the specific language
used.
-- Davyd
--
David R. Ondrejko - EDI/Referral - Safelite Glass Co.
Mathematician by training - Programmer by trade - Philosopher by nature
Genius by genetics - Atheist by conviction - Hedonist by desire!
--
This message was sent through the gnu-cobol mailing list. To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body. For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.