Sure. But I am not advocating running ISPF in batch other than as an
'adhoc' and occasional measure, just to save time. It is a lot quicker
than typing. (My next 'fastest' solution would be to use SELCOPY.) If
it's the CPU clock that matters - and it usually is - the code should be
written in assembler.
Gibney, Dave wrote:
Take a look at ISMF's Naviquest. ISPF can work in batch. It uses a lot of cpu,
but it does work.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of CM Poncelet
Sent: Monday, August 20, 2012 10:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Panel and LPAR name
Batch Clist/REXX does not use panels. They are intended for
*interactive* TSO/ISPF dialogs. Anyone who writes Clist/REXX that
invokes panels in batch doesn't have a clue about what he/she/it is
doing.
BTW Beware of embedded LIBDEFs in Clist/REXX. Code PASSLIB on ISPSTART
to avoid deallocating all datasets (not just the LIBDEF'd ones) from a
DDNAME on the final LIBDEF.
Also, DDNAME=ISPPROF can be allocated as a temporary empty PDS in batch
(e.g. for VPUT/VGETs to PROFILE, although ditto to SHARED will work
too). But I would recommend that you then code NEWAPPL(<whatever, e.g.
ASMX>) on ISPSTART ... just in case ISPF allocates its own profiles in
your ISPPROF and your Clist/REXX then has to share its profile data
with ISPF by default. I never bothered to check what actually happens:
but ISPF does not recognize ISPPROF members ASMXPROF/EDIT/EDRT and will
therefore not try to update them.
E.g. "ISPSTART CMD(%TEST <... any parms>) NEWAPPL(ABCD) PASSLIB".
Invoking programs (as opposed to commands) from batch Clist/REXX can be
done via e.g. "ISPSTART PGM(IEBCOPY) NEWAPPL(<whatever>) PASSLIB" - but
it would be more efficient to invoke the programs directly.
CP
Paul Gilmartin wrote:
On Mon, 20 Aug 2012 02:01:57 +0100, CM Poncelet wrote:
Gosh.
The ISPPLIB DD must be allocated in the JCL.
No; a dynamic allocation before ISPSTART will work just as well.
There are contrary valid points of view here:
o Not to require the programmer to provide resources he doesn't
intend to use.
o To require the programmer to supply in advance all resources
he might potentially use, in order to preclude a failure later in
the process.
ISPF apparently elects the latter; many programs elect the former e.g.
with respect to SYSLIB DD. Fortunately, ISPF doesn't require that a
display be available when the programmer intends not to use one.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
