I understand this problem now. It happened because I used cut-and-paste to create the IOCDS source file on the SE on the DR machine instead of importing from a USB stick or FTP server. This was unexpected behaviour and not welcome in a disaster recovery environment.
This caused the IOCDS source to be marked as ‘modified’ and the stand-alone IOCDS build program therefore replaced the token field in the source with a new token (message ICP130I - WARNING - DYNAMIC TOKEN ALTERED - but it does not show what alterations were made). The token normally includes the symbolic ‘processor ID’ from the HMC. I had chosen to use ‘DR’ but the IOCP program ignored this and used the ‘CPC name’ instead (LSYSTEM in the IOCP source, based on CPU serial number). I used the name ‘DR’ so that I would not need to change the HWNAME filters if the DR machine was changed. I understand why the IOCDS build program would ignore the time stamp information in modified IOCDS source but I think there should be an option to preserve the processor ID. Keith > On 28 Aug 2024, at 12:24, Keith Gooding > <0000034af3894af4-dmarc-requ...@listserv.ua.edu> wrote: > > I have a IEASYMxx member which is intended to set symbol &LOC to null unless > it is used on a machine with HWNAME ‘DR’ or z/os is running in a particular > z/VM machine. > > SYSDEF SYMDEF(&LOC=‘’’) > SYSDEF HWNAME(DR) SYMDEF(&LOC=‘DR’) > SYSDEF VMUSERID(DREMHZB) SYMDEF(&LOC=‘DR’) > > > On the production machine &LOC is correctly set to DR if running on VM > DREMHZB and null otherwise but on the DR machine the HWNAME(DR) filter is not > working in the way that I expected and &LOC is null. > > The IEASYMxx documentation states for HWNAME “To use this parameter or accept > its default value, ensure that the processor on which z/OS is running > supports dynamic I/O configuration. Also, ensure that the I/O configuration > was built using HCD.’ > > The IOCDS source was of course built using HCD but it was then compiled on > the DR machine using the stand-alone compiler and I think the token may have > been ignored. > > Does anyone have any thoughts on this problem. I can of course work around > the problem but I would like to understand what is going wrong. > > TIA > Keith Gooding > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
