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.

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.
>
>Deepak
>
>
>
In answer to your query - you've already received good advice - your
record layout is HORRIBLE. My comment for starters would be, get rid of
those horrible field-names - what the hell do they mean. You *know* as
the current author - but the next guy/gal who comes after you, having to
maintain the program , what is 'FIELD-FI" or "FIELD-II" ? Use meaningful
names :-

Cus-Name
Cus-AddressLine1
Cus-ZipPostcode.........

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

For Pete - while I agree about the occurs depending relative to file
records - recall a question I posed in softwaresimple days, "Should I be
passing objects or strings (pic x(..) ) ?".. Granted I'm now using SQL,
but the focus of my five COBOL file templates was passing :-

Linkage Section.
01 lnk-record.
05 pic x occurs a to b depending upon c

Same as above, but in reverse, passing dialog entry-field contents back
to the invoker.

Either direction I could wrap the text as an object, using M/F's
CharacterArray and then 'unpack' it at the other end as appropriate.
That appears to me to be an unnecessary step But of course my reference
to "depending upon c" does depend upon a realistic value being set for
'c' to cover all possibilities. "Ahh Ha !", you say, "Don't need to do
that with Components, write a new one"  - but if I change the value of
the constant C in the five file templates - and recompile. Doesn't
affect the invoking programs one bit.

To ensure I don't get caught with my trousers down, when first sending a
particular record-length to a file template, I check it doesn't exceed
the value of "C" - and even use an added file-status code "RL" to
display a messagebox telling me I goofed - and that occurs the first
time I do a development test.

Jimmy

X-Trace: si05.rsvl.unisys.com 1103318297 49847 192.59.246.104 (17 Dec 2004 2
1:18:17 GMT)
X-Complaints-To: news@unisys.com
NNTP-Posting-Date: 17 Dec 2004 21:18:17 GMT
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Path: imp.nntpserver.com!newsfeed-west.nntpserver.com!newsfeed-east.nntpserv
er.com!nntpserver.com!transit-1.news.visi.com!38.119.100.84.MISMATCH!news-ou
t.nuthinbutnews.com!propagator2-sterling.mcse.ms!news-in.mcse.ms
!metal.news.uhro.net!humbol
t.nl.linux.org!news.nl.linux.org!news.zanker.org!news-out.visi.com!transit-1
.news.visi.com!bbnews1.unisys.com!si05!not-for-mail
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:105237

OK, thanks for the clarification, Bill.  As you point out, it is an
extension, and isn't universally portable.  .

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:wzHwd.1024553$SM5.72921@news.easynews.com...
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:cpv43t$16u9$1@si05.rsvl.unisys.com... 
> <snip> 
>
> Chuck,
>   *ALL* IBM mainframe compilers *and* all compilers providing IBM
> "compatibility" options (e.g. Micro Focus, Realia, Fujitsu) support this
(as a
> documented extension to the '85 Standard).  See:
>
>
http://publibz.boulder.ibm.com/cgi-...R20/APPENDIX1.1
>
> which says (in part) under the OCCURS CLAUSE
>
> "Complex OCCURS DEPENDING ON. [Standard COBOL 85 requires  that an entry
> containing OCCURS DEPENDING ON be followed  only by subordinate entries,
and
> that no entry   containing OCCURS DEPENDING ON be subordinate to an
entry
> containing OCCURS DEPENDING ON.]  "
>
> In other words, IBM supports *all* of the following structures and flags
them as
> extensions):
>
> 01  Group1.
>       05  Group2
>             10 Elem1 occurs 1 to 10 times depending on Num1 Pic X.
>       05   Elem2.
>
> 01  Group3.
>       05  Group4.
>             10  Group5 Occurs 1 to 10 times depending on Num2.
>                   15  Group6 Occurs 1 to 12 times depending on Num3.
>                          20 Elem3   Pic X.
>
> 01  Group7
>       05  Group8.
>             10  Group9 Occurs 1 to 10 times depending on Num4.
>                   15  Group10  Occurs 1 to 12 times depending on Num5.
>                          20 Elem4   Pic X.
>        05  Elem5   Pic X
>
>        05  Group11.
>             10  Group12 Occurs 1 to 10 times depending on Num6.
>                   15  Group13  Occurs 1 to 12 times depending on Num7.
>                          20 Elem5   Pic X.
>
> Furthermore, this EXTENSION is defined so the maximum size is NOT used for
> "allocation" but rather the "current size" - so items following an ODO
"slide"
> (Hence the Micro Focus directive name "ODOSLIDE").  Therefore, (as these
> structures have been supported for years - for ever as far as I know.  See
> relevant "substantive change" item in '85 Standard) there are many FILES
that
> have structures "defined" this way that DO "save storage" for individual
> records.
>
> I certainly do NOT disagree with those who recommend against such
structures
> WHEN POSSIBLE, but I did want to indicate that they exist and are
supported by
> SEVERAL compilers - and where supported (with the "sliding" feature) they
> actually DO provide storage benefits (that may or may not be overridden by
> performance issues.)
>
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
>
>

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cpv43t$16u9$1@si05.rsvl.unisys.com...
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:cpv2gb$fjj$1@peabody.colorado.edu... 
<snip>
>
> 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).
>

Chuck,
*ALL* IBM mainframe compilers *and* all compilers providing IBM
"compatibility" options (e.g. Micro Focus, Realia, Fujitsu) support this (as
 a
documented extension to the '85 Standard).  See:

[url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR20/APPENDIX1.1[/u
rl]

which says (in part) under the OCCURS CLAUSE

"Complex OCCURS DEPENDING ON. [Standard COBOL 85 requires  that an entry
containing OCCURS DEPENDING ON be followed  only by subordinate entries, and
that no entry   containing OCCURS DEPENDING ON be subordinate to an   entry
containing OCCURS DEPENDING ON.]  "

In other words, IBM supports *all* of the following structures and flags the
m as
extensions):

01  Group1.
05  Group2
10 Elem1 occurs 1 to 10 times depending on Num1 Pic X.
05   Elem2.

01  Group3.
05  Group4.
10  Group5 Occurs 1 to 10 times depending on Num2.
15  Group6 Occurs 1 to 12 times depending on Num3.
20 Elem3   Pic X.

01  Group7
05  Group8.
10  Group9 Occurs 1 to 10 times depending on Num4.
15  Group10  Occurs 1 to 12 times depending on Num5.
20 Elem4   Pic X.
05  Elem5   Pic X

05  Group11.
10  Group12 Occurs 1 to 10 times depending on Num6.
15  Group13  Occurs 1 to 12 times depending on Num7.
20 Elem5   Pic X.

Furthermore, this EXTENSION is defined so the maximum size is NOT used for
"allocation" but rather the "current size" - so items following an ODO "slid
e"
(Hence the Micro Focus directive name "ODOSLIDE").  Therefore, (as these
structures have been supported for years - for ever as far as I know.  See
relevant "substantive change" item in '85 Standard) there are many FILES tha
t
have structures "defined" this way that DO "save storage" for individual
records.

I certainly do NOT disagree with those who recommend against such structures
WHEN POSSIBLE, but I did want to indicate that they exist and are supported 
by
SEVERAL compilers - and where supported (with the "sliding" feature) they
actually DO provide storage benefits (that may or may not be overridden by
performance issues.)

--
Bill Klein
wmklein <at> ix.netcom.com

"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.
>
Thank you Howard.

Not for agreeing with me (although that is always nice...<G> ), but for
recognising what Iwas saying.

Pete.

"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:41C30EEE.37C532AF@mb.sympatico.ca...
> Pete Dashwood wrote: 
>
> 
and 
nothing 
are 
>
> 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 knew when I posted, this would be controversial. That's why I stressed it
was purely opinion.

You raise a fair point, Peter, so I'll respond.

I don't personally believe that the time "saved" in searching a memory
resident table defined with OCCURS...DEPENDING , amounts to a bag of beans.

I use SEARCH for tables. If they are over a couple of hundred entries, I
load them in sequence and use SEARCH ALL. I don't sort them; I initialize
them to high values and use a binary chop to store data elements in them.
(So they are maintained dynamically in sequence). I don't do this unless I
am really sure that there will be a significant degradation in processing if
I DON'T do it.
> 
part 
occurrences 
is to 
>
>
> I dunno about that.  PROGRESS, for one, allows repeating groups and it's
> supposed to be a normalized 4GL.
>
I'll stand corrected, as I know nothing about PROGRESS. However, I DO know
something about the Relational Model and Data base design. Normalization
involves removal of repeating groups.

Pete.

Pete, I'm just  about what you would allow and what you wouldn't.

Our compiler will allow this:
01  A-REC.
03  A-TABLE OCCURS 1 TO 1000
DEPENDING ON SOME-THING.
05  AN-ELEMENT PIC X(5).

It isn't clear to me whether you are requiring, *if it's coded at all*, that
it be coded as
01  A-REC.
03  AN-ELEMENT OCCURS 1 TO 1000
DEPENDING ON SOME-THING
PIC X(5).
so that only an *elementary* item may have an ODO clause, OR that what your
standards would prohibit (which, as Bill points out, some compilers allow)
the use of an implementor extension
03  A-REC.
03  AN-ELEMENT OCCURS 1 TO 1000
DEPENDING ON SOME-THING
PIC X(5).
03  SOME-MORE-STUFF PIC X(5).

Or, for that matter, both.

I understand prohibiting anything (group or elementary) following and
*declared at the same level as* an ODO item (whether the ODO item itself is
group or elementary).  If it's allowed at all, it's an implementor
extension.

What isn't clear, if the answer is "both", is why you would prohibit an ODO
group with each element consisting of more than one subordinate field, just
as would be the case with an OCCURS without DEPENDING.

I'm not arguing whether the construct is awful or not; what I'm not clear on
is the reasoning behind your prohibition, and for that matter, what
*exactly* it is that you are prohibiting.  If you are indeed prohibiting
subfields within the elements of a table that happens to be ODO, I haven't
grasped why.

-Chuck Stevens

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:32h84uF3lsandU1@individual.net...
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:cpv1lk$1583$1@si05.rsvl.unisys.com... 
opinion 
and 
> OCCURS 
modifying 
> be 
Syntax 
do 
> My post stated quite clearly that it was about my opinion on how to use
(or
> avoid) this awful construct, not on what is legal in COBOL terms or not.
>
> Pete.
>
>
>