# Packed Decimal fields issue

**URL:** <https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473>\
**Category:** Forum\
**Tags:** Adabas-Natural, Adabas, Adabas-on-Mainframes, Adabas-Utilities-on-Mainframes, Adabas-on-Windows-UNIX, Adabas-Natural-Cloud\
**Created:** [August 25, 2010, 11:45am UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473 "2010-08-25T11:45:25Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ats](https://avatars.discourse-cdn.com/v4/letter/a/da6949/32.png) [@Ats](https://techcommunity.softwareag.com/u/Ats)\
**Post date:** [August 25, 2010, 11:45am UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/1 "2010-08-25T11:45:25Z")

</div>

While getting data down into a MF dataset using utilities, seems packed decimal fields are not being taken care (or unpacked) by the utilities. What are ways around this?

We need to use ASCII transfer method in FTP and get data back after processing and upload to Adabas again.

---

<div class="post-metadata">

**Author:** ![Ralph\_Zbrog](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/ralph_zbrog/32/78_2.png) [@Ralph\_Zbrog](https://techcommunity.softwareag.com/u/Ralph_Zbrog)\
**Post date:** [August 25, 2010, 1:33pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/2 "2010-08-25T13:33:14Z")

</div>

If you’re transferring data containing binary, integer, floating, or packed values, then you cannot allow the FTP to translate between ASCII and EBCDIC. This translation must be done at the field level.

If you’re moving data from Adabas to Adabas (between mainframe and Open Systems) then decompress the file, transfer with FTP, and compress on the target. For the FTP, specify BINARY or IMAGE to avoid ASCII/EBCDIC translation, and specify SITE RDW to format the data properly. On the Open Systems side, specify two additional utility parameters:

for Compress - RECORD\_STRUCTURE=RDW and SOURCE\_ARCHITECTURE=(EBCDIC,IBM\_370\_FLOATING,HIGH\_ORDER\_BYTE\_FIRST)

for Decompress - RECORD\_STRUCTURE=RDW and TARGET\_ARCHITECTURE=(EBCDIC,IBM\_370\_FLOATING,HIGH\_ORDER\_BYTE\_FIRST)

If you’re trying to move data via WORK files, then I suggest you convert the problematic fields prior to writing the WORK records. Convert integer and packed fields to unpacked numeric, and convert binary and floating-point fields to base64. Then let FTP provide normal ASCII/EBCDIC translation.

---

<div class="post-metadata">

**Author:** ![Ats](https://avatars.discourse-cdn.com/v4/letter/a/da6949/32.png) [@Ats](https://techcommunity.softwareag.com/u/Ats)\
**Post date:** [August 25, 2010, 2:48pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/3 "2010-08-25T14:48:59Z")

</div>

Thanks for the detailed information Ralph!

To be more specific, below is the process:

1. Get data down (with Adabas utilities) to a dataset
2. Transfer data to open system (FTP)
3. Process this data off the Mainframe (i.e. Unix or Windows)
4. Transfer processed data back to Mainframe (FTP)
5. Upload processed data into Adabas

The Adabas files contain binary, floating and packed decimal fields. I know there are plenty of points need to be considered but was curious to know workaround for P type fields. As of now not supposed to use Natural for conversion hence finding other ways.

What could be the best possible solution?

---

<div class="post-metadata">

**Author:** ![Ralph\_Zbrog](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/ralph_zbrog/32/78_2.png) [@Ralph\_Zbrog](https://techcommunity.softwareag.com/u/Ralph_Zbrog)\
**Post date:** [August 25, 2010, 7:17pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/4 "2010-08-25T19:17:40Z")

</div>

In step 3, individual alpha fields must be translated from EBCDIC to ASCII. Depending on the target platform, individual integer fields may need to be converted from big endian to little endian.

---

<div class="post-metadata">

**Author:** ![Ats](https://avatars.discourse-cdn.com/v4/letter/a/da6949/32.png) [@Ats](https://techcommunity.softwareag.com/u/Ats)\
**Post date:** [August 31, 2010, 1:29pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/5 "2010-08-31T13:29:07Z")

</div>

Ralph,

I am doubtful that control parameters RECORD\_STRUCTURE, SOURCE\_ARCHITECTURE are available with ADACMP (decompress) on Mainframe. I found them for OS though.

[url][http://techcommunity.softwareag.com/ecosystem/documentation/adabas/ada622os/utils/cmp.htm#cmprecord[/url]](http://techcommunity.softwareag.com/ecosystem/documentation/adabas/ada622os/utils/cmp.htm#cmprecord%5B/url%5D)

If they are not, what could be the other ways around?

---

<div class="post-metadata">

**Author:** ![Ralph\_Zbrog](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/ralph_zbrog/32/78_2.png) [@Ralph\_Zbrog](https://techcommunity.softwareag.com/u/Ralph_Zbrog)\
**Post date:** [August 31, 2010, 1:52pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/6 "2010-08-31T13:52:10Z")

</div>

I stand corrected. :oops: More than a little embarrassing, since I frequently copy Adabas files from a mainframe to a Windows server.

RECORD\_STRUCTURE and SOURCE\_ARCHITECTURE are specified on Open Systems Compress and Decompress to handle files originating on or destined for a mainframe.

The corresponding mainframe parameter is UARC.

---

<div class="post-metadata">

**Author:** ![Ralph\_Zbrog](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/ralph_zbrog/32/78_2.png) [@Ralph\_Zbrog](https://techcommunity.softwareag.com/u/Ralph_Zbrog)\
**Post date:** [August 31, 2010, 2:38pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/7 "2010-08-31T14:38:15Z")

</div>

I stand corrected. :oops: More than a little embarrassing, since I frequently copy Adabas files from a mainframe to a Windows server.

RECORD\_STRUCTURE and SOURCE\_ARCHITECTURE are specified on Open Systems Compress and Decompress to handle files originating on or destined for a mainframe.

The corresponding mainframe parameter is UARC.

---

<div class="post-metadata">

**Author:** ![Ats](https://avatars.discourse-cdn.com/v4/letter/a/da6949/32.png) [@Ats](https://techcommunity.softwareag.com/u/Ats)\
**Post date:** [August 31, 2010, 4:22pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/8 "2010-08-31T16:22:53Z")

</div>

No worries Ralph!

Thanks for UARC.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\
**Post date:** [October 6, 2010, 6:56am UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/9 "2010-10-06T06:56:34Z")

</div>

I just wish that the MF & OS utilities could understand each others compressed file formats and eliminate the need to FTP/transfer potentially humongous decompressed files between systems.

Cheers,

Graeme

---

<div class="post-metadata">

**Author:** ![Shank\_Browdy](https://avatars.discourse-cdn.com/v4/letter/s/ac8455/32.png) [@Shank\_Browdy](https://techcommunity.softwareag.com/u/Shank_Browdy)\
**Post date:** [August 19, 2011, 6:54pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/10 "2011-08-19T18:54:04Z")

</div>

Is IGYCRCTL supplied [track a cell phone](http://www.mspy.com) with the Operating System? or is sold as separate package?

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\
**Post date:** [April 2, 2021, 2:58pm UTC](https://techcommunity.softwareag.com/t/packed-decimal-fields-issue/94473/11 "2021-04-02T14:58:57Z")

</div>


