IBM Mainframe Forum

Sample of Records in file.

CustomerId Month Expense(in $)
34 Jan 700
46 Feb 800
57 Nov 900
78 Dec 1200
34 Jan 400
57 Nov 500
89 Mar 400
67 Jun 600
57 Aug 1400
34 Sep 500

CustomerId--- 9(2)
Month----------x(3)
Expense--------9(4)

How to find customerid's which have expense more than 1000 in a one month (with that month and total expense in it.) in Cobol ?

Expand on the previous solution you were given. Two-dimensional table, using customer-id converted to suitable index/subscript. flush/initialise table on change of customer-id. don't forget to do the last cutsomer-id flushing.

BillyBoyo wrote:Expand on the previous solution you were given. Two-dimensional table, using customer-id converted to suitable index/subscript. flush/initialise table on change of customer-id. don't forget to do the last cutsomer-id flushing.

What Billy has proposed is absolutely corect. But, in case if you want to retain the entire data read till you exit the program, you can use an additional one-dimensional array to store the conumer-id & a two-dimensional array to compute the total expenditure of that consumer in a given month. Both the arrays will store corresponding information at the same index. For e.g. -
Array 1 - Row 1 - Cons 1
Array 2 - Row 1/Column1 - Total Exp. by Cons 1 in Jan
Array 2 - Row 1/Column2 - Total Exp. by Cons 1 in Feb
Array 2 - Row 1/Column3 - Total Exp. by Cons 1 in Mar & so on.

Thanks & Regards,
Nikhil

Nik22Dec wrote:[...] in case if you want to retain the entire data read till you exit the program, you can use an additional one-dimensional array to store the conumer-id & a two-dimensional array to compute the total expenditure of that consumer in a given month. Both the arrays will store corresponding information at the same index. For e.g. -
Array 1 - Row 1 - Cons 1
Array 2 - Row 1/Column1 - Total Exp. by Cons 1 in Jan
Array 2 - Row 1/Column2 - Total Exp. by Cons 1 in Feb
Array 2 - Row 1/Column3 - Total Exp. by Cons 1 in Mar & so on.

Thanks & Regards,
Nikhil

The original post is clearly a class exercise, with a two-digit Customerid. Make the Customerid a more realistic size and you get to the "I wonder if it'll fit into Cobol" question. And what is it you propose storing? For customer 1, the value 1, for customer 28, the value 28, for customer 3487261, 3487261.

Also, as we are talking about IBM Cobol, you should standardise on how to refer to data defined by the use of an OCCURS. It is not an "array". Also your Row/Column terminology is flawed. What do you call the third level when you have three levels of OCCURS? And 3rd-7th when you have seven levels?

Hi Billy,

I unconditionally agree!! I guess my C++ background took its toll. Sorry for the confusion.Can you please elaborate on how you are planning to convert customer-id to suitable index/subscript. I am sorry but, I really couldn't think of any way of doing that.

Thanks & Regards,
Nikhil

Nik22Dec wrote:Hi Billy,

I unconditionally agree!! I guess my C++ background took its toll. Sorry for the confusion.Can you please elaborate on how you are planning to convert customer-id to suitable index/subscript. I am sorry but, I really couldn't think of any way of doing that.

Thanks & Regards,
Nikhil

For a subscript, it is easy. MOVE data-data-name TO subscript-data-name.

For an index, a little more. SET index-data-name TO data-data-name.

For the subscript, why the MOVE, why not just "use" the Customerid as it is numeric? Subscripts are much neater as binary items, otherwise, each time used, they get converted to binary. If they start off as binary, no conversion each time. To convert to binary, just do the move.

BillyBoyo wrote:

Nik22Dec wrote:Hi Billy,

I unconditionally agree!! I guess my C++ background took its toll. Sorry for the confusion.Can you please elaborate on how you are planning to convert customer-id to suitable index/subscript. I am sorry but, I really couldn't think of any way of doing that.

Thanks & Regards,
Nikhil

For a subscript, it is easy. MOVE data-data-name TO subscript-data-name.

For an index, a little more. SET index-data-name TO data-data-name.

For the subscript, why the MOVE, why not just "use" the Customerid as it is numeric? Subscripts are much neater as binary items, otherwise, each time used, they get converted to binary. If they start off as binary, no conversion each time. To convert to binary, just do the move.

Thanks so much for your prompt reply.But, I am still not sure how this is happening. In case of a subscript, when you move data-data-name TO subscript-data-name, how do you refer it back. I know it is too much of asking but, I would be really grateful if you could probably use a sample code to illustrate the same.

Also, as per my understanding, the idea of using customerid as subscript would work only if the customerids are separated by a common difference e.g. - T(n+1) - T(n) = X. If that is not the case, we might end up wasting a lot of space for customerids which do not even exist or exist but not required as per the logic.

MOVE WS-CUSTOMER-AMOUNT ( WS-CUSTOMER-SUB ) TO WS-PRINT-AMOUNT

I'm not sure what you mean by "refer it back".

For your second, that is how we know it is an exercise and what the point of the exercise is, even if its uses are limited. Yes, you may end up with a "sparsely populated" table, but the exercise is about subscripting/indexing/tables.

Nik22Dec wrote:

BillyBoyo wrote:Expand on the previous solution you were given. Two-dimensional table, using customer-id converted to suitable index/subscript. flush/initialise table on change of customer-id. don't forget to do the last cutsomer-id flushing.

What Billy has proposed is absolutely corect. But, in case if you want to retain the entire data read till you exit the program, you can use an additional one-dimensional array to store the conumer-id & a two-dimensional array to compute the total expenditure of that consumer in a given month. Both the arrays will store corresponding information at the same index. For e.g. -
Array 1 - Row 1 - Cons 1
Array 2 - Row 1/Column1 - Total Exp. by Cons 1 in Jan
Array 2 - Row 1/Column2 - Total Exp. by Cons 1 in Feb
Array 2 - Row 1/Column3 - Total Exp. by Cons 1 in Mar & so on.

Thanks & Regards,
Nikhil

Thanks once again Billy. That's exactly what my point was when I wrote the above given approach. In my approach, the table would never be sparsely populated. Please find below an illustration.
Table 1 - Pos. 1 - Cons 1
Table 2 - Pos. 1/1 - Total Exp. by Cons 1 in Jan
Table 2 - Pos. 1/2 - Total Exp. by Cons 1 in Feb
Table 2 - Pos. 1/3 - Total Exp. by Cons 1 in Mar & so on.
Table 1 - Pos. 2 - Cons 134
Table 2 - Pos. 2/1 - Total Exp. by Cons 134 in Jan
Table 2 - Pos. 2/2 - Total Exp. by Cons 134 in Feb
Table 2 - Pos. 2/3 - Total Exp. by Cons 134 in Mar & so on.
Table 1 - Pos. 3 - Cons 1000000
Table 2 - Pos. 3/1 - Total Exp. by Cons 1000000 in Jan
Table 2 - Pos. 3/2 - Total Exp. by Cons 1000000 in Feb
Table 2 - Pos. 3/3 - Total Exp. by Cons 1000000 in Mar & so on.

Using a simple SEARCH, you can find the index value of any consumer id in Table 1 & corresponding expenditure details in Table 2.
In this case, the table would never contain an unwanted details.Doeas that make sense to you now.
Thanks & Regards,
Nik

The thing with class exercises is the tendency for them not to represent actual situations, because of the need to provide examples in specific things at the time, rather than lots of things together.

In practice, with the original data shown, we'd sort on Customerid and Month (numerically) and not use a table at all - unless, as you show, you need to have all the data available at the end of the program, for some reason.

The problem with Cobol tables, faced scrillions of times, is that you have to apply an arbitrary limit to the size of the table, because, in IBM Cobol, tables are not "dynamic" (nb, you can obtain storage and make your own dynamic table, but that is another story).

So, if you need all the data "at the end" I'd have no problem with writing it to a file/db and then doing the "at end" stuff in an entirely seperate program. It is, however, a common technique to define the tables with the arbitrary limit and "hope for the best" as with your sort of example. As with any solution, the method chosen to implement the solution depends very much on the data and what is needed to be done.