Re: REXX that verify what MINIDISK is a file

[Les Koehler]

Sergio,
As Scott suggests, compiling is the first step to protect yourself from getting 
calls about tools that are not *your* tools.

The second step, assuming you can't get the tool installed in a shared segment 
(or whatever they call it these days), is to check that it is executing from an 
EXECLOAD from the correct disk. If not, then EXECLOAD it with the PUSH option, 
re-invoke it and then EXECDROP it.

Your tracking mechanism should use the same technique.

You might want to consider allowing a specified userid run it from disk for 
testing purposes.

Another advantage to doing this is that you avoid the problem of users running 
back-level code that was copied to some other disk earlier in the search order. 
Back in the days when I worked at IGS in Tampa, this was one of the biggest 
problems we constantly faced. Someone would create a 'collection' of tools from
several disks in order to avoid using up all the mode letters. Then they'd have 
everyone else in their department link&access the 'department' disk. Of course 
they never checked to see if the *original* disk had been updated with a later 
version!

A good tracking facility helps in this area as well. You can just look at the 
tracking data and tell the complainer "You're not running the current version of 
MY tool!"

Just be real careful about what you protect this way. For instance, the Rexx 
compiler execs are 'sample' code and can be greatly enhanced by the user to do 
such things as add an automatic Copyright statement from a lookup file, as well 
as a 'footprint' that identifies the source code disk, date/time of the source, etc.

Les

Scott Rohling wrote:
Yes - exactly what I did to test my code snippet.

You'll never be able to stop people from copying files to their A disk - and
making modifications - including removing any checks you make for an X disk,
etc.   Users can do an EXECDROP or EXECLOAD on their own - there's not many
good ways to stop a determined user from shooting themselves in the foot if
they want to.

Sergio - maybe the best answer to solve the root problem is to compile the
REXX code?    People could still have old copies of CATAA .. but at least if
it's compiled, they can't make changes to the current code.

Scott Rohling

On Thu, Oct 14, 2010 at 3:45 PM, Michael Coffin <michaelcof...@mccci.com>wrote:

 Just checking the filemode of the program will not guarantee that that it
is running from MAINT 31A.    If I:



ACCESS 191 X



Then execute CATAA with Parse Source in it, the Parse Source will show it
is running from the mdisk accessed as X – but it’s my 191, not the MAINT
31A.



Look into CP QUERY MDISK to verify that the disk accessed as X is MAINT
31A.



-Mike



*From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
Behalf Of *Sergio Lima
*Sent:* Thursday, October 14, 2010 5:17 PM

*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: REXX that verify what MINIDISK is a file



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.