× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Our auditors don't like old profiles out there, so most of the scheduled
jobs run under QSYSOPR or something generic we created for the occasion. A
terminated user's profile is usually deleted (not just disabled) the next
workday. A scheduled job disables them the day after the termination is
detected from the (PC-based) HR system.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Al Mac
Sent: Tuesday, February 7, 2006 2:36 AM
To: Midrange Systems Technical Discussion
Subject: Re: Technical and Philosophy

Disabling user profiles will not block the running of tasks in those user
names, such as via GO CMDSCDE.  We have a number of tasks in there, which
are scheduled to run in the wee hours when not such a big demand on the
system, and many of them in the names of former employees.  It is a nuisance
to move this stuff to other people, so now we have a bunch of SCDE jobs
running on non-existent employees which have been disabled.

I just did the end month fiscal, during which there are a bunch of tasks,
that if someone signs onto the files involved, while they are running, the
EOM will bomb.  Now the personnel of the company are accustomed to signing
on whenever they please, from one of the offices, from home, from laptop via
VPN such as from a customer site.  You can send messages & e-mail to please
stay off during some time period.  it does no good.  Before I was running
the EOM we had EOM crashes regularly, and a good half of them were due to
this phenomena.  Some were due to the EOM person forgetting this nuance.

Since i took over EOM the only crashes have been because I keyed something
in wrong to one of the input screens, such as keying a wrong cut-off date.

How I run EOM ...I get to a critical juncture and I go do the work at main
console.
* Check what's running on system both active and inactive jobs, and if
anything in JOBQ ...
** WRKACTJOB only gets active jobs ... also check WRKSBSJOB QINTER to see
any discontinued jobs
*** I have added to the instant message/400 user identification chart the
telephone extension # where the people usually located, to help personal
contact in case of a problem
** jobs can be in JOBQ set to run at a particular time ... you want to make
sure they not launch in conflict with your plans
* Do a 100% backup with SAVE 21
* ENDSBS *ALL end all subsystems so that only QCTL can sign on at main
console
* SBSSBS *QBATCH so it can do EOM stuff on JOBQ
* Start specific printers to be used in EOM which need SBS QSPL
* Do the EOM update tasks that no one may sign onto in the middle of, and I
am there personally as gatekeeper, in case someone with trouble signing on
tries to use the main console.
* Do a 100% backup with SAVE 21 on a separate tape since there will be
off-site rotation involved here

The previous EOM person used WRKCFGSTS to vary off work stations of people
suspected of being the worst culprits, so that THEY would not be culprits
this time, but with VPN and auto configuration, that does not cut it.  We
have been leaving some auto config openings for convenience of hooking up
new sessions, but not so many as to have a computer security vulnerability.

I have done some work with allocating files.  I may have messed up some
coding, but I end up sign on, run the job that has the allocation, which
goes to JOBQ that way, then sign off so that my sign on session is no longer
entangled with it, then when the JOBQ ends, nothing is entangled with it.
GO CMDLCK will get at info on who is messing with which files right now, by
file, and the nature of their access.  Within WRKACTJOB or equivalent task,
select the user job, 5 then 11 to see their current stack.

We also have some file reorgs we run during the month, that do not run
correctly if people signed on the system, and we have people who are on all
the time, then go home still signed on.  We not want to kill their sessions
during the day, since that will crash updates.  Well we have found a time
frame when we know system not being used, except by sessions left signed on
with no one there, so GO POWER takes the whole system down for a reboot, and
IT know when it is coming back up, so I VPN from home at 3 am and run the
reorgs, shortly after the GO POWER has brought the system back up.

Most of our users now connect via Client Access from PCs which thanks to
Windoze and human error are more prone to go down than dumb terminals.  If
they running certain programs at time of lost connection, this messes up
ability to get back into whatever they were in.  We run reports every nite
to identify any such messups, then deal with whatever is listed.

and don't forget to check GO CLEANUP and GO POWER and GO BACKUP to disable
anything scheduled to run at the time you need unrestricted access to some
files.

>I'm new to at the Iseries world and I need some help both, technical 
>and philosophical.
>
>
>
>I need to keep users out of my files after 7:00 PM.  Someone has 
>suggested that we allocate the files and that would keep the users out.
>Another suggestion was that we secure the users out by disabling the 
>user profiles.
>
>
>
>Which approach would be best/easiest?
>
>
>
>
>
>--
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
>list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, 
>unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a 
>moment to review the archives at 
>http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.