Cobol - urgent query!!!

Author

urgent query!!!

deepu

2004-12-20, 3:55 pm

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-20, 3:55 pm

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-20, 3:55 pm

Pete Dashwood

2004-12-20, 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.

James J. Gavan

2004-12-20, 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

Chuck Stevens

2004-12-20, 8:55 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: imp.nntpserver.com!newsfeed-west.nntpserver.com!newsfeed-east.nntpserver.com!nntpserver.com!transit-1.news.visi.com!38.119.100.84.MISMATCH!news-out.nuthinbutnews.com!propagator2-sterling.newsfeeds.com!news-in.newsfeeds.com!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
>
>

William M. Klein

2004-12-20, 8:55 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

Pete Dashwood

2004-12-20, 8:55 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-20, 8:55 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-20, 8: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.
>
Thank you Howard.

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

Pete.

Pete Dashwood

2004-12-20, 8:55 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-20, 8:55 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-20, 8:55 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-20, 8:55 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>
>
>
>

patrick.magee@microfocus.com

2004-12-21, 8:55 am

Deepak, did anyone answer your question?
You'll need qualification to make some of these compile, but field-bi
cannot be made unique by the use of qualification. Someone suggested
that you could test this yourself and that is correct. To test you need
to code references to all the items you've defined as below.

01 IN-REC.
05 FIELD-BI PIC S9(4) COMP.
05 FIELD-CI PIC S9(4) COMP.
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 PIC S9(4) COMP.
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.
77 sub pic 99.
procedure division.
move 1 to field-bi of in-rec notunique

move 1 to field-ci
move space to field-di
move space to group-ei(sub)
move space to field-fi of group-ei(sub)
move 1 to field-gi(sub)
move space to group-hi(sub)
move space to field-fi of group-hi of in-rec(sub)
move space to field-ii(sub)
move space to field-bi of in-rec
notunique
stop run.

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

James J. Gavan

2004-12-22, 8:55 am

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

Sponsored Links