QSNADS PROBLEM ON V3R2M0
Michael Frilot
We have over 800 systems in our network and the majority of them are
still at v3r2m0.
On any given week I will have a handfull(5-10) systems fail to receive
data ( splfs ) via SNADS.
What we do is end and restart the QSNADS subsystem on the v3r2 system
that is supposed to be receiving the spool files. As soon as this is
done, the location begins to put the spool files on the output queues.
Does anyone have an idea what is failing on these v3r2 systems and if
there is a PTF that resolves this problem.
Thanks
Michael Frilot
Charles R. Pence
By "fail to receive" do you mean to the users/outq or to the system?
DSPDSTLOG to determine if they made it to the system, but not the user.
I don't recall if the router is the same... but typically either the
ENDMSF/STRMSF or restarting only the QNFTP job is all that is required;
in either case restarting only when one is not active InMyExperience.
Are these SNA remote spooling OUTQs from other systems, or SNDNETSPLF
requests? Been awhile since I've used the former, so I'd have to
refresh my memory -- and if so, are they target to User or OUTQ?
Have you reviewed for any messages in QSYSOPR or joblogs of failed/ended
jobs in the QSNADS subsystem for conditions indicating reason for a
failure? Are the communcation ctl/dev functional in each case when the
non-receipt case is noticed? Is the ASP storage threshold being crossed
during these failed times? Are the spools still in the distribution
queues on the target system, and are the queues defined for retries; are
they in retry condition when non-receipt is noticed?
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.
Chris Bipes - cableone
may be held or in error recovery. Try issuing the command SNDDSTQ xxxxxx.
This will release and retry recovery if the queue is not in ready status.
It will also cause the distribution queue to activate if it has fewer
entries than the send depth is set at. You will also receive all that have
been received from the remote systems and are stuck in the communication
buffers. You may not be reading these buffers until you do a send. Check
out your distribution queue configurations.
--
Christopher K. Bipes Mailto:chr...@cross-check.com
Senior Programmer/Analyst Http://www.cross-check.com
CrossCheck, Inc. 707 586-0551 x 1102
6119 State Farm Drive 707 586-1884 FAX
Rohnert Park, CA 94928
"Michael Frilot" <mk...@virginia.edu> wrote in message
news:39a5c538.212587522@news...
These are simple SCS spool files sent from one system to a user
profile on a v3r2 system (storespl) using sndnetsplf. There is a
program that monitors an outq and sends to the destination base on the
splf user data field.
They have cleared the distribution queue on the originating system.
I have not seen any error messages in qsysopr and there is no data
refering to the files in the distribution log... until the qsnads
subsystem has been restarted. Then we see all the normal logging in
the distribution log..
When we do a wrksplf on the storespl usrprf the spool files are not
there... they should go to this users default output
queue(targetoutq). They get there right after the subsystem has been
restarted.
Endmsf and strmsf has no effect.
I have not tried starting QNFTP. Is this a prestart or autostart job?
I have not found any failed joblogs, but I think these systems clean
them up very aggressively. (before I find out that the problem exists)
Communications are up when the problem is reported and we passthru to
the location on the same ctl/dev to restart the subsystem.
All distribution queues are in the correct waiting state.
It seems like the data is at the system, but the job that brings them
into observability is not running. I have tried to find logs but
they are gone by the time the problems is reported.
System storage does not seem to be an issue, but I will check further
and see if it has peeked and been logged.
These systems get IPL's once a week.
Thanks
Michael Frilot
Michael Frilot
Charles R. Pence
> These are simple SCS spool files sent from one system to a user
> profile on a v3r2 system (storespl) using sndnetsplf. There is a
> program that monitors an outq and sends to the destination base on the
> splf user data field.
>
> I have not tried starting QNFTP. Is this a prestart or autostart job?
>
> I have not found any failed joblogs, but I think these systems clean
> them up very aggressively. (before I find out that the problem exists)
>
> Communications are up when the problem is reported and we passthru to
> the location on the same ctl/dev to restart the subsystem.
>
> All distribution queues are in the correct waiting state.
>
> It seems like the data is at the system, but the job that brings them
> into observability is not running. I have tried to find logs but
> they are gone by the time the problems is reported.
>
> System storage does not seem to be an issue, but I will check further
> and see if it has peeked and been logged.
>
> These systems get IPL's once a week.
The DSPDSTLOG should show a receipt entry for the file when it was
received to the system, then a routed entry for the routing to the
user. This condition sounds exactly like a failed QNFTP <the router;
as I've inferred -- review its active joblog>. When you do WRKACTJOB
for SBS(QSNADS) and QNFTP job is not there, then you will have these
exact symptoms. IIRC this may also have been the same symptoms when
MSF was not functioning... but all of SNA/DS seemed to be; I don't
recall much more detail on those cases however.
Try reviewing for spooled files using WRKSPLF (QSNADS *N *N QNFTP)
Probably you will fing some abnormal error condition noted which
terminated the job. I don't know if there is a 'retry' or similar
feature for that job... Hmmmm... Well anyway regarding that job, a
CPI1125 in a QPJOBLOG gives sufficient added info to re-start that
job for QSNADS by SBMJOB JOB(QSNADS) JOBQ(QGPL/QSNADS) USER(QSNADS)
FWiW my system which is a gateway SNA/DS system is also at V3R2M0;
I've not seen similar problems for a couple years.