dspfld ipgamf4/apg02phy Will show you the file you would want to interrogate to determine the CURRENT failed jobs that users submitted... This file contains a record for EVERY task request the users make in JBA... dspfld ipgamf4/apg02arc Will show the archived copy of the same file... This file is a multi-member file. Hopefully you are running the AMDAYEND command as part of your night job, if so, then any APG02PHY records are "DEALLOCATED" and archived at that time... This job will create a new member in the file APG02ARC every time it runs... The member name is 'X' + the 6-digit date when it was created... These members can accumulate quickly so consideration should be given to how much of this data to retain... Accordingly regularly scheduled housekeeping should include removal of old members from this file... If you are not running the AMDAYEND routine, then your APG02PHY file will contain history of EVERY task that has ever been run by the users on this box from the day JBA was installed... I encourage you to add the AMDAYEND command to your Night Job... Also the AMDAYEND routine issues a call to XA705 which actually runs the "DEALLOCATION" routine - XA705 can also be called at any time during the day, from the command line, to remove any bogus exclusivity locks you might encounter. Field Size Typ Description TMOF02 6 0 P Time Request Finished - This field will be all 9's if the job is active or has ended abnormally and is not "DEALLOCATED"... If the job finishes normally the field will be appropriately time-stamped... To inquire the APG02PHY file and see the currently active jobs on the system try this command and subsequent menu options. STRIPGAM 5. Operational Enquiries 2. Active Jobs Select each entry with a 1 and press enter... If you see this message on any of the records then you know you've found one that is no longer active on OS/400 but was not "DEALLOCATED" normally according to Application Manager... i.e. The job ended abnormally... THIS JOB HAS FINISHED WITHOUT DE-ALLOCATION THIS IS BECAUSE THE JOB HAS BEEN CANCELLED WHILST ON JOBQ OR ACTIVE DE-ALLOCATION (F13) IS RECOMMENDED You can issue a call to XA705 from the command line to "DEALLOCATE" all jobs or F13 to "DEALLOCATE" just this one... The following command and menu options perform the call to XA705 with a splash verification screen inserted using XA705CLP... STRIPGAM 7. Utilities 4. Verify Allocations Running XA705 is ALWAYS a safe thing to do, and is the way to deallocate bogus exclusivity locks. A field in the file called MODE02 1 A Mode of Function - will be marked with an 'X' when it is Deallocated in this way... Also the TMOF02 field will be updated with the time of the deallocation... To see a list of the archived members you currently have on the system try this command and subsequent menu options. STRIPGAM 5. Operational Enquiries 3. Job History 2. Archived Jobs This will present you with a list of all members in the file APG02ARC... >From there you can inquire within a specific member for any jobs that did not deallocate normally, i.e. Use Query and select field MODE02 = 'X' Inquire on Archived Request History 1=Inquiry 2=Flexible inquiry 3=Delete member 4=Delete member in batch 5=Create access path 6=Create access path in batch 7=Delete access path Type options, press Enter Archive Creation Access Date Date Opt Member Date Path No of entries From To X010101 1/01/01 248 12/31/00 01/01/01 X010103 1/03/01 2,875 01/01/01 01/03/01 X010104 1/04/01 2,769 01/03/01 01/04/01 X010105 1/05/01 2,644 01/04/01 01/05/01 X010106 1/06/01 2,380 01/05/01 01/06/01 X010107 1/07/01 104 01/06/01 01/07/01 X010108 1/08/01 137 01/07/01 01/08/01 X010109 1/09/01 2,791 01/08/01 01/09/01 X010110 1/10/01 2,584 01/09/01 01/10/01 X010111 1/11/01 2,493 01/10/01 01/11/01 X010112 1/12/01 2,276 01/11/01 01/12/01 X010113 1/13/01 2,098 01/12/01 01/13/01 F3=Exit F11=Delete all members in batch I can see that I have some houskeeping to do myself... Anything this old can be of no use and is only taking up space... Hope that helps... "Brunk, Kevin" <firstname.lastname@example.org> on 01/30/2002 11:41:21 AM Please respond to email@example.com To: "'firstname.lastname@example.org'" <email@example.com> cc: (bcc: Jeff Klipa/Harvard) Subject JBA ML - Listing of failed JBA jobs. : This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] We're working on a project to create a "master" schedule of jobs that run on our AS/400. Once we have this master schedule developed, we'd like our operations staff to daily log against it the completion times of jobs as well as the status of the completion (abend or completed normally). I've noticed that JBA jobs always seem to end normally, from an AS/400 viewpoint, because XA901CLP seems to detect abends and performs a dump and then ends normally. I know that jobs run from the JBA scheduler are upated with a run status and that we can tell which scheduled jobs ended abnormally. Is there a way I can similarly determine if user submitted jobs ended abnormally? Does XA901CLP store the start and stop and run status information of all jobs in some sort of history file that could be queried? Ideally, we want our morning operator to run a system status report that would list the failed jobs. ==Kevin Brunk Manager, Business Systems Development _______________________________________________ This is the GEAC/JBA System 21 Users (JBAUSERS-L) mailing list To post a message email: JBAUSERS-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/jbausers-l or email: JBAUSERS-Lfirstname.lastname@example.org Before posting, please take a moment to review the archives at http://archive.midrange.com/jbausers-l.