Thanks Chuck! I had to delete the objects & the system recreated them. I
suspected that would work but since I'm not as versed in the systems
management side I thought I'd ask the experts first. Also thanks to Rob!
I'm just happy to get this up and running.
Thanks,
Tommy Holden
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 05/31/2013 01:32 PM
Subject: Re: console & controller are damaged...any help?
Sent by: midrange-l-bounces@xxxxxxxxxxxx
On 31 May 2013 09:59, Tommy.Holden wrote:
Both objects CTL01 and DSP01 are damaged on one of my LPARs (luckily
it's not our production system!). What can I do to resolve this?
If I delete the controller and DSP01 objects will the system
recreate them or can someone tell me what steps I can take (other
than calling IBM that is...)
As I recall, the typical "damage" to communication configuration
objects is rectified by performing a vary-off\vary-on sequence, whereby
on the latter [VRYCFG STS(*ON)] request, possibly only when the /reset/
option is in effect; i.e. the /damage/ often is neither hard\full nor
partial\soft, but is instead /logical/ for which the correction to the
logical damage is to /recycle/ the communications connectivity. Best to
try that first, and even to first verify if the varied-off objects are
reported by DSPOBJD to be "damaged", than to just delete them after a
varyoff.
If the damage is not just logical damage, then DLTDEVD and DLTCTLD is
required; i.e. deletion of a damaged object is the only valid means to
effect /correction/ for actual damage [although for soft damage, i.e.
damage to the data portion of an object, some data may be recoverable],
followed by a create or restore to finish the recovery. If the DSPCTLD
and\or DSPDEVD are functional, probably all information is available
from which the necessary create commands can be intuited; i.e. obtain
the DSPxxx OUTPUT(*PRINT) prior to DLTxxx. And if those commands work,
then so too might RTVCFGSRC, which is even better to obtain
[additionally; see my later comments]. As long as the automatic
configuration feature is enabled [system value QAUTOCFG=1], every system
I had back in the day would gladly recreate any local configurations;
even if only after first turning off and then turning on the device.
Even if the CTL+DEV do not auto-config... If the controller and
device are local attach, defined by a *LWS controller and *LCLDSP
device, then the CRTCTLLWS and CRTDEVDSP for the console I recall were
fairly simple; as I recall, the model and type being the only difficult
detail. There often is even a QCTL *CTLD and a QCONSOLE *DEVD that will
match the local controller and device [they are used during manual IPL],
from which a /copy/ to the name CTL01 [3=Copy from WRKCTLD QCTL] can be
done for the controller, and a /copy/ to the name DSP01 [3=copy from
WRKDEVD QCONSOLE; be sure to correct\specify the name for the attached
controller] can be done for the device. Then varyon the recovered [by
3=copy] objects. Note: Best not to try to just vary on and use the
effective /backup/ devices named QCTL and QCONSOLE that are intended to
be used for an IPL.
FWiW: The configuration objects can be restored from a past backup
that included either or both of SAVSYS and SAVCFG requests. If the
objects are not merely logically damaged, then RTVCFGSRC will likely
fail. However a prior retrieved source of the controller [network]
and\or the device [taken before the objects were damaged] is another
means that could be used to effect the necessary CRTCTLxxx and
CRTDEVxxx; the create commands for the objects, are the effect of the
/retrieve configuration source/ (RTVCFGSRC) request. If there is not a
retrieved-source of your important configurations, obtaining them and
maintaining them as part of system change management specifically to
avoid having to restore from backup is reasonable, esp. if the SAVSYS
and\or SAVCFG are either seldom done or are not done after [frequent]
changes are implemented against those important configuration objects.
midrange.com
