occurs

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

You are talking about Standard COBOL.  There are implementations (Micro Focu
s
for example) that allow this as an extension.

The restriction (as I think I have been told - I wasn't there when it was ad
ded)
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 m
ajor
distinction between a "data-name" and an "identifier" in a syntax diagram wa
s
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
>

On Wed, 14 Nov 2007 15:10:34 -0700, "Frank Swarbrick" <Frank.Swarbrick@efirs
tbank.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 l
evels
('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 generat
e 4 byte
fillers between each TRANS-MORE-CNT in your first example, even though you d
id 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 NOSY
NC option to
'fix' it.

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

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

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:FOV_i.5538$2I3.758@bignews2.bellsouth.net...
> "Rick Smith" <ricksmith@mfi.net> wrote: 
an 
77 
you 
SYNC. 
>
> 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?

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 tol
d
this by some of the "early" CCC members.

I will say, on the "sync" issue that I *know* that was the reason  that up u
ntil
the '02 Standard, CONFORMING COBOL code could only use 01-/77-level or
elementary items in a CALL "using" phrase.  The "problem" of the intermediat
e
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 link
age
section, was the reason for that restriction.  Therefore, it is possible tha
t
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: 
>
>

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 
not 
and 
though 
>
> 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.

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

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