| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3200.1 | Recommend using DEC COBOL Data Name map to help resolve discrepancies | PACKED::MASLANKA | | Thu Feb 13 1997 14:15 | 95 |
| I put your new data structure into a copy of your ABC program, which
I have appended below. You will note that I used the *DC SET directives
in the source code to control the compile-time data allocations. When
I compiled the program I used the qualifiers /LIS/MAP=DECLARED. I also
appended the output list map below. You will observe that there now
are differences in beginning positions and the amounts of space that
are allocated for each data structure. You can see these things in the
columns which are titled "Location" and "Bytes". The Location column
tells you the beginning position of each field in hexadecimal and the
"Bytes" column tells you the lenght of each field in bytes. In this
column you should pay attention to the lengths of the group data-items,
i.e. TEST1 is 6 bytes long, TEST2 is 9, and TEST3 is 16. If you require
these fields to be of different lengths than what the DEC COBOL compiler
produces by default, you must do one of two things. First, if the COBOL
group data-item is too short as shown to accomodate the DECFORMS field,
you must insert COBOL FILLER sub-fields into produce the appropriate
sizes and alignments. (Elin Vaeth's reply in 3194.1 says this.) Second,
if the COBOL group data-item is too long (which is very unlikely), you
will have to remove sub-fields.
The actual problem between DEC COBOL and DECFORMS alignments may arise
because of differences in their positionings of top-level data fields.
DEC COBOL uses double-word alignment for the top-level fields. This
can be seen readily in the listing map. DECFORMS may use some other
top-level alignment. This is not a DEC COBOL problem. However, it is
a thing which other users have already worked through successfully with
their applications. Also, DEC COBOL alignments have been successfully
tested with other Digital software products under the current supported
versions of OpenVMS Alpha and Digital UNIX.
1 identification division.
2 program-id. ABCA.
3 date-written. 13-feb-1997.
4
5 environment division.
6
7 data division.
8
9 working-storage section.
10
11 *DC SET NOALIGNMENT
12 01 test1.
13 05 a pic x(1).
14 05 b pic s9(09) comp.
15 05 c Pic x(1).
16 *DC END-SET ALIGNMENT
17
18 *DC SET ALIGNMENT
19 01 test2.
20 05 a pic x(1).
21 05 b pic s9(09) comp.
22 05 c Pic x(1).
23 *DC END-SET ALIGNMENT
24
25 *DC SET PADALIGN
26 01 test3.
27 05 a pic x(1).
28 05 b pic s9(09) comp.
29 05 c Pic x(1).
30 *DC END-SET PADALIGN
31
32 procedure division.
33
34 main-routine.
35
36 move "A" to a of test1.
37 move 12345 to b of test1.
38 move test1 to test2 test3.
39
40 display b of test1 conversion.
41 display b of test2 conversion.
42 display b of test3 conversion.
43
44 main-routine-exit.
45 exit program.
0 Data Names in Declared Order 13-FEB-1997 10:53:19 ABCA.COB;2
Line Level Name Location Size Bytes Usage Category Subs Attribute
----- ----- ------------------------------- ------------- ---------- ---------- -------- -------- ---- ---------
12 01 TEST1 2 00000000 6 6 DISPLAY Group
13 05 A 2 00000000 1 1 DISPLAY AN
14 05 B 2 00000001 9 4 COMP N
15 05 C 2 00000005 1 1 DISPLAY AN
19 01 TEST2 2 00000008 9 9 DISPLAY Group
20 05 A 2 00000008 1 1 DISPLAY AN
21 05 B 2 0000000C 9 4 COMP N
22 05 C 2 00000010 1 1 DISPLAY AN
26 01 TEST3 2 00000018 16 16 DISPLAY Group
27 05 A 2 00000018 1 1 DISPLAY AN
28 05 B 2 0000001C 9 4 COMP N
29 05 C 2 00000020 1 1 DISPLAY AN
|
| 3200.2 | More on DEC COBOL V2.4 and /ALIGN=PADDING | PACKED::BRAFFITT | | Thu Feb 13 1997 14:17 | 68 |
| > with Cobol and with DecForms. Or could you tell
> me which qualifiers to use such as to get
> it compatible (while still using alignment).
The option
COBOL /ALIGN=PADDING
is designed to produce records which are padded out to a multiple of
the alignment of the record as required for Alpha natural alignment.
You can get details of the record structure with
COBOL /ALIGN=PADDING/LIST/MAP
Make sure you are using DEC COBOL V2.4. There is a bug in handling
of /ALIGN=PADDING in DEC COBOL V2.3. The updated documentation on
/ALIGN=PADDING is in the DEC COBOL V2.4 Release Notes.
If you think you have a record structure which uses /ALIGN=PADDING and
is not working as documented, post the record structure here along with
a specific indication of how you think this record structure is not
being padded as documented.
******************************
CLT::CLT$LIBRARY:[DEC_COBOL]DEC_COBOL_RN_V24.TXT;1
V2.4-863 /ALIGN=PADDING (-align padding) and the *DC SET PADALIGN
directive now properly interact with other uses of /ALIGN
(-align) and other directives. See the section on Doc-
umentation Notes for details.
...
V2.4-863 The material below updates section 16.4 of the DEC COBOL
User Manual.
*DC SET ALIGNMENT - makes a new entry in the align stack
which activates align with no padding
*DC SET NOALIGNMENT - makes a new entry in the align stack
which activates noalign. (VAX-compatible) that is, a pre-
vious state of either alignment or padalign is superseded
by a state of no alignment. Synonym: *DC SET NOPADALIGN
*DC SET PADALIGN - makes a new entry in the align stack
which activates align with padding
*DC END-SET ALIGNMENT - removes the current entry from
the align stack, that is, the current state of alignment
is deactivated and the state of alignment reverts to the
preceding entry on the stack. Synonym: *DC END-SET PADALIGN
Also, the initial state of alignment in a COBOL program
is determined from the presence or absence of the qual-
ifier /[NO]ALIGN[=[NO]PADDING] on the compiler's command
line. The command-line qualifier setting for alignment
is superseded by the *DC SET ALIGNMENT and *DC SET PADALIGN
compiler directives in the user's COBOL program. The align-
ment setting of the command line can be restored by the
use of the *DC END-SET ALIGNMENT compiler directive within
the COBOL program's source text.
...
For example, if a C module is compiled with the C equivalent of
/NOALIGNMENT (the DEC COBOL default on both Digital UNIX and Open-
VMS Alpha), that is, "#pragma nomember_alignment", then a DEC COBOL
module that calls or is called by that C module should be compiled
with no alignment. The DEC C default is MEMBER_ALIGNMENT. For com-
patibility with DEC C's "#pragma member_alignment", use
/ALIGNMENT=PADDING (-align padding) or *DC SET PADALIGN.
|
| 3200.3 | The diff. is in PADDING, ALIGNMENT is oke | UTRTSC::DORLAND | The Wizard of Odz2 | Mon Feb 17 1997 07:39 | 12 |
| Well, the bottom line is that the difference between COBOL
and FORMS lies in the PADDING.
Using FORMS TRANSL/ALIGN/NOPAD /LIST and COBOL/ALIGN/MAP=DECL
works and shows that the same alignment is used. When using
padding there are differences, but this is also stated in
the release notes of DecForms.
Thanks for all the answers so far, if this customer can produce
an example which does not comply to this I'll psot it here.
Regards, Ton
|
| 3200.4 | Example showing the problem... | UTRTSC::DORLAND | The Wizard of Odz2 | Wed Feb 19 1997 10:41 | 66 |
|
I posted the message below in DecForms.
The constructs below proves that there are
mismatches between COBOL and FORMS.
Hope you can help me out on this.
Hello,
I have a question with respect to Alignment .
Consider the following FORMS statements:
FORM RECORD X1
name character(1)
numbr word integer
state character(1)
END RECORD
or
FORM RECORD X1
group mygroup
name character(1)
numbr word integer
state character(1)
end group
END RECORD
Now if you compile this with FORMS TRANSLATE/MEBER/NOPAD/LIST
you'll see that the alignment results in 5 bytes for case 1
and 6 for case 2. Probably FORMS aligns groups.
Now if you try to 'match' this in COBOL you are in trouble:
WORKING STORAGE SECTION.
01 X1.
05 name pic x(1).
05 numbr pic s9(4) comp.
05 state pic x(1).
or
01 X1.
03 mygroup.
05 name pic x(1).
05 numbr pic s9(4) comp.
05 state pic x(1).
When compiled with COBOL/ALIGN/MAP=DECL/LIST it will show that
both constructs result in a 5 bytes long record. Thus, when
using the group construct in FORMS, the application will
fail with the unfamous BADRECLEN error.
I am having a rather urgent discussion with a customer
who is porting some 1000+ COBOL/FORMS application to Alpha.
He claims that either FORMS or COBOL is not really using natural
alignment, but who is at fault?
Is there anything other which may help here?
Regards and thanks in adavnce,
Ton Dorland
(Tested on VMS 6.2, DECCOBOL 2.4, DECFORMS 2.1B)
|
| 3200.5 | You need to compile COBOL/ALIGN=PADDING | PACKED::BRAFFITT | | Wed Feb 19 1997 11:29 | 10 |
| > When compiled with COBOL/ALIGN/MAP=DECL/LIST it will show that
> both constructs result in a 5 bytes long record. Thus, when
> using the group construct in FORMS, the application will
> fail with the unfamous BADRECLEN error.
You need to compile
COBOL/ALIGN=PADDING
to get Alpha natural alignment and padding.
|
| 3200.6 | Still mismatches for PERSONNEL_RECORD... | UTRTSC::DORLAND | The Wizard of Odz2 | Wed Feb 19 1997 12:26 | 13 |
| Yes, but in the example I'll posted in .4 this will give
an 8 byte reocrd for PERSONNEL_RECORD which stil does not
match FORMS. Even when you use FORMS TRANSL/MEMB/PADDING
FORMS will think PERSONNEL_RECORD is 6 bytes.
So either FORMS or COBOL does not do complete natural
alignment.
I am pleased with the quick replies, I also have contacts
with DSSDEV::RICE (Tim) for the FORMS side of the problem.
I have a feeling we are getting close to a final answer
here.
Rgds, Ton
|
| 3200.7 | DECFORMS may require some migration work for VAX-to-DEC COBOL | PACKED::MASLANKA | | Wed Feb 19 1997 12:31 | 30 |
| Re .4
With DEC COBOL compilations,
/NOALIGN gives the default COBOL alignments. Computational fields
are byte-aligned unless the SYNCHRONIZED syntax is applied.
/ALIGN gives Alpha natural alignment of fields within records. The
alignment of a non-01 group data-item is determined by the
alignment requirment of the subordinate field with the
most severe alignment requirment.
/ALIGN=PADDING does the same as /ALIGN, but in addition it pads out
all aligned fields to be multiples of their alignments.
The /MAP feature shows exactly what DEC COBOL does for any specified
COBOL data structure.
If you use DEC COBOL with DECFORMS you will have to do some adjustments
to the formatting of your own data in some cases in order to obtain
the alignment effects which are desired. The two products have different
data formatting requirements which are dependent upon their different
engineering requirements.
Also, since VAX COBOL is completely unaware of Alpha Natural Alignment
and Padding, there are distinct differences between this product and
DEC COBOL. A great many VAX COBOL programs migrate unchanged to DEC
COBOL, but it is unrealistic to expect them all to do so. Usage of
DECFORMS is one area where DEC COBOL users have had to do some recoding
work to produce acceptable results.
|
| 3200.8 | Oke, that's final | UTRTSC::DORLAND | The Wizard of Odz2 | Wed Feb 19 1997 12:54 | 20 |
| Well it is a pity that there are subtle differences between
COBOL and FORMS but at least I now know what to tell the customer.
Unfortunately they use a lot of GROUP constructs within FORMS,
without that using NOPADDING both at the COBOL and FORMS side
would have worked for most of his code.
Anyway, the final target for the customer's application is
ACMS so I think he will have to disable ALIGNment anyway for
records passed between COBOL and FORMS.
Thanks for all the answers, I'll consider this call closed.
(PS, any plans to have Compiler options for this p[roblem in
a future release?)
Rgds, Ton
|
| 3200.9 | See notes 2751 and 2833 | PACKED::BRAFFITT | | Wed Feb 19 1997 13:31 | 30 |
| > Yes, but in the example I'll posted in .4 this will give
> an 8 byte reocrd for PERSONNEL_RECORD which stil does not
> match FORMS. Even when you use FORMS TRANSL/MEMB/PADDING
> FORMS will think PERSONNEL_RECORD is 6 bytes.
> So either FORMS or COBOL does not do complete natural
> alignment.
As John said, DEC COBOL is correctly doing natural alignment and
padding with /ALIGN=PADDING based on the initial alignment in DEC COBOL
of the group item.
> (PS, any plans to have Compiler options for this p[roblem in
> a future release?)
There are no current plans to provide a DEC COBOL compiler option to
control the initial aligment of a group item. I do not know if
DECforms already includes such an option or is planning such as option.
The background information on the support requested by DECforms and
ACMSxp and added to DEC COBOL related to /ALIGN=PADDING is detailed in
notes 2751 and 2833.
We will consider other requests for additions to DEC COBOL that make it
easier to use DEC COBOL with DECforms, but we have had no additional
requests from either DECforms or ACMSxp after the new /ALIGN=PADDING
support was delivered to them as requested.
Any requests for possible future support in DEC COBOL should be
directed to the DEC COBOL Product Manager - Tariq Nazeer
(TEAMLK::NAZEER).
|