SNDNETF and CPF8072

[CENTRINO]

Can I override the 2Gb limit of SNDNETF ?

I am trying to migrate a library from system A to System B via network.
System A is V5R3M0, system B is V5R4M0 so I SAVELIB into a *SAVF and then
use SNDNETF.

But I get CPF8072 stating that there is a 2 GB limit.

Is it a OS limit, or is there any way to override such a limmit ?

[Emile]

Why don't you use FTP between the 2 systems ?

Much easier. I don't know the limit but I transfer many times more than 2GB
between i5's.

See http://faq.midrange.com/data/cache/67.html

[CENTRINO]

Good point ... FTP .... I`ll use it if there is no other chance.

Well, I have witten a program long ago wich until now have never reached
such a limmit.
I do understand that in 1.993 2GB were too much, but nowadays it is not for
SNADS ... !!!

My progam uses SNA, it consists of two parts: a daemon in the destiny system
and a set of commands such as SNDNETOBJ and SNDNETLIB in the origin system
wich until now had worked perfectly well.

I also know that there is the SAVRSTOBJ wich forms part of the 5722SS1
option 22 ObjectConnect free part of the OS.

Any way I appreciate the asyncronous manner in wich SNADS work.

I just want to know if there is a way to overrride such an old limit.

And if not supported via SNA, IBM should write something simmilar in order
to transfer objets between systems via TCP using CL commands and not needing
to use the FTP command shell.

Thanks

"Emile" <e...@e.nl> escribió en el mensaje
news:47d287d1$0$10160$e4fe...@dreader18.news.xs4all.nl...

[xyzzy]

If you have ObjectConnect/400 installed, you could configure a
connection between the two boxes then simply use the SAVRSTLIB command
to save the library from system A and restore it to System B. I'm
sure I've transferred more than 2GB using that method. I cannot lay
my hands on my ObjectConnect notes at the moment, so try a Google
search.

A quick way to check if ObjectConnect is installed is to type
SAVRSTLIB and press F4. If you get the command not found error, then
it's not installed. You'll need to check both systems.

Hope that helps.

[CENTRINO]

Thanks I am trying it right now

"xyzzy" <ukp...@ic24.net> escribió en el mensaje
news:c73c0ea8-50a0-4921...@f47g2000hsd.googlegroups.com...

[CENTRINO]

¡ And it worked !

Thanks

"CENTRINO" <no...@ninelandia.com> escribió en el mensaje
news:fqu3n0$5iu$1...@nsnmpen2-gest.nuria.telefonica-data.net...

[CRPence]

I also had a distaste for using synchronous FTP PUT or GET versus the
[mostly] async nature of SNDNETF of SNA/DS. I very much preferred the
'send & forget' as compared to the interactive FTP command shell where
it was 'send & await'. However like many others, I just wrote my own
version of a tool to effect /batch FTP/ to make the function async.
There are lots of examples about.

I eventually decided FTP was actually a better option, to avoid
[effectively] dual copies at both the source & destination nodes [and as
I understood, also a full copy at each intermediate node]. FTP also
removed the requirement to schedule or react to receipt at the target
side, since I generally know where I want the data to go when it arrives
at its destination, and with FTP the destination of the data has to have
already been decided.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

CENTRINO wrote:
> Good point ... FTP .... I`ll use it if there is no other chance.
>

> <<SNIP>>
> Anyway I appreciate the asynchronous manner in which SNADS work.
> <<SNIP>>

[CRPence]

We used to send entire tapes [CPYFRMTAP] in a similar manner, so we
would easily exceed the limit. In the custom send command there was the
ability to perform a /split file/ operation when the file [the amount of
data on the tape] would exceed a threshold of record count [multiplied
by record length], and then at the destination\receiving system, there
was recognition of the need to repackage or /merge files/ into one file
when a Control-File was received; the receiving end would usually
receive the control file before the pieces, so would wait until all were
received before starting the merge. The split-file feature would do
something like:

<code>
on-error cpyf control file to qsysprt and dmpclp
set &corto to reduced number of rows for each send
allocate & open inp file (as savf, just open as 528 rcdlen)
create a file with member CONTROL in file name to be sent:
CRTPF QTEMP/&savfnm MBR(CONTROL) RCDLEN(528) MAXMBRS(2)
set &counter to 000001
set &mbrnm to SAVF *cat &counter
create a member, allocated for the max data:
CHGPF QTEMP/&savfnm SIZE(&corto 00000 0) ALLOCATE(*YES)
ADDPFM QTEMP/&savfnm MBR(&mbrnm)
open control member for output
nextmbr:
cpyf fromfile(&lib/&savfnm) tofile(QTEMP/&savfnm)
fromrcd(((&counter-1) * &corto) + 1) NBRRCDS(&corto)
tombr(&mbrnm)
/* note: cpyf not valid for savf, use another I/O method */
RTVMBRD QTEMP/&savfnm MBR(&mbrnm) nbrcurrcd(&rcdcnt)
record file.member, sender, & nbrrcds by insert into control
sndnetf QTEMP/&savfnm MBR(&mbrnm) TOUSRID((&U &A))
If (&rcdcnt *lt &corto) then(do) /* done */
sndnetf QTEMP/&savfnm MBR(CONTROL) TOUSRID((&U &A))
goto done /* optional */
enddo
else do
clrpfm qtemp/&savfnm &mbrnm
chgvar &oldmbrnm &mbrnm
increment counter
increment member name; e.g. just *cat &counter
RNMM QTEMP/&savfnm &oldmbrnm NEWMBR(&mbrnm)
enddo
done:
DLTF QTEMP/&savfnm
return
</code>

With an automated receiver, either the recipient name or the naming
of the network files would be used to enable knowing when the delivered
file was part of a group. A recipient needed to avoid receiving a file
as part of normal single-file processing, when instead the file needed
to be merged with others. The recipient could receive each control
member into a unique member, and as long as any member remains in that
file, the recipient knows that all of the files named in the records of
each remaining control member were not all available the last time an
attempt was made to receive [& merge]; the wrknetf output(*outfile)
could be used to compare the list against the rows in the control file.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

CENTRINO wrote:
> <<SNIP>>
> My program uses SNA, it consists of two parts: a daemon in the destiny

> system and a set of commands such as SNDNETOBJ and SNDNETLIB in the

> origin system which until now had worked perfectly well.
>
> <<SNIP>>
>
> And if not supported via SNA, IBM should write something similar in
> order to transfer objects between systems via TCP using CL commands

[CENTRINO]

Thank you very much.

I´ll take a look to your approach.

"CRPence" <crp...@vnet.ibm.com> escribió en el mensaje
news:47d3165a$1@kcnews01...