+ Reply to Thread
Results 1 to 6 of 6

Thread: Unraveling the Mystery of Activation Groups

  1. #1
    Guest.Visitor Guest

    Default Unraveling the Mystery of Activation Groups

    ** This thread discusses the article: Unraveling the Mystery of Activation Groups **
    ** This thread discusses the Content article: Unraveling the Mystery of Activation Groups **
    0

  2. #2
    Guest.Visitor Guest

    Default Unraveling the Mystery of Activation Groups

    ** This thread discusses the article: Unraveling the Mystery of Activation Groups **
    What are some of the specific benefits of using activation groups? What are some of the the specific pitfalls of using activation groups? Thanks in advance for any intel.

  3. #3
    glea@dextermag.com Guest

    Default Unraveling the Mystery of Activation Groups

    ** This thread discusses the article: Unraveling the Mystery of Activation Groups **
    It's nice to know how to use activation groups but why bother? What does it do for me? What does it do for the users?

  4. #4
    Guest.Visitor Guest

    Default Unraveling the Mystery of Activation Groups

    ** This thread discusses the article: Unraveling the Mystery of Activation Groups **
    What about using commitment control, OVRxxxF, shared open data path?

  5. #5

    Default Unraveling the Mystery of Activation Groups

    ** This thread discusses the article: Unraveling the Mystery of Activation Groups **
    Using DFTACTGRP(*ELIGIBLE) is a very dangerous thing to do. It might reclaim system activation groups that are important to your job. When you want to clean up many activation groups, the easiest way is just to sign off and sign on again. If you don't want to sign off, the correct action is to do a DSPJOB, find out what activation groups are being used, and individually reclaim the ones that are associated with your own applications. If you don't know why an activation group is there, you should not reclaim it.

  6. #6

    Default Unraveling the Mystery of Activation Groups

    ** This thread discusses the article: Unraveling the Mystery of Activation Groups **
    "Limited function is defined as programs that don't contain any procedures, don't call any procedures, and use no contemporary built-in functions (BIFs) ..." I think %PADDR is the only built-in function that is not allowed for a DFTACTGRP(*YES) program. " ... as well as any features that require procedures not supported by *DFTACTGRP." What other features besides bound calls and %PADDR require procedures not supported by *DFTACTGRP?

+ Reply to Thread

Similar Threads

  1. Activation groups for embedded SQL
    By bibarnes@yahoo.com in forum COBOL
    Replies: 1
    Last Post: 07-28-2003, 01:50 PM
  2. Activation groups
    By bchinowth@werner.com in forum RPG
    Replies: 3
    Last Post: 06-03-2002, 09:47 AM
  3. A question about activation groups
    By Guest.Visitor in forum Programming
    Replies: 4
    Last Post: 11-07-2000, 01:10 PM
  4. How do you use Activation Groups?
    By Guest.Visitor in forum Programming
    Replies: 13
    Last Post: 10-15-1998, 04:07 PM
  5. Activation Groups
    By Guest.Visitor in forum Programming
    Replies: 0
    Last Post: 01-01-1995, 02:00 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts