Re: [TSO-REXX] problem w/ "allocate" cmnd within a REXX

[Lizette Koehler]

X-POST to IBMMAIN and TSO/REX


Tuco,

You may need to force the volume to NONSMS if the volume TGTVOL (in your case 
DSSUT1) is a non sms managed volume.  Which means you would need to code 
STORCLAS and MGMTCLAS appropriately (not necessarily DATACLAS).

If it is a managed volume in SMS, then you may have another issue, like the 
dataset cannot allocate in that pool.

Check with your storage admin to see what you need to use for this process.

Lizette



>From: "Bonno, Tuco" wrote: 


>
>I am trying to execute an ALLOCATE cmnd from within a rexx,  as follows:
>the REXX:
>pars arg OUTDSN TGTVOL
>   …..
>“ALLOCATE DA(“OUTDSN”) SPACE(…)   CYLINDERS   …. VOLUME(“TGTVOL”) 
>“
>
>my calling stmnt:
>xyzrexx  abc.def.ds   DSSUT1
>
>the dataset gets allocated correctly, but not on pack DSSUT1; it gets 
>allocated on an sms-managed pack
>I have researched this in the 1.9  _tso_command_reference_  manual, which says 
>as follows:
>
>
>“Allocating non-SMS-managed data sets With SMS, you can specify DATACLAS to 
>allocate non-SMS-managed data sets. You cannot, however, use the STORCLAS and 
>MGMTCLAS operands. STORCLAS and MGMTCLAS determine whether a data set is 
>managed by SMS.”
>
>-  but there’s no further info on HOW to use DATACLAS to bypass sms.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS REXX Problem

[Lindy Mayfield]

There is a great exec called XDELETE from Gilbert Saint-Flour on CBT
file 183.  It allows you to delete whole groups of files using filters
(like ABC*.D%.** and so on).

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Howard Rifkind
Sent: 7. elokuuta 2008 0:34
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: zOS REXX Problem

Thanks...worked like a charm...couldn't find the dataset...don't know
why but the second time around everything worked as it should.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS REXX Problem

[Howard Rifkind]

Thanks...worked like a charm...couldn't find the dataset...don't know why but 
the second time around everything worked as it should.


--- On Wed, 8/6/08, Big Iron <[EMAIL PROTECTED]> wrote:

> From: Big Iron <[EMAIL PROTECTED]>
> Subject: Re: zOS REXX Problem
> To: IBM-MAIN@BAMA.UA.EDU
> Date: Wednesday, August 6, 2008, 5:09 PM
> You may wish to display the trapped error messages in case
> they provide
> a clue. REXX code like:
>Do i = 1 to delete.0
>  Say delete.i
>  End i
> or equivalent after the unsuccessful deletes.
> There are a number of possible causes.
> 
> Bill
> 
> On Wed, 6 Aug 2008 14:01:46 -0700, Howard Rifkind
> <[EMAIL PROTECTED]> wrote:
> 
> >I’m trying to delete the following datasets via
> a z/OS REXX exec as shown
> below.
> >
> >The trace is showing an RC=8.  The datasets are
> properly allocated and I
> own them via my HLQ.
> >
> >Any idea what’s going on, why they don’t
> get deleted?  Any help will be
> appreciated.
> >
> >Thanks
> >
> >Display from 3.4:
> >E18823.SYSPROG.VMFTPRX.OPERLOG.INPUT Info - S  
>OPTSO1
> >E18823.SYSPROG.VMFTPRX.OPERLOG.OUTPUT  
>OPTSO1
> >
> >
> >.13 *-* CALL DEL_FILES
> >.66 *-*  DEL_FILES:
> >.67 *-*  LISTIT = OUTTRAP('DELETE.')
> >.68 *-*  SAY '= = = = >>>>'
> LISTIT
> >.= = = = >>>> DELETE.
> >.69 *-*  ADDRESS "TSO" "DELETE
> 'E18823.SYSPROG.VMFTPRX."||FUNCTION||".INPUT'
> >.   >>>"DELETE
> 'E18823.SYSPROG.VMFTPRX.OPERLOG.INPUT'"
> >.   +++ RC(8) +++
> >.70 *-*  ADDRESS "TSO" "DELETE
> 'E18823.SYSPROG.VMFTPRX."||FUNCTION||".OUTPUT
> >.   >>>"DELETE
> 'E18823.SYSPROG.VMFTPRX.OPERLOG.OUTPUT'"
> >.   +++ RC(8) +++
> >.71 *-*  X = OUTTRAP('OFF')
> >.72 *-*  SAY '= = = = >>>>' X
> >.= = = = >>>> OFF
> >.73 *-*  RETURN
> >.14 *-* SAY '= = = = >>>> DEL_FILES
> & DEL_FILES PROCEDURE COMPLETE'
> >.= = = = >>>> DEL_FILES & DEL_FILES
> PROCEDURE COMPLETE
> >.15 *-* EXIT
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access
> instructions,
> send email to [EMAIL PROTECTED] with the message: GET
> IBM-MAIN INFO
> Search the archives at
> http://bama.ua.edu/archives/ibm-main.html


  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS REXX Problem

[Big Iron]

You may wish to display the trapped error messages in case they provide
a clue. REXX code like:
   Do i = 1 to delete.0
 Say delete.i
 End i
or equivalent after the unsuccessful deletes.
There are a number of possible causes.

Bill

On Wed, 6 Aug 2008 14:01:46 -0700, Howard Rifkind <[EMAIL PROTECTED]> wrote:

>I’m trying to delete the following datasets via a z/OS REXX exec as shown
below.
>
>The trace is showing an RC=8.  The datasets are properly allocated and I
own them via my HLQ.
>
>Any idea what’s going on, why they don’t get deleted?  Any help will be
appreciated.
>
>Thanks
>
>Display from 3.4:
>E18823.SYSPROG.VMFTPRX.OPERLOG.INPUT Info - S  OPTSO1
>E18823.SYSPROG.VMFTPRX.OPERLOG.OUTPUT  OPTSO1
>
>
>.13 *-* CALL DEL_FILES
>.66 *-*  DEL_FILES:
>.67 *-*  LISTIT = OUTTRAP('DELETE.')
>.68 *-*  SAY '= = = = ' LISTIT
>.= = = =  DELETE.
>.69 *-*  ADDRESS "TSO" "DELETE
'E18823.SYSPROG.VMFTPRX."||FUNCTION||".INPUT'
>.   >>>"DELETE 'E18823.SYSPROG.VMFTPRX.OPERLOG.INPUT'"
>.   +++ RC(8) +++
>.70 *-*  ADDRESS "TSO" "DELETE
'E18823.SYSPROG.VMFTPRX."||FUNCTION||".OUTPUT
>.   >>>"DELETE 'E18823.SYSPROG.VMFTPRX.OPERLOG.OUTPUT'"
>.   +++ RC(8) +++
>.71 *-*  X = OUTTRAP('OFF')
>.72 *-*  SAY '= = = = ' X
>.= = = =  OFF
>.73 *-*  RETURN
>.14 *-* SAY '= = = =  DEL_FILES & DEL_FILES PROCEDURE COMPLETE'
>.= = = =  DEL_FILES & DEL_FILES PROCEDURE COMPLETE
>.15 *-* EXIT
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

zOS REXX Problem

[Howard Rifkind]

I’m trying to delete the following datasets via a z/OS REXX exec as shown below.

The trace is showing an RC=8.  The datasets are properly allocated and I own 
them via my HLQ.

Any idea what’s going on, why they don’t get deleted?  Any help will be 
appreciated.

Thanks

Display from 3.4:
E18823.SYSPROG.VMFTPRX.OPERLOG.INPUT Info - S  OPTSO1
E18823.SYSPROG.VMFTPRX.OPERLOG.OUTPUT  OPTSO1


.13 *-* CALL DEL_FILES  
.66 *-*  DEL_FILES: 
.67 *-*  LISTIT = OUTTRAP('DELETE.')
.68 *-*  SAY '= = = = ' LISTIT  
.= = = =  DELETE.   
.69 *-*  ADDRESS "TSO" "DELETE 'E18823.SYSPROG.VMFTPRX."||FUNCTION||".INPUT'
.   >>>"DELETE 'E18823.SYSPROG.VMFTPRX.OPERLOG.INPUT'"  
.   +++ RC(8) +++   
.70 *-*  ADDRESS "TSO" "DELETE 'E18823.SYSPROG.VMFTPRX."||FUNCTION||".OUTPUT
.   >>>"DELETE 'E18823.SYSPROG.VMFTPRX.OPERLOG.OUTPUT'" 
.   +++ RC(8) +++   
.71 *-*  X = OUTTRAP('OFF') 
.72 *-*  SAY '= = = = ' X   
.= = = =  OFF   
.73 *-*  RETURN 
.14 *-* SAY '= = = =  DEL_FILES & DEL_FILES PROCEDURE COMPLETE' 
.= = = =  DEL_FILES & DEL_FILES PROCEDURE COMPLETE  
.15 *-* EXIT   



  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SV: SDSF REXX problem

[Thomas Berg]

For those eventually doing the same misstake, 
I was sent a solution/correction by a kind guy:
(It worked!)

Hi Thomas

during the loop, the "NP ?" command overwrites the TOKEN.I variables from the 
ST command.

Add a (PREFIX R) statement to the ISFACT like 

Address SDSF "ISFACT ST TOKEN('"token.i"') PARM(NP ?) (PREFIX R)"

and all the variables from the ? panel will be prefixed by R.

The dsname var is then rdsname means

   Do  j = 1 To rdsname.0
Say rdsname.j 
End 


Good luck

Stefan



-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Thomas Berg
Skickat: den 30 april 2008 14:37
Till: IBM-MAIN@BAMA.UA.EDU
Ämne: SDSF REXX problem

Hi!
I have a problem when running SDSF REXX commands.
When looping the returned isfrows after ISFEXEC ST command, the second ISFACT 
returns "INVALID COMMAND" (and rc = 0).
I can't see why.
 
The REXX:
 
/* REXX */ Trace R 
  x = Isfcalls('ON')   
  isfprefix  = 'S000TBE5'  
  isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,  
'SYSNAME WORKLOAD CPU TRANACT SRVCLS SRVCLASS ACTSYS' ,
'SYSAFF TOKEN PRTDEST' 
  Address SDSF 'ISFEXEC ST (ALTERNATE)'
  isfcols2 = , 
'DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME' 
   
  Do  i = 1 To isfrows 
  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)'   
Trace N
  Say rc   
  Say isfmsg   
   
  Do  j = 1 To isfmsg2.0   
  Say isfmsg2.j
  End  
   
  Do  j = 1 To dsname.0
  Say dsname.j 
  End  
   
Trace R
  End  
   
  x = Isfcalls('OFF')  
  Exit 0   
 
The output:
 
  2 *-* x = Isfcalls('ON')

>>>   "0"

  3 *-* isfprefix  = 'S000TBE5'

>>>   "S000TBE5"

  4 *-* isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' , 'SYSNAME 
WORKLOAD CPU TRANACT SRVC
 LS SRVCLASS ACTSYS' , 'SYSAFF TOKEN PRTDEST'

>>>   "JNAME JOBID OWNERID JCLASS POS STATUS SYSNAME WORKLOAD
CPU TRANACT SRVCLS SRVCLASS ACTSYS SYSAFF TOKEN PRTDEST"  
  7 *-* Address SDSF 'ISFEXEC ST (ALTERNATE)'

>>>   "ISFEXEC ST (ALTERNATE)"

  8 *-* isfcols2 = ,
'DDNAME STEPN PROCS DSID OCLASS RE
 CCNT BYTECNT DSNAME'

>>>   "DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME"

 11 *-* Do  i = 1 To isfrows

>>>   "1"

>>>   "2"

 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)' 
>>>"ISFACT ST
TOKEN('6jkSNicbJpKic/D1m8LEQNp38PrbwuNA6yKmVtAgRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPDUEDj+XPw4rJGQOP4fPDrExO
 CEgEGCBQ=') PARM(NP ?)"

 14 *-*  Trace N

 0

 

 ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
 S000TBE.S000TBE5.JOB01687.D002.JESMSGLG

 S000TBE.S000TBE5.JOB01687.D003.JESJCL

 S000TBE.S000TBE5.JOB01687.D004.JESYSMSG

 S000TBE.S000TBE5.JOB01687.D104.?

 S000TBE.S000TBE5.JOB01687.D108.?

 S000TBE.S000TBE5.JOB01687.D111.?

 27 *-* End

 11 *-* Do  i = 1 To isfrows

 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)' 
>>>"ISFACT ST
TOKEN('6jkSNicbJpKic/D1esLEQNp38PrbwuNA67SCN30gRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPAUEDj+XPw4kpGQOP4c/Dh

Re: SDSF REXX problem

[Gil Peleg]

Thomas,
You're not alone :)

I think your ISFMSG2 stem variable is empty...
Try adding a VERBOSE parameter on your ISFACT call. That should put some
diagnostic messages in ISFMSG2 which may help you debug.

Gil.

On Fri, May 2, 2008 at 9:07 AM, Thomas Berg <[EMAIL PROTECTED]> wrote:

> *Am I the only one that uses the SDSF REXX interface ?
> Or is is time to buf IBM ?
>
> TIA
> Thomas Berg
>
> *
> ==  Thomas Berg  ==  wrote2008-04-30 14:37:
>
> Hi!
> > I have a problem when running SDSF REXX commands.
> > When looping the returned isfrows after ISFEXEC ST command, the second
> > ISFACT returns "INVALID COMMAND" (and rc = 0).
> > I can't see why.
> >  The REXX:
> >  /* REXX */ Trace R  x =
> > Isfcalls('ON')isfprefix  =
> > 'S000TBE5'isfcols = 'JNAME JOBID OWNERID
> > JCLASS POS STATUS' ,  'SYSNAME WORKLOAD CPU TRANACT SRVCLS SRVCLASS
> > ACTSYS' ,
> >'SYSAFF TOKEN PRTDEST'  Address SDSF
> > 'ISFEXEC ST (ALTERNATE)'  isfcols2 = ,
> >  'DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT
> > DSNAME'Do  i = 1
> > To isfrows  Address SDSF "ISFACT ST
> > TOKEN('"token.i"')" ,'PARM(NP ?)'
> > Trace N
> >  Say rcSay isfmsg
> >
> >Do  j = 1 To isfmsg2.0
> >  Say isfmsg2.j  End
> >
> >  Do  j = 1 To dsname.0
> >Say dsname.j  End
> >
> > Trace R
> >  End
> >  x = Isfcalls('OFF')
> >Exit 0
> >  The output:
> >2 *-* x = Isfcalls('ON')
> >
> >>>>   "0"
> >
> >  3 *-* isfprefix  = 'S000TBE5'
> >
> >>>>   "S000TBE5"
> >
> >  4 *-* isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,
> > 'SYSNAME WORKLOAD CPU TRANACT SRVC
> >  LS SRVCLASS ACTSYS' , 'SYSAFF TOKEN PRTDEST'
> >
> >>>>   "JNAME JOBID OWNERID JCLASS POS STATUS SYSNAME WORKLOAD
> > CPU TRANACT SRVCLS SRVCLASS ACTSYS SYSAFF TOKEN PRTDEST"7 *-*
> > Address SDSF 'ISFEXEC ST (ALTERNATE)'
> >
> >>>>   "ISFEXEC ST (ALTERNATE)"
> >
> >  8 *-* isfcols2 = ,
> > 'DDNAME STEPN PROCS DSID OCLASS RE
> >  CCNT BYTECNT DSNAME'
> >
> >>>>   "DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME"
> >
> > 11 *-* Do  i = 1 To isfrows
> >
> >>>>   "1"
> >
> >>>>   "2"
> >
> > 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
> > 'PARM(NP ?)'>>>"ISFACT ST
> > TOKEN('6jkSNicbJpKic/D1m8LEQNp38PrbwuNA6yKmVtAgRrDmEzI1o1LFTisSNjQ6IReE4
> > tDw6OPDUEDj+XPw4rJGQOP4fPDrExO
> >  CEgEGCBQ=') PARM(NP ?)"
> >
> > 14 *-*  Trace N
> >
> >  0
> >
> >
> >  ISF754I Command 'PREFIX S000TBE5' generated from associated variable
> > ISFPREFIX.
> >   S000TBE.S000TBE5.JOB01687.D002.JESMSGLG
> >
> >  S000TBE.S000TBE5.JOB01687.D003.JESJCL
> >
> >  S000TBE.S000TBE5.JOB01687.D004.JESYSMSG
> >
> >  S000TBE.S000TBE5.JOB01687.D104.?
> >
> >  S000TBE.S000TBE5.JOB01687.D108.?
> >
> >  S000TBE.S000TBE5.JOB01687.D111.?
> >
> > 27 *-* End
> >
> > 11 *-* Do  i = 1 To isfrows
> >
> > 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
> > 'PARM(NP ?)'>>>"ISFACT ST
> > TOKEN('6jkSNicbJpKic/D1esLEQNp38PrbwuNA67SCN30gRrDmEzI1o1LFTisSNjQ6IReE4
> > tDw6OPAUEDj+XPw4kpGQOP4c/DhUsT
> >  K4vH1c+PDVMPi8fh849MUliAAAQYbNapb/Q768OPGPQ==') PARM(NP ?)"
> >
> > 14 *-*  Trace N
> >
> >  0
> >
> >  INVALID COMMAND
> >
> >  ISF754I Command 'PREFIX S000TBE5' generated from associated variable
> > ISFPREFIX.
> >   S000TBE.S000TBE5.JOB01687.D002.JESMSGLG
> >
> >  S000TBE.S000TBE5.JOB01687.D003.JESJCL
> >
> >  S000TBE.S000TBE5.JOB01687.D004.JESYSMSG
> >
> >  S000TBE.S000TBE5.JOB01687.D104.?
> >
> >  S000TBE.S000TBE5.JOB01687.D108.?
> >
> >  S000TBE.S000TBE5.JOB01687.D111.?
> >
> > 27 *-* End
> >
> > 11 *-* Do  i = 1 To isfrows
> >
> > 29 *-* x = Isfcalls('OFF')
> >
> >>>>   "0"
> >
> > 30 *-* Exit 0
> >
> >>>>   "0"
> >
> >  ***
> >
> >  TIA
> > Thomas Berg
> >  __
> > Thomas Berg   Specialist   IT-U   SWEDBANK
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> >
> >
> >
>
> --
>
> __

Re: SDSF REXX problem

[Thomas Berg]

*Am I the only one that uses the SDSF REXX interface ?
Or is is time to buf IBM ?

TIA
Thomas Berg

*
==  Thomas Berg  ==  wrote2008-04-30 14:37:

Hi!
I have a problem when running SDSF REXX commands.
When looping the returned isfrows after ISFEXEC ST command, 
the second ISFACT returns "INVALID COMMAND" (and rc = 0).

I can't see why.
 
The REXX:
 
/* REXX */ Trace R 
  x = Isfcalls('ON')   
  isfprefix  = 'S000TBE5'  
  isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,  
'SYSNAME WORKLOAD CPU TRANACT SRVCLS SRVCLASS ACTSYS' ,
'SYSAFF TOKEN PRTDEST' 
  Address SDSF 'ISFEXEC ST (ALTERNATE)'
  isfcols2 = , 
'DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME' 
   
  Do  i = 1 To isfrows 
  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)'   
Trace N
  Say rc   
  Say isfmsg   
   
  Do  j = 1 To isfmsg2.0   
  Say isfmsg2.j
  End  
   
  Do  j = 1 To dsname.0
  Say dsname.j 
  End  
   
Trace R
  End  
   
  x = Isfcalls('OFF')  
  Exit 0   
 
The output:
 
  2 *-* x = Isfcalls('ON')


>>>   "0"

  3 *-* isfprefix  = 'S000TBE5'

>>>   "S000TBE5"

  4 *-* isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,
'SYSNAME WORKLOAD CPU TRANACT SRVC
 LS SRVCLASS ACTSYS' , 'SYSAFF TOKEN PRTDEST'

>>>   "JNAME JOBID OWNERID JCLASS POS STATUS SYSNAME WORKLOAD
CPU TRANACT SRVCLS SRVCLASS ACTSYS SYSAFF TOKEN PRTDEST"  
  7 *-* Address SDSF 'ISFEXEC ST (ALTERNATE)'


>>>   "ISFEXEC ST (ALTERNATE)"

  8 *-* isfcols2 = ,
'DDNAME STEPN PROCS DSID OCLASS RE
 CCNT BYTECNT DSNAME'

>>>   "DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME"

 11 *-* Do  i = 1 To isfrows

>>>   "1"

>>>   "2"

 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)' 
>>>"ISFACT ST

TOKEN('6jkSNicbJpKic/D1m8LEQNp38PrbwuNA6yKmVtAgRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPDUEDj+XPw4rJGQOP4fPDrExO
 CEgEGCBQ=') PARM(NP ?)"

 14 *-*  Trace N

 0

 


 ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
 S000TBE.S000TBE5.JOB01687.D002.JESMSGLG


 S000TBE.S000TBE5.JOB01687.D003.JESJCL

 S000TBE.S000TBE5.JOB01687.D004.JESYSMSG

 S000TBE.S000TBE5.JOB01687.D104.?

 S000TBE.S000TBE5.JOB01687.D108.?

 S000TBE.S000TBE5.JOB01687.D111.?

 27 *-* End

 11 *-* Do  i = 1 To isfrows

 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)' 
>>>"ISFACT ST

TOKEN('6jkSNicbJpKic/D1esLEQNp38PrbwuNA67SCN30gRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPAUEDj+XPw4kpGQOP4c/DhUsT
 K4vH1c+PDVMPi8fh849MUliAAAQYbNapb/Q768OPGPQ==') PARM(NP ?)"

 14 *-*  Trace N

 0

 INVALID COMMAND

 ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
 S000TBE.S000TBE5.JOB01687.D002.JESMSGLG


 S000TBE.S000TBE5.JOB01687.D003.JESJCL

 S000TBE.S000TBE5.JOB01687.D004.JESYSMSG

 S000TBE.S000TBE5.JOB01687.D104.?

 S000TBE.S000TBE5.JOB01687.D108.?

 S000TBE.S000TBE5.JOB01687.D111.?

 27 *-* End

 11 *-* Do  i = 1 To isfrows

 29 *-* x = Isfcalls('OFF')

>>>   "0"

 30 *-* Exit 0

>>>   "0"

 ***

 
TIA

Thomas Berg
 
__

Thomas Berg   Specialist   IT-U   SWEDBANK

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


  


--

__

   Mundus Vult Decipi
__


They that can give up essential liberty to ob

SDSF REXX problem

[Thomas Berg]

Hi!
I have a problem when running SDSF REXX commands.
When looping the returned isfrows after ISFEXEC ST command, 
the second ISFACT returns "INVALID COMMAND" (and rc = 0).
I can't see why.
 
The REXX:
 
/* REXX */ Trace R 
  x = Isfcalls('ON')   
  isfprefix  = 'S000TBE5'  
  isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,  
'SYSNAME WORKLOAD CPU TRANACT SRVCLS SRVCLASS ACTSYS' ,
'SYSAFF TOKEN PRTDEST' 
  Address SDSF 'ISFEXEC ST (ALTERNATE)'
  isfcols2 = , 
'DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME' 
   
  Do  i = 1 To isfrows 
  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)'   
Trace N
  Say rc   
  Say isfmsg   
   
  Do  j = 1 To isfmsg2.0   
  Say isfmsg2.j
  End  
   
  Do  j = 1 To dsname.0
  Say dsname.j 
  End  
   
Trace R
  End  
   
  x = Isfcalls('OFF')  
  Exit 0   
 
The output:
 
  2 *-* x = Isfcalls('ON')

>>>   "0"

  3 *-* isfprefix  = 'S000TBE5'

>>>   "S000TBE5"

  4 *-* isfcols = 'JNAME JOBID OWNERID JCLASS POS STATUS' ,
'SYSNAME WORKLOAD CPU TRANACT SRVC
 LS SRVCLASS ACTSYS' , 'SYSAFF TOKEN PRTDEST'

>>>   "JNAME JOBID OWNERID JCLASS POS STATUS SYSNAME WORKLOAD
CPU TRANACT SRVCLS SRVCLASS ACTSYS SYSAFF TOKEN PRTDEST"  
  7 *-* Address SDSF 'ISFEXEC ST (ALTERNATE)'

>>>   "ISFEXEC ST (ALTERNATE)"

  8 *-* isfcols2 = ,
'DDNAME STEPN PROCS DSID OCLASS RE
 CCNT BYTECNT DSNAME'

>>>   "DDNAME STEPN PROCS DSID OCLASS RECCNT BYTECNT DSNAME"

 11 *-* Do  i = 1 To isfrows

>>>   "1"

>>>   "2"

 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)' 
>>>"ISFACT ST
TOKEN('6jkSNicbJpKic/D1m8LEQNp38PrbwuNA6yKmVtAgRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPDUEDj+XPw4rJGQOP4fPDrExO
 CEgEGCBQ=') PARM(NP ?)"

 14 *-*  Trace N

 0

 

 ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
 S000TBE.S000TBE5.JOB01687.D002.JESMSGLG

 S000TBE.S000TBE5.JOB01687.D003.JESJCL

 S000TBE.S000TBE5.JOB01687.D004.JESYSMSG

 S000TBE.S000TBE5.JOB01687.D104.?

 S000TBE.S000TBE5.JOB01687.D108.?

 S000TBE.S000TBE5.JOB01687.D111.?

 27 *-* End

 11 *-* Do  i = 1 To isfrows

 12 *-*  Address SDSF "ISFACT ST TOKEN('"token.i"')" ,
'PARM(NP ?)' 
>>>"ISFACT ST
TOKEN('6jkSNicbJpKic/D1esLEQNp38PrbwuNA67SCN30gRrDmEzI1o1LFTisSNjQ6IReE4
tDw6OPAUEDj+XPw4kpGQOP4c/DhUsT
 K4vH1c+PDVMPi8fh849MUliAAAQYbNapb/Q768OPGPQ==') PARM(NP ?)"

 14 *-*  Trace N

 0

 INVALID COMMAND

 ISF754I Command 'PREFIX S000TBE5' generated from associated variable
ISFPREFIX.
 S000TBE.S000TBE5.JOB01687.D002.JESMSGLG

 S000TBE.S000TBE5.JOB01687.D003.JESJCL

 S000TBE.S000TBE5.JOB01687.D004.JESYSMSG

 S000TBE.S000TBE5.JOB01687.D104.?

 S000TBE.S000TBE5.JOB01687.D108.?

 S000TBE.S000TBE5.JOB01687.D111.?

 27 *-* End

 11 *-* Do  i = 1 To isfrows

 29 *-* x = Isfcalls('OFF')

>>>   "0"

 30 *-* Exit 0

>>>   "0"

 ***

 
TIA
Thomas Berg
 
__
Thomas Berg   Specialist   IT-U   SWEDBANK

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[David Speake]

I think one could even do FLIP/FLOP.

IIRC

In an ISREDIT macro, it comes in with the default of ISREDIT and ISPEXEC on
the "FLIP" side.

So

"MACRO"
"."
"."
ADDRESS   /* No(env) FLIPs you back to ISPEXEC */
"."
"."
"."
ADDRESS   /* And FLOP into ISREDIT  */
"."
"."
ADDRESS TSO
"."
"."
ADDRESS   /* And FLOP into ISREDIT  */

This could get REAL !UGLY!   :-)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Nix, Robert P.]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rob 
Scott
Sent: Wednesday, January 18, 2006 3:03 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: REXX Problem

A usage note on using "address (env)" on every call is that on return
the address environment is returned to whatever is was before you made
the call - so in essence we have a PUSH/POP environment - how is this a
bad thing?

Possibly due to the overhead of pushing / popping the environment for every 
line executed? 


-- 
Robert P. Nix   Mayo Foundation
RO-OC-1-13  200 First Street SW
507-284-0844Rochester, MN 55905
-
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Mark Zelden]

On Fri, 20 Jan 2006 18:07:07 +, Dave Salt <[EMAIL PROTECTED]> wrote:


>I use a different approach. I put the default address at the top of the
REXX
>exec and I *NEVER* let the default address change throughout the rest of
the
>exec.



> Put me down for prefering school (3).:-)
>

Ditto. Majority rules.  My edit macros all start with Address ISREDIT.
But then I use Address ISPEXEC "cmd" when needed.   Each to his own.
I can read and support any of the schools... it's not that big a deal
and I don't find it difficult to read / understand either way.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Seymour - you wrote this earlier :

> We'll have to agree to disagree; it is both inefficient and confusing.

And then later you wrote this :

> And my position is based on code readability and maintainability, not
efficiency


The "it is both inefficient .." part of that sentence is stated in a way
to convey absolute certainty of something that conflicts with what IBM
have told me in the past. This prompted me to reply to you.

As pointed out by Dave Salt and yourself - there is a third school of
thought on how to use "address" - that is fine. If the code is well
thought out and commented, readability and maintainability is possible
in all three schools.

> No - there is nothing to restore, because it never changes the
environment.


>From SA22-7790 REXX Reference, under the section dealing with the
"ADDRESS" statement :

"After execution of the command, environment is set back to whatever it
was before, thus temporarily changing the destination for a single
command"



  


Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

OK Dave - there are 3 schools - this could get very Monty Python :-) 

Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Dave Salt]

From: Rob Scott <[EMAIL PROTECTED]>
There seems to
be two schools of thought on using REXX address - the first one uses ONE
"ADDRESS ENV" statement followed by a number of quoted buffers that are
directed by REXX to that environment
The other school of thought puts an "ADDRESS ENV" on each statement
You prefer school (1) - I prefer school (2).


I use a different approach. I put the default address at the top of the REXX 
exec and I *NEVER* let the default address change throughout the rest of the 
exec. One glance at the top of the exec and I know exactly what the default 
address is. An example (completely contrived) would look something like 
this:


/* REXX */
address ispexec
"CONTROL ERRORS RETURN"
"ADDPOP"
"DISPLAY PANEL(MYPANEL)"
address tso "ALLOC F(MYFILE)"
address tso "PROFILE PREFIX"
"REMPOP"
address tso "FREE F(MYFILE)"

With this approach, no matter how big the procedure gets there is never any 
confusion as to what the default address is. In addition, I don't need to 
clutter things up by adding 'address ispexec' in front of everything that's 
passed to ISPF. Put me down for prefering school (3).:-)


Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/20/2006
   at 04:48 AM, Rob Scott <[EMAIL PROTECTED]> said:

>Then you have misunderstood the point that I was making.

No I didn't; you simply responcded to something that I hadn't written.
What I actually wrote was

   Note: once you execute "address ISREDIT", there is no need to
   put "ISREDIT" in front of every command.

>There seems to be two schools of thought on using REXX address - the 
>first one uses ONE "ADDRESS ENV" statement followed by a number of 
>quoted buffers that are directed by REXX to that environment :

No. The first one uses on address statement followed by a number of
expressions that are directed by REXX to that environment.

>The other school of thought puts an "ADDRESS ENV" on each statement 

The third one does both. That's what was in the code under discussion.

>Note that there is no initial "Address ISPEXEC" statement in the
>second example

Note that there *is* an initial  *ADDRESS ISREDIT* in the code under
discussion, from Message-ID:
<[EMAIL PROTECTED]>.

>You prefer school (1) - I prefer school (2).

And my position is based on code readability and maintainability, not
efficiency.

>Using "address env buffer" on each statement restores the
>environment after execution to the original setting

No - there is nothing to restore, because it never changes the
environment. Would you claim that there is a PUSH/POP USING in the
anaologous code

 STH   R0,DCBLRECL-IHADCB(R9)

just because the DCBLRECL reference isn't resolved via the current
USING?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Seymour,

>"Not that I recall; I criticized doing *both* and address env *and*
doing address  env buffer as inefficient".

Then you have misunderstood the point that I was making. There seems to
be two schools of thought on using REXX address - the first one uses ONE
"ADDRESS ENV" statement followed by a number of quoted buffers that are
directed by REXX to that environment :

/* REXX */ 
Address ISPEXEC
 "VGET (MYVAR) PROFILE"
Address TSO
 "ALLOC F(INPUT) DA(MY.INPUT) SHR"
..more code
Address ISPEXEC
 "CONTROL ERRORS RETURN"
 "DISPLAY PANEL(MYPAN00)"
..more code
Address TSO
 ""LU "userid
..more code
Address ISPEXEC
 "SETMSG MSG(ISRZ0001)"


The other school of thought puts an "ADDRESS ENV" on each statement  

/* REXX */
Address ISPEXEC "VGET (MYVAR) PROFILE"
Address TSO "ALLOC F(INPUT) DA(MY.INPUT) SHR"
..more code
Address ISPEXEC "CONTROL ERRORS RETURN"
Address ISPEXEC "DISPLAY PANEL(MYPAN00)"
Address TSO "LU "userid
..more code
Address ISPEXEC "SETMSG MSG(ISRZ0001)"


Note that there is no initial "Address ISPEXEC" statement in the second
example - maybe you thought I was advocating it? 


You prefer school (1) - I prefer school (2).


> "But the reference to PUSH/POP would still have been incorrect."

Using "address env buffer" on each statement restores the environment
after execution to the original setting - as far as I am concerned, this
means that the current environment is PUSHed (or saved or whatever REXX
does internally) before the buffer is passed to the directed environment
and then POPed back to the original setting before returning to the REXX
exec - the fact that it might not change does not negate the methodology
used by the REXX address statement.


Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/19/2006
   at 02:58 AM, Rob Scott <[EMAIL PROTECTED]> said:

>Earlier in this thread you criticized the practice of using "address
>env buffer" each time as being inefficient.

Not that I recall; I criticized doing *both* and address env *and*
doing address  env buffer as inefficient.

>I think you are nitpicking here

One man's nit is another man's ABEND.

>perhaps I should have used "address
>statement execution" instead of "call"

But the reference to PUSH/POP would still have been incorrect.

>The PUSH/POP method is used to maintain the address environment
>between executions of the "address env buffer" statement.

What PUSH/POP method and why do you need to "maintain" an environment
that doesn't change?

>I can appreciate that some coding techniques appeal to some whilst
>not to others - if this is just such a case then so be it and we can
>each agree to stick with our own gods.

As long as I don't inherit it,  I don't mind how cluttered your code
gets.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Joel Wolpert]

Joel Wolpert
Director - Performance and Capacity Planning
Shared Data Center
Securities Industry Automation Corporation
2 Metrotech Center
New York, NY 11201
(212) 383-3323
[EMAIL PROTECTED]


- Original Message -
From: IBM Mainframe Discussion List [EMAIL PROTECTED]
Sent: 01/18/2006 06:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: REXX Problem

In <[EMAIL PROTECTED]>, on 01/18/2006
   at 11:54 AM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said:

>Just out of curiosity, is there a performance impact either way?

There is a minor performance cost to putting the unnecessary ADDRESS
ISREDIT statement in front of the ADDRESS ISREDIT cmd statements.
There is some debate as to whether there is a performance difference
between

ADDRESS ISREDIT cmd

and

cmd

I regard the impact on readability and maintainability as more
important than the performance impact.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

-
This message and its attachments may contain  privileged and
confidential information.  If you are not the intended recipient(s),
you are prohibited from printing, forwarding, saving or copying this
email.  If you have received this e-mail in error, please immediately
notify the sender and delete this e-mail and its attachments from your
computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Hunkeler Peter (KRDO 4)]

>>Note the double ampersand which I understand are also required.
>I believe that is wrong; one or the other, but not both. Also,
>shouldn't the last command be
> ADDRESS ISREDIT "SCAN = (oldscan)"

I may well be wrong with the exact syntax. I became curious and
was quickly STFM (S=searching) and left the exact syntax as an 
exercise for the interested reader :-) (In fact, I just didn't 
have the time to try myself before posting, which I usually do).


Peter Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Seymour,

Earlier in this thread you criticized the practice of using "address env
buffer" each time as being inefficient. I have been told by IBM in the
past that it makes no difference either way and Mark Z has stated that
in the tests he performed it actually performed better.  

Normally IBM are pretty good at putting warnings of inefficient or
poorly performing services in the documentation.

> What call? I don't see calls, only ISPF and EDIT commands.
I think you are nitpicking here - perhaps I should have used "address
statement execution" instead of "call" - and if this confused you I
apologize (if I intended to refer to the "CALL" command I would have
used capitals).  

> Not in the code under discussion we don't.
The PUSH/POP method is used to maintain the address environment between
executions of the "address env buffer" statement.

The original code was a simple REXX EDIT macro - throughout this thread
I have been referring to more complex REXX code where the original
"address ENV" statement might be 100's of lines before the next one.  


I can appreciate that some coding techniques appeal to some whilst not
to others - if this is just such a case then so be it and we can each
agree to stick with our own gods.


Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Ted MacNEIL]

>I regard the impact on readability and maintainability as more
important than the performance impact


DITTO!


-teD
Me? A skeptic? I trust you have proof!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 01/18/2006
   at 11:54 AM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said:

>Just out of curiosity, is there a performance impact either way?

There is a minor performance cost to putting the unnecessary ADDRESS
ISREDIT statement in front of the ADDRESS ISREDIT cmd statements.
There is some debate as to whether there is a performance difference
between

ADDRESS ISREDIT cmd

and

cmd

I regard the impact on readability and maintainability as more
important than the performance impact.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/18/2006
   at 04:02 PM, Rob Scott <[EMAIL PROTECTED]> said:

>Please can you point me to some documentation that says that this is
>inefficient?

That's not the sort of question that belongs in the documentation, but
it should be clear to you that an extraneous statement adds to the
processing time. That's true whether or not

   ADDRESS ISREDIT x
   x

take the same time or different amounts of time.

>How is it confusing to have a way of knowing exactly where you
>command buffer is going? 

It isn't confusing to know; it's confusing to be given the same
information repeatedly, especially if you don't know that it will
always be the same.

>A usage note on using "address (env)" on every call is that on
>return the address environment is returned to whatever is was before
>you made the call

What call? I don't see calls, only ISPF and EDIT commands.

>so in essence we have a PUSH/POP environment

Not in the code under discussion we don't.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Mark Zelden]

On Wed, 18 Jan 2006 15:16:52 -0500, Rob Scott
<[EMAIL PROTECTED]> wrote:

>Ed Jaffe wrote :
>> Just out of curiosity, is there a performance impact either way?
>
>I was told that there was no difference when I attended my "REXX for
>Dummies" course way back when we still used 3420s..
>
>Rob Scott
>Rocket Software
>http://www.rs.com/portfolio/mxi/

Religious for the most part.   This has been discussed to death
on TSO-REXX and perhaps ISPF-L also.  A couple of years ago I
think I ran some tests and was surprised to find that when using
ADDRESS environment "command" prior to each command was slightly
quicker than "address environment" , command, command, "address
environment" command , command, etc.   Search the archives of
TSO-REXX or google for "ISPEXEC vs ISREDIT" and ZELDEN.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

TSO PREFIX, JCL MSGCLASS and ASM equated symbols+lengths

All of the items you allude to here are constants 99.9% of the time (OK
you can change your prefix in TSO/REXX - but it is not often done)  

The address environment can be changed by logic paths in executable code
at run-time.


I think this is getting to be a religious war - let's leave it alone.

Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Paul Gilmartin]

In a recent note, Rob Scott said:

> Date: Wed, 18 Jan 2006 16:02:36 -0500
> 
> Please can you point me to some documentation that says that this is
> inefficient?
> 
> How is it confusing to have a way of knowing exactly where you command
> buffer is going?
> 
A few questions, by analogy:

In your TSO commands, do you ever rely on the user prefix,
or do you always fully qualify every data set name?  (If I
knew your were a UNIX user, I'd ask whether you ever rely
on the current working directory, or always fully qualify
every path name?)

In your assembly code, do you ever refer to equated symbols,
or do you you always user self defining terms so you have a
way of knowing exactly what value is being used?

In your JCL, do you ever code SYSOUT=*, or do you always
code SYSOUT= so you have a way of knowing exactly
what class is being used.

Etc.

Often relying on a globally specified value increases
clarity by reducing clutter.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Seymour wrote :
> it is both inefficient and confusing.

Please can you point me to some documentation that says that this is
inefficient? 

How is it confusing to have a way of knowing exactly where you command
buffer is going? 

A usage note on using "address (env)" on every call is that on return
the address environment is returned to whatever is was before you made
the call - so in essence we have a PUSH/POP environment - how is this a
bad thing?

 




Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Ted MacNEIL]

>I don't see how cluttering yp the code makes it easier on the eye, and
the practice actually makes the code harder to maintain.

I agree.
Especially if you are indenting and have to start continuing TSO/ISPF/ISREDIT 
commands.
I find these difficult to read.

I have a couple of EDIT macros that have multiple lines in a block of code.

I WILL not code an address "ISREDIT" in front of each line.

I may/will code one just before the group, and, if necessary to switch 
environments for one command, will code the ocasional adress "OTHER" for that 
line.


-teD
Me? A skeptic? I trust you have proof!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 01/18/2006
   at 08:47 AM, "Hunkeler Peter (KRDO 4)"
<[EMAIL PROTECTED]> said:

>I seems to me you want to replace the &-strings in the JCL, so the &
>shall not denote a variable dereference. 

>No being a fluent edit macro writer I suggest you try to set the scan
>mode off before the change:

>ADDRESS ISREDIT "(oldscan) = SCAN"
>ADDRESS ISREDIT "SCAN = OFF"
>ADDRESS ISREDIT "CHG '&&HILVL..ZZ.ZZ.&&P.&&STK0..PARMLIB' '%'
>   ALL" 
>ADDRESS ISREDIT "SCAN = &oldscan"

>Note the double ampersand which I understand are also required.

I believe that is wrong; one or the other, but not both. Also,
shouldn't the last command be

ADDRESS ISREDIT "SCAN = (oldscan)"

or

ADDRESS ISREDIT "SCAN =" oldscan

?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/18/2006
   at 04:03 AM, Rob Scott <[EMAIL PROTECTED]> said:

>and yes it adds an extra few characters to
>each line - but so do comments 

Extraneous comments are also bad. The rule of comments is to make the
program easier to understand and to modify, not just to take up space.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 01/17/2006
   at 09:54 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>Subroutine linkage "within a procedure"?  I'm confused.

In REXX there is a disconnect between internal routines and external
routines, even though the invocation syntax is the same. Even though
much of REXX syntax is derived from PL/I, the semantics are
drastically different, and this is one example.

Now, were IBM to support Object Oriented REXX on z/OS, some of the
differences would be ameliorated.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/17/2006
   at 05:27 PM, Rob Scott <[EMAIL PROTECTED]> said:

>Maybe not - but I think it is good practice

We'll have to agree to disagree; it is both inefficient and confusing.

>Maybe not - but I think it is good practice - it protects you from
>problems if you happen to ADDRESS another environment when you next
>change the REXX exec.

It exposes you to the risk of finger checks on text that need not be
there at all. IMHO that is a more likely problem than the other.

>but in larger REXX execs you can easily shoot
>yourself in the foot. 

Indeed, and adding extraneous commands is one more exposure to
shooting yourself in the foot.

>I also think that it makes the code easier on the eye and easier to
>maintain.

I don't see how cluttering yp the code makes it easier on the eye, and
the practice actually makes the code harder to maintain.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Ed Jaffe wrote :
> Just out of curiosity, is there a performance impact either way?

I was told that there was no difference when I attended my "REXX for
Dummies" course way back when we still used 3420s.. 

Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Edward E. Jaffe]

Rob Scott wrote:

Putting the "address (env)" in front of each call will prevent
situations such as these - and yes it adds an extra few characters to
each line - but so do comments
  


Just out of curiosity, is there a performance impact either way?

--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Stephen M. Wiegand]

At 03:58 PM 01/17/2006, you wrote:

In <[EMAIL PROTECTED]>, on 01/16/2006
   at 05:20 PM, "Stephen M. Wiegand" <[EMAIL PROTECTED]> said:

>OK I admit I'm old and my brain sometimes goes out to lunch.  Today
>is one of those times.  I have this error in a REXX macro that I use
>in TSO that I just can't figure out how to correct.

Where are HILVL, P and STK0 defined? If they are ISPF variable then
that code should work. Or did you mean for the & to simply be an & in
the search string? In the latter case you need to escape the &.


They are not variables.  They are part of a JCL statement in a PDS 
member that uses symbolized statements.  For example, the PDS has a 
large number of JCL statements and one of those that occurs 
frequently in the one I'm working on and in many other PDS's, has the 
following:


//SYSIN   DD   DSN=&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB(MEMBR1),DISP=SHR



>I've looked through the REXX documentation

Why? It looks like an ISPF issue. REXX doesn't use an & as a
substitution character. What are you trying to substitute, REXX
variables or ISPF variables?


I suppose it is an ISPF issue.  At first I thought it was a syntax 
problem with my REXX.  As you can see from above, I'm not trying to 
replace REXX variables.  I suppose our use of symbolized JCL makes it 
more convoluted.




Note: once you execute "address ISREDIT", there is no need to put
"ISREDIT" in front of every command.



Didn't know that.  Thanks for the tip.


--
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Steve Wiegand

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

In the heady days of pre-Y2K, I spent a few years as a freelance
sysprog.

At one site - this involved going through hundreds of in-house assembler
programs - finding the source, bringing them under Endevor control and
making sure that they were ready for Y2K.

I think it was during this time that I lost a lot of hair - I think I
have seen it all :

(1) Asm programs with 1000+ lines without a single comment or reg equate
(2) Non-trivial programs using R15 as base
(3) Comments that are deliberately wrong
(4) Bible verses in the comments (no - really!)
(5) Really bad swearing in comments and "interestingly" named variables

I could go on but my therapist says it is best not to...

I had many "firing-squad and wall" fantasies during this period.

So the old 'real programmers don't do comemnts' joke makes my left eye
twitch somewhat as I look around for the nearest clock tower. 
 

Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Ted MacNEIL]

>Putting the "address (env)" in front of each call will prevent
situations such as these - and yes it adds an extra few characters to
each line - but so do comments

Well, we'll agree to disagree.

As for comments:
Real programmers don't do comments.
If it was hard to write, it should be hard to read!


-teD
Me? A skeptic? I trust you have proof!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Gil,

The trouble with omitting the "address" statement is that you are
ASSUMING that no statement in the previous logic has changed the
environment during execution (not compilation). 

If the REXX exec is of a reasonable size and more than one person could
be changing the code - this is a BIG assumption.

Add to the fact that Murphy states that the section of code that is
eventually going to blow up in your (or worse your customer's) face is
rarely executed during testing on your system - but is executed straight
away at a customer site.

Putting the "address (env)" in front of each call will prevent
situations such as these - and yes it adds an extra few characters to
each line - but so do comments

Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Hunkeler Peter (KRDO 4)]

I seems to me you want to replace the &-strings in the JCL, so
the & shall not denote a variable dereference. 

No being a fluent edit macro writer I suggest you try to set the
scan mode off before the change:

ADDRESS ISREDIT "(oldscan) = SCAN"
ADDRESS ISREDIT "SCAN = OFF"
ADDRESS ISREDIT "CHG '&&HILVL..ZZ.ZZ.&&P.&&STK0..PARMLIB' '%' ALL"
ADDRESS ISREDIT "SCAN = &oldscan"

Note the double ampersand which I understand are also required.


Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Paul Gilmartin]

On Tue, 17 Jan 2006 17:59:17 -0800, Edward E. Jaffe <[EMAIL PROTECTED]> wrote:
>
> Did I hear (read) my name??
>
IIRC, it was you who, a while back, advocated balancing SYSCALLS( ON )
with SYSCALLS( OFF ).  Here, SAVE/RESTORE might be useful because
there is no way of querying the state of SYSCALLS on entry.  But
Bill Schoen notes there are some harmful effects of SYSCALLS( OFF )
and recommends avoiding it entirely.

> There is a fundamental difference between ADDRESS in REXX and USING in
> assembler. USING in HLASM is positional and applies at compile time
> only. If you CALL a subroutine and return, your USINGs in effect at the

And if the subroutine saves/restores the base register, everything
works.

> CALL point haven't changed. OTOH, ADDRESS in REXX is executable. It's
> changed at run time via the instruction path. Seems like it ought to be
> stackable. PUSH ADDRESS / CALL / POP ADDRESS. (Of course, in REXX PUSH
> and POP are already taken. Maybe something like SAVE/RESTORE ala ISPF.
> But you get the idea.) Or maybe subroutine linkage should
> _automatically_ save/restore it. It happens already when invoking
> another REXX procedure. Why not within a procedure?
>
Subroutine linkage "within a procedure"?  I'm confused.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Edward E. Jaffe]

Paul Gilmartin wrote:

In a recent note, Rob Scott said:

  

Date: Tue, 17 Jan 2006 17:27:42 -0500

"Note: once you execute "address ISREDIT", there is no need to put
"ISREDIT" in front of every command."

Maybe not - but I think it is good practice - it protects you from
problems if you happen to ADDRESS another environment when you next
change the REXX exec. Admittedly this might not be a big issue with
simple edit macros - but in larger REXX execs you can easily shoot
yourself in the foot.

I also think that it makes the code easier on the eye and easier to
maintain.



You could make the same argument for putting a USING or a CSECT
in front of every other assembly language statement.

And it wouldn't be true there, either.

(Although HLASM reports effective USINGs at the top of each page.)

And, following up on teD's reasoning, if I have a large
chunk of statements in another environment, I'll habitually
make a PROCEDURE out of it.  Since the previous addressing
environment is restored on return, everything desired
happens automatically.

No, I don't put a restoring ADDRESS ... either before the
RETURN or after the CALL (although Ed Jaffe might like it
that way.)
  


Did I hear (read) my name??

There is a fundamental difference between ADDRESS in REXX and USING in 
assembler. USING in HLASM is positional and applies at compile time 
only. If you CALL a subroutine and return, your USINGs in effect at the 
CALL point haven't changed. OTOH, ADDRESS in REXX is executable. It's 
changed at run time via the instruction path. Seems like it ought to be 
stackable. PUSH ADDRESS / CALL / POP ADDRESS. (Of course, in REXX PUSH 
and POP are already taken. Maybe something like SAVE/RESTORE ala ISPF. 
But you get the idea.) Or maybe subroutine linkage should 
_automatically_ save/restore it. It happens already when invoking 
another REXX procedure. Why not within a procedure?


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Paul Gilmartin]

In a recent note, Rob Scott said:

> Date: Tue, 17 Jan 2006 17:27:42 -0500
> 
> "Note: once you execute "address ISREDIT", there is no need to put
> "ISREDIT" in front of every command."
> 
> Maybe not - but I think it is good practice - it protects you from
> problems if you happen to ADDRESS another environment when you next
> change the REXX exec. Admittedly this might not be a big issue with
> simple edit macros - but in larger REXX execs you can easily shoot
> yourself in the foot.
> 
> I also think that it makes the code easier on the eye and easier to
> maintain.
> 
You could make the same argument for putting a USING or a CSECT
in front of every other assembly language statement.

And it wouldn't be true there, either.

(Although HLASM reports effective USINGs at the top of each page.)

And, following up on teD's reasoning, if I have a large
chunk of statements in another environment, I'll habitually
make a PROCEDURE out of it.  Since the previous addressing
environment is restored on return, everything desired
happens automatically.

No, I don't put a restoring ADDRESS ... either before the
RETURN or after the CALL (although Ed Jaffe might like it
that way.)

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Charles Mills]

Certainly it only makes sense to code one or the other. Doing both is belt
and suspenders, which is perhaps a good thing with pants, but just adds
maintenance-obscuring noise to source code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Rob Scott
Sent: Tuesday, January 17, 2006 2:28 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: REXX Problem


Seymour,

"Note: once you execute "address ISREDIT", there is no need to put
"ISREDIT" in front of every command."

Maybe not - but I think it is good practice - it protects you from
problems if you happen to ADDRESS another environment when you next
change the REXX exec. Admittedly this might not be a big issue with
simple edit macros - but in larger REXX execs you can easily shoot
yourself in the foot. 

I also think that it makes the code easier on the eye and easier to
maintain.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Ted MacNEIL]

>but I think it is good practice - it protects you from
problems if you happen to ADDRESS another environment when you next
change the REXX exec. Admittedly this might not be a big issue with
simple edit macros - but in larger REXX execs you can easily shoot
yourself in the foot.

I disagree.
I usually set up a 'default' addressing environment at the front of my EXEC's, 
and then handle exceptions, unless I have large chunks of statements in another 
environment.
Also, if you are a fan of indentation and white-space, you can end up with a 
lot of continued statements if you insist on putting address statements in 
front of each command.


-teD
Me? A skeptic? I trust you have proof!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Seymour,

"Note: once you execute "address ISREDIT", there is no need to put
"ISREDIT" in front of every command."

Maybe not - but I think it is good practice - it protects you from
problems if you happen to ADDRESS another environment when you next
change the REXX exec. Admittedly this might not be a big issue with
simple edit macros - but in larger REXX execs you can easily shoot
yourself in the foot. 

I also think that it makes the code easier on the eye and easier to
maintain.  

Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 01/16/2006
   at 05:20 PM, "Stephen M. Wiegand" <[EMAIL PROTECTED]> said:

>OK I admit I'm old and my brain sometimes goes out to lunch.  Today 
>is one of those times.  I have this error in a REXX macro that I use 
>in TSO that I just can't figure out how to correct.

Where are HILVL, P and STK0 defined? If they are ISPF variable then
that code should work. Or did you mean for the & to simply be an & in
the search string? In the latter case you need to escape the &.

>I've looked through the REXX documentation

Why? It looks like an ISPF issue. REXX doesn't use an & as a
substitution character. What are you trying to substitute, REXX
variables or ISPF variables?

Note: once you execute "address ISREDIT", there is no need to put
"ISREDIT" in front of every command.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/16/2006
   at 12:00 AM, Ted MacNEIL <[EMAIL PROTECTED]> said:

>REXX does not do variable substitution with '&'.

But ISPF does.

>"CHG" "'"HILVL".""ZZ.ZZ."P||STKO"."PARMLIB'" ...etc

That will only work if those are REXX variables. Otherwise he needs a
VGET to do it.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Stephen M. Wiegand]

At 05:44 PM 01/16/2006, Rob Scott wrote:

Steve,


First of all, I advise that you standardize on the way that you use your
quotes. I always use double quotes for the buffer that I am passing to
my ADDRESS environment (if possible) and I always include them rather
than relying on REXX to init a variable to its name. This leaves single
quotes for ISPF to use to enclose things such as ampersands.

In your case I would change the following lines :

Address ISREDIT "LOCATE 1"
Address ISREDIT "CHG '&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB' '%'
ALL"



I'll give this a try and see what happens.  I've used the CHG 
construct in many other REXX macros I have without quotes but this is 
my first attempt at doing something with an & in the string.



What happens with "trace(i)" specified in the REXX ?



I've not run trace(i) but I have run trace results and it shows an 
RC=4 after the CHG statement.




Any chance of posting the text from the file that includes the string
that should be found?


It is a JCL job.  The string I'm trying to change occurs in numerous 
members I have which is why I did the REXX. I know the string is 
accurate because I cut and paste it from a member to the macro.


Thanks for the suggestions.



Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Stephen M. Wiegand
Sent: 16 January 2006 17:20
To: IBM-MAIN@BAMA.UA.EDU
Subject: REXX Problem

OK I admit I'm old and my brain sometimes goes out to lunch.  Today
is one of those times.  I have this error in a REXX macro that I use
in TSO that I just can't figure out how to correct.

The particular instructions are:

/* REXX
ADDRESS ISREDIT
"MACRO (XX)"

IF XX = "T" THEN
DO
   ISREDIT LOCATE 1
   ISREDIT CHG "&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB" "%" ALL
   IF RC > 0 THEN
   SAY "STRING NOT FOUND"
   EXIT
END

I am always getting the string not found message.  The return code is
a 4.  I added that as a trap because I couldn't figure out why
nothing was getting changed in the member I was editing and issuing this
macro.

I've looked through the REXX documentation on the IBM site but
nothing is jumping out at me.  Any help/suggestions would be
appreciated.

Steve Wiegand


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Stephen M. Wiegand]

At 11:22 PM 01/16/2006, Dave Salt wrote:

From: "Stephen M. Wiegand" <[EMAIL PROTECTED]>
I am always getting the string not found message.  The return code is a 4.
Any help/suggestions would be appreciated.



Hi Steve,

Others have mentioned the use of ampersands versus leaving variables 
outside the quotes, so I'll try a different suggestion. The odds of 
the following resolving your problem are low, but even so I believe 
it is generally good practise to include the following at the top of 
every edit macro:


"(LBND,RBND) = BOUNDS"
"BOUNDS"

What the above does is save the current boundary settings (i.e. left 
and right) and then set the boundaries to their defaults (e.g. 
columns 1 and 80). Then, after all processing in the body of the 
macro is complete, the boundaries should be returned to their 
original settings by doing the following:


"BOUNDS = "lbnd rbnd

Many commands (e.g. FIND, CHANGE, SORT, etc) are affected by 
boundary settings. By employing the above, you will ensure that your 
macro will work in every situation (where the string to change 
exists), even if the boundaries are not in their expected locations 
when the macro starts.


HTH,

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm


Thanks for that tip.  Boundaries are not a problem here but you are 
correct that to ensure compatibility across members, it would be a 
good thing to include those settings.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Steve Wiegand

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Dave Salt]

From: "Stephen M. Wiegand" <[EMAIL PROTECTED]>
I am always getting the string not found message.  The return code is a 4.  
Any help/suggestions would be appreciated.



Hi Steve,

Others have mentioned the use of ampersands versus leaving variables outside 
the quotes, so I'll try a different suggestion. The odds of the following 
resolving your problem are low, but even so I believe it is generally good 
practise to include the following at the top of every edit macro:


"(LBND,RBND) = BOUNDS"
"BOUNDS"

What the above does is save the current boundary settings (i.e. left and 
right) and then set the boundaries to their defaults (e.g. columns 1 and 
80). Then, after all processing in the body of the macro is complete, the 
boundaries should be returned to their original settings by doing the 
following:


"BOUNDS = "lbnd rbnd

Many commands (e.g. FIND, CHANGE, SORT, etc) are affected by boundary 
settings. By employing the above, you will ensure that your macro will work 
in every situation (where the string to change exists), even if the 
boundaries are not in their expected locations when the macro starts.


HTH,

Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Brian Peterson]

<[EMAIL PROTECTED]> wrote:

>REXX does not do variable substitution with '&'.

But ISPF's ISPEXEC service does - even in a REXX.

>From topic 1.3.2.3 "Using Command Invocation Variables" in manual "ISPF
Services Guide":

"You can use a CLIST or REXX variable, in the form of a name preceded by an
ampersand (&), as the service name or as a parameter anywhere within a
statement. Each variable is replaced by its current value before execution
of the ISPEXEC command. Refer to TSO/E Version 2 CLISTs, TSO/E REXX/MVS
User's Guide, and TSO/E REXX/MVS Reference for further information."

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Ted MacNEIL]

REXX does not do variable substitution with '&'.
   
ISREDIT CHG "&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB" "%" ALL
is a CLIST construct, try (or something like):
"CHG" "'"HILVL".""ZZ.ZZ."P||STKO"."PARMLIB'" ...etc

-Original Message-
From: "Stephen M. Wiegand" <[EMAIL PROTECTED]>
Date: Mon, 16 Jan 2006 17:20:23 
To:IBM-MAIN@BAMA.UA.EDU
Subject: REXX Problem

OK I admit I'm old and my brain sometimes goes out to lunch.  Today 
is one of those times.  I have this error in a REXX macro that I use 
in TSO that I just can't figure out how to correct.

The particular instructions are:

/* REXX
ADDRESS ISREDIT
"MACRO (XX)"

IF XX = "T" THEN
DO
   ISREDIT LOCATE 1
   ISREDIT CHG "&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB" "%" ALL
   IF RC > 0 THEN
   SAY "STRING NOT FOUND"
   EXIT
END

I am always getting the string not found message.  The return code is 
a 4.  I added that as a trap because I couldn't figure out why 
nothing was getting changed in the member I was editing and issuing this macro.

I've looked through the REXX documentation on the IBM site but 
nothing is jumping out at me.  Any help/suggestions would be appreciated.

Steve Wiegand

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

-teD
Me? A skeptic? I trust you have proof!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Problem

[Rob Scott]

Steve,


First of all, I advise that you standardize on the way that you use your
quotes. I always use double quotes for the buffer that I am passing to
my ADDRESS environment (if possible) and I always include them rather
than relying on REXX to init a variable to its name. This leaves single
quotes for ISPF to use to enclose things such as ampersands.

In your case I would change the following lines :

Address ISREDIT "LOCATE 1"
Address ISREDIT "CHG '&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB' '%'
ALL"



What happens with "trace(i)" specified in the REXX ?
 


Any chance of posting the text from the file that includes the string
that should be found? 


Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Stephen M. Wiegand
Sent: 16 January 2006 17:20
To: IBM-MAIN@BAMA.UA.EDU
Subject: REXX Problem

OK I admit I'm old and my brain sometimes goes out to lunch.  Today 
is one of those times.  I have this error in a REXX macro that I use 
in TSO that I just can't figure out how to correct.

The particular instructions are:

/* REXX
ADDRESS ISREDIT
"MACRO (XX)"

IF XX = "T" THEN
DO
   ISREDIT LOCATE 1
   ISREDIT CHG "&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB" "%" ALL
   IF RC > 0 THEN
   SAY "STRING NOT FOUND"
   EXIT
END

I am always getting the string not found message.  The return code is 
a 4.  I added that as a trap because I couldn't figure out why 
nothing was getting changed in the member I was editing and issuing this
macro.

I've looked through the REXX documentation on the IBM site but 
nothing is jumping out at me.  Any help/suggestions would be
appreciated.

Steve Wiegand

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

REXX Problem

[Stephen M. Wiegand]

OK I admit I'm old and my brain sometimes goes out to lunch.  Today 
is one of those times.  I have this error in a REXX macro that I use 
in TSO that I just can't figure out how to correct.


The particular instructions are:

/* REXX
ADDRESS ISREDIT
"MACRO (XX)"

IF XX = "T" THEN
DO
  ISREDIT LOCATE 1
  ISREDIT CHG "&HILVL..ZZ.ZZ.&P.&STK0..PARMLIB" "%" ALL
  IF RC > 0 THEN
  SAY "STRING NOT FOUND"
  EXIT
END

I am always getting the string not found message.  The return code is 
a 4.  I added that as a trap because I couldn't figure out why 
nothing was getting changed in the member I was editing and issuing this macro.


I've looked through the REXX documentation on the IBM site but 
nothing is jumping out at me.  Any help/suggestions would be appreciated.


Steve Wiegand

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html