Home > Archive > Cobol > November 2007 > occurs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Frank Swarbrick 2007-11-14, 6:55 pm |
| I've wondered this for a long time... Why is there a restriction that an
OCCURS clause cannot occur at level 01 or 77? For instance, why not
01 TRANS-MORE-CNT OCCURS 4
PIC S9(7) COMP-3 VALUE ZERO.
Or even
77 TRANS-MORE-CNT OCCURS 4
PIC S9(7) COMP-3 VALUE ZERO.
Rather than something silly like...
01.
05 TRANS-MORE-CNT OCCURS 4
PIC S9(7) COMP-3 VALUE ZERO.
It's always bugged me.
Frank
| |
| William M. Klein 2007-11-14, 6:55 pm |
| You are talking about Standard COBOL. There are implementations (Micro Focus
for example) that allow this as an extension.
The restriction (as I think I have been told - I wasn't there when it was added)
is that some statements require that an operand be a "data-name" instead of an
"identifier". At least up to the '85 Standard (and somewhat in there) one major
distinction between a "data-name" and an "identifier" in a syntax diagram was
the ability to subscript it.
Consider (abbreviated - I haven't checked, but I think this was one of the
"problem" cases):
FD File-1.
01 Rec-Table occurs 10 times.
....
Write Rec-Tabl.
The Standard doesn't allow one to user "Rec-Table without a subscript - but
write doesn't let you use a subscript.
Those that have such an extension come up with rules to handle "hard cases" but
given the "ease" of putting a group-item at the 01-level, J4 (and WG4) have
rejected adding this every time the "suggestion" has come up.
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:473B0FEA.6F0F.0085.0@efirstbank.com...
> I've wondered this for a long time... Why is there a restriction that an
> OCCURS clause cannot occur at level 01 or 77? For instance, why not
>
> 01 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
> Or even
>
> 77 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
> Rather than something silly like...
>
> 01.
> 05 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
> It's always bugged me.
>
> Frank
>
| |
| Robert 2007-11-14, 6:55 pm |
| On Wed, 14 Nov 2007 15:10:34 -0700, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com>
wrote:
>I've wondered this for a long time... Why is there a restriction that an
>OCCURS clause cannot occur at level 01 or 77? For instance, why not
>
>01 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
>Or even
>
>77 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
>Rather than something silly like...
>
>01.
> 05 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
>It's always bugged me.
I think the reason is SYNCHRONIZATION. The Standard does not say 01 and 77 levels
('records') are automatically synchronized, but it does say the implementor has the option
to say that, "A record itself may be automatically synchronized." 13.16.56.3 Micro Focus
elected to make it automatic; I expect most or all compilers do, on machines requiring
synchronization.
Assuming for illustration 8 byte word boundaries, the compiler would generate 4 byte
fillers between each TRANS-MORE-CNT in your first example, even though you did not say
SYNC, but no filler in your second example, BECAUSE you did not say SYNC.
After getting frustrated by this 'compiler bug', people would ask for a NOSYNC option to
'fix' it.
| |
| Rick Smith 2007-11-15, 3:55 am |
|
"Robert" <no@e.mail> wrote in message
news:0k4nj35572pnugah142kv58gnabes24lid@
4ax.com...
> On Wed, 14 Nov 2007 15:10:34 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com>
> wrote:
>
>
> I think the reason is SYNCHRONIZATION. The Standard does not say 01 and 77
levels
> ('records') are automatically synchronized, but it does say the
implementor has the option
> to say that, "A record itself may be automatically synchronized."
13.16.56.3 Micro Focus
> elected to make it automatic; I expect most or all compilers do, on
machines requiring
> synchronization.
>
> Assuming for illustration 8 byte word boundaries, the compiler would
generate 4 byte
> fillers between each TRANS-MORE-CNT in your first example, even though you
did not say
> SYNC, but no filler in your second example, BECAUSE you did not say SYNC.
Micro Focus COBOL 3.2.24 (Jun 1994) did not add
implicit FILLER bytes. The following program displays:
16 / 4 = 4.
Were implict FILLER bytes added, "space-for-table"
would have been 32. Using an odd number for the occurs
does report the next higher even number due to implicit
FILLER bytes (i.e., occurs 5 reports 24 / 4 = 6).
-----
$set align"8"
program-id. A27B20.
data division.
working-storage section.
01 item occurs 4 pic s9(7) comp-3 value 0.
01 dummy pic x.
78 space-for-table value start of dummy - start of item.
78 length-of-item value length of item.
78 occurs-count value space-for-table / length-of-item.
procedure division.
display space-for-table " / " length-of-item
" = " occurs-count
stop run.
-----
| |
| Judson McClendon 2007-11-15, 7:55 am |
| Do you fellows really think those were reasons used when OCCURS was
originally defined in COBOL decades ago? I don't think so. I suspect it
had more do with their concept of what a record was, and as pointed out
already, using a subscript in WRITE would seem a bit un-COBOL-ish
at the time. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
"Rick Smith" <ricksmith@mfi.net> wrote:
> "Robert" <no@e.mail> wrote:
> levels
> implementor has the option
> 13.16.56.3 Micro Focus
> machines requiring
> generate 4 byte
> did not say
>
> Micro Focus COBOL 3.2.24 (Jun 1994) did not add
> implicit FILLER bytes. The following program displays:
> 16 / 4 = 4.
>
> Were implict FILLER bytes added, "space-for-table"
> would have been 32. Using an odd number for the occurs
> does report the next higher even number due to implicit
> FILLER bytes (i.e., occurs 5 reports 24 / 4 = 6).
> -----
> $set align"8"
> program-id. A27B20.
> data division.
> working-storage section.
> 01 item occurs 4 pic s9(7) comp-3 value 0.
> 01 dummy pic x.
> 78 space-for-table value start of dummy - start of item.
> 78 length-of-item value length of item.
> 78 occurs-count value space-for-table / length-of-item.
> procedure division.
> display space-for-table " / " length-of-item
> " = " occurs-count
> stop run.
> -----
>
>
| |
| Rick Smith 2007-11-15, 7:55 am |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:FOV_i.5538$2I3.758@bignews2.bellsouth.net...
> "Rick Smith" <ricksmith@mfi.net> wrote:
an[color=darkred]
77[color=darkred]
you[color=darkred]
SYNC.[color=darkred]
>
> Do you fellows really think those were reasons used when OCCURS was
> originally defined in COBOL decades ago? I don't think so. I suspect it
> had more do with their concept of what a record was, and as pointed out
> already, using a subscript in WRITE would seem a bit un-COBOL-ish
> at the time. :-)
Nor do I think so, Mr McClendon. When I saw
Mr Swarbrick's post, potential problems in the file,
linkage, and communications sections came to mind.
Mr McClendon, what did you see, in my post, that
led you believe I was agreeing with Mr Wagner?
| |
| William M. Klein 2007-11-15, 6:55 pm |
| I *do* think that my post reflected the reason (i.e. data-name vs identifier
issues). I believe (but certainly could be mistaken on this) that I was told
this by some of the "early" CCC members.
I will say, on the "sync" issue that I *know* that was the reason that up until
the '02 Standard, CONFORMING COBOL code could only use 01-/77-level or
elementary items in a CALL "using" phrase. The "problem" of the intermediate
level group item being synced (or not) in the CALLing program - but getting
different "sync" values when used as an 01-level in the CALLed programs linkage
section, was the reason for that restriction. Therefore, it is possible that
this MIGHT have been an issue for OCCURS at 01-level as well.
--
Bill Klein
wmklein <at> ix.netcom.com
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:FOV_i.5538$2I3.758@bignews2.bellsouth.net...
> Do you fellows really think those were reasons used when OCCURS was
> originally defined in COBOL decades ago? I don't think so. I suspect it
> had more do with their concept of what a record was, and as pointed out
> already, using a subscript in WRITE would seem a bit un-COBOL-ish
> at the time. :-)
> --
> Judson McClendon judmc@sunvaley0.com (remove zero)
> Sun Valley Systems http://sunvaley.com
> "For God so loved the world that He gave His only begotten Son, that
> whoever believes in Him should not perish but have everlasting life."
>
>
> "Rick Smith" <ricksmith@mfi.net> wrote:
>
>
| |
| Judson McClendon 2007-11-15, 6:55 pm |
| "Rick Smith" <ricksmith@mfi.net> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
> an
> 77
> you
> SYNC.
>
> Nor do I think so, Mr McClendon. When I saw
> Mr Swarbrick's post, potential problems in the file,
> linkage, and communications sections came to mind.
>
> Mr McClendon, what did you see, in my post, that
> led you believe I was agreeing with Mr Wagner?
Why, nothing. What did you see in my post to make you think I thought
you agreed with Mr. Wagner? :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Rick Smith 2007-11-15, 6:55 pm |
| X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
X-Complaints-To: abuse@supernews.com
Lines: 108
Bytes: 5183
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:170135
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:LpY_i.4603$oa.58@bignews1.bellsouth.net...
> "Rick Smith" <ricksmith@mfi.net> wrote:
that[color=darkred]
not[color=darkred]
and[color=darkred]
though[color=darkred]
>
> Why, nothing. What did you see in my post to make you think I thought
> you agreed with Mr. Wagner? :-)
I saw "you fellows" as a grouping of Mr Wagner and me;
and I saw "those were the reasons" as agreement. I neither
agreed nor disagreed with Mr Wagner on whether
sychronization was the reason for the restriction on the
OCCURS clause. In fact, I never gave a reason for the
restriction.
Instead I addressed, and clearly I might add, the specific issue
of whether Micro Focus automatically inserts implicit FILLER
bytes when an OCCURS clause is used at level number 1.
Thus, the grouping explicit in "you fellows" and the agreement
explicit in "those were the reasons" was in err. Hence my
question.
| |
| Howard Brazee 2007-11-15, 6:55 pm |
| On Wed, 14 Nov 2007 15:10:34 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>I've wondered this for a long time... Why is there a restriction that an
>OCCURS clause cannot occur at level 01 or 77? For instance, why not
I can sort of understand it with a 77 - except I haven't used 77
levels for decades. I really don't see their value.
(I also haven't used a 66 level, but their value in the day was
obvious).
| |
| Frank Swarbrick 2007-11-15, 6:55 pm |
| >>> On 11/14/2007 at 3:10 PM, in message
<473B0FEA.6F0F.0085.0@efirstbank.com>,
Frank Swarbrick<Frank.Swarbrick@efirstbank.com> wrote:
> I've wondered this for a long time... Why is there a restriction that an
> OCCURS clause cannot occur at level 01 or 77? For instance, why not
>
> 01 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
> Or even
>
> 77 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
> Rather than something silly like...
>
> 01.
> 05 TRANS-MORE-CNT OCCURS 4
> PIC S9(7) COMP-3 VALUE ZERO.
>
> It's always bugged me.
Thanks for all of the answers.
Seems to me that it would be easy to solve the FILE SECTION issue by making
a rule that OCCURS is not allowed at level 1 or 77 in the FILE SECTION. As
for being synchronized there could be a rule that only the first byte of an
01 record need be synchronized. (Probably didn't state that well enough for
a standard, but it hardly matters as it obviously will never make it
there...)
Ah well.
Frank
| |
| Richard 2007-11-16, 3:55 am |
| On Nov 15, 11:42 am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
>
> FD File-1.
> 01 Rec-Table occurs 10 times.
> ....
In an FD area all 01 records implicitly redefine each other. The
occurs means that (theoretically) there are 10 01 level entries, each
of which is a redefinition of the other 9.
Rec-Table(1) is the same (or should be) data area as Rec-Table(2).
| |
|
|
| William M. Klein 2007-11-29, 6:55 pm |
| Richard,
I am not certain that I agree with this. It is true that in a STANDARD
CONFORMING implementation (and source code) that all 01-levels are implicit
redefines. However, if an implementation creates an extension that allows
NON-STANDARD occurs at the 01-level, then I think it is UP TO THE IMPLEMENTER
what this means. Certainly, ONE approach would be that each element is a
"redefines". However, another would be that there is an "implicit" group
01-level ABOVE the data description with the OCCURS.
Telling an implementer how they MUST create an extension is a "non-starter"
(from my perspective).
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@azonic.co.nz> wrote in message
news:6d41815e-a480-4d78-837e-979730ba94b3@d27g2000prf.googlegroups.com...
> On Nov 15, 11:42 am, "William M. Klein" <wmkl...@nospam.netcom.com>
> wrote:
>
>
> In an FD area all 01 records implicitly redefine each other. The
> occurs means that (theoretically) there are 10 01 level entries, each
> of which is a redefinition of the other 9.
>
> Rec-Table(1) is the same (or should be) data area as Rec-Table(2).
>
>
| |
| Richard 2007-11-30, 6:55 pm |
| On Nov 30, 11:57 am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> Richard,
> I am not certain that I agree with this. It is true that in a STANDARD
> CONFORMING implementation (and source code) that all 01-levels are implicit
> redefines. However, if an implementation creates an extension that allows
> NON-STANDARD occurs at the 01-level, then I think it is UP TO THE IMPLEMENTER
> what this means. Certainly, ONE approach would be that each element is a
> "redefines".
Do you know of any implementation where this is not the case in an
FD ?
> However, another would be that there is an "implicit" group
> 01-level ABOVE the data description with the OCCURS.
That would make it rather hard to do a WRITE when the "00 group level"
is implicit and has no name.
> Telling an implementer how they MUST create an extension is a "non-starter"
> (from my perspective).
Of course they could design their own language which is not like Cobol
at all.
|
|
|
|
|