Your problem is in the way IBM handles the SETLL with multi-format logical
files.
When you use a record format name, the data management routines search the
entire logical file access path for a key equal or greater with the
SPECIFIED FORMAT NAME.  If there are few records for that format, the search
could take a Loooooonnnnnngggg time!
What I have done in that case is create a separate logical file and either
chain or SETLL on that file.

This has been the case since the S/38 days!


----- Original Message -----
From: Roger Boucher <RBoucher@stanpac.com>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, July 26, 1999 2:37 PM
Subject: RE: Sanity check


Thanks Simon.  The offending SETLL is using one of the two format names
(MNTHAP).  The SETLL on the other format name (when loading the first half
of the split screen subfile) does not take long at all.

When record is not found it simply drops out of the loop rather than loading
record to the subfile.  The logical does not use DYNSLT.  The database is,
for all intents and purposes, frozen and has been for about one year.

The SETLL and the READE are all by partial key (the first key - invoice
number - of four keys).  Neither physical has any deleted records.  I do not
profess to be proficient at all the intricacies,  but I did notice some
interesting things regarding the number of file members...

Here are the physical file descriptions...

Note:  C7MTAP is the physical over which the "slow" format is built.

File C7MTAP:
Member List
                         Source Creation    Last Change
 Member           Size    Type  Date       Date     Time      Records
 ALEX              10240        03/11/96 07/20/97 21:16:23          1
   Text:
 C7MTAP            10240        03/11/96 07/20/97 21:16:23          0
   Text:  Monthly Accounts Payable File
 YOUNG             18432        03/13/96 07/20/97 21:16:23         11
   Text:
 Total number of members  . . . . . . . . . . :               3
 Total number of members not available  . . . :               0
 Total records  . . . . . . . . . . . . . . . :              12
 Total deleted records  . . . . . . . . . . . :               0
 Total of member sizes  . . . . . . . . . . . :           38912

File C8HIST:
Member List
                         Source Creation    Last Change
 Member           Size    Type  Date       Date     Time      Records
 MBR01         286279680        08/08/86 06/25/99 07:38:49    1122007
   Text:  Accounts Payable History Physical File
 MBR02             23552        08/08/86 07/20/97 23:57:35         58
   Text:  archive member
 MBR03              9216        01/20/89 07/20/97 23:57:35          0
   Text:
 Total number of members  . . . . . . . . . . :               3
 Total number of members not available  . . . :               0
 Total records  . . . . . . . . . . . . . . . :         1122065
 Total deleted records  . . . . . . . . . . . :               0
 Total of member sizes  . . . . . . . . . . . :       286312448


and here is the logical file description:

Files accessed by logical file              PFILE
   File               Library              LF Format
   C7MTAP             SP1LIB               MNTHAP
   C8HIST             SP1LIB               APHIST

Number of data members  . . . . . . . . . :              7
Based on file . . . . . . . . . . . . . . :            C7MTAP
  Library . . . . . . . . . . . . . . . . :            SP1LIB
  Member  . . . . . . . . . . . . . . . . :            MBR01
  Logical file format . . . . . . . . . . :            MNTHAP
  Number of index entries . . . . . . . . :                     1
  Number of member accesses . . . . . . . :                     0
Based on file . . . . . . . . . . . . . . :            C7MTAP
  Library . . . . . . . . . . . . . . . . :            SP1LIB
  Member  . . . . . . . . . . . . . . . . :            MBR02
  Logical file format . . . . . . . . . . :            MNTHAP
  Number of index entries . . . . . . . . :                    10
  Number of member accesses . . . . . . . :                     0
Based on file . . . . . . . . . . . . . . :            C7MTAP
  Library . . . . . . . . . . . . . . . . :            SP1LIB
  Member  . . . . . . . . . . . . . . . . :            MBR03
  Logical file format . . . . . . . . . . :            MNTHAP
  Number of index entries . . . . . . . . :                     0
  Number of member accesses . . . . . . . :                     0
Based on file . . . . . . . . . . . . . . :            C7MTAP
  Library . . . . . . . . . . . . . . . . :            SP1LIB
  Member  . . . . . . . . . . . . . . . . :            MBR04
  Logical file format . . . . . . . . . . :            MNTHAP
  Number of index entries . . . . . . . . :                     0
  Number of member accesses . . . . . . . :                     0
Based on file . . . . . . . . . . . . . . :            C8HIST
  Library . . . . . . . . . . . . . . . . :            SP1LIB
  Member  . . . . . . . . . . . . . . . . :            MBR01
  Logical file format . . . . . . . . . . :            APHIST
  Number of index entries . . . . . . . . :               1122007
  Number of member accesses . . . . . . . :                     0
Based on file . . . . . . . . . . . . . . :            C8HIST
  Library . . . . . . . . . . . . . . . . :            SP1LIB
  Member  . . . . . . . . . . . . . . . . :            MBR02
  Logical file format . . . . . . . . . . :            APHIST
  Number of index entries . . . . . . . . :                    58
  Number of member accesses . . . . . . . :                     0
Based on file . . . . . . . . . . . . . . :            C8HIST
  Library . . . . . . . . . . . . . . . . :            SP1LIB
  Member  . . . . . . . . . . . . . . . . :            MBR03
  Logical file format . . . . . . . . . . :            APHIST
  Number of index entries . . . . . . . . :                     0
  Number of member accesses . . . . . . . :                     0


-----Original Message-----
From: Simon Coulter [mailto:shc@flybynight.com.au]
Sent: Friday, July 23, 1999 10:17 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Sanity check



Hello Roger,

Is the SETLL using a format name or a file name?  Does the code do anything
else when the
record is not found?  Is the code behaving identically for found records and
not found
records?

Does the LF38 use DYNSLT?  Perhaps the database has changed sufficiently
over the years to
result in a sparse index and DB is simply taking a while to dynamically
check the records --
although you should see signs of that with found records also.

One other possibilty is to check the number of deleted records in the file.
When was the last
time a RGZPFM was performed?

Regards,
Simon Coulter.


 FlyByNight Software         AS/400 Technical Specialists       
 Eclipse the competition - run your business on an IBM AS/400.  
                                                                
 Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           
 Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      
                                                                
 Windoze should not be open at Warp speed.                      

file://--- forwarded letter
-------------------------------------------------------
> X-Mailer: Internet Mail Service (5.5.2448.0)
> Date: Fri, 23 Jul 99 16:21:48 -0700
> From: "Roger Boucher" <RBoucher@stanpac.com>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Sanity check

>
> I have a user (controller) who swears up and down that an invoice inquiry
on
> our legacy system (an old AS/400 kept around for inquiry purposes only) is
> taking much longer than it used to.  I tested it and found that it works
> quickly if record is found and takes about 30 seconds when record not
found.
> The problem point (debug) seems to be a SETLL statement on a multi-record
> format LF38.  The logical is not damaged, the physicals on which it is
based
> are not damaged.  The Edit Rebuild of Access Paths screen shows nothing
> pending.
>
> Does anyone know anything else to look for?
> Or Is this just a case of selective memory on the part of our friendly
> neighborhood user?
>
> Any help would be appreciated...
> Thanks.
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
>

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

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


This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2020 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].