Hello Mike, Thanks very much from your good explanation. We need that the user execute our EXEC from a public dasd (Maint 31a), because, We try track who executed this, the date, the time, and another thinks, like Filename, Filetype, Filemode. This EXEC do a Compilation of programs here, and now, the people here, want have a little control about what was compiled, and others thinks. Thanks again, and Best Regards, Sergio
Date: Thu, 14 Oct 2010 15:03:36 -0500 From: mike.wal...@hewitt.com Subject: Re: REXX that verify what MINIDISK is a file To: IBMVM@LISTSERV.UARK.EDU It is pretty unusual to force an EXEC to execute from a specific disk. About 98% of the time I do that is when running a common 'PROFCMS EXEC' in everybody's "PROFILE EXEC" - the "PROFCMS EXEC" complains when it is not executing from the Y-disk (or the our HAINST alternative to IBM's CMSINST NSS). Also, a common "PROFILE XEDIT" complains of the same results (after it does some preliminary setup, it attempts to execute the user's "userid XEDIT" macro). But if you really need to execute an exec from a specific disk, from my 20 July 2009 post here: Check out Kent Fiala's "DIREXEC" on the IBM VM Download page: http://www.vm.ibm.com/download/packages/descript.cgi?DIREXEC That DIREXEC VMARC package should do exactly what you wish, and explains that the included FMEXEC is syntactically easier to use for minidisk files. But before you do that, please help us understand why you would want to do so. There may be much better solutions yo meet your need. Mike Walter Aon Hewitt The opinions expressed herein are mine alone, not my employer's. "Sergio Lima" <sergiovm...@hotmail.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 10/14/2010 02:19 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject REXX that verify what MINIDISK is a file Hello List, We are changing a REXX here for that this EXEC execute only if reside on X acessed minidisk. So, try with STATE command without succesfull and now try with LISTFILE command. If execute like this : 9 *-* 'LISTFILE cataa exec x (DATE STACK LIFO' >>> "LISTFILE cataa exec x (DATE STACK LIFO" 10 *-* if rc = 0 >>> "1" *-* then *-* do 11 *-* pull x1 x2 x3 . >>> "CATAA" >>> "EXEC" >>> "X2" >.> "V 83 506 4 10/14/10 15:03:32" 12 *-* say x1 >>> "CATAA" CATAA 13 *-* say x2 >>> "EXEC" EXEC 14 *-* say x3 >>> "X2" X2 15 *-* exit But, when try execute with filemode *, lookslike the program go to a LOOPING : 9 *-* 'LISTFILE cataa exec * (DATE STACK LIFO' >>> "LISTFILE cataa exec * (DATE STACK LIFO" 10 *-* if rc = 0 >>> "1" *-* then *-* do 11 *-* pull x1 x2 x3 . >>> "CATAA" >>> "EXEC" >>> "X2" >.> "V 83 506 4 10/14/10 15:03:32" 12 *-* say x1 >>> "CATAA" CATAA 13 *-* say x2 >>> "EXEC" EXEC 14 *-* say x3 >>> "X2" X2 15 *-* exit 9 *-* 'LISTFILE cataa exec * (DATE STACK LIFO' >>> "LISTFILE cataa exec * (DATE STACK LIFO" 10 *-* if rc = 0 >>> "1" *-* then *-* do 11 *-* pull x1 x2 x3 . >>> "CATAA" >>> "EXEC" The command in the line show this : listfile cataa exec * CATAA EXEC A2 CATAA EXEC X2 Ready; T=0.01/0.01 16:17:00 Someone can help, how can verify if this EXEC is not running from X disk ? Thanks very much, Sergio Lima Costa Sao Paulo - Brazil The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
