| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3194.1 | some info on alignment around DECforms | CSC32::E_VAETH | Suffering from temporary brain cramp, stay tuned | Fri Feb 07 1997 15:48 | 124 |
| There is an article available on the database that discusses issues
with alignment and DECforms... don't know if this helps.
[DECforms] FORMS-E-BADRECLEN After Migrating To Alpha System
Any party granted access to the following copyrighted information
(protected under Federal Copyright Laws), pursuant to a duly executed
Digital Service Agreement may, under the terms of such agreement copy
all or selected portions of this information for internal use and
distribution only. No other copying or distribution for any other
purpose is authorized.
Copyright (c) Digital Equipment Corporation 1995. All rights reserved.
PRODUCT: DECforms for OpenVMS AXP, Version 1.4C/D, 2.1
OP/SYS: OpenVMS AXP, Version 6.1
COMPONENT: DECforms Runtime
SOURCE: Digital Equipment Corporation
SYMPTOM:
You have recently migrated your DECforms based application from the
VAX platform to the AXP platform and recompiled/relinked the
application. When the application is executed, the following error
condition is signaled:
FORMS-E-BADRECLEN, the record length argument does not match the
length of the record in the form.
The exact same higher level language compilation statements and link
statements were executed on both the VAX and the AXP although the
runtime failure only occurs on the AXP. What could cause this error?
SOLUTION:
Insure that the FORMS TRANSLATE member alignment and the compiler
alignment directive match. For example if COBOL and DECforms are
used, the following options would promote compatible record
alignments:
COBOL DECforms
Byte Alignment: /NOALIGNMENT /NOMEMBER_ALIGNMENT
Specifying NOMEMBER_ALIGNMENT causes record fields to be
aligned by byte. Each record field begins on the first byte
after the previous record field.
COBOL DECforms
Natural Alignment: /ALIGNMENT /MEMBER_ALIGNMENT
For compatibility between VAX and Alpha platforms this switch
will only affect the Alpha run-time record alignments, the VAX
run-time records will always be byte aligned. In this way the
produced .FORM file will be compatible between platforms.
Therefore, this switch has no effect on a VAX platform and on
Alpha the default for this switch is /MEMBER_ALIGNMENT.
The /MEMBER_ALIGNMENT=[(type=,...)] values are a list of
datatypes and the alignment multiples to use for each. Each
datatype can be aligned using one of these 5 alignment multiple
directives:
byte_alignment
word_alignment
longword_alignment
quadword_alignment
octaword_alignment
The valid datatypes that can be specified and their defaults
are:
BYTE= byte_alignment
WORD= word_alignment
LONG= longword_alignment
QUAD= quadword_alignment
ADT= quadword_alignment
TEXT= byte_alignment
VARYING_TEXT= word_alignment
F_FLOAT= longword_alignment
D_FLOAT= quadword_alignment
G_FLOAT= quadword_alignment
H_FLOAT= octaword_alignment
S_FLOAT= longword_alignment
T_FLOAT= quadword_alignment
X_FLOAT= octaword_alignment
For compatibility with Alpha DECforms V1.4 you will need to
specify "Forms Translate /Member_alignment=ADT=Longword".
Otherwise you will need to modify the programming language
defined records so that ADT fields meet the default quadword
alignment. See the /LIST listing file output section on
"Structure Layout Listing" for help.
If you find that you are indeed using compatible higher-level
alignment clauses and DECforms FORMS TRANSLATE clauses and still
receive the error checking the PADDING option and compare it to
technique used for compiler used.
If this does not seem to explain the error then manually attempt to
construct and understand the record sizes between the form record and
higher-level language. Additional information regarding tracing
techniques and padding techniques can be found in the DECforms file
SYS$HELP:FORMSA021.RELEASE_NOTES.
ANALYSIS:
Note that the DECforms AXP FORMS TRANSLATE default for MEMBER_ALIGNMENT
is /MEMBER_ALIGNMENT. This means that the DECforms forms records will
be naturally aligned on the AXP. If your record structures have not
changed between the VAX and AXP you may want to check the corresponding
default for your higher-level language compiler. Note that some
compilers still use the byte alignment technique, and if the DECforms
forms manager attempts to compare the structure descriptor sizes of
byte aligned structures to a DECforms translated form using the
default /MEMBER_ALIGNMENT, the record alignment techniques are not
compatible. This may cause the runtime error of FORMS-E-BADRECLEN to
be signaled as the underlying structure sizes are not equal.
|
| 3194.2 | Analysis and request for more information | PACKED::MASLANKA | | Fri Feb 07 1997 16:13 | 97 |
| Re .1
Hi,
I tested your submitted program on one of our in-house Digital Alphas
running OpenVMS Alpha Version 6.1 using the installed DEC COBOL V2.4-863.
I used three command lines to do three test compiles, as follows:
1. $ cobol/lis=abc_noalign/map=dec/noalign abc
2. $ cobol/lis=abc_align_nopad/map=dec/align=nopad abc
3. $ cobol/lis=abc_align_pad/map=dec/align=pad abc
My opinion is that the /ALIGN=[NO]PAD qualifer is functioning properly.
(My analysis follows.) This being the case, I feel we need you to ask
your customer to provide us with examples of the behavior that he is
expecting from /ALIGN=NOPAD and /ALIGN=PAD.
Here is my analysis.
The data structure of interest is 01 test2, because it is subject to
the value of the /align qualifier on the command line. The structure
01 test1 is not relevant, since it is enclosed by the two *DC SET
compiler directives which govern its compile. The *DC SET NOALIGNMENT
has the same effect as the /NOALIGN qualifier, and it takes precedence
over any /PAD command-line qualifier.
The compiler's /MAP=DECLARED qualifier produces the following maps for
each of the three cases.
1. $ cobol/lis=abc_noalign/map=dec/noalign abc
In this case test2 is double-word aligned, which is a feature of 01
data-items in DEC COBOL, and it is a total of five bytes in length.
The first field, with PIC X occupies 1 byte, followed immediately by
the four-byte COMP field. (Note: in this case the COMP field is byte-
aligned, not long-word aligned.)
Line Level Name Location Size Bytes Usage Category Subs Attribute
----- ----- ------------------------------- ------------- ---------- ---------- -------- -------- ---- ---------
12 01 TEST1 2 00000000 5 5 DISPLAY Group
13 05 A 2 00000000 1 1 DISPLAY AN
14 05 B 2 00000001 9 4 COMP N
17 01 TEST2 2 00000008 5 5 DISPLAY Group
18 05 A 2 00000008 1 1 DISPLAY AN
19 05 B 2 00000009 9 4 COMP N
2. $ cobol/lis=abc_align_nopad/map=dec/align=nopad abc
In this case test2 is also double-word aligned, and it is a total of eight
bytes in length. Padding is required internally in the record in order to
effect the proper alignment of the COMP field, which is long-word aligned.
However, no padding is required at the end of the record, since the length
is not required to be a multiple of the alignment.
The first field, with PIC X, occupies 1 byte, followed immediately by three
slack bytes. The four-byte COMP field has to be full-word aligned. This is
why the three slack bytes are interpolated. But, the data structure requires
no additional padding at the end. Thus, the data structure is a total of eight
bytes long.
Line Level Name Location Size Bytes Usage Category Subs Attribute
----- ----- ------------------------------- ------------- ---------- ---------- -------- -------- ---- ---------
12 01 TEST1 2 00000000 5 5 DISPLAY Group
13 05 A 2 00000000 1 1 DISPLAY AN
14 05 B 2 00000001 9 4 COMP N
17 01 TEST2 2 00000008 8 8 DISPLAY Group
18 05 A 2 00000008 1 1 DISPLAY AN
19 05 B 2 0000000C 9 4 COMP N
3. $ cobol/lis=abc_align_pad/map=dec/align=pad abc
In this case test2 is also double-word aligned, and it is also a total of
eight bytes in length, coincidentally. Eight being a multiple of four does
not require any more padding to comform to Alpha natural alignment and padding.
The first field, with PIC X occupies 1 byte, followed immediately by three
slack bytes. The four-byte COMP field has to be long-word aligned, but it
needs no additional padding at the end because of course four is the first
multiple of itself. This makes the data structure eight bytes long, which
is a multiple of four. So, the entire data structure does not require any
additional padding to comform to Alpha natural alignment and padding.
Line Level Name Location Size Bytes Usage Category Subs Attribute
----- ----- ------------------------------- ------------- ---------- ---------- -------- -------- ---- ---------
12 01 TEST1 2 00000000 5 5 DISPLAY Group
13 05 A 2 00000000 1 1 DISPLAY AN
14 05 B 2 00000001 9 4 COMP N
17 01 TEST2 2 00000008 8 8 DISPLAY Group
18 05 A 2 00000008 1 1 DISPLAY AN
19 05 B 2 0000000C 9 4 COMP N
John Maslanka
DEC/VAX COBOL Development
|
| 3194.3 | Still some questions... | UTRTSC::DORLAND | The Wizard of Odz2 | Mon Feb 10 1997 05:53 | 12 |
| RE .2: Thank you for this excellent clarification.
But still, if you RUN the program you'll see
that moving the value 12345 from test1 to test2
will result in different values being displayed
depending on the /ALIGN qualifier;
if /NOLALIGN is used both values will be 12345,
with /ALIGN= <any value> the values are no
longer the same.
That is something which I do not really understand.
Rgds, Ton
|
| 3194.4 | MOVE CORRESPONDING? | PACKED::BRAFFITT | | Mon Feb 10 1997 07:09 | 64 |
| > But still, if you RUN the program you'll see
> that moving the value 12345 from test1 to test2
> will result in different values being displayed
> depending on the /ALIGN qualifier;
DEC COBOL is working as expected for this program.
With /ALIGN, the MOVE does a 5 byte move to a 10 byte destination using
alphanumeric move rules.
I think what you may want is
MOVE CORRESPONDING
$ run c3194
A90
12345
538976256
12345
12345
identification division.
program-id. ABC.
date-written. 7-feb-1997.
environment division.
data division.
working-storage section.
*DC SET NOALIGNMENT
01 test1.
05 a pic x(1).
05 b pic s9(09) comp.
*DC END-SET ALIGNMENT
01 test2.
05 a pic x(1).
05 b pic s9(09) comp.
procedure division.
main-routine.
move "A" to a of test1.
move 12345 to b of test1.
display test1.
display test2.
display b of test1 conversion.
move test1 to test2.
display b of test2 conversion.
move a of test1 to a of test2.
move b of test1 to b of test2.
display b of test2 conversion.
move corresponding test1 to test2.
display b of test2 conversion.
main-routine-exit.
exit program.
|
| 3194.5 | Problem is due to inappropriate group-item move | PACKED::MASLANKA | | Mon Feb 10 1997 15:30 | 64 |
| Re .3
I think I see what your question is asking. I think we were confused
because we thought it was a FORMS question. Don Braffitt was closest
to answering your question when he ignored your mention of FORMS and
suggested that you use MOVE CORRESPONDING.
In your original test program when you said MOVE TEST1 TO TEST2, you
are doing what is known in COBOL as a "group-item" movement of the
data. This type of a move id done as a character move, in which each
byte of the sending field is moved to the corresponding byte of the
receiving field. In your test program, TEST1 and its two subordinate
fields are always byte-aligned because of the *DC SET ALIGNMENT and
*DC END-SET ALIGNMENT directives. The byte-aligned fields can be
shown as in the following diagram, starting from the left:
Bytes 1 2345
+------+
|TEST1 |
+-+----+
|*|** |
+-+----+
* Your "A" field is byte-aligned naturally, happens to be double-word
aligned here because it is the first elementary field in the data
structure.
** Your "B" field is byte-aligned even though it is COMP, which means
that it occupies bytes 2 thru 5 of your data structure. This has a
serious consequence when your group-item move is done.
For compiles with /ALIGNMENT and /ALIGNMENT=PADDING, your group data
structure TEST2 has "slack" bytes built into it. This data structure
is simple enough so that the results of using either compile-time
qualifier are the same. In this structure, the B field of the TEST2
structure is LONGWORD-aligned, with the result that three slack bytes
are interpolated between the two sub-fields. This is illustrated in
the following diagram.
Bytes 1 234 5678
+----------+
|TEST2 |
+-+---+----+
|&|&& |&&& |
+-+---+----+
& Your "A" field is byte-aligned naturally, happens to be double-word
aligned here because it is the first elementary field in the data
structure.
&& The three interpolated slack bytes
&&& Your "B" field is LONGWORD-aligned, which means that it occupies
bytes 5 thru 8 of your data structure.
When the group-item move of TEST1 to TEST2 is done, the five bytes of
TEST1 are moved to the first five bytes of TEST2. The remaining three
bytes of TEST2 are filled with SPACES. This means that your B field in
TEST2 has a mongrel value in it. Its first byte is the last bye of the
B field in TEST1, and the last three bytes contain spaces. This
configuration of data values can be interepreted as a Longword integer,
which is what PIC S9(9) COMP means. When you display this value with
conversion as you have done, it shows 538976256, which is perfectly
alright for what was done.
|
| 3194.6 | MOVE CORRESPONDING does the trick! | UTRTSC::DORLAND | The Wizard of Odz2 | Tue Feb 11 1997 03:11 | 8 |
| Thanks again for this excellent explanation.
Indeed MOVE CORRESPONDING is the way to solve this problem.
It will most likely also solve the FORMS releated problems
as well but I'll test that out.
Rgds,
Ton
|