Layout Hell-o

Ok, for my 21 different layouts for 21 different files from the same
company:

In all the layouts whereever I see PIC S9(9) USAGE COMP,

The translation (whatever it may be) will be the same?

The same is true for all field definitions?

thanks

Carol,
You have a 99.99 % expectation that "COMP" will be the same for all the file
layouts that were created on a single machine (with a single compiler).  It 
is
POSSIBLE (but relatively unlikely) that COMP in different file layouts were
brought into different programs that were compiled with different compiler
options/directives.

For example, if the files were created with a Micro Focus compiler, the
IBM-COMP
COMP-5
TRUNC

compiler options all impact exactly what "USAGE COMP" means.  However, it is
 a
relatively safe assumption that if these 21 different files come from the sa
me
company (creating them on the same machine with the same compiler) that PROB
ABLY
they used the same options and COMP in one means the same thing as COMP in
another.

P.S. "COMP" in a *single* file layout *must* mean the same thing for every
layout within that same file.  Even I (who can find loop-holes in almost
anything <G> ) can't think of any way for COMP to have multiple meanings with
in a
single file layout.  Of course, COMP-3, COMP-4, COMP-5, etc *will*
possibly/probably mean different things.

P.P.S.  In all these threads have we talked about both implicitly and explic
it
"SYNC" and slack bytes?  If you see binary zeroes or other unexpected "junk"
between fields, it may because the compiler and operating systems (following
specific rules) may "insert" bytes (or even bits) between two defined fields
.

--
Bill Klein
wmklein <at> ix.netcom.com
"Carol" <kgdg@helkusa.com> wrote in message
news:_K2dnVflRe2AKpvcRVn-jA@comcast.com...
> Ok, for my 21 different layouts for 21 different files from the same
> company:
>
> In all the layouts whereever I see PIC S9(9) USAGE COMP,
>
> The translation (whatever it may be) will be the same?
>
> The same is true for all field definitions?
>
> thanks
>
>

I have seen that junk!  I have cheated by fudging the starting poinsts of
some of the translated fields.

I see that I may have been on to something.  Thank you for telling me why
that is.
!


"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:VhANc.597$cK.125@newsread2.news.pas.earthlink.net...
> Carol,
>     You have a 99.99 % expectation that "COMP" will be the same for all
the file
> layouts that were created on a single machine (with a single compiler).
It is
> POSSIBLE (but relatively unlikely) that COMP in different file layouts
were
> brought into different programs that were compiled with different compiler
> options/directives.
>
> For example, if the files were created with a Micro Focus compiler, the
>    IBM-COMP
>    COMP-5
>    TRUNC
>
> compiler options all impact exactly what "USAGE COMP" means.  However, it
is a
> relatively safe assumption that if these 21 different files come from the
same
> company (creating them on the same machine with the same compiler) that
PROBABLY
> they used the same options and COMP in one means the same thing as COMP in
> another.
>
> P.S. "COMP" in a *single* file layout *must* mean the same thing for every
> layout within that same file.  Even I (who can find loop-holes in almost
> anything <G> ) can't think of any way for COMP to have multiple meanings
within a
> single file layout.  Of course, COMP-3, COMP-4, COMP-5, etc *will*
> possibly/probably mean different things.
>
> P.P.S.  In all these threads have we talked about both implicitly and
explicit
> "SYNC" and slack bytes?  If you see binary zeroes or other unexpected
"junk"
> between fields, it may because the compiler and operating systems
(following
> specific rules) may "insert" bytes (or even bits) between two defined
fields.
>
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
> "Carol" <kgdg@helkusa.com> wrote in message
> news:_K2dnVflRe2AKpvcRVn-jA@comcast.com... 
>
>

Carol wrote:
> I have seen that junk!  I have cheated by fudging the starting
> poinsts of some of the translated fields.
>
> I see that I may have been on to something.  Thank you for telling me
> why that is.
> !

He told you "what." Here's the "why" of "slack" bytes.

Early on, and continuing to this day, there were machines that had a marked
decrease in efficiency if some data fields were not on the proper
(half-word, full-word, double-word) boundary. The program must move these
mis-aligned fields to a proper alignment before they could be operated upon.

For example, assume the computer, in order to do binary arithmetic, could
load the register (where the binary arithmetic was to be done) only from a
memory location on a full-word boundary.

Extra code was generated by the compiler to move the binary-word argument to
a temporary full-word boundary in memory before the register-load
instruction. After the binary computation in the register, additional code
would have to be generated to take the result from the register and store it
in a temporary area then move it from the temporary area to its rightful
place in the program.

In days of yore (and sometimes today), COBOL programmers kept in the front
of their mind these hardware oddities. The compiler, itself, helped by
forcing all "01" level data names to full-word boundaries.

77-level data items in COBOL told the compiler to ignore this default
alignment. You'll see programs with tons of 77-level items in
Working-Storage instead of 01-level items for this original reason. In other
words, originally:

01 Data-A Pic X.
01 Data-B Pic X.
01 Data-C Pic X

took up 12 bytes of storage. Change the "01" in each to "77" and the same
set takes up only three bytes - because the 01-level forces the compiler to
begin the data element on a full-word boundary in memory.

Many of today's machines don't really care about byte alignment. They can do
binary arithmetic in situ, that is, memory-to-memory, without having to load
a register. There are other machines with hardware instructions to load
accumulators/registers without regard for byte alignment of the parameters.

Still, "slack bytes" will be with us forever.

"Slack bytes" are not to be  with "expansion bytes" (areas stuck in
by the programmer for future use).

why - thank you!

Cobol is an interesting place to visit.
"JerryMouse" <nospam@bisusa.com> wrote in message
news:2KadnTEXxpAcP5rc4p2dnA@giganews.com...
> Carol wrote: 
>
> He told you "what." Here's the "why" of "slack" bytes.
>
> Early on, and continuing to this day, there were machines that had a
marked
> decrease in efficiency if some data fields were not on the proper
> (half-word, full-word, double-word) boundary. The program must move these
> mis-aligned fields to a proper alignment before they could be operated
upon.
>
> For example, assume the computer, in order to do binary arithmetic, could
> load the register (where the binary arithmetic was to be done) only from a
> memory location on a full-word boundary.
>
> Extra code was generated by the compiler to move the binary-word argument
to
> a temporary full-word boundary in memory before the register-load
> instruction. After the binary computation in the register, additional code
> would have to be generated to take the result from the register and store
it
> in a temporary area then move it from the temporary area to its rightful
> place in the program.
>
> In days of yore (and sometimes today), COBOL programmers kept in the front
> of their mind these hardware oddities. The compiler, itself, helped by
> forcing all "01" level data names to full-word boundaries.
>
> 77-level data items in COBOL told the compiler to ignore this default
> alignment. You'll see programs with tons of 77-level items in
> Working-Storage instead of 01-level items for this original reason. In
other
> words, originally:
>
> 01 Data-A Pic X.
> 01 Data-B Pic X.
> 01 Data-C Pic X
>
> took up 12 bytes of storage. Change the "01" in each to "77" and the same
> set takes up only three bytes - because the 01-level forces the compiler
to
> begin the data element on a full-word boundary in memory.
>
> Many of today's machines don't really care about byte alignment. They can
do
> binary arithmetic in situ, that is, memory-to-memory, without having to
load
> a register. There are other machines with hardware instructions to load
> accumulators/registers without regard for byte alignment of the
parameters.
>
> Still, "slack bytes" will be with us forever.
>
> "Slack bytes" are not to be  with "expansion bytes" (areas stuck
in
> by the programmer for future use).
>
>

..    Am  28.07.04
schrieb  nospam@bisusa.com (JerryMouse)
auf  /COMP/LANG/COBOL
in  2KadnTEXxpAcP5rc4p2dnA@giganews.com
ueber  Re: Layout Hell-o

n> took up 12 bytes of storage. Change the "01" in each to "77" and the
n> same set takes up only three bytes

unless the SYNCHRONIZED clause is specified in the data
description

n> - because the 01-level forces the
n> compiler to begin the data element on a full-word boundary in memory.


Yours,
Lüko Willms                                     http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Nach meiner Ansicht besitzt die Presse _das_ _Recht_,
Schriftsteller, Politiker, Komödianten und andere öffentliche
Charaktere zu _beleidigen_. Achtete ich [so einen Angriff gegen mich]
einer Notiz wert, so galt mir in solchen Fällen der Wahlspruch: à
corsaire, corsaire et demi [auf einen Schelmen anderthalben]."
- Karl Marx   17.11.1860  (Herr Vogt, Kapitel XI)

"JerryMouse" <nospam@bisusa.com> wrote in message
news:2KadnTEXxpAcP5rc4p2dnA@giganews.com...

> Early on, and continuing to this day, there were machines that had a
marked
> decrease in efficiency if some data fields were not on the proper
> (half-word, full-word, double-word) boundary. The program must move these
> mis-aligned fields to a proper alignment before they could be operated
upon.

This rationale may be accurately stated for some machines, but I don't think
it's necessarily accurate for all.  It is not now, nor has it ever (so far
as I know) been, necessary to move a non-sync word-oriented item to a
temporary array in order to retrieve it into top-of-stack on a Burroughs
B5000 or any of its successors.  The sequence of operations will be less
efficient, but it's doable without using a temporary.

>  The compiler, itself, helped by
> forcing all "01" level data names to full-word boundaries.

That depends on the implementation, but I'd say yes, probably 01-level items
are generally aligned at the largest applicable boundary irrespective of
content.  But any relationship *between* 01-level items is an
implementor-specified detail; for example, in Unisys MCP COBOL74 (and its
COBOL(68) predecessor), every 01-level item occupies a *separate* memory
space.  The 01-level item is thus word-aligned not because 01-level items
are word-aligned but because memory is allocated in word-aligned chunks.

> 77-level data items in COBOL told the compiler to ignore this default
> alignment.

Not exactly, as I understand it.  Level 01 was originally intended to apply
to records to which elementary items were subordinate and to inform the
compiler to expect (but not require) such subordinate elementary items.
Level 77 was intended to inform the compiler that no such subordinate
entries existed and that the data items so described were independent of any
other data items.  The standard has never mandated a difference in
functionality between an 01-level elementary item and a 77-level item.  The
big difference is that the implementor can do what he wants with the
information that the item's description isn't dependent on its location or
its relationship to any other data item.  What the implementor does with
that information is up to the implementor.  And the reasons a user in one
implementation might want to use 77's instead of 01's might indeed be in
*direct conflict* with different implementations.  If a 77-level numeric
item is generally presumed to be "on the stack" in a stack-oriented machine,
it's likely to be retrievable *much* more quickly than an 01-level
elementary item if the compiler must generate code to retrieve the latter
through a descriptor to memory!

> You'll see programs with tons of 77-level items in
> Working-Storage instead of 01-level items for this original reason.

You may see programs with lots of 77-level *numeric* items in
Working-Storage instead of 01-level items because the compiler recognizes,
since these are 77-level items, it's often free to optimize the usage.
It's not clear to me that "this original reason" is the only possible
explanation.  I know programmers who use 77-level items to describe
independent data items and reserve 01 for records precisely because they
want to make it absolutely and unambiguously clear that their 77-level items
are independent data items and their 01-level items are, or are to be
treated as, records.

> In other words, originally:
>
> 01 Data-A Pic X.
> 01 Data-B Pic X.
> 01 Data-C Pic X
>
> took up 12 bytes of storage. Change the "01" in each to "77" and the same
> set takes up only three bytes - because the 01-level forces the compiler
to
> begin the data element on a full-word boundary in memory.

On some systems, not all!

It's not clear to me that the "original reason" is that 77-level items butt
up against one another at byte boundaries thus saving memory, and 01-level
ones require a minimum of 32 bits -- in fact, I think there's as much
evidence to suggest that the *original* reason is that 77-level numerics end
up on the stack and were accessible by a simple VALC, while 01-level
elementary numerics were in memory and required sequences like LT, NAMC,
NXLV (at best) to retrieve them!   ;-)

> Still, "slack bytes" will be with us forever.

I agree.  But  I don't think of "slack bytes" as the space between 01's, or
for that matter, between 77's, but rather empty spaces between items *in a
record*.

For example, the Unisys MCP implementation requires group items to begin and
end on a byte boundary (for purposes of MOVE, they are, after all,
alphanumeric).  However, packed-decimal items, which occupy data in four-bit
increments, may begin or end on a four-bit boundary.  If for example the
last elementary item in a group begins on a byte boundary but is unsigned
and contains an odd number of digits, or is signed and contains an even
number of digits, the group that immediately follows will be preceded by
four slack bits.

E.g.,
01  A-RECORD.
03  GROUP-1.
05  ITEM-1 PIC S9(4) PACKED-DECIMAL.
*    four slack bits go here
03  GROUP-2.
05  ITEM-2 PIC 9(5) PACKED-DECIMAL.
* four more slack bits go here
03  ITEM-3 PIC X.

-Chuck Stevens

Jerry, I nominate you to do definitions.  That was a very clear
description of
the problem from most perspectives.  The Engineers would wonder why<G>
Thanks for that effort.

Warren Simmons


JerryMouse wrote:

>Carol wrote:
>
> 
>
>He told you "what." Here's the "why" of "slack" bytes.
>
>Early on, and continuing to this day, there were machines that had a marked
>decrease in efficiency if some data fields were not on the proper
>(half-word, full-word, double-word) boundary. The program must move these
>mis-aligned fields to a proper alignment before they could be operated upon
.
>
>For example, assume the computer, in order to do binary arithmetic, could
>load the register (where the binary arithmetic was to be done) only from a
>memory location on a full-word boundary.
>
>Extra code was generated by the compiler to move the binary-word argument t
o
>a temporary full-word boundary in memory before the register-load
>instruction. After the binary computation in the register, additional code
>would have to be generated to take the result from the register and store i
t
>in a temporary area then move it from the temporary area to its rightful
>place in the program.
>
>In days of yore (and sometimes today), COBOL programmers kept in the front
>of their mind these hardware oddities. The compiler, itself, helped by
>forcing all "01" level data names to full-word boundaries.
>
>77-level data items in COBOL told the compiler to ignore this default
>alignment. You'll see programs with tons of 77-level items in
>Working-Storage instead of 01-level items for this original reason. In othe
r
>words, originally:
>
>01 Data-A Pic X.
>01 Data-B Pic X.
>01 Data-C Pic X
>
>took up 12 bytes of storage. Change the "01" in each to "77" and the same
>set takes up only three bytes - because the 01-level forces the compiler to
>begin the data element on a full-word boundary in memory.
>
>Many of today's machines don't really care about byte alignment. They can d
o
>binary arithmetic in situ, that is, memory-to-memory, without having to loa
d
>a register. There are other machines with hardware instructions to load
>accumulators/registers without regard for byte alignment of the parameters.
>
>Still, "slack bytes" will be with us forever.
>
>"Slack bytes" are not to be  with "expansion bytes" (areas stuck in
>by the programmer for future use).
>
>
>
>

"JerryMouse" <nospam@bisusa.com> wrote

> 77-level data items in COBOL told the compiler to ignore this default
> alignment. You'll see programs with tons of 77-level items in
> Working-Storage instead of 01-level items for this original reason. In oth
er
> words, originally:
>
> 01 Data-A Pic X.
> 01 Data-B Pic X.
> 01 Data-C Pic X
>
> took up 12 bytes of storage. Change the "01" in each to "77" and the same
> set takes up only three bytes - because the 01-level forces the compiler t
o
> begin the data element on a full-word boundary in memory.

I don't think that is true, or is certainly not true in some
implementations.

77 levels are _non-contiguous_ items.  This means that they are _not_
contiguous, or at least do not need to be contiguous, whereas you have
it that the 77 level _makes_ them contiguous.

In all implementations that I have used a 77 level it treaded
identically to it being an 01 with no subordinate items.  In other
words your example using 01s would take 12 (or 24) bytes and as 77s
would take exactly the same amount of space.

In fact with MicroFocus there is an 'ALIGN' directive which specifies
the alignment boundary to be used for both 01s and 77s.  The default
is 8 bytes, hence 24 for the 3 01 or 77s.

The way to defeat slack bytes is to use sub-ordinate items to a
grouping 01.

01  Data-Group.
03 Data-A Pic X.
03 Data-B Pic X.
03 Data-C Pic X.

This takes 3 bytes and will be followed by one or more slack bytes
before the next 01 or 77.

The point about 77s is that they are non-contiguous, the compiler is
allowed to (but need not) insert slack bytes, or move some of these
items elsewhere in memory, or shuffle them in any way it feels like.
01 levels are record items and are expected to have subordinate items.
Each subordinate item _is_ contiguous at the byte level.

Just a historical note: I was given a client support problem back in
the late 60s when a customer couldn't fit his program into the 16Kword
1901A machine.  He had 'saved space' by having a series of single
character flags as 03 levels in a record.  It turned out that each
reference to one of these flags required 11 words of instructions to
extract and align the character, it being a word machine and rather
clumsy with characters.  Changing all those flags to use a word each
saved several Kwords and made it fit.

I thought that Chuck had already explained this.

There is nothing in the '85 (or 2002 - or I think 74) Standards that in ANY 
way
distinguishes between

01  Field1  Pic X
01  Field2  Pic X

and

77 Field1 Pic X.
77 Field2 Pic X.

The implementor may (or may not)

A) put the 01-levels on specific types of boundaries
B) put the 77-levels on the same or different types of boundaries
C) place field1 and field2 (of either type) in any particular relationship t
o
each other in real or virtual storage.

There is one and ONLY one difference between 01-levels and 77-levels:

01-levels MAY (but need not) have subordinate items;
77-levels may NOT (ever) have subordinate items defined.

Slack bytes (or bits) in COBOL terminology refer only to those bytes within 
the
same "record" description, e.g.

01  aRecord.
05  Fielda Pic X.
*> there might be a slack byte, bit or other here
05  Fieldb  Pic  9 Binary Sync.
*> there might or might not be slack stuff here
05  Where-does-the-group-start
Occurs 5 times.
10  Fieldc   Usage Index
*>  what about this?
10  Fieldd  Pic S9(2) Usage Packed-Decimal.
*> what about here?

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0407281440.66ad2469@posting.google.com...
> "JerryMouse" <nospam@bisusa.com> wrote
> 
>
> I don't think that is true, or is certainly not true in some
> implementations.
>
> 77 levels are _non-contiguous_ items.  This means that they are _not_
> contiguous, or at least do not need to be contiguous, whereas you have
> it that the 77 level _makes_ them contiguous.
>
> In all implementations that I have used a 77 level it treaded
> identically to it being an 01 with no subordinate items.  In other
> words your example using 01s would take 12 (or 24) bytes and as 77s
> would take exactly the same amount of space.
>
> In fact with MicroFocus there is an 'ALIGN' directive which specifies
> the alignment boundary to be used for both 01s and 77s.  The default
> is 8 bytes, hence 24 for the 3 01 or 77s.
>
> The way to defeat slack bytes is to use sub-ordinate items to a
> grouping 01.
>
>   01  Data-Group.
>      03 Data-A Pic X.
>      03 Data-B Pic X.
>      03 Data-C Pic X.
>
> This takes 3 bytes and will be followed by one or more slack bytes
> before the next 01 or 77.
>
> The point about 77s is that they are non-contiguous, the compiler is
> allowed to (but need not) insert slack bytes, or move some of these
> items elsewhere in memory, or shuffle them in any way it feels like.
> 01 levels are record items and are expected to have subordinate items.
>  Each subordinate item _is_ contiguous at the byte level.
>
> Just a historical note: I was given a client support problem back in
> the late 60s when a customer couldn't fit his program into the 16Kword
> 1901A machine.  He had 'saved space' by having a series of single
> character flags as 03 levels in a record.  It turned out that each
> reference to one of these flags required 11 words of instructions to
> extract and align the character, it being a word machine and rather
> clumsy with characters.  Changing all those flags to use a word each
> saved several Kwords and made it fit.