Cobol - urgent query!!!

Author

urgent query!!!

deepu

2004-12-17, 8:55 am

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

Frederico Fonseca

2004-12-17, 8:55 am

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

JerryMouse

2004-12-17, 3:55 pm

Pete Dashwood

2004-12-17, 3:55 pm

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

Lueko Willms

2004-12-17, 3:55 pm

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

Chuck Stevens

2004-12-17, 3:55 pm

"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

Howard Brazee

2004-12-17, 3:55 pm

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

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.

Peter Lacey

2004-12-17, 3:55 pm

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

[color=darkred]
>
> 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...)

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

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

PL

Chuck Stevens

2004-12-17, 3:55 pm

"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[color=darkred]
OCCURS[color=darkred]
modifying[color=darkred]
>
be[color=darkred]
Syntax[color=darkred]
>
> 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

Howard Brazee

2004-12-17, 3:55 pm

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.

James J. Gavan

2004-12-17, 3:55 pm

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

William M. Klein

2004-12-18, 12:46 pm

"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>[color=darkred]
>
> 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:

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

2004-12-18, 12:46 pm

X-Trace: si05.rsvl.unisys.com 1103318297 49847 192.59.246.104 (17 Dec 2004 21: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: be2.nntpserver.com!newsfeed.ultrafeed.com!newsfeed-west.nntpserver.com!newsfeed-east.nntpserver.com!nntpserver.com!news-out.visi.com!transit-1.news.visi.com!bbnews1.unisys.com!si05!not-for-mail
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:105045

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

Pete Dashwood

2004-12-18, 12:46 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cpv1lk$1583$1@si05.rsvl.unisys.com...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:32g63fF3kae2hU1@individual.net...
>
> and
> ...
> ...
>
> it
>
> 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
>
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.

Pete Dashwood

2004-12-18, 12:46 pm

Pete Dashwood

2004-12-18, 12:46 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cpv43t$16u9$1@si05.rsvl.unisys.com...[color=darkred]
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:cpv2gb$fjj$1@peabody.colorado.edu...
> and
> OCCURS
> modifying
any[color=darkred]
think[color=darkred]
You may have misunderstood my intention, Chuck. It should be the last data
description clause at that level. It can certainly have subordinate clauses
as it did in the example.

Pete.
<snip>

Pete Dashwood

2004-12-18, 12:46 pm

"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:41C30EEE.37C532AF@mb.sympatico.ca...
> Pete Dashwood wrote:
>
>
and[color=darkred]
nothing[color=darkred]
are[color=darkred]
>
> 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[color=darkred]
occurrences[color=darkred]
is to[color=darkred]
>
>
> 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.

Chuck Stevens

2004-12-18, 12:46 pm

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[color=darkred]
and[color=darkred]
> OCCURS
modifying[color=darkred]
> be
Syntax[color=darkred]
do[color=darkred]
> 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.
>
>
>

Pete Dashwood

2004-12-18, 12:46 pm

"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:CYFwd.510364$Pl.326500@pd7tw1no...
> deepu wrote:
>
> 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.
>
Sorry Jimmy, I haven't the faintest idea what this about...<g>. I certainly
would NOT write a new component for every file (or database, for that
matter) that I needed to handle. Maybe there would be an object property
that told the component "How many?" ... can't say without fully
understanding what you are saying ( and I don't...)

Pete.

<snip>

Chuck Stevens

2004-12-18, 12:46 pm

Thanks for the clarification of "Thou shalt have ONLY ONE OCCURS...DEPENDING
in thy record layout, and it shall be the LAST data description clause in
the record description", Peter.

I wasn't aware that anyone actually allowed items *at the same level* after
an ODO item, which is why I brought it up: My expectation was that anyone
who tried it would encounter a syntax error anyway; such has been my
experience on Unisys gear!

Bill clarified that IBM and others *do* allow it, and I agree I think it's a
pretty dreadful idea to exploit that extension.

-Chuck Stevens

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:32h8emF3ma4gnU1@individual.net...
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:cpv43t$16u9$1@si05.rsvl.unisys.com...
OCCURS...DEPENDING:[color=darkred]
layout,[color=darkred]
description.[color=darkred]
> any
> think
> You may have misunderstood my intention, Chuck. It should be the last data
> description clause at that level. It can certainly have subordinate
clauses
> as it did in the example.
>
> Pete.
> <snip>
>
>
>

James J. Gavan

2004-12-18, 12:46 pm

Pete Dashwood wrote:

>"James J. Gavan" <jjgavan@shaw.ca> wrote in message
>news:CYFwd.510364$Pl.326500@pd7tw1no...
>
>
>Sorry Jimmy, I haven't the faintest idea what this about...<g>. I certainly
>would NOT write a new component for every file (or database, for that
>matter) that I needed to handle. Maybe there would be an object property
>that told the component "How many?" ... can't say without fully
>understanding what you are saying ( and I don't...)
>
>Pete.
>
>
Jeepers ! Can't win. Had I posted 3,000 lines of code - then you would
have replied, "Haven't got time to read it....". So going somewhat
*abstract* - you still don't understand.

Guess I'll have to enrol for 'English as a Second Language'. Perhaps
I'll try Pitman's shorthand next time. (Chances are you'll tell me you
are only familiar with Gregg's ). Was going to comment on 'Parameters
and Properties". Nah ! I'll give that a miss too.

Jimmy

Pete Dashwood

2004-12-18, 12:46 pm

"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:F3Nwd.537632$%k.23912@pd7tw2no...
> Pete Dashwood wrote:
>
certainly[color=darkred]
> Jeepers ! Can't win. Had I posted 3,000 lines of code - then you would
> have replied, "Haven't got time to read it....".

Yes, and it would be true, and not personal.

>So going somewhat
> *abstract* - you still don't understand.
>
Guess I must be thick...

I understood some of it and what I could, I replied to.

> Guess I'll have to enrol for 'English as a Second Language'. Perhaps
> I'll try Pitman's shorthand next time. (Chances are you'll tell me you
> are only familiar with Gregg's ). Was going to comment on 'Parameters
> and Properties". Nah ! I'll give that a miss too.
>
Probably best... but certainly your choice.

Try and understand that when you ascribe attributes to me or my approaches,
without actually asking me what they are, I have difficulty. I can't relate
to what you seem to think I do with components, based on the very small
sample of your post. When you ask a straight question that isn't based on
your own assumptions, I try to give a direct answer.

I'm not being difficult. Jimmy and it isn't personal. I honestly try to
clarify whenever people ask me. I can't relate to how you could think I
would write a component for every file (and then "write another one" if it
changed.) That is based on your understanding and approach, filtered thru
statements I made, taken out of context. It isn't what I do.

1. I don't maintain components. (I posted at length on this, using the
Christmas Tree analogy.)
2. I do write generalised components that are designed to be as "future
proof" as possible. (I posted at length on this using the Christmas Tree
analogy.)

How would that then lead you to conclude I would not write a generalised
file handling component that could handle any ISAM/VSAM file, provided you
gave it the Key Length(s) and Location(s) in the data, indicated what
action you wanted to carry out, and passed a record that was not longer than
the buffer size allocated to it? I remember giving you code that did just
that some years ago. Nowadays, I use databases.

Remember it takes (at least) two parties to communicate. If you make
asumptions that I can not relate to, then I have difficulty in understanding
your post.

Pete.

Pete Dashwood

2004-12-20, 8:55 am

Sponsored Links