Need to stop infinite retry on PCOMM AS/400 for NT V410
Jay Ringhal
We are using this product to access the AS/400, and can find no
parameters to stop the infinite retries that ensue when we do our
backups.
When the AS/400 is placed into restricted state, subsystem QCMN goes
down. The AS/400 uses this subsystem to enable the LU6.2 sessions
needed for PC5250 emulation over twinax. When the subsystem goes down,
all PCs which have not been turned off infinitely retry the AS/400.
The AS/400 logs THOUSANDS of messages each hour, rejecting the
requests from the PCs with messages CPI5206 and CPF1269, with reason
code 401. This is a 'normal' situation from the AS/400 point of view,
but results in our history logs filling up and actually slows down the
backups.
Using the SNA Connection log tool in PCOMM, we get the following
error, several hundred times each hour on each PC:
PCS4137A Error data was received from the Partner LU
We get this error sometimes once every second, sometimes as many as 14
secs. apart. On one PC, the messages were separated by the following
number of seconds: 1,6,8,4,6,8,4,14,3,14,4,14,etc.
There are no configuration parameters that we can find by going into
configuration of PCOMM. We looked into the *.WS files where the
configuration information resides and saw the following [CT] section:
[CT]
LocalLUName=
LocalLUalias=
PartnerLUName=APPN.S10A4532
PartnerLUalias=
ModeName=QPCSUPP
AutoRecovery=Y
trace=Y
PLU_IS_ALIAS=N
TraceBufferSize=0
TraceEntrySize=4096
TraceName=ctsstrace
We think that maybe the AutoRecovery keyword might affect what is
going on here, but do not want to blindly 'tweak' keywords we know
nothing about.
Can someone please help us figure out how to stop this infinite
business, or at least slow it down?
Thanks in advance,
Jay
bung...@NOSPAMhotmail.com (Jay Ringhal)
Remove the NOSPAM from the address to correspond
Charles R. Pence
Jay Ringhal wrote:
>
> We are using this product to access the AS/400, and can find no
> parameters to stop the infinite retries that ensue when we do our
> backups.
With similar conditions and no control of the settings for any
individual's PC, my solution was to vary off the IOP. In my case a
Token Ring line was varied off to stop the condition. HTH. I also
never took the time to figure out what was set on the PCs to effect the
continuous retries... but under Comm, Config, Advanced... there should
be an Auto-Retry which if it is set on can be turned off; my PC never
effected those results and my sessions are set to not retry.
Regards, Chuck
-- Comments provided "as is" with no warranties of any kind whatsoever.
Jay Ringhal
Chuck,
Thanks for answering. I went to Comm, Config, and it only lets me
configure the link (it is type 5250). The only Advanced button shows
me an IDBLK and IDNUM set at 05D 00000, which looks like a mainframe
type parameter.
If you go under SNA Node Configuration (not from inside the emulator),
you can 'configure node...view/add/change...DLU Requester...' you can
specify the following settings:
DLU Requester (blank)
DLUS Name (blank)
Backup DLUS name (blank)
DLUS connect retry timeout (5)
DLUS connect retry limit (3)
This doesn't seem to apply, and there were no other timers anywhere
else. I read through all 3 Bookmanager books that came with the
product and there is no reference as to any timers at all, just one
inactivity timeout timer.
Any more ideas?
Like I said, thanks for answering.
Jay
Richard Daniels
FWIW.. I too have experienced something similar. In my case, even
varying off the line didn't help, it would vary inself back on! (This
was an ethernet IOP with 20 remote sites (perle 494's) coming in thru
Cisco routers). In my case, I elected to physically unplug the 400 from
the net during critical system maintenance.
Here's the thing: except during maintenance, for us, the effect is/was
desirable. How often have you done off-hours maintenance only to find
that remote locations would not come back on the air 'til someone power
cycled the remote wsc's? And, having to reboot a PC to remake a
connection was a real pain in the.
The effect at the PC or remote end is similar to having a line drop.
Now, is or isn't a retry appropriate?
Well for me, the problem did not seem big enough to worry about.
Dick Daniels
WYNTH,Inc
Jay Ringhal
Richard,
In theory, this IS desirable, especially with control units such as
your 494. This way, you don't show up at the AS/400 site on the East
Coast first thing in the A.M. to find that your West Coast users have
been down for 3 hours!
The problem is that potentially hundreds of PCs can be simultaneously
trying to recover without any delay time in between attempts. I
believe that you can set the delay time on the control units to, say,
once a minute.
So it is really a matter of degree, i.e. 60 times/hour vs. 5,000
times/hour. That make all the difference to the AS/400, which is
trying to do a SAVLIB *NONSYS while processing and rejecting each and
every request.
A side issue, and not a minor one, is to try and find a message in
QHST while all this was going on. Another side issue is the SIZE of
the QHST files; that is, the amount of space they take on disk.
That is why I said in the original post that:
"This is a 'normal' situation from the AS/400 point of view, but
results in our history logs filling up and actually slows down the
backups."
Regards,
Jay
Dawn May
This situation has been addressed in V4R1. Beginning in V4R1, the AS/400 will no longer repetitvely log the CPF1269 with reason code 401 when there is no subsystem active to handle the incoming request (e.g., in restricted state). Rather, the first attempt will be logged, but subsequent attempts will not. So, if you have 300 PCs attempting to connect, you will get 300 messages - not one message for each connect attempt.
The system detects the repetitive attempts in LIC as opposed to in QLUS (which is where CPF1269 reason code 401 is sent from) so the resources required by the AS/400 will be less and should also result in an improved backup time when there are many PCs doing their infinite retries when the system is in restricted state.
However, there is a side-affect of this change. If you have a configuration error and there is no active subsystem configured for the device, you will only get one CPF1269 with reason code 401 message. If you want to see if the condition is still occuring, a vary off/on of the device will allow another message to be sent.
This change is documented in the V4R1 Memo to Users.
In article <35523288...@news.newsguy.com>, BUNG...@nospamHOTMAIL.COM (Jay Ringhal) writes:
|>
|> When the AS/400 is placed into restricted state, subsystem QCMN goes
|> down. The AS/400 uses this subsystem to enable the LU6.2 sessions
|> needed for PC5250 emulation over twinax. When the subsystem goes down,
|> all PCs which have not been turned off infinitely retry the AS/400.
|>
|> The AS/400 logs THOUSANDS of messages each hour, rejecting the
|> requests from the PCs with messages CPI5206 and CPF1269, with reason
|> code 401. This is a 'normal' situation from the AS/400 point of view,
|> but results in our history logs filling up and actually slows down the
|> backups.
--
Dawn May dm...@us.ibm.com
IBM Rochester, Minnesota
Jay Ringhal
Dawn,
Thank you for this very helpful information, we are at V2R3 soon to be
going to V4R1, so this is good.
However, I assume that the processing and rejection of each attempt
will still take place. Is this correct?
Even so, I think that system overhead will be significantly reduced
because QHST isn't being logged beyond the first attempt. Do you
agree?
Thanks,
Jay
Jay Ringhal
Dawn,
Never mind the question about overhead. I missed your comments about
the processing now taking place in LIC.
Thanks,
Jay