Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I don't know for certain if this is the problem, but I can see a logic flow that isn't going to work very well...</p> <p>First: <code>400-SALESMAN-NAME</code> reads salesmen records from a file into working storage table <code>SALESMAN-TABLE</code>. </p> <p>The file probably looks something like:</p> <pre><code>01Sales Guy One 02Lance Winslow 03Scott Peterson 04Willy Loman </code></pre> <p>When the read loop is done, <code>SALESMAN-NUMBER</code> will equal the table index because of the way you load the table (using <code>SM-NUMBER-IN</code> to set the table subscript). No problem so far...</p> <p>Next: <code>500-PROCESS-FILE</code> loops through all rows in the <code>SALESMAN-TABLE</code> by running subscript <code>ROUTINE-CHECK</code> from 1 to 99 and performing <code>510-TABLE-SEARCH</code> to write out the report for the salesman where the subscript equals <code>SALESMAN-NUMBER</code>...</p> <p>Next: The <code>SEARCH</code> statement. This is where it all goes strange and never performs <code>520-WRITE-FILE</code>. This is why.</p> <p>The <code>SEARCH</code> statement implements a linear search (<code>SEARCH ALL</code> is a binary search). <code>SEARCH</code> just increments the index associated with the searched table and then runs through a bunch of <code>WHEN</code> tests until one of them "fires" or the index runs off the end of the table. The index for your <code>TABLE-ENTRIES</code> table is <code>IND-TABLE-ENTRIES</code>. But you never set or reference it (this is the root of the problem). I will explain in a moment...</p> <p>Notice that the <code>WHEN</code> part of your <code>SEARCH</code> is using subscript <code>ROUTINE-CHECK</code>. <code>ROUTINE-CHECK</code> was set in <code>500-PROCESS-FILE</code>. Also notice that you only get to <code>520-WRITE-FILE</code> if the <code>SALESMAN-NUMBER</code> matches the value of <code>ROUTINE-CHECK</code> - which it will do if a salesman with that number was read from the input file. This could work because you loaded the table such that the row number equals the salesman number back in <code>450-TABLE-LOAD</code>.</p> <p>Now, what happens if the input file does not contain a salesman where <code>SM-NUMBER-IN</code> equals 01?</p> <p>Lets go through it, blow by blow...</p> <p><code>ROUTINE-CHECK</code> is set to 1, <code>SEARCH</code> is invoked and because the <code>IND-TABLE-ENTRIES</code> index associated with the searched table is less than the number of occurs in the table (it got initialized to zero on program load), the <code>WHEN</code> clauses are executed. </p> <p>The first test is <code>WHEN SALESMAN-NUMBER (ROUTINE-CHECK) = ROUTINE-CHECK</code>. Since Salesman 1 doesn't exist, the <code>SALESMAN-NUMBER</code> will be zero and the test fails (0&lt;>1). </p> <p>The next <code>WHEN</code> clause is tried and it succeeds because (0=0); but this is a 'do nothing' option so another cycle of SEARCH is entered <strong>after <code>IND-TABLE-ENTRIES</code> is incremented</strong>. </p> <p>Same results on this and all subsequent iterations through the <code>SEARCH</code>ed WHEN list (none of the clauses match)... Repeat this loop until <code>IND-TABLE-ENTRIES</code> is incremented beyond the end of the table. </p> <p>At this point the <code>SEARCH</code> terminates and control flows back to the next loop in <code>500-PROCESS-FILE</code>. Nothing has been printed.</p> <p><code>500-PROCESS-FILE</code> then increments <code>ROUTINE-CHECK</code> by 1 (now it is 2). We have a salesman with a <code>SALESMAN-NUMBER</code> of 02 so we should get some output - right? Wrong! But why?</p> <p>If you read up on the <code>SEARCH</code> verb you will find it does not reset the table index (in this case: <code>IND-TABLE-ENTRIES</code>). It starts using whatever value it has when the SEARCH is entered. You never reset it so it is already set beyond the end of the table. SEARCH just terminates and nothing gets printed - ever again. </p> <p><strong>Fixing the problem</strong></p> <p>Given that you have loaded <code>TABLE-ENTRIES</code> by salesman number in the first place, I don't see the purpose of using SEARCH. Just do something like:</p> <pre><code>500-PROCESS-FILE. PERFORM VARYING ROUTINE-CHECK FROM 1 BY 1 UNTIL ROUTINE-CHECK &gt; 99 IF SALESMAN-NUMBER (ROUTINE-CHECK) = ZERO CONTINUE ELSE PERFORM 520-WRITE-FILE END-IF END-PERFORM. </code></pre> <p>Might also be a good idea to have an initialization loop for the table so that every SALESMAN-NUMBER is explicitly set to zero before you read the salesman file.</p> <p>If you must use SEARCH in this program, then don't forget to set and use the associated table index variable when referencing the table being searched.</p>
    singulars
    1. This table or related slice is empty.
    1. POA Strange Error (COBOL)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USNealB
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POA Strange Error (COBOL)
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CONice analysis. I skipped it because the OP wrote that the program is running OK in debug mode. How could be?
      singulars
      1. PO
      1. USDr. belisarius
    2. COThis one makes it work, but now a couple of the fields that were reading on the previous version aren't now. At least it is reading now. I will figure it out from here, thanks!
      singulars
      1. PO
      1. USKimmy1235
    3. CO@belisarius. I think the OP may have been picking up a different file under the debugger, one with numbers ranging from 1 through to however many records he had - which would make the program "work" as expected. Always best to read the code.
      singulars
      1. PO
      1. USNealB
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload