On Thu, Apr 22, 2010 at 5:49 PM, Sam Siegel <[email protected]> wrote: > I understand what you are saying and I'm not taking anything personally. > However, I must ask how is one to learn these things. I'm > not pretending to be anything or diminishing the complexity. I thought my > approach was exactly the opposite. Ask for advice from those that know. > I knew that the questions expose my level of experience when I wrote them. > > There must be some way to gain this expertise. >
Ah yes, there's the rub. There IS a way to do it, but as I am fond of saying, it takes approximately 30 years to get 30 years of experience :-) The big problem is that this platform has evolved over 45 years or so. Back when it started out nobody knew about integrity and there wasn't a lot of difference between the programming environment seen by the system and the application. As time passed things got a whole lot more sophisticated and vastly more complex, but the documentation didn't keep up. In the mainframe community there were always two tribes; the systems software tribe (made up of IBM and the ISVs) and everyone else. Within the systems software tribe, the knowledge of the elders was passed around by word of mouth (or by reading microfiche/dumps :-) ) so by and large nobody within IBM really felt there was a need to spell out the how-tos. But fast forward to today and unless you have spent quite a lot of time working in a professional software development environment where this sort of thing is the daily grind, there's just no way to get a complete picture in anything approaching a reasonable amount of time. If I am brutally honest, most of the programmers remaining in the systems software tribe don't really know all the rules anymore (if ever) and don't (or shouldn't) write that kind of code. Aside from the likes of a few well known names from around here, very little of this sort of code is actually being written from whole cloth any more. Mostly it is little changes being grafted onto existing code here and there, so providing the existing code's basic infrastructure is sound the risks are minimized. But even so, there are some giant yawning chasms of exposures out there. They're just not as well known or recognized as they are on other platforms. Security/Integrity through obscurity is more common than anything else. (Oops, did I say that out loud? My bad!) > I believe my product idea is usefully and I want to make sure that it is > also safe. Clearly just writing an authorized only program and not > allowing > a problem state user exit is the preferred way to go. However, if it is > reasonably possible to provide a problem state user exit, I would like to > explore it. > > I'm trying my best to ensure integrity and still create something > marketable. If you and Walt are saying this is impossible outside of IBM or > a > vendor environment like BMC or CA then this is unfortunately. > > It would really be great if the people with the experience and scars would > provide the details required to write this type of application correctly. > I'm open to suggestions and would very much appreciate them. > > Again any advice on how to accomplish this would be greatly appreciated. > Or > a confirmation that this is just not possible regardless of the advice > provided would also be appreciated. It is possible to write this kind of thing, but without the benefit of having someone to look over your shoulder (IMO) there isn't ANY chance of getting it right. Certainly not the first, second or third try. I would personally rule out running unauthorized code within the confines of an authorized address space NO MATTER WHAT. I would not tackle it myself and if I was the person looking over your shoulder, I would just say no. But if you can go to the trouble of setting things up with two address spaces (perhaps by using fork() as Walt suggested, or just a garden variety long running non-APF started task) then you would be at least part way there. The problem that remains is that it turns out to be a mountain of code and setup and you would still have to deal with xmemory serialization, integrity and security issues. So your biggest problem isn't that what you're trying to do is necessarily a bad idea, it is just too big and too hard to tackle as a learning exercise. Now if you could tackle something else smaller and more manageable to get your feet wet first, that would be a good thing. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
