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
