RCVNETF from remote DSTQ

Hi
Can you use DDM?
Create a ddm file on your local i5,
CRTDDMF FILE(QTEMP/XX) RMTFILE(DSLIB/FX280109.1) RMTLOCNAME(devl400 *IP)  
cpyf  FX280109 qtemp/xx crtfile(*yes)

This will create the file on the remote system.

Dave

Murph,

Hmm.  I'm not an expert on this topic, but I'll tell you what little I do know:

SNADS stores distributions in objects called General File Server Objects (FSOs).  There is probably a way to identify the FSO you want and dump it or access it.  As I understand it, the General FSO used to store SNDNETF distributions is just basically a stream file, but it is stored in the QSYS file system.

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/off4b.htm

It looks like the File Server Object Access IDs (QZDLSTID) API might be a good place to start.  It requires a product ID, so you'd need to determine the product ID associate with file distributions initiated through SNDNETF.  If you can't find documentation on the product ID or guess it, you could always put a few distributions out on the queue and just write a loop and try all of the possible combinations until you got valid results.

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/off4a.htm

Hope that's at least enough to get you started.

- Gary Patterson

I reread the question:

Is the file still on the distribution queue on the source system, or is it in the queue on the target system?

If it is still on the source system and you want to retrieve it from there, I don't know of any way other than possibly using the FSO APIs.  Personally I'd consider  fixing the distribution problem and receiving it on the remote system, if that is an option.  Then you could send a copy back to the source system, if, say it had been deleted there and you were trying to recover some data.

If it is on the target system already, just use the RCVNETF command on the target system.  IF you don't have access to the target system, you won't be able to retrieve it remotely.

- Gary

Hi Dave,

I think I didn't express my self very well, so the whole story:

a lot of programs are placing some files in q number of DSTQ with SNDNETF.
We don't want to use SNADS anymore, because of limited availabillity.
But we are talking about at least 5 or 6 AS/400's that are exchanging files.

SO I have to replace the SNADS process, but the number of machines, the total workload of testing and validation an the number of processes we have to change is to big and it takes to long.

I like to be able to retrieve the file from the DSTQ with ? so that I can send it via e.g. FTP  to an other box,
That box has to pickup the file and place it in the local DSTQ so that the current RCVNETF can be run without any changes.

All other ideas are welcome aswell, but it has to be a replacement of the current SND/RCVNETF other changes in the process is not accaptable (I can also replace the SND/RCVNETF  commands if necessary

Regards,
Murph

Sorry Gary,
Your comment's didn't arrive when I started my response to dave :)

so in this case please replase  -Hi dave-  by  -Hi Gary, Dave- :)

Murph:

> We don't want to use SNADS anymore, because of limited availabillity.

I'm not clear on how "limited availability" fits in. If ftp works, then SNADS should work at the same time -- unless you haven't configured SNA over TCP/IP (AnyNet). Obviously, for ftp, an ftp server needs to be started; and for SNADS, SNADS processes need to be started.

Anyway, I suspect that Gary has you as close as you're going to get, unless you can dig into MI programming; and maybe even then you might be out of luck.

I'm not at clear on the FSO APIs. I have a couple old distribution queues that have net files sitting on them. (Our test systems come and go often.) I ran QZDLSTID for QMSFPRD and retrieved a single AccessID. I then ran QZDRTVID to retrieve info about... well... about whatever an AccessID tells me about. The result indicated a specific single distribution from a system serial number on 29 Oct 2007 at 11:03:52. It was pretty easy to link that to a particular distribution.

However, I couldn't determine how to get any info about a couple other net files that are sitting on two other queues. No product ID other than "QMSFPRD" returned anything. It's _possible_ that some transient "product" was somehow involved at some time. On the system I was testing, it seems unlikely.

In any case, with little else available, Gary seems to have the best chance for you.

Tom

Murph,

I get it.  It seems to me that in the past we set up distribution queues that pointed to the same machine for testing purposes.  I don't remember how exactly that worked, but the idea was to be able to do a SND and RCV on the same machine so we didn't have to set up a test environment on another machine.

Assuming that is possible, change your distribution queues to point to the same machine, then write a little process that monitors those distribution queues, receives the files, and resends them in any fashion you like.

If you can't get the "same system" thing to work, perhaps you could send the distributions to another machine you control (or a partition), that runs a little process that receives the files and then flips them to the appropriate destination based on the receiver id.

Just kicking around some ideas.

- Gary

QMSFPRD is the Mail Services Framework product ID.  Those FSO's are for SNA mail items that had attachments, I believe.

I don't know what the Product ID that is associated with SNDNETF, but I didn't think it was QMSFPRD.  I can't test it right now: Maybe "QSNADS", or perhaps the product id for SNADS from WRKLICPGM?  

Entries in the system directory have a field for Product ID, and I've seen *NONE and *IBM in there.  

Now I'm curious.  If you can find the product ID, this might be a way to get what you need.

- Gary Patterson

I had also thought that SNDNETF might not show QMSFPRD. After reviewing the distribution log, though, I'm not sure at all. I couldn't find any bits of info that distinguished a SNDNETF item from a SNDDST item. Well, the "Correlation" data had identifying stuff, but the logged sequence seemed to run through the same jobs/programs/etc.

Sigh. Almost interesting enough to waste a bunch of time on...

Tom

Agreed.  My bet, for the moment, is on "*IBM" for the product ID.  I'm gonna have to try it tomorrow.

I don't know if the FSO type or product that owns it matters to the delivery framework.  Delivery layer versus application layer.

Just conjecture.  Many, many years ago I worked with these Office APIs a bit, but only for mail-type attachments - never used anything else for a product ID.  I haven't looked at it forever and it may have changed (but doesn't much look like it from the docs).  Anyway, Murph has me curious now.

- Gary

Hi Gary,

About your response ID: 23564440 :
Yes you can setup a DSTQ to your own system, but the problem is then that the file ends up in your own incoming Queue and will be picked up by our local scheduled program that will process it.

Regards,
Murph

Murph,

Perhaps you could set up a segregated queue (I don't know if that is possible), or perhaps add a step (pre-requisite scheduled job, or just a step at the top of the existing schedule job's CL) that filters out the "self-sent" items and handles them before allowing the regular scheduled job to process the remaining incoming items.

Just a thought.

- Gary

Murph:

> Yes you can setup a DSTQ to your own system, but the problem is then that the file ends up in your own incoming Queue and will be picked up by our local scheduled program that will process it.

Even if the out-bound queue is held?

Any chance of describing what the need is? I can imagine sending a net file while communications are down and then deleting the original object before it arrives at the remote location. So, the only copy is sitting on a *DSTQ. How to retrieve it when communications cannot be re-established?

Exactly what do you _need_ to do?

Tom

Tom / Murph

My assumptin is that  the goal is to recycle (or continue to use) existing applications that are coded to deliver files via only via SNADS with a "redirector" of some sort that allows these files to be intercepted off of the SNADS queues and either delivered via alternative file transfer mechanisms (DRDA, ODBC, FTP, MQ, whetever), or delivered to ADDITIONAL destinations via alternative file transfer mechanisms.

In the former case, the SNADS distributions would be programmatically deleted (or the queue cleard eacc day, or something) as the files were redirected.

In the latter case, the files would need to be intercepted before SNADS delivers them and cleans up after itself.

Murph, perhaps you can elaborate?

- Gary Patterson

(Barry! Yo!)

I had a similar thought. Possibly make use of the QIBM_QCA_CHG_COMMAND exit point, if applications make it possible -- replace SNDNETF with something that does an ftp instead, for example.

Tom

I like that solution a lot better than dumping files onto the SNADS queues that you really don't want there.

- Gary

Thanks Barry,
I think this is the fastest solution (not a nice one) but the as/400 here will be faced out here in 6 month anyway :(  so who cares.

Thanks for the points and the grade, Murph!

The solution is admittedly not pretty, but it will help minimize impact on the apps that use SNADS. As for systems being fazed out, I am on a regular contract to support an iSeries that will be replaced by SAP....I am now in year nine of that contract.

Personally, I hate working on teams to faze these boxes out. Kinda depressing.
Take care
Barry

Barry,

Last year I taught an SAP ABAP class for RPG programmers at a small iSeries shop that was implementing SAP on the iSeries.  I knew you could do it, but I'd never seen it "in the wild".  From an ABAP developer's perspective, you'd never know it was running on OS/400, but hey, at least they weren't taking it out.

- Gary Patterson

Almost 25 years ago, I had a short 'facilities management' project to step in while a manager was off on a 2-week honeymoon. The company had been bought and the parent company was 2 years into an 18-month project to replace the System/38 with some DEC system. The existing applications were being converted.

The obstacle they were struggling with at the time was how to implement subfiles on a DEC. (I no longer recall anything about the DEC they were running.)

The estimated time-to-completion at that time was "6 months". Some day I should check back to see if the completion date was reached.

OTOH, some half-dozen years later, I was part of a small team (five people) that replaced a Wang VS with an AS/400. State government department including federal reporting requirements... Took us about a year, but most of the time was spent in meeting a high-level management imperative that demanded that everything that was converted should look/act the same. (Anything new could be fully native.)

One major element of that involved the creation of a "Query by Example" function. That function was contracted out to small consulting firm in New York that had solid Wang VS but only as much AS/400 experience as was available at the time. Pretty cool stuff; haven't seen similar elsewhere.

Amazing the difference in going the two directions.

Tom