Hi Graham, There isn't much in the way of automation for started tasks such as DB2 and CICS. The Dallas systems are configured from a basic template and all other activities such as started tasks are as you say, achieved by issuing manual start commands.
Since you are time constrained, you are probably stuck with manual startup commands. If you have the ADCD VTAM utility VTAMAPPL, you can automate most of these startup commands, for example the DB loadparm member starts DB2, CICS and MQ. We use the AUTO utility for STC startup on Dallas and z/VM EXECS to startup and shutdown to a QUIESCE and CP LOGOFF state. Wayne Wed, May 29, 2013 at 1:40 AM, Graham Hobbs <[email protected]> wrote: > Hi Wayne, > > DBPROCAG .. co-incidentally it just so happens I can't get to the D2 option > via ISPF so wrote to IBM and they tied it to logon with DBPROCAG! However, I > can only do what their Ref Guide says which is start DB2 with /-DBAG START > DB2 - that's all I know. I don't know what startup proc gets run:-( .. am > assuming the start cmd does that. Am waiting to hear from IBM. > > My system has no manual intervention, it runs in batch mode to do its thing, > is designed that way. Any stoppage is bad news. > cheers and thanks, > Graham > ------ > > On 28/05/2013 12:03 AM, Wayne Bickerdike wrote: >> >> Graham, >> >> On most Dallas setups you will have a DBPROCAG for a DBA TSO logon >> proc. Once logged on you should have the DB2 Admin tool and SPUFI. >> Most of what you have been doing can be done without running batch >> jobs. >> >> HTH >> >> On Tue, May 28, 2013 at 2:37 AM, Graham Hobbs <[email protected]> wrote: >>> >>> Hello Lizette, >>> >>> Got all your pointers about: >>> >>> - EXEC PROC, looking into SDSNLOAD, manual refs, installation step 10, >>> etc >>> >>> - doing stuff manually on TSO screens is a non-starter; my software kicks >>> off by running a single JCL stream, generating and 'sub'bing new jobs >>> along >>> its way (including this STOGROUP creation), is totally automated, no >>> hands >>> on, have got 10 freebe days left on Dallas, after that it's $550/mnth, so >>> little time to study even subsets of subjects (like DB2) when only a mini >>> job like DSNUPROC is required - in 10 days I go away:'( >>> >>> - am not averse to studying but having 40 yrs of app programming with no >>> sysprog stuff, is why I really appreciate a 'canned' solution from people >>> who've actually done these small but vital to me one-off functions; I get >>> all of my answers from a) googling, b) this group, c) IBM as last resort >>> - >>> it works >>> >>> - after writing the above (see my reply to Ron Heskell) - the DSNUPROC >>> problem is solved; more important I have the soon to be tested feeling >>> that >>> I've learned a valuable tool for my little project >>> >>> All this is much appreciated, so thanks kindly for the help! >>> >>> Graham >>> ------ >>> >>> >>> On 27/05/2013 9:32 AM, Lizette Koehler wrote: >>>> >>>> Graham, >>>> >>>> If you are DB2 V10 then you need to keep in line with IBM's direction of >>>> SMS >>>> management. I would look at the Share Presentation >>>> http://www.bwdb2ug.org/PDF/SMS_is_Now_Mandatory_for_DB2_V10.pdf >>>> >>>> >>>> Define the SMS environment for the DB2 catalog and directory data sets >>>> (DSNTIJSS) >>>> >>>> In DB2R Version 10, data sets that are defined for the DB2 catalog and >>>> directory are managed by DB2 and must be SMS-managed. >>>> >>>> Start of changeJob DSNTIJSS shows how to create a stand-alone SMS >>>> environment for the DB2 catalog and directory data sets. Job DSNTIJSS is >>>> designed for use on systems that do not already have a SMS environment, >>>> but >>>> it can also be used as a reference for adapting an existing one. End of >>>> change >>>> >>>> Start of changeYou are not required to convert existing DB2 data sets to >>>> an >>>> SMS environment before migrating to Version 10. These data sets can >>>> indefinitely remain non-SMS-managed, but they will be converted to SMS >>>> management when the related table space is reorganized.End of change >>>> >>>> The SMS environment that you use for DB2 catalog and directory data sets >>>> must be established before you begin migration to Version 10. The SMS >>>> environment must include a data class for allocating the data sets in >>>> extended format and using extended addressability. To define a data >>>> class >>>> with this attribute, specify EXT in the DATA SET NAME TYPE field of the >>>> DATA >>>> SET CLASS DEFINE panel of ISMF. Then, ensure that the automatic class >>>> selection (ACS) routine associates the DB2 catalog and directory data >>>> sets >>>> with this data class. >>>> >>>> To create the stand-alone SMS environment for the DB2 catalog and >>>> directory: >>>> >>>> Customize job DSNTIJSS according to the directions in the job >>>> prolog. >>>> Run job DSNTIJSS. >>>> To activate the SMS environment, use this z/OS command, where >>>> scds-name >>>> is the name of the SMS source control data set that was specified by >>>> DSNTIJSS: >>>> >>>> SETSMS SCDS(scds-name) >>>> >>>> Attention: This command will deactivate any existing SMS >>>> environment >>>> that is defined from another SCDS. >>>> Run the SMS CONVERTV tool with the TEST option to verify that all >>>> data >>>> sets on target volumes can be placed under SMS management. >>>> >>>> Example of running CONVERTV with the TEST option: >>>> >>>> //CONVRTV EXEC PGM=ADRDSSU,REGION=5M >>>> //SYSPRINT DD SYSOUT=* >>>> //DD1 DD UNIT=SYSALLDA,VOL=SER=targvol1,DISP=OLD >>>> //DD2 DD UNIT=SYSALLDA,VOL=SER=targvol2,DISP=OLD >>>> //SYSIN DD * >>>> CONVERTV DDNAME(DD1) SMS TEST CATALOG >>>> CONVERTV DDNAME(DD2) SMS TEST CATALOG >>>> /* >>>> >>>> When CONVERTV TEST reports that all data sets on the target >>>> volumes >>>> can >>>> be placed under SMS management, run CONVERTV without the TEST option to >>>> convert the data sets. If any data sets cannot be converted, do not run >>>> CONVERTV without the TEST option. You must either create additional ACS >>>> routines to manage these data sets or move them to different (non-SMS) >>>> volumes. >>>> >>>> Related tasks: >>>> Premigration checklist for migration to DB2 Version 10 conversion mode >>>> from >>>> Version 8 >>>> Premigration checklist for migration to DB2 Version 10 conversion mode >>>> from >>>> Version 9.1 >>>> >>>> That is why the DB2 Newsgroup can be so helpful. They focus on DB2 and >>>> can >>>> keep you on the right track. There are good SHARE presentations on how >>>> DB2 >>>> and SMS management are working together. >>>> >>>> Lizette >>>> >>>> >>>> -----Original Message----- >>>> From: IBM Mainframe Discussion List [mailto:[email protected]] On >>>> Behalf Of Ron hesketh >>>> Sent: Sunday, May 26, 2013 11:58 PM >>>> To: [email protected] >>>> Subject: Re: DFHUTILB and DFHUPROC >>>> >>>> Hi Graham, >>>> DSNUPROC is aJCL procedure for executing DB2 utilities. DSNUTILB >>>> is >>>> the >>>> DB2 utility program. >>>> To create DB2 objetcts using DSNUTILB, you nees to use the EXEC SQL >>>> online >>>> utility control statement. >>>> >>>> To create your STOGROUP using DSNUPROC , your JCL woul;d be something >>>> like >>>> : >>>> >>>> //STEP1 EXEC DSNUPROC,SYSTEM=ssid,UID='',UTPROC='' <==== ssid is >>>> your DB2 subsystem id. >>>> //DSNUPROC.SYSPRINT DD SYSOUT=(*) >>>> //DSNUPROC.UTPRINT DD SYSOUT=(*) >>>> //DSNUPROC.SYSIN DD * >>>> EXEC SQL >>>> CREATE STOGROUP CHELGRP >>>> VOLUME VPWRKD >>>> VCAT CHELCAT >>>> ENDEXEC >>>> /* >>>> >>>> To do it using IKJEFT01, you need to use one of the IBM sample programs >>>> to >>>> process the DDL.the TSO DSN command cannot execute SQL. >>>> Heres an example from the DB2 IVP job DSNTEJ1 : >>>> >>>> //PH01S01 EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT) >>>> //SYSTSPRT DD SYSOUT=* >>>> //SYSTSIN DD * >>>> DSN SYSTEM(ssid) >>>> RUN PROGRAM(DSNTIAD) PLAN(DSNTIAD) - >>>> LIB('your.RUNLIB.LOAD') >>>> //SYSPRINT DD SYSOUT=* >>>> //SYSUDUMP DD SYSOUT=* >>>> //SYSIN DD * >>>> CREATE STOGROUP CHELGRP >>>> VOLUME VPWRKD >>>> VCAT CHELCAT >>>> ; >>>> /* >>>> >>>> Regards, >>>> Ron >>>> >>>> >>>> >>>> From: Graham Hobbs <[email protected]> >>>> To: [email protected] >>>> Date: 27/05/2013 01:10 AM >>>> Subject: DFHUTILB and DFHUPROC >>>> Sent by: IBM Mainframe Discussion List <[email protected]> >>>> >>>> >>>> >>>> Wisdom sought please! I have tried to build a stogroup via batch job. >>>> >>>> CREATE STOGROUP CHELGRP >>>> VOLUME VPWRKD >>>> VCAT CHELCAT >>>> >>>> Seems DFHUPROC and DFHUTILB are options. Is one more common than the >>>> other? >>>> Is it that the first calls the second (amongst others)? >>>> Cheers, >>>> Graham Hobbs >>>> P.S. Secretly am looking for JCL that bl..dy works:-):-[ >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to [email protected] with the message: INFO IBM-MAIN >>>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >> >> >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
