The ADT is kept in memory. Does this rexx actually read the disk or do you have to issue an ACC to refresh the ADT?
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Tuesday, March 09, 2010 9:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Checking if a CMS disk has changed Thanks. Mike Horlick Conseiller CGI Gestion Intégrée des Technologies 1350 Boul. René-Lévesque Ouest Montréal, Qc, H3G 1T4 ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: March 9, 2010 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Checking if a CMS disk has changed I've got a QDSK EXEC that displays the last R/W use of a minidisk, it does so by reading block 3 of the minidisk to find the DOP (Disk Origin Pointer) and then the timestamp of the CMS directory file. This gives the last R/W access. Here the code: 'PIPE MDISKBLK READ' fm 3'!VAR REC3' /*Read Mdsk blk 3*/ if rc<>0 then return Dop=C2D(substr(Rec3,160-143,4)) /* Get Block1 of Directory file, so we can get last R/W usage */ 'PIPE MDISKBLK READ' fm dop '!Var DopRec' 'PIPE VAR DOPREC!CHOP 64!FMTFST ISO!cons' 2010/3/9 Horlick, Michael <michael.horl...@cgi.com> Greetings, I would like to know if there is a CMS command/program out there that can quickly determine if a CMS disk has been changed? The reason: We run the ASG ZEKE product that runs in our z/VSE machines that communicate via a SMSG to a CMS machine that actually sends the JCL to the reader of the requestor. The JCL could be on several CMS disks so I have added CMS ACCESSes each time a SMSG comes in. Here is the console from a ZEKE CMS machine: DMSCYW2245I *SMSG MUHC24 00236 EPIBCATZ BKUP EPIBCATZ 03 0 NONE NONE * Z TIME IS 07:04:15 EST MONDAY 2010-03-08 CONNECT= 99:59:59 VIRTCPU= 000:14.36 TOTCPU= 000:21.53 DMSACC724I 193 replaces B (193) DMSACP723I B (193) R/O DMSACC724I 194 replaces C (194) DMSACP723I C (194) R/O DMSACC724I 195 replaces E (195) DMSACP723I E (195) R/O DMSACC724I 196 replaces F (196) DMSACP723I F (196) R/O JOB INFO FROM MUHC24 WAS EVENT 00236 FNAME EPIBCATZ FTYPE BKUP -------- -------- ----- JOB EPIBCATZ PRI 03 SYSID CLASS 0 -------- -------- ----- USERINFO NONE NONE SUBMIT Z TARGET MUHC24 PUN FILE 7783 SENT TO MUHC24 RDR AS 9406 RECS 0012 CPY 001 Q NOHOLD NOKEEP ZEK11E000I PROCESSING COMPLETE. OUTPUT RECORDS=12 Those ACCESSes , probably 98% of the time, don't have to be done (since the JCL doesn't change that often) but we issue them just in case a disk or disks change. We have a problem when ZEKE requests from VSE machines start coming in quickly and the CMS machine(s) just can't keep up with them. ZEKE complains with a message on the z/VSE console: Z2 0074 Z0641E Event 000078 ver 00000 dispatch attempted-CMS machine not receiving I know I can go SFS for those disks but we don't have it set up and to do it for this problem I'm not too keen on it (probably because I'm old and lazy and the need to educate the schedulers is too much trouble). So, I'm looking for a (super)quick resident CMS module that given a virtual disk address can tell if that CMS disk needs to be re-accessed. Has it been written already and, if not, which manual(s) would have the info for me to write it? Thank you, Mike Horlick Conseiller CGI Gestion Intégrée des Technologies 1350 Boul. René-Lévesque Ouest Montréal, Qc, H3G 1T4 -- Kris Buelens, IBM Belgium, VM customer support ========================== This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
