[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU-COBOL] New to COBOL
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.
The computer didn't store decimal points, precision came from program.
>
>
> <snip>
>
> -DN
> Packed decimal means storing one digit in each nybble or your data,
> right? Perl can unpack arbitrary data into hex nybbles using
> the h or H "pack templates" and then evaluate the results as numbers
> (into the native perl number type, which is double-precision floating
> point,
> which can cause inaccuracies, so a big integer package would be called
> for, or perhaps adjusted as needed)
>
> -BK
> All numbers in COBOL are essentially INTEGER types. It is the internal storage method which changes. The big problem with packed decimal is the sign. A field defined as PIC S9, takes up a single by with the high-order nybble indicating the sign. A field defined as PIC S999 takes up two bytes, with the high order nybble of the low-order byte indicating the sign. In general the sign is the high order nybble of the low order byte.
>
> The current standard only allows numbers to have 18 digits: 123456789012345678 or 123456789.012345678 or .123456789012345678 or any other combination. The sign and the decimal point don't count (at least for storage).
The problem would come from files written with another compiler dialect e.g. IBM, Burroughs etc.
>
>
> <snip>
>
> -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?
ALWAYS -- READ a FILE -- WRITE a RECORD
>
>
> -BK
> Some of these things are platform specific (see JCL).
> Your I-O classes are covered by: OPEN, CLOSE, START, READ, WRITE, REWRITE, DELETE. Each of these have clauses which modify their inherent functioning.
>
> 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.
>
> Ask questions for more (getting tired of writing).
>
>
> <snip>
>
> How do people get into COBOL programming? It's never offered in schools
MY choices were COBOL, FORTRAN, RPG. - BASIC wasn't looked upon as
a programming language. circa 1975
>
>
> It was either COBOL or FORTRAN or PL/1 or BPL or APL or BASIC (not Bill's type) or SDL or &c.
>
> Learned and used all of them to some extent or another. Also went on to learn the new languages, Pascal, C, C++, VB, HTML (I know, not really a language), &c.
>
> Still find more work, more often in COBOL.
>
> Besides, it IS a heck of lot easier to maintain than any of the others, IMNSHO.
There's something to be said for STRUCTURED PROGRAMMING!
Ken
--
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.