AS400 Move data file to another AS400 without using save/restore

The FTP Server is responsible for converting it to ASCII so try that first.  If that doesn't work look for an FTP client that does EBCDIC to ASCII translation... maybe you can install such a client on a PC and then use the PC as a go-between ... so download from server 1 to the PC then upload to server 2 from the same PC.   Some FTP clients even have a way to modify the EBCDIC to ASCII translation table if you happen to have a customized character set.

Hi Alex,

I don't think that she wants to do that.  Data files on the AS/400 are binary.  There's a lot more to them than just the legible data (ASCII or EBCDIC).  No FTP client that I know of is smart enough to understand the internal formats and convert that to something meaningful that another AS/400 can decipher.


Kent

Hi  ... thank you both.
No I don't need to go to PC.  
The files are flat files . (Currently)  I will be doing dds defined as well .  I will do again with bin and post the  results.  It didn't work but I could be doing something wrong. I will post my step.  More in a bit.

Thank you.

Both flat and native files are losing their keys..... sample attached.

Thank You!
Copy-Example.pdf

Both flat and native files are losing their keys...

"Flat" and "keys" are mutually exclusive.

How are the two systems connected? If FTP can connect between the two, a network connection should exist. If so, why not create a DDM file on V5R1 back to the V5R4 system, and use CPYF to copy from the DDM file into whatever file you want to hold the data?

It's been a long time since I've done anything with V5R1, so I'm not sure of specific details of DDM over TCP/IP for it; but it should be possible if firewall ports can be opened. Just be sure that DDM passwords are required on the systems and use ADDSVRAUTE to set passwords for SERVER('QDDMSERVER').

Tom

Hi Tom,

One set of file is very old from a 36 system with not DDS.  The other set has been defined with a DDS and has definable fields.

I will have to do some reading on DDM.  I am not familiar with it.  The whole reason we are doing this is to get short term to access to a very specific set of data which is not link or on our main box.  We are bringing a 170 out of the closet and putting the data on it for two months.  It is all about security.... we don't want to have these two boxes connected at all once access is given.

From what you know of DDM does it still sound like it fits the bill for what we are doing?

Thank you so much for you help.

Lynn

Hi Tom,

I was kind of hoping that you'd show up.  :)


Hi Lynn,

Tom's one of our AS/400 gurus.  I'm going to step out of the discussion and leave this to someone a lot better qualified than I am.


Kent

Hi Tom,

Thank you for the instructions.  I will give this a try as soon as possible.  

I'm on a couple days vacation ... taking son back to college.  

I will post an update once I've been able to try it.

Thanks Again!
Lynn

Hi... Thank you Avi.  Sense FTP/DDM are available I will use them, but I appreciate the information.


DDM:

Works great! Thank you.  

However I'm still having one problem.   On old 36 files with packed data I'm getting an error 'retrieved record contains invalid data'.  I am speculating it is he packed fields because other 36 files work which don't have them.

Any suggestions?

More  Question:

Can I create a generic DDM file?  

Examples:
I would like to copy all files in a library.
Is there a better way then creating a DDM for each file in the library?

I would like all objects and source in a library.  
I copies all source by creating individual DDM files... ie   QCLSRC/MyddmLIB  QCLSRC/rmtLIB  then using CPYSRCF.  BUT can I do all source at once (QDDSSRC, QCLSRC, QRPGLESRC, QS36SRC,.....)

Can I copy the source from a library without having to have a DDM file for each program?


Thank You!!

Hi Lynn,

Did you mean to credit Tom?  All I did was step out of the way.....



Kent

Lyne

You have to list the members to outfile with  DSPFD *MBRLST
and in a loop  copy member by  member

Avi

ah, Thank You,

Again.  Thank You Tom for a great solution.  Worked like a charm.
            Thank you Kent and Avi for your input.

Yes, I thought I awarded the solution points to Tom. (sorry)  Is there a way to correct this.  

Also, would it be standard protocol to split the point amongst those that contributed?

Thanks,
Lynn

:)  Thank You.

I'm not aware of a good way to create a "generic" DDM file. It's somewhat contradictory because DDM relies on database file definitions that could (and often would) result in inconsistent file attributes.

And S/36 files commonly have an additional definition layer that is maintained through IDDU (a data dictionary facility that provides S/36 descriptions in the AS/400 environment). This layer isn't meaningful to the various transfer utilities such as DDM or FTP. I've never needed to do the apparent type of transfer you're doing (and more importantly don't have V5R1 available), so bits of guesswork get involved. Maybe as I throw stuff into here, someone more familiar with DDM and S/36 and unsupported target releases will think of something and add a comment.

It seems plausible that IDDU definitions might be needed for the target V5R1 in order for packed areas of S/36 file records to be interpreted properly. I don't know of a good way to automate such a transfer. It might need to be manual entry. Maybe.

Now, a difficulty in coming up with any good solution is that the actual problem scope isn't understood. What exactly are you trying to do? Why would you ever want to transfer S/36 files from V5R4 to a V5R1 system? Why transfer S/36 file data at all? That is, what is the whole point behind all of this?

Also, what is the network environment? Are these systems intended to be in the same network? Or is this some kind of transfer of data to a client or customer? Particularly for 'source' files, the networking can provide additional possibilities, e.g., via /QFileSvr.400 transfers.

Tom

Hi Tom,

Thank you.  These files are being move for a very short period to give limited access to the information.  The machine will not be on the same network.

But, here is some additional information.  Even though I get an error with upddta saying the data is invalid,,,, the 36 program still works.  So, I closed the problem.  These 36 files are going away after this and will not be needed.   (Thank Goodness!!!)

Thanks again for you help.

Lynn

Okay, it makes some sense that a compiled S/36 program worked while UPDDTA wouldn't. The program had things like packed definitions coded into the program, while UPDDTA expected the field definitions to be available from the database.

These 36 files are going away after this and will not be needed.

They were good for their day, but that day is a couple decades past.

Anyway...

Unfortunately, without a reliable local connection, things get more difficult. Going outside could take troublesome configuration, especially with a V5R1 system at the other end. I might consider a system to system VPN for example. But V5R1 is so old, I'm not sure anyone can help with it now.

Otherwise, various firewall elements will frustrate efforts. It possibly can be done, but server to server outside a local network always brings frustration. When one end is a decade out of date, it's worse. We're stuck with expecting a system that has never had serious attention to make it fully compatible with more current methods.

Is there any additional problem that needs to be solved?

I know you asked about entire libraries, but that seems unlikely. The objects from a newer system just can't be accepted by ones that are too much older. Data has possibilities, as DDM can show. But the actual file containers that hold the data are incompatible.

Source file members can be copied into streamfiles with CPYTOSTMF and copied back out with CPYFRMSTMF. FTP should have no problem sending entire directories of streamfiles between systems. Anything more sophisticated hits trouble.

Wish I could do more, but that's about as far as it goes. Hope things work out.

Tom

HI Tom,

Thank you for all your help!  Everything is solved at this point.  (Sorry for the slow reply I've been out sick for a couple days.)

Lynn