×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Janet,
Richard is right... A simple CALL XA705 (clp not required) from any JBA
OPTION line will deallocate any and all unallocated jobs across all
environments... You can run this option a million times a day without fear
of hurting anything. This should be your first thought whenever you hear of
a job ending abnormally.
Unfortunately when they developed the concept of task exclusivity they
neglected to add adequate support for environment codes... There's no
earthly reason why your live production environment should be looking at
jobs running (or not running as the case may be) in the TST environment for
task exclusivity... TST background jobs will also give you grief if you're
running them while trying to run options that require exclusive company
use...!!! And those are TST environment task definitions... So, it does
get complicated. You could simply not use the same company numbers in the
TST environment as you do in live but that doesn't lend itself to easily
refreshing TST data from the live environment...
Part of the problem is that we don't copy our tasks to the TST environment
(and rightly so IMHO) we simply use the elegantly designed "fall through"
method for MENU, LIBL, TASK and COMPANY Authority and Exclusivity checking.
That's the real reason why your production environment "thinks" you have a
production job running when in reality it was called from the TST
environment.
This has been a problem since the beginning of time... One way around it is
to set up an entirely separate "WORLD" - but that's overkill in my opinion
and not supported by geac... A lot of work for this minor irritation...
The other thing you can do is to copy your TASK definitions into the TST
environment but I do not recommend this as it can cause other
"complications"... And if you copy from 'blank' to TST you wipe out
whatever is in TST now, so you lose all your custom task definitions in
TST... You don't want that headache... Again a lot of work for a minor
irritation and the potential for larger irritations...
FYI - CALL XA705 is the same as the following steps...:
STRIPGAM (<--This is a short cut to STRM400 and 5. Application Manager)
7. Utilities
4. Verify Allocations
The fact that you found your record in APG02PHY shows a good understanding
on your part of what's going on behind the scenes with the exclusivity
locks... And you should also be running the AMDAYEND routine in the night
job if your not currently... This job actually runs the CALL XA705 option
and it archives the APG02PHY file into APG02ARC... That would clean up your
task exclusivity problems every night so the morning shift should not hit
any of yesterday's bogus exclusivity locks in the morning...
Also, it is important to note that APG02ARC is a multi-member file which has
a separate member created every time the AMDAYEND job runs... This file can
get quite large and should have it's members purged on a regular basis...
It's up to you to decide how much history to keep on the disk. At some
point the data stored in there becomes stale and useless, just taking up
disk space.
You can view and maintain the archived members stored in IPGAMF4/APG02ARC
using the following steps...:
STRIPGAM
5. Operational Enquiries
3. Job History
2. Archived Jobs
This can be a very useful resource if you're trying to investigate a mystery
that may or may not have happened several days or months ago... "Did Fred
or Barney actually run that menu option...?" or "Did Betty or Wilma
remember to update Sales Analysis after they ran invoicing?" or "Who was the
idiot who ran the G/L Rebuild?!" You have to "5=Create access path" before
you can view the data inside each member and you have to "7=Delete access
path" before you can delete the member from the file...
Again, these archives only exist if you're running the AMDAYEND routine in
the night job from Machine Manager... If you're not running this then your
APG02PHY file is growing VERY large...!!! One record every time a user runs
a job...!!! This could potentially have an impact on performance for your
users.
I hope that helps provide a little more insight into the inner workings of
Application Manager...
PS - We've written custom routines in-house to clear the two other types of
locking problems... Record locks in the *P99 files (exception SAP93) and
the Active Record flags in some Master Files... We have both an interactive
menu option for adhoc record lock clearing during the day and jobs that run
in the night job to clear all record locks each night... I find this a real
time saver for those occasional times when I do get calls about locked
records... Search this archive for more on this topic...
Good luck...
----Original Message Follows----
From: Janet Jewell <JanetJewell@xxxxxxxxxxxxxxxxx>
Reply-To: System 21 Users <system21@xxxxxxxxxxxx>
To: system21@xxxxxxxxxxxx
Subject: [SYSTEM21] AFI EXCLUSIVE USE
Date: Wed, 6 Aug 2003 17:07:40 -0700
In AFI maintenance, the system is saying that there are other requests
already using the company. When I take a F7=Display, it says there are no
jobs currently using this system. I looked in STRM400 and there were no
active jobs or jobs needing to be deallocated. I also checked for jobs in
the jobq.
The other day in our test environment, I had ended an AFI post, which I
deallocated. If I look in the APG02PHY file, the job that I had ended is
showing. I think that it should not be there.
Any ideas?
Thanks,
Janet
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.