> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt > Sent: Tuesday, October 18, 2005 11:50 AM > To: [email protected] > Subject: Re: Port to z/OS or OMVS? > > > The USS/OMVS environment offers only a subset of z/os features. More, > things like security, ordinary file activities, and product upkeep is > very different. Being so different complicates everything. > And makes for > a poor business case.
I must disagree that the z/OS UNIX environment only offers a subset. In fact, z/OS UNIX is totally integrated with "legacy" z/OS. E.g. I can read/write HFS resident file from what could be considered a "legacy" program simply by calling the appropriate BPX1xxx subroutine. Of course, there are some considerations, such as it likely being a poor idea to do subtasking using both the ATTACHX macro and the "pthread" BPX1xxx calls. I can also use dynamic allocation in a "UNIX" program and QSAM/BSAM I/O to "legacy" datasets. It is not an XOR operation. It is a true OR operation. Of course, this is definately more difficult for the programmer. So I would likely try to go one way or the other for simplicity's sake. > > Native z/os applications typically command higher prices. But, of > course, the standards are somewhat higher. Not even in the same ball > park when it comes to security. z/OS UNIX programs are just as secure as "legacy" programs. That is, using UNIX services does not suddenly bypass any sort of RACF/ACF2/TSS security that is set up. Nor does it bypass APF authorization. Securing UNIX files is more difficult. But it is possible by using the UNIX "access control list" facility. It is a real pain. I know because I had to do it for an application that I'm helping to write. And it assumes that you have all the appropriate defination for UIDs and GIDs set up. As I said, a PITA, but possible. > > In my limited experience, I have found that native 'nix > applications are > hard to fit into production environments. Many cannot conceive of not > having a human to chat with and 'press any key'. 'nix server > applications sometimes cannot tolerate the required security > constraints. This is true. But it is based on how the application is designed. Since the OP said that they already have the UNIX programs written, I assume that they must know the amount of interaction needed to run them. If they are designed for human input, then they are likely not going to run well in batch. But they may run just fine as something like a CGI program, using the free, built-in, HTTPD server as the "terminal controller". Or with the person logged in to a UNIX shell. > > So, when we go looking for solutions, 'nix based products > don't make the > first cut. I agree. Things that are designed for a specific environment generally run better in that environment than things which were designed for a different environment. Trying to "port" something that currently runs on *nix to run on z/OS is likely going to result in poor performance. Unless steps are taken (expensive) to avoid doing that which is not a z/OS type thing (such as depending on human input for a "batch" type process). -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. ---------------------------------------------------------------------- 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
