Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler wrote: >I have a request to read the oldest GDG to process. But CSI is slow sometimes >and better other times. How slow is CSI when it's slow, and have you tried to figure out why? More importantly, is it so slow

Re: Fastest way to read OLDEST GDG entry

Why does the process need to delete the oldest GDG after it reads it? Won't the oldest one be deleted when the next +1 GDG is created? Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of

Re: Fastest way to read OLDEST GDG entry

Lizette Koehler wrote: >I have a request to read the oldest GDG to process. I believe someone asked at SHARE, but my memory has been rolled out ala GDG... gr Something like these: MY.GDG(LATEST) (same as (0) ) MY.GDG(OLDEST) MY.GDG(LATEST-7) MY.GDG(LATEST+1) (for creation of a new

Re: OT - another Legacy operating system

On Mon, Nov 16, 2015 at 8:15 PM, Mike Schwab wrote: > > http://www.zdnet.com/article/a-23-year-old-windows-3-1-system-failure-crashed-paris-airport/ > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > ​Sounds "reasonable"

Re: Fastest way to read OLDEST GDG entry

I apologize - I missed the "read and..." part of the process...I would opt for reading the output of a ListCat, then you can programmatically allocate the oldest GDS, process it and then delete it. On Tue, Nov 17, 2015 at 7:21 AM, Mike Schwab wrote: > If you delete all

Re: OT - another Legacy operating system

Interestingly enough the article blames the hardware, "un ancien ordinateur", not the software. I'm not sure the writer knows the difference, but it's hard to believe the software quit if it had been running for 23 years. --

Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 17:12:09 +0100, Peter Hunkeler wrote: > >> Check out the GDGORDER parameter. It became available in z/OS 2.2 > >This actually became available with z/OS V2.1 Yes. Thanks for the correction. -- Tom Marchant

Re: OT - another Legacy operating system

On 2015-11-17, at 08:16, R.S. wrote: > W dniu 2015-11-17 o 16:01, Charles Mills pisze: >> Could be the software, or at least a vulnerability in the software. Windows >> 3.1 has not had a security patch since who knows when. > The good news it does not need most of the patches. > In the old times

AW: Re: Fastest way to read OLDEST GDG entry

> Check out the GDGORDER parameter. It became available in z/OS 2.2 and allows > you to process generation data sets in the order they were created. This actually became available with z/OS V2.1 And it doesn't help with her request to process the latest GDS *only* -- Peter Hunkeler

Help with mount?

Dear Group, Sometime USS throws me a curve. I notice UMOUNT vs UNMOUNT and some other 'features'. I learned MOUNT must have mount authority before you can issue the mount command. We are running z/OS V2R1. Q). Our RACF group says they don't control "mount authority". Where in z/OS

Re: Fastest way to read OLDEST GDG entry

Latest GDG is (-000) . They were wanting the OLDEST GDG with an uncertain number of entries. On Tue, Nov 17, 2015 at 10:12 AM, Peter Hunkeler wrote: > >> Check out the GDGORDER parameter. It became available in z/OS 2.2 and allows >> you to process generation data sets in the

Re: Fastest way to read OLDEST GDG entry

If the intention is to just delete the oldest generation, why not run IEBGENER of a dummy file to create the new +1, and this will make the oldest generation fall off. Then you could run a job to delete the (0) generation. On Tue, Nov 17, 2015 at 6:26 AM, Elardus Engelbrecht <

Re: Fastest way to read OLDEST GDG entry

If you delete all GDG members, the next one created will be G0001V00. TSO Batch IF dsn(-255) exist THEN ... On Tue, Nov 17, 2015 at 4:06 AM, Lizette Koehler wrote: > I have a request to read the oldest GDG to process. But CSI is slow sometimes > and better other times.

AW: Re: Fastest way to read OLDEST GDG entry

Processing all GDSs using the base entry is kind of like processing a DD concatenation. I can't tell the details from memory, but in Assembler you can code so that you get control when the system reaches the end of one dsn in the concatenation, just before it is going to open the next one. I

Re: OT - another Legacy operating system

W dniu 2015-11-17 o 15:02, John McKown pisze: On Tue, Nov 17, 2015 at 7:50 AM, Jon Butler wrote: Interestingly enough the article blames the hardware, "un ancien ordinateur", not the software. I'm not sure the writer knows the difference, but it's hard to believe the

Re: OT - another Legacy operating system

This machine, running this application, for 23 years has proven to be reliable for this job. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: 17 November, 2015 16:21 To: IBM-MAIN@LISTSERV.UA.EDU

Re: Fastest way to read OLDEST GDG entry

Lizette, Check out this smart DFSORT trick "Copy GDG records in first in, first out order" here http://www.ibm.com/support/docview.wss?uid=isg3T794 In step S2 you need to use the following control cards to just limit the oldest GDG generation //SYSINDD * OPTION COPY,STOPAFT=1

Re: OT - another Legacy operating system

Could be the software, or at least a vulnerability in the software. Windows 3.1 has not had a security patch since who knows when. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, November 17, 2015

Re: Fastest way to read OLDEST GDG entry

In , on 11/17/2015 at 07:58 AM, John McKown said: >I don't know why the OP says that IGGCSI00 is "slow". Or why LISTC would be any faster. -- Shmuel (Seymour J.) Metz, SysProg and JOAT

Re: OT - another Legacy operating system

In <874b151289704e46a874bf2ae6fdd8d1310a7...@kl126r4b.cs.ad.klmcorp.net>, on 11/17/2015 at 02:16 PM, "Vernooij, CP (ITOPT1) - KLM" said: >There are good reasons to keep old, reliable systems Win 3.1 is reliable.? -- Shmuel (Seymour J.) Metz, SysProg and JOAT

Re: AW: Re: Fastest way to read OLDEST GDG entry

In , on 11/17/2015 at 03:59 PM, Peter Hunkeler said: > I can't tell the details from memory, but in Assembler you can code >so that you get control when the system reaches the end of one dsn in >the concatenation, just before it is going to open

Re: OT - another Legacy operating system

W dniu 2015-11-17 o 16:01, Charles Mills pisze: Could be the software, or at least a vulnerability in the software. Windows 3.1 has not had a security patch since who knows when. The good news it does not need most of the patches. In the old times I was the only user of Win3.1 while other

Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 07:06:33 -0700, Lizette Koehler wrote: >So GDGs are typically in LIFO order, for this process the first one created >needs to be process first and then read and processed to the current version. Check out the GDGORDER parameter. It became available in z/OS 2.2 and allows you

Re: Fastest way to read OLDEST GDG entry

It seems you could do a quick LISTCAT in step one of a job, then in step 2 parse out the LISTCAT for the GDG via REXX and sort the GDG's in descending order and generate the JCL to process the data and submit? It's a little work, but it should be fairly easy to implement. -Original

Re: OT - another Legacy operating system

There are good reasons to keep old, reliable systems run crucial operations. Look how long Nasa used 360 machines, and why. The phrase 'crashed in bad weather' suggests also that the hardware broke down. What surprises me is the suggestion that 'one computer' did bring down the entire airport.

Re: Fastest way to read OLDEST GDG entry

On Tue, Nov 17, 2015 at 7:49 AM, Greg Shirey wrote: > Why does the process need to delete the oldest GDG after it reads it? > Won't the oldest one be deleted when the next +1 GDG is created? > ​Not necessarily. That only happens if the number of GDGs which are "rolled

Re: Fastest way to read OLDEST GDG entry

So the intent is to create lots of GDGs throughout the day. Then the process needs to read the oldest GDG, process it, delete it, move on to the next oldest GDG. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill

Re: Fastest way to read OLDEST GDG entry

Yikes. What happens if "lots of GDG's" goes beyond the limit for the GDG? Lost data? How much data are we talking about here? Maybe just a new GDG by day, and keep modding onto it? Can the data be sorted down so that you can process oldest first?

Re: OT - another Legacy operating system

On Tue, Nov 17, 2015 at 7:50 AM, Jon Butler wrote: > Interestingly enough the article blames the hardware, "un ancien > ordinateur", not the software. I'm not sure the writer knows the > difference, but it's hard to believe the software quit if it had been > running for 23

Re: Fastest way to read OLDEST GDG entry

So for this process, the files need to be read in FIFO order of creation. The use of the GDG rather than a HLQ.XXX.Dx.T naming convention was to make it easier to process the files. So GDGs are typically in LIFO order, for this process the first one created needs to be process first and

Re: Fastest way to read OLDEST GDG entry

If you have the FDR reporting tools, you could select, sort, and then generate the JCL to accomplish this. --- z...@cdc.gov wrote: From: "Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)" To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fastest way to read OLDEST GDG

Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 10:17:41 -0600, Mike Schwab wrote: >Latest GDG is (-000) . They were wanting the OLDEST GDG with an >uncertain number of entries. > And no one has asked why. Nor what problem the OP needs to solve. Binary search starting with an a priori known maximal relative generation?

Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 18:41:38 +0100, Lucas Rosalen wrote: >8th email on the thread describes why and the "problem" to solve > That seems to be: https://listserv.ua.edu/cgi-bin/wa?A2=ind1511=ibm-main=344282 Thanks. Keep an external index? z/OS UNIX directory search is fast; I don't know how

Re: Fastest way to read OLDEST GDG entry

8th email on the thread describes why and the "problem" to solve Lucas On Nov 17, 2015 18:28, "Paul Gilmartin" < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 17 Nov 2015 10:17:41 -0600, Mike Schwab wrote: > > >Latest GDG is (-000) . They were wanting the OLDEST GDG with

Re: Help with mount?

You can add MOUNT to your USERID which is easy or you can just submit a JOB to issue the MOUNT and UNMOUNT Steve -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hansen, Dave L - Eagan, MN Sent: Tuesday, November 17, 2015 8:34 AM

Re: Fastest way to read OLDEST GDG entry

Some example REXX which might be of some help: /* REXX */ X=OUTTRAP("OUT.","*"); "LISTC ENT('gdg.base.name') ALL" X=OUTTRAP("OFF") DSN='?' DO I=1 TO OUT.0 IF 'NONVSAM-' <> LEFT(STRIP(OUT.I,'L'),8) THEN ITERATE DSN=WORD(TRANSLATE(OUT.I,' ','-'),2) LEAVE END IF DSN='?' THEN EXIT(12) /* NO

Re: Fastest way to read OLDEST GDG entry

Another fairly slick way to do this would be to list the GDG base and then parse out the LIMIT. You could then go directly to the file ..(-00"LIMIT-1") which should be the oldest file. This is all assuming that you have created enough files to reach the limit. -Original

Re: Fastest way to read OLDEST GDG entry

Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, which need to be QUEUEd (or PUSHed) onto the stack before the main command is issued. This can be problematic when the response cannot be known in advance of issuing the command. For example, the data set name to use

Moving a Sysplex

Would a GDPS like solution work for moving a sysplex from here to there, where the there is over 1200 miles from here, without taking a sysplex outage? -- Mark Jacobs Time Customer Service Technology and Product Engineering The standard you walk past, is the standard you accept. Lieutenant

Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler wrote: >I have a request to read the oldest GDG to process. But CSI is slow sometimes >and better other times. > >So here is the basic request >File lands as a GDG often > >The process needs to read the oldest GDG and then delete it. > >GDGs

Re: (External):Re: Moving a Sysplex

Thanks Skip - I have a great team to help me. Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 925 738 9443 Corporate Tieline - 89443 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List

Re: Moving a Sysplex

Mark If you look at the Share presentations in Seattle I presented on moving a Datacenter (2 sysplexes ) and how we did it. If you look at that I'd be happy to discuss any questions that arise. My windows were only the time it took for replication to go consistent and then the times to IPL

Re: (External):Re: Moving a Sysplex

I remain impressed with Jerry's accomplishment. Our outage was on the order of 12 hours, but that included time for major network configuration changes and for hours of user testing. They had to give thumbs up for staying in the new location. Until the move was declared successful, we could not

Re: OT - another Legacy operating system

On Nov 17, 2015, at 9:55 AM, Paul Gilmartin wrote: --SNIP_ Related: http://www.nytimes.com/2015/11/18/technology/microsoft-once- infested-with-security-flaws-does-an-about-face.html Pulease talk about a bunch of BS. Ed -- gil

Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 17:57:46 -0600, Paul Gilmartin wrote: >On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler wrote: >> >>Is there another process that could be used to identify the OLDEST GDG for >>Input >>and then delete that GDG? Or is there another way to handle this situation? >>I >>was

Re: Moving a Sysplex

Thanks for the information. Do you remember how long your outage was? We're being told (using one solution) that the outage will be on the order of two hours. Mark Jacobs J O Skip Robinson November 17, 2015 at 2:11 PM Others may know something I don't, but I

Re: Moving a Sysplex

Others may know something I don't, but I would answer No. I don't believe you can run a (parallel) sysplex over that distance because of CF link limitations. Furthermore, assuming that you could somehow get one sysplex member sharing across that distance, you would have to switch from using

AW: Re: Help with mount?

> You can add MOUNT to your USERID which is easy or you can just submit a JOB > to issue the MOUNT and UNMOUNT He asked about the authority to do z/OS UNIX file system mounts and unmounts. Mount authority is given when a) the process doing the mount/unmount is running uid=0 b) the process

Re: Fastest way to read OLDEST GDG entry

On Tue, Nov 17, 2015 at 12:23 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > What makes "V00" ever Vnn, where N<>0? > > -- gil Possibly an IEBGENER from data.set.name(-000) to data.set.name(-000) DISP=(NEW,CATLG). I did do an IEBGENER data.set.name.G0123V00 to

Re: JCL QUESTION :IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET

No,not yetstill looking On Tue, 17/11/15, Vernooij, CP (ITOPT1) - KLM wrote: Subject: Re: JCL QUESTION :IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, 17

Re: Fastest way to read OLDEST GDG entry

On Tue, 17 Nov 2015 18:20:34 -0600, Paul Gilmartin wrote: >On Tue, 17 Nov 2015 17:57:46 -0600, Paul Gilmartin wrote: > >>On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler wrote: >>> >>>Is there another process that could be used to identify the OLDEST GDG for >>>Input >>>and then delete that

Re: Fastest way to read OLDEST GDG entry

On 17 Nov 2015 10:23:30 -0800, in bit.listserv.ibm-main you wrote: >On Tue, 17 Nov 2015 18:41:38 +0100, Lucas Rosalen wrote: > >>8th email on the thread describes why and the "problem" to solve >> >That seems to be: >https://listserv.ua.edu/cgi-bin/wa?A2=ind1511=ibm-main=344282 >Thanks. >

Re: Fastest way to read OLDEST GDG entry

Paul Gilmartin wrote: Naively, I'd expect that LISTCAT use CSI, or something very similar. Years ago a Storage Admin mentioned that his "List every dataset" nightly job was running more than an hour. I was playing around with CSI at the time (via assembler) and modified some existing code

Re: Fastest way to read OLDEST GDG entry

On Tue, Nov 17, 2015 at 3:23 PM, Peter Hunkeler wrote: > > What makes "V00" ever Vnn, where N<>0? > > > IIRC, the system does not really care for the version number. When a new > GDS is allocated using relative numbering, the version is always V00. If > you want to replace a GDS

Re: OT - another Legacy operating system

Next to the laptop where I am writing this mail stands a desktop computer from 1997 (Pentium, too) with 4,5 GB IBM SCSI Disks (DCAS) running OS/2 3.0, Windows NT, Windows 3.1 (DOS) and Suse Linux, all selectively bootable via OS/2 Boot Manager. The only OS I use regularly is OS/2, for

Re: Fastest way to read OLDEST GDG entry

Versioning - -teD -   Original Message   From: Peter Hunkeler Sent: Tuesday, November 17, 2015 16:42 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: AW: Re: Fastest way to read OLDEST GDG entry > What makes "V00" ever Vnn, where N<>0? IIRC, the system does not

Re: Fastest way to read OLDEST GDG entry

After several decades of using MVS I finally ran into a case where I thought GDS/GDG versioning might be useful and used it to create a corrected version of a GDS generation using V01 to make it obvious it was a corrected version. I was lucky and didn't shoot myself in the foot. Somehow I was

Re: Fastest way to read OLDEST GDG entry

At 12:23 -0600 on 11/17/2015, Paul Gilmartin wrote about Re: Fastest way to read OLDEST GDG entry: What makes "V00" ever Vnn, where N<>0? If you have a DSN called DSN.G0055V00 and create a file called DSN.G0055V01 it will replace the V00 version in the list.

Re: Fastest way to read OLDEST GDG entry

At 07:06 -0700 on 11/17/2015, Lizette Koehler wrote about Re: Fastest way to read OLDEST GDG entry: I have heard the GDG limit in z/OS V2.2 will be higher, so it may not be much of an issue for limit values. Lizette At the current time the limit is 255. Unless you are creating the GDGs

Fastest way to read OLDEST GDG entry

I have a request to read the oldest GDG to process. But CSI is slow sometimes and better other times. So here is the basic request File lands as a GDG often The process needs to read the oldest GDG and then delete it. GDGs must be read in correct order for time/date processing I tried

Re: Fastest way to read OLDEST GDG entry

At 22:05 -0600 on 11/17/2015, Joel C. Ewing wrote about Re: Fastest way to read OLDEST GDG entry: After several decades of using MVS I finally ran into a case where I thought GDS/GDG versioning might be useful and used it to create a corrected version of a GDS generation using V01 to make it

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

On 2015-11-17 12:00, J O Skip Robinson wrote: > Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, > which need to be QUEUEd (or PUSHed) onto the stack before the main command is > issued. This can be problematic when the response cannot be known in advance > of issuing

AW: Re: Fastest way to read OLDEST GDG entry

>Latest GDG is (-000) . They were wanting the OLDEST GDG with an >uncertain number of entries. > >> This actually became available with z/OS V2.1 >> And it doesn't help with her request to process the latest GDS *only* Kind of a typo, isn't it? You're absolutely right. I'm sorry for the

Re: Fastest way to read OLDEST GDG entry

I experimented with this a while back and I believe the results bore out what you stated. As I remember, the displaced GDS ended up cataloged though not as a GDS. From: IBM Mainframe Discussion List on behalf of Peter

AW: Re: Fastest way to read OLDEST GDG entry

> What makes "V00" ever Vnn, where N<>0? IIRC, the system does not really care for the version number. When a new GDS is allocated using relative numbering, the version is always V00. If you want to replace a GDS with a specific generation number while keeping the place in the GDG, you

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

An XMITted file sits in the JES output queue in a designated class (usually B) with the recipient's userid as DEST. When that user issues RECEIVE, all pending XMIT files are presented one by one. For each file, the user can store it, delete it, or issue END. END terminates the RECEIVE command

AW: Re: Fastest way to read OLDEST GDG entry

>Which mentions SYS1.SAMPLIB(IGGCSIRX). A while back I had the need to use this interface in an ISPF/REXX application. I seem to remember that the sample had some flaws. This was in the z/OS V1.11/12 timeframe. Might have been corrected in the meantime. -- Peter Hunkeler