|
If you have your jobd logging level turned up to max, and this volume of transactions, you will get huge job logs that take a long time to complete. You could do the OUTPUT idea in previous post (and then deal with huge files, and a write a purge routine) and reduce log level to minimum (if your ftp has been stable), or cancel QTFTP jobs with option for minimal job log example:ENDJOB JOB(123456/USER/XXX) OPTION(*IMMED) LOGLMT(1) You could even write a clp to find all the qtftp jobs & do this. I personally like the file output so it gets backed to tape, and is easy to scan for problems. jim ----- Original Message ----- From: <michaelr_41@xxxxxxxxxxxxxx> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> Sent: Tuesday, December 02, 2003 9:00 AM Subject: RE: Ending TCP/IP, FTP jobs in QSYSWRK > I wonder if it would help if you did an override of file OUTPUT to a > database file. That would direct the output of the FTP operation to a > file and may eliminate the joblog. > > On Mon, 1 Dec 2003 21:22:39 -0600 , "Jim Damato" > <jdamato@xxxxxxxxxxxxxxxxx> said: > > grrr... > > > > We've performed some tests based on folks' recommendations. No matter > > what > > we do the ending of these QTFTPxxxxx jobs is taking quite a long time. > > ENDTCPSVR SERVER(*FTP), for example, effectively ends all of these jobs > > *IMMED, which still takes a long time. We changed the jobs' logging > > levels > > and found that we're generating thousands of short QPJOBLOG files for > > each > > _JOB_. Each joblog identifies an FTP PUT or GET session. Apparently > > each > > of these QTFTPxxxxx jobs supports thousands of consecutive FTP sessions. > > I > > wonder whether there's some aspect of job cleanup that has grown out of > > control. > > > > We send a ridiculous number of transaction files to and from our AS/400. > > It > > amounts to tens of thousands per week. At each weekly IPL ending the FTP > > server is becoming a significant bottleneck. > > > > Is anyone else running a fairly heavy FTP environment? If so, are you > > experiencing similar issues? > > > > -Jim > > > > James P. Damato > > Manager - Technical Administration > > Dollar General Corporation > > <mailto:jdamato@xxxxxxxxxxxxxxxxx> > > > > -----Original Message----- > > From: Ingvaldson, Scott [mailto:SIngvaldson@xxxxxxxxxxxx] > > Sent: Monday, November 24, 2003 5:54 PM > > To: 'midrange-l@xxxxxxxxxxxx' > > Cc: 'jdamato@xxxxxxxxxxxxxxxxx' > > Subject: RE: Ending TCP/IP, FTP jobs in QSYSWRK > > > > > > Jim - > > > > This is the call of the SAVSYS on one of our systems. It was adapted > > from > > QMNSRBND (On previous advice from Al.) I used to also do the ENDHOSTSVR > > SERVER(*ALL) separately, I changed this after V5R1 when I was told that > > it > > was now included in the ENDTCP. In a nutshell I issue an end to the > > things > > that need a little extra time to shut down gracefully, then do a little > > delay before dropping everything else. If your QTFTPxxxxx jobs are truly > > hanging on for an hour and a half you might want to issue ENDTCPSVR > > SERVER(*FTP) well before calling your backup (if that is practical) My > > guess is that some external factor(connection not closing) is causing > > them > > to hang, is your FTP Inactivity timeout set high? Maybe you could try > > CHGFTPA INACTTIMO(300) > > > > What Al is talking about is more or less the code from LOOP on below. > > This > > basically reissues the ENDSBS *ALL every 15 seconds untile the system > > gets > > to a restricted state and then continues. LIMIT30 sends a message to the > > calling MSGQ if all SBS's don't end in 30 minutes. > > > > BKPENDSYS: PGM PARM(&TAPEDEV &IPL) > > DCL VAR(&TAPEDEV) TYPE(*CHAR) LEN(10) > > DCL VAR(&IPL) TYPE(*CHAR) LEN(1) > > DCL VAR(&LOOPCNT) TYPE(*DEC) LEN(3 0) VALUE(1) > > DCL VAR(&MSGTXT) TYPE(*CHAR) LEN(1) > > > > TECH/ENDQP <::::: > > TECH/ENDMQ <::::: Ends these applications > > > > CALL PGM(TECH/ENDOPT) <::::: ~gracefully~ > > > > > > ENDSBS SBS(QSNADS) OPTION(*IMMED) > > MONMSG MSGID(CPF1054) /* No subsystem QSNADS + > > active. */ > > > > ENDTCPSVR SERVER(*HTTP) > > ENDNFSSVR SERVER(*ALL) > > > > DLYJOB DLY(60) > > > > ENDTCP > > MONMSG MSGID(TCP5713) /* There were no active DHCP + > > jobs, end request ignored. */ > > > > LOOP: ENDSBS SBS(*ALL) OPTION(*IMMED) > > MONMSG MSGID(CPF1035 CPF1001) EXEC(GOTO + > > CMDLBL(DELAY)) /* Subsystems ending with + > > *IMMED option. */ > > GOTO CMDLBL(ENDSBSDONE) > > > > DELAY: RCVMSG MSGTYPE(*EXCP) RMV(*YES) > > IF COND(&LOOPCNT *LT 119) THEN(DO) /* 30 minute + > > limit */ > > DLYJOB DLY(15) > > CHGVAR VAR(&LOOPCNT) VALUE(&LOOPCNT + 1) > > GOTO CMDLBL(LOOP) > > ENDDO > > ELSE CMD(GOTO CMDLBL(LIMIT30)) > > > > ENDSBSDONE: RCVMSG MSGTYPE(*LAST) RMV(*YES) > > CALL PGM(TECH/BKPSAVSYS) PARM(&TAPEDEV &IPL + > > &JOBNAME) > > GOTO CMDLBL(END) > > > > LIMIT30: SNDPGMMSG MSGID(CPA3712) MSGF(*LIBL/QCPFMSG) + > > TOPGMQ(*EXT) MSGTYPE(*INQ) > > RCVMSG PGMQ(*SAME) MSGQ(*PGMQ) MSGTYPE(*RPY) + > > WAIT(*MAX) RMV(*YES) MSG(&MSGTXT) > > IF COND(%SST(&MSGTXT 1 1) *EQ 'G') THEN(DO) > > CHGVAR VAR(&LOOPCNT) VALUE(1) > > GOTO CMDLBL(LOOP) > > ENDDO > > > > END: ENDPGM > > > > > > Regards, > > > > Scott Ingvaldson > > AS/400 System Administrator > > GuideOne Insurance Group > > > > > > _______________________________________________ > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > > list > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > > or email: MIDRANGE-L-request@xxxxxxxxxxxx > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/midrange-l. > > > -- > > michaelr_41@xxxxxxxxxxxxxx > > -- > http://www.fastmail.fm - The way an email service should be > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.