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


  1.  Home
  2. COBOL400-L
  3. June 2004

RE: working storage tables indexed by






Rick, 

Try defining

INDEX-TBL04    PIC S9(04) COMP-4. 
INDEX-TBL04-LO PIC S9(04) COMP-4  VALUE +1.

I know this works on our system.
 
D. Petrucelli.








Today's Topics:

   1.  I'm stumped - working storage tables indexed by 
      (rick.baird@xxxxxxxxxxxxxxx)
   2. RE:  I'm stumped - working storage tables indexed by 
      (Terry Grider)
   3.  RE: I'm stumped - working storage tables indexed by
      (rick.baird@xxxxxxxxxxxxxxx)
   4.  RE: I'm stumped - working storage tables indexed by
      (rick.baird@xxxxxxxxxxxxxxx)
   5. RE:  RE: I'm stumped - working storage tables indexed by
      (Terry Grider)
   6.  RE: I'm stumped - working storage tables indexed by -    WTF?
      (rick.baird@xxxxxxxxxxxxxxx)
   7. RE:  RE: I'm stumped - working storage tables indexed by
      -WTF? (Terry Grider)
   8.  RE: I'm stumped - working storage tables indexed
      (rick.baird@xxxxxxxxxxxxxxx)
   9. RE:  RE: I'm stumped - working storage tables indexed
      (Terry Grider)


----------------------------------------------------------------------

message: 1
date: Thu, 10 Jun 2004 14:04:28 -0500
from: rick.baird@xxxxxxxxxxxxxxx
subject: [COBOL400-L] I'm stumped - working storage tables indexed by 

what type and size is an table index field?

to save an index field, how what type and size of field should the result
of a 'SET' verb be?

can you directly compare the index field to the save field? - IF
INDEX-FIELD = SAVE-INDEX-FIELD

I'm having a problem with a program that's worked forever, until now - my
index field is getting hammered, making a move to a table element that
isn't in the bounds of the field.

Thanks,

Rick





------------------------------

message: 2
date: Thu, 10 Jun 2004 14:18:54 -0500
from: "Terry Grider" <Terry.Grider@xxxxxxxxxxxxxxxx>
subject: RE: [COBOL400-L] I'm stumped - working storage tables indexed
        by 

You can just define it like this:

 05  GROUP-ITEM-LOC USAGE IS INDEX.

You can now target a field defined this way in your set statement.

Terry Grider

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 2:04 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] I'm stumped - working storage tables indexed by 


what type and size is an table index field?

to save an index field, how what type and size of field should the result
of a 'SET' verb be?

can you directly compare the index field to the save field? - IF
INDEX-FIELD = SAVE-INDEX-FIELD

I'm having a problem with a program that's worked forever, until now - my
index field is getting hammered, making a move to a table element that
isn't in the bounds of the field.

Thanks,

Rick



_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.




------------------------------

message: 3
date: Thu, 10 Jun 2004 15:04:00 -0500
from: rick.baird@xxxxxxxxxxxxxxx
subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed
        by

Thanks Terry,

to move the saved index back to the original, do I move or set?

Rick,

---------original message------------
You can just define it like this:

 05  GROUP-ITEM-LOC USAGE IS INDEX.

You can now target a field defined this way in your set statement.

Terry Grider

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 2:04 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] I'm stumped - working storage tables indexed by


what type and size is an table index field?

to save an index field, how what type and size of field should the result
of a 'SET' verb be?

can you directly compare the index field to the save field? - IF
INDEX-FIELD = SAVE-INDEX-FIELD

I'm having a problem with a program that's worked forever, until now - my
index field is getting hammered, making a move to a table element that
isn't in the bounds of the field.

Thanks,

Rick




------------------------------

message: 4
date: Thu, 10 Jun 2004 15:20:56 -0500
from: rick.baird@xxxxxxxxxxxxxxx
subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed
        by

Also, how do you reset it to the first element in the table?

In the program I'm working on, (which has worked forever) does the
following types of things.

       01  FILLER.
           02  FILLER  OCCURS 200 INDEXED BY INDEX04.
             03  TBL04-INGREDIENT  PIC 9(06) COMP
                                    VALUE 0.
             03  TBL04-PRICE       PIC 9(02)V9(04) COMP
                                    VALUE 0.
             03  TBL04-MEASURE     PIC X(10).
             03  TBL04-DESCRIPTION PIC X(30).
           02  INDEX-TBL04        PIC 9(03) COMP.
           02  INDEX-TBL04-LO     PIC 9(03) COMP VALUE 001.

........... load table via INDEX04,

then save last index in INDEX-TBL04:

       SET INDEX-TBL04 TO INDEX04.

then later,

       SET INDEX04 TO INDEX-TBL04

then later,

      SET INDEX04 TO INDEX-TBL04-LO

still later,

      IF INDEX04 NOT EQUAL INDEX-TBL04
            SET INDEX-TBL04-LO TO INDEX04

later still,

           MOVE 1 TO INDEX-TBL04-LO.

in other words, saving, setting, searching, re-setting, between index
fields and simple 3 digit packed fields.

My problem is that at some point in the program, it gets a bad index, and
moves something into my table at the wrong starting position -
TBL04-INGREDIENT becomes X'0023F0F' -

I've stepped through it in debug, but no matter where or how I set the
breakpoint, i can't seem to catch it where it hoses the index. - it's
reading through about a hundred thousand records, and i've stopped it where
I think it's supposed to be changing the fields, but I keep missing.

any further guidance would be appreciated.





---------original message----------------
Thanks Terry,

to move the saved index back to the original, do I move or set?

Rick,

---------original message------------
You can just define it like this:

 05  GROUP-ITEM-LOC USAGE IS INDEX.

You can now target a field defined this way in your set statement.

Terry Grider

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 2:04 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] I'm stumped - working storage tables indexed by


what type and size is an table index field?

to save an index field, how what type and size of field should the result
of a 'SET' verb be?

can you directly compare the index field to the save field? - IF
INDEX-FIELD = SAVE-INDEX-FIELD

I'm having a problem with a program that's worked forever, until now - my
index field is getting hammered, making a move to a table element that
isn't in the bounds of the field.

Thanks,

Rick




------------------------------

message: 5
date: Thu, 10 Jun 2004 16:12:43 -0500
from: "Terry Grider" <Terry.Grider@xxxxxxxxxxxxxxxx>
subject: RE: [COBOL400-L] RE: I'm stumped - working storage tables
        indexed by

The way your table is defined with the fields that hold the indexes
following behind it, you could easily overwrite them if you tried to load
more that 200 entries in the table, which would probably trash them.  Make
sure that at every place in the program where entries are loaded to the
table, that you test the index to make sure you don't go beyond 200.  By the
way, when dealing with indexes, I always use SET to modify them and I
typically define index data items to save them in.  You might consider
moving the fields where your index is saved to a location in working storage
above the table where they wouldn't get overwritten and see if you get
different results.

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 3:21 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed
by


Also, how do you reset it to the first element in the table?

In the program I'm working on, (which has worked forever) does the
following types of things.

       01  FILLER.
           02  FILLER  OCCURS 200 INDEXED BY INDEX04.
             03  TBL04-INGREDIENT  PIC 9(06) COMP
                                    VALUE 0.
             03  TBL04-PRICE       PIC 9(02)V9(04) COMP
                                    VALUE 0.
             03  TBL04-MEASURE     PIC X(10).
             03  TBL04-DESCRIPTION PIC X(30).
           02  INDEX-TBL04        PIC 9(03) COMP.
           02  INDEX-TBL04-LO     PIC 9(03) COMP VALUE 001.

........... load table via INDEX04,

then save last index in INDEX-TBL04:

       SET INDEX-TBL04 TO INDEX04.

then later,

       SET INDEX04 TO INDEX-TBL04

then later,

      SET INDEX04 TO INDEX-TBL04-LO

still later,

      IF INDEX04 NOT EQUAL INDEX-TBL04
            SET INDEX-TBL04-LO TO INDEX04

later still,

           MOVE 1 TO INDEX-TBL04-LO.

in other words, saving, setting, searching, re-setting, between index
fields and simple 3 digit packed fields.

My problem is that at some point in the program, it gets a bad index, and
moves something into my table at the wrong starting position -
TBL04-INGREDIENT becomes X'0023F0F' -

I've stepped through it in debug, but no matter where or how I set the
breakpoint, i can't seem to catch it where it hoses the index. - it's
reading through about a hundred thousand records, and i've stopped it where
I think it's supposed to be changing the fields, but I keep missing.

any further guidance would be appreciated.





---------original message----------------
Thanks Terry,

to move the saved index back to the original, do I move or set?

Rick,

---------original message------------
You can just define it like this:

 05  GROUP-ITEM-LOC USAGE IS INDEX.

You can now target a field defined this way in your set statement.

Terry Grider

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 2:04 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] I'm stumped - working storage tables indexed by


what type and size is an table index field?

to save an index field, how what type and size of field should the result
of a 'SET' verb be?

can you directly compare the index field to the save field? - IF
INDEX-FIELD = SAVE-INDEX-FIELD

I'm having a problem with a program that's worked forever, until now - my
index field is getting hammered, making a move to a table element that
isn't in the bounds of the field.

Thanks,

Rick


_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.




------------------------------

message: 6
date: Thu, 10 Jun 2004 16:27:25 -0500
from: rick.baird@xxxxxxxxxxxxxxx
subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed
        by -    WTF?

ok,  now I'm really confused.

I put a watch on the variable to see when it gets changed (sign in the
middle of a packed field)

this is what I found:

Given the following working storage definitions:

      01  TBL03.
          02  TBL03A OCCURS 400 TIMES INDEXED BY INDEX03.
            03  TBL03-LLL   PIC 9(04) COMP.
            03  TBL03-ADDR  PIC X(25).
          02  INDEX-TBL03  PIC 9(04) COMP.

      01  TBL04.
          02  TBL04A  OCCURS 200 INDEXED BY INDEX04.
            03  TBL04-INGREDIENT  PIC 9(06) COMP.
            03  TBL04-PRICE       PIC 9(02)V9(04) COMP.
            03  TBL04-MEASURE     PIC X(10).
            03  TBL04-DESCRIPTION PIC X(30).
          02  INDEX-TBL04        PIC 9(03) COMP.
          02  INDEX-TBL04-LO     PIC 9(03) COMP VALUE 001.

my watch told me that TBL04-INGREDIENT(3) changed after executing this
line:

        SET INDEX03 TO INDEX-TBL03
-->        MOVE M2REST OF MENUS-REC TO TBL03-LLL(INDEX03)
        SET INDEX03 TO 1

how the heck does that happen?  The tables are in 2 separate spots, but
changing one overlays the other?

sounds like a bug to me....





------------------------------

message: 7
date: Thu, 10 Jun 2004 16:44:14 -0500
from: "Terry Grider" <Terry.Grider@xxxxxxxxxxxxxxxx>
subject: RE: [COBOL400-L] RE: I'm stumped - working storage tables
        indexed by      -WTF?

If the value of  INDEX-TBL03 is something greater than 400, then it will
cause index03 to point to memory past TBL03 which would be TBL04.  Check for
that and see what's in  INDEX-TBL03.

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 4:27 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed
by -WTF?


ok,  now I'm really confused.

I put a watch on the variable to see when it gets changed (sign in the
middle of a packed field)

this is what I found:

Given the following working storage definitions:

      01  TBL03.
          02  TBL03A OCCURS 400 TIMES INDEXED BY INDEX03.
            03  TBL03-LLL   PIC 9(04) COMP.
            03  TBL03-ADDR  PIC X(25).
          02  INDEX-TBL03  PIC 9(04) COMP.

      01  TBL04.
          02  TBL04A  OCCURS 200 INDEXED BY INDEX04.
            03  TBL04-INGREDIENT  PIC 9(06) COMP.
            03  TBL04-PRICE       PIC 9(02)V9(04) COMP.
            03  TBL04-MEASURE     PIC X(10).
            03  TBL04-DESCRIPTION PIC X(30).
          02  INDEX-TBL04        PIC 9(03) COMP.
          02  INDEX-TBL04-LO     PIC 9(03) COMP VALUE 001.

my watch told me that TBL04-INGREDIENT(3) changed after executing this
line:

        SET INDEX03 TO INDEX-TBL03
-->        MOVE M2REST OF MENUS-REC TO TBL03-LLL(INDEX03)
        SET INDEX03 TO 1

how the heck does that happen?  The tables are in 2 separate spots, but
changing one overlays the other?

sounds like a bug to me....



_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.




------------------------------

message: 8
date: Thu, 10 Jun 2004 16:56:24 -0500
from: rick.baird@xxxxxxxxxxxxxxx
subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed

Wow, I never would have guessed.  but after I sent that last email, that's
what I figured out myself.  I increased the size of the tbl03 and
everything is hunkydory.

Gosh, I wish I didn't have to debug cobol... :)

So, in review, indexes are sort of like a pointer field?  (rpg or C)

what happens if you keep adding to the index, and it fills up all space
allocated to the program?  does it try to overwrite memory outside it's
bounds and blow up?

What's the benefit of indexing rather than subscripting tables?

Thanks again,

Rick

------original message-----------
If the value of  INDEX-TBL03 is something greater than 400, then it will
cause
index03 to point to memory past TBL03 which would be TBL04.  Check for that
and
see what's in  INDEX-TBL03.

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 4:27 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed
by -WTF?


ok,  now I'm really confused.






------------------------------

message: 9
date: Thu, 10 Jun 2004 18:39:39 -0500
from: "Terry Grider" <Terry.Grider@xxxxxxxxxxxxxxxx>
subject: RE: [COBOL400-L] RE: I'm stumped - working storage tables
        indexed

I work mostly with Realia PC Cobol now and I can't remember the error you
would get on an AS400, but it would be some kind of storage violation.  On
the PC, you can set an option to validate the range of subscripts and
indexes so you might want to look at your compiler directives and see if you
have the same thing.

The advantage of indexes over subscripts is speed, but with today's
hardware, you probably wouldn't notice much.  Subscripts have to be
converted to come up with the offset address of each table entry whereas the
index is already a hex offset to the table entry.

As for having to debug Cobol, RPG looks more like Cobol all the time.  I'm
old enough to remember when RPG didn't have IF statements or EVAL or
Freeform Support or Data Structures, not even Read Statements.  Now an RPG
program written with the newest language features looks almost just like
Cobol and please, no language wars.  We all have our opinions about the
languages we like.  I happen to appreciate each one for its appropriateness
to the task at hand.  I would probably even like Java if someone would just
force it down my throat!  :)

Terry

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 4:56 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed


Wow, I never would have guessed.  but after I sent that last email, that's
what I figured out myself.  I increased the size of the tbl03 and
everything is hunkydory.

Gosh, I wish I didn't have to debug cobol... :)

So, in review, indexes are sort of like a pointer field?  (rpg or C)

what happens if you keep adding to the index, and it fills up all space
allocated to the program?  does it try to overwrite memory outside it's
bounds and blow up?

What's the benefit of indexing rather than subscripting tables?

Thanks again,

Rick

------original message-----------
If the value of  INDEX-TBL03 is something greater than 400, then it will
cause
index03 to point to memory past TBL03 which would be TBL04.  Check for that
and
see what's in  INDEX-TBL03.

-----Original Message-----
From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx]
Sent: Thursday, June 10, 2004 4:27 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: [COBOL400-L] RE: I'm stumped - working storage tables indexed
by -WTF?


ok,  now I'm really confused.




_______________________________________________
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
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) digest list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.



End of COBOL400-L Digest, Vol 2, Issue 61
*****************************************


**************Internet Email Confidentiality Footer**************



Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person), you may
not copy or deliver this message to anyone. In such case, you
should destroy this message and kindly notify the sender by
reply email. Please advise immediately if you or your employer
do not consent to Internet email for messages of this kind.
Opinions, conclusions and other information in this message
that do not relate to the official business of HSS, Inc. shall
be understood as neither given nor endorsed by it.

As an Amazon Associate we earn from qualifying purchases.

This thread ...
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.