|
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
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.