Kbase 367: vms fields: tricks when writing to and designing appl. for
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
vms fields: tricks when writing to and designing appl. for
901119-SEC02VMS Items.
The length of packed decimal fields is specified in bytes. VMS
specifies these things in nibbles, so that PD-2 VMS field takes
up 2 bytes (2 nibbles for the digits, 1 for the sign, 1 unused),
and PD-3 field also takes up 2 bytes (3 nibbles for digits, 1 for
for the sign). What this means is that PROGRESS does not
distinguish between the two, which is no big deal if you are
reading them, but can cause problems if you are writing to them.
An example: set up a test file with 3 fields, a 2 byte integer
key field, a PD-2 and a PD-3, and I was able, with PROGRESS, to
write three digit numbers to a VMS PD-2 field. This will cause
confusion to say the least in any application of PROGRESS to
existing PD fields. In general, any VMS packed decimal field
with an EVEN number of digits is susceptible to this problem.
Packed decimal fields with an odd number of digits always take
up whole bytes. The length of a PD field in bytes for VMS
packed decimal fields is (number of digits + 2) / 2.
Possible work arounds:
1. don't use even number of digits in VMS PD fields.
2. if you do use even number digits, add some code in the
applications programs, or in the dictionary, to make sure that
the value of the field stays within the proper limits.
Progress Software Technical Support Note # 367