Basic setps -- ADA z/OS to WinXP??

I’m sure this question belongs in this “ADABAS Basics” forum.

I am doing investigation/experimentation, etc from ADABAS 8.1.4 on z/OS to ADABAS 6.1.8 on WinXP. The “Using Utilities” section of ADABAS Open Systems documentation, under “Platform Dependencies”, states:
"If you want to exchange data between high-order-first and low-order-first platforms, you should proceed as follows:
“1. Unload with ADAULD
2. Decompress with ADADCU
3. Compress with ADACMP
4. Load with ADAMUP”

…and that’s the extent of the platform dependencies information. I suspect there is MUCH more. (There are Time & Date fields in this file, but no MU’s or PE’s.)

I am starting simply. My WinXP environment is single-user on a stand-alone workstation – starting with the least complicated files first:

  1. ADACMP DECOMPRESS on z/OS
  2. IND$FILE transfer to WinXP (tried both TEXT and BINARY) – I expect this is part of the problem
  3. ADACMP (command prompt) on WinXP

[b]E:\Software AG\Adabas\V618\BIN>adacmp DBID=8,FILE=22
%ADACMP-I-STARTED, 06-JAN-2011 07:34:21, Version 6.1.8.03 (Windows)
%ADACMP-I-DBON, database 8 accessed online

%ADACMP-W-ERROR, Field = ID, ISN = 1, Offset = 249
%ADACMP-E-UNXEOF, CMPIN - unexpected end of file

Descriptor summary:

Descriptor CC : 0 bytes, 0 occ

%ADACMP-W-CMPREC, Number of compressed records : 0
%ADACMP-I-IOCNT, 2 IOs on dataset CMPDTA
%ADACMP-I-IOCNT, 1 IOs on dataset CMPDVT
%ADACMP-I-IOCNT, 6 IOs on dataset CMPERR
%ADACMP-I-IOCNT, 6 IOs on dataset CMPIN
%ADACMP-I-IOCNT, 1 IOs on dataset ASSO
%ADACMP-I-ABORTED, 06-JAN-2011 07:34:21, elapsed time: 00:00:00[/b]

I have tried several iterations of, trying a binary file, trying including the FDT rather than pointing to the file in ADABAS (the file definition exists in the database). Rather than continue to beat my head against the wall, I thought I would ask advice. In general, how SHOULD this be done?

There is an ADADCU-parameter to do conversions: TARGET_ARCHITECTURE

Did you use it?

I did not use it because there is no ADADCU utility on z/OS – only ADACMP DECOMPRESS, which does not have a TARGET_ARCHITECTURE parm. So the question is, where should I be doing the DECOMPRESS? If I do an UNLOAD of the z/OS ADABAS file, and I want to DECOMPRESS on WinXP, what is the best way to transfer the files to Windows to properly preserve the packed values, but also convert the TEXT to ASCII. Or will ADADCU on WinXP understand the EBCDIC? I know this is very basic stuff, but I am starting at the beginning.

So… Does it make sense to do an ADAULD on z/OS, and then FTP to WinXP (since there are more options for how the data is transferred)…? It seems that the utilities between the 2 platforms should have ways to manage this migration.

Or should the ADABAS data be altered (via a user program) to change the packed fields to NUMERIC…? Or are there other options?

All input and experiences are welcome.

Use ADADCU on the mainframe, then FTP it to Windows (binary). On Windows, use the ADACMP utility with SOURCE-ARCHITECTURE.

http://techcommunity.softwareag.com/ecosystem/documentation/adabas/ada621os/utils/cmp.htm#cmpsource

S,

Mainframe-to-OpenSystems migration has been covered several times, but here’s a summary:

. use Object Handler to unload the mainframe FDT (WITH TRANSFER)
. FTP the FDT
. use Object Handler to load the FDT to the target
. standard mainframe DECOMPRESS (optional ISN parameter to keep source and target in synch)
. FTP with BINARY and SITE RDW parameters
. COMPRESS with
… RECORD_STRUCTURE=RDW
… SOURCE_ARCHITECTURE=(EBCDIC,IBM_370_FLOATING,HIGH_ORDER_BYTE_FIRST)
… FILE=
. load the file

A third-party product reads directly the compressed output of ADASAV from the mainframe and reloads it into the LUW environment.
It would be nice if SAG supports such a utility. It is not magic, the utiltity is called ADAMAGIC.
LUW= Linux, Unix, Windows

The procedure:

  • ADASAV SAVE to create a backup
  • FTP to LUW
  • ADAMAGIC to separate the DVT and DATA
  • ADAMUP to reload

Dieter Storr

There’s even a method that doesn’t involve any utilities, the Adabas SOA Gateway can
do a direct replication between whatever platforms you like, the beauty is that the Gateway
will take care of all transformations, no need to FTP, IND$FILE etc., and no hassle with
records exceeding block size limits on decompression etc.