Session Control

[SLewis]

To secure out the SYSREQ function, place OS/400 object level security on
object QGMNSYSR. It is of type *PNLGRP. This way you limit the access to the
SYSREQ function to IT users if they require it.

Stephen R. Lewis
Application Systems Administrator
CCL Custom Manufacturing
Rexdale Plant
11 Bethridge Road
Etobicoke, ON Canada
M9W 1M6
Phone: (416) 740-7400 ext155
Fax: (416) 743-5439
email: [email protected]




Steve Lewis
CCL Custom Manufacturing
11 Bethridge Rd.
Toronto, ON Canada
M9W 1M6

A73 cum 8, 720 V4R4

 

[richard_jansen]

RE: Re[2]: Session Control

Hi,

What does your auditor say about those multiple sign ons?

Richard.



Quote from a posting to JDEList
"..Actually there is a JDE recommendation that you do not allow more than
one session, not for resource reasons but for record locking reasons. JDE
is not very good when it comes to data base integrity so they recommend you
don't allow two signons and all jobs go through a single threaded job
queue..."

This generalisation is a little new to me, seems we have a fair bit of
unresearched scuttlebutt out there.

We have around 200 active users most of whom have multiple sessions and we
have no problems.

Record locking is controlled very well by the OS/400 operating system and
most JDE programs will tell you if a record is locked, without the program
crashing.

Single threaded JOBQ's are essential for the GL Post program and a few
others but this can be easily regulated. We have worked out what batch jobs
(eg DWV's etc) conflict and have changed the JOBQ name appropriately in the
additional parameters section for each dreamwriter. We have about 6 (six)
JOBQs, one is exclusively for GL Post, Workfile Generation etc, in order to
spread the load around and it works a treat.

Regards...... Colin HUGILL
[email protected]
BRAMBLES INDUSTRIAL SERVICES AUSTRALIA





Colin Hugill
Consultant
--------------------------

 

[Colin_Hugill]

RE: Re[2]: Session Control

Richard,

You wrote "..What does your auditor say about those multiple sign ons?.."

Our internal and external auditors have said nothing. Two significant
reasons in my humble opinion as to why;-

a) I don't see that any audit implications exist if a user has several
sessions active, as long as the user uses the same user profile and we have
adequately set up security both at the AS/400 level and at the JDE
Application level. Maybe you could enlighten me on what your auditors
perceive as a problem with multiple sign ons by a single user. I would like
to consider their opinion and perhaps reply to you.

b) Auditors are external to the business entity, they have no direct
responsibility for day to day management and control hence unless they can
demonstratively prove lack of, or weakness in, or threat to, internal
control then there is nothing for them to say. Management (including the
board) are responsible for making decisions about whether to act on
recommendations of auditors - management is not controlled by auditors and
auditors do not control the business entity.

Regards...... Colin HUGILL



Colin Hugill
Consultant

 

[dale_draper]

RE: Re[2]: Session Control

Thank you Colin. Completely agree. We have passed our audit with PWC the
last two years, last years being fairly intensive. Even then, they miss most
of the really crucial stuff. Remember, all they can do is "advise". They
cannot order you to do anything, although they can write nasty things about
you afterwards. And IMO only a wet behind the ears no-nothing would even
try to advise against multiple sign ons. And only the same would not knock,
umm talk, some business sense into the same said auditor.
Act like you know what your about, explain the why's to them, and they
usually fold.

 

[dkahn]

Re: RE: Re[2]: Session Control

One reason for disallowing multiple sign-ons might be to prevent password sharing. If the user is signed on twice it might be 2 different people using the same ID.

Dave Kahn (World A7.3 cum 10)
=========

 

[jools]

I found this Question and answer on the News 400 website as a technical tip.

Disabling System Request by Gary Guthrie
NEWS/400, February 1999 , pg. 132
Article ID: 6377
Department: Tech Corner
Related Topics: Systems Management


Q: I need to prevent users from using the system request functions to start another session (via option 1 from the System Request menu). How can I do this?

A: To accomplish what you want, revoke authority to the TFRSECJOB (Transfer Secondary Job) command to prevent users from using option 1 from the System Request menu.

I haven't tried it personally since I don't have the correct level of authority on our AS400 but in theory should work.

Analyst Programmer
Hallmark Cards