Re: Signon Screen for Individual Workstations

Michael Ryan wrote:

I probably will. The only sticking point for me (and I knows it's not
technical), is that this is the only real differentiator. Processing
is the same, data is the same, report headings may be different but
that's about it. So from a work management standpoint, a separate
subsystem isn't needed. But...my question wasn't about work
management. :)

Michael:

A subsystem can have a library associated with it:

==> chgsbsd MySbsD syslible( MySbsLib )

This library is intended to be for language support, so it's a little risky trying to use it for other purposes. (But it works.) The library seems to be added at the top of the system portion of the library list. Perhaps this would allow a single DSPF to display different message texts in different subsystems. (I've never tried.)

That doesn't help you much, but it might help you think about how "unneeded" work management objects can be used in customizing areas of configurations.

True, they can be "unneeded"; but multiple subsystems can also be the easiest ways to get things done. As such, they might also go a long ways towards making _other_ objects "unneeded". If you could do it by having one *SBSD per company rather than a different *FILE/DSPF plus one or two other objects per company, how would you decide which technique had fewer "unneeded" objects?

Tom Liotta

On 8/17/07, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx> wrote:

So why not set up a different subsystem for each company?

Then stick a routing entry in the subsystem to forward the job (just as
soon as they sign on) to a different subsystem if you want them all to
run as one...?

This seems very easy and solves your problem exactly (and Ken already
suggested it). I wonder why you don't want to use this option?

Michael Ryan wrote:

And I'm probably using that same concept...message file? But it's
still specific to a subsystem AFAIK. IOW, the display file or message
file doesn't know which device it's on.