Re: console & controller are damaged...any help?

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.