× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: AS/400 wish list
  • From: "Evan Harris" <spanner@xxxxxxxxxx>
  • Date: Fri, 10 Mar 2000 08:29:41 +1300

John

Comments in-line

> After reading's L.S. Russell's wish for the INC opcode, I was reminded
> of the features I'd love to see in the OS.

I'm definitely not a fan of either this op-code or the ++ type constructs. I
think ADD is a pretty self document instruction and conveys its intent to
anyone reading the code prettyu explicitly. Isn't this the reason for code ?
I see INC as a horse of another colour and therefore an additional
possibility for ambiguity and effort that coudl be better expended elsewhere
(like in some decent CL programming support)

> 1) Save File support for hte LODRUN command.   This seems simple
> enough, and lends itself to e-commerce by recognizing the fact that
> products can easily be distributed over the net via save files.  Just
> FTP the SAVF to Your AS/400 and perform the LODRUN(*SAVF)
> SAVF(MyLib/MyFile).

Definitely. Not that restore then running a program is that difficult. But
ease of use for the end-user/e-shopper is king isn't it ?

> 2) The Anti-*PUBLIC User Profile.   This is a profile that is not
> allowed to get authority from the *PUBLIC bit in the object.   These
> Anti-*PUBLIC profiles could be used to allow network access without
> opening up access  to every other object on the box.  An Anti-*PUBLIC
> would have to be explicitly authorized to an object in order to use
> it.

Agreed. I'd like to see it expressed as, say,  *TRUSTED and *UNTRUSTED.
*TRUSTED would equate to my old *PUBLIC profiles which I envision those
profiles I have explicitly granted authority to the system to. *UNTRUSTED
would be those kind of profiles that equate to *ANONYMOUS access.

> 3) An Exit Program for the signon screen.   Wouldn't it be Useful to
> be able to intercept the sign-on and pass data to and from the
> screen?.

Oh, yeah ! Shouldnt all the log-on failures be referred back to the same
point ? Curretnly, in my experience, if you want to deny access gracefully
with an explanation, you have to create some kind of self terminating
screen, and further to secure it properly, I suppose you ougt to temporarily
disable access to the System request menu. Just more failure/exposure points
as I see it.

> Is anybody listening?

I am. Let's  hope IBM is.

Cheers
Evan Harris

+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.