Reading Line Sequential File Backwards

[hofacket]

How do you read a line sequential file backwards.. I basically have a existing text file that i need to add control characters to in certain places... the easiest way for me to do this, considering what i have the key off of, is to read the file backwards..

i can always read / write to a new file, but this particular instance is a 75,000 page document and id rather edit the existing document than creating a new one.

But i am not sure how to do this in Cobol...

anyone have any ideas?

 

[webrabbit]

O/S and compiler vendor and version, please. In standard COBOL you can neither read a line-sequential file backward nor can you update it.

In Micro Focus COBOL, you can use byte-stream processing to read it backwards, but it would be very tricky. If you are replacing characters, that would work, but if you are adding characters, it would be almost impossible.

Could you give a bit more detail?

 

[k5tm]

I agree... more detail, please.

Tom Morrison

http://www.liant.com

 

[CliveC]

Open the file for I/O as if it were a relative file.
For the record key use the number of the last record in the file and then just keep subtracting one.

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://port-lucaya.com

 

[k5tm]

Clive,

For most COBOL file systems, that won't work...

Tom Morrison

http://www.liant.com

 

[CliveC]

I see. It worked ok for micro focus.

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://port-lucaya.com

 

[webrabbit]

If it worked in Micro Focus as you say, then it is not a line sequential file, or it is a very special case of one.

Relative files are either fixed length or variable length. If they are variable length, in Micro Focus they have a file descriptor record at the beginning of the file, and a record descriptor field at the beginning of each record. Line sequential file records are variable length with a line-feed and carriage-return (or a line-feed only under Unix or Linix) as the record terminator, with no record descriptor field at the beginning. The only way a line-sequential file could be read as a relative file is if all the records are the same length. This is not usually the case in Micro Focus, as the I/O routines trim trailing spaces on output. The only way to get a Micro Focus program to write constant length line sequential records is to always have a non-blank character at the end of the record, and to either have no control characters imbedded in the records or to have the null-insertion option turned off.

 

[CliveC]

Well yes you are correct they would have to be fixed length line-sequential records. In fact I used a file with 9 8 byte records:
record 1
record 2
etc.

However you can create a line-sequential file with trailing blanks by moving a x'0A' to the record-length+1 position prior to writing the file.

I don't know whether it is by accident or design that notepad under XP allows you to put in trailing blanks.

       IDENTIFICATION DIVISION.
       PROGRAM-ID.    BDAMTEST.
       AUTHOR.        CLIVE CUMMINS.
       INSTALLATION.  TUBULARITY.
       DATE-WRITTEN.  OCT 15,2005.
       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
           SELECT BDAMTEST-FILE ASSIGN TO BDAMTEST-FILE-ID
                  FILE STATUS  IS BDAMTEST-RETURN-CODE
                  ACCESS MODE  IS RANDOM
                  ORGANIZATION IS RELATIVE
                  RELATIVE KEY IS BDAMTEST-RECORD-KEY.
       DATA DIVISION.
       FILE SECTION.
       FD  BDAMTEST-FILE.
       01  BDAMTEST-RECORD PIC X(08).
       WORKING-STORAGE SECTION.
       01  BDAMTEST-PARAMETERS.
           05  BDAMTEST-RETURN-CODE    PIC X(02).
           05  BDAMTEST-FILE-ID        PIC X(12) VALUE "BDAMFILE.TXT".
           05  BDAMTEST-RECORD-KEY     PIC 9(05) VALUE 9.
           05  BDAMTEST-RECORD-WORK    PIC X(08).
       PROCEDURE DIVISION.
           OPEN I-O BDAMTEST-FILE.
           PERFORM READ-BDAMTEST-FILE 9 TIMES.
           CLOSE BDAMTEST-FILE
           GOBACK.
       READ-BDAMTEST-FILE.
           READ BDAMTEST-FILE INTO BDAMTEST-RECORD-WORK.
           DISPLAY BDAMTEST-RECORD-WORK.
           SUBTRACT 1 FROM BDAMTEST-RECORD-KEY.

Clive

http://tubularity.com

http://PalliativeCareConsulting.org

http://port-lucaya.com

 

[Crox]

Hi Hofacket,

Realia has the option to read reversed. It works but it is less fast.

If your processing is making a copy with some changes... doesn't give that an easier program to maintain? In fact good programming is all about maintenance. You make it once but after that it is changed many times - at least at the offices I work for - because specifications are changed a lot.

Also if you have to add in carriage-return line-feeds or things like that, is there room for in the existing file? If so, you can use a rewrite statement to update the record. If there is no room inside the record, you have to copy it.

Regards,

Crox

 

[webrabbit]

We haven't heard back from hofacket. What have you discovered from this, hofacket?

 

[hofacket]

Thanks for all the suggestions.. Pretty much everything i tried failed and i ended up having to just read & write to a new file to get the results i needed..

If this wasnt a one time deal, i would get more into it and find a more efficient solution, but it got the job done.

Thanks again to everyone.

 

[WMK]

Dear hofacket,
Can you please tell us what compiler and operating system you are running on. Even if this IS a "one-time" issue for you, it might be nice for other readers if we could provide a "real" solution - which will only be possible when we know the ocmpiler.

P.S. "Line Sequential" is not an ANSI/ISO "standard" COBOL format, so this CERTAINLY won't have a "standard" (portable) solution.

Bill Klein

 

[baruch]

Hi all
As that said befor , in Micro Focus, any fixed line seq. file, can be tratead as a fixed ralativ file.

If you open output relative file & see the dump,
You can see that the recors end with 0D 0A, like a regular line seq. file.

That is a nice idea that must be adopted to ansi cobol standard.

It can be update such file in any text editor, or shiped from other systims, & then treated the file as relative file.

Tom, that will be nice if that method, will be also in RM/COBOL.

Baruch

 

[hofacket]

I tried 2 different compilers.. i used the Fujitsu compiler (which the client used) and also the AcuCobol compiler.

 

[k5tm]

Tom, that will be nice if that method, will be also in RM/COBOL.

Here we have the problem of interactions among the requirements of the COBOL standard and data transparency.


The COBOL standard spreads its requirements about files across several areas, but the end result is that relative files must be implemented in a manner that permits the detection of records that have been written or deleted/never written. (See file status codes 22 and 23.) If one were to implement relative files in the manner suggested by Baruch, then it follows that there must be some mechanism, strictly in the user data, to determine whether a record 'exists'.

There have been some implmentations of relative files that did use the user data area for indication of a deleted record. I would be willing to bet that the Tech Support department of such vendors has a set of stories about angry customers who fell into the trap of nontransparent data - accidentally 'deleting' some records.

Tom Morrison

http://www.liant.com

 

[k5tm]

hofacket,

You may find a solution in a BINARY SEQUENTIAL file, the record description of which is PIC X.

INPUT-OUTPUT SECTION.
FILE-CONTROL.
    select big-text assign [i]whatever[/i]
        organization binary sequential.
...
DATA DIVISION.
FILE SECTION.
FD  big-text.
01  big-text-char        PIC X.

All one can say about this approach is, "Some assembly (of the record) required." :-D

Tom Morrison

http://www.liant.com

 

[baruch]

Hi
I am also don't think that relative files is good idea to keep data in core main files.

But for temporary/working or from external system, a file that is a line seq. & relative in the same time, so for example , you can read the record back, can be useful.

Baruch

 

[ceh4702]

Whether something is ansi or not is really quite irrelevant. It may not be absolutely standard COBOL But even a mainframe compiler can handle variable length records. Maybe COBOL is not the best tool for the job. Files are just text characters one after another. A fixed length COBOL program does not care what is in a text file. It can read and write records all day and it will not care what is in each record. This is where a programmer has to be smarter than a rock.

If you do not like my post feel free to point out your opinion or my errors.