urgent query!!!

Hi All..
I'm new to this COBOL world ...so have many doubts..

PLease clarify that can we have item name under different group on
Cobol Copy Book with the same name??


For eg;
01 IN-REC
05  FIELD-BI    COMP PIC S9(4).
05  FIELD-CI    COMP PIC S9(4).
05  FIELD-DI         PIC X.
05  GROUP-EI   OCCURS 1 TO 5 TIMES
DEPENDING ON FIELD-CI
10 FIELD-FI       PIC XX.
10 FIELD-GI COMP PIC S9(4).
05  GROUP-HI   OCCURS 3 TO 5 TIMES
DEPENDING ON FIELD-CI
10 FIELD-FI       PIC X.
10 FIELD-II       PIC XXXX.
05  FIELD-BI          PIC X.

In the above CoboCopyBook GROUP-EI and GROUP-HI both have FIELD-FI as
their element name, can we have that?

Also FIELD-BI is declared twice at 05 level, can we have that??
Thanks in advance.

Deepak

On 17 Dec 2004 04:02:45 -0800, "deepu" <deepu4u@gmail.com> wrote:

>Hi All..
>I'm new to this COBOL world ...so have many doubts..
>
>PLease clarify that can we have item name under different group on
>Cobol Copy Book with the same name??
>
>
>For eg;
>01 IN-REC
>05  FIELD-BI    COMP PIC S9(4).
>05  FIELD-CI    COMP PIC S9(4).
>05  FIELD-DI         PIC X.
>05  GROUP-EI   OCCURS 1 TO 5 TIMES
>DEPENDING ON FIELD-CI
>10 FIELD-FI       PIC XX.
>10 FIELD-GI COMP PIC S9(4).
>05  GROUP-HI   OCCURS 3 TO 5 TIMES
>DEPENDING ON FIELD-CI
>10 FIELD-FI       PIC X.
>10 FIELD-II       PIC XXXX.
>05  FIELD-BI          PIC X.
>
>In the above CoboCopyBook GROUP-EI and GROUP-HI both have FIELD-FI as
>their element name, can we have that?
>
>Also FIELD-BI is declared twice at 05 level, can we have that??
>Thanks in advance.
>
>Deepak
I think the easy answer is for you to create a program and a copybook
and to try compiling it to see if you have any errors.

As this looks a lot like homework I am going to assume it is.

If on the other hand you are a professional then you should learn that
some type of questions are just not acceptable. This is one of them,
as you can easily test it yourself.


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

deepu wrote:
> Hi All..
> I'm new to this COBOL world ...so have many doubts..
>
> PLease clarify that can we have item name under different group on
> Cobol Copy Book with the same name??
>
>
> For eg;
> 01 IN-REC
> 05  FIELD-BI    COMP PIC S9(4).
> 05  FIELD-CI    COMP PIC S9(4).
> 05  FIELD-DI         PIC X.
> 05  GROUP-EI   OCCURS 1 TO 5 TIMES
> DEPENDING ON FIELD-CI
> 10 FIELD-FI       PIC XX.
> 10 FIELD-GI COMP PIC S9(4).
> 05  GROUP-HI   OCCURS 3 TO 5 TIMES
> DEPENDING ON FIELD-CI
> 10 FIELD-FI       PIC X.
> 10 FIELD-II       PIC XXXX.
> 05  FIELD-BI          PIC X.
>
> In the above CoboCopyBook GROUP-EI and GROUP-HI both have FIELD-FI as
> their element name, can we have that?
>
> Also FIELD-BI is declared twice at 05 level, can we have that??
> Thanks in advance.
>

There's so much wrong with this copy book, one doesn't know where to start.
I suggest you start over.

"deepu" <deepu4u@gmail.com> wrote in message
news:1103284965.204941.202010@z14g2000cwz.googlegroups.com...
> Hi All..
> I'm new to this COBOL world ...so have many doubts..
>
> PLease clarify that can we have item name under different group on
> Cobol Copy Book with the same name??
>
>
> For eg;
> 01 IN-REC
> 05  FIELD-BI    COMP PIC S9(4).
> 05  FIELD-CI    COMP PIC S9(4).
> 05  FIELD-DI         PIC X.
> 05  GROUP-EI   OCCURS 1 TO 5 TIMES
> DEPENDING ON FIELD-CI
> 10 FIELD-FI       PIC XX.
> 10 FIELD-GI COMP PIC S9(4).
> 05  GROUP-HI   OCCURS 3 TO 5 TIMES
> DEPENDING ON FIELD-CI
> 10 FIELD-FI       PIC X.
> 10 FIELD-II       PIC XXXX.
> 05  FIELD-BI          PIC X.
>
> In the above CoboCopyBook GROUP-EI and GROUP-HI both have FIELD-FI as
> their element name, can we have that?
>
> Also FIELD-BI is declared twice at 05 level, can we have that??
> Thanks in advance.
>
> Deepak
>
Deepak,

Frederico has given you sound advice in that you should compile it and see
for yourself.

I don't think this is homework because I couldn't imagine any institution
propagating bad practice as homework.

The problem here is use of OCCURS... DEPENDING. What follows is opinion and
my be accepted or rejected. At least you will be aware that there is a
question over this stuff. (It is informed opinion based on 40 years of
experience in the real world.)

This construct should really be avoided like the plague. It buys you nothing
(COBOL will allocate the largest area possible every time anyway, so you are
fooling yourself if you think it saves space.)

Here are some easy commandments when it comes to OCCURS...DEPENDING:

1. Thou shalt NOT use this construct unless it is ABSOLUTELY NECESSARY.
(Maintaining legacy code, designed when nobody knew any better...)
2. Thou shalt have the field that the group depends on, as close as possible
to the group that depends on it, ideally, immediately before it.
3. Thou shalt have ONLY ONE OCCURS...DEPENDING in thy record layout, and it
shall be the LAST data description clause in the record description.

Taking what you have and applying as much as possible of the above...

01 IN-REC
05  FIELD-BI          COMP PIC S9(4).
05  FIELD-DI          PIC X.
05  FIELD-CI          COMP PIC S9(4).
05  FIELD-XBI        PIC X.
05  GROUP-EI   OCCURS 1 TO 5 TIMES
DEPENDING ON FIELD-CI
10 FIELD-FI       PIC XX.
10 FIELD-GI      COMP PIC S9(4).
05  FIELD-XI          COMP PIC S9(4).
05  GROUP-HI   OCCURS 3 TO 5 TIMES
*                                   DEPENDING ON FIELD-CI  *> Can't work...

*> What if CI has a 1 or 2 in it?
DEPENDING ON FIELD-XI.
10 FIELD-FI       PIC X.
10 FIELD-II       PIC XXXX.
*NO Fields should follow OCCURS...DEPENDING... moved FIELD-BI back up the
record and renamed it because it could *not be qualified.

OCCURS DEPENDING is highly inefficient because everything under it has
another level of indexing in addition to what it actually requires, and it
requires indirect addressing at machine level, on most platforms.

If the above is a record, what you are really saying is that there is a part
of the record that can occur up to 5 times. For each of these occurrences
there will always be 3, and could be up to 5, further parts. These are
called repeating groups. Part of the process of database normalization is to
REMOVE repeating groups. COBOL alone (or COBOL Programmers...) seems to
propagate them...

What happens if the system changes and you now need 6 groups at the highest
level? Or more than 5 or less than 3 at the second level?  EVERY SINGLE
program that uses this COPY Book has to be recompiled.

Given that we are NOT considering databases here (which is really the best
answer for this) split the repeating groups to separate files, like this:

File 1:
01 IN-REC
05   KEY-FIELD     PIC 9(6).
05  FIELD-BI          COMP PIC S9(4).
05  FIELD-DI          PIC X.
05  FIELD-CI          COMP PIC S9(4).
05  FIELD-XBI        PIC X.

File 2:
01  RG-1.
05  KEY-FIELD-RG-1.   PIC 9(6).
10  KEY-FIELD     PIC 9(6).
10  OCC-NO         PIC 99. *> Allows 100 instances of  Repeating
Group 1.
05 FIELD-FI       PIC XX.
05 FIELD-GI      COMP PIC S9(4).

File 3:
01  RG-2.
05  KEY-FIELD-RG-2.   PIC 9(6).
10  KEY-FIELD        PIC 9(6).
10  OCC-NO            PIC 99. *> Allows 100 instances of
Repeating Group 2.
05 FIELD-FI       PIC X.
05 FIELD-II        PIC XXXX.

Now a quick look at the pros and cons of this:

CONS:

1. Needs 3 files. (Overheads in OPEN and CLOSE).
2. Key structure is duplicated in files 2 and 3.

PROS:

1. Will support maintenance much better without needing amendment.  (No of
"occurrences" can change without having to recompile programs.)
2. The OCCURS clauses have disappeared, along with their overheads. It is
arguably a less complex structure without them also.
3. There is no loss of functionality. You can still access any "occurrence"
directly by setting the OCC-NO in the key of the repeating group, or you can
access them sequentially by using only the generic KEY-FIELD in the
repeating group, and issuing START then READ NEXT.
4. The case of ZERO occurrences of a repeating group is now catered for. (It
wasn't with OCCURS...DEPENDING. Well, it was, insofar as space was allocated
to it whether there was data or not. Now space is only allocated when there
is data.)
5. If you want to process only the RG data you can. Randomly or
Sequentially. (Before you had to access the whole record to get any part of
it.)

This represents a "second normal form" of the data, according to the
Rlational Model developed by Codd and Date. It is "purer" mathematically
(contains no reflexive relationships), and simpler for maintenance (Less
complex, and less limited, data structure.)

There is really no need to complicate data structure and systems with use of
this ugly OCCURS... DEPENDING  construct.

Pete.

..    On  17.12.04
wrote  deepu4u@gmail.com (deepu)
on  /COMP/LANG/COBOL
in  1103284965.204941.202010@z14g2000cwz.googlegroups.com
about  urgent query!!!


d> PLease clarify that can we have item name under different group on
d> Cobol Copy Book with the same name??

Sure, as long as the item can be qualified to a unique dataname, no
problem.


d> For eg;

d> 01 IN-REC
d>    05  FIELD-BI    COMP PIC S9(4).
d>    05  FIELD-CI    COMP PIC S9(4).
d>    05  FIELD-DI         PIC X.
d>    05  GROUP-EI   OCCURS 1 TO 5 TIMES
d>                     DEPENDING ON FIELD-CI
d>      10 FIELD-FI       PIC XX.
d>      10 FIELD-GI COMP PIC S9(4).
d>    05  GROUP-HI   OCCURS 3 TO 5 TIMES
d>                     DEPENDING ON FIELD-CI
d>      10 FIELD-FI       PIC X.
d>      10 FIELD-II       PIC XXXX.
d>    05  FIELD-BI          PIC X.
d>
d> In the above CoboCopyBook GROUP-EI and GROUP-HI both have FIELD-FI as
d> their element name, can we have that?

Yes, they can be qualified as e.g.
FIELD-FI OF GROUP-HI (some-subscript) OF IN-REC
or
FIELD-GI OF GROUP-EI (some-subscript) OF IN-REC

But as far as I know COBOL, having two OCCURS DEPENDING ON in
sequence will result in a syntax error. Since both depend on the same
dataname, i.e. have the same number of occurrences, why don't you
define both GROUP-xI totgether as one group?

d> Also FIELD-BI is declared twice at 05 level, can we have that??

No, there is no way to distinquish between the two FIELD-BI, they
are both immediately qualified by IN-REC. When there is no need to
address a field directly, I suggest to use the generic dataname
FILLER. Or give it a different name.

Besides, looking at the declaration of the two GROUP-xI, it seems
to me that you actually want to have a "GROUP-HI REDEFINES GROUP-EI",
i.e. just two different division of that sequence of bits. Right?


Yours,
Lüko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Das ganze Zeitungs-All.  -G.C.Lichtenberg

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:32g63fF3kae2hU1@individual.net...

> The problem here is use of OCCURS... DEPENDING. What follows is opinion
and
> my be accepted or rejected. At least you will be aware that there is a
> question over this stuff. (It is informed opinion based on 40 years of
> experience in the real world.)
...
> Here are some easy commandments when it comes to OCCURS...DEPENDING:
...

> 3. Thou shalt have ONLY ONE OCCURS...DEPENDING in thy record layout, and
it
> shall be the LAST data description clause in the record description.

Well, not sure exactly how you mean that;  *if* you are going to use OCCURS
... DEPENDING it's OK to have items *subordinate* to it -- thus, modifying
the above to read in part " ... clause in the record description at any
level less than or equal to the level in which it occurs" would I think
cover it.

ISO/IEC 1989:2002 says it pretty clearly:  "The subject of the entry may be
followed within that record description only by data description entries
that are subordinate to it."  (page 307, 13.16.36.2, OCCURS clause, Syntax
Rule 20).

In any implementation that claims conformance to any COBOL standard
(presuming that the implementation in question includes the ability to do
this in the first place), I would expect the compiler to slap the
programmer's hands rather decisively if the above rule weren't followed.

-Chuck Stevens

On 17-Dec-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
 
> ...
> 
> it 
>
> Well, not sure exactly how you mean that;  *if* you are going to use OCCUR
S
> ... DEPENDING it's OK to have items *subordinate* to it -- thus, modifying
> the above to read in part " ... clause in the record description at any
> level less than or equal to the level in which it occurs" would I think
> cover it.

> ISO/IEC 1989:2002 says it pretty clearly:  "The subject of the entry may b
e
> followed within that record description only by data description entries
> that are subordinate to it."  (page 307, 13.16.36.2, OCCURS clause, Syntax
> Rule 20).

It's pretty obvious that his THOU SHALT NOTs aren't discussing what the ISO/
IEC
allows - but are instead his desired shop standards.

And I agree with him - it's been a long time since I've had to put up with
OCCURS DEPENDING.   That's one thing that the mainframe world was able to mo
ve
past relatively early.

Pete Dashwood wrote:
>
> "deepu" <deepu4u@gmail.com> wrote in message
> news:1103284965.204941.202010@z14g2000cwz.googlegroups.com... 


>
> The problem here is use of OCCURS... DEPENDING. What follows is opinion an
d
> my be accepted or rejected. At least you will be aware that there is a
> question over this stuff. (It is informed opinion based on 40 years of
> experience in the real world.)
>
> This construct should really be avoided like the plague. It buys you nothi
ng
> (COBOL will allocate the largest area possible every time anyway, so you a
re
> fooling yourself if you think it saves space.)
>
> Here are some easy commandments when it comes to OCCURS...DEPENDING:
>
> 1. Thou shalt NOT use this construct unless it is ABSOLUTELY NECESSARY.
> (Maintaining legacy code, designed when nobody knew any better...)

I think you're overdoing it here, Pete; isn't a legitimate use of
"DEPENDING ON" to limit search times in the table?  (Not to mention not
having to allow for null entries in a search if you don't have the
actual # of entries specified, one way or the other).


>
> If the above is a record, what you are really saying is that there is a pa
rt
> of the record that can occur up to 5 times. For each of these occurrences
> there will always be 3, and could be up to 5, further parts. These are
> called repeating groups. Part of the process of database normalization is 
to
> REMOVE repeating groups. COBOL alone (or COBOL Programmers...) seems to
> propagate them...
>


I dunno about that.  PROGRESS, for one, allows repeating groups and it's
supposed to be a normalized 4GL.

PL

"Howard Brazee" <howard@brazee.net> wrote in message
news:cpv2gb$fjj$1@peabody.colorado.edu...
>
> On 17-Dec-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> 
and 
OCCURS 
modifying 
> 
be 
Syntax 
>
> It's pretty obvious that his THOU SHALT NOTs aren't discussing what the
ISO/IEC
> allows - but are instead his desired shop standards.
>
> And I agree with him - it's been a long time since I've had to put up with
> OCCURS DEPENDING.   That's one thing that the mainframe world was able to
move
> past relatively early.

I don't disagree with the basic premise of "don't go there", but if you're
already there, the restriction that an ODO item may not be a group item --
must be elementary -- as a "shop standard" seems just plain peculiar to me.

I don't know any *compilers* offhand that allow the following:

01  A-RECORD.
03  A-FIELD PIC 9(5).
03  A-TABLE OCCURS 1 TO 1000 DEPENDING ON A-FIELD.
05  A-TABLE-ENTRY PIC X.
03  ANOTHER-FIELD PIC X(5).

I personally have nothing against A-TABLE having a subordinate
A-TABLE-ENTRY, if indeed I'm going to allow A-TABLE to be declared an ODO
entry to begin with.

But our '74 and '85 compilers give a syntax error pointing to ANOTHER-FIELD
saying something along the lines of "Only subordinate items are allowed
after an 'OCCURS DEPENDING' clause", and that's consistent with both
applicable standards as well as to the current one (though the '68 standard
didn't include that restriction).

Are there any corresponding implementations that allow ANOTHER-FIELD without
complaint?

Incidentally, the issues associated with this restriction are those for
which Dynamic-Capacity Tables, being proposed for the 2008 standard (along
with Any-Length Elementary Items), are intended to provide solutions in
standard COBOL.

-Chuck Stevens

On 17-Dec-2004, Peter Lacey <lacey@mb.sympatico.ca> wrote:

> I think you're overdoing it here, Pete; isn't a legitimate use of
> "DEPENDING ON" to limit search times in the table?  (Not to mention not
> having to allow for null entries in a search if you don't have the
> actual # of entries specified, one way or the other).

I don't know if it saves much if the excess is filled with high-values.

But I do know that a huge table can make a huge dump.