Re: Hexadecimal Input Files

In article <1151331823.840604.30880@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Stacy Kay <stacykw85@xxxxxxxxxxx> wrote:
I guess I didn't give enough information. I am an intern this summer. I
have already finished a program in Assembler. What my task is, is to
convert that program to COBOL. I have had two semesters of COBOL class
experience.

Some familiarity, then... well, that's a start.

The format of the input file I am to use is in
hexadecimal.

Ummmmm... maybe what the difficulty here is a matter of terminology.
Usually when a COBOL programmer refers to 'the format of a file' what is
indicated is the layout of the records, found either in the FD or in the
WORKING-STORAGE SECTION as the target of a READ (filename) INTO. Without
that one is usually reduced to READing a file into a field defined as a
simple alphanumeric and 'making sense' of the results by use of reference
modification. For example:

FD INFILE.
01 INFILE-REC PIC X( ).
....
WORKING-STORAGE SECTION.
....
01 WS-INFILE-REC.
05 WS-INFILE-LNAME PIC X(25) VALUE SPACES.
05 WS-INFILE-FNAME PIC X(20) VALUE SPACES.
05 WS-INFILE-MI PIC X(01) VALUE SPACES.
05 WS-INFILE-EMPNO PIC 9(09) VALUE ZEROES.
05 WS-INFILE-DPTNO PIC X(05) VALUE SPACES.
05 WS-INFILE-MGRNO PIC 9(09) VALUE ZEROES.
....
PROCEDURE DIVISION.
....
READ INFILE INTO WS-INFILE-REC
AT END SET NO-MORE-INFILE TO TRUE.

After this READ is successfully executed both INFILE-REC and WS-INFILE-REC
contain the same data. One can refer to WS-INFILE-DPTNO or
INFILE-REC(55:5) and the data will be the same; a COBOL programmer would,
in my experience, refer to the 'format' as being WS-INFILE-REC.

Where is a similar structure to be found for the file you will be using?


I just haven't had this experience before with this
format.

With good reason... one of the advantages of COBOL is that when (not if)
the program blows up at 2:am and Ops calls you then you will have an
easier time making sense of (and repairing) WS-INFILE-DEPTNO than
INFILE-REC(55:5).

I've read it before in a JCL dump, but just haven't used it.
Also, I am working on a mainframe environment.

With 'JCL' and 'mainframe' being mentioned I will conclude that you are
working in an IBM-compatible environment... this, also, is helpful to
know.

I didn't want to have
someone do my work. I just wanted ideas or even just information about
the relationship between COBOL using hexadecimal numbers. I've looked
in some of my mentor's manuals, but nothing goes too deep on this
subject.

Once again, 'hexadecimal numbers' are used in different ways... compare
the differences between what results from

01 NUM-COMP PIC S9(8) COMP VALUE +123456.

.... and ...

01 NUM-COMP3 PIC S9(8) COMP-3 VALUE +123456.

DD
.

Relevant Pages

  • Re: Quick n Dirty Unpacking of COMP-3?
    ... What you need is a tool that reads Cobol descriptions of the input and output ... an interpreter is fast enough .. ... >OPEN INPUT INFILE OUTPUT OUTFILE. ...
    (comp.lang.cobol)
  • Re: If you were inventing CoBOL...
    ... > working-storage section. ... > procedure division. ... *> like Net Express in V 4.0 to comply with COBOL 2002 ... A Trigger program invokes Class A. which in turn invokes Classes B, ...
    (comp.lang.cobol)
  • Re: Revisiting an Old Prejudice: READ INTO/WRITE FROM
    ... The following applies ONLY to IBM's mainframe environment. ... Somewhere around "LANGLVL" and/or VS COBOL II, ... Not for history ... and that everything should be dealt with in WORKING-STORAGE using READ ...
    (comp.lang.cobol)
  • Re: Constants, Static, Public, Private
    ... "static" is equivalent of Working-Storage (but not for Cobol.NET, ... located below the declaration. ... That's like imagine to put several Cobol programs into one file, ...
    (comp.lang.cobol)
  • Re: Cobol language dictionary page -- assignment complete?
    ... > Some further thoughts on free-form reference format in COBOL. ...
    (comp.lang.cobol)