Packed Decimal fields issue

, , , , ,
1

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.

2

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.

3

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?

4

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.

5

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]

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

6

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.

7

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.

8

No worries Ralph!

Thanks for UARC.

9

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

10

Is IGYCRCTL supplied track a cell phone with the Operating System? or is sold as separate package?