IBM Mainframe Forum

Hi, all:


First off, thank you for providing this resource.

I'm having a bit of trouble comprehending indexes and PERFORM...VARYING statements. I'm using Cobol Unleashed as a resource, but the examples there are apparently too advanced for me. I also looked the manuals and searched this forum.

This is what I have:



New office codes begin every 9 characters. Think of it as:



So, each office will have up to 87 names.

I want to MOVE DEPT AND OFFICES TO the field below until spaces are encountered:



Then DISPLAY DEPT-AND-OFFICE as follows:



Any help you can provide will be appreciated.

I did not quite understand your post completely. But, I presume you are trying the build and store data the OFFICES array. This is how you would do it -



Thank you very much.

These users thanked the author Quasar for the post:

abnk (Fri Mar 29, 2013 9:37 pm)

I think part of your problem comes from not having data structures defined correctly. A table key should, but does not have to be, a unique value (as long as you are doing sequential searches). It is not clear from what you posted whether there will be up to 87 code1 and code2 values per department, or if there is 1 code1 / code2 combination per department.

Assuming the latter, one possible way (but certainly NOT the only way) to define and access the data you posted would be:

These users thanked the author Robert Sample for the post:

abnk (Fri Mar 29, 2013 9:38 pm)

Robert is correct "I think part of your problem comes from not having data structures defined correctly "
There are other problems such as your table only being 87 instances yet your input can hold up to 555 entries.

Alas, here is another alternative for your requirement.
This code moves your X(5000) into the array for processing.
Then moves the instances of the array to the output layout for display
Note: rather than display you can put it out to a file or whatever.

I am hoping that this code will at least get you going in the right direction.
PM

These users thanked the author pmartyn for the post:

abnk (Fri Mar 29, 2013 9:38 pm)

I would also advise that having a variable called WORKING-STORAGE is bad as it could be confused with the WORKING-STORAGE SECTION name.

These users thanked the author NicC for the post:

abnk (Fri Mar 29, 2013 9:38 pm)

You may be able to tell that we don't necessarily understand what you are trying to do.

Your first step is definitely to get your data structures sorted out. We have no idea how the OCCURS 87 and the 5000 relate to each other.

Separately from sorting out the data definition, get to know how to hand "tables" and "subscripting" by starting out with something very easy and becoming very familiar with it.

This you may have to read through several times, but don't worry. It does have some element of confusion, as you'll see from the explanation, but get some grip on it first, then try the really simple example, and through that become familiar with how to use single-dimension Cobol "subscripting". You'll use it a lot. There are a few more dimensions available, but leave those aside for now.

To reference data within a table (a data structure with OCCURS) you use "subscripting".

There are three ways to specify a subscript: a literal; a subscript (numeric data-name not directly related to table); an index (compiler-defined and managed storage, connected to table by name you give it).


These uses are all called "subscripting" although using an index is also sometimes called "indexing".

A "subscript" is just a numeric item that you define. It is best if it is BINARY or COMP or COMP-4 or COMP-5. It's value when reference a table should be between 1 (one) and the maximum number of table entries. As it is a "normal" data definition, you can use all the normal verbs to manipulate it.

An "index" is defined by INDEXED BY on the OCCURS clause of the table. The Compiler defines the storage for it. You can only change the value of an index by SET, PERFORM ... VARYING ... and SEARCH/SEARCH ALL. An index can be used in conditions and of course for subscripting.

To add a little complexity, there is also USAGE INDEX. This is a field that you define in the DATA DIVISION but which has no PICture clause (meaning the Compiler defines the size and type of the storage). This, using the SET statement, can be used to store the value of an index (an INDEXED BY item), for instance the maxiumum number of entries in a table, expressed as an INDEX.

What does "expressed as an INDEX mean"? This relates to the difference between a subscript and an index. A subscript is just an integer. An index is the "offset" or "displacement" from the start of the table of the particular entry in the table whose value it is SET to.

If you SET an index to 1, the actual content of the index is zero, indicating the entry which is displacement zero from the start of the table, ie the first entry. If you SET an index to 2, the actual content of the index is the length of the entry, ie a displacement from the start of the table which arrives at the 2nd entry. SET an index to 3, and it has the value 2 times entry-length. Etc.

When you SET a USAGE INDEX item to the value of an index name, the "displacement" that the index contains is preserved in the USAGE INDEX item. When you SET an index to a USAGE INDEX item, the compiler knows that it already contains a displacement.

With a SET to a non-USAGE INDEX value, the compiler knows it is an "entry", and calculates the displacement of that entry, and sets the value of the index to that.

This sounds more complicated than it is, partly because of the mixed-nomenclature (subscript, subscripting, index, indexing, USAGE INDEX) and partly because you just haven't done it yet.

Another confusion is "reference modification" which looks a bit like subscripting, but isn't. The longer you can avoid reference-modification, the better (there are examples already in this topic).

The thing to do is to read the manual, the book, try out something really simple, see what happens, and go back to the manual/book to see if you now understand, if not, try again.



You should try to come up with a number of ways to produce this output:



using DISPLAY A-DIGIT ( something )

As a start, here's the easiest



Don't worry if you don't get it first time, just be systematic. Read. Experiment. Read. Continue until understood. If you have problems, or are unclear about something, just post here.

These users thanked the author BillyBoyo for the post (total 2):

pmartyn (Fri Mar 29, 2013 9:40 pm) • abnk (Fri Mar 29, 2013 9:39 pm)

Thank you, all.

Quasar, I am actually trying to do the opposite--MOVE DEPT and OFFICES TO DEPT-AND-OFFICE.

This is what I think it should be:




Robert Sample, sorry for the confusion of the data definition. There are 87 code1/code2 combinations for each department. Why PIC X(5000) and OCCURS 87 TIMES don't make sense, is actually a separate problem and perhaps I should have not added it here. I am READing from a variable length VSAM file. This is the actual copybook:



However, I kept getting failures to read with this definition, so I changed the record length to the maximum length of the VSAM file, which is 5000. This way, I was able to get past the failure to read.

If I MOVE DEPT and OFFICES TO DEPT-AND-OFFICE (after increasing DEPT-AND-OFFICE to PIC X(788), [DEPT PIC(5) + OFFICES PIC X(9) * 87 occurrences]), the output is this (not actual values):



What I want is this:



I will read the rest of the replies carefully before replying.

I am READing from a variable length VSAM file.

Does your COBOL program understand that the vSAM file is variable length? Look at the compiler output to see how the file is listed -- fixed or variable.

To make a file variable length, you must (1) provide more than one 01 level for the FD where at least one 01 in the FD has a different record length, or (2) use OCCURS DEPENDING ON in the 01 definition of the FD, or (3) use RECORD VARYING in the FD. Note that it is NOT enough to merely specify RECORD FORMAT V since this allows for fixed-length or variable length records, per the COBOL manual. The copy book you posted would NOT make the file variable length but fixed length, and the file read errors would make sense.

The data you posted looks like what would be expected for the data structure you described, although a mainframe COBOL program would NOT display the datga the way you showed. To get the output you want, you need to change your PROCEDURE DIVISION statements toThere is no reason to have the DEPT-AND-OFFICE variable at all. DISPLAY can have one or more variables as well as one or more literals up to the compiler limit.

These users thanked the author Robert Sample for the post:

abnk (Sat Mar 30, 2013 12:18 am)

pmartyn, thank you for taking the time you write the code. It helps.

NicC, thank you for the advice. I can see how that is confusing.

BillyBoyo, I read your post a few times and each time it makes more sense. It is exactly what I needed to read and more. I will practice with the example you provided. Thank you very much.