Re: IEASYM filtering on HWNAME not working
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 > <034af3894af4-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
Re: IEASYM filtering on HWNAME not working
The obvious first thought is "the hardware name is not DR" on the system where the definition is not working. Look at ECVTHDNM and see what it says (among many choices, you could write a tiny program, use REXX, use TSO TEST, use IPCS ACTIVE, use IPCS upon an SVC Dump) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of, e.g., LAE in IBM macros
>How many IBM macros have documentation like "For both primary ASC mode callers >and AR ASC mode callers, >control parameters must be in the primary address space."? Almost all that go so far as to document this (for many others, they should but don't). Of course there are a fair number that allow their data to be ALET-qualified. >Are there any IM macros where requesting use of LAE would be reasonable? With what goal? Saving one instruction (such as doing "LAE" instead of "LR" and "CPYA")? Such a request would not be reasonable. But maybe you have a better goal in mind. For almost all services the rule is that an input AR (or input ALET) is ignored if the caller is not AR mode. There are exceptions. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of, e.g., LAE in IBM macros
I was thinking of macros that allow cross-memory RX parameters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Thursday, August 29, 2024 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Use of, e.g., LAE in IBM macros >How many IBM macros have documentation like "For both primary ASC mode callers >and AR ASC mode callers, >control parameters must be in the primary address space."? Almost all that go so far as to document this (for many others, they should but don't). Of course there are a fair number that allow their data to be ALET-qualified. >Are there any IM macros where requesting use of LAE would be reasonable? With what goal? Saving one instruction (such as doing "LAE" instead of "LR" and "CPYA")? Such a request would not be reasonable. But maybe you have a better goal in mind. For almost all services the rule is that an input AR (or input ALET) is ignored if the caller is not AR mode. There are exceptions. Peter Relson z/OS Core Technology Design -- 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
Re: Help with JDBC message
Java™ Database Connectivity (JDBC) is a Java API for connecting and interactive with relational databases. I guess.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
