Re: Batch ISPF invoking a Rexx

[John P Kalinich]

Richard Fazio of the TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
wrote on 07/30/2008 02:02:47 PM:

> Rexx / ISPF gurus,
>
> I've got one for you. We have a weird mix of Rexx/ISPF and clists for a
> process.
>
> The following is run through a batch invocation of IKJEFT01
>
> //SYSTSIN DD *
> EXECUTIL SEARCHDD(YES)
> PROFILE PREFIX(V0664)
> PDF CMD(REXX1 +
> PARM1(A) +
> PARM2(A) +
> PARM3(A))
> CUTOFFTP())
> /*
> //
>
> If we run the "PDF" with only one REXX1 (above)...all is fine. The ISPF
> environment is created, the job ends successfully.
> -----------------------------------
>
> However, if we run the command as listed below (two PDF commands) there
> is all kind of weirdness (technical term).
>
> //SYSTSIN DD *
> EXECUTIL SEARCHDD(YES)
> PROFILE PREFIX(V0664)
> PDF CMD(REXX1 +
> PARM1(A) +
> PARM2(A) +
> PARM3(A))
> CUTOFFTP())
> PDF CMD(REXX1 +
> PARM1(B) +
> PARM2(B) +
> PARM3(B))
> CUTOFFTP())
> /*
> //
>
> REXX1 with PARM(B) never runs
>
> REXX1 with PARM(A) throws syntax errors almost immediately...and the
> syntax errors correspond to the command input "PDF CMD(REXX1
> PARM1(B...." the actual commands itself. I don't know how to explain
> this any better.
>
> I think the execution of "PDF CMD(REXX1) PARM(B)" is being passed into
> the first execution's stack thus, never running and causing syntax
> errors.
>
> I've never used ISPF in batch to run Rexx before. Is there a way to
> terminate the ISPF environment so that we can run two invocations?
> Obviously, we can create multiple jobsteps, but that's too simple.
>
> It's only Wednesday. Half-assed solutions get put in on Friday. I'd
> prefer to use some best practices here.
>
> I'd be glad to talk through this...email your phone# to
> rfa...@transunion.com and I'll call you back.
>

PDF is an alias for ISPF. I always use ISPSTART in batch. See if that
gives you different results.

Regards,
John K

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Hardee, Charles H]

Check out your set of parens.
I've combined them into one line:

> PDF CMD( REXX1 PARM1(A) PARM2(A) PARM3(A) ) CUTOFFTP() )

> PDF CMD( REXX1 PARM1(B) PARM2(B) PARM3(B) ) CUTOFFTP() )

I think you really want:

> PDF CMD( REXX1 PARM1(A) PARM2(A) PARM3(A) CUTOFFTP() )

> PDF CMD( REXX1 PARM1(B) PARM2(B) PARM3(B) CUTOFFTP() )

Chuck

<snip>

> However, if we run the command as listed below (two PDF commands)
there
> is all kind of weirdness (technical term).
>
> //SYSTSIN DD *
> EXECUTIL SEARCHDD(YES)
> PROFILE PREFIX(V0664)
> PDF CMD(REXX1 +
> PARM1(A) +
> PARM2(A) +
> PARM3(A))
> CUTOFFTP())
> PDF CMD(REXX1 +
> PARM1(B) +
> PARM2(B) +
> PARM3(B))
> CUTOFFTP())
> /*
> //

</snip>

[Mickey Bee]

Being an idiot, I would just code one Rexx, pass all the parms to it, parse them and then have IT call each process with teh correct parms. That way, I could also plop out messages on the status of each Rexx. I have about 20 such driver Rexx programs I run at the site I am currently working at.

Mickey

[Fazio, Richard]

Yea, I'm with you. I told them that I could create one Rexx to rule them all. They're thinging about it.... :)

At this point it's more of a quest as to "why" this is happening.

Very weird, the traces are not giving us any clues. I'm hoping they give me an opportunity to re-write. We'll see.
Faz

[Mickey Bee]

It might have something to do with the PDF itself. If it is a Rexx or Clist, it might be issuing FREE commands against ISPF required datasets.

[Fazio, Richard]

Doh!

Found it. There was a diagnostic present in the rexx "Trace ?r". It's always beed there and nobody thought twice about it.

It was dumping and interpreting (badly) the stack.

I removed the trace and life is good. Odd how a "trace" made it into production ... Hmmmm

Thanks all for the effort.