Re: Accessing Cross Memory Storage in REXX

Lourne, You can use AUTHTSF/AUTHCMD definitions to get a REXX external function to operate authorized and then you can MODESET and trash the system to your heart's content :-) I had a quick sniff at the code from the referenced article and it does indeed use AUTHCMD - however the one resoundin

Re: Migrating from z/OS V1.4 to z/OS V1.11

I may have pointed this out before, but, for perspective (and oversimplifying only slightly) the entire rest of the IT world makes big OS jumps *every* time they upgrade. The rigorous, vendor-supported coexistence/fallback regimes available with z/OS release N to release N+1 or N+2 (and its middlew

Re: Accessing Cross Memory Storage in REXX

On Sun, May 9, 2010 at 9:16 PM, Lorne Dudley wrote: > The October 2001 issue of the Xephon MVS Update 181 contained REXX Cross > Memory assembler subroutine code allowing access to information in other > memory spaces by ASID. > > I was never able to get this to operate properly. > > Has anyone h

Accessing Cross Memory Storage in REXX

The October 2001 issue of the Xephon MVS Update 181 contained REXX Cross Memory assembler subroutine code allowing access to information in other memory spaces by ASID. I was never able to get this to operate properly. Has anyone had any success with this or do you have some equivalent code t

Re: /usr/lib/nls/charmap/IBM-1047 (plus announcement / ad, so delete if you're offended)

Tony Harminc wrote: On 1 April 2010 12:06, Steve Comstock wrote: David Bond at Tachyon software has some terrific pages about codepages on their website. A lot of my current work uses this page as a starting point: http://www.tachyonsoft.com/uc.htm#U00F0 Based on this page I see: UCS-

Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)

On Sun, 9 May 2010 10:52:28 -0400, Shmuel Metz (Seymour J.) wrote: > >>How can there ever be an "empty generated SYSIN DD *"? > >The obvious way, if it works, is to place a /* statement after another >JCL statement. > By experiment, it does not. It might be notionally more consistent if it did. >

Re: IEBCOP Y losing A PF authori sation in middle of JOB - etc

On Sun, 9 May 2010 11:36:03 -0400, Shmuel Metz (Seymour J.) wrote: >In , on 04/20/2010 > at 09:18 PM, john gilmore said: > >>An authorized step cannot load a member from an unauthorized library; >>and an unauthorized step cannot of course load a member from an >>authorized library. > >There is n

Re: emptiness

On Sat, 8 May 2010 18:14:27 +, john gilmore wrote: >As I hope has now been agreed, an empty data set, an empty pool, stack, or >queue, an empty whatever is not per se an error. > Uncharacteristically, three of us are in substantial agreement here. >There are circumstances in which the user o

Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)

In , on 05/08/2010 at 11:20 AM, Paul Gilmartin said: >How can there ever be an "empty generated SYSIN DD *"? The obvious way, if it works, is to place a /* statement after another JCL statement. >The SYSIN DD * is generated only if there's a line in the JCL >causing it to be generated, henc

Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)

In <201005082105.esp94...@c2beaomr05.btconnect.com>, on 05/08/2010 at 10:05 PM, Terry Sambrooks said: >It was always my understanding that they would not be the same as the >system had made a decision before IEBCOPY gets the opportunity. >That decision means that SYSIN DD * will cause Device

Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)

In <003501caeed4$23ad0720$6b0715...@org>, on 05/08/2010 at 10:30 AM, Charles Mills said: >Gil's right. I was speaking about a problem described by others not >immediately witnessed by myself and I spoke too hastily. A "generated >SYSIN DD *" should never produce an empty dataset; that would be

Re: IEBCOP Y losing A PF authori sation in middle of JOB - etc

In , on 04/20/2010 at 09:18 PM, john gilmore said: >An authorized step cannot load a member from an unauthorized library; >and an unauthorized step cannot of course load a member from an >authorized library. There is no "of course", because unauthorized programs routinely load members from a

Re: Emptiness (was: IEBCOPY ignoring SYSIN override?)

In <1649177411-1273336230-cardhu_decombobulator_blackberry.rim.net-7911814...@bda026.bisx.prod.on.blackberry>, on 05/08/2010 at 04:30 PM, Ted MacNEIL said: >What is (coded in the JCL): >//SYSIN DD * >/* Something other than an "empty generated SYSIN DD *". The Devil is in the details, and th

Re: Migrating from z/OS V1.4 to z/OS V1.11

In , on 05/07/2010 at 10:36 AM, Pat Mihalec said: >I am running z/OS 1.4 and think of just jumping to z/OS 1.11, if they > finally let me upgrade the software. Unless you have the tapes for intermediate releases in house, you have no choice but to make the big jump. Put the necessary work in

Re: Amazing article.

On Sun, 9 May 2010 16:20:53 +, Ted MacNEIL wrote: >>Apparently abhorrence of liberty is the modal attitude of z/OS programmers. > The Dog in the Manger comes to mind. >Why do you work on a platform you hate so much? > I enjoy it greatly, twice a month. -- gil ---

Re: Passing parameter(s) between IPCS verbexits

IBM Mainframe Discussion List wrote on 05/06/2010 09:16:02 AM: > Any way to pass user parameters (addresses) between different IPCS > verbexit routines ? On verbexit routine could use the Equate Symbol function of the Symbol Service to create a symbol in the dump directory, and another verb

Re: Member name format for z/OS directory as simulated PDS?

On Sat, 8 May 2010 20:27:33 -0400, Shmuel Metz (Seymour J.) wrote: > >>Strange rule; I wonder what motivated it? > >CVOL. > The thread, which you trimmed excessively, as is your bad custom, concerned, for example, why, when the programmer codes: //SYSUT2 DD DISP=(,CATLG),DSN=FOO.BAR ... the

Re: Amazing article.

On Sun, May 9, 2010 at 5:20 PM, Ted MacNEIL wrote: >>Apparently abhorrence of liberty is the modal attitude of z/OS programmers. > > Why do you work on a platform you hate so much? > > Every one has some restriction that users of same don't like! > > Find another field and stop b*tching! Hear, he

Re: Amazing article.

>Apparently abhorrence of liberty is the modal attitude of z/OS programmers. Why do you work on a platform you hate so much? Every one has some restriction that users of same don't like! Find another field and stop b*tching! - Too busy driving to stop for gas! -

Re: Amazing article.

On Sat, 8 May 2010 20:45:54 -0400, Shmuel Metz (Seymour J.) wrote: > >They are now; that wasn't always true. The restriction to 8 character >index level was due to SYSCTLG and CVOL, and is still with us now that >CVOL's are gone. ... >They aren't. E.g., MVS does not allow you to catalog a name

Re: Amazing article.

In , on 05/07/2010 at 12:16 PM, Sam Siegel said: >I'm commenting from the perspective of a developer. I'm not sure that I >understand the distinctions being made. The SYSCATLG and CVOL[1] infrastructure that existed before VSAM maintained a tree with 8 character node names. The original VSAM

Re: Member name format for z/OS directory as simulated PDS?

In , on 05/06/2010 at 04:35 PM, Paul Gilmartin said: >Strange rule; I wonder what motivated it? CVOL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see We don't care. We don't have to care, we're Congress. (S877: The S

Re: Amazing article.

In , on 05/08/2010 at 07:11 AM, "McKown, John" said: >Not any from IBM that I am aware of. IBM's method implys a "stack" of >GDGs, There is no "IBM's method", only IBM's method*s*; as Larry Wall claims, TMTOWTDI. In particular, you can read the catalog, extract the GDS names and process them

Re: Member name format for z/OS directory as simulated PDS?

In , on 05/06/2010 at 07:53 PM, Tony Harminc said: >It's been that way "forever". Since before there were catalogues, I >believe. AFAIK catalogs were there ab initio. >Maybe this predates PDSs, or are they primordial? Primordial. -- Shmuel (Seymour J.) Metz, SysProg and JOAT IS

Re: (may o r may not be on topi c) Floatin g point ar ithmetic?

In , on 05/07/2010 at 12:28 PM, Kirk Talman said: >I agree w/Shmuel. This is a display issue. ? I wrote that it is a numeric conversion issue, *not* a display issue. >The problems were detected because the "old" machine was CDC 1604 which >had the same precision as a 7094. The 7094 was

Re: (may o r may not be on topi c) Floatin g point ar ithmetic?

> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman > > -- > > >It's hardly unusual to have fractional cents in calculations, which > >are rounded to the nearest cent only for the final, billable

Re: Amazing article - Info on Collecting GDGs

> >Not any from IBM that I am aware of. IBM's method implys a "stack" of GDGs, where (0) is always the newest one created. So if you're JCL refers to the current gen, it gets the youngest. There is not an IBM way to process them from oldest to youngest. Now, in a z/OS UNIX paradigm, using DoveTa

Re: GSE Enterprise Security Meeting - 30th June 2010 - UK

All, resent with the correct URL later in the email. Mark > Hi, > > I am pleased to announce the next meeting of the GSE Enterprise Security Group > on the 30th June 2010. > > Full details and Agenda can be found at http://www.racf.gse.org.uk/future.html > > If you wish to attend the meeting

Re: IBMLink and CA Support planned outages this weekend

On 7 May 2010 15:32:13 -0700, in bit.listserv.ibm-main you wrote: >Quite a coincidence > > >Planned IBMLink Outage - May 7 > >5 May 2010 > >This is to inform you that IBMLink will have a planned outage starting on >Friday, May 7th at 9:00 PM Eastern Time through Saturday, May 8th at 9:00 AM >E

Re: Migrating from z/OS V1.4 to z/OS V1.11

Yeahhh that must be the reason. Now why didn't I think of that ?. Shane ... On Sun, May 9th, 2010 at 7:42 PM, Brian Westerman wrote: > I guess I'm just getting mellow. ;) -- For IBM-MAIN subscribe / signoff / archive acces

Re: Migrating from z/OS V1.4 to z/OS V1.11

I guess I'm just getting mellow. ;) Brian -- 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/archive