I guess you could. Why would you want to?

But, for sake of argument, sockets is just how your two programs talk to each other. The real issue is how to read and write the save files.

I've never tried opening a save file as a *STMF. FTP with IFS naming, sure. I just don't know what will happen if you try to write to one that way.

Traditional file I/O with save files is easy. You need to declare a 528-byte program described file, with a single field (the entire record). I've not tried using EXTFILE with a SAVF; I don't see any comments in the RPG Reference or Programmer's Guide about doing this. OVRSAVF is easy and obvious.

You could create the remote save file before trying to write to it, obviously. Which means at the start of your sockets conversation, you have the opportunity to send some control info, like what the target file name should be.

Why would I want to?  Because I am wanting a quick and easy way to move objects between systems.  FTP is not an option because most people here do not have authority to use FTP (as crazy as that might sound) and using SNDNETF also isn't an option since some profiles we are using do not exist on the other system. 

I am in the process of creating a utility that will push or pull data between our systems and I am looking at other ways that this utility could be used.  Allowing objects to be copied between systems is one of the things that I am looking at adding.

I am thinking that this will work, but was curious if anyone else had tried this or could think of an easier way to accomplish what I am trying to accomplish.

Do you have ObjectConnect installed?  It's option 22 of the OS, which I believe is free.  It uses the SAVRSTxxx commands, so you wouldn't have to deal with save files.  Here's a link for more information if you're interested: http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzarm%2Frzarmobjcht.htm

I love ObjectConnect, but the problem is it's an SNA app. Which means you most likely need Enterprise Extender, aka HPRIP, which is the replacement for AnyNet. (AnyNet is still out there, but IBM recommends you use HPRIP instead.)

HPRIP isn't that hard to configure; it's less complicated than AnyNet was.
* You need an APPC *HPRIP controller for each remote node that's directly connected.
* You do not need remote configuration list entries (in fact, if you have them, you need to remove them).
* You no longer need the special host list entries (the .SNA.IBM.COM entries).

HPRIP and AnyNet can coexist, which is convenient if you're trying to migrate away from AnyNet.

The SAVRST* commands are also not an option.  Besides we wont have to deal with save files, but program will handle everything under the covers.  

Fish,

You can open, read and then send the Save File's data over a Socket like any other buffer of data. On the other end, the Socket app will need to be Save File Aware, and write to an existing save file--maybe create it first.

If that isn't an option and you simply want to send the data over there, write to a physical file and then use RPG to "copy it" to a save file, you can do that too, obviously. But RPG reads save files like normal db2 files and the data is just data.

Thanks Bob...that is sort of what I was thinking, but I have never tried it.  I was hoping that you, or someone else, had tried something similar to this before and could tell me if it was possible.  I am going to proceed.  

Have you considered using ssh to connect the two IBM i servers? The documentation generally expects you to be connecting from a PC, but you cant' see why you couldn't connect IBMi to IBMi (assuming you have PASE installed, of course). 

Curious that a firm would allow you to roll your own transfer protocol, but not allow you to use ftp for an internal transfer.

You could use Scott Klement's FTPAPI, that is using sockets and written in RPGLE. His sample programmes are easily adapted for your own uses.

Regards,

Carel Teijgeler

jjclljn,

This project is something I am developing on my own time for the purpose of obtaining more knowledge about sockets and for that I need no "permission" and seek none.  I don't sit around waiting for permission to learn new skills.  However, one reason I am working on this is because I see a need for it where I work and I am trying to develop a practical application that we can utilize here.  Obviously I will need permission to implement this new utility and activate it, but since my director understands what I am developing and wants to be able to use it then am almost 100% sure that I will be allowed to implement it once I have completed the development.  

While I and a few others do have authority to native FTP, most do not.  That doesn't mean that they should not be allowed to move data in a controlled manner.  And the other problem is that sometimes we need this functionality when using a production profile that doesn't exist on our test machine.  A few of us have 2 production profiles, one with limited authority that matches the profile on our test box and another profile with authorities that we need to do our job but without command line access.  This prevents us from using DDM in many cases.

So native FTP and DDM are both out of the question.  I am developing a tool that works without the confinements of our security setup.  

There is also a lot more to this tool than just moving data...it will have a few front-end commands to use it from a command line, but it will also be a serious of ILE functions that we can easily integrate into applications.  It allows us to define related database files in a maintenance program, starting with a primary file and all the secondary (or related) files and how the files are linked/joined.  When we want to push or pull data we will basically pass an SQL statement for the primary file into this tool (along with what I am calling a package name) and it will actually extract the records from the primary file and records from all the related files that we have defined.  This tool is going to be used to extract test data from our test box and pull over to our development box.  It is also going to be used to push a data from one box to the other.  For example, I have built a tool that allows us to customize EDI routines without having to change RPG code all the time.  It stores program-like statements in a series of files.  Right now we have to key everything twice, once on the development box and again in production.  This utility will allow me to add an option that will allow us to "promote" the tablized code (or copy to another box) directly from our maintenance program.

One more thing...even though the program will be running in batch under a profile with more authority than the user making requests, it will still check the user's authority to the object(s) being copied.  For example, if I want to copy a file then this tool will make sure that I have authority to the file(s) I am copying to.  Same thing with other object types...I will not be able to copy a program into a production library because I do not have the necessary authority to that object.  So this tool really will not allow us to circumvent authority.

A couple of points in case anyone else's situation might fit.

For DDM, you don't have to have matching user profiles on the source and target system.  You can "map" a user on the source side to a different user on the target side using the ADDSVRAUTE command. There are a couple of other setup steps (certain system values need to be set a certain way, etc.). The Infocenter has all the details on how to make it work.

If you're on 7.1 and are at a certain DB2 group PTF level, you can use a 3 part file name in the SQL FROM clause.  The parts are server_name.library_name.table_name.  I'm not sure if it was also added to 6.1.  For more info on that, look at the DeveloperWorks website: https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/IBM%20i%20Technology%20Updates

TFisher:

Wasn't trying to imply you were doing something unscrupulous- you want to spend time learning sockets, more power to you.

Just surprising that you'd want spend the time to roll your own protocol to transfer data and trigger remote processes when there are several usually available proven options on the IBMi.  Could certainly build in the protections you mention for a program written using over the ftp api to restrict unauthorized usage. I've done so using the Scott Klement provided ftpapi service program mentioned earlier (as part of a process that transforms and replicates production data from an IBM i to a SQL server data warehouse).

Rest of project (determining how to pack, ship and unpack related data sets spread across multiple tables) certainly sounds challenging. Good luck.

jjcllhn,

Actually, the extraction of the relational database data from multiple files is fairly easy. Being able to package everything up into a save file and then read the subfile, send the data through a socket and write to a save file on the other end is going to make this very easy.

If writing a socket program to transfer data was going to takes weeks instead of hours then I probably wouldn't be willing to spend the time creating my own protocol.  But since socket programming isn't very time consuming then I don't have a problem spending the time doing this to avoid all the problems we have here using either DDM or FTP.  

How will your own socket programme "avoid all the problems we have here using (...) FTP."? FTP is using the TCP protocol and using sockets as well. You have to write a client and a server, a sender and receiver, and both have to be connected to the same (virtual) port. Your programme is going to transfer data, like FTP,  and will encounter the same problems/troubles as FTP.

arsenal,

Yes, I will have a client and a server. 

Not related to Fish's educational experience RE: Sockets, but the COZTOOLS includes several SENDxxx commands. Including:

1. SENDOBJ
2. SENDSAVF
3. SENDLIB
4. SENDPRTF

Under the covers, they create a save file and use FTP to transfer the data to the remote. Some of them, such as the SENDOBJ command, include a "Restore on the other side" option so that when the command finished, the data being sent has been restored to the appropriate library.