RE: Technical and Philosophy

Once again, there are several options on the SECTOOLS menu that can help with 
user profiles. This menu is on every iSeries/i5/system whatever.


-------------- Original message -------------- 
From: "Lapeyre, Francis" <FLAPEYRE@xxxxxxxx> 

> 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. 
> -- 
> 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. 
>