Tracy,

You are correct.  This is one of the things we try to highlight about the
new command file.  I believe the command file can be adapted to handle
multiple groups, since DBGENERAL permits multiple jobs as long as they are
in different groups.  However, currently this has not been implemented.

One issue is that if you have two databases in the same group with
different creators the old command file will spawn jobs for each
simultaneously.  This must be avoided as DBGENERAL does not permit multiple
jobs in the same group.

So in your particular case, I would suggest you stream two jobs - one in
each group.  Or create a jcl which logs into one group, does an '@' manage
of capacities, then does a change group and an '@' manage of the capacities.

The rule is you must have a separate invocation of DBGENALT for each
creator and group.  Said another way, you can manage multiple databases if
they are in the same group and created by the same user.

Note you are also free to add the JCW mentioned previously to cause the
'old' command file to work with DBGENERAL version 7.3.

tj


At 08:26 AM 12/19/00, Johnson, Tracy wrote:
>Using the 7.3 script version fixes this problem
>but now another anomaly appears.  It provides the
>error:
>
>Group different than current logon::: DBFILE##.DBGROUP.ACCOUNT
>(DBGROUP:::LOGONGROUP)
>
>if you are in a different group than where the file resides.
>
>It appears the 7.217 script didn't care if you used @.@ for the fileset,
>it made the attempt whether you were in the logon group or not.
>
>Tracy Johnson
>MSI Schaevitz Sensors




    Tim Joseph, Technical Support
    425-485-8536 (phone)
    206-650-3101 (mobil)
    [log in to unmask] (email)
    425-485-7801 (fax)
    http://www.bradmark.com/