Re: AFI EXCLUSIVE USE -- SYSTEM21

I just want to address the issue of the environment codes vs exclusivity 
and why it works the way it does.

Under normal situations your environments would have separate data 
libraries, but it is possible to have the same data libraries in use by 
multiple environments.  You might say that no sane person would do this 
but it is a possibility. In fact some users have a test environment and 
then create a PTF environment which is a copy of test but with an extra 
PTF library on top to save on disk space. 

It is a major hassle I know but at present there is no way to ensure 100% 
that a data library does not cross environments and therefore 
...................

Richard




"Jeff Klipa" <jklipa@xxxxxxxxxxx>
Sent by: system21-bounces@xxxxxxxxxxxx
08/07/2003 09:06 AM
Please respond to System 21 Users

 
        To:     system21@xxxxxxxxxxxx
        cc: 
        Subject:        Re: [SYSTEM21] AFI EXCLUSIVE USE


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

_______________________________________________
This is the System 21 Users (SYSTEM21) mailing list
To post a message email: SYSTEM21@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/system21
or email: SYSTEM21-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/system21.