QSNADS Problem with Large Files

[Dennis Rose]

Hello,

When trying to QSNADS a file larger than 16MB we are getting
corrupted data. The large files transfer, but when we try to recieve
them into a savefile we are receiving "CPF5175 - Invalid record
received". We are on a 50S with V3R6 sending to another RISC system
with V3R6. Both sides have a 56Kb line to Advantis.

IBM suggested changing the Mode Type to *Blank and the Max Packet Size
to 1496. Neither fix resolved the problem.

Any suggestions??

Thanks!!!!!

Dennis Rose

[Tony Downs]

Dennis Rose <dr...@intecinfosys.com> wrote in article
<32d6f90f....@client.news.psi.net>...

There used to be a 16MB limit on SNADS distributions. We quit using SNADS
for anything significant around 1991 (not because of that), so I haven't
kept up with its particulars. You might want to track down what the actual
size limit is now and get it in writing from IBM. If they support >16MB
transfers and all other messages go without a hitch, this would seem to be
an undocumented feature (read bug) that they should fix.

Tony

[wtho...@madisn.k12.wi.us]

When creating the save file try *NOMAX in the MAXRCDS Parm.

CRTSAVF FILE(XXX) MAXRCDS(*NOMAX)

We have been using SNADS about 5 years now and it works great.
Have no proplems shipping or receiving save files that are 300 MB.

[vil...@cus.cul.ca]

In <32d6f90f....@client.news.psi.net>, dr...@intecinfosys.com (Dennis Rose) writes:
>Hello,
>
>When trying to QSNADS a file larger than 16MB we are getting
>corrupted data. The large files transfer, but when we try to recieve
>them into a savefile we are receiving "CPF5175 - Invalid record
>received". We are on a 50S with V3R6 sending to another RISC system
>with V3R6. Both sides have a 56Kb line to Advantis.
>

Dennis, I started having some intermittant SNADS problems after we switched
to frame relay. I can't remember what the error message was, but it did
happen when we tried to do a receive on the file.

I finally narrowed the problem down to a packet being received out of sequence -
a not unlikely occurance with FR. There is no provision in the SNA stack for
checking and correcting this because it is never supposed to happen i.e. the
lower level stuff is supposed to take care of it, unfortunately this doesn't
always happen when you have FR and all sorts of routers (and who knows what else).

I resolved the problem by changing my pacing value to one on both ends of the
connection. Now a packet isn't sent until the previous one has been receipted for.

Slows things down somewhat, and reduces the line efficiency. On the other hand, it
certainly improves the response for anyone trying to use the connection interactively
while the transfer is taking place..

Let me know how this works out!

Villy G. Madsen ISP
Technical Consultant, Technical Services
Canadian Utilities Ltd
Edmonton, AB
403-420-5093