×

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.



  1.  Home
  2. MIDRANGE-L
  3. December 2003

Re: Ending TCP/IP, FTP jobs in QSYSWRK

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 thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 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.