× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Greetings;

Is the file configured to reuse deleted records?  If so, the new records
could appear anywhere in the file.

Just a thought.

Jim

At 03:43 PM 5/6/2002 +0200, you wrote:
>This is a multipart message in MIME format.
>--
>[ Picked text/plain from multipart/alternative ]
>Velazar.
>
>You do not say if your physical file has a key or not, and you do not say
>how you browse your file(DFU/QUERY/others).
>
>My experience is like this:  Normally, if you write to a file, the records
>will be added on by one to the end of the physical file(if it doesn't have
>a key).  You  can write via a logical file, but still the records will be
>found at the end of the non-keyed physical file(using DFU).  If your
>physical file has a key,  or you browse a logical file, the records will
>be found in key-sequence, of course.
>
>
>Mvh.
>
>Geir Kildal
>
>
>
>
>
>
>veleazar@gseguros.com
>Sent by: cobol400-l-admin@midrange.com
>06.05.2002 13:32
>Please respond to cobol400-l
>
>
>         To:     cobol400-l@midrange.com
>         cc:
>         Subject:        Order of writen records.
>
>
>Este es un mensaje de varios componentes en formato MIME.
>--
>--
>[ Picked text/plain from multipart/alternative ]
>Hi every one.
>
>I need some help (any would be thank) to fix a problem I have when writing
>into a file from 2 diferent subprograms calles from the same main program
>on the same execution.
>
>I have a main program (A) calling 2 programs (B and C). They are all cobol
>programs and A is called fron a main CL program. There is a file (F) 800
>positions long that would recive information from programs B and C.
>
>
>
>The sistem works this way:
>
>A starts and begin the cicle:
>- A calls B. B opens file F and writes 2 records and goes back.
>- A calls C. C opens file F,  writes 8 records to file F and goes back.
>- A calls B again and B writes 2 new records to file F and goes back.
>the cicle terminates and A finishes.
>
>File F is never closed but at the end when probrams B and C are called and
>should never be, cause there could be 1000's of cicles like this in a
>single execution.
>
>When the file is browsed I find the 'C' records first and all the 'B'
>records together at the end.
>
>I think the records order has somthing to do with the buffer size and the
>usage of a diferent path to acces F for each program B and C.
>
>Is there any way to force the order of the records as they were writen?
>
>
>Virgilio Eleazar Rodríguez Domínguez
>Tel: 963 87 59 00 ext. 6156
>Aseval, S.A.
>--
>[ Content of type image/gif deleted ]
>_______________________________________________
>This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing
>list
>To post a message email: COBOL400-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l
>or email: COBOL400-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/cobol400-l.
>
>
>_______________________________________________
>This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
>To post a message email: COBOL400-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l
>or email: COBOL400-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/cobol400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.