× 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.


  • Subject: Re: S36 Index Sort and Record Not Found
  • From: Jim Langston <jlangston@xxxxxxxxxxxxxxxx>
  • Date: Mon, 03 Jul 2000 08:34:38 -0700

This is an alternative, but wouldn't I have to change both the OCL and
RPG program to read from the logical instead of the index file?

An alternative I have considered is building a logical file, and change it
to MAINT(*RBLD) or MAINT(*DELAY) just so the system doesn't
have to use so many resources to maintain it.  Then I would have to
change the RPG program to read this file instead of the CMFile and
the index file.

I just don't want to have to maintain these things as they are going to
be dying a natural death in 6 months or so.

Regards,

Jim Langston

Norm Dennis wrote:

> Jim,
> the sort routine looks to be creating an alpha sequence file which I assume
> to be customer name. Is there any additional sort criteria to confirm this?
> If so, a BLDINDEX or CRTLF to replace the sort would handle any
> interim maintenance/deleting of records.
> The RECORDS entry does specify the number of records to create
> the file size but it does not create blank entries unless the file created
> is
> a DIRECT (old format no longer used) file.
> The RETAIN-J indicates the file is only retained for the duration of the
> job, so you may want to delete any alternate index or logical file that
> you create.
>
> Have a good one,
>
> Norm
>
> ________________________________________________________
> My web site is - http://www.iinet.net.au/~wmss - have a look around.
>
> ----- Original Message -----
> From: "Jim Langston" <jlangston@conexfreight.com>
> To: <RPG400-L@midrange.com>
> Sent: Saturday, 1 July 2000 3:01
> Subject: S36 Index Sort and Record Not Found
>
> > We still have a number of S/36 reports on our system that are going to die
> a natural death.
> > This use the indexed sort for an RPG program, and we commonly get an RPG
> error stating
> > the record is not found.  It is a big pain to keep typing I for ignore to
> get these things to continue.
> >
> > So, my questions are, what is wrong and how do I fix it?
> >
> > Sort cryteria:
> >      // LOAD #GSORT
> >      // FILE NAME-INPUT,LABEL-CMFILE,DISP-SHR
> >      // FILE NAME-OUTPUT,LABEL-ASCM1540,RECORDS-00040196,RETAIN-J
> >      // RUN
> >           HSORTA    25A        3X       N
> >
> > Output according to Job Cryteira
> >      34031 records read and 30009 records selected from CMFILE in library
> QS36F
> >        mbr CMFILE.
> >      34031 total records read, and 30009 total records selected.
> >      30009 RA entries placed in output file ASCM1540 in library QTEMP mbr
> >        M000629.
> >      REQUEST SUCCESSFUL 06/29/00 14:42:51.
> >
> > Then we run a S/36 RPG program:
> >     // LOAD CM1540
> >     // FILE NAME-ASCM1540,DISP-SHR
> >     // FILE NAME-CUSMAS,DISP-SHR
> >     // FILE NAME-EQPMST,DISP-SHR
> >     // FILE NAME-CMFILE,DISP-SHR
> >     // RUN
> >
> > It opens the files:
> > 0020.00 0020 FCMFILE  IP  F4480 448R16II     1 DISK                   300
> > 0021.00 0021 FASCM1540IR    300   3  3IT      EDISK
> > 0022.00 0022 FCUSMAS  IC  F 180 180R 5AI     1 DISK                    80
> > 0023.00 0023 FEQPMST  IC  F  80  80R11AI     1 DISK                   100
> > 0024.00 0024 FPRINTER O     132 132     OF     PRINTER
> > 0025.00 0025 FPRINTER2O     132 132     OA     PRINTER
> > 0026.00 0026 E    ASCM1540CMFILE
> >
> > I uses the RPG cycle as you can see.  When the program runs sometimes (if
> not all the time) we
> > get errors we have to answer:
> >
> >  Message ID . . . . . . :   SSP0352
> >  Date sent  . . . . . . :   06/30/00      Time sent  . . . . . . :
> 11:47:49
> >
> >  Message . . . . :   RPG9035 Options ( 123F)
> >                   No record was found on read operation for file CMFILE.
> >
> >  Cause . . . . . :   The RPG program CM1540 in library CNXY2K at statement
> >    00000000 is trying to read a record that does not exist.  For an
> indexed
> >    file, there is no record containing the key value specified.  For a
> direct
> >    file or file processed by address output file, the relative record
> number is
> >    in the file, but it is a deleted record.
> >
> > We just had the sort procedure sort the address output file, so it
> shouldn't contain
> > deleted records, correct?
> >
> > Does anyone have a clue?  We have to keep selecting reply 1 over and over
> and over
> > to get these things to finish.
> >
> > P.S. I just re-read this note before I sent it and noticed the line:
> >      // FILE NAME-OUTPUT,LABEL-ASCM1540,RECORDS-00040196,RETAIN-J
> >
> > That RECORDS-00040196: Does that tell the sort to create the output file
> with 40,196 records,
> > and since there's only 30,009 that over 10,000 records contain blank info?
> I doubt it, as I know
> > we have to reply 1 a lot of times, but surely not 10,000 times!
> >
> > Regards,
> >
> > Jim Langston
> >
> > +---
> > | This is the RPG/400 Mailing List!
> > | To submit a new message, send your mail to RPG400-L@midrange.com.
> > | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
> >
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.