This is an example of where I was going with the suggestion that new sessions (*DEVDs) might be restricted from use on the AS/400. It might not matter if new .WS files are created if the they result in *DEVDs that can’t be used.

Note, however, that restricting a user to a particular *DEVD has no effect on whether the associated .WS might allow VB macros, which was the point of the question. You can have any number of .WS files that all attach to the same *DEVD.

Tom

Get it formally agreed that it is policy that ALL access to the system is ONLY via the provided desktop icon. Any staff not complying can be subjected to your company’s normal disciplinary procedure – informal warning – written formal warning – sanctions including dismissal, however it goes.

Sounds a bit harsh? maybe, but it would focus the users’ minds!

Johnson

That prevents them from running menu options. It doesn’t prevent them from simply using copy/paste for a .WS file and making any changes they want to the copy. Notepad is all that’s needed.

However — “Defense in depth.” It might be worthwhile just to increase the obstacles by an extra layer.

In a sense, the problem becomes one of having the clever user digging deeper to learn more. It’s not unheard of to have users be more knowledgeable than AS/400 administrators about Windows.

Tom

The users should still have access to data transfer etc. through the buttons on theClient Access menu bar….

Can you describe the parameters that you need to control?

There are two general possible directions.

First, you can try to prevent the creation of new workstation sessions on the PC. I don’t have a good idea how that might be done.

But second, you might be able to control whether or not a new workstation session can be used on your AS/400. The example from Slateken about QAUTOCFG is one potential idea along that line, but there might be other thoughts that are more useful and more precise. It’s possible that the parameters you want to protect will give a clue.

Even if new sessions are created, maybe they can’t be used. That might be a sufficient resolution to your problem. Different parameters might cause a different workstation type — you might be able to reject those when they try to connect.

Tom

The objective is to prevent users from creating another workstation on his pc as earlier workstation parameters are saved and we do not want user to have fresh set of workstation with default parameters as parameters such as within API section to be would get modified.

Hope you have understood.

Johnson

Unless, of course, they connect to WS130 or WS129 or any of the other devices that already exist.

Not only do system values such as QAUTOCFG need to be disabled, but a security structure needs to be implemented and managed to assign and control authorities for all of the various *DEVDs (and device *MSGQs) that probably already exist so that each user can use only appropriate devices.

Tom