Re: AFI EXCLUSIVE USE -- SYSTEM21

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