I will address how I have implemented #1 - end user HOME subdirectories. I use automount. I do this as follows:
In /etc/rc (UNIX startup script), I put the lines: # Start the automount facility /usr/sbin/automount I created the UNIX file /etc/automaster containing the line: /home /etc/home.map I use "/home" as the "home" root subdirectory. Many others use "/u". Modify the above as necessary. In /etc/home.map, I have: name * type ZFS Filesystem TSSPV.PLEX&SYSPLEX..HOME.<uc_name>.ZFS mode rdwr allocuser space(20,10) cyl dataclas(DCSTD) parm FSFULL(70,10) delay 10 duration 10 setuid No I don't need to do much of anything after this. When a user logs into a UNIX shell for the first time, a VSAM zFS filesystem is created and initialized, then mounted. Thereafter, the existing zFS data set is mounted. The "<uc_name>" is replaced by the upper case value of the subdirectory. In the OMVS segment, I have something like: OMVS INFORMATION ---------------- UID= 0000001009 HOME= /home/tsh009 PROGRAM= /bin/sh CPUTIMEMAX= NONE ASSIZEMAX= NONE FILEPROCMAX= NONE PROCUSERMAX= NONE THREADSMAX= NONE MMAPAREAMAX= NONE Unfortunately, this does not lead to easy use of the automatic assignment of an OMVS segment because I end up "hard coding" the HOME and it cannot be coded with some sort of variable. The "<uc_name>" previously mentioned comes from the "/home/tsh009" in the HOME field. Automount strips out the "/home/" portion, then upper cases the remaining "tsh009", so the zFS data set name is TSSPV.PLEXLIH1.HOME.TSH009.ZFS . Note that I, perhaps unnecessarily, include the PLEXLIH1 node. I'm not sure why I really do this. Perhaps due to the "strange" way that I assign temporary space to a UNIX shell user. I can go into that if you like, but basically I use automount to dynamically create a system specific zFS filesystem for each user and "hard code" them to more-or-less force each user to use their own zFS "temporary" file system, instead of generally using the "/tmp" mount point. I do this so that one "greedy" user cannot use up all the UNIX temporary space and thus cause a problem to other UNIX users. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Jousma, David > Sent: Wednesday, October 31, 2012 9:48 AM > To: [email protected] > Subject: JAVA development best practices > > All, > > Looking for some feedback - publications, real world experience, etc on > managing the z/OS environment to support JAVA application development > in our shop. Up until now, JAVA has been a service provider for > systems level(and controlled) functions. > > A couple things come to mind immediately that have never been a real > concern before, and maybe are a pipe dream: > > > 1) Unix Systems Services for the masses - today no one outside of > tech services can get to unix command prompt. I suspect developers > will need their own filesystems, etc. Don't want to make it > complicated or require a lot of administrative overhead. Security? > > 2) Isolating JAVA release levels from applications. Is this > possible? We tend to keep several versions of JAVA available(1.4, > 5,6, and 7) but make the most current, the "default" as in the path in > JAVA_HOME. What I don't want is applications coding for specific > versions(if possible) causing upgrade nightmares. > > 3) Shared file systems. Today we do not share filesystems for > read/write across the lpars in our sysplex. We share sysres > filesystems readonly. Filesystems for write access are system specific > today. > > 4) ?? > > What am I missing? Please share your experiences either on/off list > is fine. Just looking to learn from others and be able to implement > general best practices BEFORE the masses hit the systems. > > Thanks, Dave > > _________________________________________________________________ > Dave Jousma > Assistant Vice President, Mainframe Services [email protected] 1830 > East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f > 616.653.2717 > > This e-mail transmission contains information that is confidential and > may be privileged. > It is intended only for the addressee(s) named above. If you receive > this e-mail in error, please do not read, copy or disseminate it in any > manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the > sender that the message was misdirected. After replying, please erase > it from your computer system. Your assistance in correcting this error > is appreciated. > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
