Re: Remote Java calls to RPG AS400 programs ? -- MIDRANGE-L

From Alister Macintyre

I am not part of the distinguished group, just someone who knows enough to be 
dangerous.

The remote connection also has a job session virtual device address that may 
default to something like QPDAV000## but there are various places these rules 
can be altered, which I am not up on .... where I work we are using XXX#### 
where the XXX are the initials of the person whose PC is being used & 0001 
0002 0003 etc. is their session sides.  

There is also a unique IP address for that PC that shows up in the DSPLOG 
when the connection is made.  Our PC users get onto our ERP via a password 
check (400 sign on screen) at which point 400 knows their name, but some 
OS/400 functions via CA bypass this & come in as QUSER.

Recently I got a question from one user ... he powers off his PC when he is 
done for the day & every time he returns to work it is powered on again & he 
wants to know how that is happening.  I suspect some other persons using his 
PC when he is not in his office, but I can only identify when sign on 
sessions occurred to the 400 & link what user was using what device, not when 
someone using his PC & not onto 400.

I plan to write for him step by step instructions how to get at DSPLOG 
information in a form that he can search for hits associated with his PC.  
There might even be a future interest in me writing a program for this ... 
user runs program, RTV gets what device that user is running it from, 
identifies recent other connections by that same device.

We could have used that the weekend someone erased all the passwords from the 
CFO's PC.

I am thinking there ought to be some application on the PC or internet 
connection that authorizes permission to access the 400 that captures WHO the 
user is that can be passed to the 400 application, when not using standard 
sign on screen.

I should think that when the Java programmer fires off the call to 400, that 
a set of standard passed parameters should be SECURITY related ... WHO is 
running this, so that if the connection loses the standard ways of 
identification, the 400 software knows ... this is which of our users, it is 
a customer or vendor & which one like in terms of their account #.

Such security would be dependent on the programmers ... you/400 & guys/Java 
... not as good as OS security ... but may be good enough if hackers cannot 
get into the code.

There is a security issue if the Java calls can be made from a web site.  Our 
customers are major OEMs many of which are in competition with each other.
We want customer-A to be able to see information about what we are doing for 
customer-A.  We do not want customer-B to see info about what we are doing 
for customer-C.

There is a sizing questionairre from IBM & major software package suppliers 
to evaluate the kinds of drains on the OS that you anticipate & the level of 
performance you desire for all types of operations, and from this they have 
reccommendations for hardware resources, and this can also tie into 
performance tools.  If you have a type of activity that has started small & 
is about to take off, you may wish to do a performance review ... do you need 
to add resources so this works efficiently as it becomes a big time operation?

What Tim describes as having accomplished could make him a very popular 
person in the larger 400 community if there could be a communication of how 
he did it.  Would his employer permit some kind of shareware or write up in 
the trade press?

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---