|
I wonder, how long does the AMDAYEND thing run? I've never run it and hence have no idea. Thanks. -----Original Message----- From: system21-request@xxxxxxxxxxxx [mailto:system21-request@xxxxxxxxxxxx] Sent: Friday, 8 August 2003 1:01 AM To: system21@xxxxxxxxxxxx Subject: SYSTEM21 Digest, Vol 1, Issue 570 Send SYSTEM21 mailing list submissions to system21@xxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.midrange.com/mailman/listinfo/system21 or, via email, send a message with subject or body 'help' to system21-request@xxxxxxxxxxxx You can reach the person managing the list at system21-owner@xxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of SYSTEM21 digest..." Today's Topics: 1. AFI EXCLUSIVE USE (Janet Jewell) 2. Re: AFI EXCLUSIVE USE (Richard_Caldicott@xxxxxxxxxxxxxxx) 3. Re: AFI EXCLUSIVE USE (Rhearl@xxxxxxx) 4. Re: [SYSTEM21] AFI EXCLUSIVE USE (Jeff Klipa) 5. Re: [SYSTEM21] AFI EXCLUSIVE USE (Richard_Caldicott@xxxxxxxxxxxxxxx) ---------------------------------------------------------------------- message: 1 date: Wed, 6 Aug 2003 17:07:40 -0700 from: Janet Jewell <JanetJewell@xxxxxxxxxxxxxxxxx> subject: [SYSTEM21] AFI EXCLUSIVE USE 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 ------------------------------ message: 2 date: Wed, 6 Aug 2003 23:03:57 -0500 from: Richard_Caldicott@xxxxxxxxxxxxxxx subject: Re: [SYSTEM21] AFI EXCLUSIVE USE <P> On a command line type call xa705clp and then press enter & enter again. Hopefully this will sort it.</P><P> </P><P>Richard<BR><BR><FONT SIZE=2><B>Janet Jewell <JanetJewell@xxxxxxxxxxxxxxxxx></B></FONT><BR><FONT SIZE=2>Sent by: system21-bounces+richard_caldicott=tandybrands.com@xxxxxxxxxxxx</FONT><BR><F ONT SIZE=2>08/06/2003 05:07 PM MST</FONT><BR><FONT SIZE=2>Please respond to System 21 Users</FONT><BR><BR> <FONT SIZE=2>To:</FONT> <FONT SIZE=2>system21@xxxxxxxxxxxx</FONT><BR> <FONT SIZE=2>cc:</FONT> <BR> <FONT SIZE=2>bcc:</FONT> <BR> <FONT SIZE=2>Subject:</FONT> <FONT SIZE=2>[SYSTEM21] AFI EXCLUSIVE USE</FONT><BR> <BR><BR></P><P><FONT FACE="Monospace,Courier">In AFI maintenance, the system is saying that there are other requests<BR>already using the company. When I take a F7=Display, it says there are no<BR>jobs currently using this system. I looked in STRM400 and there were no<BR>active jobs or jobs needing to be deallocated. ! I also checked for jobs in<BR>the jobq.<BR></FONT><BR><FONT FACE="Monospace,Courier">The other day in our test environment, I had ended an AFI post, which I<BR>deallocated. If I look in the APG02PHY file, the job that I had ended is<BR>showing. I think that it should not be there.<BR></FONT><BR><FONT FACE="Monospace,Courier">Any ideas?<BR></FONT><BR><FONT FACE="Monospace,Courier">Thanks,<BR>Janet<BR></FONT><BR><BR><BR><FONT FACE="Monospace,Courier">_______________________________________________<BR> This is the System 21 Users (SYSTEM21) mailing list<BR>To post a message email: SYSTEM21@xxxxxxxxxxxx<BR>To subscribe, unsubscribe, or change list options,<BR>visit: <A HREF=http://lists.midrange.com/mailman/listinfo/system21>http://lists.midran ge.com/mailman/listinfo/system21</A><BR>or email: SYSTEM21-request@xxxxxxxxxxxx<BR>Before posting, please take a moment to review the archives<BR>at <A HREF=http://archive.midrange.com/system21>http://archive.midrange.com/system ! 21</A>.</FONT></P> ------------------------------ message: 3 date: Thu, 7 Aug 2003 06:07:28 EDT from: Rhearl@xxxxxxx subject: Re: [SYSTEM21] AFI EXCLUSIVE USE I agree....... ------------------------------ message: 4 date: Thu, 07 Aug 2003 14:06:50 +0000 from: "Jeff Klipa" <jklipa@xxxxxxxxxxx> 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 ------------------------------ message: 5 date: Thu, 7 Aug 2003 09:37:36 -0500 from: Richard_Caldicott@xxxxxxxxxxxxxxx subject: Re: [SYSTEM21] AFI EXCLUSIVE USE 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. ------------------------------ _______________________________________________ This is the System 21 Users (SYSTEM21) digest 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. End of SYSTEM21 Digest, Vol 1, Issue 570 **************************************** ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
midrange.com
