Active System Segment needs replacing
rip_uno
has some errors in a couple of the macros that it contains. I have
fixed the macros, but now have to get them into use. Since the SYSSEG
is in use all the time I am wondering the best practice to replace it.
1) Rename the existing SYSSEG out of the way. Create a new SYSSEG
and let the old one slowly go way as users log in and out.
2) Create a SYSSEG1 and modify TACLLOCL to reference SYSSEG1 letting
SYSSEG slowly lose users as they log in and out.
3) Wait for a maintenance window to fix segment to bring in the
corrected macros. {least appealing to me due to time constraints}
Any suggestions as to the best approach in your eyes?
Doug Miller
>We have a segment (SYSSEG) referenced by TACLLOCL that we have found
>has some errors in a couple of the macros that it contains. I have
>fixed the macros, but now have to get them into use. Since the SYSSEG
>is in use all the time I am wondering the best practice to replace it.
The remainder of my comments are predicated on the assumption that the bugs
(or at least the problems they cause) are minor -- otherwise you would have
already forced a maintenance window and fixed the problem, and you wouldn't be
here asking this question. :-)
>1) Rename the existing SYSSEG out of the way. Create a new SYSSEG
>and let the old one slowly go way as users log in and out.
That's the way I've always done it.
If you need the old one to go away quicker, you could write a macro that
detects which segment file a TACL process has attached, and makes the switch
automagically. Then send an email to all users, asking them to run that macro.
If you want to be slick about it, you could modify some frequently-used macro
that's run as a stand-alone file (not from the segment file) to invoke your
new macro.
If you want to be *really* slick about it, embed that code in some
frequently-used macro within the segment file itself. Then you'll never have
to worry about that again.
>
>2) Create a SYSSEG1 and modify TACLLOCL to reference SYSSEG1 letting
>SYSSEG slowly lose users as they log in and out.
Major drawback I see there is that the name of the current segment file has
changed. What will you do the next time this happens? Create another one
called SYSSEG2, and modify TACLLOCL again? No point in creating unnecessary
work for yourself.
Makes more sense to me for the current version to always be SYSSEG,
immediately previous version SYSSEG1, next previous SYSSEG2, etc.
>
>3) Wait for a maintenance window to fix segment to bring in the
>corrected macros. {least appealing to me due to time constraints}
The only reason I can see for taking this option is if there's any possibility
of conflicts resulting from some users having a [slightly] different set of
macros from the rest.
Warren M
> We have a segment (SYSSEG) referenced by TACLLOCL that we have found
> has some errors in a couple of the macros that it contains. I have
> fixed the macros, but now have to get them into use. Since the SYSSEG
> is in use all the time I am wondering the best practice to replace it.
>
PURGE [default_subvol].ZZSEGF* == Get rid of any old segment files
which are no longer in use.
IF NOT file exists [default_subvol].SYSSEG
OR modif timestamp of [default_subvol].SYSSEG < modif timestamp of
[standard_location].SYSSEG
== SYSSEG does not exist or is out of date
rename [default_subvol].SYSSEG, [default_subvol].ZZSEGFxx ==
Where xx is unique
FUP DUP [standard_location].SYSSEG , [default_subvol].SYSSEG ,
SOURCEDATE
ENDIF
ATTACHSEG [default_subvol].SYSSEG == etc
rip_uno
Thanks Doug and Warren.
It seems both have referenced the same as the best solution, but
Warren - I really like your concept of the automation of the task. I
am thinking that is the route we will take.
I have been doing applications work using COBOL for the past 15 years
and have just started more on the Systems side and working with TACL
and in that regard, these groups have been a real blessing. Thanks to
all of you who hang out here and help - if nobody has said it enough -
you are extremely appreciated!
rip_uno
>
> - Show quoted text -
One last question on this hopefully. How do you handle the security
on this? Currently we have this secured 255,255, "AGAG"
I could secure it "AAAA" but that kinda defeats the security of the
file and anything else blows up during the rename with error 48.
Thanks in advance for the assistance
Doug Miller
>
>One last question on this hopefully. How do you handle the security
>on this? Currently we have this secured 255,255, "AGAG"
Anyone in the SUPER group should be able to rename it.
>
>I could secure it "AAAA" but that kinda defeats the security of the
>file and anything else blows up during the rename with error 48.
Leave the security and ownership as is, and use a SUPER-group logon to do the
rename.
Warren M
> on this? Currently we have this secured 255,255, "AGAG"
>
> I could secure it "AAAA" but that kinda defeats the security of the
> file and anything else blows up during the rename with error 48.
>
>
> - Show quoted text -
I handle security as follows:
- [standard_location].SYSSEG is secured for public read since it is
copied by each user.
- Before renaming the existing [default_subvol].SYSSEG, I obtain the
userid of it.
- After the FUP DUP, I do a FUP GIVE to the owner of the renamed
SYSSEG file.
This keeps the ownership of the users copy of the file consistant
(assuming the first copy was created by the owner of the subvol).
Each user gets a "private" copy of SYSSEG in their default subvolume,
which is always current (as of when they logged on).
If a user has multiple TACL sessions, those TACL sessions share the
segment file.
No security issues, since the "private" copy of SYSSEG in the users
default subvolume always belongs to the user.
Granted the user could resecure or even replace it, but since
everything in a TACL segment file is visible by displaying the
variables contained in it, and there are no special privledges granted
by executing TACL code, there is not much point in worrying about it.
rip_uno
> In article <de2e531a-44c0-4684-9e5a-2546b41ec...@y33g2000prg.googlegroups.com>, rip_uno <ronbog...@hotmail.com> wrote:
>
>
>
> >One last question on this hopefully. How do you handle the security
> >on this? Currently we have this secured 255,255, "AGAG"
>
> Anyone in the SUPER group should be able to rename it.
>
>
>
> >I could secure it "AAAA" but that kinda defeats the security of the
> >file and anything else blows up during the rename with error 48.
>
> Leave the security and ownership as is, and use a SUPER-group logon to do the
> rename.
We took the path of leaving security as it stood and renaming the
existing SYSSEG out fo the way and creating a new one in it's place
instaed of creating individual copies for all users. Since the
changes are ate best rarely necessary and this one was a quick and
easy fix - it was solved and I was on my way to bigger and dirtier
tasks.
Thanks to all who jumped in and helped.