Re: Common Dataspace

2007-12-08 Thread Gibney, Dave
This has become interesting. There are three people (that I've actually met) outside IBM (well another seems to have exited recently) whose opinion I really respect in these levels that are really far outside my current abilities. When two of them argue, I pay attention. Both Shane and Ed's positi

Re: Jeff Foxworthy & IBM

2007-12-08 Thread Martin Packer
"You might write a Redbook if" :-) Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box

Re: DFDSS and Copy of Offline Volumes

2007-12-08 Thread Bruce Hewson
EMC's Infomover product accesses OFFLINE products from the mainframe... and as a result doesn't support dynamic path. Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL

Re: Possible change to MCSOPER processing

2007-12-08 Thread Bruce Hewson
Hello Kevin, We are required to have LOGON REQUIRED on all consoles, including SYSCONS. (HMC Operating System Messages). This allows us to IPL and reply to messages until RACF starts up and locks up the console until you sign in.but, tragically, there is no LOGON command available via SYSCO

Re: Common Dataspace

2007-12-08 Thread Shane
On Fri, 2007-12-07 at 23:38 -0800, Edward Jaffe wrote: > It's a CADS. It's not "in" *MASTER*. It's simply "owned" by *MASTER*. > There's no code running there, and no storage living, there. And, > *MASTER* is the only address space guaranteed for the life of IPL. It's > routinely used for this

Re: Common Dataspace

2007-12-08 Thread Rob Scott
Ed, Not matter how simple it sounds to hang a CADS on *MASTER*'s back like some sort of "KICK ME" sign - if it was up to me to design the software I would endevour to find a less intrusive method (like a CADS-owning STC). Accessing the CADS afterwards would typically require storing the ALET s

Re: Common Dataspace

2007-12-08 Thread Rob Scott
Martin, A couple of reasons spring to mind : (1) Short path length to perform instructions to access data in CADS (load the ALET into ARx, init Rx, SAC 512). If you are in a system exit and your purpose is to intercept and store certain information, you need to do this as quickly as possible a

EC/MCL and PTFs

2007-12-08 Thread Mike Myers
Is there a way of cross-referencing hardware ECs or MCLs to z/OS software versions or PTFs required to successfully run after installation of such hardware changes? Mike Myers Mentor Services Corporation -- For IBM-MAIN subscr

Re: zOS Maintenance Best Practices

2007-12-08 Thread Scott Fagen
On Fri, 7 Dec 2007 10:32:29 -0500, Matt Dazzo <[EMAIL PROTECTED]> wrote: >I'm looking for latest pdf for zOS Maintenance Best Practices. I'd hunt around this area of ibm.com: http://www-03.ibm.com/servers/eserver/zseries/zos/servicetst/ (of course, since the website path hierarchy changes freq

Re: Common Dataspace

2007-12-08 Thread Martin Packer
Can someone explain to me - in this day and age - why we're talking CADS and not Shared Memory Objects (above The Bar). Thanks! Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom

Re: Common Dataspace

2007-12-08 Thread Edward Jaffe
Shane wrote: So ... let's just drop an SRB (which apparently doesn't qualify as "code" ???) in one of (the ???) most important address spaces in the system. Turn on a trace sometime and watch how many SRBs are scheduled into MSTR. Based on your response above, you might want to have a seat

Re: Common Dataspace

2007-12-08 Thread Keith E. Moe
Scheduling an SRB into the Master sure seem to be a touchy subject, I have two observations/comments. First, since the SRB is a unit of work that is independent of any existing dispatchable unit in the Master, any normal error that occurs within it has no impact on any other work in the addres

Re: Common Dataspace

2007-12-08 Thread Edward Jaffe
Martin Packer wrote: Can someone explain to me - in this day and age - why we're talking CADS and not Shared Memory Objects (above The Bar). Depending on your application, 64-bit shared memory may not be a viable replacement for CADS. 64-bit shared memory objects: o Must be explicitly share

Re: Reel to Reel 6250 BPI

2007-12-08 Thread Jeffrey Deaver
Got rid of that hardware just a few years ago. There are companies that specialize in that... http://www.reeltapetransfer.com/ http://www.computer-convert.com/ http://www.datastoragetech.com/tapeconversion.html http://www.pivar.com/ ... can't say I've used any of them, however. Jeffrey Deaver,

Re: Code pages (was: Square Brackets in Java?)

2007-12-08 Thread Joel C. Ewing
Patrick O'Keefe wrote: On Sat, 1 Dec 2007 11:07:06 -0600, Joel C. Ewing <[EMAIL PROTECTED]> wrote: .. I notice your table doesn't mention the "¬" encoding differences between IBM-1140 and IBM-1047, but perhaps that character wasn't relevant in the context of that discussion. ... Once ag

Re: Common Dataspace

2007-12-08 Thread Jim Mulder
IBM Mainframe Discussion List wrote on 12/08/2007 10:45:02 AM: > First, since the SRB is a unit of work that is independent of any > existing dispatchable unit in the Master, any normal error that > occurs within it has > no impact on any other work in the address space. If it abends, it > d

Re: Code pages

2007-12-08 Thread Steve Comstock
Joel C. Ewing wrote: [snip it all] Joel, Here's a few links I've found helpful: http://www-03.ibm.com/servers/eserver/iseries/software/globalization/codepages.html http://www.tachyonsoft.com/cpindex.htm http://www.alanwood.net/unicode/fonts.html http://www.alanwood.net/unicode/index.html http:

REGION=0M and LSQA

2007-12-08 Thread Kenneth J. Kripke
I wish to ask the group on the pitfalls of coding REGION=0m. Is it true that if more storage is needed up to the region cap, VSM will allocate from LSQA? Thanks, Kenneth J. Kripke [EMAIL PROTECTED] -- For IBM-MAIN subscribe

Re: Common Dataspace

2007-12-08 Thread Edward Jaffe
Keith E. Moe wrote: First, since the SRB is a unit of work that is independent of any existing dispatchable unit in the Master, any normal error that occurs within it has no impact on any other work in the address space. If it abends, it doesn't take a TCB with it. (The SRB must still use ap

Re: REGION=0M and LSQA

2007-12-08 Thread Johnny Luo
Never heard of that. Region cap is a up-limit for low private subpools and high private subpools not restriced by it. Of course, low private and high private cannot meet in the middle. On Dec 9, 2007 5:22 AM, Kenneth J. Kripke <[EMAIL PROTECTED]> wrote: > I wish to ask the group on the pitfalls

Contacted for an SMP/E person

2007-12-08 Thread Steve Thompson
I got an email from a head hunter looking for someone to do SMP/E based work for a large retailer located in Arkansas. Here is the crux of what they asked: Minimum 2 years experience with SMPE, System Software Installation & Maintenance, MVS Utilities & JCL Ok, I've already responded to them th

Re: REGION=0M and LSQA

2007-12-08 Thread Steve Thompson
As a general observation: In the Private area (as opposed to X-Private), your storage is obtained starting at the bottom of your space going toward the top. System control blocks needed for servicing your address space are obtained in LSQA (Local System Queue Area) which is at the top of your P

ISVs and their sins: was Common Dataspace

2007-12-08 Thread Shane
On Sat, 2007-12-08 at 03:42 -0800, Gibney, Dave wrote: > Where does the stuff CAS9 leaves around anchor? As a Natural/Adabas > shop, we run their "global buffer pool" (which will (at this time) > require me to allow common user key 8). How/where do I check on it's > anchor point. G'day Dave. The

Re: ISVs and their sins: was Common Dataspace

2007-12-08 Thread Gibney, Dave
Thanks Shane, MXI is on my list of to-do's. Unfortunately it's fairly well down on the priority list. :) And it seems that I now work at a place on the 3 to 5 year ERP and then no mainframe plan. :( > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On