Re: Need a way to syntax check IDCAMS control cards
Hi Ant, we use CA-JCLCHECK which also checks IDCAMS statements, but we're not at 1.11 yet. Regards, Mark. Mark Darvodelsky | Systems Engineer | Mainframe Systems | Hosting | BT Infrastructure | Business Technology | Suncorp | +61 (0)2 9978 9081 +61 (0)418 249 176 | mark.darvodel...@suncorp.com.au | IPC: 2BT074 | Level 7, 465 Victoria Ave, Chatswood, NSW, 2067 | www.suncorp.com.au -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Anthony Thompson Sent: Wednesday, 16 December 2009 13:08 To: IBM-MAIN@bama.ua.edu Subject: Re: Need a way to syntax check IDCAMS control cards Do you have a JCL syntax-checking software product? I know of a couple that will also check IDCAMS sysin statements (and other utility control cards) SmartJCL by HorizonT JED by DCMS We have SmartJCL, but it's not quite up to speed with the z/OS 1.11 enhancements (like the new MASK parm to the IDCAMS DELETE command). Cheers, Ant. Northern Territory Government -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Duane Reaugh Sent: Tuesday, 15 December 2009 7:14 AM To: IBM-MAIN@bama.ua.edu Subject: Need a way to syntax check IDCAMS control cards Does anyone know a way to get IDCAMS to syntax check (but not run) a set of control cards. Sort of a TYPERUN=HOLD but for control cards. The only way we have found is to put a "IF LASTCC = 4 THEN DO" statement in front but we are looking for a more elegant solution. IF LASTCC = 4 THEN DO DELETE RAY.GARB.TEST DELETE ENT(GARB.TEST3) EELETE RAY.GARB.TEST2 LISTCAT ENTRY(TOM.A) XXL LISTCAT ENTRY(TOM.A) XXX LISTCAT ENTRY(TOM.A) ALL This generates errors for cards 3,4 & 5 but misses the contextual error in card 2 and nothing is deleted or listed Thanks Duane Reaugh DTS Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
old manuals
Hi, Does anyone still have any copies of the old Syncsort product manuals from before about 1994 to 96? A friend of mine has asked me if I could help locate one for him and I told him that I would post to the forum to see. He said that he is working with a site that is running 1 application on a processor that is quite backlevel and still running syncsort release 3.5 and he is trying to find out where things are and how to use them. I pointed him to the current manuals but he said that while it was better than what he already has (nothing) that it would help him if he had some from about that time. He said that they are apparently using the old Syncsort to parse some data before it goes into a SAS process, apparently (according to him) SAS didn't process large numbers of these types of records very well back then so they apparently use Syncsort to process them in a single pass, (which is the part he needs to alter). Please send me a email if you have one you can spare a copy of. Brian Brian_Westerman at SyzygyInc.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Need a way to syntax check IDCAMS control cards
Do you have a JCL syntax-checking software product? I know of a couple that will also check IDCAMS sysin statements (and other utility control cards) SmartJCL by HorizonT JED by DCMS We have SmartJCL, but it's not quite up to speed with the z/OS 1.11 enhancements (like the new MASK parm to the IDCAMS DELETE command). Cheers, Ant. Northern Territory Government -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Duane Reaugh Sent: Tuesday, 15 December 2009 7:14 AM To: IBM-MAIN@bama.ua.edu Subject: Need a way to syntax check IDCAMS control cards Does anyone know a way to get IDCAMS to syntax check (but not run) a set of control cards. Sort of a TYPERUN=HOLD but for control cards. The only way we have found is to put a "IF LASTCC = 4 THEN DO" statement in front but we are looking for a more elegant solution. IF LASTCC = 4 THEN DO DELETE RAY.GARB.TEST DELETE ENT(GARB.TEST3) EELETE RAY.GARB.TEST2 LISTCAT ENTRY(TOM.A) XXL LISTCAT ENTRY(TOM.A) XXX LISTCAT ENTRY(TOM.A) ALL This generates errors for cards 3,4 & 5 but misses the contextual error in card 2 and nothing is deleted or listed Thanks Duane Reaugh DTS Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
>Now, let's assume that you do not have permission to that file. BUT, you know that if you build a "long name" that uses your userid as the HLQ and prepend that to the DSN, you will cause SAF to be passed the LONG name, not the real name, and this will allow you, via volume specific allocation, to now read that data (or write to the file). What makes you think that, if implemented, this hole would exist? For example, I would insist on ALTER access before you could create the alias. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S306-30
>Does IKJEFT01 require a TSO segment? I would say NO. I've written many REXX EXEC's for implementation through CA-7 & CTL-M. The production id's never had TSO segments and all was well. ACF2 & RACF -- never used TOP SECRET. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
On Tue, 15 Dec 2009 15:07:13 -0600, Kline, Martin wrote: > >I suppose if I were to assume that the SYSDSN enqueue could never be coded >to handle greater than 44 character dsnames, then I see what you mean. On >the other hand, maybe the enqueue could be coded to use exact length of >dsname or a higher fixed length. > Aren't all RNAMES 256 characters? (I ask without RTFM.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kline, Martin Sent: Tuesday, December 15, 2009 3:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names? I'm glad you pointed that out, but I'm not sure why there's an assumption that this is the only possible implementation. Of course security is a consideration. How it could be managed is entirely open. It isn't. That's what I came up with in under 2 minutes. I normally don't think like a cracker, but part of my job includes foiling them. >Without a tape system, this is a back door into reading tape data that >is not yours, if the tape label is 17 characters long. Is this different from the same issue today? Only used as an example of why I came up with the idea that I did. I suppose if I were to assume that the SYSDSN enqueue could never be coded to handle greater than 44 character dsnames, then I see what you mean. On the other hand, maybe the enqueue could be coded to use exact length of dsname or a higher fixed length. Also, if someone wants 'to cause a problem,' they should be willing to go job hunting and let a more qualified person take their position. When you are a developer, you get to experience what Robert Heinlein said: "It is impossible to make anything foolproof, because fools are so ingenious." And then you get to throw in the crackers that enjoy breaking systems to prove they are smarter than you, or to actually cause problems by some type of theft. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3592 Cartridges
The TS7720 is a tapeless VTS. The TS7740 is the VTS with backend tape drives Sent from my iPhone On 2009-12-15, at 2:38 PM, Hal Merritt wrote: I'm confused. I thought management of the physical tape was a function of the TS7720. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of George Rodriguez Sent: Monday, December 14, 2009 11:10 AM To: IBM-MAIN@bama.ua.edu Subject: 3592 Cartridges I've got a VTL (TS7720) and 2 3592 tape drives. A rexx exec was written, to use DFSMSdss to back up volumes for disk to the 3592. The problem is that the job is divided into 4 parts because of the step limitation. Is there a way of keeping the tape mounted and at the same position after job 1 completes? Thanks in advance. . . George Rodriguez Specialist II - IT Solutions Application Support / Quality Assurance PX - 47652 (561) 357-7652 (office) (561) 707-3496 (mobile) School District of Palm Beach County 3348 Forest Hill Blvd. Room B-332 West Palm Beach, FL. 33406-5869 Florida's Only A-Rated Urban District For Five Consecutive Years -- --Palm Beach County Schools- Rated "A" by the Florida Department of Education 2005-2009 -Home of Florida's first LEED Gold Certified School- ---http://www.palmbeachschools.org- The District of Palm Beach County is an Equal Education Opportunity Provider and Employer. Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
>Let me point out two possible security risks. >Assume that the real file name is 44 characters long and that is the way >it is held in the VTOC. >Now, let's assume that you do not have permission to that file. BUT, you >know that if you build a "long name" that uses your userid as the HLQ >and prepend that to the DSN, you will cause SAF to be passed the LONG >name, not the real name, and this will allow you, via volume specific >allocation, to now read that data (or write to the file). I'm glad you pointed that out, but I'm not sure why there's an assumption that this is the only possible implementation. Of course security is a consideration. How it could be managed is entirely open. >Without a tape system, this is a back door into reading tape data that >is not yours, if the tape label is 17 characters long. Is this different from the same issue today? >The only way out of this is to set a bit (probably in the model 1 DSCB) >that shows that the 44 characters is the REAL name, not truncated, and >have the security system do a VTOC look aside (for lack of a better >name). I assume this is going back to the first issue you have with VTOCs. Yes, Using a VTOC flag is a possible solution. >Now, let us say that you want to cause a problem for the system. So you >pick a data set that is 44 characters long. You prepend your userid, and >under TSO you do an allocate with OLD. ENQUEUE SYSDSN will be for the 44 >characters. You see where this is going? I suppose if I were to assume that the SYSDSN enqueue could never be coded to handle greater than 44 character dsnames, then I see what you mean. On the other hand, maybe the enqueue could be coded to use exact length of dsname or a higher fixed length. Also, if someone wants 'to cause a problem,' they should be willing to go job hunting and let a more qualified person take their position. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Writing Mainframe Executive magazine article on IBM's System z Solution Series
IBM's System z Solution Series consists of several integrated hardware, software and services packages that help deploy new enterprise workloads such as data warehousing, electronic payments, and disaster recovery. The most recently announced was IBM System z Solution Edition for Enterprise Linux: http://www-03.ibm.com/systems/z/solutions/editions/linux.html I'd like to talk to sites with experience evaluating/deploying any of these editions. Please copy replies to me so they're not lost in list digests. Thanks... -- Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042g...@gabegold.com LinkedIn: http://www.linkedin.com/in/gabegold -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Logging of PDS(E) member opens ???
Does anyone have code that will log access to PDS members by jobname, stepname, etcetera, or suggestions as to how to develop such code, or model code that could be used as a starting point ? I'm running at the z/OS 1.10 level, soon moving to 1.11. I've scanned the SMF manual for a record type that has that type of detail but I don't see it. If I had a method that would log all opens down to the PDS member level, that would satisfy the requirement. Regards Lorne Dudley Queen's University Kingston, Ontario -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3592 Cartridges
I'm confused. I thought management of the physical tape was a function of the TS7720. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of George Rodriguez Sent: Monday, December 14, 2009 11:10 AM To: IBM-MAIN@bama.ua.edu Subject: 3592 Cartridges I've got a VTL (TS7720) and 2 3592 tape drives. A rexx exec was written, to use DFSMSdss to back up volumes for disk to the 3592. The problem is that the job is divided into 4 parts because of the step limitation. Is there a way of keeping the tape mounted and at the same position after job 1 completes? Thanks in advance. . . George Rodriguez Specialist II - IT Solutions Application Support / Quality Assurance PX - 47652 (561) 357-7652 (office) (561) 707-3496 (mobile) School District of Palm Beach County 3348 Forest Hill Blvd. Room B-332 West Palm Beach, FL. 33406-5869 Florida's Only A-Rated Urban District For Five Consecutive Years -- --Palm Beach County Schools- Rated "A" by the Florida Department of Education 2005-2009 -Home of Florida's first LEED Gold Certified School- ---http://www.palmbeachschools.org- The District of Palm Beach County is an Equal Education Opportunity Provider and Employer. Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
On 15 Dec 2009 09:49:53 -0800, kees.vern...@klm.com (Vernooij, CP - SPLXM) wrote: >Finally your local need can be easily beaten down: it will probably come >from the same users that start complaining when they have to invent a >password longer than 6 characters. By the time they are fully willing to >generate 44 character passwords and use them without complaining, I >would say then we can consider taking their business case seriously. Who >really has the need to create Let's expand on that. For security, all users should have a different, unique, random 44 character password for each application and web page they visit - provided they remember their User name. Don't let them write the password down. Don't let them use software to "cheat". And when they fail, it's their fault, not ours. Or maybe we need to revisit the business case analysis, remembering that people are people.Not just for user passwords, but for technical users as well. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
>Wouldn't that risk exist with the current IDCAMS ALIAS facility? >Isn't SAF checking done on the actual (VTOC) data set name, not on the alias? Tyhe answer is YES. Resolve, then check. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BCPii and z890
Excerpt from z/OS MVS Programming: Callable Services for High-Level Languages - Document Number SA22-7613-05 " 6.1.1.1.1 Levels of Hardware BCPii Supports The HWIBCPII address space, which supports the issuing of BCPii APIs from a z/OS image, runs on any level of hardware that supports the level of the z/OS operating system in which BCPii is included. . . . The HWICMD service is only allowed to be targeted to at least a System z9® hardware level running on a particular microcode level." Bob Shannon wrote: BCPii is supposed to work on any CEC supported by z/OS 1.1, which means z900 or later. So yes, your z890 should be fine. Z890 is not supported. A z9 or higher is required. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Martin Kline Sent: Tuesday, December 15, 2009 9:40 AM To: IBM-MAIN@bama.ua.edu Subject: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names? I'm just throwing this idea on the table, and expect either little interest or strong opposition. What if catalog support allowed ALIAS names to exceed 44 characters? First, yes, I did search the archives. Second, Yes I understand the implications. The cost and impact of supporting long alias names (though still not small) would be considerably less than the cost of expanding actual data set names. I just came up with this before my second cup of coffee, so the idea is still cooking. Let me point out two possible security risks. Assume that the real file name is 44 characters long and that is the way it is held in the VTOC. Now, let's assume that you do not have permission to that file. BUT, you know that if you build a "long name" that uses your userid as the HLQ and prepend that to the DSN, you will cause SAF to be passed the LONG name, not the real name, and this will allow you, via volume specific allocation, to now read that data (or write to the file). Without a tape system, this is a back door into reading tape data that is not yours, if the tape label is 17 characters long. The only way out of this is to set a bit (probably in the model 1 DSCB) that shows that the 44 characters is the REAL name, not truncated, and have the security system do a VTOC look aside (for lack of a better name). Now, let us say that you want to cause a problem for the system. So you pick a data set that is 44 characters long. You prepend your userid, and under TSO you do an allocate with OLD. ENQUEUE SYSDSN will be for the 44 characters. You see where this is going? Just a few thoughts on this idea. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
All the time when reading your idea, besides thinking of several other complications, I was wondering: why? Finally your local need can be easily beaten down: it will probably come from the same users that start complaining when they have to invent a password longer than 6 characters. By the time they are fully willing to generate 44 character passwords and use them without complaining, I would say then we can consider taking their business case seriously. Who really has the need to create dsn=this_is_the_dataset_with_the_december_2009_production_figures_for_wh ich_I_really_could_not_think_of_a_compacter_name. If you really can't resist and need more complications, create a USS file. Kees. "Martin Kline" wrote in message news:... > I'm just throwing this idea on the table, and expect either little interest or > strong opposition. What if catalog support allowed ALIAS names to exceed 44 > characters? > > First, yes, I did search the archives. Second, Yes I understand the > implications. > > The cost and impact of supporting long alias names (though still not small) > would be considerably less than the cost of expanding actual data set names. > > I just came up with this before my second cup of coffee, so the idea is still > cooking. > > Last time I checked, the impact to IDCAMS and catalog records would mostly > involve relaxing the syntax restrictions. The impact to JCL conversion would > be similar. JCL processing would have to allow for longer names prior to > catalog search, and actual (shorter) names could be stored in places like the > JFCB. Certain SMF records might have to change. > > Expanding a little bit, SMS processing could potentially define long names as > aliases automatically and generate actual names using some schema like > temporary name generation. Doing this would mask the effort of mapping long > and short names from the end user, effectively allowing long names without > any special user changes. > > As for a business case to get IBM to implement- oh well. It was just a thought. > > As a local business case - There are those twice-a-year instances when users > can't seem to create a meaningful and acceptable name in under 45 > characters. So, I guess I won't be creating any usermods today . . . but if I > still had those microfiche . . . > > > >Subject: Re: IDC3203IITEM 'xxx' DOES NOT ADHERE TO RESTRICTIONS > >From: "McKown, John" > >Reply-To: IBM Mainframe Discussion List > >Date: Mon, 14 Dec 2009 10:10:14 -0600 > > >Not likely to be done. That would require a complete rewrite of the VTOC. > >The DSN is a 44 byte hardware key in the VTOC. I cannot imagine how IBM > >would ever compatibly change the DSN length. Short of creating an entirely > >new, incompatable, interface where something (perhaps in the record which > >points to the VTOC) indicates that this is a "new VTOC" formatted volume. > >And that would require updates to the entire world. Who's gonna pay? I'd > >rather they support SAN DASD in z/OS (which means FBA). > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [TSO-REXX] problem w/ "allocate" cmnd within a REXX
X-POST to IBMMAIN and TSO/REX Tuco, You may need to force the volume to NONSMS if the volume TGTVOL (in your case DSSUT1) is a non sms managed volume. Which means you would need to code STORCLAS and MGMTCLAS appropriately (not necessarily DATACLAS). If it is a managed volume in SMS, then you may have another issue, like the dataset cannot allocate in that pool. Check with your storage admin to see what you need to use for this process. Lizette >From: "Bonno, Tuco" wrote: > >I am trying to execute an ALLOCATE cmnd from within a rexx, as follows: >the REXX: >pars arg OUTDSN TGTVOL > ….. >“ALLOCATE DA(“OUTDSN”) SPACE(…) CYLINDERS …. VOLUME(“TGTVOL”) >“ > >my calling stmnt: >xyzrexx abc.def.ds DSSUT1 > >the dataset gets allocated correctly, but not on pack DSSUT1; it gets >allocated on an sms-managed pack >I have researched this in the 1.9 _tso_command_reference_ manual, which says >as follows: > > >“Allocating non-SMS-managed data sets With SMS, you can specify DATACLAS to >allocate non-SMS-managed data sets. You cannot, however, use the STORCLAS and >MGMTCLAS operands. STORCLAS and MGMTCLAS determine whether a data set is >managed by SMS.” > >- but there’s no further info on HOW to use DATACLAS to bypass sms. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
The BCS itself is just another KSDS. The code directly accessing the BCS limits itself to using 45-byte keys. That is obviously part of what would have to change. The 45-byte catalog key (44 for DSN and 1 to indicate an extension record) is not dictated by some universal law. It is merely a number chosen to correspond with the 'standard' data set name length. One option that comes to mind is to utilize the extension byte values x'F1'-x'FF' in some manner. Another is to allow longer catalog keys. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Staller, Allan Sent: Tuesday, December 15, 2009 9:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names? How do you get around the 44 byte key length restriction (for compatability) on catalogs? I'm just throwing this idea on the table, and expect either little interest or strong opposition. What if catalog support allowed ALIAS names to exceed 44 characters? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Martin Kline Sent: Tuesday, December 15, 2009 9:40 AM To: IBM-MAIN@bama.ua.edu Subject: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names? I'm just throwing this idea on the table, and expect either little interest or strong opposition. What if catalog support allowed ALIAS names to exceed 44 characters? First, yes, I did search the archives. Second, Yes I understand the implications. The cost and impact of supporting long alias names (though still not small) would be considerably less than the cost of expanding actual data set names. I just came up with this before my second cup of coffee, so the idea is still cooking. Last time I checked, the impact to IDCAMS and catalog records would mostly involve relaxing the syntax restrictions. The impact to JCL conversion would be similar. JCL processing would have to allow for longer names prior to catalog search, and actual (shorter) names could be stored in places like the JFCB. Certain SMF records might have to change. Expanding a little bit, SMS processing could potentially define long names as aliases automatically and generate actual names using some schema like temporary name generation. Doing this would mask the effort of mapping long and short names from the end user, effectively allowing long names without any special user changes. As for a business case to get IBM to implement- oh well. It was just a thought. As a local business case - There are those twice-a-year instances when users can't seem to create a meaningful and acceptable name in under 45 characters. So, I guess I won't be creating any usermods today . . . but if I still had those microfiche . . . >Subject: Re: IDC3203IITEM 'xxx' DOES NOT ADHERE TO RESTRICTIONS >From: "McKown, John" >Reply-To: IBM Mainframe Discussion List >Date: Mon, 14 Dec 2009 10:10:14 -0600 >Not likely to be done. That would require a complete rewrite of the VTOC. >The DSN is a 44 byte hardware key in the VTOC. I cannot imagine how IBM >would ever compatibly change the DSN length. Short of creating an entirely >new, incompatable, interface where something (perhaps in the record which >points to the VTOC) indicates that this is a "new VTOC" formatted volume. >And that would require updates to the entire world. Who's gonna pay? I'd >rather they support SAN DASD in z/OS (which means FBA). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Need a way to syntax check IDCAMS control cards
I am not aware of one on Z/OS on VSE it works like this // EXEC IDCAMS,SIZE=AUTO,PARM='SYNCHK' yse I know that didn't help Duane Reaugh To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List Need a way to syntax check IDCAMS control cards 12/14/2009 11:11 PM Please respond to IBM Mainframe Discussion List Does anyone know a way to get IDCAMS to syntax check (but not run) a set of control cards. Sort of a TYPERUN=HOLD but for control cards. The only way we have found is to put a "IF LASTCC = 4 THEN DO" statement in front but we are looking for a more elegant solution. IF LASTCC = 4 THEN DO DELETE RAY.GARB.TEST DELETE ENT(GARB.TEST3) EELETE RAY.GARB.TEST2 LISTCAT ENTRY(TOM.A) XXL LISTCAT ENTRY(TOM.A) XXX LISTCAT ENTRY(TOM.A) ALL This generates errors for cards 3,4 & 5 but misses the contextual error in card 2 and nothing is deleted or listed Thanks Duane Reaugh DTS Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S306-30
I moved this discussion to RACF-L and failed to indicate here. My bad. We are almost there and results will be posted both places. Thank you for your help and suggestions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
On Tue, 15 Dec 2009 09:39:51 -0600, Martin Kline wrote: > >Expanding a little bit, SMS processing could potentially define long names as >aliases automatically and generate actual names using some schema like >temporary name generation. Doing this would mask the effort of mapping long >and short names from the end user, effectively allowing long names without >any special user changes. Automatically generating the real dsname would be difficult because RACF checking is done with the real name. You'd have to generate a dsname that matched any profiles. Maybe even profiles that will be defined tomorrow -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
On Tue, 15 Dec 2009 11:51:51 -0600, Paul Gilmartin wrote: >Wouldn't that risk exist with the current IDCAMS ALIAS facility? >Isn't SAF checking done on the actual (VTOC) data set name, not >on the alias? > Correct, gil. The alias has no relevance for security purposes. His point about long names causing problems on tapes is, of course, true, but that applies to any tape data set name longer than 17 characters, in the absence of a tape manager or of RACF TAPEVOL profiles with TVTOCs. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
problem w/ "allocate" cmnd within a REXX
cross-posting to tso-rexx, ibm-main. environemtn here is z/os 1.9 I am trying to execute an ALLOCATE cmnd from within a rexx, as follows: the REXX: pars arg OUTDSN TGTVOL ….. “ALLOCATE DA(“OUTDSN”) SPACE(…) CYLINDERS …. VOLUME(“TGTVOL”) “ my calling stmnt: xyzrexx abc.def.ds DSSUT1 the dataset gets allocated correctly, but not on pack DSSUT1; it gets allocated on an sms-managed pack I have researched this in the 1.9 _tso_command_reference_ manual, which says as follows: “Allocating non-SMS-managed data sets With SMS, you can specify DATACLAS to allocate non-SMS-managed data sets. You cannot, however, use the STORCLAS and MGMTCLAS operands. STORCLAS and MGMTCLAS determine whether a data set is managed by SMS.” - but there’s no further info on HOW to use DATACLAS to bypass sms. so …. does anyone have any know how to do this: how do you bypass SMS when running an ALLOCATE command from within a rexx? ( I don’t have this problem when using ispf 3.2 or batch br14 to allocate datasets …. ) thanks in advance /s/ tuco bonno graduate, College of Conflict Management; University of Southeast Asia; "I partied on the Ho Chi Minh Trail - tiến lên !! "
Re: Is there a "system programming" library for C++?
2009/12/13 Timothy Sipples : > > This would be a good area to document at the Open Source Software for z/OS > Wiki, wouldn't it? That Wiki can be found here: > http://www.oss4zos.org > Last time I looked, neither IBM's XL C/C++ compiler and run time, nor the Dignus C/C++ product was open source. So I'm missing the point here, I think. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
Chase, John wrote: It would seem that if Neon prevails, IBM's marketing credibility will be reduced to that of politicians seeking (re-)election to high office. I don't think a loss to NEON would reflect negatively on IBM's credibility. It would dramatically change how System z software is priced. "Free" software execution on specialty engines will all but disappear unless IBM is successful at developing a way to differentiate and quantify Eligible execution from that which is not Eligible using SMF. -- Edward E Jaffe Chief Technology Officer Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
On Tue, Dec 15, 2009 at 9:55 AM, Howard Brazee wrote: > On 15 Dec 2009 05:23:16 -0800, jch...@ussco.com (Chase, John) wrote: > > >It would seem that if Neon prevails, IBM's marketing credibility will be > >reduced to that of politicians seeking (re-)election to high office. > > I think you exaggerate.It will only be reduced to the level of > that Tiger would have if he told us he never looked at another woman. > Their lawyers must have a hard time sitting or walking around with a set like that on them. Maybe they use wheelbarrows? -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
I've wanted long names for decades, but I've never been able to convert my want into a business need. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Martin Kline Sent: Tuesday, December 15, 2009 10:40 AM To: IBM-MAIN@bama.ua.edu Subject: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names? I'm just throwing this idea on the table, and expect either little interest or strong opposition. What if catalog support allowed ALIAS names to exceed 44 characters? First, yes, I did search the archives. Second, Yes I understand the implications. The cost and impact of supporting long alias names (though still not small) would be considerably less than the cost of expanding actual data set names. I just came up with this before my second cup of coffee, so the idea is still cooking. Last time I checked, the impact to IDCAMS and catalog records would mostly involve relaxing the syntax restrictions. The impact to JCL conversion would be similar. JCL processing would have to allow for longer names prior to catalog search, and actual (shorter) names could be stored in places like the JFCB. Certain SMF records might have to change. Expanding a little bit, SMS processing could potentially define long names as aliases automatically and generate actual names using some schema like temporary name generation. Doing this would mask the effort of mapping long and short names from the end user, effectively allowing long names without any special user changes. As for a business case to get IBM to implement- oh well. It was just a thought. As a local business case - There are those twice-a-year instances when users can't seem to create a meaningful and acceptable name in under 45 characters. So, I guess I won't be creating any usermods today . . . but if I still had those microfiche . . . >Subject: Re: IDC3203IITEM 'xxx' DOES NOT ADHERE TO RESTRICTIONS >From: "McKown, John" >Reply-To: IBM Mainframe Discussion List >Date: Mon, 14 Dec 2009 10:10:14 -0600 >Not likely to be done. That would require a complete rewrite of the VTOC. >The DSN is a 44 byte hardware key in the VTOC. I cannot imagine how IBM >would ever compatibly change the DSN length. Short of creating an entirely >new, incompatable, interface where something (perhaps in the record which >points to the VTOC) indicates that this is a "new VTOC" formatted volume. >And that would require updates to the entire world. Who's gonna pay? I'd >rather they support SAN DASD in z/OS (which means FBA). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
Attitudes like this are part of what is pushing folks away from z/OS onto other platforms. Saying that "This is the way it always has been and we don't want to change" will make folks move, and NOT to USS but to 'real' UNIX or LINUX platforms. My $.02 Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Tuesday, December 15, 2009 10:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names? All the time when reading your idea, besides thinking of several other complications, I was wondering: why? Finally your local need can be easily beaten down: it will probably come from the same users that start complaining when they have to invent a password longer than 6 characters. By the time they are fully willing to generate 44 character passwords and use them without complaining, I would say then we can consider taking their business case seriously. Who really has the need to create dsn=this_is_the_dataset_with_the_december_2009_production_figures_for_wh ich_I_really_could_not_think_of_a_compacter_name. If you really can't resist and need more complications, create a USS file. Kees. "Martin Kline" wrote in message news:... > I'm just throwing this idea on the table, and expect either little interest or > strong opposition. What if catalog support allowed ALIAS names to exceed 44 > characters? > > First, yes, I did search the archives. Second, Yes I understand the > implications. > > The cost and impact of supporting long alias names (though still not small) > would be considerably less than the cost of expanding actual data set names. > > I just came up with this before my second cup of coffee, so the idea is still > cooking. > > Last time I checked, the impact to IDCAMS and catalog records would mostly > involve relaxing the syntax restrictions. The impact to JCL conversion would > be similar. JCL processing would have to allow for longer names prior to > catalog search, and actual (shorter) names could be stored in places like the > JFCB. Certain SMF records might have to change. > > Expanding a little bit, SMS processing could potentially define long names as > aliases automatically and generate actual names using some schema like > temporary name generation. Doing this would mask the effort of mapping long > and short names from the end user, effectively allowing long names without > any special user changes. > > As for a business case to get IBM to implement- oh well. It was just a thought. > > As a local business case - There are those twice-a-year instances when users > can't seem to create a meaningful and acceptable name in under 45 > characters. So, I guess I won't be creating any usermods today . . . but if I > still had those microfiche . . . > > > >Subject: Re: IDC3203IITEM 'xxx' DOES NOT ADHERE TO RESTRICTIONS > >From: "McKown, John" > >Reply-To: IBM Mainframe Discussion List > >Date: Mon, 14 Dec 2009 10:10:14 -0600 > > >Not likely to be done. That would require a complete rewrite of the VTOC. > >The DSN is a 44 byte hardware key in the VTOC. I cannot imagine how IBM > >would ever compatibly change the DSN length. Short of creating an entirely > >new, incompatable, interface where something (perhaps in the record which > >points to the VTOC) indicates that this is a "new VTOC" formatted volume. > >And that would require updates to the entire world. Who's gonna pay? I'd > >rather they support SAN DASD in z/OS (which means FBA). > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
On Tue, 15 Dec 2009 11:21:07 -0500, Thompson, Steve wrote: > >Let me point out two possible security risks. > >Assume that the real file name is 44 characters long and that is the way >it is held in the VTOC. > >Now, let's assume that you do not have permission to that file. BUT, you >know that if you build a "long name" that uses your userid as the HLQ >and prepend that to the DSN, you will cause SAF to be passed the LONG >name, not the real name, and this will allow you, via volume specific >allocation, to now read that data (or write to the file). > Wouldn't that risk exist with the current IDCAMS ALIAS facility? Isn't SAF checking done on the actual (VTOC) data set name, not on the alias? >Now, let us say that you want to cause a problem for the system. So you >pick a data set that is 44 characters long. You prepend your userid, and >under TSO you do an allocate with OLD. ENQUEUE SYSDSN will be for the 44 >characters. You see where this is going? > That problem exists now; additional use of aliases would only aggravate it. By experiment, if my job contains a DD statement for an alias, a SYSDSN ENQ is issued for the alias at job initiation. At step initiation, a catalog lookup is performed and an ENQ is attempted for the RELATED name, without WAIT. Failure of that ENQ is lethal (JCL ERROR? I forget exactly.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S306-30
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin > Sent: Tuesday, December 15, 2009 9:22 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: S306-30 > > On Tue, 15 Dec 2009 07:56:36 -0600, Daniel McLaughlin wrote: > > > >Last bugaboo...EXEC gets (-3) executing the RACF ALU > command. My guess is > >because of running IRXJCL V. IKJEFT01. I'm also guessing > that since the > >batch ID has no TSO segment that ADDRESS TSO wouldn't help. > > > TSO segment has little to do with it: ADDRESS TSO is simply > unavailable > under IRXJCL regardless. (Well, barring the byzantine > ADDRESS SYSCALL spawn > of an EXEC which could issue the Unix-peculiar flavor of ADDRESS TSO.) > > >Suggestions? (Going to try IKJEFT01 and see what happens.) > > > Does IKJEFT01 require a TSO segment? > > -- gil No. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
How do you get around the 44 byte key length restriction (for compatability) on catalogs? I'm just throwing this idea on the table, and expect either little interest or strong opposition. What if catalog support allowed ALIAS names to exceed 44 characters? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
On Tue, 2009-12-15 at 10:39 -0500, Martin Kline wrote: > As a local business case - There are those twice-a-year instances when users > can't seem to create a meaningful and acceptable name in under 45 > characters. We have some automation that archives datasets, producing a snapshot copy of DATA.SET.NAME to e.g. HLQ.DATA.SET.NAME.Dddd.Tttt. That 44-byte DSN constraint can be irritating. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFRMM removing VOLSER
Mark, What command have you tried and what was the result? Any error message? command return code? The simplest way to delete a volume, i.e remove the data abse record from the rmm cds - is to RMM DV volser FORCE For system managed volumes, depending on whether you want the volume ejected from the library or does not exist in the library when it should, you might add NOEJECT to that subcommand. Mike Wood RMM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
On 15 Dec 2009 05:23:16 -0800, jch...@ussco.com (Chase, John) wrote: >It would seem that if Neon prevails, IBM's marketing credibility will be >reduced to that of politicians seeking (re-)election to high office. I think you exaggerate.It will only be reduced to the level of that Tiger would have if he told us he never looked at another woman. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
I'm just throwing this idea on the table, and expect either little interest or strong opposition. What if catalog support allowed ALIAS names to exceed 44 characters? First, yes, I did search the archives. Second, Yes I understand the implications. The cost and impact of supporting long alias names (though still not small) would be considerably less than the cost of expanding actual data set names. I just came up with this before my second cup of coffee, so the idea is still cooking. Last time I checked, the impact to IDCAMS and catalog records would mostly involve relaxing the syntax restrictions. The impact to JCL conversion would be similar. JCL processing would have to allow for longer names prior to catalog search, and actual (shorter) names could be stored in places like the JFCB. Certain SMF records might have to change. Expanding a little bit, SMS processing could potentially define long names as aliases automatically and generate actual names using some schema like temporary name generation. Doing this would mask the effort of mapping long and short names from the end user, effectively allowing long names without any special user changes. As for a business case to get IBM to implement- oh well. It was just a thought. As a local business case - There are those twice-a-year instances when users can't seem to create a meaningful and acceptable name in under 45 characters. So, I guess I won't be creating any usermods today . . . but if I still had those microfiche . . . >Subject: Re: IDC3203IITEM 'xxx' DOES NOT ADHERE TO RESTRICTIONS >From: "McKown, John" >Reply-To: IBM Mainframe Discussion List >Date: Mon, 14 Dec 2009 10:10:14 -0600 >Not likely to be done. That would require a complete rewrite of the VTOC. >The DSN is a 44 byte hardware key in the VTOC. I cannot imagine how IBM >would ever compatibly change the DSN length. Short of creating an entirely >new, incompatable, interface where something (perhaps in the record which >points to the VTOC) indicates that this is a "new VTOC" formatted volume. >And that would require updates to the entire world. Who's gonna pay? I'd >rather they support SAN DASD in z/OS (which means FBA). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S306-30
Daniel McLaughlin wrote: >Last bugaboo...EXEC gets (-3) executing the RACF ALU command. Try replacing ALU with a safe command like LU (list user) to ensure your EXEC is working 100% correctly. Then you can check the id which is to be resumed/psw changed against the issuer of the ALU command. The id must be owned by the group and the ALU issuer must be group special in that group. If you still see no solution, try looking at the SYSLOG or the SMF records to see what is the reason of the failure ofthe ALU command. >Suggestions? (Going to try IKJEFT01 and see what happens.) Any good/bad results? >When this all works I'll be glad to share it in case anyone is interested. Yes, please if you can. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APF to PDF project
On Tue, 15 Dec 2009 09:52:59 -0500, Adams, Tracy wrote: >I will be initiating a project to "rewrite" our APF images of our >company's bills and produce them as a PDF image. I am not looking for a >AFP to PDF print stream converter. We do have SAS in-house and it does >have limited PDF creation capabilities. Currently the billing system >generates a line of data that gets processed and laid out by PSF on a >form def/page def. Basically the functions of AFP/PSF is to produce a >graph and shade some boxes. Before I dive into SAS, I was hoping >someone out here could make some suggestions, share their experience, >provide some guidance on what paths are tried and true. Thanks in >advance! > No experience, but might AFP -> PostScript -> PDF be a workable path? Could the AFP be bypassed entirely? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S306-30
On Tue, 15 Dec 2009 07:56:36 -0600, Daniel McLaughlin wrote: > >Last bugaboo...EXEC gets (-3) executing the RACF ALU command. My guess is >because of running IRXJCL V. IKJEFT01. I'm also guessing that since the >batch ID has no TSO segment that ADDRESS TSO wouldn't help. > TSO segment has little to do with it: ADDRESS TSO is simply unavailable under IRXJCL regardless. (Well, barring the byzantine ADDRESS SYSCALL spawn of an EXEC which could issue the Unix-peculiar flavor of ADDRESS TSO.) >Suggestions? (Going to try IKJEFT01 and see what happens.) > Does IKJEFT01 require a TSO segment? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
APF to PDF project
I will be initiating a project to "rewrite" our APF images of our company's bills and produce them as a PDF image. I am not looking for a AFP to PDF print stream converter. We do have SAS in-house and it does have limited PDF creation capabilities. Currently the billing system generates a line of data that gets processed and laid out by PSF on a form def/page def. Basically the functions of AFP/PSF is to produce a graph and shade some boxes. Before I dive into SAS, I was hoping someone out here could make some suggestions, share their experience, provide some guidance on what paths are tried and true. Thanks in advance! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OA25988 - IDCAMS DEFINE OF LINEAR DS WITH CISIZE GREATER THAN 4K
On Mon, 14 Dec 2009 10:58:28 -0600, Patrick Lyon wrote: >BTW for those who might care, BMC's fix is PUT0939. > My apologies, the PTFs are BPU0939, BPU0940, BPU0941, and BPU0966. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S306-30
Latest update: Use IRXJCL; changed to generic read-a-record style (only 9 records input in any case); modified JCL to have DD cards for input and output...creating new passwords and saving into a file; file mailed to OPS via SMTP mail. Last bugaboo...EXEC gets (-3) executing the RACF ALU command. My guess is because of running IRXJCL V. IKJEFT01. I'm also guessing that since the batch ID has no TSO segment that ADDRESS TSO wouldn't help. Suggestions? (Going to try IKJEFT01 and see what happens.) When this all works I'll be glad to share it in case anyone is interested. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
So, what else is new? This will complete the decade. Bill Janulin Mgr Tech Support & Product Dev. ASPG, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Tuesday, December 15, 2009 7:23 AM To: IBM-MAIN@bama.ua.edu Subject: NEON sues IBM I guess business has been a bit slow... http://www.neon.com/neon/news_121409.shtm -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ASA character viewer
I wish to thank all of those who replied. All answers were helpful in one way or another. Great list we have here! On 12/15/09, Gerry Palmer wrote: > > I wrote a Microsoft Word macro that handles the basics (new page, skip > one/two/three lines, and to some extent "overtype"). I'll send you the macro > and installation instructions off-list. > > > At 01:50 PM 12/14/2009, you wrote: > >> Do you know of a freeware Windows viewer that can display reports with >> embedded asa carriage control characters and be able to display it >> correctly? The viewer should be able to interpret the ASA characters. >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- "I am as you, in you, for you. One as you in all, as all, forever. My call is your call." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
Surely this is just the start of the game of legal ping-pong between the two? A veritable sea of lawyer drool at the prospect of those billable hours. Rob Scott Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shane Sent: 15 December 2009 13:06 To: IBM-MAIN@bama.ua.edu Subject: Re: NEON sues IBM On Tue, 2009-12-15 at 07:58 -0500, Bob Shannon wrote: > The owner is a lawyer and is a billionaire, give or take. This was expected. No doubt all true, but I had expected the action in the reverse direction. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Shane > > On Tue, 2009-12-15 at 07:58 -0500, Bob Shannon wrote: > > > The owner is a lawyer and is a billionaire, give or take. This was expected. > > No doubt all true, but I had expected the action in the reverse > direction. It would seem that if Neon prevails, IBM's marketing credibility will be reduced to that of politicians seeking (re-)election to high office. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
On Tue, 2009-12-15 at 07:58 -0500, Bob Shannon wrote: > The owner is a lawyer and is a billionaire, give or take. This was expected. No doubt all true, but I had expected the action in the reverse direction. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NEON sues IBM
The owner is a lawyer and is a billionaire, give or take. This was expected. Bob Shannon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stacking vs. non-stacking PC's
The stacking PC instruction is undoubtedly quite a bit slower than the basic PC, but that's not where the story ends. A basic PC protocol includes saving and restoring regs and the secondary ASN, and is intended to go through PCLINK STACK processing on the way in and PCLINK UNSTACK processing on the way out. All of this together takes far longer than a stacking PC / PR. With reusable LX's, basic PC's are extremely tedious / difficult to accommodate. That is why almost every basic PC within z/OS itself was changed to be stacking. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
NEON sues IBM
I guess business has been a bit slow... http://www.neon.com/neon/news_121409.shtm -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Does SAC 0 make PASN = HASN = SASN
127.0.0.1 ;-) Kees. "Rob Scott" wrote in message news:... > Lindy > > :-)) > > > Rob Scott > Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield > Sent: 15 December 2009 11:09 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Does SAC 0 make PASN = HASN = SASN > > This vaguely reminds me of someone I know. > > Regards, > Lindy > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock > Sent: 15. joulukuuta 2009 0:03 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Does SAC 0 make PASN = HASN = SASN > > Could I politely suggest you spend some time reading the cross memory programming documentation? That will be less painful in the end than groping in the dark. > > -- > 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S306-30
On 12/14/2009 01:08 PM, Walt Farrell wrote: > On Mon, 14 Dec 2009 08:04:23 -0600, Staller, Allan > wrote: > >>From your original post: >> >> IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED >> And the FM: >> Explanation: If RACF is installed, a background job will be run using >> the minimum default user attributes. (Not the attributes of >> USER=XXX. My Italics) Either the user ID was unidentifiable, or no >> user ID was specified as a JOB card parameter, or allocation of the user >> attributes data set (SYS1.UADS) failed. >> >> >> >> This means that no userid (in the "true sense") was assigned to the >> task. T > > No, it doesn't. It means exactly what it says, that there is no *TSO* > information associated with the user; i.e., it does not have a TSO segment > nor an entry in UADS, and therefore runs with minimal TSO authorities. > > That message has nothing to do with this problem. And lack of a TSO segment should be a normal setup for a production batch userid which should never be used for an interactive TSO session. Granted, the "PROTECTED" attribute would also prevent that abuse, but with a setup convention with two barriers you would have to commit two setup errors before the userid would be exposed to TSO hacking. -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Does SAC 0 make PASN = HASN = SASN
Lindy :-)) Rob Scott Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lindy Mayfield Sent: 15 December 2009 11:09 To: IBM-MAIN@bama.ua.edu Subject: Re: Does SAC 0 make PASN = HASN = SASN This vaguely reminds me of someone I know. Regards, Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: 15. joulukuuta 2009 0:03 To: IBM-MAIN@bama.ua.edu Subject: Re: Does SAC 0 make PASN = HASN = SASN Could I politely suggest you spend some time reading the cross memory programming documentation? That will be less painful in the end than groping in the dark. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Does SAC 0 make PASN = HASN = SASN
This vaguely reminds me of someone I know. Regards, Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: 15. joulukuuta 2009 0:03 To: IBM-MAIN@bama.ua.edu Subject: Re: Does SAC 0 make PASN = HASN = SASN Could I politely suggest you spend some time reading the cross memory programming documentation? That will be less painful in the end than groping in the dark. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CEE3RPH equivalent for VHM
Hi We also played around with HEAPCHK and VHM. I think a DUMP before termination would conatin all the enclave data. Saravanan J wrote: I used _CEE_HEAP_MANAGER=CEL4MCHK to get Heap storage leak report. The problem with the report is it always gives the enclave name as "main" as shown below "HEAP LEAK REPORT for enclave main, termination report ". In my application we have many enclaves created. Now from the report we are not able to map the individual enclaves and the corresponding heap leak report. Any ideas that will help us here in mapping the report with corresponding enclaves? Something similar to CEE3RPH service will be helpful. Is there an equivalent of CEE3RPH for Vendor heap manager report? Thanks in advance for your help -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Way to use IPCS to browse protected ACTIVE storage
Binyamin Dissen wrote: I vaguely recall a presentation where some (FACILITY?) resource was described as permitting IPCS to display protected storage in the ACTIVE system. I have searched and have not yet found it. Is there such a thing? The two controls with which I'm familiar are: BLSACTV.ADDRSPAC BLSACTV.SYSTEM -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Way to use IPCS to browse protected ACTIVE storage
I vaguely recall a presentation where some (FACILITY?) resource was described as permitting IPCS to display protected storage in the ACTIVE system. I have searched and have not yet found it. Is there such a thing? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Update Notice area of Broadcast dataset
On Tue, 15 Dec 2009 00:52:11 -0600 Ravi Gaur wrote: :>Don't know but SEND 'Text',SAVE command doesn't seems to be working for :>me...is there somekind of parameter/option should be enabled for a :>particular profile? any idea You are aware that SEND SAVE is an Operator command and not a TSO command (though it can be issued from the OPER TSO command)? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Does SAC 0 make PASN = HASN = SASN
On Tue, 15 Dec 2009 08:59:41 +0800 David Stephens wrote: :>Thanks Rob, Chris and Binyamin for your comments. I've learnt a lot from :>them. :>A couple of questions for the panel: :>Chris, you said that: :>"Using AX=1 and SSAR to another address space is not very clearly documented by IBM because it is a violation of the MVS xmemory architecture". :>This comes as a surprise, as I've seen this used in many different programs. Setting AX=1 will certainly allow you to access any address space's memory, but unless you have another TCB needing to AXSET to something other than 1, I can't see how this may not work, or could cause difficulties. Can you give more details? :>You also said that using ASC mode doesn't remove the need for the target address space to be swapped in. Short of a paging error, what could go wrong here? :>Binyamin, you've suggested grabbing the LOCAL lock when the SSAR succeeds. Why do you suggest this? The basic issue is that AX=1 & SSAR gives you a hardware bind to the address space, but MVS is not "aware" of it. It is possible that MVS will choose to swap out what you are using as the secondary address space. MVS does not take kindly to a page fault against a swapped out address space. Taking the LOCAL lock of the secondary address space informs MVS that you have a bind and prevents the swap out. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
