|
One of the biggest reasons for this device assignment, if not using
DHCP is to allow users to print reports to a known printer. Some
functions initiate printing from a batch job, basically a NEP, and
users don't have the option of specifying a printer. Maybe that is an
application issue, but it is what it is. The application is not
developed in-house.
John McKee
On Mon, Feb 13, 2012 at 7:16 AM,<rob@xxxxxxxxx> wrote:
> This just sounds like too much work for me. In this day and age of
> laptops I may connect to my system from DHCP address on wire on my desk.
> > From some wireless address in the conference room. From a wireless, or
> wired, address from our corporate office. Or from our VPN access. There's
> no way I'd constantly change my device names on my 5250 sessions to always
> match where I am connecting from. Can you imagine trying to explain that
> logic to some mobile bean counter in accounting?
>
> I wrote our FTP exit point. I used to say that they had to come from a
> particular address (or range). However a vast majority of our trading
> partners could do tricks like IPCONFIG at their DOS prompt (after the 3rd
> day of explanation) but rarely could tell me their NATted address. And
> then I had this 'major customer' whose ftp person was a mobile user,
> including doing work in between her night classes at college.
> Much of this is now handled by our network consultant. And when I told
> him I wanted it opened to the world and we would handle it by user id's
> and passwords he wanted it in writing. Basically we had the same problems
> with the same users. Granted, we may block a range of addresses used by
> certain foreign entities for nefarious purposes. But that I would do at
> the network level. Oh, I'll grant you that there's some argument to be
> made for defense in depth.
>
> Your SA was not a nut. At one time it was a generally accepted practice
> to do such stuff. The IBM i still has a system value to limit which
> terminals QSECOFR can sign on to. The theory being you could limit them
> to the system console. Which would be in a secured room where you could
> keep an eye on what they were doing.
>
> Rob Berendt
> --
> Group Dekko
> Dept 1600
> Mail to: 2505 Dekko Drive
> Garrett, IN 46738
> Ship to: Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From: John McKee<jmmckee@xxxxxxxxxxxxxx>
> To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>,
> Date: 02/12/2012 08:48 PM
> Subject: Re: Modifying an exit point program
> Sent by:midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> This is related to my original question. The sa coded the exit point
> program to examine the first three characters of the device. If they
> were not equal to 'VPN', then the IP address is used to look up a
> device name in a file. No device name means no signon screen is
> allowed. If the first three characters were equal to 'VPN' then the
> device name is check for existance and that the status is VARY ON
> PENDING. If those conditions are met, then signon is allowed.
>
> I tried to find out the origin of this logic. Nobody knows. The only
> thing I learned is that there was speculation that this was for system
> security. The system is not directly connected to the internet. From
> outside, somebody would have to have a login to the corporate office,
> then would have to have access to my facility, and then would have to
> have access to the i itself. Finally, they would need to supply a
> valid, existing device name.
>
> Does the logic that requires a device name starting with "VPN" offer
> any additional security? To me, any additional security that might be
> offered is minima, at best.
>
> What I am left with is to either add multiple additional tests to the
> login exit point program - no idea how many, or remove that validation
> piece. Which was why I asked earlier about adding more tests and if
> "and" worked in free format. Just seems to be making the logic more
> complicated than necessary.
>
> This mess was brought to a head due to the network guys wanting to use
> DHCP for internal new devices. The external devices come throught the
> corporate firewall and get NAT addresses that we are not informed
> about.
>
> Thoughts?
>
> John McKee
>
>
>
> On Fri, Feb 10, 2012 at 1:47 PM, Monnier, Gary<Gary.Monnier@xxxxxxxxx>
> wrote:
>> John,> point. The exit program is only called when a telnet session first
>>
>> Not equal is<>
>>
>> The System does not have to be in a restricted state for the telnet exit
> starts.
>>> normal cautions apply - ownership, authorizations, adopt authority, etc.
>> You can "move" the recreated program into the target library. All the
>> It is much easier to have the object you are going to move match the> target object before you "install" it.
>>> session when you "install" your change.
>> The only difficulty you may encounter is if someone is starting a telnet
>>> mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKee
>> Gary Monnier
>>
>> -----Original Message-----
>> From:midrange-l-bounces@xxxxxxxxxxxx [
>> Sent: Friday, February 10, 2012 11:12 AM> Existing line is testing for first three characters equal to "VPN"
>> To: Midrange Systems Technical Discussion
>> Subject: Modifying an exit point program
>>
>> An exit point program is installed on QIBM_QTG_DEVINIT
>>
>> It contains a single line that needs to be changed. It is free format.
>>> or something else?
>> Questions:
>>
>> 1) What is the not equal operator in free format RPG? Is it != or<>,
>> 2) I recall the discussion on a mediator program. I can't recall if it> was only needed for a data file change, or for any program change.
>> Does system have to be in restricted state to make this change?> changes, or does the exit point have to be dropped an readded?
>> 3) Does recompile of the program into the target library accomplish all
>>> functioned as sa, does not necessarily do this anymore.
>> I ask, since I may be "asked" to make the changes. The person who
>>
>> John McKee
>> --
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.